若你没有经历过完整的解决方案构建，当需求来临时，却不知所措。那么该如何从零规划一个解决方案级产品矩阵？作者分享了真实项目复盘，描述了从零规划一个解决方案产品矩阵，希望对你有所启发。

前言

本文对一个真实产品的规划过程进行了复盘。描述了从零开始规划一个软硬件解决方案级产品矩阵的思考过程，以及具体场景下关键业务的需求分析及功能设计思路。同时会包含部分项目管理视角的考量，毕竟想法再好也要考虑项目推进时的资源限制，及相关技术与市场风险。希望对没有经历过整体解决方案构建过程的产品人有所启发，初步了解如何从零构建类似的整体解决方案。

行业调研、交互设计、原型设计等实操细节的文章市面上很多，此类内容非本文关注重点，不会过多着墨。

解决方案的规划过程，涉及到行业与企业的视角切换，时间线上的价段划分，业务领域内横向产线划分过程错综复杂。为简化表述，下面以时间为主线，仅做线性描述。

实际设计过程中，很多设计上的思考都不是一蹴而就的，而是经过反复取舍，交错进行的。有些关键设计环节，为了优化到合适的程度，甚至会出现推导重来的情况。

就个人经验来看，做好扎实的产品定位研究与业务架构设计是第一要务。这一块的工作做好了，产品在进入研发环节前，已在大的方向上与各方达成了共识。这会为后续工作减少了很多摩擦，同时也为后续细节设计指明了方向，避免在需求频繁变动时失焦。

产品的细节设计阶段上，建议结合敏捷项管思维，采用渐进明细的设计方式迭代前行。同时，设计环节相对研发环节，保持两到三个 sprint 的进度提前量，将是一个比较恰当的工作节奏。

这能让产品设计人员在保持足够紧凑度的同时，拥有适度的容错空间，从而以更为开放的态度响应市场反馈及需求变更。这样能将变更导致的影响尽量消化在设计环节，为研发环节创造出相对稳定需求环境，从而有利于研发质量提升，减少对研发进度的冲击，降低项目整体的产出成本。

背景

19 年底，公司决定决定涉足智慧城市领域，成为该领域的解决方案提供商。笔者当时在产品与项目管理部，我的任务是为公司智慧城市战略规划软硬件解决方案，并负责软件部分的产品设计及整体方案的研发推进。

公司当时的主营业务，是给水电气热领域的厂商提供远程低功耗数据采集模组。公司辅助业务，是建立在低功耗采集技术基础上的通用数据采集硬件，以及在此基础上孵化出来的一些智能硬件。

从组织结构上看，研发中心硬件 嵌入式软件人员占比超过 80%，应用软件人员占比不到 20%。且应用软件部门之前的工作，主要是辅助硬件部门做设备调试运维的上位机软件，以及远程查看数据及设备运维的 APP，没有行业应用的项目经验。应用软件开发及行业背景上是短板，无论是技术基础，项目经验，还是人才储备上都捉襟见肘，预期短时间内不会得到改善。

一、确定方案定位

1. 明确方向，缩小边界

智慧城市是个很大的概念，囊括基础设施，生态环保，安全服务，社会管理，民生服务，产业发展等六大领域。而基础设施上又包括：智慧交通、智慧电网、智慧管廊、智慧楼宇、智慧酒店、智慧工地。

智慧城市显然不是一个具体可执行的目标，需要缩小领域范围，然后聚焦到一个可能落地的场景。通过与公司领导及软硬件部门的多次沟通，结合自身资源禀赋进行分析论证，最后公司内部达成共识，将范围压缩至园区管理领域，并将场景聚焦至园区内的能耗管理方向。

2. 行业视角下战略定位

行业现状：能耗管理并不是一个新概念，只是受制于技术与成本，市面上的解决方案有各自的问题。其中较为突出的问题为架构老旧，兼容困难，业务割裂，数据孤立，扩展受限，售后及维护成本高昂等。具体问题总结在下图：

造成上述问题的核心原因大体可分为两块：一块是软硬件研发分离，另一块硬件间互通成本高。软硬件因技术方向差异大，企业往往选择专精一个方向。这种方式下软硬件企业各用其长，优势明显，但也给软硬件集成留下不少麻烦。硬件间互通困难的原因构成复杂，大体可从客观与主观两个维度进行分析。

• 客观上： 因史原因，底层设备的传输与通讯协议纷繁复杂，常见的就有几十种，选择范围极其宽泛。而硬件的实际应用场景差异极大，对功耗控制，通信距离，数据安全，硬件成本等要求各异，于是各硬件遵循的协议规约没法简单统一。
• 主观上： 尽管国际与国家标准组织在努力推进标准的统一化。但硬件厂商为保护自家市场，主观上有动力制订私有协议，以增加对接成本的方式减少竞争，导致硬件互通成本更高。

在国内，水，电，气，热属公共事业，分属不同行政部门监管。在之前数字政务的推进过程中，水，电，气，热分别发展了各自的单体管理系统，分别服务于其归口单位的后端系统。市面能耗综合管理方案，大多在上述基础上简改造而成，存在架构老旧、功能与场景脱离、数据互通性差的问题。再叠加实际落地时，各规格硬件的互通难题，后续拓展需求，对冲售后 及维护都面临诸多挑战。

