今天阅读了2.4节：活下来的永远是少数，主要讲的是需求筛选或者说PK的过程，是不同产品经理去PK争夺资源的“战

---

惯例，先是一张总结的图，我发现作者真的很擅长总结，在每节开头经常都会有一张提纲式的图，很清晰。

需求筛选

写在前面：为什么有需求筛选？

需求筛选与公司的组织结构有关，主要是对公司有限资源的争夺。如果公司是按照产品线划分部门的，那么某个产品就会有自己的产品设计师、开发与测试等，下一段时间要做哪些需求，完全可以在产品经理的层面上决定，所以就算有战争也是部门内部的，比较温和，基本上在分析商业价值的需求讨论会上，也就顺带着确定了下一段时间做哪些。而如果公司是按照职能线划分团队，那么产品中心、研发中心、质控中心都是单独的团队，这样的话，每个产品还是由原来的产品人员做，但是开发与测试资源在一定程度上就有了流动的可能。每个产品想做的需求都很多，所以都想尽可能多地抢到开发与测试的资源，然而人力资源总是严重不足的，所以最终把资源投给哪个产品，就必须上升到几个中心的大老板层面来决定了，而大老板的决策依据就是各个产品团队制作的商业需求文档。

两种组织结构都有优劣。按产品线划分的团队对产品本身是有利的，产品经理权力更大，可以按照自己的想法做，资源有保证，产品规划不容易被动改变。此外，各种职能的员工之间沟通顺畅，单线领导，开发的头、测试的头等都向产品经理负责。按职能线划分的团队对多个产品间的资源共享有利，可以让资源流向更需要的地方，保证对核心产品的投入，但是效率不高，产品规划的决策需要在更高层面上敲定，单个产品的发展速度会有所降低。但与此同时，资源战争可以把【鲶鱼效应】从产品内部扩大到公司层面（鲶鱼效应即采取一种手段或措施，刺激一些企业活跃起来投入到市场中积极参与竞争，从而激活市场中的同行业企业，其实质是一种负向激励，是激活员工队伍之奥秘），使产品经理和设计师们更抓狂地为产品的发展而苦苦思索，这是一件好事。

作者认为两种组织结构是“一攻一守”的，产品在创业期的时候，需要全速发展，必然是产品线结构，产品经理带头往前冲。而当公司里有多个产品慢慢成熟之后，就多用职能线来更充分地利用资源，因为在成熟的产品团队中，要做的事情通常比创业时期少，或者说没那么急，那么各种资源就显得有富裕，可以更加的稳扎稳打，所以按职能线划分以实现资源共享，同时还可以促进不同产品团队之间的互相学习，让员工的个人能力得到更多的提升。

第一步：需求打包

首先要把需求整合到一个将来的潜在项目里。做项目的终极目标就是多快好省，即范围大、时间短、品质高、资源省，通常要在上述4 个要求中做平衡。作者参与的是互联网、软件项目，比较推崇敏捷方法，所以有比较固定的项目时间，专业点叫“迭代周期”，一般是2～4 周。也有一个人员相对固定的团队，意味着项目资源确定，此外任何时候都要保证项目品质，最后能变的只能是量——项目范围，也就是包的大小。

继续，有了项目时间长短和开发工程师数量就可以直接算出有多少“可用工作量”，以“人天”为单位。然后对照按照“性价比”从大到小排序过的产品需求列表，从上往下看，每一行后面都对应着一个“工作量”，现在只要一行又一行地从上到下依次纳入项目，就能一目了然看出做多少，这个过程就叫“需求打包”，而对这些需求的整体描述，也就是商业需求文档里的功能说明了。

几个需要注意的地方：

第一，“需求打包”最好打包类似的功能点。是否类似取决于需求的基本属性，一般来说业务上逻辑关系密切的需求会包含在一个项目里。需求在打包以后，可以通过业务逻辑图的方式可视化。

第二，需求依赖，功能互相之间有依赖关系。那些只能先做的功能，应该在产品需求列表里注明；功能与人力资源之间的依赖关系也会经常存在，比如有些功能只能由团队里的特定成员来做。

