研发流程不只是一个流程

以人治天下，贤则大治，不贤则大乱。

以术知天下，术高多宵小。

以法治天下，法令莫不从，民生定。

一、总要有个流程

作为一个研发，你最讨厌什么？

"小功能，十分钟能搞定吧！"

"需求都清楚了吧，明天老板要看效果！"

"有个急事，插一下！"

"这个地方，还要调整下，稍后给你更新的文档！"

"这个当初肯定不是这样定的，是你们的问题"

"代码怎么被覆盖了？"

"测过的代码怎么没上线？"

"这个线上问题是谁谁的变动引起的。"

"这个为什么没测到？"

... ...

需求张口就提，说变就变；开发时间不明确，无法控制；测试不规范，不全面，质量无法保障等等，不一列举。

没有规范约束，没有流程限制，没有章程遵循。 可能对于某些场景会很高效，但问题也是层出不穷。

一个公司成长到了一定的规模，如果还是如上这种，那么唯一的结果只有：混乱。

二、需要一个怎样的流程

一个完整的研发过程包括哪些活动？

需求 => 开发 => 测试 => 上线。

1、需求怎么提？

a）需求阶段需要做什么？

确定要做什么 + 做成什么样 + 怎么做

比如：

要做什么：发表文章的功能页面要改版，以更好的适应用户的操作习惯。

做成什么样：新的功能布局 + 新的编辑器支持 + 表情符号支持 + 话题插入支持 + 图片编辑支持 + 自动实时保存支持。

怎么做：输出详细的 prd 需求文档 + 需求评审 + 资源调配 + 排期 + 进度控制。

相对来说，前两步多是产品自身范围内的工作活动，是需求的基础。最后一项则是和关联研发人员的协作，支持。以成品 prd 文档作为媒介，进一步展开后续的流程。

b）需求优先级界定

一个公司会有很多个产品，每个产品负责不同的业务范畴，那么便会衍生出不同方向的需求。

需求有大有小，重要性也不尽相同，所以需要有一个排序的流程。

将所有的需求都摆在桌面上，由上层来结合公司发展方向及公司战略来筛选哪些需要做，每一项的优先级。

2、需求评审

产品形成成熟的需求文档后，则要进行需求的宣讲，评审。也就是把上述的过程内容阐述给后续流程的研发人员（包括开发和测试等）。

所谓评审，既要评，又要审，也并不会是一锤定音，一遍过。 对需求内容的整体方向，产出，roi等综合进行考评，合适的的方保留，不合适的去掉，可以改进的继续改进。

对于比较大的，比较重要的或者比较复杂的需求，项目，可能需要经过多次评审，多次改进才能最终定稿。

这一流程节点产出是要作为整个研发流程的指导性文件，应该做到不厌繁琐，力求能够尽善尽美。否则越是往后流程的返工，成本越大。

3、排期

我们讲一个需求或者项目，即为在特定的资源条件下实现特定的目的。

既定的资源包括时间，人力及设备成本等。

需求周期一般是既定的，比如，老板说下个月什么功能上线，你就得上线，转圜余地不大。

所以涉及到人力需求则要在如上既定时间周期下去安排，调配人力资源。包括开发及测试等。

其它成本包括服务器，网络，外部付费技术资源（安全、校验）等，是不是需要采购新的服务器，是不是需要拓宽网络，是否是需要引入外部的校验API等。

这一阶段，主要是确定每个流程节点的时间需求，确保每个流程能够在合适的时间开始和结束。

4、技术方案评审

需求确定后，流程流转至开发人员，此时，开发人员应根据既定的 prd 需求文档，产出详细的技术方案文件。

闻道有先后，术业有专攻，每个人都有自己擅长的领域。单人主导的技术方案至少要经过交叉人员评审后方可定档实施。

比如，

数据怎么存储？表字段设计的合不合理？需不需要分表？

需不需要介入缓存层？需要哪种形式的缓存？

系统间怎么交互？交互方式？

接口设计是否合理？前后端交互流程？

哪些是核心业务逻辑？哪些业务可以拆分异步处理？

需不需要引入新的技术？

... ... 等等。

5、编码开发

编码开发其实占用的时间并不多。

就好像炒菜一样，菜品的清洗，准备往往是最耗时的，反而入锅翻炒也就一会儿的事。

6、Code Review

我一直秉信 Code Review 是能够极大保障代码质量的。

Code Review 关注点包括：代码设计、功能实现、复杂性、测试友好性、代码风格、命名、注释、文档等。

Code Review 的形式可以采取代码库流程，或者集体拉会形式等。

7、提供测试

开发流程结束后，流程流转至测试。

研发环境一般要提供完整的开发、测试、灰度、线上环境区分，以供不同阶段不同流程需要。

这一阶段，开发人员需要将开发结果部署到测试环境，提供给测试人员。

如有必要，也需要提供相关测试数据支持。

8、测试用例评审

测试用例输出及评审通常和开发并行，由技术方案流程确定后起始。

测试人员根据既定的需求及技术方案文档设计测试用例，包括新功能、变动功能及回归功能等。

测试用例完结后，需要和开发人员进行沟通评审，确保测试用例的完整性。

9、测试

测试环境及测试用例就绪后，开始流转测试流程。

测试包括功能测试、集成测试、回归测试、灰度测试、线上验证等。

由此节点开始可能需要横跨所有后续流程。

测试往往是产品质量的最后一道防线。

及早发现问题、提出问题应为首要，尤其不要试图掩盖问题。

上线前一秒发现问题都是居功至伟。

10、上线、验证

功能上线，不同公司可能操作方会略有不同，开发、测试、SRE人员都有可能操作这一流程。

上线后功能验证必不可少，由测试或者产品执行，确保产出和目标相符。