本项目案例根据真实故事进行改编。
剧情介绍
这是一个典型的紧急需求。X团队在周一开早会时，被告知有一个需求，本周三晚务必要完成开发并上线。对于突如其来的紧急需求，X团队是如何应对，又面临了怎样的挑战和总结？
“这个紧急需求，周三必须上线”
这是和往常一样的周一，但不一样的是新的挑战。
在周一最早的公司晨会上，CEO对大家说，接下来，为了更快推进公司业务的市场拓展，我们需要接入第三方平台，减少现场人员的手工操作成本，提高人效，释放人力。“因此”，顿了一下，CEO继续说，“为了配合实体店的扩张，这个紧急需求，周三必须上线”。
在这之前的30分钟，在高管早会上，CTO根据当前团队的项目安排，以及当前紧急需求的情况，评估下来，约周五才能完成开发和上线。
这是一个典型的紧急需求，其特点有：
1、来得突然，并且基于实际业务的开展，有明显的上线时间限制
2、根据常规的做法，技术团队评估需要一周时间，但需求方期望用一半的时间就完成，项目时间被压缩
3、非常依赖于外部第三方、合作伙伴或供应商的支持与配合，包括但不限于合同签定、账号权限开通、API接口对接、业务整合
分工合作，说干就干！
所幸的是，X团队是一支作风优良、敢打胜仗、经验丰富的团队，根据“定好需求、输出原型，排期开发、发布上线”的十六字方针，在进行公司晨会结束后，CTO立即组织了产品经理和项目干系人对此需求进行了需求评审。
在完成需求评审后，根据本次需求所涉及的系统调整范围，以及团队情况，参与本次的紧急需求的项目干系人共7人，主要有：
产品经理：1人，负责本次的紧急需求梳理与输出。
Java开发工程师：2人，分别负责第三方系统和接口的对接；以及内部主流程和管理后台的后端开发。
前端开发工程师：2人，分别负责主流程小程序的开发；以及管理后台的前端开发。
安卓开发工程师：1人，负责APP客户端的调整与开发。
测试工程师：1人，负责整体需求的测试、回归和验收。
明确项目里程碑、参与人员和分工后，各自人员便根据自身情况，对需求的理解以及对原有系统、应用、代码的理解，对各自所负责的具体需求拆解了任务，并估计工作量（即工时，以小时为单位）和完成时间（即排期）。
评估后的任务、工时、完成时间和负责人，如下（部分，敏感信息已隐藏）：
项目排期如下：
同时，为了方便及时沟通，创建了对应的企业微信工作群，取名为：紧急需求-XXXXX-3.10上线，注明了需求紧急程度、需求名称和计划上线时间。
按时上线，使命必达
在接下来的几天，团队成员各司其职，有的负责第三方平台的账号申请开通和充值，有的负责API接口文档的对接，有的负责内部管理后台数据录入与配置的开发。
值得注意的细节是，在前期，团队识别到了对第三方高度依赖的风险，因此针对需要调用到第三方的3个接口，在前期开发时，采用了根据接口文档中的接口规约进行数据的模拟，极大避免了对第三方API的依赖和对进度的阻碍。
最终，经过研发团队、市场部和产品部的积极配合，此紧急需求在周三晚如期按时上线。
在公司大群里，受到了老板的肯定：
在项目群里，也收到了大大的红包。
后续调整和周末问题排查
在周三晚上约21点，完成了这次的紧急需求的发布上线，但是否意味着本次需求就到此圆满结束？
不是的，通常而言，紧急需求上线后，很大概率会发生新的问题。原因在于：
1、由于时间紧张，很多细分场景和边缘系统，未能充分考虑周到
2、新的系统接入，在完成两个生态体系对接后，任何一个细微的字段都会导致现场线下业务的运转，甚至引起客诉
3、在未正式上线前，在未经过实际业务检验前，都可能会存在之前未曾预料或无法识别的偏差
所以，当周四上班后，在进行了内部测试和现场试运行后，针对新发现的问题，技术人员继续进行了优化、修复和调整。
到了周五，又发现了部分订单存在状态不一致问题。
到了周末，又发现了另一个问题，为此技术人员需要赶回公司才能进行现场的调试和排查。
经过多次的迭代和优化，本次的紧急需求，终于完美融入了现有的系统、业务和代码。
对本次紧急需求的回顾与总结
站在故事的尾声，当我们回顾本次紧急需求的项目燃尽图时，可以发现本次的燃尽图也体现了典型的紧急需求和生命周期和其独特的特征。
项目燃尽图，有3条线，分别是：
参考线：计划排期下的理论进度
实际线：实际执行后的真实进度
对角斜线：基准线
本次需求的项目总工时为：85H，约10.5人天，其中在周四任务工时增加是因为后续发现新问题进行需求调整带来的新工作量。
对于这10.5人天的工作量，是不是就可以理解成：如果1个人开发要10.5天，如果2个人开发要5天，如果10个人开发则要1天就能完成？
按《人月神话》里的解释以及真实情况，并这是这样理解和假设的。实际上，参与本次项目的有5名技术人员，时间跨度了4个工作日。
回顾以下本次紧急需求的项目燃尽图，我们发现：
1、计划排期的参考线（黄线），在对角斜线之下，表示计划排期比最快速度还要快速，否则不可能在指定日期完成开发和上线
2、实际的进度（蓝线），在参考线之上，表示实际进度通常都会落后于计划进度，要么因为任务未完成，要么时间紧张未及时更新任务完成状态
3、在项目上线后，项目工时增加，是因为上线后发现了新的问题需要继续优化
紧急需求的应对和损害
对于其他团队，根据对紧急需求的经验总结，当自己遇到紧急需求时，我们应该如何更好地应对呢？
紧急需求应对策略1：需求早提早上线
需求早提早上线，这是非常重要的经验总结。项目和需求流转下来，最终压缩的都是最后执行团队的时间，也就是技术团队的开发时间，尤其会压缩的是测试时间。
如果一个需求，前期沟通和梳理花了1个月的时间，到产品原型输出时又用了1周时间，当明确要做的时候，可能留给技术团队的时间只有3天时间，而给测试人员的时间很可能就只有3小时了。
如果尽早确定需求，确定需求要不要，优先级如何，具体需求怎样，那么就能为技术团队争取更多的时间窗口。
说到这里，我们会发现一个很有趣的现象，就是决定软件项目的开发时间，不是专业的工程师本人，而是需求方。需求方往往会说，“3天不行，今天就要上线”，产品或许会经常说，“这个需求很简单的，改几行代码不就可以了吗？”。
如果一个病人去医院就诊，他肯定不会说，“这个点滴我要5分钟内打完，我等不了45分钟那么久，因为我还要赶去上班。”因为他会听从专业医生的建议。那为什么在软件开发行业里，不是由技术团队自己决定项目的时间呢？很可能，在别人看来，我们不是专业的人士，甚至在我们自己看来，我们自己也只是码农、程序员，而不是专业的工程师。在外部因素里，需求方所定的时间，也是基于激烈市场竞争环境而作出的要求。因为，创业实在需要分秒必争，尤其是互联网企业。要快，更快，非常快，做到最快。
紧急需求应对策略2：提前识别延期风险
对于紧急需求，最大的阻碍就是无法上线，其次是延期上线。
阻碍上线的因素，最大的风险不是来自内部，而是来自外部，第三方平台如果不签定合同、不开通账号、不提供API接口文档和权限，都会导致最终项目的上线。因此，这些非技术的因素，作为项目负责人，要第一时间识别、跟进和沟通。
导致项目延期上线，很大的程度决定于两边对接的进度。在明确需求后，找对方负责人获取相应的开发文档、提供测试环境和测试账号、并要求安排相应的技术对接负责人，能极大保障和加快对接的顺畅度。
紧急需求应对策略3：做好抗冲击的准备
紧急需求，并不是上线就结束了，而是一个新的开始。要做好对业务的监控、进行内部试运行、还要对即将发生的各种问题做好排查的准备。
任何一个不恰当的地方，任何一行不对的代码，都会被内部的员工或者被外部成千上万的用户找到，群众的眼睛是雪亮的。
另一方面，紧急需求并不是百利而无一害的。紧急需求，也有它自身的损害。一方面，紧急需求是排期性的，也就是说，如果一个人优先做了紧急需求，那么他就不能同时继续完成原来既定的需求安排。这样，会导到其他原来的需求延期，从而影响了原来其他项目的正常计划。假若是被影响的需求和项目是其他产品业务线或产品经理负责的，那么这将会展开另一波的沟通工作。
另一方面，紧急需求会导致技术债务的产生，增加了系统的不稳定性和日后的维护成本。由于时间紧张，技术人员第一想到的是完成需求，而对于系统架构、扩展性、代码质量、数据库设计、自动化测试这些非功能性需求，很可能会暂且放下。曾经在饭堂和技术总监吃饭聊天时，他说道，现在房地产的房子，越快时间建好的越不敢住，因为一栋楼本来要6年时间才能盖好的，现在2年时间就建好，真不知他们为了赶工期而忽略了哪些重要的地方。我觉得，项目开发，也是如此。时间一压缩，注定会留坑。
YesDev小技巧
在项目管理模块，创建项目后，可以通过工作组圈定项目干系人，进行需求关联，拆解分配任务。随后，YesDev会自动生成项目排期表和项目燃尽图。
如果项目负责人需要进行项目的定期汇总，可以一键复制项目概况，粘贴到聊天群或邮件里。如果需要编写更正式全面的项目汇总邮件，可以点击【生成项目汇总邮件】，在系统自动生成的总结上进行补充和概括。
本文分享自微信公众号 - 小白开放平台（yesapi）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
