惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

U
Unit 42
Microsoft Azure Blog
Microsoft Azure Blog
Engineering at Meta
Engineering at Meta
博客园 - 【当耐特】
人人都是产品经理
人人都是产品经理
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
WordPress大学
WordPress大学
有赞技术团队
有赞技术团队
Blog — PlanetScale
Blog — PlanetScale
酷 壳 – CoolShell
酷 壳 – CoolShell
aimingoo的专栏
aimingoo的专栏
Jina AI
Jina AI
小众软件
小众软件
博客园 - 叶小钗
MongoDB | Blog
MongoDB | Blog
大猫的无限游戏
大猫的无限游戏
博客园 - 聂微东
Y
Y Combinator Blog
云风的 BLOG
云风的 BLOG
I
InfoQ
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Martin Fowler
Martin Fowler
P
Proofpoint News Feed
MyScale Blog
MyScale Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
物联网设备接入产品该怎么设计?
产品海豚湾 · 2023-01-25 · via 人人都是产品经理

在某些B端产品中,会通过安装物联网设备来提高工作效率,比如能耗监测、智能抄表、远程监控等。而如果接入的物联网设备品牌多又不一样的话,就需要产品层面设计一个物联网接入模块了。本文作者对物联网设备接入产品的设计进行了分析,一起来看一下吧。

在某些B 端产品中,会通过安装物联网设备来提高工作效率,比如能耗监测、智能抄表、远程监测等等。如果接入的物联网设备品牌多、各家协议、数据格式不一致的话,那么就需要产品层面设计一个物联网接入模块,这个模块充当业务层和设备层的桥梁,使得业务层无需关心具体接入设备的品牌、协议和数据格式。

有了物联网接入模块后,接入新的设备时就不需要更改业务层的设计了,也就能够减少业务层的开发工作量,提高整个团队的产出效率。

01 一个反面案例

先给大家看一个没有物联网设备接入模块的反面案例,这样会更好理解为什么需要物联网接入模块。本人曾经接触过一个物联网监测项目,他们的产品选用的物联网设备只有一个厂家,因此产品设计没有多考虑,开发这边也是为了尽快上线,于是设计了下面这样的产品架构。

物联网设备接入产品该怎么设计?

结构很简单,实现起来确实也很快,产品顺利上线了。随着业务的发展,从成本和厂家设备的质量综合考虑,公司又选了另外一个厂家的同类设备,但问题来了,新厂家的数据格式和之前的厂家的完全不同,为了接入新设备,他们的产品架构变成了下面的样子。

物联网设备接入产品该怎么设计?

业务模块变“胖”了,需要新的业务逻辑来对接新厂家的数据 API 接口。更为失误的是,他们的前端页面的字段名称是按照之前的设备写死的,这就意味着前端应用也需要按不同的厂家类型做适配,如果是厂家1就按厂家1的数据格式展示,如果是厂家2就按厂家2的数据格式展示。

之后,公司又引入了新的厂家,然后开发同学就“炸锅”了 —— 简直就是在人工制造“代码屎山”啊!引入一个新的厂家,一是整个开发链条从设备数据 API对接,到业务逻辑处理再到前端页面展示全部都需要跟着改动;二是整个业务的代码里面堆积了一堆按不同厂家做的条件判断,越来越臃肿,难以维护。开发同学怨声载道,对产品经理的配合度自然会下降很多。

02 问题在哪?

出了问题,自然要看看怎么“甩锅”。那么这里到底是产品同学的问题还是开发同学的问题呢?个人觉得都有问题,但是产品是源头,责任更大一些。作为产品经理,应该要具备业务前瞻性。以这个案例来说,物联网设备属于硬件设备,作为公司运营肯定会考虑硬件采购的成本,产品的质量、稳定性。因此,很大可能会使用其他厂家的设备替换。

而且,物联网设备有一个很大的特点就是,设备已经部署后,可能分布在全国各个地方,根本不太可能用一个新厂家的设备完全替换已有的设备。这就意味着,产品设计上需要考虑不同厂家设备的共存情况 —— 也就是要能够支持多个厂家的物联网设备接入。

物联网设备接入需要考虑不同厂家的兼容性,需要能够同时接入不同厂家的同类功能设备。

03 如何解决问题?

先讲我们生活中的一个例子。我们知道不同国家的交流电的电压是不同的,有220伏 ,也有110V的。如果直接接入电器设备,电器设备会因为工作电压超出范围而导致烧毁。

这个问题是怎么解决呢?通过电源适配器来解决,比如下图是一个笔记本的电源适配器,标明了工作输入电压范围是100-240伏,虽然输入电压波动范围很大,但是输出一直稳定在笔记本需要的电压范围内(下图是19.5伏)。

