文档介绍：项目复盘思路:一款产品上线后要如何做复盘? 进行了2个多月的APP大改版即将结束,为此产品技术团队真的是尽心尽力,猛追猛赶,非常辛苦。然而越是大项目,越需要在结束时好好总结,这篇文章就来聊聊项目复盘应该怎么做。在复盘前,产品经理,或项目经理,需要拟好一个提纲,按:目标达成度、计划执行情况、资源协调情况、变更管理、从设计到编码、从测试到发布、团队协作几个方面,分别设定问题,并提前发给团队成员,收集大家的反馈;复盘时,召开全体产品研发设计测试会议,针对每个问题,思考解决方案,形成结论;复盘后,将会议结论汇总成文,发给全体与会人员,让大家进一步了解如何规避问题,为接下来的新项目做准备。下面重点讲述提纲中需要确认的问题,包括以下几个方面: 目标完成度我们的产品要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 我们达到目标了么(原计划的功能做到了几个?按照原计划交付时间交付了么?)? 用户量,用户对重要功能的接受程度和我们事先的预想一致么?我们离目标更近了么?(需要上线后观察再回答) 计划执行情况开发前,是否有充足的时间来做计划? 团队在计划阶段是如何解决同事们对于计划的不同意见的? 你原计划的工作是否最后都做完了?如果有没做完的,为什么? 有没有发现你做了一些事后看来没必要或没多大价值的事? 是否每一项产品需求都有清楚定义和衡量的交付成果? 是否项目的整个过程都按计划进行?项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到? 在计划中有没有留下缓冲区,缓冲区有作用么? 将来的计划会做什么修改? 资源协调情况我们有足够的资源来完成这个项目么? 项目所需时间和其他资源是如何估计的?精度如何? 测试的时间、人力和软件/硬件资源是否足够?对于那些不需要编程的资源(产品设计/文案/运营策略)是否低估了难度? 你有没有感到你做的事情可以让别人来做(更有效率)? 变更管理是否存在需求变更?变更了几次?每次变更的原因是什么? 需求变更时,是否每个相关的员工都及时知道了变更的消息? 我们采用了什么办法决定每次变更,是“推迟”还是“必须实现”? 变更的出口条件(也就是什么叫“改好了”)有清晰的定义么? 对于可能的变更是否能提前制定应急计划? 员工是否能够有效地处理意料之外的工作变更? 从设计到编码产品设计工作在什么时候,由谁来完成的?是合适的时间、合适的人么? 产品设计工作有没有碰到模棱两可的情况,团队是如何解决的? 团队是否运用单元测试(UnitTest),测试驱动开发(TDD)、UML、LINT,或其他工具来帮助编码?这些工具有效么? 什么功能产生的Bug最多,为什么? 在发布之后发现了什么重要的bug?为什么我们在设计/开发的时候没有想到这些情况?(需要上线后观察再回答) 代码走查(CodeReview)是如何进行的?是否严格执行了代码规范? 从测试到发布团队是否有一个测试计划?这样的计划是否有效? 是否进行了正式的验收测试? 团队是否有测试工具来帮助测试?效果如何? 团队是如何测试并跟踪产品开发效果的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进? 在发布的过程中发现了哪些意外问题?如何解决的?后续如何避免? 团队协作团队