迭代上线前后，产品经理一定不能忘记的10件事儿

正文

请到「今天看啥」查看全文

邮件内容基本是本次迭代周期的工作总结，包括功能概要、开发测试概要、以及上线预期等，最好附上相关的需求文档、测试用例等等。

上线邮件是一个完整产品迭代流程的重要环节，是整个团队日常工作的阶段性总结。

上一段是对外说法，实际上产品经理的小心思是，万一线上出了什么问题，这邮件可以作为甩锅凭据：要么你测试没测出来（还能干点啥？），要么你开发没严格按照我的需求做（还能不能干了？）。

04 发布策略

迭代直接粗暴的全量发布的话，此条可以忽略。

如果需要灰度发布，就要提前约定好新版本推送的灰度用户范围，并唐僧附体一样反复念叨，直到程序猿想拿起那根铁棒子为止。

就这，上线前一刻也要再度确认灰度范围，稍不注意，他们就能手滑全量发出去。

05 应急预案

预估本次迭代可能带来的流量大小，别保守，往高了估，提前跟运维打招呼：服务器加足了，以及做好通宵加班的准备。

预估本次迭代可能出现的问题，别保守，往坏了估，提前跟开发打招呼：不要以为上线了就能下班，加班其实刚刚开始。

最后，怀着沉痛的心情做好迭代回滚的应急预案，包括技术准备、安抚用户、安抚销售以及领导等，提前更新一下简历也是可以的。

06 更新物料

提前准备好更新日志、版本号等，如果涉及到移动端APP，还要准备好新版本应用截图、功能介绍等。

上线后：

07 数据配置

对于需要后台配置参数的功能， 切记要在迭代上线后第一时间配置相关数据。

大多数活动类迭代，一般都需要配置参数，比如各种奖项个数、中奖率；一等奖的内定账号等。

08 通知用户

费时费力为用户做的功能，当然要通知用户了！

对于灰度发布的情况，上线后赶紧通知小白鼠们来用，产品公告、用户群、push、短信统统说了，有问题早发现早解决，解决不了早回滚。

如果跳过灰度，直接全量发布，不建议上线后的第一时间通知用户，最好是先让少量用户主动发现并使用，这样即使有问题，也能控制影响范围。（类似灰度发布的效果）

一段时间之后，基本确认本次迭代没问题了，再全量通知用户。

09 监测数据

请到「今天看啥」查看全文