具有嵌入式軟件開發的敏捷硬件

構建適合產品/市場的複雜硬件和軟件生態系統是一項艱鉅的任務。 根據 CB Insights 的一份報告，雖然大多數硬件初創公司最終因資金不足而失敗，但最大的根本原因實際上是對其產品的需求不足。 這只強調了產品經理角色對硬件初創公司的重要性，因為他們的主要目標是找出客戶需求和痛點，以交付成功的產品。

我經營的最後一家公司為停車行業創建了一個由網絡、移動、嵌入式軟件應用程序和硬件設備組成的生態系統。 硬件產品策略是我日常工作的一部分，這讓我嘗試了各種硬件產品開發工作流程。 儘管從事硬件產品工作 10 年並擁有電子和電信學士學位，但我在工作中仍然有很多東西要學習。 我創建了下面的指南，希望您能夠比我更快地在具有嵌入式軟件空間的硬件中加快產品管理的速度。

硬件產品管理的挑戰

雖然 SaaS 和移動應用程序可以使用敏捷框架輕鬆開發，但嵌入式軟件和硬件設備開發的獨特條件使得應用敏捷原則變得更加困難。 在第一部分中，我們將介紹造成複雜性的硬件開發的特徵。 並非所有人都有直接的解決方案，但有一些方法可以通過採用特定的硬件開發策略來降低難度，這將在下一節中介紹。

專業技術人才在當地難找

創建新的硬件產品比迭代現有產品要困難得多。 它涉及大量的原型製作創意和經驗，這在大學裡很少教授。 一些大學甚至沒有原型設計設施或必要的工具來開發這些技能，而這種經驗幾乎完全是在擁有研發中心的大型硬件公司中獲得的。 因此，尋找具有相關專業知識的本地專業人士可能非常困難，導致許多硬件初創公司創始人需要通過遠程招聘來擴大他們的人才庫。

版本控制系統不適應硬件設計

大多數版本控制系統 (VCS) 都面向支持文本格式，因為它們是為軟件開發協作工作而創建的。 在涉及硬件開發的項目中，信息被封裝在藉助 OrCAD 等特殊工具創建的設計文件中。 其中一些工具僅支持二進製文件，這些文件甚至沒有經過優化以在 VCS 中使用。 CADLAB 是創建硬件兼容 VCS 的一項相對較新的嘗試，希望在不久的將來會有更多類似的工具。

硬件生產設施異地化

硬件生產設施通常位於另一個地區、國家或大陸。 硬件生產商和製造商之間的溝通需要特別考慮，並且是成功交付產品的關鍵。 成功的溝通需要更多的戰略框架，以確保產品的質量，並確保它能夠應對動態的產品市場驗證階段的變化。 為了實現這一點，硬件生產商需要創建許多發送給製造商的詳細規範。 協作框架必須確保信息的快節奏交付和規範生命週期的管理，因為它們很容易很快過時。

硬件更改不太靈活

軟件初創公司中流行的運營模式會在早期階段犧牲質量來換取速度。 就連 Facebook 也在相當長的時間裡倡導“快速行動，打破常規”的口號。 另一種熟悉的方法是“假裝它，直到你成功”。 這適用於軟件初創公司，因為廉價的基礎設施成本和簡化的編程框架允許開發人員每天部署代碼更新。

雖然這種開發方法已經慢慢滲入硬件領域，但這是該領域的一個不幸趨勢，因為進行和部署硬件更改要困難得多。 開發成本抵消了通過快速和頻繁發布所獲得的價值，因此在設計階段投入更多資金以創建完善的硬件架構實際上是一種更理想的策略。

眾籌的陷阱

許多初創公司都陷入了這樣一種觀念，即發起一場成功的硬件眾籌活動就等同於市場驗證。 對於涉及硬件組件的產品，眾籌往往最成功，特別是因為我們無意識地渴望與物理對象相關的所有權。 然而，眾籌並不是為了大規模驗證你的產品，而是一種為早期產品開發提供資金的民主方式。 不幸的現實是，許多成功開展眾籌活動的公司隨後發現很難或幾乎不可能擴大生產規模，因為他們沒有大規模驗證市場。

