本文對 AI 硬體產品開發中各階段的資源配置展開了資源配置分析、並簡單介紹了項目管理到底在做什麼。
項目流程詳解，針對上一篇《項目管理：智能硬體項目研發流程》的細化，解釋任務串並行。
上一篇文章《智能硬體項目研發流程 ｜項目管理》發布後，通過各個平臺找到我並且加我微信與我交流的很多，實在應付不過來，文字交流很是不方便且效率低下，在此萬分抱歉。
這也讓我驗證了一個事情，智能硬體產品經理產品與項目一肩挑還是有不少公司是這麼做的。
上一篇，是圖文版本，需要將流程表與任務排期結合來看才能理清楚各部門之間怎麼流轉。
本篇是純文字版，將會比較枯燥、囉嗦。因為各部門之間串行與並行同時展開，不像一根線貫穿到底的清澈。
本篇也不討論研發之前的產品定義、評審等環節。從項目立項著手研發開始。
一般產品經理完成產品定義，評審通過或者預研通過就開始移交給項目了。產品經理輸出《產品需求文檔》《產品配置表》。
一、資源配置分析
項目經理分析產品經理的需求，需要用哪些資源來做成這個項目。也就是這個產品涉及到哪些部門、第三方（板廠、模具廠、代工廠或者方案商）。可能產品有些需要第三方支持，比如雲平臺。
這些在項目分析的時候做到心中有數，哪些是提前做，哪些是在研發時間間隙中去完成的。也就是有個總體規劃，保證時間完美的銜接，不要讓某個任務因為資源不到位導致項目中斷，處於等待中。
這是在項目啟動前，項目經理的分析梳理工作。
這一步，規劃很重要，需要保證自己從全局去考慮，無遺漏。
本篇假定涉及硬體（HW）、系統及應用軟體（SW）、結構（MD）、外觀設計（ID）、網際網路平臺。下面進行研發流程銜接說明，將按照項目啟動、設計開發、設計驗證、生產驗證、生產發布這個主脈絡進行囉嗦敘述，再強調一遍，因為涉及串行與並行，可能有點兒跳躍。
01 項目啟動
分析完成，製作一張任務排期表，組織召開立項會議。
這個表格使用的是 micro Project 軟體，只是個工具。方便易用就行。我喜歡按照部門進行排期，因為各部門做到哪一步一目了然。您也可以按照時間軸循序進行排期。
這個計劃包含了組建項目小組、制定項目計劃、召開啟動會議。從上圖中均可看出。
項目小組：涉及的部門以及責任人，如果你手上有幾個項目在同時進行，你可以單獨列一張成員表，方便查看每個工程師手上的項目，以便合理分配任務。項目計劃：任務的起止時間節點，單獨列出關鍵任務節點，細項任務很可能延期，但是一定保證關鍵任務不要延期。項目會議：明確責任人、總體計劃以及項目目標。目的是動員全體成員以確保明確各自任務以及時間節點，並且讓成員理解項目目標，這樣大家的發力點是一致的，凝聚團隊。會後，項目經理輸出《項目立項會議記錄》發往各部門以及抄送老闆，固化會議成果。
02 設計開發
項目啟動後，硬體、系統及應用軟體、ID、網際網路平臺（雲服務、App 等）幾乎同步啟動。
全新項目一般項目啟動前就已經開始，草圖已經出來了，概念方向已經選定。甚至產品 ID 的 2D 渲染圖已經出來了。
在外觀上體現出來的交互器件擺放比例關係也出來了，比如攝像頭、屏幕、按鍵等。ID 設計到這時候基本就是等待狀態。
延伸型項目，可能就是在原來的外觀上做些調整/修改，這種項目可能在項目啟動的時候才開始外觀設計，ID 工程師根據結構變化等情況與結構工程師討論進行設計。
方案設計：硬體以及系統各自開始進行方案設計，他們之間並行。方案設計完成後，項目組織硬體及系統軟體進行方案評審。項目經理整理輸出《評審報告》。
評審後，硬體、系統部門根據《評審報告》進行修改，然後再次進行評審。
方案設計，硬體方案設計包含系統功能及功能劃分、系統邏輯框圖、組成系統各功能模塊的邏輯框圖、電路結構圖等。需要系統及應用軟體部門參與評審。本篇的重點不在各任務的內容介紹，只介紹任務的串並行，了解嵌入式開發較為詳細的流程脈絡。
另外，我默認「需求分析」這一項產品經理已經組織評審完成了。在需求分析的時候，軟硬體已經有過溝通關於方案上的內容。
詳細設計：方案設計通過之後，軟硬體就開始各自的詳細設計，軟硬體又進入並行開發。
硬體工程師開始原理圖設計，完成後，硬體部門內審，軟硬體共同評審。
在此階段，硬體並行的工作任務是根據 2D ID 設計圖進行元器件擺件，輸出「擺件圖」。
堆疊工程師拿到元器件擺件圖之後進行「堆疊設計」，評審，然後輸出「堆疊圖」。
此時需要硬體或者項目經理/產品經理/採購提供元器件的規格書（比如：攝像頭、電池、屏幕、喇叭等）
ID 工程師拿到「堆疊圖」後，根據堆疊進行優化。確認沒問題後，ID 可以進行 3D 建模，輸出「3D 建模文件」。ID 設計完成也可以用 3D 列印出來看看實體效果。
硬體、結構、ID 這三個部門在此階段是相互溝通協調的。因為 ID 工程師考慮，這個元器件這樣放會影響外觀，增加厚度等等問題；結構會考慮 ID 這樣調整會造成結構幹涉、散熱等問題；也會涉及到硬體板子空間、天線擺放等問題。
結構工程師拿到「3D 建模文件」後，開始進行結構詳細設計。並且輸出「板框圖」。
硬體工程師拿到「板框圖」後，根據「原理圖」進行 Layout(PCB 設計)，完成後評審、修改、評審。評審通過後輸出「PCB 資料（原理/位號/坐標/鋼網/測試點/Gerber）。同時輸出《電子 BOM 清單》。
採購拿到《電子 BOM 清單》後進行採購。拿到「PCB 資料」後開始投板，進行 PCB 制板（或叫做打板）。
PCB 制板回來後，硬體工程師進行檢測（一般目檢），無問題後，通知板廠進行貼片。
PCBA 回來後，硬體介入，看看電路是否有問題。軟體也開始介入了，驗證電路元器件功能是否正常。
PCB 設計的同時，結構設計也在進行詳細設計。
結構設計完成之後，組織硬體、ID 進行評審，修改完成之後，輸出《MD 圖紙》。將《MD 圖紙》【也可叫（結構 3D 圖檔）】、《結構 BOM 清單》發往模廠進行開模評審，然後再溝通評審、修改。
結構設計評審通過後，先用 3D 列印或者發出去做結構手板。
這時候，結構評審一般評審沒啥大問題，需要 ID 改動的概率比較小。可以通知 ID 出《3D 渲染圖》《CMF 文件》，用於試模的時候做外觀生產，以及宣傳文件設計。
結構手板回來後,用 PCBA 試裝,驗證結構設計的問題點。將影響硬體和結構的問題一併修改之後重新制板或者修改結構設。
所以這個階段硬體、結構、ID 三個部門之間基本是串行的，依賴對方的輸出才能進行工作;待他們各自獲取到需要的支持才進入並行。
03 設計驗證
經過上面設計開發過程，硬體、機構、ID 三方基本上磨合的差不多了，進入設計驗證。
PCBA 改板回來後，一般基本上就沒有太大的問題了。也有可能第一版 PCBA 回來就沒有太大問題，不過複雜嵌入式設備這種概率很低。
我們在硬體、結構、ID 聯合開發過程中，系統及應用軟體一直在默默的開發過程中，與他們是並行的。軟體是開發板或者 PC 端模擬環境下開發。
PCBA 回來後，將軟體燒錄進去，在真實硬體環境上進行開發、優化。
軟硬體聯合開發（俗稱系統聯調）。
聯調是整機性能提高、穩定的重要環節，也是驗證設計是否達到的唯一方法。
聯調的過程中，硬體和系統軟體是配合完成的，可能也有結構參與，因為硬體某些元器件的改動可能會影響到結構。
系統聯調過程中，結構/硬體/軟體會有 N 多相關問題，主要是軟硬體的問題點。
一旦聯調及測試結果有了比較明朗的結果後，這時候就可以投模了。採購將 《MD 圖紙》發給模具廠開模。
一般情況下，結構手板確認沒問題就可以投模了，這個可以根據項目相性質決定。
試模結構件回來，組裝一些樣機，給到硬體、軟體、測試、網際網路平臺相關工程師進行整機聯調，稱之為樣機驗證。
聯調過程就是不斷的測試、修改、評審、測試。
在聯調過程中，硬體沒啥大問題，只要不涉及到認證部分的改動就可以送去認證，可以直接拿試模的樣機去做認證，以便不影響上市時間。
認證周期比較長，一般都需要 30 天左右，甚至更長，因此需要根據情況提前安排。認證根據產品類別以及需要進入的市場選擇做哪些認證。
此階段可以開始做包裝設計、產品機身上的標籤貼紙設計、說明書等。並且發出去打樣確認效果。然後封樣等待生產。這個過程比較快，沒那麼複雜。
只要不等到發出試產通知再去設計這些即可。根據工程師的時間安排製作就可以。
最終的目的是不要因為這些小的東西導致生產等待，比如試產樣機已經在產線上了，貼紙還沒回來。
聯調完成，出具《軟體測試報告》《硬體測試報告》，然後進行評審，評估是否可以進入小批量試產。
04 生產驗證
根據《產品測試報告》《產品可靠性測試報告》進行評審，判定是否進入試產，出具《產品可生產性評審報告》。
然後就開始小批量試產。
將設計驗證過程中，籤樣的電子元器件、結構及外觀件、電子 BOM 清單、結構 BOM 清單、CMF 文件、絲印文件、包裝清單發往工廠。
發出籤核的試產申請，通知工廠相關人員、採購，進行試產備料，以及生產工具製作。
NPI 工程師製作 SOP（生產指導文件），這個也可以在設計驗證的樣機組裝時就開始，試產前再確認/調整也可以。
試產的時候，組織硬體、軟體、結構跟線（跟進產線），隨時解決生產問題。
試產完成，組織研發（硬體/軟體/結構）與工廠相關人進行試產總結，出具《試產報告》。
根據《試產報告》，各問題點涉及方進行修改。
領取試產機器進行一致性、可靠性等測試。
問題改進完成，再次小批量試產，重複上述動作。
然後，評審是否可轉入量產。
05 生產發布
可進入量產時，將最後確認的結構/硬體元器件等進行重新籤樣。將生產需要的文件，各種 BOM 清單發送給工廠。
更改電子版的電子器件/結構件/包裝 BOM。
組織市場、運營等培訓產品知識。
06 網際網路平臺
網際網路平臺（雲服務/後臺/App/小程序等）就不詳細介紹了，在設計驗證階段，他們已經介入了。
軟體的更新迭代我個人認為相對嵌入式要簡單些，因為就算錯了，更改成本低，時間快。
比如，硬體已經到客戶手裡了，再去售後，成本和品牌影響都很大了，用戶體驗也會收到很大的影響。
二、項目管理到底在做什麼
在一個產品落地的過程中，產品經理和項目經理的角色和出發點有一定的差異。如果您是產品經理同時負責項目管理，那麼在產品/項目生命周期中切換身份，需要做好權衡和取捨。
在成本、進度和範圍之間，平衡取捨。
因為有一些需求和改進點，放在下一個版本中迭代完成，未嘗不是一個更好的選擇。AI 硬體某些屬性功能是可以做到的，不想以前的電視等產品，出廠即定型。
以上，寫了那麼多，核心無非四個方面：
本文由 @AI 產品觀 原創發布於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議