常常被問到，硬件的敏捷怎么做？2年前我就非常關(guān)注這個跨界融合的話題，所以在不同場合發(fā)表過自己的觀點。前不久，被一個車企客戶軟件負責(zé)人再一次問到了，于是那場訪談變成我說得多、對方聆聽的模式（汗！）。所以我想，還是，寫一段文字吧，一來算是把觀點系統(tǒng)性總結(jié)一下；二來也算是拋磚引玉，在更大范圍和讀者朋友一起做個交流探討。

首先申明，這個話題非常大，我的背景局限了我的經(jīng)驗和知識面，一定是掛一漏萬，事先給讀者打聲招呼，讀者群體可能分兩大類：

• 一類讀者是熟悉敏捷的軟件背景人士：建議對本文抱著開放心態(tài)來閱讀，想一下再反駁！，或許本文可以給你一些how方面的啟示;* 另一類讀者是熟悉硬件產(chǎn)品開發(fā)、并不那么熟悉敏捷的小伙伴：建議也要開放，因為有些how部分你肯定比我更專業(yè)，希望本文能更多給你why和what方面的啟示。
  另一類讀者是熟悉硬件產(chǎn)品開發(fā)、并不那么熟悉敏捷的小伙伴：建議也要開放，因為有些how部分你肯定比我更專業(yè)，希望本文能更多給你why和what方面的啟示。
  0，本文核心框架

首先用下面兩張圖來概括本文的觀點，圖一是MVP、精益創(chuàng)業(yè)的循環(huán)：

圖一 MVP的實現(xiàn)路徑

圖二是喬幫主的“持續(xù)交付”雙輪模型，其實就是圖一MVP的拆解：

• 如果把業(yè)務(wù)管理看成時間維度上的活動、就是左邊一個科學(xué)探索環(huán)，強調(diào)業(yè)務(wù)創(chuàng)新。
• 如果把工程開發(fā)看成空間維度上的活動、就是右邊一個快速驗證環(huán)，強調(diào)工程卓越。
  

1，厘清定義：何謂敏捷？何謂硬件、系統(tǒng)、零部件？

在進入兩個環(huán)如何相輔相成地支持硬件敏捷之前，先厘清本文題中的兩個基本定義：何謂敏捷？何謂“硬件”？

首先，何謂敏捷？

它本質(zhì)上是一種管理哲學(xué)，和很多先進的管理哲學(xué)殊途同歸，關(guān)于它的第一性原理，可以參考我兩年前的《[敏捷+的時代，傳統(tǒng)項目管理真的過時了嗎？]》一文，也推薦愛索團隊宋老師今年2月的直播《[甲方視角看敏捷實踐的得與失]》，這里不再贅述。敏捷并不是越快越好；而是可以通過快速迭代實現(xiàn)更早交付 價值 、且強調(diào)build in quality，也就是一次性通過FPY（First Pass Yield）；產(chǎn)品開發(fā)對業(yè)務(wù)的影響，可以從以下兩方面來理解：

第一，如何保障未來的商業(yè)成功？ENSURE FUTURE BUSINESS SUCCESS

產(chǎn)品要大規(guī)?？蓮?fù)制：這意味著，我們不得不以最小成本、在給定時間內(nèi)開發(fā)出可靠的產(chǎn)品。這里的可靠是真正的工程術(shù)語reliability，是指0到1不夠，還有1到1000000。因此要遵循3R原則，如圖三左側(cè)。

第二，如何避免帶來經(jīng)濟損失？AVOID ECONOMIC DAMAGE

產(chǎn)品要盡量避免技術(shù)風(fēng)險：這意味著，我們可能不得不預(yù)測結(jié)果，而且?guī)讉€樣件得并行跑，而不再像以前那樣，按部就班地一遍一遍瀑布地順序?qū)嵤捍驑?、測試并學(xué)習(xí)是否有錯、再打樣。如圖三右側(cè)。

圖三 硬件開發(fā)的3R原則和敏捷的prototype模式

其實圖三中的3R原則，是硬件敏捷的精髓，也可以看成敏捷版的QCT

其次，本文題中的“硬件”到底是指什么？

本文指的是相對于純機械更復(fù)雜的 軟硬件結(jié)合產(chǎn)品 ，包含mechanic+eletronics+SW在一起的“系統(tǒng)”及其包含的零部件（傳感器、控制器、執(zhí)行器等等），比如EMS、ESP這樣的電控系統(tǒng)。如果是整車級別的自駕復(fù)雜控制系統(tǒng)（system of system），那么依然可以做功能分解，總能分解到軟硬件、參數(shù)這一級 實現(xiàn)層 ，如圖。

