多年前，我作为一名B端产品新人，牵头负责公司SCRM平台的定制化开发。在项目过程中不断复盘，让我的产品能力有了很大提升，在这里我总结了一些之前的复盘思考给各位B端产品新人，希望能给你带来一些工作上的启示。
我认为复盘是 PDCA 戴明环里最重要的一环，对计划P和执行D进行检查C，输出处理行动A，让我们的工作形成持续优化的循环，提升工作的绩效。
如果我们只是不停的做计划，执行计划，缺少了对工作的复盘，就很容易陷入一种低效的忙碌，无法提炼出优秀实践经验来指导未来的行动。
复盘是个人或团队对事件或项目，进行回顾、反思、重构的结构化的学习过程。
在复盘的过程中，我们从实践中反思经验，分析成功和失败的关键，总结出规律进而形成个人经验，提炼出高度抽象的方法论，进而提升我们解决问题的能力。
在《远见》一书中，开篇就提到“可迁移技能”是三大职场燃料之一，而解决问题的能力是能让你与他人拉开差距的可迁移技能。
多年前，我所在的公司是一家传统制造业企业，计划引入一款SCRM Saas产品进行私有化部署，并基于乙方公司标品的底层能力，进行深度的定制化开发，接入公司现有系统，以便于更好的满足业务团队个性化的需求。
由于当时公司还处于数字化转型的初级阶段，公司的IT采购流程要求必须需要给采购部门提供详细并且明确的采购需求说明书，遵循严格的预算控制。
这给我们的新产品开发带来了很大的难度，因为这个时候项目才刚成立，大家都不知道具体应该怎么做，业务方给到我们的需求也是非常笼统的，好在公司财大气粗预算充足。我只好硬着头皮，将宽泛空洞的需求说明书尽量描述清楚，在采购巨大的挑战下完成了采购流程。
第一期产品耗时整整3个月才完成开发上线，功能上线后，业务方的运营重心已经开始转变，已上线的功能价值远不如提需求时的高。其次业务方还提出了大量的优化需求，当前功能已不符合当下的业务场景。
后面通过对项目管理的系统性学习，我逐步了解到，在项目管理中将项目的开发生命周期可分为预测型、敏捷型、迭代型、增量型，或者多种类型结合的混合型。
传统制造业企业更关注计划，按照采购的要求，明显是要求我们项目的开发生命周期采取预测型，这确实也符合企业过往的业务流程，但在互联网产品上就明显不适用了，因为IT产品的有着非常强的灵活性，需求的变化调整也是非常高频，在互联网公司，基本都采取增量型或是敏捷开发的模式。
Action行动：
为此，第二期的开发我提出采取混合型的项目管理方案。采购层面仍然采用预测型，将可能涉及到的需求范围尽量描述完整。而开发层面采取敏捷项目管理的 Scrum 框架，每3周一个Sprint冲刺。
经过这样的调整：
首先，产品功能价值得到了大幅提升。业务方提出的需求，可以保障3周内完成MVP的上线，业务方可以尽快用起来了。
其次，能更好地应对频繁的需求变化。在冲刺期间内不做需求变更，业务方提出的新需求，评估可行后统一放到未来的 Sprint 进行开发，由于3周的时间对比过往3个月灵活很多，可以更好地贴合业务侧的各种调整。
最近看到一个段子，产品经理去面试，面试官问收到业务需求后应该做什么，产品经理回答进行需求分析，结果直接被淘汰。面试官给出的答案是要先看谁提出的，如果是老板提出的直接开始做。
看似是个段子，但是也确实反映了当时我们公司和其他很多公司产品经理的现状。
当老板发现我们效率提升后，要求我们将一个 Sprint冲刺缩短到2周，并也开始给我们提出新需求。当业务侧发现我们的开发效率提升后，也开始给我们提出更多的需求。
随着一个又一个迭代的上线，功能越来越多，也开始出现一些功能，提出需求的时候非常急，但上线了又没人使用的情况。这让我开始反思，在需求分析环节，是不是还没真正做到位。
Action行动：
我和团队基于需求文档，对已上线的功能，进行了系统性的复盘，共同输出了需求分析的灵魂7问：
之后无论是谁提出需求，都要先和我共同完成这灵魂七问。能够清晰回答出这七个问题，最起码是一个经过认真思考的需求，后续再根据回答进行需求价值分析、定义优先级，让我们的产品功能更加集中在解决核心业务问题上。后续我们还在此基础上迭代更加系统的需求收集表，帮助我们更好地进行产品规划和资源评估。
第一期的SCRM平台开发项目，基于服务商通过PHP语言开发的标品Saas，由服务商提供PHP开发人员进行定制化开发。
而我司内部的开发团队只有Java的开发人员，并没有PHP的开发和运维资源，这就意味着未来服务商质保结束后，我们的开发团队还需要新增额外的PHP开发资源来专门进行这一个系统的运维。其次就是在一期产品上线后，出现常用功能页面加载速度明显过慢的情况。
出现这个问题，一是我作为产品经理在评估技术需求时过度依赖开发团队，没能更进一步多考虑下技术层面的内容。二是在项目初期，内部开发团队人员较为混乱，核心成员计划离职，没有从技术层面进行更长远的规划。
Action行动：
首先，从第二期合作开始，我与内部开发团队建立共识，要求服务商全部基于Java语言进行开发，并将第一期的内容进行Java重构。这里着实走了一些弯路，但我也问了一些做开发测试的朋友，说这种代码重构项目他们公司也很常见。
其次，我与开发团队将之前过于宽泛的技术需求文档进行了重新梳理，对技术需求进行了更加细致的描述和要求，包括：开发语言、安全性、稳定性、可用性、易用性、可伸缩性、网络要求、软硬件要求等等， 详细到最高能支持多少TPS并发、页面响应时间的最高的毫秒数都做了更加细致的量化要求。
我在上面项目生命周期类型选取中讲到采取混合型的开发生命周期。
因为我们基于预测的计划给到采购需求范围，但基于Scrum敏捷框架积极拥抱需求变化，，在未来几个Sprint冲刺后必然会出现需求变更，导致采购环节的需求范围和实际开发的内容不一致，这在采购和审计环节是一件可大可小事，总归来说不是一件好事。
Action行动：
老老实实的收到研读公司的采购制度，严格做好需求变更管理。
在技术开发合作中，甲方与乙方间不仅仅是下需求然后开发交付这么简单。无论是内部业务方、内部开发、采购、法务甚至是客服，如果有任何一方对服务商产生负面情绪，都是一件非常麻烦的事情。
我们项目在进行的过程中，业务方对服务商的问题处理速度出现不满，最后的结果演变成对服务商极度缺乏信心，提出要更换服务商。
经过几个月漫长的服务商招标、甄选等环节，成功更换了新的服务商。不久之后，IT团队又开始对新服务商的开发质量出现不满，又提出要更换服务商，来来回回，服务商的频繁变动，给项目带来很多负面的影响，比如说：
Action行动：
这其中涉及的原因可能有很多，在这里我只分享一个最基本有效的行动，建立起良好的沟通：
首先，确保最基本的沟通顺畅。建立好项目沟通群，邀请各相关方加入，如果日常沟通信息较多，在项目沟通群的基础上，再进一步建立细分的小群。例如需求沟通群、故障缺陷群等等，确保沟通的高效。
其次，建立服务商的汇报机制。我让供应商的项目经理，每周通过邮件的方式进行一次项目进度报告，发送给所有相关方，确保项目进度信息的同步，加强了对服务商的监督。
最后，促进多方高层之间的沟通。高层级的沟通对推动项目稳健发展尤为重要，至少每个季度召开一次阶段性的项目成果汇报会议，如果有特别关键的里程碑可以额外增加。项目成果汇报会议邀请服务商的高层和我司各相关部门的高层领导参加，共同检阅，提升领导们对项目的认可度。
项目刚开始的时候，公司的各个产品/系统东一个西一个，整体软件产品系统架构特别混乱。
如果业务方的某个需求涉及跨系统数据对接，在需求分析阶段的沟通成本巨高。
先是要分别向公司老同事打听各系统负责人，再分别找对应的系统负责人沟通。有时各部门对同一个系统名称的口径还不统一，鸡同鸭讲眼碌碌。
Action行动：
我们开发的SCRM平台里有一个核心的功能叫做“顾客档案”，用于给销售人员记录并展示自己跟进的客户信息。
首先，针对内部沟通的问题，我也建立了自己在公司内部沟通的同事档案。包括同事姓名、所属部门、负责哪个产品/系统、这样下次需要对接时就可以查阅档案快速找到对应的负责人。并基于这份档案，逐步建立起自己对于公司整体系统框架的理解和认识。
其次，要积极向上管理，不断和公司管理层反馈这个问题，拿着同事档案给管理层提建议。后面领导逐步意识到了这个问题，牵头成立了架构委员会，梳理出整体的系统架构字典，包括前中后台的各个产品模块、统一系统口径名称和负责人。
架构委员会也同步制定了详细的管理规范，包括新产品上线前需要进行架构评审、接口评审、安全评审等等。每个环节的评审都会延长上线时间，在需求分析阶段需要提前做好更全面的评估。
项目管理能力、需求分析能力、沟通能力、技术思维和向上管理都是产品经理需要不断打磨的基本功。
长期来看，通过对过往工作的复盘思考，关注有效的行动，提炼出自己工作的原则和方法是提升自我的关键。
本文由 @Jack 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。