第三，需求的粒度大小问题。商业价值很高的功能，如果细分的话，我们会发现其中也有价值相对低的部分，所以需求的粒度应该尽量细，前提是细化引起的管理成本上升在可接受的范围内。作者给出的经验是，在需求列表里出现的任意一行，工作量最好不要超过“5人天”。我认为这是由于周末双休，“5人天”的工作量正好方便每周一个工作总结，不然休息两天之后周一再继续总会多花费一些时间成本来回顾上周。

第二步：商业需求文档

商业需求文档就是对我们上面打包的需求包的描述。英文Business Requirement Document，简称BRD，是给大老板看的，是参加资源争夺战的武器。下面介绍BRD的内容：

项目背景：我们在哪里？为什么要做这个项目，解决什么问题，可以列出一些数据说明项目的必要性。

商业价值：我们去哪里？最关键的重点！大老板们最感兴趣的是做了这个项目以后有什么价值，一定要说在点子上。一般还会预测一下相关数字的变化，提出这个项目的商业目标。

功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打好包的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系，若能给出一些简单的Demo更好，让老板们提前看到产品完成后的样子，很可能成为争取资源的加分因素，也可以搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西，这有点类似谈判技巧里的玩意，但不要在上面太花心思。

非功能需求描述：提一下重要的非功能需求，如果有的话。

资源评估：第二个重点！大老板们要在了解达成项目的目标需要多大的花费以后，才能做出决策。这里要根据团队的实际情况，比如重点评估主要功能对产品设计师、用户体验师、开发工程师的人力需求等。

风险和对策：有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并且给出自己的对策。说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定。而且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突，这时候提出来也是让老板们把一下关。

其实本质上大老板们也是在追求性价比。

第三步：产品会议

最后一步就是参加产品会议。作者提出了一些技巧：

首先，当某个产品团队开始登场亮相的时候，一般要先回顾上一次产品会议通过的项目，现在进展如何，是否需要调整时间进度、是否需要追加资源、是否有重大需求变更，已经发布的项目有什么问题，等等。这样一方面是为了让大老板们更新对各个项目的信息，更重要的是为了积累经验，让今后产品会议上的决策越来越合理。

回顾之后，就是最关键的部分了，我们会拿出准备好的商业需求文档，每个产品都会拿出三五个，占满2～3倍的潜在资源。这里的潜在资源，是指相对固定的开发、测试人员，因为技术人员有对产品的熟悉问题，所以在短时间内，不可能太多的人同时转去做其他产品，这也就意味着潜在的人力资源数量在一个值附近做微小浮动。所以在一定程度上，资源的争夺是以产品间的争夺为辅，产品内多个项目的争夺为主。很有意思的是，这三五个商业需求文档通常是产品团队里不同的人做出来的，所以内部也会争夺得你死我活。

最后：谨记，少做就是多做

作者举了自己工作中的经历：一个功能的多次需求会议中，必然有这样一个过程：开始对一个功能想得不完整，说着说着大家都想把这个功能做得再强一点，这里加一点那里加一点，但后来通常因为技术实现、资源等原因，又把这些加上去的功能点一个又一个地砍掉，甚至会发现砍到最后和一个月前的第一次方案是一样的。看似白搭的这个过程其实是有用的，这是一个“见山是山，见山不是山，见山还是山”的三段过程，第一阶段还是无知的，是不断了解的过程，第二阶段在了解基础上提出“大而全”的功能点，第三个阶段是权衡了利弊之后的决定，最后的“少做”是超越了第二阶段“多做”的“少做”，这才是真正的“多做”。

用100%的质量去实现75%的数量，而不是反过来用75%的质量去实现100%的数量！吸引用户的往往只是功能模块中的一两个点，我们一开始只要让其拥有100%的质量其实就够了，这样留给用户的是升级的期待，而如果反过来，功能铺得很开，但每个点都不爽，那反而喧宾夺主，把闪光的地方给掩埋了。

第2.2.5节说要“尽可能多地采集”，但这里作者又提到要“尽可能多地放弃”，看似矛盾，其实正反映了我们对事物的认识过程，只有在收集阶段没有遗漏，才可能完整地看到事物的全貌，有了大局观，在放弃的时候才知道孰重孰轻，也更下得了手。