复盘：B端产品经理快速提升法

　　盘就是一个系统化思考的过程，当我们的知识体系结构化了、系统化了，我们才能举一反三，融汇贯通，提升自己的综合能力。
　　一、为什么要做复盘？
　　产品经理没有专业，也没有科班之说，学计算机的，法律的，设计的只要想做，都可以成为产品经理。正因为人人都是产品经理，我在刚开始做产品经理的时候，心里很没底。还特地请教了几位大佬：怎样才能提高产品能力呢？要看哪些书呢？
　　结果，答案很一致：经验积累。
　　我以为不停的做功能，做上个三五年，自然就成熟了。然而，埋头苦干了2年，发现自己还一直在门外徘徊。
　　不止是我，很多人都不愿意去复盘。觉得功能上线就是终点，其实，这只是个开始。每一次复盘时对自己的批判和肯定，逐渐构建了自己的知识体系。知道哪边可能会有坑，知道如何最小成本试错，知道怎么找到用户需求和开发成本之间的平衡点，知道怎么推动项目，知道怎么和其他团队协作。。
　　毫不夸张的说，复盘比不停的做功能更加有效，对我来说，绝大部分的能力提升，都来源于复盘。
　　二、什么时候需要做复盘？
　　时时刻刻。
　　是的，你没有看错，当发现问题时，就可以去复盘，总结经验，需要行动的就快速落实。
　　但这种复盘是不全面、不系统的。我们可以先把日常零散的点记着，再在这些重要的节点上做全面的复盘：
　　新功能上线半个月后，每1个月后，直到非常稳定。
　　年中，以及年终对整个系统的全面复盘。
　　三、如何做好全面复盘？
　　复盘要从用户的使用情况入手，通过真实的数据和回访来分析。功能设计肯定是我们重点关注的，但内部的项目协作方面也不能忽视。下面就来说说具体复盘的内容。
　　1。用户使用情况分析
　　这步收集和分析主要是为了下面的功能分析。
　　1）实际使用者数量是否达到预期？
　　我们在做功能的时候，会先进行用户调研，这部分用户就是我们的潜在使用者。功能刚上线时，他们可能是最先开始使用的。在针对新功能刚上线复盘时，我们会先看这些用户是否已经使用起来，使用情况如何。如果这部分用户都不能用起来，那功能设计可能存在很大的问题，整个方案都可能是错误的。
　　在后面使用的一段时间内，持续的关注用户数量。如果没有增长，那很可能这个功能是一些特殊用户的伪需求。如果稳定的在增长，说明这是一个合理，且有价值的功能。
　　2）用户对功能的整体评价如何？
　　有时候新功能上线了，不怕用户提一堆优化，就怕没人提。一点反馈都没有，要么就是没人用，要么就是没问题。但后者可能性还是很小的。
　　我们会先统计出用户对功能的使用量，选择数据量大的一些用户进行回访。题目设置如下：
　　实际场景中是否能用起来这个功能？
　　有哪些细节场景不满足使用？
　　对这个功能打几分？
　　回访样本足够多时，我们对功能的理解和迭代规划就会有更深层次的思考。
　　2、产品功能验证
　　很多时候，B端产品经理并不是用户，没有B端业务的亲身经历，做功能的时候常常感到很虚，就怕需求调研不充分，被部分用户带偏；也怕功能设计不合理，做出来以后没人用。
　　通过上面的用户使用情况调研分析，我们可以有理有据地来分析下功能层面的问题了。
　　1）整体方案是否合理？
　　这其实考验的是需求调研和功能设计能力。在调研阶段，有没有挖掘到用户的真实需求？在功能设计时，有没有基于用户的使用场景？
　　这时要反推这几点：
　　调研的是否是目标用户？
　　调研的是否是功能实际使用者？
　　调研对象是否具有代表性？
　　调研样本量是否充足？
　　是否获得了用户的真实需求？
　　是否是基于用户的实际场景给出的解决方案？
　　是否走通了功能的闭环？
　　是否全面考虑了对系统其他模块的影响？
　　如果这是一个成功的功能，那么那些调研过的用户，可以归到我们的vip库里，下次有类似功能需求时，可以先听听他们的意见。
　　如果很不幸，这是一个失败的功能，那么我们需要分析下，到底是上面的哪几点导致了失败。是因为调研的用户数太少？还是用户根本就不典型？那下次在选取调研对象时需要谨慎。
　　或者是因为设计能力差，没有弄清用户真实所需，那下次做完产品设计后，一定要内部多讨论，集大家的智慧。在产品原型出完后，多调研一些用户，请他们看方案是否合理。
　　前置环节做的越足，开发时就越顺利。功能做错了，后面再在那上面修改，或者推倒重来，成本是非常高的。特别是产生了一些数据后，不得不考虑老数据的兼容问题。
　　目前来说，基本上不会遇到整体方案不正确的情况。关于如何做需求调研，之前在”人人都是产品经理“上讲过直播课，大家可以去看看。
　　具体功能整体设计，可以看看之前写的这2篇：《全面解析：就诊预约应如何设计？》《叫号系统设计指南》
　　2）有哪些细节没有考虑到？
　　细节多少都是会有点问题的，但不是所有问题下次都可以规避的。这里要分2部分来看。
　　特殊的正常场景没考虑到
　　这就属于那种难以规避的类型。他属于正常的业务场景，但是属于正常场景中的异常流程。除非很了解B端业务，否则调研的时候，这类问题很难调研到。
　　比如说输液台。正常流程就是医生开输液单药房发药护士输液。此时的特殊场景就是：医生开了3天的药，输了1天，第二天换药了，如何提醒护士不要输错了？
　　还有一种更想不到的：因为护士扎针没扎好，患者生气，早上不输了，药品都被扔了，然后下午又来输液了，如何告诉护士，3天的输液量，2天输完了，还没有结束输液，不是系统的bug？
　　要想减少这种场景的考虑步骤，最好的办法找几个用户看原型，先体验功能。在功能上线后，短期内及时跟进。如果对这项业务不熟悉，心理没底，一定要多问用户。
　　产品设计细节考虑不周
　　这部分的能力是可以提升的，甚至做到基本不出现设计层面的缺陷。一方面是当前功能的设计细节。另一个最大、隐藏最深的问题就是对现有功能的影响考虑不周。
　　往往体现在这几方面：
　　当前功能细节不明。比如说统计报表中，最长的时间筛选跨度是多长？文本字段中，字数限制是多少？
　　和原有功能有冲突。比如说在做叫号功能的时候，需要增加预约后就给号的模式，但这和原来的预约模式产生了冲突，无法协调，只能二选一。
　　原有功能同步不到位。比如说增加了患者在手机端填写体重、血压等指标数据的功能，但是这些数据没有记录到系统的病人指标库里面，导致数据缺失。
　　遇到这类问题的时候，随时记下来，多复盘，下次在做功能的时候，就会很敏感，哪些地方可能有坑。对其他功能影响考虑不周，还有个笨办法就是，一页页去看原型，看看是否有哪一点被忽略了。
　　3）功能迭代计划是否合理？
　　我们都懂MVP这个道理，但是做的时候，可能就把握不好度了，一不小心就做多了。产品经理很多都有完美心理，以为做的越多，功能越丰富，用户使用就越满足。恰恰相反，做的越多，错的越多。在确认功能价值前，要懂得规划。
　　如果功能上线后，能被正常使用，且没有多余的，这是最理想的状态。比如叫号虽然复杂，有登记给号模式，预约给号模式，但都能被用户用到，且模式的占比差不多是1：1，就不适合做模式的分割迭代了。
　　如果功能上线后，有多余用不到的，或者急缺的。那首次的规划就不合理。比如说优惠券功能，实际上用户每次都只使用一张，但做到了多张叠加使用的程度，就造成了浪费。
　　需求优先级怎么划分，可以看下我之前写的这篇《B端产品的需求优先级选择》。
　　3、开发过程回顾
　　团队项目的协作，难度一点都不低于产品设计，甚至是产品经理更加头痛的事情。明明我设计的很好，是开发没有做到位；我文档很早就给了，但开发没有按期交付。为什么都要我背锅？
　　产品经理不只是用户和产品的黏合剂，也是各部门的黏合剂。开发过程的回顾，不仅要看开发功能实现上的问题，还要看项目管理上的问题。
　　1）功能实现不了怎么办？
　　开发说的最多的一句：这个做不了。
　　是不想做还是做不了？
　　刚开始的时候，开发说做不了，我们就以为真的没办法做。时间长了就会发现，做不了的功能很少很少。我们为了功能能顺利上线，就要对症下药。
　　如果是不想做，那就整理让他做的对策：
　　时间紧来不及。这期不上线，慢慢做，下期或者下下期上线。
　　觉得麻烦不想做。找他领导，要么做，要么换人做。
　　如果是做不了，也有做得了的对策：
　　能力有限不会做。给他找能解决的人指导。
　　底层设计如此，确实做不了。找替代方案。
　　2）项目中的介入节点是否合理？
　　项目周期截点有这几个：需求调研初评详评设计稿静态页面完成联调完成测试验收产品验收上线。
　　正常需要产品经理介入的环节是这几个：需求调研，初评，详评，设计稿，产品验收。
　　如果是小功能，产品最后验收一下就行，也不会有很大的问题。但如果功能比较大、比较复杂，我们需要注意介入的时间截点。尽量把工作都提前，以防上线时发现错误很多，来不及改。
　　我们在做大功能时，就会增加静态页面和联调后的验收。先把控页面字段对不对，功能有没有漏，等后面产品验收时就主要看流程通不通就行了。
　　产品经理最终要对产品负责，如何分散风险，保质量是需要在实践中不断调整的。
　　3）各部门的合作方式是否需要改进？
　　涉及到合作，最大的问题就是信息不同步，以此产生互相推锅。
　　功能没做，开发说是因为产品经理需求有变更，我不知道。产品经理说，我都当面和你说了，你怎么不认账了呢类似的扯皮可能每天都会发生。
　　我们必须把合作流程定下来，按照规定来执行。如果执行中又发现了其他问题，也要纳入流程中，直到各方达成一致，不会有大问题出现。
　　比如说我们会要求设计出完一部分设计稿后，先同步给我们审查。需求变更的通知要在群里发送，对应的人，并私聊发送变动内容，还会两至三天发送变更邮件，确保大家都知道。
　　只要涉及到合作的部分，都建议规范化流程。这样即使碰到人事变更，都一样能有序进行。
　　总结
　　我们每天都在学习，在接收信息，也在积累经验。但为什么有的人能快速成长，有的人老是栽在同一个坑里？因为知识太零散，不能学以致用。
　　而复盘就是一个系统化思考的过程。当我们的知识体系结构化了、系统化了，我们才能举一反三，融汇贯通，提升自己的综合能力。
　　再怎么忙，都要定时去复盘，特别是新功能上线后的一段时间内。不仅要分析产品设计是否合理，还要反思开发过程中的协作问题。因为产品经理不只是写文档、画原型就可以了，沟通协作也是必备技能。
　　建议收藏此文，下次做复盘时参考下。