关于B端产品开拓项目的「复盘思虑」

文章目录 [+]

一、为什么要做复盘？1. 复盘是绩效提升的关键一环

我认为复盘是 PDCA 戴明环里最主要的一环，对操持P和实行D进行检讨C，输出处理行动A，让我们的事情形成持续优化的循环，提升事情的绩效。

关于B端产品开拓项目的「复盘思虑」关于B端产品开拓项目的「复盘思虑」互联通信

如果我们只是一直的做操持，实行操持，短缺了对事情的复盘，就很随意马虎陷入一种低效的劳碌，无法提炼出精良实践履历来辅导未来的行动。

（图片来自网络侵删）

2. 复盘是个人发展的关联路径

复盘是个人或团队对事宜或项目，进行回顾、反思、重构的构造化的学习过程。

在复盘的过程中，我们从实践中反思履历，剖析成功和失落败的关键，总结出规律进而形成个人履历，提炼出高度抽象的方法论，进而提升我们办理问题的能力。

在《远见》一书中，开篇就提到“可迁移技能”是三大职场燃料之一，而办理问题的能力是能让你与他人拉开差距的可迁移技能。

二、详细项目实践中的复盘思考1. 项目应选取什么样的生命周期类型？

多年前，我所在的公司是一祖传统制造业企业，操持引入一款SCRM Saas产品进行私有化支配，并基于乙方公司标品的底层能力，进行深度的定制化开拓，接入公司现有系统，以便于更好的知足业务团队个性化的需求。

由于当时公司还处于数字化转型的低级阶段，公司的IT采购流程哀求必须须要给采购部门供应详细并且明确的采购需求解释书，遵照严格的预算掌握。

这给我们的新产品开拓带来了很大的难度，由于这个时候项目才刚成立，大家都不知道详细该当怎么做，业务方给到我们的需求也是非常笼统的，好在公司财大气粗预算充足。
我只好硬着头皮，将宽泛空洞的需求解释书只管即便描述清楚，在采购巨大的寻衅下完成了采购流程。

第一期产品耗时整整3个月才完成开拓上线，功能上线后，业务方的运营重心已经开始转变，已上线的功能代价远不如提需求时的高。
其次业务方还提出了大量的优化需求，当前功能已不符合当下的业务场景。

后面通过对项目管理的系统性学习，我逐步理解到，在项目管理中将项目的开拓生命周期可分为预测型、敏捷型、迭代型、增量型，或者多种类型结合的稠浊型。

传统制造业企业更关注操持，按照采购的哀求，明显是哀求我们项目的开拓生命周期采纳预测型，这确实也符合企业过往的业务流程，但在互联网产品上就明显不适用了，由于IT产品的有着非常强的灵巧性，需求的变革调度也是非常高频，在互联网公司，基本都采纳增量型或是敏捷开拓的模式。

Action行动：

为此，第二期的开拓我提出采纳稠浊型的项目管理方案。
采购层面仍旧采取预测型，将可能涉及到的需求范围只管即便描述完全。
而开拓层面采纳敏捷项目管理的Scrum 框架，每3周一个Sprint冲刺。

经由这样的调度：

首先，产品功能代价得到了大幅提升。
业务方提出的需求，可以保障3周内完成MVP的上线，业务方可以尽快用起来了。

其次，能更好地应对频繁的需求变革。
在冲刺期间内不做需求变更，业务方提出的新需求，评估可行后统一放到未来的 Sprint 进行开拓，由于3周的韶光比拟过往3个月灵巧很多，可以更好地贴合业务侧的各种调度。

2. 收到业务需求后该当做什么？

最近看到一个段子，产品经理去口试，口试官问收到业务需求后该当做什么，产品经理回答进行需求剖析，结果直接被淘汰。
口试官给出的答案是要先看谁提出的，如果是老板提出的直接开始做。

看似是个段子，但是也确实反响了当时我们公司和其他很多公司产品经理的现状。

当老板创造我们效率提升后，哀求我们将一个 Sprint冲刺缩短到2周，并也开始给我们提出新需求。
当业务侧创造我们的开拓效率提升后，也开始给我们提出更多的需求。

随着一个又一个迭代的上线，功能越来越多，也开始涌现一些功能，提出需求的时候非常急，但上线了又没人利用的情形。
这让我开始反思，在需求剖析环节，是不是还没真正做到位。

Action行动：

我和团队基于需求文档，对已上线的功能，进行了系统性的复盘，共同输出了需求剖析的灵魂7问：

您的落地场景是什么？您要达成的业务目标和要办理的问题是什么？利用这个功能的主体和工具是谁？上线之后如何验证效果？假设功能上线了，您会怎么推广这个功能让用户利用？配套的运营职员是谁？有哪些额外资源支持？

之后无论是谁提出需求，都要先和我共同完成这灵魂七问。
能够清晰回答出这七个问题，最最少是一个经由负责思考的需求，后续再根据回答进行需求代价剖析、定义优先级，让我们的产品功能更加集中在办理核心业务问题上。
后续我们还在此根本上迭代更加系统的需求网络表，帮助我们更好地进行产品方案和资源评估。

