项目流程优化
引言及概览
需求阶段
- 梳理需求提交流程
- 制定需求质量规范
- 项目/需求风险管理
设计阶段
测试阶段
- 准入规范
- 提测流程
- Bug 规范
- 测试进度报告
- 测试结论报告
上线阶段
引言及概览
项目流程优化是一个持续过程，每个公司，每个团队情况不一样，总原则是：如果在项目过程中你感觉到某一点很别扭、很不爽、痛了，那么这就是优化点。
优化的手段是多样化的，如通过流程规范去约束、开发和利用工具去辅助等等，都是优化方式。
流程优化是一件需要团队合作才能做得更好的事情，所以任何优化都需要与团队各角色达成一致，才能够有效地去落地。同时，优化过的流程要持续坚持去落地，作为负责人要起到督导作用，才能让团队持续精进。
下图为本文项目流程优化的概览：
需求阶段
梳理需求提交流程
1）规范需求 list 评审
有些团队可能会今天提一个需求，明天提一个。对此，可以制定一个每周过需求 list 的时间，统一安排过本周的需求，并对需求进行优先级排序，开发和测试可根据本周的人力情况去安排本周的需求，避免需求乱提。
而且各个角色要有一个明确的对接人，统一收敛到接口人，不要面向全员提需求。
2）制定需求截止时间
制定需求截止时间，比如像 APP 是需要发版的，发版一般是有固定周期的，若临近发版进行需求变更，会对版本有很大影响，所以需要制定一个需求截止时间，比如版本开发前一周的周四。
3）紧急需求流程
若有特殊情况，比如 CTO 直拍的紧急需求，要走特殊流程，需要发送邮件抄送产品及各技术老大，老大回复后才确认修改或增加需求。
制定需求质量规范
出需求虽然是产品的工作范围，但一份需求的质量一定程度上会影响整个项目的质量。
比如，跨部门的项目，由于涉及到外部系统，如果前期产品调研不够充分，对于业务边界了解不够清晰，对交互系统的是否可实现性无法确定，会直接导致开发阶段的问题。
所以从整个项目的角度出发，测试也需要关注需求的质量。
1）需求是否达到评审状态
若需求前期调研不充分，产品对边界系统了解不清楚，疑问点较多，此需求存在很多不确定性，开发/测试负责人可先将需求打回（可根据情况选择委婉或强硬）。
2）需求的可行性
产品需要说明需求的预期收益，需要用历史数据说话，否则投入人力去做，却丝毫没有收益，从资源层面来说是一种浪费。
如果开发和测试评估，需求实现难度大，没有数据做支撑，此需求需要重新调研。
项目/需求风险管理
- 风险如何定级？
- 是否已经创建风险登记册并同步给相关方？
- 风险问题反馈给谁统一跟进和管理？
- 风险 review 机制如何？
- ...
设计阶段
设计阶段包括开发设计及 UI 设计。这个阶段比较常见的问题有：UI 设计与需求文档原型图不一致、开发设计没有文档等。
UI 设计图
UI 设计图与需求不一致，会导致开发和用例设计不能够明确以谁为准。尤其涉及到前端页面的需求，不一致是很大的一个痛点。
基于这种情况，可以制定 UI 准入规范，可包含以下内容：UI 图格式、存放地址、出 UI 图的时间（一般最晚在开发前一天提供）等，并且要求产品对 UI 图进行验收之后再提供给开发。
开发设计文档
开发设计文档可以跟开发提诉求并落实到文档，尤其是与外部系统交互的文档。
- 数据库改动的表结构设计文档是否清晰？
- 开发涉及到的接口文档是否清晰？
- ...
测试阶段
测试阶段可以做的事情很多，可以根据自己所在团队的情况而定。一般是对测试过程的监控，使测试更顺畅，更高效。也可以通过项目结束后的数据分析，比如 bug 占比及趋势、每周的线上 Bug、二次上线率等来对测试流程进行优化。
自测规范
自测标准
如自测用例要占总用例的 30%，开发需要执行完自测用例且通过率为 100% 后再进行提测。
有时，开发执行自测 case 可能与测试执行方式不一致，有时开发会用假数据 mock，但真正走流程可能会有问题。执行自测是为了后续的测试流程更顺畅和高效，所以可以要求开发执行自测的方式是要从前端触发，而不能后端直接 mock。
自测用例确认
用例评审会可确定自测 case 范围，与开发达成一致。
打回流程
若自测用例执行不通过，后续怎么打回。
提测流程
邮件提测 or 口头提测 or 平台提测，根据情况制定。
Bug 规范
包含但不仅限于：
- Bug 描述：标题要言简意骇，避免阅读成本；步骤写清楚+截图。
- Bug 流转：比如已解决状态只能开发去更新；已关闭由测试执行等。
- Bug 解决方案：尤其关注不是 bug 的情况，测试要提高 bug 的质量，与开发约定不是 bug 的范围。
- Bug 分类：严重级别、类型根源、优先级等可根据自己所在团队的情况制定规范。
测试进度报告
有些同学在测试过程中是默默执行的，比如排期三天的测试需求，到了测试阶段，两天过去了，群里没动静，相关 leader 可能会对此需求的进度不了解，所以可以制定测试进度报告定期同步给相关方。
测试进度报告一般包含以下信息：
- 整体测试进度（%）
- 已测内容及未测内容
- Bug 及阻塞性问题的风险评估、解决方案、解决时间、跟进人
- ...
测试结论报告
见《如何编写测试报告》。
上线阶段
- 线上问题跟进流程：进行轮值，对线上问题要快速响应，且给予结论。
- 灰度&线上问题收集及复盘。