認證、法規和批准

所有硬件產品都需要某種認證才能出售。 這是將硬件產品推向市場的早期階段最容易被忽視的步驟之一。 認證約束將如何影響產品計劃和申請開發的框架？ 將認證和其他批准作為項目里程碑計劃項目的早期階段並不少見，然後才有條件地回溯到啟動階段。 相反，產品經理可以以更像瀑布的方法仔細分析法規、依賴關係和產品計劃戰略決策網關。

硬件產品管理的機會

既然我們已經涵蓋了硬件與嵌入式軟件領域存在的一些挑戰，現在讓我們看看如何使開發過程更加簡化和可預測，以抵消硬件開發的固有困難。

將敏捷融入硬件開發

經驗豐富的產品經理意識到使用嵌入式軟件構建硬件產品背後的挑戰，試圖利用新技術發展創造的市場機會。 他們學會平衡加快上市時間，而不影響從規劃階段產品成功的可能性。 大多數情況下，這是通過水-scrum-fall方法形成的。

產品構思階段盡可能詳細地擴展產品原理、目標和高級功能。 優秀的產品經理會花更多的時間來完善這一階段的可交付成果：願景、使命、機會評估、硬件產品目標和功能。 這是產品的北極星，在開始處理任何類型的硬件原型之前需要足夠清晰，因此建議使用瀑布方法。

為硬件產品製定完善的需求和功能規範以及驅動硬件產品的嵌入式軟件的良好技術架構至關重要。 要求和規範的更改應該受到懲罰，而不是在整個團隊簽署後才鼓勵。

開發嵌入式軟件時可以使用標準的 Scrum 方法。 就時間和金錢而言，調整和改進軟件實現以使用預定義的硬件架構比反之亦然更便宜。

最終的集成測試和用戶驗收測試應該在瀑布條件下進行。 在此階段，開發階段已完成，新功能和缺失的功能將作為下一個計劃期的附加工作請求記錄下來。

將敏捷融入嵌入式軟件開發

使用嵌入式軟件構建複雜的硬件產品會影響傳統軟件開發方法的應用方式。 許多用於生產在個人計算機上運行的軟件的系統不適用於開發嵌入式軟件，因為存在資源稀缺和更長的開發生命週期方面的限制。

來自巴西的一組學者和專業人士提供了一個潛在的解決方案：嵌入式控制系統的基於平台的軟件設計方法：一個敏捷工具包。 這種方法將敏捷原則融入到嵌入式軟件開發中。 以下是該方法的簡短摘要，但強烈建議硬件產品經理在將其應用於實踐之前閱讀完整描述。

此方法中涉及的角色是：

• 平台所有者——負責定義質量、計劃和成本目標
• 產品負責人——負責產品的實施、集成和測試
• 功能負責人——負責管理子系統項目並跟踪功能可交付成果的進度
• 開發團隊——致力於產品開發

該方法將嵌入式軟件的開發分為三個過程組：

1. 系統平台進程組。 系統從平台庫中選擇將成為架構和 API 平台一部分的系統組件，並對其進行定制以滿足相關應用程序的約束。 通過對集成到平台中的設計人員可配置處理器和運行時可重新配置邏輯進行編程，以迭代周期執​​行定製過程。
2. 產品開發過程組。 構成產品的功能被劃分為平台的硬件或軟件元素。 該方法提供了分區算法，以考慮應用程序組件的能耗、執行時間和內存大小。
3. 產品管理流程組監控和控制產品範圍、時間、質量和成本參數。 建議的方法主要包括 Scrum Agile 方法所提倡的實踐以及敏捷模式。

創建硬件開發計劃

構建早期硬件開發計劃使公司能夠提供快速轉型或 B 計劃。從業務角度來看，它可能會降低財務利潤，但最終，它提供了應對不斷變化的市場所需的敏捷性競爭產品發布的條件和先進的技術能力。

