中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

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

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

一、復雜性

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

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

經過對智能硬件產品知識的不斷了解，以及最近一年項目的經驗總結，當前市面上可移動的家庭機器人大致會涉及到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看智能電動汽車發展趨勢》，只能說中信有實力?。ü撬诠臼欠駮虞m大幾千上萬買一臺競品供工程師和產品設計者進行拆解和分析，這只能看公司的格局和實力啦。

四、已知性

之前在做互聯網產品設計時，同樣也會考慮國家法規，平臺標準之類的規則，根據相關文件設計或修改業務邏輯。

例如：

• 互聯網應用（APP）中必須有用戶注銷功能，否則無法上交應用市場?！禔pp違法違規收集使用個人信息行為認定方法》。
• 互聯網醫院平臺接入規則（要想通過某地方的互聯網醫院平臺的年審，則相應“互聯網醫院”產品必須按照平臺規則進行整改）。

同樣智能硬件產品中的硬件、軟件以及算法也可以找到一些相關的國家標準和規范，這對于剛接觸硬件或算法相關需求設計的產品經理，在不知道算法邊界或者硬件的好壞要求時，在國家標準的基礎上進行相關需求的描述，是一個很不錯的選擇（但并不是所有的需求功能都能找到相應的標準和參考）。例如常見的人臉識別需求中涉及的需求描述：

《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。

每一個算法模型關注的輸入和輸出的參數以及前置條件都不盡相同，對于一個純互聯網產品經理，在未接觸到算法前，可能不知道對一個算法需求的描述需要對哪些些字段進行描述。

五、周期性

上文已提到過智能硬件產品主要包含：軟件、硬件、算法等部分組成；其中軟件、算法負責“智能”的部分，但是智能部分的更新迭代，很大程度上都依賴硬件部分的迭代，相較于互聯網產品的敏捷開發，兩周迭代一個版本，智能硬件產品的迭代周期就不可能這么快了，當然其中單純的軟件和部分算法是可以脫離硬件進行部分迭代的。

硬件部分迭代少則一年，多則兩年或更久都是很有可能的。硬件的定義、設計、評審、打樣、生產等部分，作為一個新人，目前就不在這獻丑了，后續有深入的理解后再給大家分享。