转行智能硬件产品后才发现的二三事
个人在产品经理这个岗位也大约有6年之久，其中前5年一直在互联网行业谋生活，而且一直在一个一直被称之为的“朝阳行业”——医疗行业，从起初的小功能的优化，到负责一个产品端，直至最后到整个产品线的负责，甚至到对外（B端）整个产品方案的输出以及售前的产品宣讲和售后的产品培训，吃饭的家伙也从写逻辑画图的Axure、X-mind回到了讲故事的PPT，可是等了这么久，医疗还在朝阳，日出始终没有冒头。
机缘巧合年前跳出了互联网医疗这个舒适区，开始设计一款家庭智能机器人产品，由于是公司的一个尝试性项目，所以在人员不足的情况下，所有与产品设计相关的工作内容均有涉及，还好基本功扎实，但是这近一年来也确实遇到了不少的挑战，可以说痛并emo着。
这里从一个智能硬件产品的新人视角，从智能硬件产品设计的角度，结合个人对智能硬件产品的理解，将其与个人在舒适区（互联网）的产品设计工作进行比较，发现智能硬件产品（主要还是与硬件配套的软件设计）设计阶段存在的5个特点或称之为现象，与大家分享：
- 复杂性：产品组成的复杂性，软件-硬件-算法。
- 差异性：相对互联网产品，智能硬件产品交互方式的差异，以及产品经理输出成果的差异。
- 已知性：国家标准和行业做法对硬件产品的设计和算法需求的描述提供参考。
- 未知性：算法需求边界的未知（对刚换行的产品来讲）。
- 周期性：相较于互联网产品敏捷开发，智能硬件产品的开发的长周期不可回避。
一、复杂性
也许是本人初次接触智能硬件产品，也许是这个项目是公司的一个尝试项目，只安排了我这么一个产品来负责整体的软件、硬件交互的设计让我才有如此的感觉（智能硬件行业的产品大佬多多指教）。
先来看看之前在舒适区做的一款互联网医疗产品：从0-1搭建的涉及患者、医生、药师、村医、药代、企业员工、医院管理人员、平台运营人员等8种角色的3条业务线11个用户端的产品体系。现在回头看貌似也比较复杂，也许是在舒适区，轻车熟路，唯手熟尔，当时确实没有觉得有多复杂。
经过对智能硬件产品知识的不断了解，以及最近一年项目的经验总结，当前市面上可移动的家庭机器人大致会涉及到7个重要的组成模块：本体APP、手机APP、硬件本身、内容生态、运营管理后台、语音平台、算法平台。
这其中就有触碰到我的逆鳞的区域，让我踩进了盲区：硬件、语音、算法；其中硬件部分是完全不懂啊，不过庆幸的是硬件产品的定义在我介入这个项目前已由另一个硬件同事完成了，但是悲剧的是在我深入介入这个项目时，这位硬件同事已经离职，所以后期开发遇到了什么问题还得以质问的语气来找我做决策，只能提前去了解。
还有就是语音部分，语音可不是之前在互联网软件设计时接触过的语音通话、语音录入这类功能了，这里的语音涉及到语音脚本的撰写、语音指令的定义等等。
最盲的盲区就是算法了，算法可不是之前理解的推荐、查询逻辑、规则或策略一类的定义，这其中主要指视觉识别相关的类似人脸识别、人体跟随以及雷达相关的导航、路径规划一类的了，下文会进一步说明。
这里我们还是首先看看这7个模块的定位：
- 本体APP：结合算法、手机APP以及内容生态和语音平台，调动机器人按照设定的业务逻辑执行相关任务。
- 手机APP：负责远程遥控、管理和查看机器人的授权、任务状态等信息，与本体APP、管理后台、三方内容库均有交互，交互类型主要以图形（GUI）为主。
- 硬件：包含机器人的产品定义、ID设计、结构堆叠以及执行器、芯片、传感器、显示器等元器件的选型和规格定义。
- 内容生态：根据产品的定位接入对应的第三方服务资源，例如：音乐、视频等。
- 运营管理后台：对产品中涉及的用户、设备、内容、等其他数据以及三方生态服务进行查看和管理。
- 语音平台：涉及唤醒、指令、任务对话、畅聊对话等语音交互。
- 算法平台：主要设计语音、视频、雷达等相关的算法。
常规情况下，就这么复杂的一款智能硬件产品该配备几个产品经理呢？个人曾尝试去咨询了下我身边认识的大佬，得到的结果是5个：软件、硬件、导航、语音、算法各一个，还好硬件结构工程师和算法工作师的可以协助进行硬件和算法、导航相关需求的定义，不然作为一个新手如何hold住这些陌生的领域。
二、差异性
1. 交互形式的多样性
智能硬件产品的交互方式呈现多样性，并不像纯互联网应用主要以图形交互（GUI）为主，其中智能硬件产品所涉及的交互方式包含但不限于以下几种：
- 基本交互：主要指直接的硬件实体键的接触交互，例如开关键（短按、长按、连续按…），身体表面触摸板的交互定义等。
- 图形交互：主要指用户通过机器人屏幕操作本体APP，或者通过手机APP进行远程遥控机器人的交互。
- 语音交互：主要指用户通过语音操控机器人进行唤醒、聊天、执行任务的交互过程。
- 体感交互：主要通过身体的动作和姿态与机器人进行交互，例如：人体跟随、手势识别、表情识别等。
- 灯光交互：硬件的组成中一般会包含一种或多种具有一定功能定义的指示灯或者氛围灯来表现当前硬件所处的状态，包括灯的颜色，明暗度，变化频率、时长、组合图形等形式。
智能硬件（机器人）对用户的每一次交互反馈通常不局限于一种交互方式，一般是多种交互方式组合的形式即多模态交互。
例如：早上用户给机器人打招呼，机器人则可能作出以下反应：
- 【图形交互】：屏幕切换出微笑表情。
- 【语音交互】：机器人移动至用户身边，说“主人早上好吖，又是元气满满的一天呢！”，然后播放了一首班得瑞的歌曲“清晨”。
- 【灯光交互】：随着音乐的旋律，机器人身体上的矩阵灯球开始跳动。
- 【体感交互】：机器人跟随着主人来到门口，为用户送行。
2. 产品交付物的不同
同样作为产品经理，无论是互联网行业还是智能硬件行业，需要产出的文档：BRD、MRD、PRD确实一个都不少，但是其中连接产品和开发最核心的产品设计文档PRD，确实不尽相同。
互联网行业的PRD核心侧重于呈现界面设计、业务逻辑、交互逻辑，即该怎么去实现某一项需求或功能，其中主要包含：业务背景说明、业务流程图表、产品架构图表、功能清单列表、业务状态说明、推送消息汇总、全局规则说明、主要页面跳转示意图、需求评审记录、需求修改记录、界面详细设计文档、版本上线说明等。
其中“界面详细设计文档”占据篇幅最大，决定着产品设计在开发侧的落地，也是花费时间最多的一项文档。
智能硬件行业的PRD（0-1的产品）则完整地描述了：为什么要做、如何去做、做成什么样、需要多少成本、存在多少风险等内容，感觉是将PPT版本的BRD和MRD和重要内容进行了扩展然后和当前Word版本的PRD进行了一个组合。
其中主要包含有：文件属性、记录变更、背景分析、需求定义、外观设计、硬件方案、软件方案、算法应用、结构设计、非功能设计、测试要求、成本控制、风险控制等13项。
三、未知性
之前有一个互联网产品经理提出了一个需求：需要APP主题色与手机壳保持一致，随着手机壳颜色的调整自动适应；然后，然后就没有了，听说被“祭天”了。
作为产品经理在设计产品时多少需要知道些当前技术的边界，作为互联网产品经理最简单的办法就是去疯狂体验各种产品，看的多了，然后再结合自己对需求的分解，也就知道大概哪些需求是可以实现，哪些需求是无法实现。
回想之前负责互联网产品时，如果开发对你的需求提出质疑，多是质疑你需求的合理性，以及开发问的最多的是“现在市面是上有产品这么做的吗？”当产品经理找出竞品给到开发时，开发又会拿当前公司的人员和项目时间以及各种投入和条件无法与竞品相比说事。
但是在智能硬件产品设计评审过程中，除了以上这些，还会质疑或者说直接否决需求的可行性，特别是算法需求，导致这些质疑的原因就是产品经理对当前开发能力或者说行业技术能力边界的认知，与算法相关需求可行性遭到质疑有以下几点原因：
1）算法本身限制
行业中确实没有可行或者较好的算法模型来满足提出的业务需求（一般小公司利用的算法模型均是市面上开源的，然后进行算法的优化调试，愿意投入成本和时间去开发创新算法的确实很少，也许那些头部公司才会有这些举措）。
2）公司算法能力限制
行业中存在相应的算法模型应用，但是公司算法人员的认知局限或者能力不足，导致对算法相关需求可行性的否定。
3）硬件设计限制
可以找到相应的算法实现业务需求，但是硬件提供不了算法需要的数据，算法工程师也无法进行无米之炊。
例如：某一个视觉算法需要深度相机采集的数据，但是当前硬件设计只能提供普通相机采集的数据，导致业务无法实现。
4）算力限制
有可行的算法，但是选型的硬件芯片算力不够，无法满足算法的运行。
5）成本限制
有可行的算法，但是如果要进行成熟的应用，后期需要投入大量的人力和购买大量数据进行训练调优，但是项目时间却等不起，或者公司不愿意花这么大的人力和时间成本去做这件事。
另外一个不可知，就是竞品分析的难度：
互联网产品相关的应用APP几乎都是开放注册（B端产品有部分是封闭的），进入即可以进行一个完整的产品体验和分析。
硬件产品则不同，即使下载并注册了硬件相关的应用，在没有绑定硬件的情况下，整个应用APP的分析几乎是没有太大意义的，所以需要进行一个完整的产品分析，那得首先买不止一台竞品，然后全方位地对硬件和软件功能进行体验、拆解和分析。
例如前段时间中信证券拆解了一辆全新的特斯拉Model3，输出了一份长达94页的研究报告《从拆解Model3看智能电动汽车发展趋势》，只能说中信有实力啊（哈哈），但是所在公司是否会动辄大几千上万买一台竞品供工程师和产品设计者进行拆解和分析，这只能看公司的格局和实力啦。
四、已知性
之前在做互联网产品设计时，同样也会考虑国家法规，平台标准之类的规则，根据相关文件设计或修改业务逻辑。
例如：
- 互联网应用（APP）中必须有用户注销功能，否则无法上交应用市场。《App违法违规收集使用个人信息行为认定方法》。
- 互联网医院平台接入规则（要想通过某地方的互联网医院平台的年审，则相应“互联网医院”产品必须按照平台规则进行整改）。
同样智能硬件产品中的硬件、软件以及算法也可以找到一些相关的国家标准和规范，这对于刚接触硬件或算法相关需求设计的产品经理，在不知道算法边界或者硬件的好坏要求时，在国家标准的基础上进行相关需求的描述，是一个很不错的选择（但并不是所有的需求功能都能找到相应的标准和参考）。例如常见的人脸识别需求中涉及的需求描述：
《GB/T 35678-2017 公共安全 人脸识别应用图像技术要求》
1 采集图像
1.1 表情
中性或微笑，眼睛自然睁开，嘴唇自然闭合。
1.2 眼镜
眼镜框应不遮挡眼睛，镜片应无色无反光。戴粗框眼镜注册时宜采集两张图像，一张戴粗框眼镜， —张不戴眼镜。
1.3 遮挡
遮挡物应不遮挡眉毛、眼睛、嘴巴、鼻子及脸部轮廓。
1.4 两眼间距
两眼间距应大于等于60像素，宜大于等于90像素。
1.5 姿态
人脸水平转动角应在±10°以内，俯仰角应在±10以内，倾斜角应在±10°以内。
1.6 亮度和对比度
图像亮度均匀，对比度适中，脸部无阴影、无过曝光和无欠曝光。图像灰度化后脸部区域动态范围在85～200 之间。
1.7 脸部区域
人脸完整，轮廓和五官清晰，无浓妆，图像脸部区域应无编辑修改性处理，几何失真应小于等于 5%，运动模糊应小于等于0.15，高斯模糊应小于等于0.24。
……
2 识别图像
2.1 遮挡
遮挡物应不遮挡眉毛、眼睛、嘴巴、鼻子及脸部轮廓等。
2.2 两眼间距
两眼间距应大于等于30像素，宜大于等于60像素。
2.3 姿态
人脸水平转动角应在±30°以内，俯仰角应在±20°以内，倾斜角应在±30°以内。
2.4 脸部区域
人脸完整，轮廓和五官清晰，无浓妆，图像脸部区域应无编辑修改性处理，几何失真应小于等于 10%，运动模糊应小于等于0.20，高斯模糊应小于等于0.25。
每一个算法模型关注的输入和输出的参数以及前置条件都不尽相同，对于一个纯互联网产品经理，在未接触到算法前，可能不知道对一个算法需求的描述需要对哪些些字段进行描述。
五、周期性
上文已提到过智能硬件产品主要包含：软件、硬件、算法等部分组成；其中软件、算法负责“智能”的部分，但是智能部分的更新迭代，很大程度上都依赖硬件部分的迭代，相较于互联网产品的敏捷开发，两周迭代一个版本，智能硬件产品的迭代周期就不可能这么快了，当然其中单纯的软件和部分算法是可以脱离硬件进行部分迭代的。
硬件部分迭代少则一年，多则两年或更久都是很有可能的。硬件的定义、设计、评审、打样、生产等部分，作为一个新人，目前就不在这献丑了，后续有深入的理解后再给大家分享。
作者
andy，微信公众号：PM大白，一名产品经理行业的小兽医经理行业的小兽医
本文
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