圖四 系統(tǒng)的拆解，需求工程也遵循此邏輯（根據(jù)系統(tǒng)論：系統(tǒng)是分層次的）

2，HOW？硬件敏捷的工程卓越部分

我認為硬件敏捷的工程卓越可以通過以下四個方面來實現(xiàn)。

a，產(chǎn)品工程PE（V模型的需求工程路徑和經(jīng)典PE工具）

工業(yè)界人盡皆知的V模型，是產(chǎn)品工程的精髓。系統(tǒng)工程的骨架之美，是指導(dǎo)我們一次性把事情做對：比如按QFD、FAA、DRBFM等方法論來提升效率；其中，F(xiàn)AA（Focus Area Analysis）是用于快速識別和聚焦關(guān)鍵部位的工具；DRBFM（Design Review Based Failure Mode）是針對變更局部做影響分析和設(shè)計回顧的工具。

這些工具背后都是非常精益、敏捷的思想。

圖五 V模型的分層分解

這里簡單分享一個最佳實踐：一個被動安全空氣氣囊ECU產(chǎn)品，為了滿足中國五星碰撞法規(guī)CNCAP的要求，需要加大電容、加高ECU外殼體等元器件。整個變更項目還是存在不少風(fēng)險點和不可知因素，團隊從立項開始做好了充分規(guī)劃，靈活采用了FAA、DRBFM、DFMA和仿真等PE工具方法論，總共只花了1年就完成改款從設(shè)計到各級V&V的驗證，最后成為了全球的一個最佳實踐；

圖六 一個電控單元設(shè)計變更遵循3R原則、靈活運用PE工具的最佳實踐

b，系統(tǒng)（同步）工程SE

其實同步工程屬于系統(tǒng)工程里的常規(guī)方法了，就是從設(shè)計之初就引入后面工業(yè)化階段需要有資產(chǎn)投資、有實體產(chǎn)出的諸如工藝、設(shè)備、采購、包裝、物流等等職能部門，而不是等到很多工作做完，最后做出成品發(fā)現(xiàn)不行，甚至可能連需求都是錯的。其核心就是避免閉門造車、增加成功率，就和敏捷宣言里Working Software異曲同工。

這里面也有非常豐富的工具箱，比如以DfX為代表：DfE、DfR、DfM等。

圖七 體現(xiàn)同步工程的產(chǎn)品工程路徑

c，數(shù)字技術(shù)Digitial Technology

如果我們?nèi)鞒痰目创龣C器的開發(fā)，從概念設(shè)計、原型設(shè)計、測試驗證，整個流程中，最燒錢的地方在哪里？

對于機器與系統(tǒng)的開發(fā)，V-Model是普遍被應(yīng)用的模式，在整個設(shè)計與開發(fā)階段，從概念到需求、功能規(guī)范、子系統(tǒng)設(shè)計再到實現(xiàn)，各個階段對應(yīng)都有相應(yīng)的測試與驗證，這個集成測試驗證是確保每個流程都能夠保證任務(wù)的質(zhì)量與進度得到控制，順利完成產(chǎn)品整個的研發(fā)過程，而這些過程中，真正需要耗費大量成本的往往是測試驗證這些過程。

現(xiàn)在有了數(shù)字孿生、建模仿真等手段，可以有效減少了費時耗力的長周期測試的長尾部分（20%的測試會用掉80%的時間）。類似的新技術(shù)還有virtual ECU的模擬測試，3D打?。ㄔ霾募夹g(shù)）快速成型，等等，這些數(shù)字化手段都能讓研發(fā)周期得以縮短，成本也得以降低。

圖八 通過仿真測試等數(shù)字化手段可縮短研發(fā)周期（圖源：知乎）

d，架構(gòu)設(shè)計：標準化、模塊化、平臺化

就跟工業(yè)柔性生產(chǎn)線一樣，研發(fā)之所以能快速提供多樣化產(chǎn)品組合給不同的用戶，其實，只有先標準化、模塊化、平臺化，才能做到快。也就是先做減法再做加法。

標準化、模塊化、平臺化的最大好處就是，能夠復(fù)用reuse、而不是重復(fù)造輪子，從而降低風(fēng)險，而且開發(fā)周期短。

圖九 架構(gòu)設(shè)計帶來的平臺化、模塊化、標準化是快速、靈活交付的基礎(chǔ)

特別是復(fù)雜性提高、互相依賴越來越多的情況下，為了提高組織研發(fā)工作的韌性和靈活性，好的技術(shù)架構(gòu)顯得尤為重要：比如SOA架構(gòu)。

再比如特斯拉的諸多顛覆式創(chuàng)新，像一體式壓鑄giga-press，制造端實現(xiàn)了快速、低成本；第三代中央計算EE架構(gòu)，線束節(jié)省到幾百米。

