产品交付发展过程

笔者所在的业务团队恰好处于高速发展的B端业务团队，为了更加“快速”的传递价值，无论是产品交付过程还是内部的协作链路，都经历过或者正在经历一些典型的“阵痛”，因此借笔者所经历的一些经验和教训在此文中阐述一二。

B端产品与C端产品有着比较大的区别在于，B端产品的需求容易走向 定向渠道 ，即某一类客户或者某一个客户提出来的需求，这对产品经理识别需求和过滤需求的能力要求就会不断变高。同时在B端的业务线中，业务决策链或者协作重要干系人的差异也很明显，比如：销售和客户就会成为影响我们内部决策的重要影响因素。

然而，在互联网的产品发展过程中，唯快不破，我们的终端用户无论是企业还是个人都对于“快速交付”会有着越来越高的诉求。

首先，我们要确定的是： 我们交付的是什么？

作为B端业务产品，一次成功的交付必须以客户所见为标准，即需求不是只存在于我们产品经理的构想中，而有可能来源于客户现场的调研或者是同类竞品的分析过程。如果一个需求产出经历研发上线之后，客户根本用不起来，那也可以称其为不是一个成功的交付，这就意味着我们后续还需为此付出较多的迭代成本。

从产品发展的沿革过程来看，我们大致经历了以下几个阶段：

1. 产品起步阶段
2. 产品发展期
3. 大客户时代

一、产品起步阶段

毫无疑问，任何一个产品在起步阶段的最重要问题是要搞清楚“我是谁”、“我在哪里”、“我即将去向哪里”， 因此我们更多在摸索产品从0到1的建设阶段。此时更多的是遵循Workshop的开发模式，按照业务的形态区分，大概会持续3-6个月时间不等，直到我们可以生产出第一个具备完整形态的0.1版本。

在这个过程中遵循以下几个原则：

• 快 ：以最快速或者集中开发的形式进行版本交付，甚至不用care一个版本的周期具体时长，可以按照每一个功能点的滚动交付为完成的依据，不停的完善版本功能；
• 准 ：产品经理除了需要梳理功能点，还需要明确我们最小MVP 版本的完整路径，梳理产品的roadmap；
• 狠 ：快速的收集市场或者种子用户的反馈，分析与竞品的差距。

二、产品发展期

什么是产品发展期？

当产品形态逐渐稳定，需要抢占市场份额时，会主攻追赶核心功能——我们一般可以将这个阶段定义为发展阶段。

在这个阶段，我们的团队和产品一般会具备如下几个特征：

1. 因为要追赶竞品的某些核心功能，版本的周期倾向于较短；
2. 销售、售前、服务的团队配备逐渐健全，信息收敛的速度变慢；
3. 团队的整体意识遭遇B端市场的冲击加大。

由于团队规模的不断壮大，团队建制不断完整，各种角色产生信息的速率上升，而信息收敛的速率会下降，尤为典型的就是需求的采集过程。

大家会发现，我们在这个阶段的需求来源不断增多，如：产品经理自生的需求池，销售反馈的需求池以及服务在售前售后过程中获取的需求范围，稍不注意就会信息爆棚。因此产品团队在此刻需要运用 工具 化手段管理需求渠道，并且逐渐依赖比较严格的需求管理标准，否则即使是需求管理的过程都容易造成瓶颈。

不难发现，“客户数量上升”是在这个阶段非常典型的特征之一。客户数量增加了，版本覆盖需求范围更广，而客户依赖的交付管理也会逐渐呈个性化趋势。

因为B端产品不同于C端产品，C端产品可以很好的自我控制产品交付的时间和周期，而B端的用户却是非常容易提出比较独立且分散的期望交付时间，然而这也是符合B端市场发展的诉求的。

因为企业不同于个体，虽然我们提供的是SaaS平台的服务，而对企业而言，它期望获得的每一个产品收益也是符合它自身发展路径的，“时间”就会变成我们的不可变量。

当我们意识到这一点时，就需要相应的调整我们自身的版本交付规划，如：

1. 重在响应： 产品作为售前资源，充分考量和评估销售侧、服务侧的需求；快速响应前向团队；
2. 版本弹性： 虽然周期不固定，但基本维持在较短时间范围内；同时允许某些客户的需求弹性上线。

这非常符合我在团队内推崇的“响应力”over “效率”的产品交付模型，而我们也确实在很长一段时间内都享受着这种模型给我们带来的“福利”。因为看起来，每一个提出特殊要求的客户无论是申通还是顺丰，我们在进行数轮的需求调研和评审之后，都会尽量满足他们各自的上线时间要求，看起来——似乎一切都很完美，直到我们大客户时代的真正来临。

三、大客户时代

什么是大客户时代？

按照我们业务规划的定义，它可以帮助我们提升客单价，也帮助我们不断的聚焦于某一些行业或者某几类客户。然而，随着大客户数量的不断增多，我们也很快就遭遇了瓶颈，如下图：

因为我们不断的允许大客户需求的临时插入和临时上线，所以我们可以将此图命名为：一条生产线上的崩溃。 当我们的大客户需求还可以被尽量收敛时，我们认为团队资源和大家原本已经熟悉的研发模式是可以帮助我们顺利度过的。

因此大家一拍脑袋，设计了这样一个我们原本以为可以称之为“美好“的新模式：

如上图，大家天真的以为将每一个中途进入的大客户并行排布，就可以以此来拉伸原有主版本的交付周期。

然而事实证明，它们不但不可以完美的并行开发，团队在研发过程中还会付出远超出于需求本身的沟通成本和代码管理的成本，以至于我们在曾经经历过的一个版本中，会发现缺陷的收敛趋势变慢、版本后期的风险也几乎无法收敛，导致我们不得不采取最后的防御措施来控制版本上线日的风险。

同时，我们在整个迭代周期中，因为响应不同客户的不停上线也为自己带来了不可控制的风险，因为每一次线上变更需要花费的风险控制成本趋势也是在逐渐上升的。

综上所述，我们在这样一个为了响应“所有”大客户而设计的产品研发过程基本可以论述为“瀑布式交付是如何诞生的”。同时，我们的团队内还带来了很多的次生灾害，因为无法完美的交付给团队带来的不自信、团队的焦虑、以及不同角色间发生冲突的概率也随之上升。

因此，我们必须要快速的采取行动了，否则将无法控制事态的发展。

如上图所示，客户虽然都是重要的， 但不应该将每一个客户都定义为紧急的，甚至是同等重要的。因为客户本身的需求极容易对我们的产品过程造成冲击， 因此客户的分级也就需要去进行推算，通过一定的客户等级概念来决定哪一些客户的需求可以成为紧急的，就如同每一个需求本身都应该对应一个优先级一样。

另外，我们强行固定版本的交付周期，如现在的3周一迭代，看起来我们可以做的需求规模肯定会比原来的少，但却可以保障部分客户的需求可以优先且准时的交付，这对管理客户预期来说是一个利好的消息。同时也会让我们的产品和研发团队的规划，以及相应的工作更加的有节奏感，明确的知道自己的交付标准和完成度应该是多少。

只有当我们客观的解决了客户的问题，以及摆在我们面前现实的痛点后，才可以从本质上去缓解协作团队间的冲突，因为大家的最终诉求是一致的，即： 满足客户诉求，提升客户的满意度。

作者：夏力云，网易资深项目经理，PMP，曾在传统软件行业具有多年项目管理经验。

本文由 @网易杭研项目管理（微信公众号：NetEasePM） 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。