内容举报
请慎重选择举报原因
复盘,是对一个事件的回顾、分析、反思、总结;
复盘,是在类似的情况再次发生时,知道该如何应对,并做得更好;
复盘,是为了能少走一些弯路,提升之后的工作效率。
作为产品经理,你平时复盘吗?复盘的内容是哪些?
个人认为,大项目完结后,复盘是一定必要,短时间内高度集中完成某件事情,也是最能暴露发现问题的阶段;非大项目外,作为产品汪,也应该保持下定期总结复盘的习惯,总结近期遇到的问题,规划下如何调整;
针对大项目复盘,个人建议预先思考整理复盘的核心要点,在召集团队成员进行开会复盘。核心要点可以从以下几个角度出发(欢迎补充指正):
1,项目目标完成度
要解决什么问题?上线的需求中解决了吗?原计划中的功能完成度如何?是否按时间交付?使用群体是否接受你的功能"改进"
2,项目计划实际执行情况
开发前需求评审足够细致?是否有充足时间安排排期?项目执行过程中有遇到什么风险,导致的后果是什么?排期时是否针对潜在风险预留了缓冲时间?
3,项目过程中的变更情况
过程中是否存在需求的变更?变更的频次和影响分别是怎样的?变更后各端是否都及时知晓了内容?是否提前预估到了可能存在的变更风险?
4,多端协调情况
研发、设计资源是否足够支持项目?其他方协助资源是否预估明确交付时间点(运营侧文案、产品侧需求等),是否按时交付?
5,设计/研发/测试/上线
研发团队对于设计的还原度如何?设计方向是否遵循了一贯的设计标准?什么功能存在的bug最多,核心原因是什么?是否有明确的测试计划?是否进行了严格的提测验收?发布后遇到了哪些意外问题?为何在测试阶段没有暴露这些问题?下次有什么方式避免?
6,团队协作情况
团队成员是否完成了本职的工作任务?项目执行过程中是否发生了人员的变更?原因是什么?团队间的协作情况是怎么样的?出现重大难题时,团队成员是如何解决的?
当然,最后别忘了带团队成员一起聚个餐,放松下,没什么事是一顿烧烤解决不了的~
对于产品经理来说,每一次有大的项目上线,总是需要进行复盘的。说简单一点,复盘就是一次思想的迭代,为下一次做出更好的产品做准备,也是一次成果分享,与研发、设计、数据等兄弟团队共享工作成果。我认为,要做好一次复盘必须从以下几点考虑:
复盘的背景,即我们为什么要去复盘。一个新产品的上线,要么是从0到1,此时应该讲清楚为什么要做这个产品,支撑起了什么样的业务战略;要么是优化,此时要讲清楚旧产品有什么样的缺陷,影响范围是多少。
总结得失。基于数据分析产品需求单中的核心指标相关,用于回顾产品整体效果,通过额外数据分析产品后续的迭代方向。
目标,即我们通过分析想要达到什么效果。从信息的表达效率考虑,将关键结论前置是有必要的。但从整体上来说,复盘报告还是会按照STAR法则展开。因此,在这一步,我们该介绍(回顾)项目的目标了。
具体分析。基于此目的,我的建议是具体分析包括结论回顾+图表+文字说明这三个部分。其中图表是核心,优秀的图表往往不需要很多的文字说明,就能够很直观地表达出你的结论。
反思及补充。这部分是对整篇文档的补充说明,一般包括起到补充说明作用的数据报表、产品的视觉图或者其他你认为能够起到补充说明作用的内容。基本上到这里,一篇完整的产品复盘报告就算完成了。
提供一下我的复盘思路,供你参考~
因为我喜欢自我辩证,所以无论事情大小,我都会主动去复盘,大到项目就不说了,小到一次决策一个对客户或同事的回复等,所以我觉得最重要的是要有复盘思维。
具体形式的话因人而异,我是这样的:
时间上一般一年会输出一份年报(即使没有要求),内容包含:
- 产品目标是什么、是否达成目标、如果未达成的话是为什么
- 产品运营指标是什么、达成多少、为什么
- 关键性产出、里程碑节点统计,是否和预期内容和时间节点一致
- 市场调研成果、下一年产品规划方向
- 转发给老板评阅
关键节点上也会有输出报告,关键节点包括但不仅限于:
- 产品重点版本更新且上线一段时间后已收到数据反馈。一般这种情况是会在上线之前有预期和埋点的,观察数据是否达标。这时候输出的就是是否达标的总结和原因分析
- 完成客户拜访且纠正了之前对业务的认知偏差。一般对业务理解发生纠偏的时候一定要及时复盘,特别是这种拜访客户的场景,很容易忘,且对业务纠偏直接影响后续产品规划。一般我会在会议的时候录音,并且会议纪要是记录关键事件的时间节点的。比如客户说了一句对产品(或解决方方案)表达态度的话会记录时间和客户的具体反映,再比如就是 BD 在演示解决方案 PPT 的时候哪些板块客户提了大量问题且很感兴趣,哪些板块客户巴不得早点跳过去等。
- 内部关键性会议且产出关键决策。比如产品部门就某个业务形态的讨论会议(不是那种划水的周会),特别是会议内容和自己或自己的产品强相关,且决策内容和之前自己的预期有比较大出入的时候,此时最好在会议上表达自己的看法,会后一定要复盘,除了知道接下来知道怎么办之外,还要搞清楚为什么,多问几个为什么。(因为有些决策背后可能是政治、社会因素,比如两个选择都没有绝对对错的时候)
从19年下半年开始至今,每天都有复盘,不只是工作中的问题
复盘的内容主要是今天遇到了什么问题,怎么解决的,为什么这样解决,有没有更好的方式(因为人在不同时间段对一个问题有不同的想法)。有没有没有解决的问题,后面需要注意哪些地方不再犯。
人际关系中也是一样,如果有同事之间有矛盾或者抱怨工作,想想为什么会有这样的情绪。
我觉得每一次复盘都是必要的,有时候方向以及经验是不同的
复盘的内容主要从背景、目的、流程、效果、分析、以及总结来说
背景:就是你为什么做这个事情
目的 :就是做这个事情的目的是什么呢
流程:他的流程都有哪些呢?业务流程?页面流程?
效果:达成的效果是什么样子的呢?
分析:上线后的分析是什么样子的呢?
总结:总结下这次做的地方,以及下次可以改进的地方
答案是肯定的,分享下我日常复盘的内容
业务篇:周、月、季度为单位,与业务执行部门开会复盘周,月及季度的成绩,并从业务部门获取需求,排期及实现;
团队篇:人员比较多,从以前的全员例会修改为组长例会,涉及技术,产品,设计小组,以周为单位,复盘一周工作进度及下一周计划,并对工作产出进行点评,给到足够的意见与建议并收集小组需求以确保团队的相互配合与公司业务发展在同一条线上;
个人篇:基本以月为单位,复盘当前月自己所花的精力与产出是否成正比,是否有浪费的精力及精力都分别分配在哪些板块,对自己的公司奉献值,个人成长(经验),人脉进行复盘;
生活篇:个人把工作和生活分的比较开,一般复盘下出入账,夫妻感情,生活热点等;
每天写日报的时候,工作和感悟不就是对自己一天工作下来进行的一个复盘嘛。复盘今天目标达成的进度、数据的表现、和开发以及其他部门的沟通情况......就是今天干了啥,就复盘啥,哪里做得不好的写出来,再加上改善的措施,就是一个复盘了。
复盘。不只是一个项目做完之后才总结,我们每周一都会开例会,对上周的工作进行总结复盘,以及这周的工作内容、工作重心,所以复盘总结不一定是在项目完成后,也可以在项目过程中。
每次做完一个项目,复盘总结是必须的。我的习惯是形成书面文档,方便追溯,主要从流程、效果、分析、总结四个方面进行。
’流程是介绍项目的背景和重要节点梳理。
效果是项目上线后的表现,比如是否达成了目标,用户满意度如何。
分析就是复盘总结的重中之重了,对项目过程中做得好与不好得地方进行分析,总结经验。
总结即是如何解决上面遇到的问题,并运用在后续的工作中。
暂时还没回答,等你发挥
扫码即可下载app
内容举报
请慎重选择举报原因
邀请回答
想要更快获得答案?试试邀请回答吧~ 今日已邀请0/5
瑞瑞
ζ浅安时光
肉凇
笨笨的大雄
无
木夕
塔塔金
赵潇
东隅
产品经理
PGP
万年一遇的天才少年灰
并不疼的腾讯
玬.
single 先生
要武
Jerry
前科大讯飞(划水)工程师 / 奇瑞汽车(摸鱼)经理
小蜗牛
遇见 更好的自己
做运维也是产品经理吗
既然选择了这条路,就不能再回头
阿啵呲嘚
天下之至拙,能胜天下之至巧。
DANIEL Z
icysincere
Aube
易恒
以无厚,入有间
ABCD
crystal
汪仔9954
歪瑞古德
starry
汪仔7060
Way
专栏作家
某国民办公软件产品人,多年SaaS、数字营销、商业化经验,公众号:产品之way
Master
生如夏花之灿烂
Jason🎈 ?
全球问
天天问在全球
红夜
资深产品经理、互联网分析师
和光同尘
数据改变人类的决策方式,自身能力和环境!
dustmoon
Demi
专业背锅侠
给问题加标签后,可根据标签推荐更专业的用户来回答
微信扫码即可分享
删除后将不会展示在回答列表中
沉底后问题将从推荐列表中移除,此为
智囊团成员特殊权限,请谨慎使用
问题已沉底
用户将无法在列表查看到该问题
沉底操作已达上限,建议联系天天问管理员
处理违规内容
请重新尝试
©2016-2024 - 深圳聚力创想信息科技有限公司 - 粤ICP备14037330号 粤公网安备 44030502002255号
广播电视节目制作经营许可证(粤)字第03109号 增值电信业务经营许可证粤B2-20190788 版权所有 © 深圳聚力创想信息科技有限公司