本文作者跳出他互聯網醫療的舒适區後，開始設計一款家庭智能機器人産品，在對兩種産品進行比較後，發現智能硬件産品存在複雜性、差異性、已知性、未知性、周期性這5個特點。本文以一個智能硬件産品的新人視角，對這5個特點進行了分析，一起來看一下吧。

個人在産品經理這個崗位也大約有6年之久，其中前5年一直在互聯網行業謀生活，而且一直在一個一直被稱之為的“朝陽行業”——醫療行業，從起初的小功能的優化，到負責一個産品端，直至最後到整個産品線的負責，甚至到對外（B端）整個産品方案的輸出以及售前的産品宣講和售後的産品培訓，吃飯的家夥也從寫邏輯畫圖的Axure、X-mind回到了講故事的PPT，可是等了這麼久，醫療還在朝陽，日出始終沒有冒頭。

機緣巧合年前跳出了互聯網醫療這個舒适區，開始設計一款家庭智能機器人産品，由于是公司的一個嘗試性項目，所以在人員不足的情況下，所有與産品設計相關的工作内容均有涉及，還好基本功紮實，但是這近一年來也确實遇到了不少的挑戰，可以說痛并emo着。

這裡從一個智能硬件産品的新人視角，從智能硬件産品設計的角度，結合個人對智能硬件産品的理解，将其與個人在舒适區（互聯網）的産品設計工作進行比較，發現智能硬件産品（主要還是與硬件配套的軟件設計）設計階段存在的5個特點或稱之為現象，與大家分享：

1. 複雜性：産品組成的複雜性，軟件-硬件-算法。
2. 差異性：相對互聯網産品，智能硬件産品交互方式的差異，以及産品經理輸出成果的差異。
3. 已知性：國家标準和行業做法對硬件産品的設計和算法需求的描述提供參考。
4. 未知性：算法需求邊界的未知（對剛換行的産品來講）。
5. 周期性：相較于互聯網産品敏捷開發，智能硬件産品的開發的長周期不可回避。

一、複雜性

也許是本人初次接觸智能硬件産品，也許是這個項目是公司的一個嘗試項目，隻安排了我這麼一個産品來負責整體的軟件、硬件交互的設計讓我才有如此的感覺（智能硬件行業的産品大佬多多指教）。

先來看看之前在舒适區做的一款互聯網醫療産品：從0-1搭建的涉及患者、醫生、藥師、村醫、藥代、企業員工、醫院管理人員、平台運營人員等8種角色的3條業務線11個用戶端的産品體系。現在回頭看貌似也比較複雜，也許是在舒适區，輕車熟路，唯手熟爾，當時确實沒有覺得有多複雜。

經過對智能硬件産品知識的不斷了解，以及最近一年項目的經驗總結，當前市面上可移動的家庭機器人大緻會涉及到7個重要的組成模塊：本體APP、手機APP、硬件本身、内容生态、運營管理後台、語音平台、算法平台。

這其中就有觸碰到我的逆鱗的區域，讓我踩進了盲區：硬件、語音、算法；其中硬件部分是完全不懂啊，不過慶幸的是硬件産品的定義在我介入這個項目前已由另一個硬件同事完成了，但是悲劇的是在我深入介入這個項目時，這位硬件同事已經離職，所以後期開發遇到了什麼問題還得以質問的語氣來找我做決策，隻能提前去了解。

還有就是語音部分，語音可不是之前在互聯網軟件設計時接觸過的語音通話、語音錄入這類功能了，這裡的語音涉及到語音腳本的撰寫、語音指令的定義等等。

最盲的盲區就是算法了，算法可不是之前理解的推薦、查詢邏輯、規則或策略一類的定義，這其中主要指視覺識别相關的類似人臉識别、人體跟随以及雷達相關的導航、路徑規劃一類的了，下文會進一步說明。

這裡我們還是首先看看這7個模塊的定位：

1. 本體APP：結合算法、手機APP以及内容生态和語音平台，調動機器人按照設定的業務邏輯執行相關任務。
2. 手機APP：負責遠程遙控、管理和查看機器人的授權、任務狀态等信息，與本體APP、管理後台、三方内容庫均有交互，交互類型主要以圖形（GUI）為主。
3. 硬件：包含機器人的産品定義、ID設計、結構堆疊以及執行器、芯片、傳感器、顯示器等元器件的選型和規格定義。
4. 内容生态：根據産品的定位接入對應的第三方服務資源，例如：音樂、視頻等。
5. 運營管理後台：對産品中涉及的用戶、設備、内容、等其他數據以及三方生态服務進行查看和管理。
6. 語音平台：涉及喚醒、指令、任務對話、暢聊對話等語音交互。
7. 算法平台：主要設計語音、視頻、雷達等相關的算法。

常規情況下，就這麼複雜的一款智能硬件産品該配備幾個産品經理呢？個人曾嘗試去咨詢了下我身邊認識的大佬，得到的結果是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大白，一名産品經理行業的小獸醫經理行業的小獸醫

本文原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自 unsplash，基于 CC0 協議

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部