假設一家公司為其帶有嵌入式軟件的硬件產品開展了成功的眾籌活動。 他們在第一批產品上表現出色，直到一家大型成熟公司宣布類似的產品。 多功能性和上市時間是最重要的，對這種情況採取務實和敏捷的反應會增加產品成功的可能性。 通過制定硬件開發計劃，公司可以快速適應並在聚光燈下推出更豐富的產品版本，作為對競爭對手的回應。

使用嵌入式軟件成功測試硬件

測試是硬件產品管理的重要組成部分，因為與敏捷軟件測試不同，大多數硬件錯誤只能通過生產一批新產品來修復。 著火的三星 Galaxy Note 7 設備就是一個很好的例子，說明為什麼硬件測試應該是所有產品經理的頭等大事。

功能測試是對帶有嵌入式軟件產品的硬件進行技術驗證的關鍵目標。 這些過程的複雜性來自於錯誤可能來自系統的任何部分這一事實。

單元測試通常在每次 sprint 之後在模擬環境中進行，因為模擬硬件具有完全可控的優勢。 測試腳本可以自動化，可以監督執行，並殺死似乎已經崩潰而無法產生任何結果的測試。

集成測試應考慮在線和離線操作以及將硬件產品提交到實際操作條件。 例如，如果公司在戶外活動中開發頭戴式大腦監測系統，則測試條件應考慮這些特殊性。

系統測試涉及測試整個系統的錯誤和錯誤。 該測試通過連接整個系統的硬件和軟件組件（之前已經過單元和集成測試）然後作為一個整體進行測試來執行。 此測試列在黑盒測試方法下，其中檢查軟件的用戶預期場景、潛在異常和邊緣情況條件。 可提及的特殊測試類別：

• 事件觸發測試：由硬件產品生命週期中的特定事件或狀態變化（例如，啟動、重置、關閉）啟動。 其目標是檢測永久性故障。
• 時間觸發測試：在系統正常運行的預配置時間啟動，定期進行以檢測永久性故障。 它在長時間運行的系統中很有用，在這些系統中不會發生重大的測試觸發事件。 時間觸發測試對於檢測間歇性故障也很有用。

帶有嵌入式軟件的硬件產品驗收

帶有嵌入式軟件的硬件產品的產品價值通常在 Water-scrum-fall 方法中的產品驗收步驟之後進行驗證。 具有嵌入式軟件生態系統的硬件必須優先考慮硬件而不是軟件才能進行驗證和驗收。 如前所述，硬件更改執行起來更加困難和昂貴。 產品經理通常會構思創新的解決方案，解決驗收問題或調整價值，考慮到無法更改硬件和支持軟件開發領域的額外迭代的約束。

優秀的產品經理具有產品敏銳度和遠見，能夠預測硬件需求並優先考慮正確的包含功能，從而使業務模型合理、接受度高、用戶喜歡使用產品。 考慮到嵌入式軟件，硬件的“裝飾”應該不足為奇，因為它需要遵循規則和約束，由硬件開發過程、認證程序、生產挑戰和市場接受度驅動。

硬件開發需要託管敏捷性

敏捷已經席捲了軟件開發領域，現在已經開始進入硬件領域。 然而，嵌入式軟件開發的硬件產品條件帶來了各種挑戰：

• 缺乏專業人才
• 不適合硬件的版本控制系統
• 異地生產設施
• 與軟件相比更難做出的改變
• 施加規劃障礙的認證和監管要求

這些挑戰使得以與軟件公司相同的方式應用敏捷原則變得更加困難。

為了應對這些挑戰，需要一種以水-scrum-fall 的形式進行管理的敏捷方法。 嵌入式軟件開發是按照標準 Scrum 程序創建的，而其他步驟（如構思、創建規範和測試）則在瀑佈設置中實現。 這使硬件公司能夠獲得敏捷提供的回報，同時保持一種有效的產品管理方法，該方法必須考慮上面列出的各種限制。 在瞬息萬變的市場條件和不斷的技術改進的背景下，這種管理的敏捷性方法提供了一條成功的前進道路。