2.4.1 永远忘不掉的那场战争 为什么原来没有这样的战争？ 我没找到理论支撑，但就个人经历和与同事的交流来说，下面是一个因素：更早的时候，公司是按照产品线划分部门的，对于某个产品来说，有自己的产品设计师、开发与测试等，下一段时间要做哪些需求，完全可以在产品经理的层面上决定，所以就算有战争也是部门内部的，比较温和，基本上在分析商业价值的需求讨论会上，也就顺带着确定了下一段时间做哪些。 为什么现在有战争了？ 2008年初，公司组织结构调整，变成了按职能线划分团队，有了统一的产品中心，包括所有的产品经理和设计师；研发中心，包括所有的开发工程师、架构师等；质控中心，包括所有的测试工程师……这样的话，每个产品还是由原来的产品人员做，但是开发与测试资源在一定程度上就有了流动的可能。每个产品想做的需求都很多，所以都想尽可能多地抢到开发与测试的资源，然而人力资源总是严重不足的，所以最终把资源投给哪个产品，就必须上升到几个中心的大老板层面来决定了，而大老板的决策依据就是各个产品团队制作的商业需求文档。 其实，后来我们又经历过几次反复，部门总是一会按产品线划分、一会按职能线划分，这让我忍不住也对这个问题给出点自己的解释。 按产品线划分的团队对产品本身是有利的，产品经理权力更大，可以按照自己的想法做，资源有保证，产品规划不容易被动改变。此外，各种职能的员工之间沟通顺畅，单线领导，开发的头、测试的头等都向产品经理负责。 按职能线划分的团队对多个产品间的资源共享有利，可以让资源流向更需要的地方，保证对核心产品的投入，但是效率不高，由于产品规划的决策需要在更高层面上敲定，单个产品的发展速度会有所降低。此外，资源战争可以把“鲶鱼效应28”从产品内部扩大到公司层面，使产品经理和设计师们更抓狂地为产品的发展而苦苦思索，这是一件好事。 两种组织结构，给我“一攻一守”的感觉，产品在创业期的时候，需要全速发展，必然是产品线结构，产品经理带头往前冲。而当公司里有多个产品慢慢成熟之后，就多用职能线来更充分地利用资源，因为在成熟的产品团队中，要做的事情通常比创业时期少，或者说没那么急，那么各种资源就显得有富裕，可以更加的稳扎稳打，所以按职能线划分以实现资源共享，同时还可以促进不同产品团队之间的互相学习，让员工的个人能力得到更多的提升。 更多有关组织结构的话题，将在第4.1.3节“团队之大”与大家讨论，到时候再见。 准备出发：把需求打个包 上战场之前，就像战士要把自己的物品打包一样，需求也要打包。我们现在来解决这个包有多大的问题，即某个将来的潜在项目里，到底应该包括多少需求的问题。这里不得不提前谈一点项目管理的内容了。 做项目，终极目标就是：多快好省29，即范围大、时间短、品质高、资源省。 但又要马儿跑又想马儿不吃草的事情是没有的，所以我们通常是在上述4个要求中做平衡。我经历的互联网、软件项目，比较推崇敏捷方法30，所以有比较固定的项目时间，专业点叫“迭代周期”，一般是2~4周。然后有一个人员相对固定的团队，意味着项目资源确定，此外任何时候都要保证项目品质，最后能变的只能是量――项目范围。 继续，我们有了项目时间长短，也就意味着可以按经验的比例估计出留给开发的时间有几天，然后团队里有多少开发工程师也是知道的，所以我们可以直接算出有多少“可用工作量”，同样以“人天”为单位。还记得我们把产品需求列表按照“性价比”从大到小排序过了么？从上往下看，每一行后面都还对应着一个“工作量”，现在我们只要做一个简单的加法，一行又一行地从上到下依次纳入项目，能做多少，一目了然，我们把这个动作叫“需求打包”，而对这些需求的整体描述，也就是商业需求文档里的功能说明了。 当然，这只是一个基准，可变因素很多。我们每次产品会议都要准备好几个项目让大老板们选，每个项目也有可能在产品会议上被砍掉部分需求，所以可以先相对随意地超出“可用工作量”。 这个过程完全定量地回答了“做多少”的问题。但，真实情况哪会这么简单明了，就像课本里总是给出一个简单到不真实的例子，然后再告诉你还有很多特例，而到了实际操作中，你会发现又要复杂很多，没办法，大家都尽力吧，让每个项目的大小相对靠谱，下面说几个需要注意的地方。 第一，“需求打包”最好打包类似的功能点。是否类似取决于需求的基本属性，这是“确定需求的基本属性”那一节里做的事情。一般来说业务上逻辑关系密切的需求才会包含在一个项目里，这也很好理解，否则就是一个纯粹修修补补的“小需求项目”了。实际操作中打包多大，更多的是取决于这一点。更好的方式是，需求在打包以后，通过业务逻辑图的方式可视化，可以更直观地给别人讲解。 第二，需求依赖，功能互相之间有依赖关系。那些只能先做的功能，应该在产品需求列表里注明；功能与人力资源之间的依赖关系也会经常存在，比如有些功能只能由团队里的特定成员来做。在这里评估工作量的时候不会考虑“谁来做”的问题，在正式立项以后，组建团队的时候会重点考虑，当然长期来说，为了避免这类风险，提升与平衡团队成员的能力是王道。 第三，需求的粒度大小问题。商业价值很高的功能，如果细分的话，我们会发现其中也有价值相对低的部分，所以需求的粒度应该尽量细，前提是细化引起的管理成本上升在可接受的范围内，给个生活中的例子帮助理解：大开间办公区域里的灯，不可能用一个开关控制，也不可能每一个开关只控制一盏灯。具体细到多少，要根据具体情况具体分析。我们的经验是，在需求列表里出现的任意一行，工作量最好不要超过“5人天”。 战场：产品会议 需求打包完成了，战争就要打响了。 某天，各个部门的老板们都聚集到一个大会议室，准备待上一整天。各个产品的产品经理和设计师们等着被轮流召唤，当然如果你有空且愿意，也可以旁听一整天。其实对资源的争夺，在部门内讨论商业价值的时候已经预演过了，通常来说每个人都会尽力为自己提出的需求说好话，毕竟实现自己想法的感觉总是好过帮别人实现想法。 一般来说产品会议一个月一次，当然这和产品性质有关，如果你们公司的产品周期比较长，那也可以两三个月一次。 当某个产品团队开始登场亮相的时候，一般要先回顾上一次产品会议通过的项目，现在进展如何，是否需要调整时间进度、是否需要追加资源、是否有重大需求变更，已经发布的项目有什么问题，等等。这样一方面是为了让大老板们更新对各个项目的信息，更重要的是为了积累经验，让今后产品会议上的决策越来越合理。 回顾之后，就是最关键的部分了，我们会拿出准备好的商业需求文档，每个产品都会拿出三五个，占满2~3倍的潜在资源。这里说的潜在资源，是指相对固定的开发、测试人员，因为技术人员有对产品的熟悉问题，所以在短时间内，不可能太多的人同时转去做其他产品，这也就意味着潜在的人力资源数量是在一个值附近做微小浮动的，所以我们也可以认为，在一定程度上，资源的争夺是以产品间的争夺为辅，产品内多个项目的争夺为主。很有意思的是，这三五个商业需求文档通常是产品团队里不同的人做出来的，所以内部也会争夺得你死我活。 接下来的重头戏是一直提到的商业需求文档。 武器：商业需求文档 我们刚刚把需求打好包，接下来就要描述一下这个包了，这就是商业需求文档，Business Requirement Document，简称BRD，它也是我们参加资源争夺战的武器。 先看一下几个长得很像的词：BRD、MRD31、PRD32。按顺序来讲，这几个词是从商业的描述渐渐过渡到对技术的描述。我经历的团队在实际操作中通常只写两种文档，一个是给大老板们看的BRD，包含了BRD，以及MRD的部分内容；另一个是在项目中写的PRD。 下面来聊聊我们的武器――BRD怎么写，都包含哪些内容。 项目背景：我们在哪里？为什么要做这个项目，解决什么问题，可以列出一些数据说明项目的必要性。 商业价值：我们去哪里？最关键的重点！大老板们最感兴趣的，做了这个项目以后有什么价值，一定要说在点子上。一般我们还会预测一下相关数字的变化，提出这个项目的商业目标。 功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打好包的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西，这有点类似谈判技巧里的玩意，大家可以试试，但不要在这上面太花心思了。 非功能需求描述：提一下重要的非功能需求，如果有的话。 资源评估：第二个重点！大老板们要看成本，他们在了解达成项目的目标需要多大的花费以后，才能做出决策。 风险和对策：有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并且给出自己的对策，说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定。而且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突，这时候提出来也是让老板们把一下关。 从BRD中的“商业价值”、“资源评估”两个重点中大家可能也发现了，其实本质上大老板们也是在追求那个词――性价比。大家都希望花费最少的资源获得最大的商业价值。 下面通过一个BRD的实例，再给大家讲一点直观的认识。 首页，我们会给BRD，也意味着将来的项目，起一个有意义的名字，再配上一幅图，这样有助于团队的归属感，比如某个BRD叫“魔方计划”，是因为这个项目打算将两个老产品整合为一个新产品，有点像魔方一样，通过打散、组合，得到一个全新的结果。 商业价值，给老板们看他们最关心的指标，比如魔方计划就聚焦在“活跃用户数”上。 功能需求描述，这里给出了业务逻辑图，若能给出一些简单的Demo更好，让老板们提前看到产品完成后的样子，很可能成为争取资源的加分因素。 资源评估，我们会根据团队的实际情况，重点评估主要功能对产品设计师、用户体验师、开发工程师的人力需求。 BRD转化为项目也并非一一对应，很可能老板会把多个BRD合并为一个项目，或者把一个BRD拆成多个项目，或者直接砍碎了再重新组合，这都无所谓，不管怎么说，产品会议开完以后，我们终于确定了接下来一段时间要做哪些需求了，准备启动项目，迎接新的开始。 等等，我们还需要先安抚一下“被砍得遍体鳞伤”的兄弟们。