复杂、短周期、多人项目工程化思考

1 背景

在日常开发中,我们经常会碰到一类具有如下特征的需求。一,业务复杂,动辄开发70 ~ 80人日(客户端30 ~ 40,服务端30 ~ 40) 。二,周期短,PM要求下个版本或者下下个版本必须上线,通常一个迭代给客户端开发就12 ~ 13天左右。三,多人参与,基于前两个特征,客户端要在指定时间内完成指定需求,必须要多个人参与项目。如果客户端不具备复杂、短周期、多人项目工程化能力,让项目delay或者加班堆人日解决问题,就会成为业务发展的瓶颈,备受各方吐槽。

2 原因分析

这里我们仅讨论项目迭代中的开发阶段。先分析一下大需求delay或者加班堆人日的原因。我认为原因大致有两点。一、缺乏有效估时;二、缺乏有效监督与纠偏

2.1 缺乏有效估时

  1. 需求点把握不足,进行拆解估时时候,经验不足的同学偏乐观,凭借自己对相关业务需求的大致理解估时,很容易需求点把握不足,从而估时不足。
  2. 缺乏架构设计,在项目开始的时候,缺乏整体架构设计,整体认知不足,不能高屋建瓴。
  3. 缺乏核心流程分析,对需求的核心流程没有画出流程图,很容易出现后期编码流程跑不通。
  4. 估时没有考虑到人员交流成本,估计时间的时候要考虑到交流沟通的时间耗散。

2.2 缺乏有效监督与纠偏

  1. 没有里程碑或者里程碑过于简略,完全没有里程碑几乎必然导致项目的延期,一个合理的里程碑,简单来说就是什么时间做什么事达到什么效果。
  2. 进度滞后不能预警和纠偏,没有全方位跟踪项目进度,进行进度滞后预警,以及安排项目纠偏。

3 针对性措施

3.1 有效估时

3.1.1 需求点把握

  1. 逐行校对需求文档、交互稿、设计稿、API文档,确保不会遗漏需求点。
  2. 理解需求,对需求的理解跟其他业务合作方要一致,如跟PM和API一致等。
  3. 吃透需求,把需求点跟对应代码上下文进行映射。

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或者加班的原因,并总结了一些可行的针对性措施,希望能提高生产率,降低风险,尽量减少不必要的加班。