如何接手数据产品（2）：Do it Smart

当数据产品经理突然通知接手一个新的业务， 那么如何能够快速的上手并建立起工作模型呢？这篇文章**继续深入探讨。

01 建立工作模型

当产品经理找到了主要的stakeholder之后，接下来的就是建立一个有效的合作模式（engage model）。

笔者公司是核心业务是互联网电商，公司内部推行的工作框架是自上而下的V2MOM计划模型和敏捷开发模型。

在这种环境下，对于PM来说，快速熟悉所对应业务的年度计划并快速的建起来适合高效的合作模式可以为之后的工作打下坚实的基础，可以少趟很多坑，接下来我**根据自身经验，介绍一下笔者在这次实际操作中是如何完成对外和对内的框架搭建。

在进行下面的分享前，先对齐一下概念，简单介绍一下笔者公司的两款工作模型。

1. V2MOM模型

V2MOM分别代表愿景（vision）、价值（values）、方法（methods）、障碍（obstacles）、衡量指标（measurement）。

公司层面**在每年进行一次年度计划， 自上而下对现有问题的展开分析从而制定明年公司的多个愿景（vision）并确定愿景所量化产生的价值（value），公司的目标自上而下将**分配在每条业务线并形成基于高度而不断细分的方法（Method），笔者公司为2级， M1 公司层面，M2业务部门, scope从大到小。

交付团队需要每个M2进行基于V2MOM框架的详细的价值阐述，将M2分解成可落地的M3并写出已有Obstacle和最终的衡量指标。完成后，进行逐级向上的横向评估，最终完成公司具体的项目筛选，并完成资源分配。

2. 敏捷开发 – Scrum 网络上的内容很多， 大家可以自己搜索

（图**源于百度百科）

3. 对外面向客户 : 业务 – 计划 – 需求 – 目标 – 回顾

对于每个团队来说，在完成了年度计划后，一年的工作重心**围绕重点项目以保证能够交付所计划的产品和完成目标， 与之对接的数据产品经理需要了解核心stakeholder的M2和M3，理解其今年需要每个产品交付的核心需求以及核心的成功指标（success metrics). 这个可以很好的帮助PM解释所有客户产品的深层次需求，笔者一直认为单纯的从数据推演的价值是有限的，而目标导向的数据才能萃取出数据的价值。

那么在这些前提下， 产品经理需要完成以下几步而完成对业务的理解， 确认对团队的需求并了解设定目标。

1）启动**议 – 核心了解业务重点和实施计划

产品经理需要和stakeholder建立计划**议，用以了解业务方需求，这个**议上不需要谈及技术细节，主要了解业务内容和可能的合作模式。笔者的经验一般从以下几个问题引入主题。

• 核心业务介绍
• 今年的业务计划以及文档
• 今年的主要项目，开始和交付计划以及成功衡量指标
• 每个项目的主要的合作方以及职能介绍
• 可能的话需要产品的设计相关文档

2）设计定期审查**议模型（Regular Review）

定期审查**议的主要作用是和主要的stakeholder共同完成以下行为

• 建立需求列表
• 回顾上一个生产周期的交付
• 确认最新优先级，并承诺下一生产周期的交付计划

那么在真正于staekholder建立定期审查**议之前一定要慎重，产品经理需要认真的规划**议的架构以及期望目标。主要是有三个层面，

• 价值 – 这个**议的前提是双方有长期的合作价值，产品经理需要根据客户所在部门的年度计划理解对你的团队的需求程度来决定是用基于项目的**议框架还是需要设定regular review 来进行持续交付。
• 承诺 – 因为这个**议代表着和stakeholder建立一个长期的合作模型，用户**定期和你进行需求的审查并不断丰富需求列表，并可以定义需求列表的优先级。
• 效率 – 如果你对接的是一个比较大的组织，如笔者这次对接的需求来自于一个上千人的组织，已知的需求方来自10+个团队，假设每两周进行一次审查，这无疑对产品经理的大量时间将浪费在准备**议， 参加**议上。而对于独立产品经理来讲，你的效率将**成为团队产出的瓶颈。

基于以上的背景，笔者强烈建议需要将这个**议进行收敛，将需求向上整合，并建立基于大组织架构的的产品列表。下图为笔者的收敛过程。

Before – 笔者需要和以下所有的团队进行对接

After – 为笔者实际的**议仅为4个审查**议（绿色部分）

通过这种方法，笔者在实际工作中大大的提高了工作效率，节约了近60%的**议时间成本。要知道在笔者接收这个业务前，这个业务线一共有4个全职的产品经理，而笔者只有个人的50%的时间资源投入并预期完成同样的产出，所以笔者要保证**议的每一分钟都极度高效的。接下来笔者分享一下自己如何进行高效的**议。

3）启动定期审查**议

设计好**议框架后， 就要开始实际进行**议了。

**议建立

• 确定参**者 – 根据之前的业务了解，产品经理已经有能力选择需要合作的核心人物来参加这个定期审查**议。
• 搭建需求列表（backlog grooming） – 收集需求列表，通过协同工具或者邮件在**议开始前进行需求收集。并对每一个需求要进行了解，产品经理需要能够回答好这个需求的交付标准（DoD）究竟是什么，需求的负责人是谁以及有哪些相关方需要参与在这个项目中。

**前准备

