网易一千零一夜——如何赶工期？

项目经理通常遇到这样的困境： 项目交付时间被老板拍板定的死死的，但是基于现有的资源完成项目几乎是不可能的。遇到这样的情况，我们应该如何处理 ？

一般来说，大家的反应是加班 、加人等等，但是这些都是非常规做法。原因网易的作者做出来说明如下：

1. 加班。 一方面，弱矩阵项目结构的组织中，项目经理没有绝对的权利要求团队成员进行加班。另一方面，团队成员的工作是一个持续的过程，一个项目结束后就会马上有另一个项目的任务，长期加班影响团队的士气与效率，并且长期加班造成大家对绩效有较高预期，但是绩效并非根据加班来评定，那这个周期的考核就面临各种矛盾和考验。
2. 加入。有了项目需求再去招人是比较困难的，人员到岗的速度没有这么快。另外一方面，一个新成员的加入，会增加不少沟通成本，所以加人也不是处理时间紧张问题的常规方式。

其实我们可以来重温一下项目的不可能三角， 如下图：

现在是时间 确定不可以变了，那我们就是只能从 范围 以及成本 上考虑了。增加成本，较小范围。 具体做法如下：

1. 需求调整
   一般项目都有关键约束因素和浮动约束因素。关键因素是决定项目是否成功的因素。浮动因素是指可以调整的重要影响因素。我们回顾需求文档，根据需求的优先级，重新划定本里程碑的范围，将锦上添花的功能拿掉，剩下主体功能。产品在最初规划的时候，总希望在最近的迭代中将所有需求做完，往往有一些需求并那么迫切，对用户来讲可能也无关紧要，没必要非在本里程碑中完成。或者本里程碑中可以完成这些需求的简单实现，在下个里程碑进行完善。
2. 小迭代开发, 敏捷模式的优势无需多言了，无法推进敏捷，敏捷中的快速交付的思想我们可以学习借鉴。
3. Bug 管理 ， 时间不充裕，在确定交付标准的时间应适当降低 bug 修复的标准。修复代价大但是影响较小的 bug 可以暂时不修， bug 按优先级进行调整，低优先级的 bug 可在里程碑结束后修复。
4. 增加资源，增加的人员包括但不限于前端、后端、测试、运维等等。

“不可能完成的使命” 的应对方案

上面的例子中，项目三角固定了一个，项目经理其他两个还有腾挪的空间。但是也有不少时候，老板不仅给你限定了时间，还给你限定了范围，但是资源呢短期内很难增加，这种情况要怎么搞 ？
这种情况在项目管理中称之为 “不可能完成的使命”（mission impossible）,但是是老板下达的死命令，没法子，只能拼了。怎么个拼法？

1. 固定周期交付，价值交付。固定交付的周期，用以解决产品规划功能，以及开发过程总的沟通、协调、跟进等问题。但是固定节奏并非一味的求快，快并不等于有效的产品交付，原因如下：
   • 产品需求不靠谱。一个需求很有可能到开发或测试时被发现不完整或有自相矛盾之处，在研发过程中再补充需求细节，这 tm 就是研发效率低效的罪魁祸首。产品需求必须经过项目的充分讨论以及核心干系人的评审。
   • 研发效率低。一味的求快，那开发过程中必定有很多妥协的地方，很多坑没时间去填，造成牵一发而动全身，前行缓慢。技术的坑也要记录需求池中，在某个迭代进行问题的处理。
   • 过程流动不靠谱。项目团队中必然存在能力上的瓶颈，当所有人都被工作塞满后，有可能就像高峰时的高架桥，每一寸土地都被利用，但是有效的流动确很慢。这个时候需要项目经理去做这个处理堵塞问题的交通警察。
2. 明确传递并同意对项目目标的理解和价值认同。项目启动会的时候，必须建立好基础的项目章程。
3. 加强变更管理。拥抱变化的目的是为了快速响应市场变化，甚至是引导用户习惯，但并不是为不成熟的需求方案买单。
4. 多层级站会。召集人建立良好的规律习惯。
5. 加强状态展示以及更新，及时发现风险，并制定解决方案和落地策略。
6. 明确定义质量标准。冒烟 100% 才可提测，关键 bug 全部修复，用例通过率 95% 以上方可通过测试。
7. 记录技术债，并排入版本计划
8. 情绪以及人际关系早预防、早发现、早协调。加班的库，稍作调整可以化为众乐乐的和谐气氛，下午茶、甜点都可以为加班增加亮色。