产品设计体会（1014）需求，如何确定“做多少”
【小广告】今天在我的强烈要求下，出院了，进入在家休息阶段，本周六去医院拆线，发一篇庆祝~~~
敏捷（Agile ） 的一个特点，先确定项目时间 ，专业点叫“迭代周期”，然后有一个人员相对固定的团队，意味着项目资源 ，要保证项目品质 ，根据项目的“多快好省”原则，最后能变得只能是量——项目范围 ，前段写过一篇 如何做好“老板项目” 里也有相关描述。
那么，某个项目里，做多少需求到底怎么定？ 这个过程不妨用下图来表示，这张图也是PD 的需求过程图中的一小部分，即 “PD @ alisoft 做什么”这张图 里最左边一个箭头里的“需求分析”那个小框，以后有机会再把全图展开来说。
同学们可以先回顾一下之前说过的 excel 功能列表 和 需求管理表格 ，产品团队的一项日常工作就是采集产品干系人，即“广义用户”，提过来的各种需求，并 整理转化为产品需求 ， 即图中的“需求转化 ”，通常转化之前我们用mindmap 较自由的表达，转化之后就成了excel 里的功能列表。采集到这个需求的PD ，自己可以先“确定属性 ”，即这个需求是属于产品的哪个模块？是基本、扩展、增值功能？是功能、性能、用户体验方面的？等等，属性的维度大家可以按照产品的不同自由定义，原则是为了便于需求的管理。
这样我们得到的feature list ，就有必要每隔一段时间、或是新需求积累到一定数量、或是由特别事件触发，拿出来大家一起过一遍，这是最关键的，即图中用红色突出的“确定商业价值（产品内PK ） ”。我们的经验，商业价值由单个PD 确定风险很大，所以这个步骤是PD 团队集体讨论，再叫上有必要的干系人，比如销售、服务。对于商业价值可以从多个维度描述，并加权平均得到综合的商业价值，详细描述可参见 单向需求卡片 ，但绝大多数情况下，我们发现只用一个值的高中低，或者5 、4 、3 、2 、1 分来衡量就足够了。具体讨论的时候，大家充分表达意见，最终往往是会场上级别最高的人综合以后说一个数字，这是现实，也是一种高效的办法，我想过投票、群体打分的方式，可是实施起来成本太高。
注 意一点，讨论商业价值的会议上，会把所有状态为“待讨论”的功能点都过一遍，散会的时候，它们的状态一定要变化，或是进入“需求中”、或是被“拒绝”、或 是“暂缓”。拒绝的需求是被认为对产品的商业目的没有价值的，而暂缓的需求是“有价值，但是现在不做”的，通常要表明重启的条件，比如“3 个月后再拿出来讨论”、“某相关产品实现某功能后再拿出来讨论”等等。
对于状态变为“需求中”的功能点，下一步就是初定工作量 了，因为需求不明确，所以只是简单的评估，和真实情况的匹配程度很取决于经验, 要 靠不断的实践来反复修正。我们通常经历的项目，三大类人力资源是“产品、开发、测试”，用团队里的瓶颈资源做评估基准，所以我们一般评估每个功能点的开发 工程师工作量，因为在我们的团队里通常产品、测试资源相对可以调配，这个大家视自己团队的情况灵活应用。具体的评估，通常是类似技术经理的角色来做，评估 者按照自己做需要多少时间，乘以一个系数确定，这个系数一般大于1 。
继续，既然对于每个迭代周期，我们有多少时间、多少人是早就知道的，那么可用工作量 是多少“人日”，也就知道了。有了每个功能点的商业价值和工作量，很自然的就能算出性价比 ，简单的说即“商业价值/ 开发工作量”，我们把feature list 按照性价比从大到小排序，再对应考察每行评估出来的开发工作量，从上到下依次纳入项目，我们的可用工作量 能做多少个功能点，一目了然。
上面谈到的这些，也就是一步步确定某个
最后，我们把这些要做的功能点合在一起，把“需求打包 ”，再往下就要做这个 项目的BRD 了。BRD 通过，立项之后，再全程跟踪某个需求的进度，上述整个过程就是一步步确定某个需求的各种属性的过程，而对某个需求的描述，可以用下面的表格来表示（不妨起个名字叫做“一个需求的DNA ”），表中红色星号表示的项目，是我心目中的必填项。
这个过程完全是定量的，也就回答了“做多少”的问题。但，真实情况哪会这么简单明了，下面再说几个需要注意的地方。
第一，需求打包最好打类似的功能点 ，是否类似取决于需求的属性，“确定属性”这步做的事情起作用了，一般来说业务上有逻辑关系的需求才会包含一个项目里，否则就是一个纯粹修修补补的“小需求项目”了。
第二，需求依赖，功能点互相之间有依赖关系 ，那没办法，只能先做某些功能，应该在feature list 里注明；功能点与人力资源之间的依赖关系也会经常存在，在这里评估工作量的时候不会考虑“谁来做”的问题，但是在后续立项，组建团队的时候需要注意，当然长期来说，为了避免这类风险，提升与平衡团队成员的能力是王道。
第三，功能点的粒度大小问题 ，商业价值很高的功能，如果细分的话，我们也会发现其中有价值相对低的部分，所以功能点的粒度应该尽量细，前提是细化引起的管理成本上升在可接受的范围内。具体细到多少，也只能具体情况具体分析，我想工作量的最小单位总不能超过“5 人日”吧。