圖十 特斯拉特別注重common part、減少零部件數(shù)量和簡化裝配工藝

3，HOW？硬件敏捷的管理創(chuàng)新部分

現(xiàn)在來說說管理創(chuàng)新，也就是敏捷可以如何應(yīng)用到硬件領(lǐng)域。

- 產(chǎn)品思維VS.項目思維

硬件之所以要敏捷，就是擁抱變化、響應(yīng)變化，是要快速交付價值并得到反饋和驗證。那么和過去市場驅(qū)動不同，我們更多需要引入新技術(shù)、來進行產(chǎn)品驅(qū)動，引領(lǐng)市場而不是跟隨者。于是，從用戶畫像、需求挖掘、產(chǎn)品愿景到MVP再一步步迭代完善，就特別重要。參考愛索近期好文《淺析MVP》。

- 組織形式：

SCRUM、Sportify、SAFe本身就是不錯的系統(tǒng)性實踐框架。哪怕小到站會、看板、需求backlog、回顧、用戶故事、AC（Acceptance Criteria），這些日常工作的標準化做法，也非常適合引入到硬件敏捷項目管理。

對比一下，同樣是需求表達，為了避免模棱兩可的現(xiàn)象，硬件領(lǐng)域以前我們被要求遵循4C原則（Complete，Clear，Correct，Consistent），但是怎么做到，并不清楚，對于成熟度低的開發(fā)團隊就很要命了；相對而言，軟件敏捷開發(fā)的user story的表述范式更易于掌握；再比如需求的排序方法，來自軟件領(lǐng)域的WSJF就非?？刹僮?，都非常適合借鑒到硬件領(lǐng)域，諸如此類的例子還很多。我一直說，軟件敏捷開發(fā)方法把人們尤其是不成熟的團隊從大的足球場框到小一點的足球場（像2周一個sprint的時間盒就能很好地解決學(xué)生癥候群），規(guī)范了人們的行為。

圖十一 需求表達：4C原則 VS. 用戶故事

- 管理原則：

更主要的是，敏捷脫胎于精益，而精益價值流的概念應(yīng)用在研發(fā)端，是非常有用武之地的，通過價值流識別VSI、價值流分析VSM、價值流設(shè)計VSD，能很好地識別重大浪費和不合理，從而找到優(yōu)化和改善點，極大提升研發(fā)效率，比如現(xiàn)在我們在輔導(dǎo)的多家車企客戶，都在應(yīng)用這個方法、反饋效果很好。

- 決策模式：

Cynefine及CAS：與時俱進，科學(xué)管理有其局限性，現(xiàn)在越來越需要CAS來應(yīng)對VUCA。即去中心化的決策機制，響應(yīng)更快。這部分對人的影響是最大的。無論軟件工程師還是硬件/系統(tǒng)工程師，其實最終都希望通過敏捷理念賦能每個人，就是人人都是thinker + doer；如此，實現(xiàn)學(xué)習(xí)型組織，充分擁抱變化、快速響應(yīng)變化。

圖十二 敏捷轉(zhuǎn)型的終極目標：學(xué)習(xí)型組織

4，最后的暢想

敏捷在硬件領(lǐng)域會有更多形態(tài)，因其跨學(xué)科的多樣（材料、化學(xué)、等）造成的組合就是好幾個數(shù)量級的差別、同時約束更多，試錯成本相對高。軟件世界本質(zhì)上是計算機能解決的，但并不是世界上所有問題都能通過計算機解決。從比特世界來到原子世界，從數(shù)學(xué)世界來到物理世界，我們需要面對的是更復(fù)雜的組合：跨學(xué)科、約束更多、軟硬件一起，多物理學(xué)科。

這也就不難理解為什么馬斯克說，對于特斯拉這樣一家軟件牛逼的造車公司而言，99%的疑難雜癥來自于批量生產(chǎn)了。

可能需要更多的創(chuàng)新，技術(shù)的創(chuàng)新，流程的創(chuàng)新，管理方法的創(chuàng)新。沒有敬畏感，那么必然就會像諸多廠家的案例那樣，TAKATA因為技術(shù)問題徹底破產(chǎn)、特斯拉最近的電子件召回和小鵬的斷軸，都出過事故；但是太有敬畏感，也不行，反倒束縛了創(chuàng)新的手腳?？傊诟鼜V闊的物理世界，人類的產(chǎn)品開發(fā)這種創(chuàng)造性活動如果得到敏捷的加持，一定會綻放出更多創(chuàng)新的智慧之花。

圖十三 不是所有問題都能通過計算機或人工智能解決（credit：吳軍）

/作者： 文蔚