项目复盘思路:产品上线后要如何做复盘?

5 评论 63228 浏览 661 收藏 8 分钟

进行了2个多月的APP大改版即将结束,为此产品技术团队真的是尽心尽力,猛追猛赶,非常辛苦。然而越是大项目,越需要在结束时好好总结,这篇文章就来聊聊项目复盘应该怎么做。(注:本文内容部分来自邹欣《构建之法》一书,有兴趣的同学建议仔细阅读)。

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

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

目标完成度

  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. 各小组负责人保证要采取行动,优先执行票数最高的一些改进意见,持续优化所有需要改进的点

最后还可以在会议结束后大家一起聚个餐,休整一下,以备再战!

#专栏作家#

申悦,人人都是产品经理专栏作家,36氪产品总监,微信公众号:互联网悦读笔记(ID:pmbox)

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自摄图网,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 如获至宝!大赞

    来自内蒙古 回复
  2. 干货王

    回复
  3. 很不错,按这个提纲认真走一遍团队整体每次都应该会有提高。

    来自天津 回复
  4. 可以参考

    来自北京 回复
  5. 巨细,有些地方着实可以考虑一下

    回复