1. 前言
以前在不足百人的小公司待过，产品需求的研发并没有什么正规的流程，通常是产品提了需求之后，技术部门简单评审一下就开始写代码，本地和测试环境没问题就直接发布线上了。
后来去了某二线互联网公司，大概几千人。虽然跟一线大厂还差很多，但需求的研发流程跟大厂大同小异。
前段时间运营小姐姐找我了解一些开发相关的内容，就跟她讲到了我们的开发流程。这里简单做个小结。
2. 整体概述
一个相对完整的需求研发流程大致如下图所示：
PS: 该流程仅供参考，不同公司可能会有所不同，但主流程大体相似。
下面简要介绍各个环节的主要内容。
3. 流程分析
0. 产品提出需求
产品通常是对接「运营」和「研发」的，是运营和研发之间的桥梁。
运营过程中产生的需求一般会反馈给产品，产品把需求的主要功能整理成需求文档（Product Requirements Document, PRD），并画出产品原型图（常用工具：Axure）。
PRD 通常主要包含：
- 需求背景。就是为什么要做这个需求？想要达成怎样的目的？
- 需求细节。各部分如何实现，包括业务逻辑以及如何交互等。
1. PRD 评审
PRD 完成之后，产品经理（或者项目经理）就约一个会议室，邀请开发、测试、运营、交互设计师等人一起开会，详细说明本次需求，主要是讨论需求的可行性，比如技术能否实现、逻辑是否有问题等。
2. 交互评审
产品给出的原型图可能不够具体，细节部分就要由交互设计师来出设计稿了（常用工具：Sketch、Figma 等）。
比如某个按钮具体放到哪里、宽高多少、颜色值多少、点击后如何跳转，等等。然后设计师会根据设计稿切图并给到前端开发人员。
3. 技术评审
就是确定技术方案，这部分工作就要由我们开发人员来主导了。主要包括如下部分：
- 需求整体可以分为哪几个模块？
- 需要哪些业务方配合？是否需要对接二方、三方？各业务方之间是如何交互的？
- 表结构如何设计？接口如何定义？
- 有没有技术难点？
主要是开发同学向大家阐述详细的技术实现方案，评估一下是否有不合理之处。
对于架构图、流程图和时序图，常用画图工具有 ProcessOn、draw.io、OmniGraffle、StarUML 等。
4. 开发测试排期
经过技术评审，一个需求具体有多少工作量大致就可以确定了。此时就要给出一个比较详细的排期了，主要包括：
- 开发时间：单纯的开发「总人时」需要多久（时间通常以 0.5 天/人、或者 0.25 天/人为单位）
- 联调时间：前后端联调、后端跟其他第二方、第三方联调需要多久
- 提测时间：哪天可以交付测试同学进行测试（如果需求比较紧急，可以分批提测，也就是拆分成不同的功能模块提测）
- 测试时间：通常包括测试环境、预发布环境、生产环境回归测试，这几个时间都要算上
通常「开发排期 + 联调排期 + 测试排期」就是这个需求的实施时间，这几个时间确定之后需求的发布上线时间基本就定了。但也要考虑到期间可能产生的一些意外情况。
5. 输出技术文档
技术评审需要输出技术文档，把此次需求使用哪些技术、增加哪些配置、设计哪些表记录下来，涉及到流程图、架构图也要形成文档，以便过段时间之后再看，或者后面交接给其他人维护。
此外，后端开发通常还要先给出接口定义、入参出参等（该过程可以前后端讨论确定），以便前端同学 Mock 数据。
6. 测试用例评审
测试同学把本期需求的功能点全部列出来，向大家说明自己如何去测试、期望得到怎样的结果等。如果有的接口对 QPS、RT 等要求较高，一般会进行「压测」来确定是否满足要求。
有点类似测试的“技术评审”。
7. 前后端各自开发
这时候总算可以撸代码了！
前后端按照之前的接口定义各自开发。
8. 前后端联调
开发分别在本地自测以后，前后端一起走下整体流程。
PS: 有时候提测之前测试同学会给出一个冒烟测试用例（非必须），通常是主流程和一些核心部分逻辑，当这些地方都没问题时，才可以提测。
9. 提测
提测就是正式告诉测试同学这个需求已经初步开发完成，可以进行测试了。
一般以邮件的形式告知，包含相关测试同学、项目经理、开发、产品等人，以便各方了解项目进度。
PS: 如有特殊情况导致延期，需要提前发邮件告知各需求方延期的原因。
10. 测试环境测试
测试同学在测试环境按照之前的测试用例各种测、各种找 bug……改 bug……找 bug……改 bug……
bug 整体改完之后，会叫产品经理初步验收一下是否符合预期。
11. 预发布环境测试
测试环境的数据可能不够正式，主要是用来测试各个流程能够走通。而到了预发布环境，各种配置和数据库就跟生产环境基本一致了。
如果预发布环境没问题，就准备发布生产环境了。
12. 发布生产环境
发布生产环境之前，通常是需要做些准备工作的：比如创建数据表、新增配置等，通常要运维同学配合添加和修改（因为开发通常没这个权限）。
13. 线上回归测试
发布成功之后，测试同学需要进行回归测试，也就是在生产环境把需求再验证一次。
全部通过之后，就叫产品正式验收了，产品觉得 OK，才能说明这次需求 OK 的。产品点头之后，这个需求才算真正开发完成。之后可能还会有些其他收尾工作，但非必须。
14. 项目复盘总结
这部分并非必须。
一般在需求过程中问题比较多时，会复盘一下问题主要出在哪里，以后如何规避等。
15. 需求完成
至此，一个比较完整的需求研发流程就结束了。
4. 补充说明
1. Code Review
通常的 Code Review 在测试环境流程通过之后。
虽然经过测试功能上没问题了，但代码中可能潜藏一些问题难以测出来。此时可以叫几个开发小哥还有老大，一起找个地方把关键部分的代码 Review 一下，看是否有潜在的漏洞，或者代码在哪部分写得不够合理。
这部分做好的话其实对个人成长帮助挺大的，但有些公司可能会忽略这部分，尤其是排期紧张的时候。
2. 说明
上述流程只是根据个人平时开发经历总结的，仅供参考。
若需求比较简单，可能会把一些步骤省略掉。