如何接手数据产品（1）：找到业务的利益相关者（key stakeholder）

Stanley 2023-07-22 02:57:13

背景

数据产品经理在实际工作中需要支持不同的业务线，这其中存在着很大的业务隔离。

然而由于各种原因，比如公司的组织结构变动，人事变动或者个人的职能变化，公司和团队会要求产品经理们快速接手一些新的业务数据。

那么如何能够快速的了解自己所不熟悉的产品业务并保证最小程度上影响产品交付，这对产品经理来讲是一个非常大的挑战。

笔者希望分享个人最近的经验，来分享一些实操过程中碰到的问题以及解决方法。希望能够帮助大家快速将一个看似杂乱无章的新的业务数据产品，进行结构化的梳理并快速接手并建立高效的工作模型。

01 谁是key stakeholder（利益相关者）？

作为数据产品经理接手新的业务时，首先你需要知谁是你的stakeholder。把这个问题搞清楚了之后，你其实已经完成了50%的业务交接。因为只要清楚你的客户是谁，其实就锁定了你的范围。

这点很重要因为这个业务是从别的负责人转给交给你，那么他一定已经建立了一个较为稳定的合作伙伴，那么你需要快速的找到这个原负责人，并将他的知识储备进行转移。其中需要快速搞清楚以下几个事情：

这种情况实际上为最优的解决方案，原业务负责人的存在会给你流出充足的适应期，保证你在接手业务的时候可以得到足够的背景和知识储备支持。同时，最好要求原业务负责人发一封变更通知，这会帮助stakeholder快速和你建立关系，以便接下来工作的开展。

如果原负责人已经离职，那么在完全没有背景的情况下，所有的情况将变得复杂的多。

笔者这次的情况就是原业务负责人和原开发团队已经全部离职，笔者接手的时候发现原有的所有连接已经断开，需要重新来构建合作模型。

下面介绍了在这种情况下笔者如何获取所需要的信息完成业务梳理：

你需要获得新的开发团队的大力支持。通过接手已有的产品，尽快理清产品线。这点非常重要，因为如果原团队的代码维护得当，从开发代码中以及维护历史中可以得到大量的线索，并猜测重要的产品。
快速掌握已有产品并了解其核心价值。这点无需赘言，每个经理都需要先了解自己已有的产品。
寻找原负责人的邮件，查看收件人并提取可能stakeholder列表。这点在实际操作中帮助笔者以最快的速度，确定了第一轮的会议列表。笔者通过原同事的离职邮件，寻找到了非本组的同事，将其所有人的只能部门于产品进行交叉比对，锁定了第一轮的接洽以及主题。事实证明，这个在非常大的程度上帮助我们锁定了主要的合作伙伴。

会议，笔者在完成上述三项后，很快的和主要的stakeholder开始了第一轮会议，笔者的主要问题会包括：

介绍本部门的变化
了解其所在部门业务
了解过去的合作模式
了解本部门的业务需求
管理好用户的期望以及确认最高优先级（这点非常重要，因为在接下里的2-3个星期，团队的所有侧重都会在熟悉接手已有产品，产品经理很重要的职责是告知相关方接下来的产出会受到影响）
咨询是否已知其他stakeholders （很多时候，需求的stakeholder可能为多个人，而了解到这些人很大程度会帮助你安排接下来的会议）
下一步计划（笔者在这里不建议在第一次会议室就确定合作模式，因为当你没有一个完整的业务理解的时候，过多的承诺合作会导致过量的会议，很大程度的影响你的工作并吃掉你的资源。这里建议承诺一次性的follow up meeting，时间大概在2-3 周后，因为那时你会有更好的业务理解并定义合理的合作模式）
文档分享（年度计划，业务介绍，过去的邮件等）

整理并理解本团队核心价值，并确认下一步计划。 完成第一轮的会议后，笔者了解到stakeholders的需求会有很大程度的重叠，理解后发现需求会落入横向的基础支持以及纵向的业务专门支持两个维度。而这个模型实际上会有很大的扩展可能，所以有和更多的业务方团队进行沟通的必要。

扩大会议。笔者通过于第一批用户进行沟通后，锁定了未在名单上的更多参会者，对只能的解读和产品的匹配，确定下一批会议的参会着名单。于是重复上两步的操作，直到完成了所有的产品矩阵和核心stakeholder的匹配。

收敛 x 高效。在完成了对主要的stakeholder的收集后，需要确定接下来的产品方向以及合作模式。笔者最近经历的这个case有15+主要的合作伙伴，如何能高效的管理关系并实现已有资源的产出最大化而不是迷失在海量的需求中，这个会在下一篇文章中讲到。