编辑导读：产品经理在工作3—5年后，已经从纯执行方向升级到规划方向。但是，一些产品经理对于如何规划产品还是存在误区，经常出现规划不到位，执行阶段手忙脚乱等情况。本文作者从自身工作经验出发，给3-5年产品经理提出一些产品规划的建议，与你分享。

3－5年产品经理，如果成长速度平稳，往往已经从纯执行升级，开始负责给系统或者独立模块进行规划。但就观察发现，大部分同学因为缺失有效指导和方法，经常出现规划不到位，执行阶段手忙脚乱，或者把规划搞成愿望清单，罗列不具备执行价值的通用规划。一个令人不安的现象是，这样的无效规划，在高阶产品中也屡见不鲜。

基于此，希望和大家分享一些做B端系统规划的方法。这些方法不为大而全，只希望帮助3－5年产品同学快速上手，做出实用的系统规划。

一、B端系统规划的4个步骤

1. 明确系统定位

做规划，首先要明确自己负责系统/模块的定位，这样才知道我们在给什么做规划。所谓明确定位，本质是思考，我们负责的系统，长期在为企业解决什么问题，满足什么需求。

这里的“满足什么需求”，要非常明确，不能是泛泛的，比如“给公司降本提效用的”这种没用的话。没错，就B端系统而言，通常的作用，是通过信息化的方式，提高企业内部管理或者服务流程的效率。但具体到系统，比如商品管理系统，我们要明确，这个系统的定位，是通过信息化商品信息的方式，提高企业管理商品的效率。比如订单系统，是通过信息化交易过程，达到交易效率和交易体验提升的目的。

也许你的系统在解决之外的问题，没有关系，只是要注意，在思考定位的时候，要站在【企业】【长期】对的需求去想——想想如果没有这个系统，企业会出现什么问题罢。

除了空泛定位之外，也不要搞短期定位，也就是站在短期项目、短期业务需求的角度去思考定位，这样很容易把系统定位变成写项目目标——我们的屁股要坐在系统负责人的位子上。

同时，随着我们的理解加深和职责变化，系统的定位是动态变化的。建议大家每个Q，或者每次业务方向变动的时候，都重新思考一下自己系统的定位。

2. 梳理系统现状

确定定位后，我们要梳理一遍系统和系统功能的现状，功能现状代表着我们作为一个生产车间，能生产的设备是什么，设备的生产能力怎么样。掌握现状，我们才能在新的需求到来时，确定是否要新添设备，或者改造已有设备。

梳理功能现状，我们可以从两个问题进行：

1. 我负责的系统，都有什么模块？
2. 每个模块的运作状态怎么样？

模块的状态，意味着该模块是临时搭建的，还是由合理产品方案组成的。临时搭建的模块，通常是写死、耦合的逻辑，灵活性、稳定性、拓展性都比较差。当然，即使是运作良好的模块，经过长时间需求的冲刷，也会老化，等待重构。在这里我们不用心急，梳理现状时，对每个模块当前的运作状态了如指掌即可。

我们可以通过一张系统框架图，来清晰表达系统模块的现状，框架图上，需要说明当前在运作的系统/功能，以及各自的运作状态。

下图是一个订单系统框架的简单示意。从图上我们可以看出，该订单系统处在早期阶段，仅有7个模块，其中订单创建和订单状态机是两个临时搭建的模块，有可能下一次需求到来，我们就要进行改造。

3. 明确业务发展趋势

当我们明确了定位和现状后，可以着手分析业务的发展趋势——注意，这个阶段非常重要，你看得有多远，对业务判断有多准，决定了接下来规划的质量有多好。

尝试通过了解和梳理这些问题，来明确业务发展的趋势：

• 下一个阶段，业务发展的方向是什么？——通常，发展方向会围绕规模化已有业务、精细化已有业务和试验新业务来进行
• 在这个发展方向上，下一个阶段的目标是什么？——这里的目标，要能明确到可以做价值判断的程度，目标完成后带来的价值，将是我们判断优先级的重要依据。
• 为了完成目标，计划在什么时间做哪些动作？
• 每个动作对目标的影响程度有多大？——通常在业务规划阶段，点子是非常多的，我们要确定哪些事情是非做不可的，哪些是锦上添花的，哪些是可有可无的，这是更细颗粒度的，对优先级判断的依据。
• 业务的方向和动作，有哪些会发生变化和风险，可能发生变化和出现风险的原因是什么？

基于上图，我们会得出一个表格，来表达下个阶段业务的变化。、

我们依然以订单系统举例，从表格可以看出，订单系统对应的业务部门，下一个阶段计划保住单均营收，同时规模化增长。

好了，现在我们新增一列时间维度，再对这些问题进行询问，尝试把【下一个阶段，业务发展的方向是什么】，换成以下时间周期：【这个月，业务发展的方向是什么】、【这个Q，业务发展的方向是什么】、【这半年，业务发展的方向是什么】、【今年，业务发展的方向是什么】、【三年后，业务发展的方向是什么】

