前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >一个产品需求的研发流程是怎样的?

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

作者头像
WriteOnRead
发布2021-01-08 15:31:38
3K0
发布2021-01-08 15:31:38
举报
文章被收录于专栏:WriteOnRead

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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-12-28,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 WriteOnRead 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1. 前言
  • 2. 整体概述
  • 3. 流程分析
    • 0. 产品提出需求
      • 1. PRD 评审
        • 2. 交互评审
          • 3. 技术评审
            • 4. 开发测试排期
              • 5. 输出技术文档
                • 6. 测试用例评审
                  • 7. 前后端各自开发
                    • 8. 前后端联调
                      • 9. 提测
                        • 10. 测试环境测试
                          • 11. 预发布环境测试
                            • 12. 发布生产环境
                              • 13. 线上回归测试
                                • 14. 项目复盘总结
                                  • 15. 需求完成
                                    • 4. 补充说明
                                      • 1. Code Review
                                      • 2. 说明
                                  领券
                                  问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档