读完了书第2.5节：心急吃不了热豆腐，主要讲的是需求管理，也是第二章的结束。
产品反复经历需求采集、需求分析、需求筛选的过程，才能不断进化不断完善。在这个过程中需求会越来越多，因此我们必须在资源有限的情况下找到并做好最有价值的需求，这就是需求管理。作者提出的方法是：在产品需求列表上再加几个属性项，管理需求的生命周期，主要是需求的状态和各阶段的负责人。
需求管理
需求状态。通常有“待讨论”（需求讨论会讨论的）、“拒绝”（商业目标在相当长的时间内没有价值）、“暂缓”（有价值但现在不做，通常要表明重启条件）、“需求中”（要继续初评工作了量计算性价比）、“开发中”（产品会议上通过的需求，正式进入项目）、“已发布”（项目发布）几个状态，可按照实际情况有所增减，比如管理的粒度细一点，还可以增加“测试中”。
负责PD。在需求状态变为“需求中”时指定，最可能是此需求的提交人，在需求的整个生命周期中，此人要从头到尾跟进，是这个需求的主人。
开发工程师。在需求状态变为“开发中”时指定，负责这个需求的技术实现，以及将来可能的故障解决。其他比如测试负责人，项目经理，大家可以按需要决定是否填写。
项目名称。辅助信息，在需求进入“开发中”时确定，用来筛选某个项目的需求。
发布时间。辅助信息，在需求状态变为“已发布”时填写，用来查看某段时间发布的需求。
备注。其他任何信息都可以写在这里，如：需求被拒绝的理由，需求被暂缓的理由和重启条件，其他相关文档，等等。
至此，我们终于得到一个需求完整的DNA，如下图所示，整个表中星号（*）标识的项目，是作者建议的必填项。
完整的需求DNA
根据需求的状态变化，我们可以将上图变为动态的“需求的生老病死”。
需求的生老病死
需求管理的附加价值
需求管理除了可以清晰需求所处的状态、负责人等信息外，还可以带来很多额外价值。
通过简单统计需求列表，可以形成一份需求简报。统计时可以从以下角度统计：
（1）统计每个“提交人”的需求数量：可以看出产品团队里每个人提交了多少需求，如果再加上时间段的条件，就可以从一个侧面反映出某段时间每个人的工作情况，老板们一定喜欢看这样的内容。
（2）统计“提交时间”、“发布时间”等信息：比如按月统计，可以从需求数量的侧面看出产品发展是在增速还是在减速。如果需求提交的数量明显减少，就需要考虑对策了。
（3）统计每个“模块”的需求数量：因为需求都是直接或间接的从用户那里采集的，所以从各个模块的需求数量分布可以看出，用户对产品的哪些模块感兴趣，可以指导产品发展的方向。
（4）统计每个“分类”的需求数量：从各种分类的变化，看出最近是在做新功能，还是更多地做老功能优化，从而了解产品是在成长期还是成熟期。
（5）统计需求的“商业价值”、“性价比”变化：可以看出这个产品的发展空间还有多大，如果连续几个月，需求的“商业价值”、“性价比”都不高，就要考虑改变方向以求突破了。
以上统计可以用Excel来管理，此外还有更专业的需求管理方法和工具，如Mantis系统、Mercury Interactive公司的Quality Center、IBM的Rational RequisitePro等，可以根据自己的产品与团队的情况选用。
第二章总结
最后，一张图总结第二章，也是作者第一年的奋斗史，围绕需求展开，主要经历需求采集（读后感4）、需求分析（读后感6）、需求筛选（读后感7）和需求管理（本篇）的过程。
“一个需求的奋斗史”
撒花~与需求的纠缠告一段落，每天开始第三章：项目的坎坷一生，哈哈~~
网友评论