主要总结重构项目的前期预备,前期预备工作是产品经理应该投进时间最多的阶段,包括了需求调研、数据分析、老系统/老版本逻辑梳理、重构版本逻辑定义等等。甚至前期预备工作决定了重构项目的质量以及重构后的用户满足度,本文将各种场景下重构项目必不可少的预备工作抽象出来,以实例进行拆解。
文章较长,实在浓缩出来也就一张图,下面所有内收留都是对这张图的注释:
(虎扑M站在进行灰度时的中间页)
3. 沟通策略
沟通是产品经理的强项技能之一,不仅对内对接开发设计测试等,对外对接用户也应该展现很强的沟通能力。
重构/改版一定会碰到用户侧的阻力,改版不当很可能用户就再也不见了。灰度上线后一定要做好用户反馈搜集,可以考虑在新版悬浮一个新版反馈的进口。灰度期间就是不中断迭代的过程,将用户反馈的点列表记录,制定解决方案,排定优先级。
重构/改版后有人喷是好事儿,说明还有用户在用,对产品还有期待。真正可怕的是改版后用户一声不吭地直接走了。对于愿意反馈的用户可以考虑联系用户,拉群沟通,没有什么题目是沟通无法解决的,只要把用户真心放在第一位,尊重用户的反馈,改版阻力会大大减少。甚至可以考虑对一些忠实用户做认证标签,比如”热心XX“,这对于忠实用户是一个非常有效的激励。
四、后期跟进
中期灰度发布,逐步迭代完善后趋近于终极的产品形态,接着就可以全量替换上线了。实在到这里产品经理针对这个项目的核心工作基本上已经结束了,但是好产品永远是打磨出来的。
以全量上线的版本为x.0版本,持续关注数据和可优化的点,积攒一段时间后再进行迭代优化。这个时候的产品相对比较稳定,可以使用A/B测试、MVT测试等方法打磨产品。前端对于加载性能优化,后端对于响应速度升级等,都是在迭代过程中可以重点往提升的方面。
大多数情况随着项目结束,产品趋于稳定,同时又有新的项目接手,根本无暇顾及已经全量上线的新版本。
这无关痛痒,但是有心的产品会把自己做的每一个项目做到尽善尽美,将每一个可以优化的点记录下来,在后面当开发有空闲时间时安插需求,当开发看到一个专心做产品的伙伴,不会拒尽的。
本文来自投稿,不代表微盟圈立场,如若转载,请注明出处:https://www.vm7.com/a/ziyuan/11555.html