我一直认为，我们所做的事情并不是团队割裂的独立性的工作，而是属于有目标、有阶段的团队协作性工作，也就是我们常谈及的软件工程。在软件工程里，有一个非常著名的金三角理论：项目质量是由范围、成本与时间这三个要素进行平衡与约束的。 

一般来说，项目质量是开发团队的基础保证，该要素大部份情况是“不妥协的”。因此当项目开发过程中遇到意外事件时，需要灵活调整范围、成本、时间以此确保质量。

简单举个例子，假如哪天管理层希望卡某个时间点或者节假日上新版本的功能需求压缩时间，那么项目负责人则需要与产品经理协商减少非核心需求的范围，再或者从别的部门借调人员来加快开发效率。

假设，在时间压缩的前提下，不减少需求范围，又不增派人手，那么项目质量必然会受此影响进而致使交付质量降低。

应对之法：一减两加

理解完金三角理论后，我们可以思考下，假如项目出现了意外，应该如果应对。我过往的经验中有三种应对方案，一减法两加法：“砍需求”“加人”“加班”，这三个方案正分别对应着范围、成本、时间这三个要素。

应对方案的优先度，要是排个序，我认为是 砍需求>加人>加班。下面我具体说说原因。

当项目出现意外的时候，团队更多考虑的是 是否可在约定的时间里保质交付项目，因此砍需求本质上来说，是一个低成本，低风险并且可控的应对方案，既可以减少过多的成本投入，又不会打击团队士气。把非核心的需求向后排期挪一挪，以逐步演进的方式完善优化产品，例如像用户体验类的优化需求。

理想上，谁都会希望把事情一次性做完美，但现实上，在有限的资源前提下我们是无法一口吃成个大胖子的。有的放矢也是一种选择方式。

有些特殊的场景下，既不能砍需求，还有可能会额外增加需求。一般情况下，进入开发的阶段是需要冻结需求变更的，如果真的有不可退让的理由而需要增加需求，则需要重新评估工时并调整排期。假如既得加需求，又不允许调整时间，那么我们还有个方法就是增派人手。

调派的人数不宜过多，因为人数增加必然会增加沟通成本。《人月神话》这本书有说，如果项目或组织的人员越复杂，那么他的沟通成本将会越高。即沟通成本会随着项目或者组织的人增加成指数增加。洶通成本计算公式 n(n-1)/2，5个人的团队，沟通渠道是10；15个团队，沟通渠道是105。也因为沟通成本的存在，效率也不会以平均数的方式提升，也就是说3人15个工作日调整成了6人后，并不会说以完美的7.5人工作日进行交付 。

大多数公司都是一个萝卜一个坑的，特别是中小型公司想调派人手还是有点困难的。假如上面两个方案都都没办法应对，那么就只能使用下下策-加班。

加班方案的优缺点

加班这种做法，我是非常建议使用到冲刺性的团队任务上，短期的冲刺性任务可以使得团队凝聚力增加，因为大家共患难了嘛。但是战线拉长了，加班是非常打击团队士气的，还会额外增加不少成本。特别是那种长期加班或者政治性加班的，会让团队产生惰性、负能量，这种的结果就会与初衷背道而驰。

有些同行看到这里可能会认为加班，其实是一种应对项目意外的最直接最简单的方式，你看，管理者根本不需要额外去协调需求范围和人手，只需要一句指令“加班”，就可以应对所有意外情况。

对于这种只会用加班的管理者，我只想说一句，这群伪管理者，别用他人的额外付出以此掩盖管理的无能，也不要用战术上的假勤奋掩饰战略上的真懒惰。如果只会用加班解决问题，那团队还真的需要你管么？

当然了，加班这种社会乱象，在咱们国家各行各业都非常普遍，我总结了主要这三点原因：

1、有待完善的劳动法监管制度；

2、人多了就会“卷”出“廉价”的劳动力；

3、缺乏担当的“伪管理者”。

对于这三点原因，我简单解释下：

首先，我国确实存在着一些劳动法监管的不足之处，导致某些企业雇主能够以各种方式绕过加班限制，迫使员工超负荷工作。其次，我国人口多以至于劳动力市场竞争激烈，某些雇主为了降低成本，更倾向于雇佣廉价的劳动力。这些劳动力通常面临较低的工资待遇和劳动条件，因此他们更容易被要求加。以上两点都属于国情，并非由我们的绵薄之力就可以解决的。

对于伪管理者这个说法，我希望大家别轻易的对号入座。当然了，在我职业生涯里，确实遇到了，也听到了不少的管理者缺乏担当精神和责任感，不能有效地组织、分配和管理工作，导致工作流程不畅，员工任务无法合理分配，而他们的本质可能就是个上级的“传话筒”，这些管理者只关注自身利益，缺乏对员工权益的关注和保护，加重了员工的工作压力和加班负担。 

以上就是我这次分享的内容，大家可以把自己的想法反馈到下方评论，我们一起探讨。