项目上线前怎么做 手把手教攻略

项目随着时间的推移与PMO、PM的鞭策，项目开发阶段接近尾声，PM需要进行统筹项目上线相关事宜。本篇文章将从三个方向，提供项目上线前的全部攻略。

分享一下我自己挖的坑或者别人分享的生产事故现场：

未与相关业务部门宣导项目上线，导致上线后业务部门瘫痪。相关参数配置未初始化，生产配置出错。主流程验收不认真，导致生产灰度失败。项目匆忙上线，生产无法运行，无回滚方案。………（未完待续）

上面的事故可能PM或多或少都有出现过，踩过坑不怕，我们吸取教训，怕的是在同样的项目上犯同样的错误。那么回过头去复盘思考，是否上线步骤有规律、有方法可寻！（万物皆有方法可寻）

我复盘了自己经历过的大大小小的项目（小到三人项目，大到几百人项目），把项目上线的过程用金字塔思维整理成思维导图分享给大家。

我认为项目上线的过程分为三个阶段【产品主导阶段】【技术主导阶段】【项目发布成功】，下面用稍微啰嗦的语言与大家一一唠嗑。

一、产品主导阶段

时间节点：全项目周期（感觉做产品很苦逼）

其实大家可以看出来从我梳理的结构来看，PM在每个项目所需要干的事情挺多的，且很杂（这里还没有包括项目前期的需求分析，出方案，交付物产出等），我们接下来针对每个阶段展开说明。

1.1 项目验收测试

目的：PM或需求干系人进行确认需求的实现是否达到预期，并推进项目进入发版阶段。

前置流程：测试同事完成ST测试并回归完所有BUG,开发同事重新打包程序包用于验收环节测试。

（特别说明：中小型企业在项目团队不完善或开发人力资源紧张时，PM其实在ST测试环节已经变身测试人员进行测试，从而会把ST测试环节与验收测试进行合并进行）

关键关注点：

核心流程验收。涉及前端需求（涉及前端交互习惯改变，客户端视觉优化），需要叫上设计师进行配合完成关键节点还原度。干系人关注点，需通过内部沟通软件或邮件通知干系人验收，或者由产品经理向干系人演示相关节点。保证需求的策划满足干系人的诉求。当关键验收指令发出，测试同事抒写测试验收报告，开发进行代码封板，准备上线事宜，产品同事需要准备相关上线的材料与配置规则。技术与测试相关的事宜我们放到第二阶段，技术主导层面去科普，当前第一阶段我们先谈产品经理需要搬砖的内容。

1.2 材料准备清单

每次的需求上线都伴随着相关的更新说明文档等相关的材料，当然材料之间也会有大的区分，针对不同的目标群体需要制作不同的材料。我分为2大类，下面我们一一说道。

1.2.1 标准化文档

1.2.1.1 标准化SOP指引文档

SOP为“Standard Operation Procedure”三个单词中首字母的大写，即标准作业程序，在企业中指的就是将工作和操作步骤规范为一个标准的流程，从而给员工的日常工作提供最优化的指导。

材料目的：为本次需求优化针对市场人员/客服人员应对用户或者客户进行的疑问咨询，提供标准的解释模板。前置流程：在指定文档之前，需要与干系部门的相关干系人员确认文档的合理性。当然材料不一定产品经理撰写，但是产品经理一定要跟进此文档的完成情况。关键关注点：文档的通用性，文档的可读性，文档的指引覆盖的全面性文档撰写人：产品经理or 业务人员。简单举个例子：客服作业的SOP标准文档，这个就是有产品经理辅助客服部门进行完成文档的撰写，比如提供可能的功能疑问点，常见问题等，由客服人员撰写文档内容，最后进行统一审阅，确定最终版本SOP指引文档。1.2.1.2 业务规则配置文档

常见的配置文档，组织架构权限文档，活动默认规则、数据报表文档等。

文档目的：针对譬如“活动、权限、组织架构、业务审批流等具备多规则功能需求”需设定系统层面默认上线参数配置。前置流程：与功能涉及干系部门梳理业务规则与涉及干系人，另外必须基于包含在当前需求范围内。（超范围沟通难免的事情）关键关注点：文档覆盖配置项完整，参数配置之间无互斥条件。文档撰写人：产品经理。简单举个例子：比如某某信贷系统更新，需要与各个业务部门之间确认涉及岗位，岗位角色、岗位功能、可操作数据范围等等。1.2.2 差异化材料

企业业务方向不一样，准备的材料可能会有一些区分，简单定义为TOB 与TOC企业两种 ，现在流行的TOVC的高度过高，就不提及了。

1.2.2.1 TOB企业差异化材料

1.2.2.1.1 培训材料（PPT）

文档目的：让运营部门或客户支持部门快速并且全貌的了解和熟知本次项目或者版本升级的全部功能点。然后由运营人员在向企业客户进行培训（如需要）或者进行答疑前置规则：在新版本上线之前完成材料内容即可， 提前约相关的部门时间点。关键关注点：提前完成培训材料，产品内部进行过初步内容，查漏补缺阶段。提前发出材料让业务部门的人员熟知，并且预约培训时间与版本上线时间。文档撰写人：产品经理1.2.2.1.2 宣传易拉宝、落地页等