物联网设备接入产品该怎么设计?

适配器就是解决不同的输入源不影响输出的一个中间设备。受到适配器的启发,软件设计领域就产生了一个“适配器”模式。适配器模式就是将不同的输入转换为相同的输出,从而避免业务层和输入直接产生关系。这样,输入源的改变处理全部由适配器来完成,业务层则无需关心输入源的变动。

对于物联网设备接入,我们会发现和适配器要解决的问题是一样的。因此,对于物联网设备接入,我们应该设计一个适配层,作为厂家数据 API 和业务层的桥梁。这个适配层的职责就是接入不同厂家的物联网设备数据 API,然后转换为业务层需要的标准格式数据。

这样,即便是换厂家、换设备,都只需要更改适配层,业务层和前端都不需要做任何改动。有了适配层之后,我们的产品架构就演变成下面的样子。这种架构下,不管接入多少个厂家、多少种设备,都只需要在适配层进行调整,业务模块和前端无需做任何修改。

图中绘制的箭头是单向的,实际上换成双向箭头也是没问题的。如果业务模块需要下发指令到物联网设备,同样也可以通过适配层将标准指令转换为不同厂家设备能够接收的相应指令,接入新厂家设备同样也不需要更改业务模块。

物联网设备接入产品该怎么设计?

04 经验分享

其实上面说的反面案例类似的情况十分常见,出现这样的问题很大程度上是没有类似的产品设计经验。本人曾经负责过一个智能电表抄表模块的产品设计,这里面就涉及到抄表、计费、欠费拉闸断电、充值恢复通电、手动通断电等等业务。

在产品设计时,由于有适配器这样的概念(实际经验来自做软件开发时的设计模式),所以提前考虑了做适配层。并且,明确和开发同学交待要考虑未来新的厂商设备接入。到后面,确实也因为采购成本原因,采购了另一个厂家的设备。由于有适配层的存在,新厂家的智能电表非常快就接入到产品中,而业务层并没有做任何改动。要知道,如果要更改业务层的抄表、计费、通断电指令那开发的工作量就非常多,而且还容易出现纰漏导致 bug。

对于物联网设备适配层,通常来说需要下面几个模块:

1)设备档案

设备档案主要维护设备的基础信息,其中关键的一个信息就是与厂家平台对接的唯一标识,通常会是设备编号或 IMEI。在产品设计的时候,需要考虑支持移动端登记设备档案以及批量导入。移动端登记是方便设备安装的时候边安装边登记;批量导入是应对大量设备的批量录入,提高效率。

2)接口管理

与不同厂家的对接接口管理,这里有两种处理方式,一是开发直接在代码层面完成,二是通过页面配置完成。第二种会更复杂一些,但是通用性更强。

3)数据格式配置

将厂家的设备数据转换为业务模块的标准格式数据,和接口管理一样,一种方式是开发在代码里完成,另一种方式是通过配置完成。通常,如果是配置会和接口配置一起完成,将厂家的设备数据字段映射到业务模块相应的字段。

异常监控:异常监控包括两种类型,一个是厂家的服务可用性监控,另一个是业务数据层的监控。可用性是防止厂家的服务不可用导致自有业务的不可用;业务数据层的监控是监测异常数据,方便及时发现业务层面的问题。比如我们的智能电表就遇到过一个极端的案例,由于线路故障导致抄表数据异常。

另外,如果你的产品是 SaaS 平台,那么建议是按照“开箱即用”的理念来设计物联网设备接入模块。什么是“开箱即用”?那就是脏活累活由平台运营来做,客户在业务系统中只需要关注业务模块即可。

以我们的抄表为例,我们把设备档案这个最繁杂的工作留给了平台运营层面完成。我们会在平台层面完成设备档案的录入,然后将设备分配给客户的对应的业务单元。到了客户这边,只需要完成业务层面的计费、通断电规则就可以像使用非智能表一样使用我们的智能抄表功能。

05 总结

本篇以实例的方式介绍了物联网设备接入的产品设计。可以看到,通过引入适配层可以有效实现多厂家设备快捷接入而不影响业务层。

对于产品经理而言,在做物联网设备接入或者类似的功能模块时,应当具备业务前瞻视野,提前预判可能的变化,在产品设计上引入应对变化的适配层,从而提高产品迭代的速度、减少开发工作量的同时提高产品的稳定性。

作者:产品海豚湾;公众号:产品海豚湾(ID:pm-dophin-bay)

本文由@产品海豚湾 原创发布于人人都是产品经理,未经许可,禁止转载。

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

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