新增时间维度后，我们可以对表格进行改进。

当然，对于1个Q之后的计划，不要纠结细节，有时候业务处在探索期，我们可能只能看到这个月能干什么，探讨未来，是便于我们在长期方向上达成共识，毕竟系统设计是需要拓展性的。

为了完成上述表格，我们不仅需要搞明白业务趋势是什么，还要反复追问为什么。另外，我们要接受不是每个业务同学在每个阶段，都能把上述问题一次性讲得非常清楚，和产品一样，做业务也是要迭代的。探索的不确定性，也是一种合理的业务趋势。我们可以做的，是通过各种渠道，充分收集和分析信息，最终自己给出问题的答案。

4. 规划系统建设方向

了解业务发展趋势后，我们要着手设计系统下一个周期的建设方向和目标了。一般的，做方向规划，我们要经历3个子环节：梳理业务流程——明确建设方向——明确建设目标

1）梳理业务流程

首先，我们要具备两个认知：

1. 互联网产品本质是提升效率的工具，路径一般是将业务过程和用户行为在线化——自动化——智能化。
2. 通常，业务动作可以被抽象成【什么角色完成什么行为，以达成什么目的】

围绕这两点，基于我们已经收集到的业务信息，我们可以梳理下一个阶段的业务流程，以此判断哪些角色哪些行为未来是需要被搞到线上去，或者搞成自动化的。为了让思考更聚焦，我们可以尝试用一张作业流程图来引导我们思考。作业流程图需要反映出角色、作业环节、以及环节之间的流转关系。

2）明确建设方向

梳理作业流程后，我们要明确下一个阶段，系统要给什么角色什么环节进行什么程度的支持。别忘了，信息化的过程是：在线化——自动化——智能化。

我们可以通过回答下面几个问题，来引导我们思考。

• 新的作业流程里，哪些环节线上化程度是不够的，需要线上化支持的？
• 新的作业流程里，哪些环节在线但效率低下，需要引入类似自动化的规则进行提效的？
• 上述系统支持的优先级是什么？

上述问题回答后，我们可以升级作业流程图，加上我们计划的系统建设方向。

从图中可以看出，规模化增长可能导致原有的客服成本增长，我们需要对订单创建和退款环节进行系统支持，控制这部分成本。虽然订单履行阶段也占用客服人力，但成本相对可控，根据优先级，我们本期可以不对其进行改造。

3）明确建设目标

有了方向后，我们要给每个方向制定目标，以使执行动作聚焦和执行结果可衡量。

我们要明确两个类型的指标。一方面，我们要制定系统目标，系统目标可以是根据业务目标来的，比如时效指标、人效指标、人力成本指标、转化率指标。也可以基于系统建设的角度制定，比如线上化覆盖度等。另一方面，我们要明确时间节奏目标，时间节奏决定我们采用什么质量的设计方案来实现需求。

强调一下，目标一定要有，且需要保证可达成和可衡量。我们要给每一个方向定好明确的目标，以及衡量达成的方法罢。不要谈虚词，比如，目标就是提升效率，衡量方法是上线后进行调研。相信我，上线后，你就会去忙新需求了，然后会去忙另一个新需求，直到汇报时，才想起来凑数字去写PPT，到时候只能靠编了。

上图是添加了目标的产品建设方向。

另外，如前文说的，目标和定位是两回事。目标是短期的，比如，在下个月，我们的目标是，要把创建订单的时间缩短到10S。而定位更像是愿景，比如，我们要提供高效的创建订单过程，在这个定位之下，10S是不够的，自动化也是不够的，下个月10S，再下个月，我们就要想办法让它变成5S，1S。

5. 拆解项目

终于，我们到了熟悉的环节，拆解产品项目。我们要拆解出不同的项目，以保证在规划好的产品方向下，能够达成目标。

首先，基于方向，我们要明确改造的系统/模块是什么。从改造类型角度，我们要判断本次是新增系统/模块，还是对已有系统/模块进行改造。

其次，基于时间节奏目标，我们需要明确系统建设的深度是怎样的。是选择放弃，改为线下支持，是短期方案，硬逻辑直接上，还是幸福快乐的理想情况——做长期产品方案。同时我们要做好版本拆解，要将精力重点放在最能实现目标，产出最大收益的项目上。

最后，我们会得出一张图和一张表格。一张图指的是我们的系统框架图，我们梳理过现状了，应该知道在新的变化下，我系统要怎么演进。我们可以在框架图添上计划支持的系统和模块，以表示演进过程。

从图中可看出，我们要对订单创建模块进行升级，以及新增订单规则和一整套退款模块。而订单状态机模块，虽然过去很烂，但目前无论长短期业务变化都对它依赖不强，改造可以放缓。

一张表格，指的是我们应该有一张项目列表，来管理以下信息

