关于项目交付的一些思考

对于开发来说，在团队中的首要任务就是完成好业务需求。那如何做好交付，保证交付质量以及如何控制项目交付风险呢？

交付周期

这个可以根据团队的实际情况来定，之前在腾讯做 toB 产品时，是双周一个版本，因为产品当时仍处在早期阶段，需要比较快的节奏保证功能迭代和 bug 修复。如果是一些比较成熟的产品，这个周期可以拉长，因为成熟产品就不能只考虑堆功能，还需要考虑功能的合理性以及对线上数据的分析。

交付节奏

1.总共十个工作日，常规开发时间大约在 5-7 个工作日，测试时间大约 2-3 个工作日，1 个工作日发布并观察外网情况，有问题及时回滚

2.大需求会拆成多个版本，迭代上线，如果迭代的版本不能单独上线，我们会用前端开关来控制

交付质量保证

自动化测试流程，先挖个坑，后面另写一篇

项目风险控制

因代码质量导致的测试周期拉长的风险

1.对新同事/较初级的同事的代码质量需要更重点地关注，新同学可能因为对团队的环境和规范不熟悉，较初级的同事需要导师指导

之前有一个运营活动的需求，交给了组里的毕业生和一个 T9 的同事，预计一周的开发时间，工作量按能力分配大约 3：7，开发进度基本正常，按时转入测试阶段，测试同学预估 5 天测完，但是在测了四天之后， bug 量明显异常，已经达到 90+，并且有持续上涨的趋势，在分析了已有的 bug 单和阅读了项目代码之后，给出结论和方案：

a. 结论：代码组织和代码逻辑有明显的问题，组件拆分不清，框架理解和使用有误

b. 方案：向组长申请再加一名开发，和这个项目原有的T9开发逐步梳理和重构毕业生的代码，预计时间 3 天；其它模块可以正常测试不受影响

c. 结果：用时2.5天将有问题的代码重构，测试同学再加 3 天测试，整体延期 4.5 天上线；在这个过程中我虽然没有加入写代码，但是在我完成正常工作的情况下，一直紧跟重构进度和测试进度，持续观察测试 bug 的趋势

d.复盘：

1). 对于毕业生同学，需要对自己的代码进行复盘和审查，对比自己的设计和重构后的设计，有哪些区别和优劣，并在周会上分享

2). 对于面试过程，需要增加写代码的环节，特别是对实战经验的考察

3). 代码在需求转测之后需要在组内发起代码评审，对于不同职级的同学有不同的要求:

i.实习生：所有需求都需要评审 ii.校招生：入职半年内所有需求都需要评审 iii.社招同学：试用期内所有需求都需要评审 iv.之后的需求，改动量在300 行以上的重点需求，需要组长决定是否需要评审，改动量在 300 行以下，必须经过组长和另一位同学的评审之后才能合入主干

2.老项目的修改需求，对现有逻辑改动的风险

需求评审时需要负责人和对应的开发同学对现有逻辑十分了解，并在评工时的时候考虑到对现有逻辑改动会有哪些影响，尽早抛出因其它觉得对需求理解不到位导致的预期工时差异

需求最开始是组长去评审的，在需求评审会上，产品的预期是只做 UI 改动，同时增加一个 ABTest，由于负责这个需求的同事有更高优的需求，所以希望我们组可以帮忙处理这个需求，就把这个需求交给了我。

但是我们组长对这个需求的历史情况和当前实现完全不了解，在评审会上给产品预期是这个需求很简单，组长在评审会上给的预期是 1 周左右可以快速上线。

在我对齐需求之后，发现和预期完全不同，所以在开始开发前就和各岗位的同事同步了这个情况，让大家降低预期，最后我评估的开发时间是 7 天，上线时间大约 3 周。

最后产品体验和测试环节走完，需求周期是 4 周交付，基本符合我最开始的评估。

如何保证项目按时交付

1.向上级申请更多资源，像实习生运营活动这个例子，就是向 ld 申请了一个开发人力，其它也可能会出现跨团队申请资源的情况；

2.自己搞定或寻求同事帮助，如果是自己搞定，需要详细评估开发周期，对明显可能影响交付的问题有预判，如果是寻求同事帮助，可能需要向 ld 申请

3.管理客户预期，有节奏的提供小版本迭代：需要向产品侧反馈，可能是产品的预期和实际情况有偏差

a. 举例：ToB 平台内的模块迁移

b. 背景：该模块本来是单独的项目维护，是给团队内的运营使用，后来客户也有这个需求，为了降低用户切换平台的成本，决定将这个平台迁移到用户使用的平台中成为一个模块；产品的需求单里预期是一次性全部迁移，但是因为模块太多，一次性迁移风险太大，所以需要小版本迭代，并给到客户预期

c. 具体措施：

i. 将平台上的内容按模块划分，对每个模块及模块下的内容进行详细的迁移工时评估

ii. 将预期的里程碑进度同步给团队内各角色，其中需要产品将迭代预期以合理的形式反馈给客户，我们当时的情况是在企业微信群里管理了用户，因此在群公告中贴了迁移计划

iii. 我按计划逐步迁移模块，每完成一个模块，都在企业微信群中同步给客户，并且预留 1-2 天的时间来收集客户的反馈

iv. 最终耗时 5 周迁移完成，虽然时间上比一次性迁移预估的时间长 1 周多，但是这个方式最终没有收到任何核心功能使用受到影响的反馈，仅有零星几例样式相关的反馈

4.通过开关，控制功能的渐进式开发：某些较大的功能，如果全部开发完才投入测试流程，不仅会给测试同学造成较大压力（因为测试点太多），开发周期也会变长，产品侧的感受不佳

a. 举例：平台中需求管理模块改版

b. 成果：需求正常交付，且交付周期比预期要短

c. 背景：旧版中需求流程阶段较多，并且有很多流程是冗余的，产品侧希望在精简流程的基础上，对 UI 也做一次大的改版。从开发角度看这就是一次重写。因为需求管理模块涉及 3 个页面，几十个业务组件，改新版之后，有大约 40%的组件需要重写，有大约 50%的组件需要修改功能，所有的组件都需要改 UI

d.具体措施：

i. 将产品需求按照 UI 重构 - 前端交互 - 页面接口数据三个步骤进行重写

ii. 并给出对应的交付周期，在完全改版完成之前，新版页面通过开关控制，在外网我们可以控制只有指定 id 的角色才可以看到新版的效果

iii. 按计划控制功能渐进式开发，由于每个里程碑都有明确的目标，所以在每个里程碑下，产品、测试、开发的目标都很一致，第一个阶段所有角色都关注 UI 的问题，设计稿的还原度是否足够；第二个阶段都关注交互问题，各个组件之间的交互是否正常；第三个阶段都关注页面数据的问题，数据渲染是否正常，结合了交互之后，数据更新是否正常等。避免了在非渐进式开发的场景下，一个大需求里所有角色需要关心各种问题，导致精力不集中，无法高效地完成需求

iv. 原预估开发时间为 11 天，测试时间为 8 天，采用渐进式开发，开发时间为 10 天，测试时间为6 天，由于各个环节更聚焦了，整体的交付周期反而有所缩短

小结

以上是对项目交付的一些总结和思考，简而言之就是小步快跑、提前预警、降低预期，切勿随意承诺工时、隐瞒风险、拉长需求周期。