从五人到五十人：浅谈围绕业务和资源的成熟度，设计团队和项目管理模型
By 房如华@搜狐
摘要：本文站在资源、组织形态、管理方法为业务目标服务的角度，结合笔者在不同规模互联网团队的实践经验，向读者阐述在业务发展的不同阶段，组织资源的目标、侧重点的差异，并提供一点经验之谈。
如何度量研发和项目管理模型是否良好的支持了业务发展？
互联网的产品植根于高度充分竞争的土壤中，对外界环境的变化是非常敏感的，我们不能保证时刻都做正确的事，因为正确是相对的。在传统软件行业里，通常软件会被交付给明确的客户群体，那么软件的品质只与是否满足了客户需求，以及与同类产品的相对优势有关。而一款互联网产品，在出生之日起，就面临着用户的不确定性，用户需求迁移的不确定及复杂性，竞品可能来自多个领域等因素，我们唯一能够确定的就是变化本身。
研发和项目的管理模型，实际上就是团队的能力成熟度模型。我们既不能在缺人的时候才开始招人、培养人，也不能在业务尚未成熟时招到无法施展拳脚的专家，同时还要确认团队中的大多数同学的潜力能够跟随业务一起成长，否则团队在早期的波动会严重影响甚至毁灭整个业务的进程。因此，业务的成熟度与团队的能力成熟度是呈双螺旋不断迭代的，两者不能产生较大的偏差。
评估两者是否匹配的标准，我认为主要有以下两点：
敏捷性：能够控制从“决定做某种修改”到“该修改结果正式上线”的这段时间，也叫做周期时间（cycle time）
灵活性：只有当能够控制每一次从引入变更到发布的整个过程时，你才能开始优化和改进软件交付的速度和质量。
下面，为了简化表述，我们把业务和团队的成熟度分为四个阶段，每个阶段有其自身的特点和面临的挑战，接受并克服了这些挑战，团队将变得更为强大。
0-5人：挖下成功的第一锹泥土
当你想办法向你的老板或者投资人讲完一个美妙的故事之后，你就拥有资源了，这时你需要的是招募（确切的说是说服）一个能够把事情做起来的初始团队，也许一开始只有5个人，但不要紧，明确好从0到1的目标，马上开始工作吧。
这一步通常是用最小的抛弃成本来验证目标、团队的可行性。你要想办法在团队没有产生自我怀疑之前，把事情尽快做成。此时，应遵循INVEST原则，即独立的（Independent）、可协商的（Negotiable）、有价值的（Valuable）、可估计的（Estimable）、小的（Small）并且可测试的（Testable）。
对于这5个人，角色分工很简单，你是项目经理，其他成员都是研发人员，一切资源面向把事情做成。沟通方式是次要的，大家坐在一起，早期不会有太大的沟通障碍。此时人员的单点不是最大的风险，没人测试也不是最大的风险，因为很多项目没等第一个Demo做出来就已经失败了。
但不关心沟通不代表工具是次要的。好的工具可以极大的提高工作的效率，例如代码控制、Wiki这些基本的工具还是要使用的，而且等团队成型之后，容易成为团队文化基因的一部分。
这个阶段对团队的技能和经验也提出了一些必要的挑战：
需要有解决问题能力很强的人，在项目因各种原因停滞的时候需要有人站出来解决；
需要有较强项目过程管理能力的人，在优先级、项目品质等方面受资源影响需要调整计划时，要能基于不全面的信息做出合理的决定。
要从一开始就让团队养成持续交付的习惯。持续交付就是要形成需求、开发、测试、部署的流水线。对于早期团队来说，就要想办法让部署的工作流水线化。首先，版本控制是必要的，它能够保证随时checkout一个版本用于上线，并且随时回滚；其次，配置管理也是必要的，方便我们基于部署环境编写不同的配置文件；最后，部署的变更管理也是重要的，而且需要尽可能的自动化，为什么要自动化？因为早期你的产品很显然会出现大量的缺陷，你唯一能做到的就是把缺陷在代码里修复之后，以秒级的速度发布到线上。目前国内有很多初始成本低廉的公有云产品可以使用，通过写一些简单的脚本，可以把程序和配置快速发布到一个高可用的环境中。
5-20人：踌躇满志，更快的奔跑
初始的业务模式得到验证，团队活下来了，可以沿着预计的大方向前进了，这时候，终于可以把之前的Demo细化了，因为Demo只是跑通了流程，但此时产品可能连可用性还谈不上呢。
你招来了一名产品经理，他开始兴致勃勃的编制未来半年，甚至一年的路线图。假设能够完成这些需求，并保证品质，那么前途是一片光明，并有望领先大部分竞争对手。
这时，作为项目负责人的你，欣慰的发现产品经理在大多数方面和你的业务见解是一致的，因为都提出了大量不得不做的需求，我们确实辜负了用户太多的期待，但你突然意识到一个更关键的问题，完成这些的资源远远不够！
要开始做取舍了，你知道在这个冗长的列表里，永远存在“更有价值“的需求。
好的，列一个Excel，我们开始排个序。
判断优先级的标准是什么？很简单，做两个极端的假设，一个是：哪个需求不做会死人？另一个是：哪个需求带来的预期收益更大？
可能有的需求需要加三个月的班才能完成呢，浪费了时间，贻误战机怎么办？其实不用担心，先把可用性做好，再找你的目标用户群体不晚，在此之前，患得患失是无意义的。
与其患得患失，不如多花点开发量，做点更“精益”的事吧。比如通过小范围的用户测试、灰度发布等方法，快速验证产品的可用性，使用尽可能多的用户行为分析软件来评估你的用户按照你的预期使用了功能并且留存下来。这样万一你先前的决定是错误的，你也可以用较小的抛弃成本来调整方向，少留些遗憾给未来。
努力奔跑的日子总是充满期待的，但你也经常会从资深的员工嘴里听到些许纠结：“我是不是该重构了？”先重构后开发总是没坏处的，这正是素养优秀的表现。然而此时你仍需要帮助他们进行取舍，合理的留下一些技术负债。
如何判断要留下哪些负债呢？
负债产生利息吗？也就是未来团队和业务复杂度不断增加的情况下，是否会让技术问题的影响范围扩大，或是优化成本不断升高直至失控？如果负债会产生短期的利息，那么把精力花在减少利息和让业务加速奔跑相比，哪个更合算？
当前的负债，能够通过后期招募一名专业、资深的成员，用更少的时间、更好的经验或者更成熟的组件来一次性解决它吗？
如果某个业务模块的需求变化本身是频繁的，那么此处产生的负债也是不确定的，刻舟求剑的优化之后，发现需求已经变化了，也是一种浪费。
在这个阶段，因为引入了制定需求和跟踪缺陷的角色—产品经理，所以需要使用工具来对需求和确信进行追踪，一个类似Bugzilla的开源缺陷跟踪软件就能满足你大部分的需求了。
20-35人：总体产出随人数增加减缓，团队能力出现瓶颈
你的团队成型了，80%的成员都是工程师，他们努力的实现着一个一个小的目标，照此速度运转下去，似乎你脑海中的那个路线图就要实现了！
“继续招人吧！多一倍的资源投入就能换来多一倍的回报，因为他们负责的业务模块是不同的，不会产生沟通上的麻烦。”
观点听起来很有道理，但实际是错误的，你的团队毕竟不是流水线上的组装工人，更何况，随着事情越来越复杂，沟通的交集是不可避免的。这就好比一片森林，地表以上的树干都是笔直挺拔，互不影响，但地表以下的树根已不可避免的盘根错节在一起，更可怕的是，没人能完整的掌握这种交集的状态，更不要提如何改进了。于是，一辆战车抛锚了，而看起来任何人都没做错什么。
瓶颈到来了。
我们知道在早期的网络通信技术里有一个名词叫做“广播风暴”，指的是在集线器组成的共享网络下，所有用户的实际可用带宽，随用户数的增加而递减，并且在争抢信道的时候产生用户的等待。
这是不是很像目前你的未被治理的早期团队遇到的情况？为了确保每个人都得到足够的信息，全员会议在增加，人数越多，会议议程越复杂导致沟通成本的进一步增加，这还不包括团队成员随时被打断、叫到某个会议中的情况。
集线器最终被交换机和路由器彻底的取代了。随着团队增长，也需要主动革新现有的成员之间的沟通协作方式。
沟通的本质是解决信息传递问题，让信息的生产者能够尽快抵达必要的受众。但自发的信息传递并不保证效率，也不保证可达，所以需要一个协调员来优化沟通的效率，当然协调员就不能总是组织全体会议了。
必要的信息，还是要广播出去，提到Dashboard的概念，Dashboard是团队成员需要得到的信息的最小子集，通过这些信息，团队成员能够基于自身角色和目标的考量，迅速开展后续行动。如何让Dashboard的变更成本最小化？就必须协作了，一开始这种协作是痛苦的，因为并没有流程来保证不同角色间信息传递是一致的，所以只好让团队中的每个角色的关键成员都来更新Dashboard，刚开始会出现大量的信息不完善、不一致甚至自相矛盾的情况，但不要怕，频繁的去做，坚持两三周，情况一定会好转，管理就是不断重复，把主观上想做好变为真正有能力做好的过程。
局部的信息传递给团队中局部的群体，该如何来操作呢？如果你的团队中有几个人具备项目经验和较强的责任心，还是可以通过定期的会议和不定期的沟通来解决的，但你一定觉得在这个阶段投入专职的项目管理或流程优化的人员还是过于奢侈了，那么不要紧，充分利用好工作流这个IT界的伟大发明吧。工作流能够让你的团队根据一系列预先设定好的过程规则，将文档、信息、任务在不同的执行者之间进行传递与执行，避免人工的方式造成的低效、等待和错误。可以考虑购买Atlassian的Jira软件，这可能是你的第一笔软件投资了，或许觉得有些昂贵，但这一定比你招募一个专职的员工便宜多了。
加强团队不同角色对信息中“一致”的部分的约定，例如版本，版本用于识别一篇文档、一份代码的各个时间点的历史快照，不同角色的成员基于对版本的一致命名，可以有效的识别需求、实现、部署工作之间的对应关系。
35-50人：重装上阵，提高整体交付品质和团队成熟度
你拖着沉重的身躯，靠一己之力把团队带到了一个执行力和结果都还不错的状态，终于可以停下来歇一歇了。
这是大多数业务负责人梦寐以求的状态，但要想从同行中杀出血路，保持进一步的竞争优势，这还不够完美。
你望着窗外鳞次栉比的建筑物，发现大多数二三十层的楼房并没有什么不同，但鹤立鸡群的几幢摩天大楼，让你意识到，一定有一些工作是只有某些人才能完成的，而当你的进取心激发你要建造摩天大楼的时候，你也需要他们。这就是专家的价值。
如果你想停止修修补补的民工游击队的日子，就在这个时候引入专家团队，来让团队变得更加高大上吧。
专家能扮演怎样的角色，取决于你需要他们发挥怎样的作用，每位专家都有自己擅长的工作模式，你需要了解他们的工作偏好，以帮助你改善团队的能力基因。
架构师：具备一定的理论高度，并在相当规模的环境下，成功的完成过研发或管理能力的升级。他倾向于了解到具体情况后去务实的推进解决问题，并怀着积极和包容的沟通心态获取团队的支持。这种工作模式的优势是目标明确，执行有力；劣势是可能过程中需要调用较多的资源，会与业务线的资源调配产生优先级上的冲突。
咨询师：他不是最主动或者最敏感解决问题的人，也许平常他只是收到各个项目组抄送给他的邮件，但遇到紧急情况时，能够快速亲自解决，或者叫上其他同学一起会诊，对于可能会重复出现的问题，或者重复产生的工作量，会设法通过优化流程来降低内部消耗。这种工作模式的优势是面向问题持续迭代团队，确保短期的成果总是可被衡量的；劣势是受团队现有成员的视野的限制较大，总是踩过坑后才能促使团队意识到问题并统一思想。
此外，还要使用IT管理的思想来提高团队的流程成熟度和专业度，从而提高整体交付品质。
互联网的商业化只经历了短短的不到二十年的时间，但在此之前，IT的信息化就已经在国外很多企业中普及开来了，企业中的大部分员工是使用IT设备作为生产力工具和协作沟通的渠道，那么如何支持好IT基础设施就变成了很重要的工作，并由此催生了IT服务管理的概念，在20世纪80年代末期，还由英国政府部门发起制订了一个信息技术基础架构库即ITIL，到目前已修订至第3版，从流程的规范制订，发展为面向全生命周期的服务管理。
虽然前面反复提到：互联网与IT企业对于需求的管理存在相当大的差异，但这只会促使我们思考如何吸取面向交付品质的ITIL的理念，并在此基础上让一切环节运转在一条流水线上，并想方设法让流水线变得更快。
让流水线变的更快，可以从两个角度进行优化，一个是提高效率，一个是减少损耗。工具的高度自动化，把尽可能多的事情交给机器去做是提高效率的最显而易见的方法。那么减少损耗呢？通常因为测试资源、环境复杂性等问题，导致原本在测试环境运转正常的软件，在服务器或者用户的手机上出现了问题，你几乎没有办法在生产运行环境下远程调试和修改程序，但这些问题又无法复现，所以捕获现场就变成了非常重要的事。日志和监控是经无数团队和项目证明的最重要的两种捕获现场、衡量线上交付品质的方式，所以在你的团队有允许的资源时，一定要有专人面向其进行持续的分析、优化和质量评价。
总结
在业务还比较小的时候，要面向成功率最大化进行团队资源配置，随着业务的逐步发展，资源配置的原则要逐步倾斜至执行效率、交付品质，直至从理论的高度设计相应的流程和角色来固化你的团队，使之变得优质、高效、稳定、可控。
充分利用工具，尽可能将一切工作自动化。
重复、频繁的做一件事，尤其是你发现这件事情既重要又困难的时候。
在你的团队没有强大到能够筑巢引凤的时候，不用花精力弥补技能的短板，因为成功率低，回报也有限，反而对团队的项目管理要亲力亲为，识别损耗并推动改进。