1. 前言

以前在不足百人的小公司待过，产品需求的研发并没有什么正规的流程，通常是产品提了需求之后，技术部门简单评审一下就开始写代码，本地和测试环境没问题就直接发布线上了。

后来去了某二线互联网公司，大概几千人。虽然跟一线大厂还差很多，但需求的研发流程跟大厂大同小异。

前段时间运营小姐姐找我了解一些开发相关的内容，就跟她讲到了我们的开发流程。这里简单做个小结。

2. 整体概述

一个相对完整的需求研发流程大致如下图所示：

PS: 该流程仅供参考，不同公司可能会有所不同，但主流程大体相似。

下面简要介绍各个环节的主要内容。

3. 流程分析

0. 产品提出需求

产品通常是对接「运营」和「研发」的，是运营和研发之间的桥梁。

运营过程中产生的需求一般会反馈给产品，产品把需求的主要功能整理成需求文档（Product Requirements Document, PRD），并画出产品原型图（常用工具：Axure）。

PRD 通常主要包含：

1. 需求背景。就是为什么要做这个需求？想要达成怎样的目的？
2. 需求细节。各部分如何实现，包括业务逻辑以及如何交互等。

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. 说明

上述流程只是根据个人平时开发经历总结的，仅供参考。

若需求比较简单，可能会把一些步骤省略掉。

PS: 运营小姐姐说此前还觉得我们做需求应该很快，不明白为啥开发一个需求要这么久，待我跟她讲完开发流程，她保证以后再也不催我们了。