去年，我參與了一個專注於藍牙智能裝置的物聯網（IoT）項目。這個經驗與純軟體開發在幾個方面有顯著的不同：

首先，集成帶來了挑戰，因為項目的機械設計、固件、手機應用程式和設計組件被分包給多個供應商。這些供應商有地理上分散的團隊和不同的工作文化。當開發人員在他們的領域專門化到組織成獨立的群體時，Scrum模型不太可能有效運行。

其次，硬體迭代的時長遠超過軟體迭代，使其難以適應變化。與軟體不同，軟體可以輕易被模塊化，許多硬體組件如晶片和主機板卻是相互關聯。這種情況推動了開發過程向著更像瀑布模型的方向。你只能收到整個原型或者一無所有；沒有傳遞一個用於消費者測試的最小可行產品（MVP）的中間地帶。早期用戶反饋的缺乏進一步阻礙了特性優先級的確定過程。

第三，當事情出錯時，診斷問題尤其具有挑戰性。很難確定問題是出在機械設計、固件還是手機應用程式的開發。此外，隨著介面的演變，端到端的測試變得更加複雜。在沒有全面的硬體自動化的情況下進行測試也很耗時。為了緩解這一點，有必要明確並可驗證的接受準則，確保“完成”的嚴格定義。

對任何IT項目的成功而言，有效的溝通至關重要，特別是當各個方面沒有按計劃進展時。指責和防衛可以嚴重損害部門之間的關係。有效的溝通需要同理心；嘗試從他人的角度理解問題，而不是情緒化或判斷式地反應。

客戶根據他們從產品中獲得的價值來評估性能。採取同理心和解決問題的思維方式可以減少浪費的時間和精力，從而提高整體性能。我期待著產品的發佈和最終用戶的積極反饋。