材料目的：如上线功能利于业务推广宣传，需要与业务部门进行沟通，进行宣传材料的制作。前置规则：更新升级有必要大势宣传。关键关注点：营销内容确认，需要产品提供完成的功能吸引点，跟进业务部门确保上线之前物料能到位。材料准备人：业务部门人员。1.2.2.2 TOC企业差异化材料

1.2.2.2.1 停机更新通知（如有）

材料目的：为了让用户提前知悉功能升级内容及停机通知。用户提前心里有预期避免出现没通知用户进行临时发布，用户会一脸懵逼。（讲一个活生生例子，以前做支付需要断交易半小时，未全部用户通知到位，导致商户收款失败，客服电话都被打爆的那种。）前置规则：本次更新涉及到需要影响生产环境业务运转。关键关注点：停机文案撰写的合理性，停机公告推送时间，建议提前2~3天进行推送，最晚也需要提前1天。文案撰写人：运营部门或者产品经理（emmmm大概率是PM）。1.2.2.2.2 重磅更新banner图

材料目的：让用户明白或者知悉本次更新的重要内容，达到通知和引导用户升级APP等目的。前置规则：根据新版本内容确定是否需要更新客户端，当然现在不同的载体更新机制不一样。关键关注点：通知形式确认，push通知还是弹窗banner 还是二者皆而有之;通知内容确认，运营人员提炼相关更新内容与措辞.材料准备人员：运营人员。1.2.2.2.3 投放广告渠道方案（如有）

方案目的：仅针对新业务或者新功能需要进行投入资源进行大力曝光，需要配套准备广告投放方案。前置规则：功能需要设计投入而外资源进行推广。需要与广告部门或者运营部进行协作完成广告投放方案，需要提前想财务进行提预算审批。关键关注点：投放渠道，是否需要做渠道区分（可能会涉及到功能埋点的区分);投放需要哪些产品层面的支持;投放的时间与周期。方案策划人：运营部门或者广告部门 （大概率不会是产品部）还有其他的很多差异化的材料或者方案………避免篇幅过长我这边就不一一举例。

1.3 项目上线策略

1.3.1 灰度计划

微信视频号为什么我没有入口，视频号为什么我没有发布入口，这些都是产品灰度的机制。我们简单分析和了解一下灰度机会一般需要准备什么？

目的：常见产品上线规则，很多产品上线都会有灰度阶段，新功能/重大业务流程改造需要小范围测试用户接受程度与业务数据（转化率、跳出率）等。

设计策略：结合公司资源进行灵活设置，不要为了做灰度投入过高或过多的资源。需要去平衡投入产出比。

二、技术主导阶段

这个阶段基本没多少产品经理的事情啦，就是配合开发提供一些系统配置参数等。

来看图：

2.1 发布前步骤前置流程

产品经理/业务部门干系人员验收完成，测试正式推送验收报告，测试通过进入封包发版阶段。

其实思维导图里面的都是我自己根据多个项目经验整理出来的步骤，有技术型产品经理觉得梳理得有误，可以指正我修改。完整以下内容知道就好了。

2.1.1 配置参数检查（如有）：检查相关人员/系统参数是否配置正确。（例如：上新某个实名认证功能，需要做成开关配置，默认为【开】，那么肯定需要检查开关配置是否正确。）

2.1.2 项目版本封板：代码有毒，停止撸代码。（ 意思就是开发可以不用改代码了，不封版就会有各种“优化”需求提出来，改个字段，换个图片等。）

2.1.3 服务发布方案：发版的时候肯定是有个先后顺序，先发什么服务，后发什么服务，这里面不同公司机制不一样，当做了解就行。

2.1.4 版本回滚方案：这个一般都是不愿意看到的，基本出现了这个回滚就有人要倒霉了，年底kpi考核难看了。当然不管版本回不回滚，方案是需要的。最可怕的是版本需要回滚，没有回滚方案。emmmmm这事故现场想都不敢想。回滚场景：项目发布成功后，在准生产环境进行验收主流程无法通过且短时间无法修复。

系统环境科普及其场景：

开发环境：技术同事实现需求环境。测试环境：测试同事进行功能冒烟测试、ST测试UAT环境：业务部门、产品经理验收项目。灰度环境（准生产环境）：与生产配置一模一样，为了做上线后验证，如果业务流程无误才会发布到生产环境。生产环境：这个没啥科普的。

三、项目发布成功

开发大佬把项目成功发布上线，这个时候又需要产品/测试/业务人员介入了，进行最后的生产验证测试。

3.1 产品/测试验收

3.1.1 产品验收：验收功能配置、灰度范围、主流程是否正常。

3.1.2 测试验收：生产其他原有功能、业务是否正常。不能因为新功能的上线，影响到了老功能。

3.2 干系人验收

3.2.1 业务干系人验收：验证所提需求是否正常（有些需求改小小的规则，你们懂得，所以让业务的人自己验证）。

项目的上线是结束也是全新的开始。

本文由@微丶笑 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议