在没有完整产品规划经验的情况下，如何从零规划一个解决方案级产品矩阵？本文从制订产品路线图和产品设计功能两个维度出发，总结相关经验方法，希望对你有所启发。
至此，我们已将智慧能耗解决方案的实现路径有了基本概念，下面就开始根据战略愿景开始第一阶段的产品设计。但第一阶段需要并行完成计量与采集的前端设备，IoT平台，设备管理平台，以及能耗管理平台，工作量依然庞大。公司资源特别是软件资源无法覆盖，必须对范围及功能进行裁剪，否则会变成一个裹脚布项目。
智能硬件部分，策略是利用之前的技术积累，将之前的预研成果进行排列组合，快速实现硬件 demo。后期再针对上层应用需求，调整升级嵌入式程序。极大减轻硬件部门压力。
IoT 平台简化为仅保留基本功能的后台服务，南向对接公司内部硬件，北向对接能耗管理应用平台，功能上简单实现设备上下行数据接入与协议转换，数据上打通应用软件与智能硬件。后期根据市场及公司资源情况，再考虑是否将其升级为通用型的 IoT 服务平台。
将设备管理拍扁，简化为基本的设备资产管理并入能耗管理平台。将有限的应用软件团队，全部投入到最核心也最复杂能耗管理应用平台。
通过以上裁剪，将第一阶段的战略目标转换为下图所示的三层简结构。软硬件团队互为黑盒，独立并行开发，中间通过轻量的数据服务提供桥接，形成数据闭环。
现在，项目团队在怀揣方案全景的前提下，可以各自轻装急行了。
自此，已完成从行业，到企业，再到项目的顶层设计。现在，我们将拿起扩大镜，对具体业务场景进行更细致的观察分析，识别出典型需求，进而开始功能规划。
通过市场调研分析，我们把用户使用场景，按是否计费与是否实时监控两个维度，划分为如下 4 个象限，并对对能耗管理典型场景的核心述求进行的简单勾勒。
数据远程采集及基础数据接入场景： 如货场，仓库等，此场景下，只需对表端数据进行远程采集，仅提供原始数据在线显示及设备资产管理，系统不参与任何业务处理。这是最简单的使用场景，涉及的系统功能为基础功能，其它场景也需要使用。
自管物业等能耗抄收场景： 比如水电自管的老旧小区，公寓出租物业等，此场景下，存在管理方与使用方。管理方需要对使用方信息进行管理，对使用方的水电气热消耗量进行计量及收费。分户计量及费用收缴是其主要诉求，设备运维不太关注。系统目标是覆盖多种收费场景，兼容水电气热多种表计，做到采集，计量，计费，收缴费自动化。
商场园区等综合能耗管理场景： 商业园区场景下，同时存在收缴费及能耗设备监控的需求。希望在一个平台对水电气热用量及费用进行统一管理，同时对节点设备进行监管，但设备监控的实时性与复杂性工业能耗监控低得多。
工业能耗监控场景： 此场景下，主体是同一企业，目标对重点区域，重点设备能耗及运行等监控，无内部租户概念，不涉及收缴费流程。因业务需求，可能存在多种非能耗设备的接入需求，从而形成一整天监管系统。此场景下，能耗监管，设备状态特别是异常状态监控是其主要诉求。系统目标是事前预测，事中监控，事后分析。
我们将能耗管理典型业务环节进行抽象，得到如下概念模型已便于观察分析。模型中红色矩形为关键业务实体，矮圆柱为关键数据，连线为他们间的关系。
通过观察分析发现，能耗管理的业务本质是数据管理，其核心业务可抽象为三条数据流。
以上三条数据流，分别对应1,2,4象限的应用场景中的核心业务。三条数据流合起来，就构成了第三象限的核心业务。我们将上述洞察丰富到概念模型上，于是构建出如下识别度更高的概念模型，用以指导进一步的产品设计。
通过对典型场景下业务概念模型的进一步分解与取舍后，得出第一阶段的核心功能范围，制定出如下产品路线图，用以指导后续设计研发工作。
现在让我将视角再切回起点，提出智慧能耗解决方案的原因，是因为市面方案存在架构老旧，兼容困难，业务割裂，数据孤立，扩展受限，售后及维护成本高昂等问题。
而我们的方案定位，是提供一套软硬件一体，水电气热综合管理，抄收缴管一条龙服务，后付预付全覆盖，能耗数据全打通的一站式解决方案。能耗管理云平台的设计目标就是解决现状问题，实现方案定位所设定的目标。 在进入功能设计之前，我们需要确定一个相对灵活的系统结构，这个结构需要有如下特点：
从上述要求出发，兼顾预留后期扩展的基础上，对智慧能耗系统进行拆分。以使用人员的类型差异为拆分线索，将智慧能耗系统划分为商户管理端，企业业务管理端，用户远程查缴费客户端。其中企业业务端暂时只实现 web 版，后续再行实现移动版。这是极简关系架构关系图。
各端的目标用户及大致功能描述如下： 商户管理端： 目标用户为我司及其它具备客户承接能力的表具厂，系统集成商，渠道商等合作服务商。提供设备管理，客户管理，客户设备类型及功能配置等管理功能。
企业业务管理端： 目标用户是『园区物业管理方』等我方或服务商客户。提供用企业内部能耗用户管理，能耗设备管理，能耗数据的远程抄收，费率配置及费用收缴业务，并提供数据分析及报表下载等管理功能。
用户查缴费应用： 目标用户是能耗商户下属的终端用能用户。提供用户自行远程查询能源使用情况，缴费账单及远程充值缴费等业务。减少企业及其用户的交易成本。
将系统结构与功能范围结合，制订出如下功能结构图。图中不同颜色代表功能的不同优先级。蓝色优先级最高，其后依次为青，橙，黑，灰。
从上述认知的基础上，做进一步分析梳理，设计了各端权限控制及数据流转架构。
有了前面工作的铺垫，现在开始进入具体的业务设计。在进入具体业务设计前，让我们再次观察之前所抽象出的业务概念模型。不难发现，这是一个典型的，由数据驱动的 AIoT 业务流。
全部业务由红，绿，黄，紫四条数据链组成，覆盖了四种典型的业务场景。其中红色数据链是关键数据输入。其它三条数据链都是在红色数据链的基础上，辅以不同业务规则而发展出来的数据应用。
也就是说，红色数据链是整个业务的数据基座，我们需要确保它的健壮性，挖掘它的可能性。
红色数据链的外部输入是各类传感与智能设备。我们通过“设备档案”，记录设备的类型，归属层级，网络类型，关键参数等数据，为后续构建设备的节点网络进行数据构建。
每个设备节点都有独立 ID，而它们上传数据都会带有时标，也就是说，每个设备节点都是一个天然的时序数列发生器。而每个智能设备都会有一个物理上的安放点或检测地点。这样我们就能将设备上一维的时序数据，关联上三维的空间数据，升维成四维的时空数据。
我们引入了“最小计量区”这个概念，用来代表具体设备的检测点，并关联空间坐标。因为我们关注的是园区管理，需要更细的空间划分。所以在地理位置的基础上，进一步拓展出楼栋/楼层/区域三级空间维度。结合行政区划上的省/市/区县/乡镇/村组，我们构建了 8 级空间，用于以后的数据切片及分层统计。
通过上述方式，我们已经将设备上的单一的原始数据加工成有6个时间深度（年月日时分秒），8 个空间深度，带48 个切面的原子数据。再加上节点网络维度的划分。我们有了一个可能性极大的数据基座。
下面以智能电表为例，说明下红色数据链的在实际系统中的加工过程。
之前，我们通过是否计费与是否实时监控两个维度，将纷繁复杂的业务场景划分为了四个场景类型。并抽象了关键业务模型，提炼出了 4 条数据链。同时将设备输入通过红色数据链加工成了数据基座。下面，我们将在数据基座的基础上，开始具体业务实现方式的设计。
这里选择既有设备监控又需计费的商务园区场景为目标，进行能耗业务设计。因为这个业务场景，涉及到数据基座中的全部数据链的使用。完成这个场景的设计后，其它 3 个场景，只需此基础上配置各自的业务规则，就可以完成各自的业务设计。为简化问题，我们将设备这块内容折叠变换将核心业务抽象为如下模型。
从模型中可以看出，统计最小计量单元的实时用量，就能得出不同区域在不同时段用量。通过查询用户使用区域，就能统计到用户的耗能情况。通过计费规则与出账规则的计算，就能得到用户账单费用。
大的逻辑是这样的，但实际情况远比这复杂。就拿支付账单举例：商务园区场景下有先用后付及预付后用两种业务形态，支付方式可分线上与线下两种方式。同时因为管理方式不同，预付业务有充值及退还，费用不足提醒，透支额度授予，自动阀控反制等业务管理需求；后付业态有滞纳账单等罚性手段等业务管理需求。下图是对能耗费功能的大体描述。
拆分到上面这个程度，我们已经对这块的业务建立起了总体印象，对后续功能的总体走向有了把握。但认知还是停留在宏观层面，业务逻辑的颗粒度太大，不足以指导系统开发。需要进一步细化挖掘，才能形成对业务的微观层面的理解，最终提炼出实现业务的关键路径，进而设计出对用户真正有用的功能。
下面抽出付费模式这个业务点举例，其进一步细化分析如下：
后付费模式（1:1，1:n，n:1）：
预付费模式（1:1）：
通过上述的细化分析后，我们才真正认识到实际场景下用户需求的多样性，才能设计出覆盖全面，从容应对多种业务场景的能耗收费功能。而不是一个漏洞百出，需要频繁打补丁才能运行的收费模块。
综合上述分析与业务模型，与设计按用户类型配置个性收费方案的功能，覆盖典型业务场景下的所有业态。对于无需收费的内部能耗监控场景，不配置收费方案即可。
对于需要收费的场景，我们提供自动抄收，自动出账，自动扣费，远程缴费，以及自动催收，自动阀控等自动化能耗计量计费及收缴一条龙服务。并且覆盖了水电气热多种能耗类型。
文章内容较长，将分成三个篇章输出。后续篇章会在上述内容的基础上，对 2B 类产品的 PRD 输出示例与项目总结等内容进行输出。
本文由 @李金尧 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。