基于业务闭环，设计产品迭代规划

毋庸置疑，产品迭代是产品生命中非常重要的一环，好的产品迭代，能够让产品结合市场、用户需求等因素达成进一步优化，达到延长产品生命周期，甚至成为一款优秀产品。

产品迭代是一个在有限的资源背景下，最优的以产品解决客户业务需求的持续性过程。

在产品的生命周期中，规划产品的迭代方案是非常重要的一环。基于迭代开发互联网产品，是当前互联网产品开发模式中非常高效的一种，并能够发挥优势找到产品和市场匹配点（PMF）。

在以迭代开发产品时，一般都会做长远迭代规划，至少2~3个版本。

对于B端产品，通常规划更为长远，可能在产品立项之初，就已经规划出了产品的整个生命周期和发展演变走向。

对于B端产品，长远的迭代规划是非常有必要的。B端产品都是基于业务的，如果没有长远的迭代规划，必然导致产品功能的变动，这样很难保证产品与业务的契合。

对于B端产品，迭代就是将业务对应的产品，切成一块一块的；然后依据时间，一段一段的完成产品的开发。

那么怎么才能「一块一块」和「一段一段」的最优？既能迅速满足客户的业务需求，又能达到资源的高效利用呢？

这就需要在产品设计的初级，设计优秀的产品迭代规划方案。再通过迭代方案，来指导产品的开发过程。

本文以医美医院的管理系统举例，讲解如何做B端产品的的迭代规划。当然，某些内容是可以更加深入探究的，本文的主要作用是把整个公式化方法展示出来。

B端产品的迭代规划设计方法，是以实现业务闭环为目标，即先建立核心可用业务，再逐步扩展到整个业务流程，直至完成业务闭环。

类似C端产品的MVP产品思路，都是规划产品时由小到大，由核心辐射周边。不同的是，MVP强调在快速迭代的过程中，根据产品的反馈调整产品的方向；而基于业务闭环的迭代规划，更强调由核心业务向整个业务拓展，业务的方向和规划，一定是明确和可靠的。

制定以业务闭环为目标的迭代规划，主要分为四个步骤：

1. 1. 整体业务流程分析
   1. 核心业务分析
   2. 子业务分析
   3. 设计迭代规划

一、整体业务流程分析

以本文的医美医院管理系统为例，分析并整理出如下的业务流程图。

在整理业务流程图时，整个过程就是分析客户的业务流程。对业务流程分析的准确性，对于产品的开发至关重要。

在业务流程分析时，我们可以进行用户调研、用户访谈，甚至于亲身去参与客户的业务，进行轮岗。

二、核心业务分析

在完成业务流程分析后，我们需要分析出客户的核心业务。核心业务，可能是业务流程中的业务，也可能是隐藏在业务流程之下，支持整个业务运转的系统。

在分析核心业务时，有几个简单的标准。

• 业务各角色普遍参与的业务
• 该业务直接关系产品的核心价值
• 该业务与其它业务都要进行密集的交互
• 在业务序列图中，交互最密集的业务

根据例子所展示的业务流程图，不能确定哪块业务是核心业务；但是可以发现，「患者」这个角色一直贯穿业务流程，并且「患者」也是产品的核心价值。

所以，针对「患者」肯定需要设计一个客户管理系统。大部分的业务都需要依赖客户管理系统。这样可以分析出，整个产品业务的核心是客户管理。

在分析核心业务时，还有一些比较简单直接的方法：

一是核心角色相关的业务，通常都是核心业务；比如本例子系统，就是以患者客户为核心角色。

再则，我们做需求分析是时，通常都会分析需求的优先级。高优先级关联的业务，通常也是核心业务。

三、子业务分析

分析核心业务后，我们首先需要分析各子业务间的关系。在分析时，我们可以使用辐射图来直观的呈现各子业务的关系。辐射图的中心是核心业务「客户管理」。

子业务间的关系，我们可以分为依赖、关联和支撑。

依赖表示该业务是另一业务的基础，关联表示子业务需要协同工作，支撑表示该业务是另一业务的基础。

在分析业务关系时，还要分析出一些基础的支持系统，比如，权限管理、架构管理等。

分析完子业务间的关系后，我们需要针对各子业务进行单独的分析。主要是分析各子业务研发成系统、所需要投入的资源、研发的周期、投入产出回报比（ROI）、参与的角色和客户的期望。

分析后，我们需要将这些内容，整理成表格，以便直观的分析。

估计投入资源时，一定要做到定量，比如最简单的就是投入多少人员。ROI需要结合功能的预期收益或报价来评估，本文例子中简单以高中低三个等级来表示。客户的期望也需要进行量化，量化客户期望是比较复杂的，本文简单以「希望多久上线」来进行量化。

本文例子整理的表格如下：

同时，我们也可以参考，在设计产品架构时，设计的产品架构图。

四、设计迭代规划

在分析完各个子业务后，可以正式开始设计迭代规划了。设计迭代规划时，都要参考上面分析的结果。那具体如何设计呢？

业务闭环，当然是以核心业务出发，优先选择业务流程中较近的业务，优先选择能串联的业务。保证在核心业务需求可用的基础上，逐步向整个业务拓展，直至闭环。同时，也可以参考以下的原则，作为判断依据和补充。

1. 架构中底层业务第一次迭代必须，基础业务优先考虑。
2. 核心业务在第一次迭代必须。
3. 辐射图中，辐射出射线最多的业务优先考虑。
4. 业务流程中，越靠前越靠近主干流程越优先。
5. 综合考虑业务系统间关联关系和ROI等数据综合分析。优先考虑用户期望高、ROI高的、业务参与角色多的。

在设计迭代规划时，我们还要根据整体的时间节点，确定迭代的版本数。

比如，本文例子如果开发周期是四个月，结合业务的特点，将迭代版本数定位为三个版本。

当然，具体的迭代版本数，可以根据具体的开发场景确定，不一定一定要迭代多少版本。

在本例中，第一个版本完成核心基础框架和核心业务客户管理；第二个版本完成客户在客户拓展到产生订单到关系维护的整个业务流程；第三个版本完成医院提供客户服务的业务，以达到完成整个客户在医院的业务闭环的目标。

在设计版本迭代规划时，我们可以用图进行直观的表示。本文例子设计的迭代规划如下：

在完成迭代规划后，产品经理还需要将其细化成里程碑计划。里程碑计划更多的关系到项目管理，不是本文的重点，就不多分析了。

一些思考

在进行迭代规划时，作为产品经理需要合理划分业务，确保每个迭代在合理的时间段完成，确保每个迭代中产品的质量。

做好迭代规划后，应该立刻召开评审会议，完成迭代节点的排期，并设计好里程碑计划。

在迭代规划设计时，对于产品经理，核心是通过迭代来覆盖业务，完成业务的闭环。对于业务方来说，迭代的目的是为了快速满足核心业务需求。所以在做迭代规划时，必须要要摸清业务方的需求期望。

作者：产品小思考，B端产品经理，微信公众号：产品小思考

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

题图来自Unsplash，基于CC0协议

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: