互联网产品上线后,产品经理该思考这几点复盘!

最近看到一个项目的复盘,这个项目距离预期目标还差的很远,但这个项目的回顾,只用了三句话:

  • 目标未达成
  • 渠道转化率过低
  • 万圣节+双十一公众号阅读量过低

不知道项目参与者及其他人看后怎么想,我看完的感受是:这种复盘能帮助项目下次达成目标吗?失败的原因只是因为外部因素吗?这能算是复盘吗?

答案是不,这是甩锅。我很反感这种行为,这是典型的“不愿意承担责任的”行为。

有人觉得反正给公司做事,事情没做好,给老板一个看似“合理”的理由不就可以了,干嘛追根究底跟自己过不去,自己只想舒舒服服的做事,舒舒服服的领工资。

可是,这不仅是对公司、对团队不负责任,更是对自己不负责任。假设你在某个问题上栽了跟头,不去想是哪里没想清楚、还是哪个动作没做到位,下次遇到这个问题,还是会失误啊。

这几年复盘被炒得很热,在互联网思维大潮下,所有企业和互联网人都面临着自我的创新和突破。

从最早的棋类术语,到现在的互联网术语,复盘已经有了一些成熟的方法论。恰好最近听了柳传志关于复盘的分享,有一点小收获及小感想,想分享给大家。

01 时刻保持警惕和前瞻性

无论是做一件事,还是做一件事的复盘,都要时刻保持警惕和前瞻性,不要完全沉浸在当前的事情里,要时不时抬头看看身前、身后的人都在做什么。

这里不得不提一个案例:被数字技术终结的柯达胶卷。

1998年,数字成像技术冲击了传统成像技术,柯达深感传统胶卷业务的萎缩之痛。但是,柯达的决策者们,却不敢大力发展数字业务:担心胶卷销量会受到影响。6年之后,柯达推出了数码相机。

可这一切都太迟了,柯达最终破产了。打败它的不是数字技术,而是柯达自己。

决策者们为了维护自己胶卷霸主的位置,选择对技术和市场的变化视而不见,同时也忽视了一个生死的问题:数码相机出现了,人们还会需要胶卷吗?

这个例子告诉我们,即便此前是成功的,也不可能完全复制。成功的某些边界条件是在不断变化的,比如用户需求和习惯的转变、市场大环境的改变、时间的迁移等等,任何一个因素的变化都能影响下一次的结果。

02 去做你相信的事情

复盘的前提是先归因,保证从战略到思考再到执行,整条线都是正确的,哪个环节出了问题都可以马上知道原因。

就好比我们要做一件事情之前,都会有一个假设,我们相信了这个假设才会去做这件事,做完了之后,再去全盘回顾和复盘。

复盘的目的是“瞄”着打,而非“懵”着打。当然,有人会说“不是所有事情在做之前都能想的那么清楚的”、“哪有时间想那么多”……

只要你愿意,总能想清楚百分之六七十吧?我遇到过没去想清楚、不愿意花时间想清楚的项目,最后的复盘简直就是甩锅大会。

做了一个活动,效果不好,就说“下次不用这个渠道了”;

做了一个方案,用户不买账,就说“我早就说了这么做不行”;

做的项目没办法交付,就说“我就说交给那谁谁不靠谱”……

渠道不好、方案不行、同事不给力……为什么不在一开始就提出?为什么不做预备方案和补救措施?

每件事都会有因果,结果是自然而然的,决定要做一件事,要应该关注的是思考的清晰和执行动作的到位。复盘的结论落脚在偶然因素上一定是错误的。复盘没有进入到逻辑层面,没经过逻辑验证,结果一定不可信。

03 一定要开放心态

之前在知乎上看到一个问题,大意是“最后两天,产品出现问题了,一定不能按时交付,你会跟老板说吗?怎么说?”

这是职场中很常见的问题类型:产品无法按时上线,负责人却没有提前跟老板打招呼;研发被一个功能卡住了,明显要延期却不告诉产品;活动某环节出现问题,偷偷处理……

这种问题的最好的解决办法不是私下处理,而是开诚布公:

研发在预知到无法按时交付的时候,可以跟产品经理沟通,产品经理来决定是否精简需求、或是重新估算研发时间。而不是临近交付才被动传达这个信息,影响整个团队的交付。

再说知乎的问题,如果老板对这个项目的结果非常关心,作为负责人,发现问题及问题的影响之后,应当立刻向老板说明情况:

  1. 问题产生的原因、影响;
  2. 问题的解决方案;
  3. 其他可替代解决方案;
  4. 每个方案的优劣势;
  5. 你建议采纳哪个方案。

复盘也是一样,有些同事会刻意避开一些问题或是隐瞒一些情况,导致整个团队的复盘都不够客观、有效。

之前见过一个项目,从立项开始就各种坑,一个坑一个坑跳到最后去的,而这些坑绝大部分都是思考不到位、准备不充分导致的。

最后项目结束了,相关负责人却在团队里各种打鸡血,只抛出几点有不错反馈的东西,让大家都感觉这个项目非常的成功。

无论是正在做,还是在复盘,都应当秉持着开放的心态,进行客观的剖析后,向相关同事实事求是的坦诚表达,能给出解决方案就给解决方案,给不出也可以请教大家,集思广益也能帮你解决问题。

04 要总结规律

总结规律是复盘最重要的环节,这个环节需要找到哪些失误可以避免,哪些方法可以总结为经验,未来再做,又有哪些需要特别关注的地方。

