科普一下正式的大厂需求开发流程

大多数人认为的程序员，也就是很多人眼中的技术开发人员（前端或者后端），他们就是整个项目开发过程中的主力人员，此外就没什么其余人了。

但其实，一个需求从提出到开发再到测试，直到最后上线，是需要几波人共同努力的，而不是像很多外行理解的只需要程序员这种个角色就可以搞定的。

今天阿秀就根据在前司字节以及现司SAP的工作经历科普一下互联网公司一般常见的需求开发流程有哪些？会有哪些人参与到？

新手朋友们可以稍微了解下大致流程有哪些，尤其是一些在校的学生粉丝们提前了解了解。

先科普一下常规的互联网公司的需求开发中的三种角色以及三种环境：

三种角色分别是产品经理、研发和测试，在下文中也会使用PM、RD、QA来做简称；

而三种环境依次是开发环境、测试环境和生产环境，有的还会在测试环境和生产环境中再加一个模拟生产环境做数据隔离和真实演练。

三种角色

1、产品经理(Product Manager/Project Manager)，缩写为PM：产品经理是在产品的研发过程中，负责调查并根据用户的需求制定出一套方案的相关人员。

2、研发(Research and Development engineer)，缩写为RD：研发一般分为前端开发工程师或者后端开发工程师，比如C++后端开发工程师、Java后端开发工程师、Golang后端开发工程师等都属于RD，他们是把功能具体实现出来的一拨人，也是网上各种程序员相关段子调侃的主要对象。

3、测试(Qualtiy Assurance)，缩写为QA：QA的主要职责就是质量保证工作，也就是很多人口中俗称的测试，负责对RD实现的功能进行检测，保证该功能在上线后能够正常使用。

三种环境

1、开发环境

开发环境主要指研发进行功能开发的环境，其实就如同大家在自己的笔记本或者台式机上写程序一样，这就是开发环境。

而大厂中用什么工具开发要看具体的组了，有些组选择用统一型号的笔记本进行开发；也有些组会选择使用开发机来进行开发。

这里一般是要求组员的开发环境都是一致的，比如大家都使用Window来进行开发，或者都用Mac进行开发或者开发机的型号也是一致的，为的就是减少可能因开发环境不一致而引发的BUG。

不要小看这个环境问题，很多莫名其妙出现的问题，最后排查下来都是由于环境不一致导致的。

2、测试环境

测试环境主要指的是测试人员进行功能验收和检测的环境，在正式上线前都会在这个环境中进行模拟功能的检测。

这个环境一般脏数据会比较多，有时候为了模拟真实的线上环境，甚至要从线上数据库copy数据到测试环境中去。

3、生产环境

生产环境就是广大真实用户使用的场景，也有的管它叫线上环境。这个环境是最重要的，因为一旦出事就是线上生产事故，需要立马进行处理的。很多人看到的"程序员需要24小时 on call"的段子就是为了防止生产环境出问题。

不过有的比较讲究的部门会在测试和生产环境之间再加一个生产隔离环境，比如涉及到支付、电商这样跟钱强相关的部门。测试人员在测试环境中将需求测完无误后，再发生产环境之前会现在生产隔离环境中走一遍，确认无误后再正式上线。

下面我用一个很常规的功能：网站的登录功能，来介绍下一个需求的正常开发流程是怎样的，是如何从构思到实现再到最终上线的，而在这其中又会使用哪些工具？涉及到哪些人？

需要说明的是不用公司流程可能有略微差别，这里主要介绍的是比较常见的需求开发迭代过程。

1、产品调研

一个需求的起点应该是产品经理，也就是PM。

产品把调研结论写成一页纸"决策记录"，附原型图和指标公式，拉研发、测试、设计、运营、法务五方会审。

通过标准：指标可量化、技术风险可控、法务无否决。

评审表全员电子签名后，需求池上锁，任何人再加需求必须走"变更流程"，否则研发有权说"不"。

2、技术方案与评估

研发负责人3-7天内给出技术方案：

• 时序图：用户→网关→登录服务→风控→消息中心，每一步超时阈值标清楚；

• 接口定义：字段、码值、限流阈值、降级逻辑；

• 数据变更：索引新增、历史数据迁移脚本；

• 灰度策略：按用户尾号分批，开关在配置中心，秒级回滚。

技术方案评审需要安全、性能、测试三方拍桌子，问题全部落地，研发才准开工，否则打回重新进行。

3、测试用例

测试同学拿到产品和技术组长的文档后写出"用例脑图"，分功能、异常、性能、兼容四类，一键导入自动化平台，等待研发人员将项目上线到测试环境中再开工。

4、正式开发

研发组长重新起一个会，简单过一下需求，将需求分给组员，每个人负责1-2个需求。

其中研发人员统一用公司镜像，本地一键起 Redis、MySQL、网关；

在代码主分支上重新拉分支，一般是从master或者main分支重新开分支。

分支合并请求必须满足以下下三条：

• 单测覆盖率≥90%

• 静态扫描零阻断

• Code Review 两人及其以上同意才可以发布。

每日晨会 15 分钟，对齐需求进度，如果延期以及无法按时交付的话，组长需要马上协调资源。

在组员全部开发完毕后，开发小组内部会约定一个时间一起合并代码，简单自测一下没什么问题才会发布到测试环境中。

然后通过测试人员开始测试。

5、开始测试

接口层用脚本压 1 万并发，UI 层用浏览器集群跑 20 条主流程； 同时把线上真实数据脱敏后灌入测试库，造出 500 种"脏"组合，提前发现边界 Bug。

严重 Bug 未清零，测试人员将版本打回，研发重新开工，直至全部功能确保无误。

6、灰度发布

先推 10% 用户，监控看三行数字：成功率、延迟、错误率，任一红线飘升，自动触发回滚，5 秒内切回老版本。

灰度 24 小时无异常，全量放开；期间运营在后台看实时漏斗，确认指标达标才签字画押。

7、线上观察与复盘

上线后 7 天持续监控，数据落到统一报表：登录成功率从 71% 提到 89%，验证码拦截量下降 38%，算是达到预期。

若出现事故，按"1-5-15"原则处理：1 分钟发现、5 分钟定位、15 分钟恢复；

事故等级定级后，48 小时内开复盘会，产出"教训清单"，Wiki 永久留存，下次评审先检查旧账是否闭环。

上面7个流程是大多数稍微正规点的互联网公司在开发新需求都会经历的七个步骤，有的可能更复杂，有的可能会精简某些环节。

像我就知道有个互联网中厂某些部门都是野路子开发，产品全程就一句话，啥文档都不提供的，研发有问题只能去问，就这样口口相传，出问题了就相互甩锅。

不要觉得不可思议，这个世界确实是个草台班子哈哈。

越是正规的公司，在上线新功能的时候就越严谨。需求不是简单"写代码"，而是把"一个想法"拆成可验证、可回滚、可量化的七步流水线，每步都有门禁和责任人；

流程是速度的朋友，不是敌人—它让几百人能在同一节奏里快跑而不翻车。

来源 | 拓跋阿秀（ID：coder_Axiu）

作者 | 阿秀 ; 编辑 | 呼呼大睡

内容仅代表作者独立观点，不代表早读课立场