常常被問到,硬件的敏捷怎么做?2年前我就非常關注這個跨界融合的話題,所以在不同場合發表過自己的觀點。前不久,被一個車企客戶軟件負責人再一次問到了,于是那場訪談變成我說得多、對方聆聽的模式(汗!)。所以我想,還是,寫一段文字吧,一來算是把觀點系統性總結一下;二來也算是拋磚引玉,在更大范圍和讀者朋友一起做個交流探討。
首先申明,這個話題非常大,我的背景局限了我的經驗和知識面,一定是掛一漏萬,事先給讀者打聲招呼,讀者群體可能分兩大類:
- 一類讀者是熟悉敏捷的軟件背景人士:建議對本文抱著開放心態來閱讀,想一下再反駁!,或許本文可以給你一些how方面的啟示;* 另一類讀者是熟悉硬件產品開發、并不那么熟悉敏捷的小伙伴:建議也要開放,因為有些how部分你肯定比我更專業,希望本文能更多給你why和what方面的啟示。
另一類讀者是熟悉硬件產品開發、并不那么熟悉敏捷的小伙伴:建議也要開放,因為有些how部分你肯定比我更專業,希望本文能更多給你why和what方面的啟示。
0,本文核心框架
首先用下面兩張圖來概括本文的觀點,圖一是MVP、精益創業的循環:
圖一 MVP的實現路徑
圖二是喬幫主的“持續交付”雙輪模型,其實就是圖一MVP的拆解:
- 如果把業務管理看成時間維度上的活動、就是左邊一個科學探索環,強調業務創新。
- 如果把工程開發看成空間維度上的活動、就是右邊一個快速驗證環,強調工程卓越。
1,厘清定義:何謂敏捷?何謂硬件、系統、零部件?
在進入兩個環如何相輔相成地支持硬件敏捷之前,先厘清本文題中的兩個基本定義:何謂敏捷?何謂“硬件”?
首先,何謂敏捷?
它本質上是一種管理哲學,和很多先進的管理哲學殊途同歸,關于它的第一性原理,可以參考我兩年前的《[敏捷+的時代,傳統項目管理真的過時了嗎?]》一文,也推薦愛索團隊宋老師今年2月的直播《[甲方視角看敏捷實踐的得與失]》,這里不再贅述。敏捷并不是越快越好;而是可以通過快速迭代實現更早交付 價值 、且強調build in quality,也就是一次性通過FPY(First Pass Yield);產品開發對業務的影響,可以從以下兩方面來理解:
第一,如何保障未來的商業成功?ENSURE FUTURE BUSINESS SUCCESS
產品要大規模可復制:這意味著,我們不得不以最小成本、在給定時間內開發出可靠的產品。這里的可靠是真正的工程術語reliability,是指0到1不夠,還有1到1000000。因此要遵循3R原則,如圖三左側。
第二,如何避免帶來經濟損失?AVOID ECONOMIC DAMAGE
產品要盡量避免技術風險:這意味著,我們可能不得不預測結果,而且幾個樣件得并行跑,而不再像以前那樣,按部就班地一遍一遍瀑布地順序實施:打樣、測試并學習是否有錯、再打樣。如圖三右側。
圖三 硬件開發的3R原則和敏捷的prototype模式
其實圖三中的3R原則,是硬件敏捷的精髓,也可以看成敏捷版的QCT
其次,本文題中的“硬件”到底是指什么?
本文指的是相對于純機械更復雜的 軟硬件結合產品 ,包含mechanic+eletronics+SW在一起的“系統”及其包含的零部件(傳感器、控制器、執行器等等),比如EMS、ESP這樣的電控系統。如果是整車級別的自駕復雜控制系統(system of system),那么依然可以做功能分解,總能分解到軟硬件、參數這一級 實現層 ,如圖。
圖四 系統的拆解,需求工程也遵循此邏輯(根據系統論:系統是分層次的)
2,HOW?硬件敏捷的工程卓越部分
我認為硬件敏捷的工程卓越可以通過以下四個方面來實現。
a,產品工程PE(V模型的需求工程路徑和經典PE工具)
工業界人盡皆知的V模型,是產品工程的精髓。系統工程的骨架之美,是指導我們一次性把事情做對:比如按QFD、FAA、DRBFM等方法論來提升效率;其中,FAA(Focus Area Analysis)是用于快速識別和聚焦關鍵部位的工具;DRBFM(Design Review Based Failure Mode)是針對變更局部做影響分析和設計回顧的工具。
這些工具背后都是非常精益、敏捷的思想。
圖五 V模型的分層分解
這里簡單分享一個最佳實踐:一個被動安全空氣氣囊ECU產品,為了滿足中國五星碰撞法規CNCAP的要求,需要加大電容、加高ECU外殼體等元器件。整個變更項目還是存在不少風險點和不可知因素,團隊從立項開始做好了充分規劃,靈活采用了FAA、DRBFM、DFMA和仿真等PE工具方法論,總共只花了1年就完成改款從設計到各級V&V的驗證,最后成為了全球的一個最佳實踐;
圖六 一個電控單元設計變更遵循3R原則、靈活運用PE工具的最佳實踐
b,系統(同步)工程SE
其實同步工程屬于系統工程里的常規方法了,就是從設計之初就引入后面工業化階段需要有資產投資、有實體產出的諸如工藝、設備、采購、包裝、物流等等職能部門,而不是等到很多工作做完,最后做出成品發現不行,甚至可能連需求都是錯的。其核心就是避免閉門造車、增加成功率,就和敏捷宣言里Working Software異曲同工。
這里面也有非常豐富的工具箱,比如以DfX為代表:DfE、DfR、DfM等。
圖七 體現同步工程的產品工程路徑
如果我們全流程的看待機器的開發,從概念設計、原型設計、測試驗證,整個流程中,最燒錢的地方在哪里?
對于機器與系統的開發,V-Model是普遍被應用的模式,在整個設計與開發階段,從概念到需求、功能規范、子系統設計再到實現,各個階段對應都有相應的測試與驗證,這個集成測試驗證是確保每個流程都能夠保證任務的質量與進度得到控制,順利完成產品整個的研發過程,而這些過程中,真正需要耗費大量成本的往往是測試驗證這些過程。
現在有了數字孿生、建模仿真等手段,可以有效減少了費時耗力的長周期測試的長尾部分(20%的測試會用掉80%的時間)。類似的新技術還有virtual ECU的模擬測試,3D打印(增材技術)快速成型,等等,這些數字化手段都能讓研發周期得以縮短,成本也得以降低。
圖八 通過仿真測試等數字化手段可縮短研發周期(圖源:知乎)
d,架構設計:標準化、模塊化、平臺化
就跟工業柔性生產線一樣,研發之所以能快速提供多樣化產品組合給不同的用戶,其實,只有先標準化、模塊化、平臺化,才能做到快。也就是先做減法再做加法。
標準化、模塊化、平臺化的最大好處就是,能夠復用reuse、而不是重復造輪子,從而降低風險,而且開發周期短。
圖九 架構設計帶來的平臺化、模塊化、標準化是快速、靈活交付的基礎
特別是復雜性提高、互相依賴越來越多的情況下,為了提高組織研發工作的韌性和靈活性,好的技術架構顯得尤為重要:比如SOA架構。
再比如特斯拉的諸多顛覆式創新,像一體式壓鑄giga-press,制造端實現了快速、低成本;第三代中央計算EE架構,線束節省到幾百米。
圖十 特斯拉特別注重common part、減少零部件數量和簡化裝配工藝
3,HOW?硬件敏捷的管理創新部分
現在來說說管理創新,也就是敏捷可以如何應用到硬件領域。
- 產品思維VS.項目思維
硬件之所以要敏捷,就是擁抱變化、響應變化,是要快速交付價值并得到反饋和驗證。那么和過去市場驅動不同,我們更多需要引入新技術、來進行產品驅動,引領市場而不是跟隨者。于是,從用戶畫像、需求挖掘、產品愿景到MVP再一步步迭代完善,就特別重要。參考愛索近期好文《淺析MVP》。
- 組織形式:
SCRUM、Sportify、SAFe本身就是不錯的系統性實踐框架。哪怕小到站會、看板、需求backlog、回顧、用戶故事、AC(Acceptance Criteria),這些日常工作的標準化做法,也非常適合引入到硬件敏捷項目管理。
對比一下,同樣是需求表達,為了避免模棱兩可的現象,硬件領域以前我們被要求遵循4C原則(Complete,Clear,Correct,Consistent),但是怎么做到,并不清楚,對于成熟度低的開發團隊就很要命了;相對而言,軟件敏捷開發的user story的表述范式更易于掌握;再比如需求的排序方法,來自軟件領域的WSJF就非常可操作,都非常適合借鑒到硬件領域,諸如此類的例子還很多。我一直說,軟件敏捷開發方法把人們尤其是不成熟的團隊從大的足球場框到小一點的足球場(像2周一個sprint的時間盒就能很好地解決學生癥候群),規范了人們的行為。
圖十一 需求表達:4C原則 VS. 用戶故事
- 管理原則:
更主要的是,敏捷脫胎于精益,而精益價值流的概念應用在研發端,是非常有用武之地的,通過價值流識別VSI、價值流分析VSM、價值流設計VSD,能很好地識別重大浪費和不合理,從而找到優化和改善點,極大提升研發效率,比如現在我們在輔導的多家車企客戶,都在應用這個方法、反饋效果很好。
- 決策模式:
Cynefine及CAS:與時俱進,科學管理有其局限性,現在越來越需要CAS來應對VUCA。即去中心化的決策機制,響應更快。這部分對人的影響是最大的。無論軟件工程師還是硬件/系統工程師,其實最終都希望通過敏捷理念賦能每個人,就是人人都是thinker + doer;如此,實現學習型組織,充分擁抱變化、快速響應變化。
圖十二 敏捷轉型的終極目標:學習型組織
4,最后的暢想
敏捷在硬件領域會有更多形態,因其跨學科的多樣(材料、化學、等)造成的組合就是好幾個數量級的差別、同時約束更多,試錯成本相對高。軟件世界本質上是計算機能解決的,但并不是世界上所有問題都能通過計算機解決。從比特世界來到原子世界,從數學世界來到物理世界,我們需要面對的是更復雜的組合:跨學科、約束更多、軟硬件一起,多物理學科。
這也就不難理解為什么馬斯克說,對于特斯拉這樣一家軟件牛逼的造車公司而言,99%的疑難雜癥來自于批量生產了。
可能需要更多的創新,技術的創新,流程的創新,管理方法的創新。沒有敬畏感,那么必然就會像諸多廠家的案例那樣,TAKATA因為技術問題徹底破產、特斯拉最近的電子件召回和小鵬的斷軸,都出過事故;但是太有敬畏感,也不行,反倒束縛了創新的手腳。總之,在更廣闊的物理世界,人類的產品開發這種創造性活動如果得到敏捷的加持,一定會綻放出更多創新的智慧之花。
圖十三 不是所有問題都能通過計算機或人工智能解決(credit:吳軍)
/作者: 文蔚
-
硬件
+關注
關注
11文章
3429瀏覽量
66847 -
機器
+關注
關注
0文章
788瀏覽量
40980 -
mvp
+關注
關注
0文章
13瀏覽量
2345
發布評論請先 登錄
相關推薦
評論