政策红利：随着数据化及自动化趋势的不断推进，加之碳中和，碳达峰的政策引导。各企事业单位为减员增效，降低能耗，开始逐步重视能耗监管及智能化改造，这是一个长期的政策利好。

我方优势：目前所在公司，深耕无线传输领域17载，在水电气热等能耗远传及抄收领域有深厚积淀，是能耗管理领域的硬件提供商，有扎实的硬件研发能力。在整合了公司在前端表计、远传通讯及行业理解上的诸多优势后。结合软硬件分离及硬件互通的问题就解决了一大半，相较纯软公司我们优势明显。

战略定位：经过上述分析，并考虑到市场竞争情况后，我们提出如下定位。

• 市场定位： 二级能耗计量、采集、费控的智能化建设及改造市场。
• 客户定位： 自管物业，校园，工矿企业，综合商务楼宇，科技园区，产业园区等运营单位。
• 功能定位： 提供一套软硬件一体，水电气热综合管理，抄收缴管一条龙服务，后付预付全覆盖，能耗数据全打通的一站式解决方案。

二、建立方案愿景

园区能耗管理领域内涉及传感设备，计量仪表，远程采集等前端设备，负责数据解析及分发的IoT 平台，以及具体的能耗管理应用三大业务版块。各版块下还生存了繁多的软硬件供应商。而能耗管理作为智慧园区的一个环节，还需考虑与上下游的软硬件系统互通。一言以蔽之，能耗管理整体解决方案涉及面很广，没法一蹴而就，只能分而治之。

1. 时间维度上纵向分解

由内而外展开能耗解决方案就会发现，这是一个由企业核心能力与行业伙伴链接的多层网络结构。建立企业核心能力是前提，然后以此为基础向行业提供价值，进一步裹挟行业资源为我所用。从而可以将整个解决方案，按时间维度大体分成三个阶段分步实施。

第一阶段： 目标是构建一个最小化的业务闭环，完成能耗管理的核心业务，使之能独立完成客户服务。在不考虑第三方硬件与系统的前提下，完成从能耗计量，远程数采，抄收计费，费用收缴结算、数据分析以及设备监控的业务闭环。

第二阶段： 目标是完成标准化接口建设，使之能参与到其它集成系统中去，拓展市场边界。这个阶段，会将第一阶段的业务数据以标准的 API 接口输出，供给第三方系统调用，或是整个解决方案作为子系统，集成到更高维度的智慧园区管理系统中去。

第三阶段： 目标是，作为集成平台，集成第三方的设备与服务，拓宽业务边界。使得我们的智慧能耗管理方案能适配到更加复杂的业务场景，并为系统的后续拓展铺路。

2. 业务领域间横向拆分

完成第一阶的战略目标，才有了自身的核心价值，是在行业生态上了占据一个生态位的前提。但第一阶战略涉及到多个智能硬件与两个软件平台的开发，整体的设计与开发周期必然不短，而公司能挤出的人力资源十分有限。长周期的产品开发，如得不到市场验证，研发内部压力与产品的市场风险都很大，甚者整个方案都会流产。

在考虑方案的正面收益时，必须同时考虑不如预期时如何减轻风险的冲击，如何进行产品退出。不考虑市场与风险的产品设计都是耍流氓。

研究整体解决方案的业务链条发现： 智能硬件、数据服务、设备管控、能耗应用这 4 块业务，边界明确，边界内业务相对独立，边界间仅存在数据流的上下游关系，具备拆分的天然条件。且上述业务领域对应的资源基础与研发周期不一，相互解耦后分别开发能极大的缩短方案交付的周期。

结合公司当时的组织结构与业务沉淀，将解决方案横向划成4 条横向业务线，形成一个产品矩阵。各业务线的阶段产出都能独立作为为产品售卖获取现金收益，接受市场反馈，极大的减轻了研发压力与市场风险。业务线进行组合，便构建起软硬件一体的完整解决方案。

数据采集： 在公司已有硬件基础上，研发水电气热智能仪表，数据采集模组，智能网关等硬件产品，可作为独立硬件投入市场销售。

数据接入与分发： 在公司之前运维服务基础上，进行改造升级。这块可作为智能硬件的配套服务与硬件打包销售。也可升级为通用的 IoT 平台单独销售。

数据映射与设备管控： 以设备管理为核心的功能组，设备的定义，档案管理，数据位点配置，实时监控等都在这个模块完成。这个模块可与前两模块合并就是一套完整的设备监控解决方案。也可后续升级成为专业设备管理应用。

数据应用与能耗费控： 这是能耗管理解决方案的核心应用，与前面三个模块构成完整的智慧能耗管理解决方案。也可作为独立软件，成为行业生态的能耗管理组件，实现对第三方系统的赋能。

3. 建立整体愿景

通过方案的战略定位及阶段分解，解决方案落实为由智能硬件，IoT 服务平台，设备管理平台，能耗管理平台四个业务线构成的产品矩阵。第一阶段只考虑企业内部四条业务线的建设，完成能耗管理的核心业务。后续再考虑与第三方软硬件集成，形成与上下游生态厂商的互动合作。至此，可将智慧能耗整体解决方案具象成如下拓扑。

文章内容较长，将分成三个篇章输出。后续两个篇章会在上述内容的基础上，进行产品路线规划，产品功能设计，以及 2B 类产品的 PRD 输出示例与项目总结等内容输出。

本文由 @李金尧 原创发布于人人都是产品经理，未经许可，禁止转载

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

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。