3-4-4：

3个流程：产品评审流程、产品研发流程、项目交付流程

4个会议：评审会、周会/日会、回顾/复盘会‘、分享会

4张表格：产品规划表、OKR表、项目跟踪表、绩效考核表

产品评审流程/评审会

主要是对新产品或者产品大版本迭代的评审，对于启动一个新产品研发，需要多维度评估，参与方包括业务负责人、产品负责人、研发负责人和市场负责人。新产品的评审需要发起人从以下几个方面准备：

1）客户价值：客户需求、市场空间、竞争对手分析；

2）商业价值：短期投入产出比和长期价值；

3）资源优势：为什么我们能做，我们具备哪些资源、哪些优势？

4）产品规划：MVP版投入资源和时间、第一版推出计划和时间、前三个种子客户落地计划、复制推广计划；

启动一个新产品的评审需要做一个完整的BP，做BP的过程需要多次头脑风暴，BP提纲如下：

另外，四个频次比较高的评审会是产品需求评审会、系统架构评审会、测试用例评审会和非标产品（客户定制化项目）评审会。产品需求评审由产品经理发起，UI设计和研发人员参加，通过产品原型和PRD文档来讲解产品需求。由于我们选用springcloud微服务架构，常规的架构基本已经确定，所以，系统架构评审通常发生在第三方组件选用或者一些复杂系统组件间的边界和通讯问题。测试用例评审主要目的站在测试的角度对产品需求进一步梳理和理解，开发同步考虑如何实现，是测试驱动开发的入口。定制化项目的评审也会比较常见，主要是大B客户很少能直接用产品满足其需求的，所以，如果客户需求被产品经理直接接纳到产品规划中，直接调整产品迭代优先级即可，不用评审。如果产品经理认为属于完全定制需求，需要从投入产出比上考量是否需要接受客户定制化需求。

产品研发流程

产品研发流程主要采用scrum敏捷开发管理流程。产品启动定义MVP范围，后期迭代周期一般为两到三周，根据每个迭代周期的需求范围制定OKR表，产品与研发人员每天早晨开站会，总结前一天的工作、讲当天的工作安排和需要其他人配合或者求助的地方。每个迭代周期完成后开回顾会，展示本期迭代成果，总结做得好的（Done well）、还可以改进的（To do better）和下一步落地措施（Try to do）。在这个过程中，比较有挑战的工作是如何确定每个迭代周期的需求范围，即要考虑工作量、又要考虑可交付的成果、还要尽量避免重复工作。另外，在研发过程中，统一的技术架构和编程规范非常重要，是在启动前和新同事入职时必须培训的内容，定期做code review（这一点我们一直做的不够）。

一般产品研发，在三个月左右的时候，我们会暂停一下产品迭代，留出两周左右的时间来对系统进行一次重构。原因是我们采用OKR来驱动，节奏和压力都非常大，必然有些垃圾代码和不合理的结构，利用重构的时间，可以让他们对产品架构、系统架构和代码质量，甚至开发流程管理有一个完整的思考时间。