通过是否计费与是否实时监控这两个维度，可以将复杂的业务场景划分为四个场景类型，提炼出了4条数据链，并将设备输入通过红色数据链加工成了数据基座。本文在数据基座的基础上，分析具体业务实现方式的设计，一起来看一下吧。

一、设计业务实现方案

之前，我们通过是否计费与是否实时监控两个维度，将纷繁复杂的业务场景划分为了四个场景类型。并抽象了关键业务模型，提炼出了 4 条数据链。同时将设备输入通过红色数据链加工成了数据基座。下面，我们将在数据基座的基础上，开始具体业务实现方式的设计。

这里选择既有设备监控又需计费的商务园区场景为目标，进行能耗业务设计。因为这个业务场景，涉及到数据基座中的全部数据链的使用。完成这个场景的设计后，其它 3 个场景，只需此基础上配置各自的业务规则，就可以完成各自的业务设计。为简化问题，我们将设备这块内容折叠变换将核心业务抽象为如下模型。

从模型中可以看出，统计最小计量单元的实时用量，就能得出不同区域在不同时段用量。通过查询用户使用区域，就能统计到用户的耗能情况。通过计费规则与出账规则的计算，就能得到用户账单费用。

大的逻辑是这样的，但实际情况远比这复杂。就拿支付账单举例：商务园区场景下有先用后付及预付后用两种业务形态，支付方式可分线上与线下两种方式。同时因为管理方式不同，预付业务有充值及退还，费用不足提醒，透支额度授予，自动阀控反制等业务管理需求；后付业态有滞纳账单等罚性手段等业务管理需求。下图是对能耗费功能的大体描述。

拆分到上面这个程度，我们已经对这块的业务建立起了总体印象，对后续功能的总体走向有了把握。但认知还是停留在宏观层面，业务逻辑的颗粒度太大，不足以指导系统开发。需要进一步细化挖掘，才能形成对业务的微观层面的理解，最终提炼出实现业务的关键路径，进而设计出对用户真正有用的功能。

下面抽出后付费模式这个业务场景举例，其进一步细化分析如下。

后付费模式（1:1，1:n，n:1）：

内部细节已省略，仅保留关键字段用做说明

通过上述的细化分析后，我们才真正认识到实际场景下用户需求的多样性，才能设计出覆盖全面，从容应对多种业务场景的能耗收费功能。而不是一个漏洞百出，需要频繁打补丁才能运行的收费模块。

综合上述分析与业务模型，设计了按用户类型配置个性收费方案的功能，覆盖典型业务场景下的所有业态。对于无需收费的内部能耗监控场景而言，不配置收费方案即可。

对于需要收费的场景，我们提供自动抄收，自动出账，自动扣费，远程缴费，以及自动催收，自动阀控等自动化能耗计量计费及收缴一条龙服务。并且覆盖了水电气热多种能耗类型。

后续其它功能模块，也依据上述方式不断分析挖掘，直到找出业务关键，形成业务洞察，建立业务模型，然后在此基础上进行界面及交互设计。

二、输出PRD 文档

有了上述分析的基础，我们对整个产品功能的认知已经比较全面了，可以开始交互及界面线框设计，着手PRD 文档的输出了。

不同于 2C 类产品追求界面与交互的新颖性。2B 类产品注重效率，除大屏类界面最求炫酷外，功能界面一般以简洁高效为主。交互设计的重点是易用，趋向于使用大众熟悉的交互方式，不追求花式创新。如果企业设计资源不是很充足，建议直接使用大厂开源的 UI 设计体系，基本上能满足大多数的 2B 类产品，且界面样式及交互都在平均水准以上。这样能节约不少设计资源，减轻前端工程师的工作压力。利于将不多的研发资源投入到业务实现与功能研发上去。

我们这个项目上，选择使用了蚂蚁的 Ant Design。从产品的线框设计，到 UI，再到前端都使用同一套组件库，效率提升明显。

2B 类产品涉及很多业务领域的背景知识，业务规则也相对复杂，简单的线框+标注的形式很难保证研发人员正确理解需求。因此需要有较为详细的 PRD 文档进行辅助说明，帮助团队对齐业务理解。

我一般会将确认的产品需求放在待办供团队成员查看，使团队成员对后续研发工作胸中有数。在Sprint Retrospective 会议上对下个冲刺的需求做讲解与答疑，并在会后将会议上的提出问题更新到 PRD 文档。

因为时间有限，不太可能按写论文的严格程度去写 PRD 文档。我一般会根据项目内容确定一个文档模板，然后是格式化写作，内容多是条目式。这当然不完美，但对我而言高效，对团队沟通也够用，这就行了。

1. PRD 文档示例

我从项目中抽取了一个 sprint 的PRD文档贴在下面，仅供参考。

我从项目中抽取了一个 sprint 的PRD文档贴在下面，仅供参考。

三、项目总结

实际情况工作中，产品经理不太可能有时间一次性将上述工作全部做完，然后再启动线框设计。但时间不够不是不做上述工作的理由，否则会给整个项目埋下天坑，给研发平添工作量。

2B类型的产品，特别是方案级的产品矩阵，相关方众多，业务复杂，需求多变，尤其需要有产品的顶层设计。否则项目范围极易蔓延，项目进度失控，极有可能胎死腹中。

当然，过早设置僵化的顶层设计也不可取，很可能导致最终实现与市场需求相去甚远，企业付出极大的资源与时间成本后，却得不到相应的市场回报。

个人经验是采取渐进明细的方式进行规划设计。进入功能设计前，先要对产品在行业的生态位有清晰认知，在脑海中对产品的全貌有基本轮廓，在这个基础上进行初步的顶层设计，用以指导后续规划。然后在做详细设计的过程中，逐步丰富并修正顶层设计。再用更有血肉的顶层设计，指导后续模块设计。这是一个交错进行，相互增强的过程。

在上述方案的规划设计过程中，我就是用上述方法论，从零开始规划设计了智慧能耗管理解决方案，并推动整个研发过程。项目团队以一到两周一个 sprint 的频率稳定推进，4个月 不到的时间，我们上线第一个试用版，开启市场测试。前后持续进行了 24 个增量迭代冲刺，完成解决方案第一阶段的软硬件产品目标，中间没出现过一次大的需求变更。同时为后续的产品功能拓展及系统拆分留出了数据与功能结构上的插槽。

整个项目过程中，我们始终面向业务规划，面向市场开发，一直牟定行业痛点，紧盯客户需求，最终取得了不错的结果。对照市场定位于行业问题，我们提出并实现了如下功能。

通过这次的产品研发，软件团队很快熟悉了 scrum 开发模式，技术能力得到了提升。硬件部门也在这个过程中梳理了自己产品组合，构建了园区能耗相关的硬件产品矩阵。

下面是能耗管理系统企业业务端的部分产品界面展示。是从我给商务做的推介材料上截取的，算不上商业机密。放在此处，让大家从沉闷的业务分析中放松一下下。

在规划智慧能耗解决方案的过程中，我收获了对对智慧园区的领域知识，砥砺自身产品设计与项目管理技能，同时也总结了一套规划与设计 AIoT软件项目的方法论。这套方法论，对我设计后来的“智慧水务综合管理系”与“汽车充电管理系统”，帮助甚大。如果大家感兴趣的话，以后找时间再分享下这两个产品的设计过程。

• 如何从零规划一个解决方案级产品矩阵（一）
• 如何从零规划一个解决方案级产品矩阵（二）