一个最全产品开发流程
👇关注我入群，和3w+产品人，一起变优秀
产品开发流程起点，是需求的完成。
需求完成的前面，涉及到产品规划、需求管理等流程，此处暂不展开，后面另找时间写。
另外，此产品开发流程中，我只梳理产品经理参与的流程。
有些流程仅在开发、测试内部完成，产品不需要参与，时间很值钱，术业有专攻，可不用关注。
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，需要回退或修复
等等。这些作为分支流程，可补充在上述主流程中。
另外，所有这些流程，不需要都组会沟通，有些工位当面碰一下、或群里发一下确认就可以。
如无必要，不要开会。
还有，你可以按照需要，将多个节点合并为一个流程，比如交叉评审和技术评审等。
如果你的需求很紧急，可舍弃大多数流程，直接拉技术评审后开干。
最后，产品开发流程，不是最全最好，最合适自己的团队最好。
「全」的代价是耗时、效率偏低；「全」的优点是不容易出问题。
不同的组织、团队，不同的业务，敏捷性不一样，协作流程不一样。合适自己的就好。
你可以基于你的需要，增加、删除、修改、合并，让适合自己的团队和业务即可。
这份产品开发流程，希望对你有帮助。
👇关注我入群，和3w+产品人，一起变优秀
·································END·································
👇「产品笔记星球」，来了
一个产品人的成长星球，现邀请你加入
扫码可领50元减免券（最后30多个名额）
——推荐阅读——
2、微信热搜榜，来了
——粉丝群——
👇扫码加岳老三微信，免费拉你入「粉丝群」
和3w+产品人，共同进步