筆者結合自己的項目管經歷，向我們介紹了如何管理智能硬體項目的研發流程。
我曾在《AI 智能硬體｜產品思維與項目思維》中舉了蔚來汽車的例子說明項目管理的重要性，另外在知乎上寫了一篇關於智能硬體研發流程的文章，只是個開頭瀏覽量也有 1700 左右。
為了寫這篇文章，畫總體流程以及編制相對詳細的表格，因此花費了不少的時間，導致一周未更新。
哎，以上都是廢話，從總體流程開始吧！
一款產品，我們通常說從 0 到 1，包括了市場階段的產品需求、產品實現；從 1 到 100，包括了產品的銷售、運營、維護等。
這裡講的研發流程僅指產品需求已經確定了，將產品需求變為產品的研發過程，不包含前期的市場部分，也不包含產品上市以及運營過程。
智能硬體看似複雜，拆解出來脈絡很清晰。包含硬體（HW）、軟體（SW）、外觀（ID）、結構（MD）、網際網路平臺。
其中軟體包含板級支持包（BSP）、底層引導程序（bootloade）、系統與應用程式、算法，這些不展開來講，找固件打包的工程師就 OK ，一般所有的程序都匯總到他那兒了。
作為項目經理，不太需要進行深入的了解，當然能夠深入更好，但作為產品經理還是更深入一點較好。
網際網路平臺，這個包含雲服務、後臺、App、小程序等。常見的是前三個。跟進對應的工程師就好。
總體流程圖如下：
可能到這兒，脈絡上比較清晰了，但是具體到操作執行上，怎麼跟細化還是不太清楚。因為有些任務是串行的，有些是並行的。一個細項任務牽扯到幾個部門。
很多項目管理人喜歡將項目研發分為EVT階段、DVT階段、PVT階段、MP階段和維護階段，我一般不這樣分，對於這些總結性的項目管理概念熟知於心即可，不必要過於追求。
因為有時候，你會發現，因為需求的改動、比較重要的 BUG 等原因會改變項目的階段，比如從 DVT 階段又回到了 EVT 階段。
另一個原因是智能硬體產品一般更加適用瀑布流開發，網際網路的敏捷開發不太適用於智能硬體。所以這一節只做簡單介紹，作為項目管理有個概念認知就好。
下面根據我自己經驗，我的心理認知進行階段界定。
EVT 階段：（Engineering Verification Test），指工程驗證。一般在工程樣機之前的研發行為，我都稱之為工程驗證。
這個階段，目的是工程驗證。儘可能的發現設計問題，方案對比。
最終拿到的是工程樣機，用於樣機整機測試，判定是否可以開模。
DVT 階段:（Design Verification Test）,指設計驗證測試。最終拿到的是試產的整機樣機，用於多方聯調，驗證優化。
上一個階段，完成產品的雛形，這個階段繼續上個階段的設計開發、優化。MD 詳細設計完成，開始投模、試模、修模、顏色調製等。
試產模具，組裝整機，進行硬體/結構的整機測試。軟硬體、結構、網際網路平臺多方聯調。比如軟硬體的穩定性、可靠性、性能等；軟體與網際網路平臺（雲服務/App等）聯調測試；硬體與結構的聯調測試，比如散熱、結構強度等。
另外，這在這階段關於產品的貼紙、說明書、包裝等可以開始設計/打樣，然後等待，因為這些時間周期比較短。
如果軟硬體狀態比較理想，在這個階段儘早安排認證。因為認證周期非常長，基本在 40 天左右，別等到產品快要量產了，認證還沒出來，影響銷售。
總之，這個階段就是聯調、測試、試模、打板、試產。
PVT 階段 ：（Process Verification Test），指生產驗證。進行小批量產，摸清生產工藝，測試工藝，為大批量產做準備。
這個階段依然會進行各種驗證，以及解決上一階段遺留的一些小問題。但主要的精力放在一致性、設計（細節，比如按鍵手感不好，幹涉等）調整上。
各部門處於生產支持模式，比如工程部製作 SOP（標準作業程序），結構部幫忙解決生產上的結構問題。與生產相關的測試工具、生產工具、燒錄工具、產測工具的支持。
所有的生產支持文件規定當送到工廠，量產軟體/量產硬體BOM/量產結構BOM，結構/元器件終版籤樣。
總之，這個階段就是為了保證產品量產。 量產順利，效率高，不良率最低，產品一致性夠高。
關於研發階段就這麼多，其他的就不講了。這個分類只是自己項目管理用，工程師其實不關心。自己做到心中有數，自己的產品到了什麼階段，離目標還有多遠，從全局角度考量如何把控項目進度。
這一節是我最想講的，因為我剛做研發端產品的時候，需要管項目。
我的切身體會是，不知道各項細化任務之間怎麼串起來，不知道從哪裡下手，該找誰並拿到什麼輸出作為下一步的開始。網上找了很多資料都是關於項目階段的介紹，類似上面一節的介紹。
因此想寫一寫細化流程，但限於文字描述的直觀性較差，先看一個表格，然後稍微文字說明。
/簡單文字描述/
產品規格書/產品定義出來了之後，產品會組織技術評審。通過後就正式開始立項，排研發計劃了。有些項目會先進行預研，然後才導入正式研發。
一般新產品，首先開始 ID 草圖設計，然後出 2D 渲染圖。
立項後，硬體/軟體/結構/網際網路平臺開始做方案設計、評審（軟硬體評審需要雙方參與，他們倆高度相關），通過後開始做詳細設計。
硬體，這時候開始畫原理圖、器件擺件。
結構，根據硬體的器件擺件圖、關鍵器件（電池/屏幕/攝像頭/SPK 等）與 ID/硬體部門充分共同進行堆疊設計。滿足各部門的需求，最終完成產品定義的要求。
ID，拿到結構的堆疊設計圖，進行 3D 建模，導出建模圖給結構。
結構，根據 ID 的 3D 建模圖做詳細結構設計。導出板框圖給硬體。詳細結構設計完成轉給模具廠。
硬體，根據板框圖 Layout，然後出 PCB 資料，評審/投板。
模具廠，根據結構設計開模。
然後就是軟硬體聯調，結構/硬體/模具聯合解決驗證後的問題點。
因為互相關聯穿插，文字很難描述。一看《項目管理研發流程》表格，了解全貌，二看下面的《任務排期》。
這一節重點關注各個任務輸出的文檔文件，後面我組織一下語言做一個純文字的介紹，怎麼串行，怎麼並行，相應任務輸出什麼樣的文檔文件以及有什麼作用。
任務排期的關鍵是將各模塊拆分成較細立刻的任務，將各個任務串起來。
依然上圖：
這個任務排期可能與你的有細微的不一樣，我的是根據項目有相應裁剪，順序略微調整，但是基本邏輯是這樣的。
項目經理的天職就是保證項目按時按質交付。因此，項目經理需要緊盯項目，推進項目。
一個智能硬體項目涉及的面非常廣，溝通的人也非常多。如果同時跟進幾個項目，事項任務更加繁複，不可避免會造成遺漏，溝通不到位，支持不夠及時等等狀態。
我們在任務排期的時候將任務拆分成中度粒度，為了不遺忘，支持及時，我們可以制定一個任務清單，拆的非常細。
這個用 Excel 就好，我喜歡用這個。每一個任務後面是一級任務/二級任務、做出什麼決策、由誰負責、什麼時間完成，任務狀態等。
例如，ID 設計
總之，這是一份行動清單。
上一節提到項目事項任務繁複，最為常見的是管理不到位造成混亂；另一個是項目問題涉及到多部門造成卡殼。
解決問題的方式是，找到目前現狀與目標之間的關鍵障礙，想辦法清除障礙。
解決思路是：
解題思路有了，但是項目管理涉及的面非常廣，而且又不懂技術，怎麼辦呢？
拆解問題，將問題拆解成完全窮盡，相互獨立的任務。當然這個是與工程師溝通進行的，與相關責任人開短會定性分析。這個結構化思維在產品思維最後一篇文章介紹過，可以回看一下。
表達能力，往往與工程師溝通會出現溝通錯位，這時結構化的表達很重要。
先結果，後過程：反向推導，這樣保證溝通目標是確定的。
先全局，後細節：從全局出發，限定範圍，不要擴散問題，然後再確定細節，不能陷入細節不能自拔。
最後，一定要復盤，在溝通的最後複述問題及溝通出來的解決方案，確保沒有錯位。
項目管理，本質上還是邏輯思維能力和結構化思維能力。做好項目管理需要不斷的學習、反思、復盤，提升底層的邏輯能力。
作者：Arvinzhou，公眾號：AI 硬體產品官（ID：aipm001）
本文由 @Arvinzhou原創發布於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議