重大产品项目，牵一发动全身，在阿里这10年，经历过大大小小各种项目，菩提整理了重大产品项目流程。
并不是每个项目都要经过严格的流程，流程只是形式，重要的是，是否有相应的思考、准备。产品人只有深思熟虑了，才经得起挑战，才做得出好产品。
每家公司、每个产品的情况有差异，大家根据情况自行取舍。
重大产品项目流程，包含4个关键节点：
- 1.立项评审：确定项目价值，及是否可以启动。
- 2.需求评审：确定需求详细内容。
- 3.上线评审：确定项目是否可以发布上线，及上线发布方案。
- 4.Review评审：确定项目是否达成预期目标及问题、后续action，包含业务层面和项目管理层面。
1.立项评审
1.1 立项评审内容
立项评审核心看商业价值、投入产出比。
商业价值的论证需要充分、有力，包括用户价值、业务价值、行业分析，要有很强的用户体感+数据论证。
立项关键ckecklist在下面单列。
1.2 立项关键Checklist
立项关键checklist的核心作用，帮产品经理，想清楚方方面面的问题，并且和各团队做好协同。
立项关键ckecklist中，容易忽视的内容：
1）对关联业务的影响评估。
比如数据产品中将展示各类型广告的效果（直通车、钻展、淘宝客等），这可能会影响商家对广告业务的效果判断，进而影响广告业务营收。那么立项说明中，需要有充分的分析、论证，产品上也要有应对策略，并和相关团队做好沟通、协调，并达成一致。
要不然可能辛辛苦苦半载，项目还没上线就被掐死在襁褓中，也可能刚上线就被要求下线。
2）提前预知服务、销售，征求他们的意见。
服务、销售是最前线的同学。
一方面，服务、销售对客户、对市场的理解更接地气，会帮产品输入有价值的信息；
另一方面，他们在最前沿处理客户问题，如果产品改动没有提前告知，他们会很被动，造成客户的不满意，进而影响公司业务。
2.需求评审
立项评审通过后，根据项目情况进行拆解。
1个大项目可能会被拆解成若干子项目，每个子项目都需要进行需求评审。
需求评审的目的：让大家对要做的具体功能、流程、节点、用户体验达成一致，需求评审完后，大家可以开工码代码。
需求评审需要包含的内容如下：
需求评审中，很重要又容易被忽略的是项目背景与价值。
项目背景、价值是需求的起源，大家对背景、价值达成一致后，详细的功能设计就好沟通很多，不然到了项目详细说明和demo部分，还是会被拉回到背景和价值中，因为业务、开发、交互、法务、财务等各方还是会揪着问为什么要这么做。
3.上线评审
项目开发、验证完成后，是不是马上可以上？菩提的有篇文章分析了项目发布的4要素，重大项目不是想发就可以发。
大型项目需要进行上线评审。上线评审内容包含：
- 3.1 上线评审Check List；
- 3.2 运营沟通Checklist；
- 3.3 项目预发通知；
3.1 上线评审Checklist
还是以服务、销售协同为案例。
如果没有和服务沟通发布时间，万一公司大大小小N多项目集中在1周内，那就意味着客服电话会被打爆，电话接通率下滑，客户投诉必然升级，最终影响的还是客户对公司的信任。
如果没有提前给服务、销售培训，面对客户咨询，服务、销售无法解答客户的问题，客户会认为公司不专业、不靠谱。
同时，产品也在公司内部为以后的项目埋下隐患，因为一旦上了服务、销售团队的黑名单，以后洗白就没那么容易了。
3.2 运营沟通Checklist
可能有人说，运营不是上线后才开始的吗？
不是的噢。上线之前需要准备好完整的运营方案，上线前的预热也是一种运营。而且这是广义的运营，包括对内运营、对外运营。
3.3产品&项目预发布通知
根据项目等级确定项目预发的形式。
预发通知的内容：项目背景、价值、内容，发布时间、FAQ等。
预发需告知的人员：需包含产品&项目直接参与人员、周边合作人员（如服务、销售、关联业务）、决策管理人员。
4. Review评审
4.1：评审时间：
根据项目结果反馈周期确定，在立项申请中其实已明确review时间，一般在2周内完成，大部分需要在一个月内完成。
4.2：评审内容：
- 1）商业数据结果及分析
- 2）Review 结论：是否达到项目预期及原因
- 3）后续Action 和实施计划
4.3: Review汇报对象：
和立项审批的沟通级别保持一致，书面或会议形式不限。
项目尽可能做成闭环，项目review是很好的一种形式，有助于产品发展，也有助于人的成长，还是一种内部运营方式。就是不要把review做成走过场、走形式。
最后，无论项目大小，无论是否有立项评审、需求评审、上线评审、Review评审，每个环节的思考不能漏，这是产品人的内功。
本文由用户@阿沐发布于新媒体运营，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。