产品经理

一个产品需求的研发流程是怎样的?

Posted on 2021-01-08,7 min read

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

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

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

下一篇: 作为项目经理应该串联起哪些流程→