需要注意的是,不是所有规律都能拿来直接用的。规律也有可控、不可控、部分可控之分。可控的规律,我们可以将其标准化;不可控的规律,可以提前准备PlanB。

总结完规律,也要有接下来的举措和行动计划。要有明确的todo,哪个环节、步骤、人是下次要注意和替换的。

管理层面来看,一个系统中可以调整的基本元素是人和事:要么改变事情的流程和方法,要么调整事情的执行者。

05 时刻复盘

前面说了这么多,都是想传达一件事:复盘值得你的时间。大到战略、中到战术、小到每一天每一件小事的思考,同一件事不同时段去看都是不一样的。

复盘更多的是思维上对事件的重现,通过对过去的思维和行为进行回顾、反思,从而发现问题,吸取经验,最终实现能力的提升。可以防止我们以后在同样的事情上犯同样的错误,或是降低出错的概率,也可以帮助我们不断检验和矫正目标。

复盘前,产品经理,或项目经理,需要拟好一个提纲,按:目标达成度、计划执行情况、资源协调情况、变更管理、从设计到编码、从测试到发布、团队协作几个方面,分别设定问题,并提前发给团队成员,收集大家的反馈;复盘时召开全体产品研发设计测试会议,针对每个问题,思考解决方案,形成结论复盘后,将会议结论汇总成文,发给全体与会人员,让大家进一步了解如何规避问题,为接下来的新项目做准备。

下面重点讲述提纲中需要确认的问题,包括以下几个方面:

目标完成度

  1. 我们的产品要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
  2. 我们达到目标了么(原计划的功能做到了几个?按照原计划交付时间交付了么?)?
  3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?(需要上线后观察再回答)

计划执行情况

  1. 开发前,是否有充足的时间来做计划?
  2. 团队在计划阶段是如何解决同事们对于计划的不同意见的?
  3. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
  4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
  5. 是否每一项产品需求都有清楚定义和衡量的交付成果?
  6. 是否项目的整个过程都按计划进行?项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
  7. 在计划中有没有留下缓冲区,缓冲区有作用么?
  8. 将来的计划会做什么修改?

资源协调情况

  1. 我们有足够的资源来完成这个项目么?
  2. 项目所需时间和其他资源是如何估计的?精度如何?
  3. 测试的时间、人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (产品设计/文案/运营策略)是否低估了难度?
  4. 你有没有感到你做的事情可以让别人来做(更有效率)?

变更管理

  1. 是否存在需求变更?变更了几次?每次变更的原因是什么?
  2. 需求变更时,是否每个相关的员工都及时知道了变更的消息?
  3. 我们采用了什么办法决定每次变更,是“推迟”还是“必须实现”?
  4. 变更的出口条件(也就是什么叫“改好了”)有清晰的定义么?
  5. 对于可能的变更是否能提前制定应急计划?
  6. 员工是否能够有效地处理意料之外的工作变更?

从设计到编码

  1. 产品设计工作在什么时候,由谁来完成的?是合适的时间、合适的人么?
  2. 产品设计工作有没有碰到模棱两可的情况,团队是如何解决的?
  3. 团队是否运用单元测试(Unit Test),测试驱动开发(TDD)、UML、LINT, 或其他工具来帮助编码?这些工具有效么?
  4. 什么功能产生的Bug最多,为什么?
  5. 在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?(需要上线后观察再回答)
  6. 代码走查(Code Review)是如何进行的?是否严格执行了代码规范?

从测试到发布

  1. 团队是否有一个测试计划?这样的计划是否有效?
  2. 是否进行了正式的验收测试?
  3. 团队是否有测试工具来帮助测试?效果如何?
  4. 团队是如何测试并跟踪产品开发效果的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
  5. 在发布的过程中发现了哪些意外问题?如何解决的?后续如何避免?

团队协作

  1. 团队的每个角色是如何确定的,是不是人尽其才?
  2. 项目执行过程中是否有团队成员变更?变更是否带来的问题?如何解决的?
  3. 团队成员之间有互相帮助么?
  4. 当出现需求描述、项目管理、合作方面的问题时,团队成员如何解决问题?

总结

  1. 关于以上问题,有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
  2. 你觉得团队目前处于“萌芽/磨合/规范/创造”阶段的哪一个阶段?为什么?
  3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
  4. 你觉得目前最需要改进的一个方面是什么?

每次的项目复盘,都建议针对以上问题,全体成员在会上都发表意见,提出自己的看法,并群策群力寻找最优的解决办法。具体到会议的组织,有如下建议:

  1. 保持会议轻松愉快的氛围, 可以考虑换一个开会的环境, 有饮料、零食、音乐的帮助更好
  2. 大领导最好不要出现,让大家畅所欲言。(即使出现,也要夹着尾巴,不要为自己以前的行为辩护,作好听众)
  3. 坚持对事不对人的原创,强调:如果再有一次机会,会如何改进?而不是挖历史旧帐。
  4. 照顾到上述提纲中提及的各个方面, 可以深入团队最感兴趣的部分。
  5. 让所有人都有充分发言的机会。
  6. 务必有人记录发言要点, 最后列出所有改进意见
  7. 最后大家可以投票, 如果我只有三票, 投给哪些改进意见
  8. 各小组负责人保证要采取行动,优先执行票数最高的一些改进意见,持续优化所有需要改进的点

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/3192.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息