3. 产品经理要持续提升技能思维

第一期的SCRM平台开拓项目，基于做事商通过PHP措辞开拓的标品Saas，由做事商供应PHP开拓职员进行定制化开拓。

而我司内部的开拓团队只有Java的开拓职员，并没有PHP的开拓和运维资源，这就意味着未来做事商质保结束后，我们的开拓团队还须要新增额外的PHP开拓资源来专门进行这一个别系的运维。
其次便是在一期产品上线后，涌现常用功能页面加载速率明显过慢的情形。

涌现这个问题，一是我作为产品经理在评估技能需求时过度依赖开拓团队，没能更进一步多考虑下技能层面的内容。
二是在项目初期，内部开拓团队职员较为混乱，核心成员操持离职，没有从技能层面进行更长远的方案。

Action行动：

首先，从第二期互助开始，我与内部开拓团队建立共识，哀求做事商全部基于Java措辞进行开拓，并将第一期的内容进行Java重构。
这里其实走了一些弯路，但我也问了一些做开拓测试的朋友，说这种代码重构项目他们公司也很常见。

其次，我与开拓团队将之前过于宽泛的技能需求文档进行了重新梳理，对技能需求进行了更加细致的描述和哀求，包括：开拓措辞、安全性、稳定性、可用性、易用性、可伸缩性、网络哀求、软硬件哀求等等，详细到最高能支持多少TPS并发、页面相应韶光的最高的毫秒数都做了更加细致的量化哀求。

末了，我还针对易用性，输出了B端系统设计规范，例如规范非常报错的交互和提示文案。
这里我非常推举酸梅干超人的电话亭的《B端设计规范搭建全流程讲解》，非常适宜B端产品新人快速提升产品设计能力。

4. 涌现需求的变更该当怎么办？

我在上面项目生命周期类型选取中讲到采纳稠浊型的开拓生命周期。

由于我们基于预测的操持给到采购需求范围，但基于Scrum敏捷框架积极拥抱需求变革，，在未来几个Sprint冲刺后一定会涌现需求变更，导致采购环节的需求范围和实际开拓的内容不一致，这在采购和审计环节是一件可大可小事，总归来说不是一件好事。

Action行动：

老诚笃实的收到研读公司的采购制度，严格做好需求变更管理。

记录：谁在什么韶光点提出的、为什么要变更，让变更发起方发起变更邮件，产品经理记录在需求网络表中，做好留痕。
评估：结合上文提到的需求剖析方法，评估需求变更带来的影响，确定做还是不做。
如果做，结合优先级的高低，放到接下来哪个Sprint冲刺中。
提交：在项目管理流程中，变更须要提交给到CCB（变更掌握委员会）或是PMO(项目管理办公室)进行批准，由于我们公司当时这两个职能都没有，直接给到老板和采购确认审核即可。
更新：在需求网络表中更新这条变更需求的结果和状态关照：涉及该需求的干系方都要做好知会，包括需求方、开拓、采购、做事商等等。

5. 如何保持各个干系方之间的良好沟通？

在技能开拓互助中，甲方与乙方间不仅仅是下需求然后开拓交付这么大略。
无论是内部业务方、内部开拓、采购、法务乃至是客服，如果有任何一方对做事商产生负面感情，都是一件非常麻烦的事情。

我们项目在进行的过程中，业务方对做事商的问题处理速率涌现不满，末了的结果演化成对做事商极度缺少信心，提出要改换做事商。

经由几个月漫长的做事商招标、甄选等环节，成功改换了新的做事商。
不久之后，IT团队又开始对新做事商的开拓质量涌现不满，又提出要改换做事商，交往返回，做事商的频繁变动，给项目带来很多负面的影响，比如说：

做事商感想熏染到不受信赖和打压，在互助末期会显著降落交付质量和做事质量；项目成员的变动须要重新进行业务知识培训，尤其是公司的业务规则特殊繁芜时，沟通本钱会变得非常高。

Action行动：

这个中涉及的缘故原由可能有很多，在这里我只分享一个最基本有效的行动，建立起良好的沟通：

首先，确保最基本的沟畅通畅。
建立好项目沟通群，约请各干系方加入，如果日常沟通信息较多，在项目沟通群的根本上，再进一步建立细分的小群。
例如需求沟通群、故障毛病群等等，确保沟通的高效。

其次，建立做事商的申报请示机制。
我让供应商的项目经理，每周通过邮件的办法进行一次项目进度报告，发送给所有干系方，确保项目进度信息的同步，加强了对做事商的监督。

末了，促进多方高层之间的沟通。
高层级的沟通对推动项目稳健发展尤为主要，至少每个季度召开一次阶段性的项目成果申报请示会议，如果有特殊关键的里程碑可以额外增加。
项目成果申报请示会议约请做事商的高层和我司各干系部门的高层领导参加，共同校阅阅兵，提升领导们对项目的认可度。

6. 跨系统数据对接，不熟习公司整体系统框架怎么办？

项目刚开始的时候，公司的各个产品/系统东一个西一个，整体软件产品系统架构特殊混乱。