最近在半路接手一个从0-1的产品，产品功能设计完毕、需求文档完成、需求评审结束，开发进行到了第二周，只需要保证产品正常上线。

听起来像一切步入正轨，正常推进上线很简单。真正了解后发现，产品的大部分功能细节没有解释清楚，主流程之外的功能存在缺失，协议类等文档不完整，外部沟通反馈时间过长等等问题。同时自己手中还有两个需求，一个在开发阶段，另一个产品设计中。

我是如何在这种环境之下，保证一款基于微信环境的保险类H5产品，正常上线的。下文讲述，上线前的物料准备。

一、产品载体准备 1. 注册微信服务号

微信服务号与公众号间的区别：微信服务号会在微信消息的一级对话栏中展示，方便服务消息及时触达用户；微信公众号全部收缩在订阅号消息中。所以选择微信服务号为产品载体；

2. 完成公众号认证和消息模板申请

这里消息模板需要提前申请，审核通过后，可选择行业内的模板进行配置。如果没有找到合适的模板，可以自己做提醒模板文案，然后向微信提交审核。官方给的审核时间是7-15天，实际会比这快一点。当然作为1.0版本的产品，可以根据资源情况去判断，要不要做。

3. 底部菜单和自动回复

底部菜单作为产品的入口，需要提前确认放置的内容，毕竟进入开发者模式，无法通过后台配置。还有一些自动回复文案，确定下来也要让开发进行配置。

二、文档类内容准备 1. 协议类文档

包含：《用户协议》、《投保须知》、《保险条款》、《常见问题》等等，需要先自己拟好，然后再通过法务人员审核。或者直接找有行业背景（保险行业）的人协助拟初版，然后再审核；

2. 短信提醒模板

短信提醒主要起到通知和促单的效果。用于接收短信验证码，支付成功的通知短信。以及保单到期，未支付订单等促单短信。第三方短信分发商，也需要进行短信模板审核，不过审核时间很短。

三、邮件准备 1. 同步项目进度类邮件

向产品总监、需求方、老板等关注项目的上级，进行定期的项目进度同步。比如每周一或每周五，发送项目进度类邮件，说明开发进度、文档准备情况、项目不会不延期、需不需要什么协助等。

2. 正式上线邮件

产品上线当天，面向公司全体成员的邮件。用较正式的口吻写明什么产品几号正式上线，上线后对哪些人有影响，介绍产品功能点，放置产品截图，最后留下联系方式方便全体成员进行需求反馈。

四、开发测试问题跟踪 1. 关注bu list

重点关注严重bug的处理情况，为了保证项目的正常上线，可以把影响用户量少、触发频率低的bug放入下次迭代中优化。

2. 回归测试

因为团队是比较相信测试人员，所以在产品上公测环境后，不需要大范围的验收，把主流程回归一下，没有问题即可。

3. 需求池管理

开发中总会有难决的问题，或者采用折中的方案，需要把这部分问题及时纳入需求池，方便下个版本优化。

五、相关人员通知

提前培训。告知运营、 *** 、销售、支持等相关团队，后台系统哪些功能点与其相关，上线后对现有工作有什么影响。可以通过文字、操作视频、会议等方式传达。

运营账/号开通。收集人员开通后台账号的基本信息，确定后台系统用户角色、能力范围，以此配置相应的权限。

六、接口系统情况 接口bug

需要关注接口系统情况，比如现有接口系统存在bug，经过沟通在测试环境下优先修复，是否能在产品上线前发布到正式环境。

PS：我负责的这个H5项目，就因为接口系统的bug修复后没有及时上线，导致我们的产品开发完毕，在正式环境下无法正常使用，最终项目延期。。。血与泪的教训。。。

总结所有类型产品的通用 *** 1. 查—产品是否满足上线标准

关注bug  list是否情况，是否还有严重bug

回归测试：产品的核心流程、核心功能是否完成可用？

上线时间：选择好了上线时间了嘛

冷启动：内容是否准备完毕，尤其是资讯类和社交类；

文案：所有文案是否明显无歧义。

2. 教—给一切相关的人做培训

运营需要的上线物料准备（使用文档，帮助文档、应用商店、帮助中心、推广物料）

告知运营、 *** 、销售、支持等相关团队，说明上线后的影响；

3. 预案—万一……怎么办

是否有planB，去解决上线不成功、大量用户投诉、用户暴增等问题；

4. 收—一个小小的好习惯，会让别人觉得更专业

收拾文档，开发期间存在需求变更的，需求文档是否补充完整；

交互图、设计稿，是否已更新；

未实现的需求、bug是否有解决方案。