• 需要清楚的把握上一个生产周期的具体产出，确认承诺的项目的最新进度，并对backlog进行更新。
• 需要列出所有影响项目产出的主要的问题和即将发生的隐患，这极为重要，因为你需要一方面管理stakeholder的预期并寻求他们的帮助。
• 了解新的需求并寻求开发的同事的帮助，帮助评估需求的开发量（t-shirt size), 这将给很大的信息在**议上完成对下一个生产周期的规划。
• 个人策略 – 你需要很了解业务方的重点，并准备好将对那些项目进行倾向性建议。这个策略主要是因为当你面对客户时，双方一定**存在概念不对齐，很多项目实际上是互相有依赖关系或者开发效率的最优次序，所以这些信息你需要准备好并在**上进行提案，站在用户的角度帮助他们实现交付最优。

开展**议

• 快速更新每一个项目的最新进展 – 10% time
• 阐述遇到的问题并确定有结果导向的**后行为， 需要客户帮助或者暂停项目等待 – 20%
• 横向对每个业务线进行需求梳理， 并对最高优先级需求进行一轮筛选 – 40%
• 对各业务部门的需求进行第二轮的横向评估，确定最终项目优先级输入 – 20%
• 对下个生产周期的项目进行评选并预计交付成果 – 10%

笔者想着重阐述一下c&d， 由于将需求进行向上收敛， 我们的**议实际上并不是面向一个单一的团队进行而是跨团队评估， 那么如何评估每个团队的需求并保证资源配置符合预期，笔者**

• 将每个团队的项目进行一轮筛选并提取最高优先级项目
• 进行第二轮的横向评估并完成优先级输入

这能最大程度保证优先级得到所有参**者的认同并完成资源配置。

**后总结

笔者强烈建议每一次**议需要写一封**议纪要（meeting minutes)， 这个**极大的提升**议的效果以及固化**议产出。

• 有助于概念对齐，有时候**议上的共识并不是100%，将结论记录下来可以帮助参**者对齐概念和DoD。
• 可供之后参考， 好记性不如烂笔头，记下来的东西可以方便以后查找并固化产出，非常便利。

在每次**议后产品经理需要花30 – 60 分钟对**议的内容进行消化并进行项目需求和交付标准的撰写。并准备交付到另一个闭环进行投产 – let’s do sprint。

4. 对内面向研发 : 需求列表输入 – 计划 – 生产 – 交付 & 回顾

当产品经理对外完成了backlog搭建后， 接下来就是完成和研发团队的高效工作模型。

笔者这次的场景比较特别，原产品和研发团队同时离开，并没有给足交接信息，这直接导致研发团队也面临着巨大的考验来接手项目并进行持续交付。那么笔者将介绍产品和研发团队是如何一起解决这个困境的。

资源分配调整 

首先所有人都应该确认一个事情， 就是在这段时间，最终要的一定保证已有的产品线没有问题，而对于已有产品的运维在这个阶段的成本将**远远**过平时，所有资源应该大量的倾斜于已有产品的运维。以下是笔者团队的的资源比例 –

•  缩减新需求资源投入比例 – 15%
•  增加维护的资源比例比例 – 85%

这个情况**随着时间逐渐平衡，以下为2个月后的资源分配

•  新需求 – 65%
•  运维 – 35%

预期为70% & 30%。

梳理现有产品线并建立技术文档

对现有的产品， 需要技术的同事快速通过项目代码分析而掌握整个产品的dataflow和架构，并产出文档。由于时间紧迫，前期可提供简图，这**快速帮助团队熟悉产品的产品的设计并确定主要的产品相关方。

这个时候，产品经理需要根据从stakeholder处掌握的产品重要性，并快速优先熟悉重要的产品线。

以上行为大概需要3个星期，这三个星期基本上是无法完成新项目交付的，产品经理需要对外确保客户的合理期望。

开始计划**议 – sprint meeting

经过三周后，团队已经熟悉了30%的核心产品，基本上覆盖了主要的服务人群，这个时候可以开始将工作重心开始向新需求进行倾斜。

笔者团队开始就是在这个时候开始进行每两周一次的sprint meeting. 具体的sprint的细节由于外部已经有很多文档， 笔者这里就不详述了。

基于业务的资源分配

由于笔者团队涵盖的数据较广，要求每个工程师熟悉所有的业务是不切实际的，那么我们需要将人员进行基于domain的分配。

由于在刚接手的时候团队其实并不知道合理的分配比例，我们团队的做法是先进行较为广泛的资源分割，在进行2-3 个sprint后，我们**搞清楚哪些业务的需求较大且与战略更匹配，那么我们**进行的人员在业务线的调整，大概两轮后人员的分配更加合理，产出也得到很大的优化。

总结

以上就是笔者基于个人经验的一个总结，这次的业务交接发生的很突然， 笔者团队临危受命，在人员缩减，完全没有交接的情况下，发挥了最大的“聪明才智”，广泛沟通，快速熟悉业务，并成功收敛成高效的合作模型，最终成功的在1个多月的时间里接手原来的业务并实现了较原团队更为高效的产出。

回顾整体资源变化：

• 研发 – 缩减20%
• 产品- 缩减75%
• 产出 – 120%相较于原团队产出（统计截止于接手后2个月）

笔者的踩过的雷能够给大家未来的工作一点帮助吧。

该文章主要为个人实践中的心得，如果有什么问题的话欢迎交流 pm_stanley@163.com。

作者：Stanley；邮箱： pm_stanley@163.com

本文由 @Stanley原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 unsplash，基于 CC0 协议

给作者打赏，鼓励TA抓紧创作！

**赏

4人打赏