为什么是3~5人？
作为一个初期的项目团队，都要经历“草莽”期，资源缺乏是此时的背景，所以人是不会太多，其实对项目也不见得有好处，一来项目团队本身可靠性还没有得到证明，二来项目团队内部需要磨合，初期人数多了一般很难符合资源最优的配置要求。因此团队初期的人数少既有外部因素制约，也有内部环境考量。
但是少也要有少的方法，因为一个项目所需要的项目步骤不会随着资源匮乏而减少的，具体可以看下面这个图，具体说明了项目步骤。
所以这个时期需要的是项目关键技能全覆盖，简单的公式是：
根据公式，我们对应出团队开始的是三个角色：项目经理、开发工程师和测试工程师。
这三个岗位的分项技能分别是倾向
项目经理（沟通能力+逻辑能力+管理能力 ）
对接需求方的需求与需求边界并尽量避免需求的蔓延。项目执行过程中协调资源与把控项目进度，对整个项目负责
开发工程师（逻辑能力+专业开发技能）
具备全面的开发专业技能，能将设计语言转换为计算机语言开发出目标系统。
测试工程师（协调能力+原则性+耐心）
做好“守门员”的角色，有效对系统做测试与验收。测试工程师肩负的是项目的底线。
为什么一定要测试工程师？从技能角度考虑，测试工程师的确是可以被开发工程师或者项目经理替代，而现在单独列出来作为最重要的三人之一，是因为在实际项目执行过程中，如果让程序员测试相当于又当裁判又当运动员，是起不到“守门员”效果，而如果让项目经理测试，则不可避免的会为了项目相关方而妥协原则，所以测试工程师从权利制衡角度上考虑是不可缺少。
如何从3个人发展到5个人？
我的建议加上两个开发，至于是前端工程师还是后端工程师视情况而定，现在等于是有三个开发了，“一拖二”的结构，这样的选择主要考虑的是增加开发战斗力对项目推进是效果显著的。
在此变化过程中，需求传递准确的压力随人员的增加上升，而消化这部分压力的主力是项目经理。也就是项目经理从要将项目需求准确传递给两个人到现在需要传递四个人，达到五人脑海画面基本保持一致。这里需要强调的是画面基本一致是结果，绝对一致是可接近但不可及的远方。
团队5人之后人员扩张的方向是什么？当团队已经有3~5人，我们接下来的扩张是按简化模型进行完成，人员角色做整体的拆分，分为项目经理、产品经理、UI设计师、UE设计师、技术经理、前端开发、后端开发和测试工程师。
这是角色进一步拆分的过程。至此，大家能遇到的项目角色全部登场。为了方便大家理解角色间的职能与关系，我将以信息传递链路展示一个项目开发“流水线”上各个角色的分工情况。
需求方提出项目的模糊需求→项目经理将模糊需求转化为具体需求→产品经理将具体需求转化为初步视觉需求（原型）→UI/UE工程师将原型转化为精细目标设计→开发工程师将设计转化为alpha版本系统（内部测试版）→测试工程师将alpha版本系统检查后输出带有使用文档（说明书）的上线版本系统
现在我们有了相当规模的团队，那接下来是什么呢？答案是生产效率与控制之前的平衡之路。
已经有了相当规模的团队后，团队的改进主要目标会发生变化，从初期的团队必要性证明，即生存证明转变为追求稳定输出预期结果。之前是追求团队生产效率，现在是追求团队生产稳定。如果是乙方团队就是保证项目团队的稳定结项，甲方项目团队就是希望项目稳定迭代，总而言之，这个时候存量思维是会压过增量思维，项目全员的核心目标是守护当下已经有的团队成果。为了实现稳定和守护存量，最高效的方法就是做好权责向上传递，让更有能力对当前情况负责的人员对项目负责，这种权责的转移最有效的方式就是审批。
常见的审批有：项目开发需求审批、项目需求变更审批、开发计划审批、测试用例审批、测试报告审批等。
这里需要特别说明的是加强监管本质对于项目执行团队削权，原来团队内部拍板能定的事现在需要得到上级的审批，对于执行团队而言最直观的感受是开发顺畅性下降。另外削权行为将会成为审批流程落地的最大阻力来源。
为什么是削权？我想任何人在权利被约束的时候本能的都有不适，就如很多人不喜欢日报制度一样。而人们对于日报的理解，不同的思维模式会得出不一样的结论。其中一种结论是：日报是一种表达自己工作成果和展示自己的通道，是向上沟通的稳定通路。类比监管也一样，监管流程其实是项目团队的自检和工作的展示渠道，工作成果从原来的大阶段展示变成小阶段展示，为项目团队增加展示和“绩效存档”机会。
组织过程资产同时，在监管过程中还会产生一个对于组织来说很重要的副产品，是组织无法抗拒的副产品，那就是 组织过程资产，组织过程资产是项目过程中得到的教训、经验、技巧和方法以文档或者视频载体形式留存下无形资产。是组织私有的过程资产，是构成组织和核心竞争力的重要元素。所以监管流程的增加对组织而言也是一种必然，是一种良性的必然，不以个体意志为转移的必然。
随着监管流程的增加，组织的参与者就会上升（当然，开发人员也会增加），逐步的将项目参与团队从之前的完全务实成员转变为务实成员+务虚成员的配比。团队这时候就叫“肿了”，然后就“慢了”，同时也更“稳”了，就如人一样，过了少年的意气风发，走向中年的成熟稳重，在这个过程中，辅助“效率成本曲线”可以有更直观的理解。
在团队增长期，人员增加对团队总效率的提高是边际递减的，就是每增加一个人所带来的整体开发效率增长是随着人数增加而下降的。尤其是过了下图C1时间后，增加人员的本质已经是在对冲风险，而不是提高产出。因为团队的产出效率是有极限的，这里我们可以选择一个极端场景，我们是否能找一万人，一周造出一个京东，显然不现实。很多情况就是存在客观极限，不然就可以“人有多大胆，地有多大产”。
所以在团队后期，之前因为管理而设置的制度将会成为团队的“枷锁”，导致项目团队在迎接变化的时候反应迟钝，对于组织而言就是性价比过低（一般是技术的变革跟进迟缓），最终完成项目团队生命周期的最后步--解散。
以上就是一个项目项目团队简化生命周期模型，从团队开始到团队结束，我们从3个人聊起，到最终的多人团队。上不封顶是结论，也是我的答案，不知道你的答案是什么，欢迎留言讨论。
