一个最全产品开发流程

产品刘

共 2670字,需浏览 6分钟

 · 2022-05-17

近日有粉丝问我,是否可以分享一份产品的开发流程。
他总觉得自己对于产品开发流程把握不全,想查漏补缺,对照优化下。
今天我把我用过多年、一份最全的产品开发流程,分享给你参考。
希望对你开展工作有帮助。
产品开发流程起点,是需求的完成。
需求完成的前面,涉及到产品规划、需求管理等流程,此处暂不展开,后面另找时间写。
另外,此产品开发流程中,我只梳理产品经理参与的流程。
有些流程仅在开发、测试内部完成,产品不需要参与,时间很值钱,术业有专攻,可不用关注。

1、需求产出
产品研发流程的起点。没有需求,就没有产品开发流程。
研发需要需求方案,进行开发。
测试需要需求方案,指导测试。
目的:指导后续工作开展
参与方:你(指产品经理,下同)
2、需求内部评审
你所在的产品小组内部评审,主要是和你的直属领导和小组同事过。
所有对外评审的东西,需要领导确认认可,如果出问题,领导担责。领导的主要功能之一,就是担责😝。
同时,小组成员参与,也能帮助查漏补缺,有助于了解大家都在做什么。
目的:产品方案小组内部确认
参与方:你,直属领导,小组成员
3、需求交叉评审
进入技术评审前,和公司其他相关人评审。
因为你的需求,可能来源于业务方,可能来源于客诉反馈,需要和他们确认。
需求可能需要交互、设计参与或把关,需要和他们沟通。
需求可能涉及合规问题、安全问题,需要相关人把关。
目的:产品方案外部确认
参与方:你,业务方,客服,交互或设计,信息安全,合规等
4、需求技术评审
和技术、测试进行需求评审,便于理解需求后进行估时、排期和落地。
目的:需求解读和理解,认知一致
参与方:你,研发,测试
5、需求估时
前端、后端、测试进行需求估时,需要多少人天。
要做的东西很多,研发资源永远是紧张的。
时间出来了,可按照投入产出调整需求范围、方案,或者调整优先级。
目的:评估对研发资源消耗
参与方:研发,测试(你虽然不需要参与,但是需要推进给出排期,或者对估时有疑惑,可反馈给技术和技术leader)
6、确定优先级
对于带排期需求,排定排定优先级。
目的:确定优先级
参与方:产品负责人,或者产品负责人授权的人
7、需求排期
技术(含测试)负责人对需求排期,即什么时候开始、什么时候提测、什么时候测完等。
目的:确定需求落地各重要节点
参与方:研发,测试(你虽然不需要参与,但需要了解自己的项目排期情况)
8、需求开发
技术进行技术方案设计、编码。
这里技术有严格的开发流程,产品经理不必介入,不展开。
目的:把功能按照需求方案做出来
参与方:研发
9、测试用例评审
测试组织测试用例评审,看是否覆盖前面。
目的:测试范围和方案确定
参与方:测试,研发,你
10、需求提测和测试
技术提测需求,测试开展测试。
这里测试有严格的测试流程,产品经理不必介入,不展开。
目的:产品质量把控
参与方:测试,研发
11、上线前产品验收
这个阶段也叫用户验收测试(UAT,user acceptance testing),由产品经理来组织和验收。
目的:确保研发做的功能是自己需求中定义的,可用性符合预期
参与方:你
12、上线前UI验收
UI验收功能界面是否符合设计稿要求,提出修改意见。前端技术根据反馈意见进行修改。
目的:产品界面质量把控。
参与方:UI设计师,前端技术
12、上线评审
测试、产品验收通过的功能,进行上线前的上线评审。
产品经理阐述功能和价值,各部门或各小组负责人评审确认。
目的:上线前的把关和信息同步
参与方:你,各部门或小组负责人
13、上线
上线评审通过后,技术上线。
技术上线,也有严格上线流程,此次产品不必介入,也不用过多关注。
目的:功能上线应用
参与方:技术
14、线上验收
功能上线后,需要测试、产品经理,进行线上验收。
如果验收有问题,需要基于影响情况确定方案,是技术马上修复?还是先回滚,修复后再上线。
目的:确保上线后功能没有问题
参与方:测试、你
15、通知相关方功能上线
当功能上线后,验收通过后,就需要通知业务方(给你提需求的人)、你的领导和项目参与人。
如果是后台功能,功能较多、较复杂,还需要组织培训或提供培训文档。
通知邮件也表达下对技术、测试、UI、交互等深度参与项目的人感谢。
目的:告知、培训和感谢
参与方:你,业务方,项目参与人
16、数据跟踪
上线后,记得跟进下数据表现。
如果是历史功能改进,对比下上线前后的提升或下降情况。
提升的,全局放大;下降的,分析原因,仅需改进。
目的:跟进上线效果,评估是否达到预期计划
参与方:你
17、反馈收集和跟进
上线后,会收到用户、业务方或者自己发现的新的反馈、优化点。
新的优化和反馈,会进入下一个产品规划、需求管理、产品开发流程。
目的:跟进上线后反馈,为下一步优化做准备
参与方:你

这是一个非常全、颗粒度非常细的产品上线流程。
这个主流程里,还有一些分支流程,我没有罗列出来。比如:
1)需求的内部、交叉、技术评审,会存在一些问题,需修改后再次发起评审
2)技术的估时间和排期,没有到达预期,需要重新沟通后确定
3)uat不通过,需技术再次修改和提测
4)中途存在需求变更,走需求变更流程
5)上线后存在bug,需要回退或修复
等等。这些作为分支流程,可补充在上述主流程中。
另外,所有这些流程,不需要都组会沟通,有些工位当面碰一下、或群里发一下确认就可以。
如无必要,不要开会。
还有,你可以按照需要,将多个节点合并为一个流程,比如交叉评审和技术评审等。
如果你的需求很紧急,可舍弃大多数流程,直接拉技术评审后开干。
最后,产品开发流程,不是最全最好,最合适自己的团队最好。
「全」的代价是耗时、效率偏低;「全」的优点是不容易出问题。
不同的组织、团队,不同的业务,敏捷性不一样,协作流程不一样。合适自己的就好。
你可以基于你的需要,增加、删除、修改、合并,让适合自己的团队和业务即可。
这份产品开发流程,希望对你有帮助。
如果你喜欢这篇文章,欢迎关注上面的公众号


最后,我建立了各大城市交流群,想入群的小伙伴可加微信:yw5201a1 我拉你进群。
关注微信公众号:产品刘 可领取大礼包一份。
··················END··················
今日报告:抖音发布2021抖音数据报告下载报告去公众号:硬核刘大  后台回复“抖音数据”,即可下载完整PDF文件。
申明:报告版权归 抖音 独家所有,此处仅限分享学习使用,如有侵权,请联系小编做删除处理。

RECOMMEND

推荐阅读
盘点一下国内外优秀的“低代码”开发平台
手把手教你做产品经理
手把手教你写B端产品PRD
面试一对一辅导

点击“阅读原文”

查看更多干货

浏览 13
点赞
评论
收藏
分享

手机扫一扫分享

举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

举报