第一次听见996的时候，恰巧我和Peter正在讨论加班的问题。他苦笑说：“什么996，不是9-12-6就不错了！”

Peter是一个资深产品经理，负责公司的核心产品。目前产品处于成长期，今年开始客户突增，导致整个部门的密集加班成为了常态。于是乎，出现了连锁反应——很多程序员不堪长期负荷，选择了离开。两个月的时间，离职率上升了50%。HR也是很努力的，但招聘的速度仍然跟不上。

Peter完全被失控的状况牵制了所有的精力。他今年原本的工作重点是产品升级。可今年已经过半，不但常规的交付各种拖延；更为严重的是，产品的升级几乎没有实质性的进展。

Peter一想到好不容易挣来的竞争优势，可能因升级不及时而被竞品替代，就坐立不安，简直是1个头3个大：

1. 要控制加班，防止离职，要新人培训，解决无人可用的困局；

2. 要面对产品交付过程中，客户的各种问题和变化；

3. 要进行产品升级。

Peter希望我能给他一剂猛药，“让有限的人，干完所有的活”。

可事情总会比人多。除了一些让我们望尘莫及的情况外（你懂的），绝不可能哪个以营利为目的的组织，备100人干50人的活。如果一件一件线性地干，就极有可能会进入Peter的恶性循环。因此，Peter的问题解决起来无疑是一个系统性工程，需要对“有限的人员”进行系统化的管理。

既然是人员的系统化管理，那就推给HR呗。

Peter也是跟HR“战斗”过的，结果各打五十大板。交付不能延、研发不能停，这些下在Peter身上的“死命令”，只能一边继续要求HR，一边自己默默地扛下来。

眼下，首先要解决的便是有人可用。不过，这只能治标，不能治本。如此困局产生的原因，在于产品快速发展而导致的工作激增。无论是Peter还是HR，都没能对这一点提前预案。那么多出来的工作，便只能强行挑战团队的承受底线了。

既然是工作负荷出了问题，那么招多少人才能达到平衡呢？这个问题，只能Peter站在团队生产力的角度，给出答案。在IT企业中，“3个人干5个人的活”非常常见。我们不能简单地站在工作量与生产力的角度，去评价这样的情况是否正确。但是工作量与生产力的关系，以及人员有限的常态化，确实是Peter避免类似情况二次发生的重要考量。借用CMMI-Service模型中，关于“容量与可用性管理”的最佳实践，把人看成资源，我们来给Peter支支招。

容量：人员的生产力及其范围

可用性：工作需要时，可以获得的人员数量与可用程度

很显然，Peter在人员的容量与可用性两个方面，均遇到了挑战。解决起来无法一朝一夕，因此建议他按照短中长期，运用不同的策略，分阶段逐一解决：

短期策略（3个月内）：工作和生产力盘点+应急措施（以招聘、借调、转岗的方式，应对产品交付）

中期策略（3-6个月）：生产力提升+产品升级调研

长期策略（6-12个月）：工作与人员规划（包含产品升级规划）

基于上述策略，我们分三个阶段给出人员容量和可用性的具体解决方案：

我和Peter进行了为期一周的盘点，识别出未来三个月的工作任务与工作量估算，现有人员可以容忍的生产力水平，以及这两方面可能存在的风险。基于盘点结果，我们得出了明确的人员缺口。据此，我们从招聘人数、到岗时间与能力要求三方面，提出了明确用人需求。在人力资源部门的帮助下，不仅积极开展招聘工作，还从内部进行了借调和转岗，以解燃眉之急。

中期的重点，在于提升新员工的生产力，逐渐减轻老员工的工作负荷。Peter和人力资源部门通力合作。一方面，对这一批新人采取了敏捷的培训模式——在新人完成了基本的入职培训后，便与老员工“一一结对”，快速了解和接手项目；另一方面，为了褒奖老员工在特殊时期的奉献，调整了激励机制，并在培训新人方面给予了政策性的倾斜。

另外，Peter还协调了营销部门，应对因交付延迟而导致的客户满意度问题，为业务部门争取了一个短暂但相对“安静”的空档，专心解决交付的问题。接着，在不断修复的客户关系中，营销人员可以逐渐识别出客户最为关注的重点，并把这些重点纳入到产品升级的规划之中。

有了营销部门输入的客户需要，Peter和团队确立了具体的产品升级方案，除了功能和进度外，他们还对工作量、人员容量与可用性做了细致的预估与规划。困境逐一攻克，远期最重要的便是吸取教训，杜绝悲剧重现。尽管人手还是不宽裕，但加班情况明显得到缓解。

团队稳定了、健康了，Peter就再也不头大了。他不用再担心时不时地起火，而是有更多的时间进行规划和改进。他跟我说，希望有那么一天他的团队可以基本杜绝加班。尽管这是个梦想，但我认为，这是个可以实现的梦想。