• 都有哪些项目
• 每个项目完成的目标是什么
• 优先级是什么
• 当前状态是什么，下一个里程碑是什么（下一个里程碑，指的是下一个重要阶段的时间点是什么），预期上线时间是什么
• 需要什么部门，什么资源支持
• 风险是什么

6. 同步规划

很多时候，规划没有执行下去，是因为我们没有做好规划的同步。产品经理这一群体容易产生研究型人才，娇气，擅长闭门造车，但如果要执行规划，我们必须让信息流通起来，向合作伙伴们提出诉求，以保证规划落地。

一般的，我们需要带着作业流程图、系统框架图和项目列表，和下面这些角色，就规划达成共识。

• 业务方：我们要重点就系统建设方向和项目列表达成共识，要确认产品方向和业务方向一致，以及产品目标是否能达成
• Leader：我们需要和Leader对齐目标、风险，以及需要协调的资源
• 团队同学：如果我们已经在带领团队，那我们应该将规划的思考过程、目标和项目列表和团队达成共识，让大家充分理解建设方向和每个项目的意义。
• 技术和设计部门：提前同步规划，可以让下游部门进行人力储备，甚至开始进行方案设计。也可以在同步规划后，再约技术和设计负责人沟通下，确保每个方向，都放置了足够的资源进行支持
• 同级部门：拉上所有相关部门同学，提前打好招呼吧。相信我，无论在规划落地花了多少时间沟通，都好过在需要支持时，同级部门问出那句——让我们支持可以，但能先讲讲背景么？

好了，以上就是我们进行B端系统规划的方法。另外，有一些3－5年产品经理，在做规划时的傲娇思维，需要我们高度避免。

二、做规划时需要避免的傲娇思维

傲娇思维1：做规划没有用，业务总是变，做的规划将来也会废掉

• 规划的意义在于让产品工作开展更有序，没有规划，工作会变得东一榔头西一棒槌——如果因为变动，大家可以停下工作，等到稳定了才开始，那我们可以不规划。问题是，即使不规划，各位也要干活啊，因为各位要写汇报PPT啊，最终导致做了一堆无用的PPT功能，还抱怨，业务总是变，产品没办法规划。
• 要有这样的认知：快速变动，是一种常见的企业发展情况。我们要做的，是摸索出快速变动下，应该怎么进行系统规划，比如MVP方法，比如寻找不变的业务环节进行支持，比如对频繁变动的地方做松耦合，做配置化。
• 如果确实出现变动，确认原因后，应该按规划步骤，及时调整规划。同样的，这也是一种非常常见的情况。但要注意，在这个周期过后，应该和业务同学进行复盘，思考是否有可能提前做规划来降低变动风险，要思考，是因为自己规划失误，还是确实业务在无脑变化。
• 做产品规划，也是反向Push业务做规划的过程。如果业务永远不做规划，没有目标，且频繁变动业务方向，此时你应该考虑的是换个公司，或者换个老板了。

傲娇思维2：业务提需求提不明白，没办法做规划

• 运营同学提需求的质量不应该决定产品规划的质量。
• 运营同学的本职工作是运营好产品，定好业务目标和方向，而不是有条理地有远见地提出合理的产品需求，如果运营同学都能干到这份上，要你何用呢，PRD写起来很难么。产品需要支持什么，支持到什么程度，是产品同学需要完成的工作。另外，这份工作的内容也包含，产出规划后，和业务同学对齐。因为没有对齐出现的规划失误，锅应该产品背。

傲娇思维3：喜欢做通用规划

• 3－5年产品经理，在做规划时容易做通用规划，第一类通用规划是，抄袭大厂产品做规划。见过产品经理做商品系统，就对着淘宝商品系统抄一遍功能框架，美名其曰，做规划。兄弟，如果可以这么做事，找一个记性好的低阶淘宝产品不就行了，要你何用呢。抄作业是轮不到大家的。
• 第二类通用规划是：什么都想做，认为多就是好。同样的，如果什么都做，要你何用呢。好的规划是方向聚焦的，且核心动作通常不会超过五个。如果出现方向很多的情况，需要重新思考，业务方向是否明确，优先级判断是否合理，或者在产品方向的抽象上是否合理。

傲娇思维4：基于现有人力情况做规划

做规划时要考虑人力情况，这一点是没错的。但注意，现有人力情况，只是做规划的考虑因素之一。如果我们对业务方向已经达成共识，下面要考虑的是，该方向能带来多大价值，为满足这个价值，我们要付出多大成本。如果价值很大，成本可控，那还有什么说的，缺人，就招人啊。公司下个Q要做一亿美金的生意，难道因为缺你一个B端产品，一亿美金就不挣了么——是的，先思考价值大小，再思考成本大小，这是一个心智成熟的产品经理应该具备的规划思维。

以上是做B端系统规划的一点心得，希望能帮助到3-5年级的产品同学。

作者：好啦一宸聊产品 ，多年B端产品经理，认为信息化是改变世界的一种方式

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

题图来自 Unsplash ，基于 CC0 协议