需求基础：需求的定义、类型与来源

需求是产品概念设计的逻辑起点。没有清晰的需求定义，后续所有的功能规划、技术选型和方案评估都将失去判断基准。在实际项目中，我们经常看到“需求变更频繁”“开发出来的功能没人用”“技术实现与业务目标脱节”等现象，其根源往往不是执行力不足，而是对需求本身缺乏结构化的认知。本章将围绕“需求是什么、需求分几类、需求从哪里来”三个核心问题展开，帮助学员建立一套可操作的需求分析框架。

需求的定义与本质

需求（Requirement）在IEEE标准中的定义是：用户为解决某一问题或达到某一目标而需要具备的条件或能力。但在产品实践中，需求并不是一个静态的“待办清单”，而是一个从模糊到清晰、从抽象到具体的动态演化过程。需求本质上是对“问题空间”与“解决方案空间”之间差距的描述——它既包含对现状不满的表述，也隐含了对未来状态的期望。

理解需求需要区分三个层次：需求（Need）是用户内心深处的真实诉求，往往难以直接表达；期望（Want）是用户基于自身认知提出的显性要求；规格（Specification）是产品团队将需求转化为可验证的技术描述。例如，用户说“我希望系统响应快一点”，这是期望；其背后的需求可能是“减少等待焦虑，提升工作效率”；转化为规格则是“在4G网络下，列表页首屏加载时间不超过1.5秒”。

需求的三种类型

在概念设计阶段，将需求划分为用户需求、业务需求和技术需求，有助于团队从不同视角审视问题，避免“一锅烩”导致的优先级混乱。

三类需求之间存在传导关系：业务需求定义了“为什么做”，用户需求定义了“做什么”，技术需求定义了“怎么做”。在概念设计阶段，如果业务需求不清晰，用户需求就会失去方向；如果用户需求不充分，技术需求就会变成无源之水；如果技术需求被忽视，再好的功能设计也可能在实现阶段遭遇瓶颈。

需求来源的五大渠道

需求不会自动出现在产品经理的办公桌上，需要主动、系统性地从多个渠道获取。根据项目实践，需求来源可以归纳为以下五个主要渠道：

1. 干系人直接沟通：包括用户访谈、客户拜访、管理层战略传达、客服反馈汇总。这是最直接的需求来源，但需要注意“用户说的不等于用户要的”，需要交叉验证。
2. 数据分析与行为观察：通过产品日志、用户行为路径、功能使用频率、流失漏斗等数据，发现用户“实际做了什么”与“声称要什么”之间的差异。数据能揭示用户自己都未意识到的需求。
3. 竞品分析与市场研究：研究竞品的功能设计、用户评价、市场报告、行业趋势，可以识别出“用户已经习惯但现有产品未满足”的需求，以及“未来可能产生”的潜在需求。
4. 原型测试与实验：通过低保真原型、MVP（最小可行产品）、A/B测试等方式，让用户在真实或接近真实的环境中体验，观察其反应和行为，从而验证和修正需求假设。
5. 内部利益相关者：销售团队了解客户痛点，技术支持团队了解常见故障，法务团队了解合规要求，财务团队了解成本约束。这些内部视角往往能补充外部用户看不到的约束条件。

需求分析的操作流程

从原始信息到可执行的需求定义，需要经过一个结构化的处理流程。推荐采用以下五步法：

• 第一步：收集与记录。将所有来源的原始信息统一记录，不遗漏、不筛选。使用需求卡片或电子表格，记录信息来源、提出者、时间、上下文。
• 第二步：分类与去重。将原始信息按用户需求、业务需求、技术需求分类，合并重复项，识别冲突项。冲突项需要单独标记，后续通过优先级排序或干系人协商解决。
• 第三步：优先级排序。采用MoSCoW方法（Must have必须有、Should have应该有、Could have可以有、Won't have本次不做）或Kano模型（基本型、期望型、兴奋型）进行排序。业务需求通常决定Must项的边界。
• 第四步：可验证化表达。将模糊的需求描述转化为可度量的验收标准。例如，“系统要快”转化为“在标准测试环境下，API响应时间P95小于200ms”。
• 第五步：评审与基线化。组织干系人评审，确认需求理解的准确性，形成需求基线。基线后的变更需要走正式的变更管理流程。

案例拆解：企业报销系统的需求定义

某中型企业（约2000名员工）计划开发一套新的费用报销系统，替换现有的Excel+邮件审批模式。项目启动初期，团队收集到以下原始信息：

• 财务总监：“现在每月处理报销单约1500份，财务团队3个人需要8个工作日才能完成审核，希望新系统能将审核周期缩短到2个工作日以内。”
• 销售员工：“每次贴发票、填单子特别麻烦，尤其是出差期间，单据容易丢，希望手机就能拍照上传。”
• IT部门：“现有系统没有API接口，无法与ERP对接，希望新系统支持标准接口，并且数据安全等级要达到等保三级。”
• 客服记录：“员工经常抱怨报销进度不透明，不知道钱什么时候到账。”

团队按照五步法进行分析：

分类与澄清：财务总监的表述属于业务需求（效率提升），销售员工的表述属于用户需求（便捷性），IT部门的表述属于技术需求（集成与安全），客服记录反映的是用户需求（透明度）。进一步访谈发现，员工真正的痛点不是“填单麻烦”，而是“垫付资金压力大”，希望缩短报销到账时间。

优先级排序：业务需求（审核周期缩短）为Must项；用户需求（移动端拍照上传）为Should项；技术需求（等保三级）为Must项（合规强制）；透明度需求为Could项。

可验证化表达：将“审核周期缩短”转化为“从员工提交完整单据到财务审核完成，平均时长不超过2个工作日，P90不超过3个工作日”；将“拍照上传”转化为“支持iOS/Android端拍摄发票，OCR识别率不低于95%”。

结果与复盘：系统上线后，审核周期从8个工作日缩短到1.5个工作日，员工满意度提升32%。复盘发现，最初收集的“填单麻烦”需求其实掩盖了更深层的“资金垫付压力”需求，如果只按表面需求设计，可能会做出一个“更好用的填单工具”，而无法真正解决业务问题。

常见误区与总结

在需求基础分析中，产品团队常犯以下错误：

• 误区一：需求收集等于需求分析。收集只是第一步，真正的价值在于后续的分类、验证和优先级排序。很多团队收集了大量信息，却从未进行结构化处理，导致需求池变成“垃圾场”。
• 误区二：只关注用户需求，忽视业务需求。用户需求解决的是“好用”问题，业务需求解决的是“值得做”问题。如果业务需求不成立，再好的用户体验也无法支撑产品持续发展。
• 误区三：技术需求被当作“实现细节”而推迟讨论。技术需求（如性能、安全、可扩展性）直接影响概念设计的方案选择。等到开发阶段再考虑，往往需要推翻重来。
• 误区四：需求优先级由嗓门大小决定。谁声音大、谁职位高，谁的需求就优先。这会导致资源错配。应建立客观的优先级评估标准，如价值-成本矩阵、Kano模型等。

总结而言，需求基础是产品概念设计的“地基工程”。清晰定义需求、准确分类需求、系统化获取需求，是后续所有设计工作的前提。本章建立的分析框架——从定义到类型、从来源到流程——为学员提供了一套可复用的方法论。在下一阶段的概念设计工作中，请时刻带着“这是哪类需求？它来自哪里？它是否可验证？”这三个问题去审视每一个输入。