给需求做一次DNA检测：
我们先把用户需求转化为产品需求，然后一步步确定每个产品需求的基本属性、商业价值、实现难度、性价比等。
把用户需求转化为产品需求
检测的第一步就是“需求转化”，现在我们有很多用户需求，可能记录在“单项需求卡片”里，可能记录在Excel里，可能是用Word随意写的几段话，也可能是一张思维导图。
表格中每一行是一个产品需求，而每一列描述了产品需求的一种属性。值得一提的是，用户需求与产品需求是多对多的关系，我们可能用多个功能来满足一个用户需求，也可能用一个功能来满足多个用户需求，甚至是用几个产品需求来满足几个用户需求，其中并没有一一对应的关系。对任何产品来说，只要需求采集的功夫做足了，你就会发现上面这个产品需求列表行数超多，所以在需求转化过程中，我们也会做一轮筛选，把明显不靠谱的用户需求直接过滤掉，不计入上述列表，当然，是否“明显不靠谱”就要由你来把握了，不要把“没资源做”、“短期内有技术难点”的用户需求给错杀了。
确定需求的基本属性
对于产品需求列表的维护，有时候我们是在产品团队里指定一个人负责，所有的
需求都由他来录入，有时候是采取共享文档的形式，大家共同维护，更多相关话题我
会在第3.5.1 节的“多人协作与版本管理”中和大家讨论，但不管怎样，我觉得对于每
个需求，提交人都可以独立确定一些基本属性，如表2-4 所示，这些属性是：
编号：看似作用不大，最初表格中没有这一项，但有一次大家把列表打印出来讨论，当提到某个需求的时候，发现很难告诉大家是哪个，因为Excel的行号没有一并打印出来，所以后来我们都把序号加上了，作为需求的唯一性标识。有时候在某个需求的备注里，也会写“与273 号需求类似，可以参考”。提交人：必填，提交人是PD，我们的需求管理方法比较轻量级，更多的是只管理产品需求，而用户需求并没有很好的整理，经常只是一堆各种格式的文档，所以提交人要负责在今后的任何时候解释这个需求的来源，提交人有义务充分理解原始的用户需求。提交时间：这是一个辅助信息，记录提交人是何时录入这个需求的。模块：一般来说，根据人类记忆的特点，产品有5±2 个模块比较合理，如果超过7 个，你就要考虑重新划分，甚至增加一个基本属性叫“二级模块”。如果你是做网站产品，这些模块的划分就很可能影响到网站的导航结构，这属于信息架构16
16 信息架构（InformationArchitecture），简称IA。它的主要任务是为信息与用户认知之间搭建一座畅通的桥梁，是
信息直观表达的载体。通俗点讲，信息架构就是研究信息的表达和传递。
领域的知识。当然，在设置自己电脑里的文件目录结构时，也可以遵循这个原则。举个例子，如图2-13的网店版菜单结构，就可以从其产品需求列表里的“模块”设置里看出来。
需求种类：
分类：可以分为“新增功能、功能改进、体验提升、Bug 修复、内部需求”等。
其实产品需求远非我们直接可以想到的功能需求，还包括了很多非功能需求，比如：性能、可培训、可维护、可扩展……有很多需求不是为终端用户做的，而是为销售、服务、测试团队的同学做的。
举几个例子，“论坛需要支持1000 人同时在线”，这是一个性能需求；“系统功
能升级，必须在发布2 周以前完成对客服部门的培训”，这是一个培训需求；“如果
硬件压力突增，应该有报警，具体细节是……”，这是一个运维部门的维护需求；“在
用户数增加10 倍的情况下，硬件投入必须小于10 倍”，这是一个可扩展需求；“此
功能的用户操作日志需要记录”，这是一个内部数据分析的需求。
当然，对于一些边缘的需求，是列入这个表格统一管理，还是另外单独对付，这可以随机应变。
通常来说“产品功能需求+产品非功能需求= 产品需求”，而“产品需求+市场需求+开发需求+测试需求+服务需求+…… = 产品包需求”，对这些概念感兴趣的同学可以去查阅“需求管理”相关的资料。层次：把需求分成“基础、扩展（期望需求）、增值（兴奋需求）”三层，理论
依据参见KANO模型17
17 KANO 模型以东京理工大学教授狩野纪昭（NoriakiKano）的名字命名，是一种对顾客需求或者说对绩效指标的
分类，通常在满意度评价工作前期作为辅助研究模型，KANO模型的目的是通过对顾客的不同需求进行区分处
理，帮助企业找出提高企业顾客满意度的切入点。
。
举个例子：
小明：“我想到一个手机的例子，打电话、发短信是基本功能；给电话录音是扩
展功能，和基本功能相关；而如果这个电话特别结实，可以当锤子砸钉子，或者当砖
头防身，那就是增值功能了。”
大毛：“嗯，好多山寨手机的特点就在于满足了一些诡异的增值需求，比如可以
当手电筒、当验钞机、当剃须刀……”
对需求种类的区分其实没那么绝对，取决于很多因素，比如商业目的变了，某个功能的分类也就变了，我自己经常从“雪中送炭”还是“锦上添花”的角度去理解：雪中送炭是基本功能，对用户很有用，产品缺了这个功能根本跑不起来，比如E-mail系统里的“收发邮件”；锦上添花的功能是指非必须的，用户有时用得到，有的话会给用户的使用带来方便，比如在发E-mail填写收件人的时候，系统根据你输入的内容自动提示你曾经发送过邮件的联系人。
我们在和用户接触的过程中会很明显地感受到这两种需求的不同，没有雪中送炭
的功能就像系统有缺陷一样，所以应优先考虑。而当一个锦上添花的功能被用户普遍
接受以后，几乎所有的产品也都拥有了，也就渐渐发提升为雪中送炭的功能了，就像
现在的手机，几乎没有人能接受黑白屏一样，当初彩屏可是作为一大卖点来宣传的。
分析需求的商业价值
一个公司做任何产品，一个产品做任何需求，最终都是要满足一定的商业目的，
所以“需求的商业价值”是最关键的内容，有条件的团队最好利用群体智慧，我们通
常在这个时候举行“需求讨论会”。
正因为商业价值如此重要，所以最复杂的时候我们尝试过用重要性、紧急度、持
续时间3 个指标来衡量，如表2-6 所示。
重要性：可以参考时间管理里“重要与紧急”的概念。这里的重要度又可细分为：满足后“一般”“非常高兴”；未实现“略感遗憾”到“非常懊恼”，更多可以学习KANO 模型加深理解。
紧急度：在时间维度上判断这个需求是否迫切，紧急不重要的需求通常表现为解决了短期的问题，如果熬过去没做，对长期影响不大；或者解决了局部的问题，如果不做对于大多数用户没有影响。比如某个用户是大老板的朋友，通过大老板“天外飞仙”地提过来一个需求，就很可能是一个超级紧急的需求，但重要性未必很高。
持续时间：需求是有生命的，有的长寿有的短寿，比如迎合过年过节的运营活动需求，一般就比较短寿。试想8 月我们录入了一个庆国庆的主题运营活动，如果到了9月底还没资源做，那一年内也就不用再考虑这个需求了。
商业价值，或者叫商业优先级，是对上述几种商业价值指标的综合评判。这一条是整个需求列表中最核心的部分，这里的判断直接影响着产品未来的方向。有时候我们还在列表里增加一列“商业价值描述”，通俗点就是这个需求的卖点是什么，可以给用户提供什么价值，对公司又有什么帮助。如此重要的商业价值评估，我们的做法是在需求讨论会上由产品团队集体讨论，再叫上有必要的干系人，比如销售、服务等。对于某个需求，需求提交人是对它最熟悉的，提交人先基于自己对商业目标的理解，做一番陈述，主观定个级别，比如高中低。然后大家讨论，所以在这个讨论会之前，每个人都应该做好功课。
上述那么多的维度，可以加权平均得到综合的商业价值，我们甚至还尝试过在列
表中增加“某关键人物的打分”一列，但绝大多数实际操作中，我们都是直接把商业
价值抽象为一个指标，用“高、中、低”，或者“5、4、3、2、1”来衡量。而具体讨
论的时候，大家充分表达意见之后，安全的做法是谁官大谁负责，俗称老板拍脑袋，
最终由会场上级别最高的人报一个数字结束，这就是现实，也是一种高效的办法。我
曾经考虑过群体打分取均值等方式，可是实施起来成本太高，很难推动，也不是很有
必要。
初评需求的实现难度
绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做。
我们现在知道了每个需求的商业价值，接下来决定做哪个还需要另一个关键指标，那就是——实现难度。有时候我们会叫上技术人员代表参与需求讨论会，当场确定这个指标，但更多的情况是留给做技术的同学一点时间，会后与相关的PD 讨论确定。但实现难度这个词太难量化，所以在实际操作中我们会对它进行大刀阔斧的简化。
首先简化为人力成本，即工作量，其他资源的消耗，比如额外的硬件成本，我们会发现只有极少数的需求会有这样的问题，不具有普遍性，所以碰到的时候都做特例处理。
其次，我们把工作量再简化为开发量。我经历的项目，各类人力资源有：产品、开发、测试、服务等。但一般情况下，团队里产品人员资源相对富裕，测试资源可以调配，服务资源可以临时补充，所以开发资源经常成为瓶颈。于是，我们一般评估每个需求的开发工程师工作量来表征其实现难度，这背后的道理是以团队里的瓶颈资源
为评估基准（如表2-7 所示），大家视自己团队的情况灵活应用。
在这个时候，需求其实并不明确，只知道要做哪些，还是比较粗略的要点，而具体怎么做根本还没有考虑，所以有的技术人员会觉得无法评估开发量，这很正常，这个问题我们和技术人员纠结过许多次。他们说你们不明确每个需求怎么做，他们就无法准确评估开发量，我们说没那么多时间明确每个需求该怎么做，你们不评估每个需求的开发量，我们就不知道哪些值得进一步分析怎么做，而哪些又不值……于是就死循环了。这类先有鸡还是先有蛋的问题也无须纠缠，我们继续讲实际的。
开发量是非评估不可的，我把它叫做“初评”，允许误差，并且会要经验丰富的人来评估，通常是技术经理，或者系统分析师、架构师。他们做出简单的评估，并且靠不断的实践来反复修正，评估者通常估计自己做这个需求要多少时间，然后乘以一个系数，这个系数大于1，反映着相应技术团队的平均技术能力。这里的评估一般用“人天”作为单位，某个需求需要“1 人天”意味着需要1 个人做1 个工作日。
相对于“初评”，在项目启动之后，制定项目开发计划的时候还会有一次更精确的评估，那时候需求怎么做已经知道、由哪位开发工程师来做也知道，所以可以推算出相对准确的工期，工期和工作量是有很大区别的，比如生一个小孩，需要1 个女人10 个月的时间，工作量可以说“10 人月”，但10 个女人1 个月的时间，同样“10 人月”是绝对完成不了这个任务的，不管几个人，工期都只能是10 个月……
性价比
不要试图满足一切用户
性价比 = 商业价值÷实现难度（简化为开发量）
现在可以做决定了，我们把产品需求列表按照“性价比”一列从大到小排序，先
做排在上面的就可以了（如表2-8 所示）。
但是工作中对“性价比”的判断还是会经常有偏差，很实际的一个原因，是自己经常和哪类人接触。在工作中，由于一直和工程师直接接触，经常听到他们抱怨某个需求太麻烦之类的，所以综合考虑时有点倾向于做实现难度小的；而如果经常和销售、运营的同学一起开会，就会倾向于更多的考虑商业价值，这点与大家共勉，时刻注意。
道理说完了，对需求的DNA 检测也暂告一个段落，接下来我们将迎来一场残酷的
“战争”。