自由读 — 15.3需求管理步骤1：需求收集

15.3.1 需求的特点

♢需求不总是显而易见的，而且它可来自各个方面；

♢需求并不总是容易用文字明白无误地表达；

♢存在不同种类的需求，其详细程度各不相同；

♢如果不加以控制，需求的数量将难以管理；

♢需求相互之间，以及与流程的其他可交付工件之间以多种方式相关联；

♢需求既非同等重要，处理的难度也不同；

♢需求涉及众多相关利益责任方，这意味着需求要由跨职能的各组人员来管理；

♢需求发生变更；

♢需求可能对时间敏感。

15.3.2 需求收集12种方法

表15-4列出了需求收集的12种方法，并且列出了优劣势。通过这12种需求收集方法，收集原始需求数据，整理需求（解释和翻译、整合、归并、分组），排优先级，检查结果和流程规范性，完成需求收集活动。

表15-4 需求收集的12种方法

序号	名称	主要目的	优点	缺点	特点
1	用户拜访、投标、访谈、销售人员反馈、客户满意度调查	获得用户对现有产品的意见、未来期望、重要程度等，开发中新产品的早期反馈、验证	在反馈、验证过程中得到更多需求，客户对竞争者和公司产品的综合评述	意见散乱，从公司整体角度获得宏观的输入，对产品级的反馈较少	短期到中期的需求
2	研发高层交流	与用户交流双方在业务、产品上目前的问题和未来的趋势	了解双方问题的焦点，预测未来需求的要点	纯技术层面，对业务的需求和技术实现无充分的考虑，不可轻易承诺	覆盖从短期到长期的需求
3	内部专家顾问团	聘请行业专家、研发人员、技术规划人员根据产品市场趋势，提出的需求和新技术应用。找到跨不同用户群和产品的共同需求，确定它们的汇聚点	相互激发思维	容易走题	需求中长期、明确
4	用户大会、技术推广	产品发布，检视过去、规划未来。加强与客户的沟通交流，验证当前开发计划，商讨未来计划	高层次的交流，容易取得有价值的需求	需求采集淹没在产品的推销中。客户在会议上的语言闪烁其词	需求为中长期、未来版本
5	需求探针	了解客户目前的业务和需求，根据客户战略及业务的发展变化，预测客户需求	可以随时把握客户在业务方面和需求方面的变化，利于公司产品的改进和未来需求的预测	人员成本较高，人员素质要求高	短期、中期、长期需求全面掌握，适用行业大客户
6	合作开发	确保满足客户需求的产品，提炼客户的核心需求，深度了解客户的业务	对客户需求了解的深度与广度得到提高	容易忽略别人的经验点	中期需求
7	产品试用	对产品概念、原型的验证、补充	获得的需求明确，方便在产品的当前或以后版本中进行采纳	围绕问题，需求采集作用小，代表性差	短期需求
8	现场支持	派驻客户驻地，及时响应客户的支持需求获得产品问题和支持需求	一线接触，获得产品兼容、竞争比对、产品缺陷信息	关注产品的缺陷和问题较多依赖于双方支持人员的交流情况	短期需求，包括可服务性需求和服务需求
9	售后反馈/服务	采集目前公司产品存在的问题，特别是可维护性需求，减少维护成本	对现有产品的主要问题可以得到全面的反馈	对产品未来的机会点很少	短期需求
10	网站/售后支持热线	用户投诉、热线、售后维修记录，了解现有产品缺陷，重大事故经验	主要问题可以得到有效的体现	信息量大、杂乱。需求通常是非常具体的，需求收集并不是热线支持特别关注的方面	短期需求
11	参与行业会议、论坛/新闻媒体	委托第三方或者自行通过市场调查、网络等方式获得行业分析报告，业界的认知，提高信誉，吸引新的客户。收集业界与竞争对手情报的机会	会议是获得客户需求的一种间接方式	重点在于提高知名度和信誉，获得业界最新消息，收集竞争对手情报，获得客户需求并不是其关注的重点	获得中长期需求
12	标杆研究	收集竞争对手相关产品的技术规格资料，用标杆来评估产品性能，并按照业界/客户认可的性能标准衡量，以及产品与竞争对手相比的好坏	帮助测试是否满足性能要求，并反映出竞争定位情况	与需求收集的联系松散，不系统	适用于时间范围短的当前版本

案例分析：某企业的需求记录来源如图15-2所示。

图15-2 某企业的需求记录来源

该企业的需求统计特点包括：

♢网站平台约占1/3的需求来源，其他是内部IT平台；

♢太多短期需求（3～6个月内需要实现）；

♢需求拒绝的原因包括6.5%重复提交、9.5%无价值、16.1%已规划、21.3%已经实现、46.6%是长期需求。

一般需求收集有两个特点，一是大部分需求来自于公司内部渠道，需要增加客户渠道、市场渠道的需求。二是大部分需求都是短期需求，实现这些需求的产品必须在6个月或更短的时间内交付。应该有一大部分需求是交付时间为一年或一年以上的长期需求，这样才可以及时开发出高质量产品，而不是在最后时刻匆匆交付低质量产品。

所有的需求都要归入需求管理组织进行统一管控处理。有接口人的市场区域需求，也一并提交需求管理组织进行管控，对需求进行分析批准后再递交给研发实现。需要减少甚至杜绝绕过正式流程而向PDT直接提交客户需求。

建立客户需求收集的长效机制，识别客户的重要需求，降低需求收集的盲目性，建立合理的需求收集的方法和过程，提高需求收集的有效性，需求访谈的方法和技巧。

案例分析：某企业需求收集的来源如表15-5所示。

