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