1 背景
在日常开发中，我们经常会碰到一类具有如下特征的需求。一，业务复杂，动辄开发70 ~ 80人日（客户端30 ~ 40，服务端30 ~ 40） 。二，周期短，PM要求下个版本或者下下个版本必须上线，通常一个迭代给客户端开发就12 ~ 13天左右。三，多人参与，基于前两个特征，客户端要在指定时间内完成指定需求，必须要多个人参与项目。如果客户端不具备复杂、短周期、多人项目工程化能力，让项目delay或者加班堆人日解决问题，就会成为业务发展的瓶颈，备受各方吐槽。
2 原因分析
这里我们仅讨论项目迭代中的开发阶段。先分析一下大需求delay或者加班堆人日的原因。我认为原因大致有两点。一、缺乏有效估时；二、缺乏有效监督与纠偏。
2.1 缺乏有效估时
- 需求点把握不足，进行拆解估时时候，经验不足的同学偏乐观，凭借自己对相关业务需求的大致理解估时，很容易需求点把握不足，从而估时不足。
- 缺乏架构设计，在项目开始的时候，缺乏整体架构设计，整体认知不足，不能高屋建瓴。
- 缺乏核心流程分析，对需求的核心流程没有画出流程图，很容易出现后期编码流程跑不通。
- 估时没有考虑到人员交流成本，估计时间的时候要考虑到交流沟通的时间耗散。
2.2 缺乏有效监督与纠偏
- 没有里程碑或者里程碑过于简略，完全没有里程碑几乎必然导致项目的延期，一个合理的里程碑，简单来说就是什么时间做什么事达到什么效果。
- 进度滞后不能预警和纠偏，没有全方位跟踪项目进度，进行进度滞后预警，以及安排项目纠偏。
3 针对性措施
3.1 有效估时
3.1.1 需求点把握
- 逐行校对需求文档、交互稿、设计稿、API文档，确保不会遗漏需求点。
- 理解需求，对需求的理解跟其他业务合作方要一致，如跟PM和API一致等。
- 吃透需求，把需求点跟对应代码上下文进行映射。
3.1.2 架构设计
业务需求架构设计，大致分为两个部分，界面和业务。界面又包括偏交互和偏视觉。业务也能进行具体的模块拆分。架构的时候要进行合理的模块细分，充分暴露大方向上的问题。
3.1.3 核心流程图
核心流程至少要涉及API的调用时机和页面跳转以及页面刷新等。
3.1.4 合理人员划分减少沟通成本
偏界面和偏业务都要有一个整体负责人，尽量不要产生跨细分模块的交流。
3.2 监督与纠偏
3.2.1 合理的里程碑
合理的里程碑设置时间点考虑因素大致有两点。一、API可用性，即API提测时间，提测bug率等。二、QA用例可用性。里程碑不要缺乏必要信息，要可以度量，简单来说就是什么时间什么事怎么算做成了。一种有效的方式是基于Case来评判。
3.2.2 进度监控预警与纠偏
当发生不预期事件，导致估计时间与时间所用时间产生偏差时，要及时预警与纠偏。常见的不预期事件有两类，第一是编码过程中踩坑，第二是跟PM需求点理解不一致。出现这些事件首先要跟其他业务方沟通，看看能不能规避。如果不能规避，看看是否在对应里程碑能Cover住，不能Cover住要及时调整里程碑。
4 总结
本文从实际出发分析了复杂、短周期、多人项目在项目迭代中的开发阶段产生delay或者加班的原因，并总结了一些可行的针对性措施，希望能提高生产率，降低风险，尽量减少不必要的加班。