表15-5 某企业需求收集的来源

序号	主题	内容
1	新产品规划类需求	包括产品研发过程中产生的需求
2	老产品维护类需求	由外部传来的需求： ² 新功能：原产品不能支持的功能； ² 新配置：指产品设计时已考虑的各种功能组合，但产品上市以来主要量产的是一些常见的功能组合，而一些不常见的功能组合没有提供配置清单BOM，因此提出新配置需求； ² 定制化：指丝印、颜色、包装（说明书、铭牌、保修卡、装箱清单、包装箱、卡通箱）； ² 认证：老产品维护中仅指证书到期或其他需要重做的认证（新产品认证包括各项产品认证的计划，以及根据计划逐步地去做各项产品认证）
3	内部需求	成本降低，物料替换，缺陷修复，性能提升

15.3.3 需求属性模板

除了需求的内容外，每个功能需求应该有一些相关属性与之相联系。这些属性为每个需求建立了一个上下文和背景资料，方便对需求的理解，并为开发活动提供决策的参考。定义和更新这些属性值是需求管理的一部分。表15-6这个属性模板亦可作为《客户原始需求信息表》，对于收集到的用户需求详细记录到该表中，避免需求的遗漏。

表15-6 需求属性模板

序号	需求属性	说明
1	需求编号	需求的顺序号
2	需求名称	标题，一句话概述需求内容
3	需求来源	由用户依据实际填写需求的来源，市场分析、预测、与公司各事业部及其他客户交流、使用过程、工作中的思考等，高层交流、定期客户拜访、现场支持、竞争产品分析、支持热线、参加展览会、客户满意度调查
4	需求提出人	该需求的提交人，一般是需求收集活动的责任主体
5	需求提交时间	自动记录
6	所属部门	提交人的所属部门
7	需求描述	需求内容详细描述，对需求的详细叙述，需求目标，必需的功能等
8	需求类别	业务需求、用户需求、功能需求、质量需求、性能需求、其他需求、问题、预研等可自由扩充
9	优先级	最高（5）、高（4）、中（3）、低（2）、最低（1），第5级需求在提交后第二天即要求开始处理，并由专人跟催。第1级需求定期进行处理，主要起备忘的作用。一般需求的优先级为4、3、2
10	优先级说明	从各个角度（市场、成本、重要程度、紧急程度等）详细说明设置优先级的理由
11	所属产品	由用户填写需求对应的产品或者项目，包括产品的型号和版本，没有填“无”
12	客户信息	记录提供需求的客户信息（可选）：客户公司名称、客户姓名、客户职务、联系方式
13	希望交付日期	需求提交人员希望该需求交付的日期
14	竞争对手状况	指出竞争对手在该需求的满足程度情况，如有可能，指出具体的竞争对手。 ² 哪些竞争对手已实现该需求，描述竞争对手的特色和产品运行情况； ² 竞争对手是否就此点攻击我们产品； ² 用户是否会采用竞争对手的方案作为公司的替代方案； ² 实现该需求对竞争对手的影响

案例分析：某客户的需求卡片如表15-7所示。

表15-7 某客户的需求卡片

需求编号:年月日＋员工号＋需求顺序号

需求类型：（在进行评审时填写）

来源（Who）：

² 公司提供者：需求提供者的部门、联系方式

² 产生需求的客户：用户需求的公司、部门、岗位、联系方式

² 客户背景资料：受教育程度、岗位经验、其他与本单项需求相关经验

场景（Where、When）：

产生该需求的用户活动特定的时间、地理、环境

描述（What）：

用（主语＋谓语＋宾语）的语法结构，禁止使用修饰语句

原因（Why）:

验收标准（How）：

² 用量化的语言

² 无法量化寻找标杆

需求重要性权重（How much）：

² 满足后（1一般～5非常高兴）

² 未实现（1略感遗憾～5非常懊恼）

需求生命特征（When）：

需求的迫切度和时间持续性

需求关联（Which）：

² 人：需求关联的用户影响人物

² 事：需求关联的用户业务与关联需求编号

² 物：需求关联的客户系统、设备

² 需求关联的公司产品及版本

参考材料：在采集活动中的输入材料，仅仅输入援用的条目、章节

竞争者比对：（按照1差～10分好进行评估）

² 竞争者对该需求的满足方式

² 用户、客户对竞争者及公司在该需求的评价

15.3.4 需求收集要点

一般由产品经理编写汇总需求，列出需求规格表（或产品规格书，不管是ODM/OEM，还是自主研发产品），并不断完善。小一点的企业由项目经理兼职承担，但最好是设立产品经理负责，项目经理更侧重于项目管理，而不是产品管理。规范需求收集模板，形成需求IT数据库。需要保证足够的用户参与时间，因为用户经常不明白为什么收集需求和确保需求质量需花费那么多时间，不愿意给太多的沟通时间，研发人员也可能不重视用户的参与，觉得与用户合作不如编写代码有意思，或觉得已经明白用户的需求了。以下是需求收集的要点：

♢多听少说；

♢多听多问，不要推销你的想法；

♢对于听到的信息要确认，确保理解对方的意思，以及客户真正的意图；

♢语言要中性，有些话你越不赞同，可能越是机会；

♢表现得“无知”一些，让客户详细举例或描述；

♢聚焦于期望，而不是问题；

♢了解不一致的地方；

♢注意引导、倾听人们的“话外音”；

♢没有十足把握前，不要将你了解到的东西与他人交流；

♢不要完全相信任何人；

♢所有收集到的需求都应记录下来；

♢不对外承诺无法实现的功能、不能达到的指标。