舍與得——主機廠與供應商的ASPICE博弈

駕駛哥

2022年2月11日 15:49

要不要求ASPICE？這是個問題

主機廠

拿到供應商提交上來的軟件和100%通過率的測試報告，才跑幾個功能就發現一堆明顯的bug，發生甚么事了？難道是打開的方式不對？還是雙方對“測試通過率”這個概念的理解不同？——既然理解不同就用行業里大家都懂的語言ASPICE溝通吧，“SYS.2系統需求里的驗證準則是怎么定義的”、“SYS.5系統合規性測試中測試策略的要求都滿足了么”……

供應商

小伙伴們通宵加班總算是在期限之內把軟件交付給主機廠，就連頻繁變更的需求都實現了，這下金主爸爸總該滿意了吧。納尼！？這封味十足的郵件在challenge什么？ASPICE？我們在合同里承諾過么？想要馬兒跑就得給馬兒吃草，系統需求和軟件需求要分開、各種追溯性得建立鏈接、評審checklist都得用上……要做ASPICE都是實打實的工作量啊！銷售，客戶既然提到了ASPICE，我們是不是該向他們多收點錢啊？

主機廠

還要加錢？確定驗證準則保證可測試性不是需求人員的本分么？保證所有功能在目標環境下正常運行不是開發人員的基本職責么？就算你們自己搞了ASPICE，找了技術背景不如自己靠著精通流程賺錢的咨詢公司來評估，最終搞出那一堆文檔真的能提升產品質量么？是，合同里是沒有寫ASPICE，但IATF16949總得認吧，最新版本里明確了嵌入式開發需要配套的軟件評估方法和質量保證流程，不用ASPICE的話，用的是哪一套呢？那家狼性文化的供應商過的就是ASPICE，還是三級！人家還用架構師來擔當SQA來保證質量，你們的SQA有多少年開發經驗？為啥別人能做到你們做不到？

供應商

這是純屬站著說話不腰疼，如果這合理的話，甲方的軟件團隊自己能做到么？己所不欲勿施于人，不是每家公司都適合狼性文化，這社會已經夠卷了，還讓不讓年輕人留點希望了？！

……

以上關于主機廠與供應商的ASPICE博弈場景純屬虛構，做鋪墊之用。 現實中，甲方的主機廠與乙方供應商的博弈，在壓力達到一定閾值的情況下甚至可能會陷入無休止的彼此指責之中，而這，恰恰與敏捷價值觀之一的"客戶合作高于合同談判（Customer collaboration over contract negotiation）"背道而馳，這樣的場景即使敏捷方法論大行其道各種工具鏈完整部署的今天依舊時有發生。那么在現實情況下，主機廠應當如何以ASPICE為依據提出要求才能最大程度的保證開發質量呢？而供應商，又應當以什么樣的態度和投入來在滿足主機廠的相關要求的同時確保交付呢？

這里從個人的觀察，從產品、流程和技術三個維度，整理出以下三點思考，期望能對相關的行業同仁提供參考，或者拋磚引玉得到更精辟的見解：

產品維度：結果導向，統一準則
流程維度：質量驅動，迭代改進
技術維度：打通工具，實時協同

后續會從這三點出發，結合實例進行說明。

為啥要做ASPICE？

展開實施層面的討論之前，還是讓我們先弄清一個問題——為啥要做ASPICE？

省錢！省錢！還是為了省錢！

這也許和我們的感受相悖，做ASPICE需要投入更多的人力、產生更多的工作產品、花更多的錢，和省錢有啥子關系？不拐彎抹角，讓我們直接打開ASPICE官方培訓機構INTACS在Provisional Assessor官方培訓資料里關于Motivation（驅動力、動機）的那兩頁PPT，看看官方是怎么說的——

在這一頁里給出了統計數據，為了糾正一個典型的錯誤，在不同階段所需消耗的成本，可見越在后面的階段，成本越是成幾何級數上升，最終得出結論：因此，應當在流程盡可能早的時候把缺陷修復掉！那么如何實現呢？讓我們看看下一頁：

翻譯一下就是：

如果能做到

更早地發現缺陷

那么能實現

更少的系統性錯誤留在產品中
更精確的計劃和估算
更可預測的組織績效
更可重用的財富和知識/經驗
更低的成本

通過重用國際化的流程經驗，避免問題，實現這個（achieve this）。這里的this是單數而非復數，很明顯指向上述一系列推導后果中的最后一項——更低的成本，說人話就是兩個字——省錢！當然，這里的“省”的范圍并不局限于單個項目，例如有可能在平臺項目的前期預備中投入了大量人力物力卻為后續的多機種項目節約了前期開發的成本，或是前期保證了文檔的完整性可以大大降低未來人員離職后的系統維護成本等等，這就要根據具體情況具體分析了，會在后續的系列中討論。回顧歷史，在ISO9001剛剛成為行業標準還未普及之時，處境也許也和今天的ASPICE相似，當年的人也許也會問出“為啥要做ISO9001”“多出這些文檔有什么意義”“沒有這套標準我們照樣能做好甚至做的更好”“哪里能省錢或者帶來價值了”，而歷史發展到ISO9001成為行業標準的今天，這類的問題都已經有了答案。日光之下無新事，也許，不久的將來，ASPICE中的問題都也會找到相似的答案。

這頁PPT的最終目的是解釋ASPICE的驅動力動機，于是就導出了標題中所說的為了達成這一美好的愿景我們需要更好的流程，然后就繼續介紹ASPICE，展開培訓的課程。當然如果是賣工具的，完全可以把process（流程）改成tools（工具），毫無違和感，因業務需要而異。（最后一句純屬個人理解）

這樣看來，關于實施ASPICE，不要忘記初心——你，真的能省錢么？

關于“為啥要做ASPICE”討論就到此為止，后面將要提到的“結果導向，統一準則”中的“結果”、“質量驅動，迭代改進”的“中驅動”，“打通工具，實時協同”中的“協同”，也都是是圍繞這個Motivation服務的。

結果導向，統一準則

功能驅動開發下的品控三板斧

作為主機廠要驗收供應商的成果物，checklist（檢查表）是必不可少的驗收標準，然而不同于硬件質量的精密嚴謹且已經發展多年相對成熟，軟件質量的復雜多變帶來了很多挑戰。有的時候，完全按照checklist填寫非但不一定能檢查出問題反而或浪費實踐（尤其當checklist是由“何不食肉糜”的理論專家定義出來的時候），后續根據新的問題添加了檢查項卻又導致不必要的工序影響交付工期。因而，以雙方都能達成統一標準的“結果導向”進行實施非常重要，從形式上是要按照常規操作填滿checklist，而操作層面上卻要更加關注我們共通在乎的“結果導向”——產品質量。

十多年的軟件質量職業經歷中，見過不少checklist，檢查項也是從幾條到上千條不等，逐條確認固然必不可少，但只有建立自己的理解框架“把書讀薄”才能提綱挈領地理解其中的精義。個人整理出來的框架是以下三條的“品控三板斧”，即：

做完了嗎？
驗過了嗎？
改掉了嗎？

如果用這個框架理解ASPICE，那么的三個問題又能對應各自不同的過程域。

例如“做完了嗎”對應系統和軟件過程域的左側SYS.1-3、SWE.1-3，按層級拓展為類似如下的檢查項，括號里的內容列舉啟發式的一些問題，僅供參考：

需求挖掘做完了嗎？（除了客戶需求，行業標準和相關法規考慮了嗎？）
系統需求分析做完了嗎？

功能性需求做完了嗎？（跟甲方功能列表每一項都對得上嗎？）
非功能性需求做完了嗎？（系統工程師了解什么是非功能性需求嗎？）
驗證準則做完了嗎？（測試人員能按照準則寫用例嗎）

系統架構設計做完了嗎？（EA圖里的接口都定義了嗎？）
軟件需求分析做完了嗎？（真的做了還是把系統需求拷貝下來應付了事？）
軟件架構設計做完了嗎？（時序圖是不是只寫了啟/停/睡/醒，沒做維護？）
軟件詳細設計和單元構建做完了嗎？（詳細設計真的覆蓋每個函數了嗎？）

……

相應的，“驗過了嗎”對應系統和軟件過程域的左側SYS.4-5、SWE.4-6，按層級拓展為：

軟件單元驗證都驗過了嗎？

代碼評審驗過了嗎？（Gerrit上的評審記錄留下了嗎？）
靜態代碼標準驗過了嗎？（按MISRA標準跑出的結果分析了嗎？）
單元驗證驗過了嗎？（語句覆蓋率和分支覆蓋率都100%了嗎？）

軟件集成和集成測試都驗過了嗎？（每個模塊的接口都驗證了嗎？）
軟件合格性測試都驗過了嗎？（是對應獨立的軟件需求而非系統需求寫的嗎？）
系統集成和集成測試都驗過了嗎？（能覆蓋所有軟硬件接口通信嗎？）
系統合格性測試都驗過了嗎？（能覆蓋所有的甲方功能列表嗎？）

……

而“改掉了嗎”則對應SUP支持內過程域過程域：

流程不符合項都改掉了嗎？（SUP.1.BP5: 確保不符合項的解決。）
配置項的不合規都改掉了嗎？（SUP.8.BP7：報告配置狀態。）
高嚴重等級的缺陷都改掉了嗎？（SUP.9.BP8: 跟蹤問題直至關閉。）
需求變更都改掉了嗎？（SUP.10.BP7: 跟蹤變更請求直至關閉。）

……

僅僅列個框架，就能“文思泉涌”地寫出一堆的檢查項，然而在落地層面上真的可行么？尤其在產品快速迭代的市場環境下，即使再完善的checklist如果沒有相應的資源和時間，最終下場也必然只是“形式主義”——開發人員復制粘貼“Pass（通過）”了事，別扯什么德國的嚴謹、日本的工匠、美國的專業——全世界都是一樣的，缺錢缺時間的情況下品控流程肯定會打折扣。

那么有什么方式可以讓品控流程真的做到提高產品質量呢？Jeff De Luca 給出的回答是 “功能驅動開發“，Feature-driven development (FDD)。

在 1997 年新加坡一家大型銀行為期 15 個月、50 人的軟件開發項目中，Jeff De Luca設計出了Feature-driven development (FDD)的方法論，聚焦于功能（Feature），主要包含一組五個流程，涵蓋了整體模型的開發和功能的列出、規劃、設計和構建。時至今日，FDD已經與Scrum、XP一樣，成為敏捷的核心方法論之一。

也就是說，作為開發的甲乙雙方，主機廠與供應商的聚焦點都應當在功能（Feature），在有限的時間內，把精力集中在Feature列表的計劃、設計和構建上，雙方對每個功能的DoD（完成的定義Definition of Done）明確定義且達成一致作為雙方的共識。在定義DoD時，基于品控三板斧“做完了嗎”“驗過了嗎”“改掉了嗎”的框架，參考ASPICE中的原則可以定義出雙方開發團隊都認可的checklist作為驗收準則。注意，該checklist不但乙方，甲方的開發團隊也應當充分理解并在實踐中使用。而需求分層、建立追溯等ASPICE相關要求的任務則在DoD明確的上，可以放在后續的迭代中細化。

總之，從產品的維度出發，主機廠與供應商在ASPICE的實施上結果導向、統一準則，雙方只有把聚焦放在功能列表之上，對“做完了嗎”“驗過了嗎”“改掉了嗎”這三個問題都能達成共識進行功能驅動的開發，才能使ASPICE的落地對產品質量的提升提供價值。

質量驅動，迭代改進

質量驅動架構

在汽車中軟件占比不斷提升的今天，“軟件定義汽車”早已成為共識，那么用什么來保證軟件質量？行業或制定新的標準如針對網絡安全的ISO21434、或IATF16949，對軟件質量在特定領域提出了更嚴格、更具體的管控要求。

那諸多針對特定領域的行業標準如何融合落地？

ASPICE就成了兵家必爭之地：功能安全需要它的追溯、信息安全需要它的設計、IATF16949需要它的體系，雖然實際落地考慮成本都有各自的算盤，但各家在口頭上對ASPICE實施這件事上就沒有誰會直截了當的說“不”。

ASPICE如此厚重如何在快速迭代的短周期開發中落地？

畢竟ASPICE在流程層面只提到了做什么，至于“怎么做則是由各企業的流程體系中定義的。為了滿足快速開發快速迭代，那么“Agile”的開發方式自然就提上議事日程了，用敏捷的方式落地ASPICE，應該可以事半功倍吧？

用敏捷的方式如何落地ASPICE呢？

哪些過程域和實踐可以裁剪、任務的優先級如何設定、如何在裁剪之后仍然能滿足質量要求、工具鏈應當如何選取如何配置如何使用、取舍之下主機廠和供應商在哪些方面可以達成共識……，這一系列的問題并沒有因為采取了敏捷得到解決，如果沒有合適的方法論和扎實的落地能力，最終看到的也許只是一地雞毛，什么敏捷，還不如按照原來的做法呢，至少還省掉了白折騰的時間。

有什么方法不白折騰就能部署一套適用的流程么？

很多廠商在一頓折騰后又回到了原點，沒有豐富實踐和方法論的流程咨詢，別說ASPICE和敏捷，任何的流程改進都是空談。而這也是當年為什么華為要斥巨資請IBM進行流程咨詢，最終形成了以IPD為代表的一套體系流程實現組織的持續發展。

咨詢公司靠譜么？

實際上并不是所有的廠商都如華為有如此財力、魄力引入咨詢公司的流程體系自我革新，況且外來的流程體系還有“水土不服”的風險。咨詢公司在流程體系方面固然可能很專業，但畢竟是外人，對本組織的技術細節和業務發展理解有限，就算有了深入理解合同期滿也不再負責。因而即使請了咨詢公司，內部也需要一個團隊負責流程落地的責任。例如埃森哲針對汽車電子的開發，結合敏捷、ASPICE、功能安全、信息安全等標準和方法論定制出來AutoScrum，在流程部署上倒是面面俱到。

公司內部如何建立部署流程的咨詢團隊呢？

內部咨詢團隊不單要熟悉流程體系，而且也需要對本組織的技術細節和業務發展有深入理解，確保不是“紙上談兵”，畢竟應付客戶已經不易，再給工程師團隊頭上加個“大爺”（如下圖），那比起“白折騰”更受不了。事實上，相對于重新建立一個團隊，不如優化已有的團隊——軟件質量團隊是最好的人選，首先他們得天獨厚的熟悉流程體系、對具體的項目和工程團隊的各個角色（項目經理、產品經理、架構師、程序員、測試組）都會每天打交道、因監管需要有權限查看各個項目資料，而且本來就是“大爺”之一了的QA經理，最關鍵的，是要讓這個團隊轉型成為一個可以驅動組織變革的咨詢性團隊。

質量驅動，迭代改進

從價值觀到方法論

阻力與困境

當質量人員聚在一起分享ASPICE推行的心得時，不可避免地會提及來自工程團隊的各種阻力——

“客戶合同里都沒要求ASPICE，我們憑什么要做？”

“最近有人離職資源不足，老板讓我們集中精力先把東西做出來。”

“最近實在太忙全員每天都在加班，等過段時間好些了一定把流程文檔都給你補上！”

……

怎么辦？看到晚上燈火通明辦公室里加班的小伙伴們確實心下不忍，再加上工程團隊或委婉拖延或強勢拒絕的說辭，也不自覺地會懷疑自己的價值——

“我這樣努力地推行的ASPICE真的有意義么？”

“如果真的有意義為什么大家會這樣抵觸？”

“既然大家都不想做為什么公司還要推行？”

事實上，作為質量人員面臨各樣的推諉拒絕是家常便飯，每個人也都有自己的應對之策，身處這類困境時作為個體的質量人員如何回歸專業進一步樹立對自己定位的信心，往往才是能“走下去”的關鍵。個人在十多年的軟件質量工作中，在面對此類困境應用比較多的思維框架是ISO9001的7大質量管理原則。

理論與實踐

ISO9001的7大質量管理原則列表如下，應當是每個質量人員都能達成的共識，也是我們非常熟悉的理論，而是否能將框架內化到質量思維中，則是只有經歷過實際質量工作的困境才能深刻體會到的。

在軟件質量領域，ASPICE在公司里的落地，本質上是屬于“過程方法”，也就是7大質量管理原則的第4個，質量人員在思考為什么組織定義的過程方法為什么沒能貫徹下去的時候，不可忽略的前提是“前三個原則”落實的怎樣了？

1.客戶為中心

2.領導力

3.全員參與

在7大原則中，這前3項原則處在價值觀層的層面，而后4項原則屬于方法論的范疇，而前3項的價值觀，則是決定包含“過程方法”在內的后4項原則的方法論能夠落實的前提。

如果“客戶為中心”只是停留在銷售對甲方的服務，關于代碼質量、流程監管等的條款項目工程團隊選擇性忽略只顧著拿到需求往下做，那別提ASPICE，簡單的確保測試覆蓋率100%都得打折扣；

如果“領導力”中的總監們對ASPICE缺乏基本常識，把這個針對具體項目特定過程域的評估當成公司的認證進行宣傳，那么讓他們投入資源在項目中落地規范的難度可想而知；

如果“全員參與”達成的共識是流程文檔都是給質量團隊做的，那么應付式文檔只能是常態。

所以，當一個過程方法推行的時候，如果遇到的主要阻力是關于“要不要做”的各種推諉拒絕，那么很明顯是價值觀層面出了問題；而如果遇到的主要阻力是“該怎么做”的各種具體難度，那么就應當在方法論上進行提升，將理論落地實踐做好。

那么，如何判斷一個組織對過程方法的推行是不是“動真格的”呢？根據個人經驗，只要看看這個組織對質量團隊的定位就知道了。

質量驅動，迭代改進

軟件質量團隊的定位之爭

第一次聽到ASPICE，是2008年在日本參加培訓時一位同事進行的知識分享，當時對這個與CMMI很相似但是更加契合汽車電子開發的流程體系印象非常深刻。于是問了培訓者一個問題，“我們會在開發過程中遵循ASPICE的方法么？“然而得到的回復是——”還不行，ASPICE還沒有成為行業共識的標準，目前軟件開發還是按照CMMI來做“。

時間一晃來到2022，歷時將近14年之后的今天，汽車電子行業已經發生了天翻地覆的變化，而ASPICE也正在逐漸成為行業共識的標準。不知不覺中，焦點已經從“要不要做“變成了”怎么做“。

為了落地必須進行自上而下的推行，以及全員參與的落地，而ASPICE本身只定義了”What（做什么）”，關于解決“How（怎么做）“的定義符合組織實際的過程方法的問題，則需要一個專業團隊來負責牽頭。在大多數的組織里，軟件質量團隊就當仁不讓地被分配成了這個牽頭的角色，因而這個角色的定位也就代表了企業對于ASPICE推行的態度和成熟度。這并沒有對錯之分，而是根據實際情況所做的定制，而在這定位的過程中最關鍵的是回答以下兩個問題——

歸屬：工程開發部門or獨立質量部門？
路線：流程、產品or技術？

歸屬決定了這個團隊的匯報對象和負責部門，而路線則決定了招什么人和做什么事。

歸屬之爭

有人可能很自然地回答，有什么好爭的，軟件質量團隊當然歸屬于獨立的質量部門，若質量不獨立則監管不給力。就像自己的代碼自己測總找不出問題一樣，如果監管流程的質量部門都歸屬工程團隊了，發現了重大缺陷真的有權限叫停么？

也有人說，從知識體系和工作內容看軟件質量團隊都應當歸屬工程部門，脫離軟件開發實踐活動的質量人員就是個外行，最多能看看文檔版本格式對不對，根本起不到發現實際問題的作用。

雙方各執一詞，而這也并不是一個非黑即白的問題，要回答這個問題，需要分別先看看質量部門與工程部門的組成。

先來看看質量部門。

汽車電子開發是一個復雜的系統工程，即使在質量部門內部，根據服務對象的差異、所處流程的不同，相關成員的知識體系和工作內容都有可能天差地別——

面向下游供應商的SQE（供應商質量工程師 Supplier Quality Engineer）
面向軟件的SWQE（軟件質量工程師 Software Quality Engineer）
面向項目的CAQE（客戶前期質量工程師 Customer Advanced Quality Engineer）
面向產線的PQE（產品質量工程師 Product Quality Engineer）
面向上游客戶的CQE（客戶質量工程師 Customer Quality Engineer）
面向終端用戶的WQE（質保質量工程師 Warranty Quality Engineer）

……

誠然，沒有獨立的授權，軟件質量團隊很難推行一套流程或者叫停一個行動，但確實也存在知識能力維度的局限。ASPICE的各個過程域無論是系統架構的搭建、軟件中CICD的各種指標、測試覆蓋率的確認、項目管理的協調等等，作為軟件質量人員進行相關的檢查都需要相當專業的知識，而這卻又因為知識體系的差異不是其他質量團隊可以提供的。

反觀工程團隊，從ASPICE過程域的分工看，項目經理PM負責MAN的管理類過程域，系統團隊負責SYS相關PA、軟件團隊負責SWE相關、SUP/ACQ過程域除了SUP.1歸屬軟件質量則由各部門協商出人負責，各司其職如有未定事項則有PM拍板。這樣在知識維度上確實可以做到互補，同一個團隊的軟件質量人員可以更好與工程團隊配合。但是，在這之下的一個問題是，質量人員的話語權能有多少呢？交付優先的原則之下，別說ASPICE就連交付前的release audit也很難保證獨立性。

兩難之下如何取舍，個人的觀點是依據組織的實際情況進行規劃。

對初創公司而言 ，質量管理注重的是“快”，更多關注快速響應而非完善步驟，多數情況下軟件質量可能依附于工程部門存在。從流程模板編寫、到審計流程評審代碼、到搭建CI環境配置管理、到收集度量生成報告……有可能一個人就搞定，哪會像在大公司里那樣“這塊不歸我管”，不懂就馬上學上手干。當下國內造車新勢力可能會比較適用該種情況。

公司中期 突破瓶頸之時，質量管理的重心在“廣”，隨著業務的鋪開各種技術難度之大涉獵之廣，唯有依靠團隊的力量才能突破瓶頸。質量人員不可能成為所有領域的技術專家，而要把控質量必須依靠數據指標，此時關注工程參數過于流程指標，而工程參數也需要抓到重點否則流于形式反而成為負擔。此時，兼具技術能力和質量理論的專業團隊就必須成型，而且要求相對的獨立性，謀求轉型的各大OEM、Tier1當屬此類情況。

公司長期發展的遠景規劃中，質量管理則更加注重“穩”。例如當年華為斥巨資請IBM為其做流程咨詢完善管理體制，是在其規模效應形成而關注長期發展之時所做的，此時質量部在完善流程體系之下獨立運行可按部就班。“大企業病”可能會帶來流程冗余的弊端引發工程人員的吐槽，質量人員也有可能因此懷疑自己的價值。因此“穩”就是非常可貴的品質，在堅持原則的同時需要保持一定的靈活性，這是有一定難度的。在該種情況下，質量部門無疑應當是作為獨立且強勢的部門存在的。

路線之辯

歸屬明確了，那要招什么人，做什么事呢？

如果你說要找個架構師到質量團隊來驗證質量，結果checklist的檢查項全都是瑣碎的確認文檔格式、評審記錄之類，那不是大材小用么？

一般情況下，軟件質量團隊的路線有三種：技術、產品、流程。個人觀點也是根據實際情況進行區分——

初創公司， 或者剛開始部署ASPICE的組織，應當重在技術路線。流程的部署是依賴工具鏈的，把時間花在填EXCEL做PPT上，不如踏踏實實的把工具鏈部署好——讓程序員通過Jenkins中每天更新的dashboard看到自己注入的warning及時修改；讓需求人員通過JIRA / Polarion同步各個功能的細節；讓架構師的Enterprise Architect中使用的圖例都符合規范……Linux操作系統的創始人Linus Torvalds有一句話“Talk is cheap. Show me the code”（空談容易，給我代碼！）。縱然不用自己寫代碼，質量人員對應該維持與代碼的零距離狀態。

中期轉型公司 則可以走產品路線，將質量需求作為Stakeholder Requirement的一部分寫進product backlog里并且明確DoD，然后實打實地把它實現出來。

至于穩定的企業里質量部門當然是流程路線，無論工具鏈開發流程都已經相對成熟，就只需要專職的質量人員定期審計、培訓、評估等等例行公事即可，當然，到了這個時候行業也走向穩定乃至下行了吧。

個人認為，在當下ASPICE標準本身還不完善行業趨勢風起云涌之際，無論什么企業，都應當把姿態放低將自己作為一家初創公司帶著好奇心走技術路線，認認真真把工具鏈落實好才是正道。

可以的話，老板們多花點錢招些有技術背景的質量人員吧。

打通工具，實時協同

從物理現象引申到團隊合作，無論是產業鏈、供應鏈、工具鏈……任何的鏈條都適用于這個理論，鏈條上的最弱一環將可能導致滿盤皆輸的結局，這也是為什么“卡脖子”的策略能奏效的原因。

如果把主機廠和供應商當做供應鏈兩端主體，那么在軟件比重不斷提升的今天，鏈接雙方的環節的狀態是怎么樣的呢？也許是SQE收集到的乙方進度報告質量度量等的PPT，也許是工程團隊的驗收報告測試結果的EXCEL，又或許是DRE針對各種問題收到的分析報告……是的，這些都是根據流程定義的非常有意義的內容，但為什么總有缺了什么的感覺。甚至當主機廠收到了供應商最詳盡的ASPICE評估報告，所有關鍵過程域都是三級，對于產品質量還是沒底。

事實上，以上列舉的報告、結果、評估，都是事后的滯后指標，而沒有事前或實時的先導指標。

由于缺少實時性，雙方的協同不可避免的會出現滯后，而這非常有可能引發鏈條的斷裂風險，例如重大缺陷無法按時修復、物料不足等等等等，那么如何應對這個問題呢？

以色列學者伊利雅胡·高德拉特基于鏈條的原理曾提出限制理論，主張一個復雜的系統隱含著簡單化。即使在任何時間，一個復雜的系統可能是由成千上萬人和一系列設備所組成。但是只有非常少的變數或只有一個，稱為限制，它會限制（或阻礙）此系統達到更高的目標。作為解決方法，以下是TOC的五步聚焦法的圖例。

TOC應用比較廣泛的是在機器工業領域，針對的也是流水線上的各個環節，切換到軟件開發領域，流水線就成了工具鏈——項目管理的Jira、需求的Polarion、設計的EA、開發的Matlab、編譯的Jenkins、測試的CANOE……而不是Office的PPT、Excel。

如果主機廠和供應商的鏈接是基于工具鏈進行互動，如雙方PM針對Jira上的一個story跟蹤狀態、雙方需求人員基于同一個Polarion里的工作項進行評審、雙方程序員看到的是同一個Jenkins發出來的代碼狀態dashboard進行修復……是不是可以省掉修飾PPT排版、調整Excel格式、各種郵件飛來飛去的內耗呢？

——理想很豐滿，現實很骨感。且不說雙方的工具鏈是否統一、信息安全條例是否允許、領導層是否可以達成互信，就算萬一真的排除了一切障礙真的達到了這樣的互通，出了問題是不是能坐在一起共同解決而不是互相甩鍋，還是個問號。

當然，這也許只是發展的問題，很多改革都是倒逼的，軟件工程比起已經發展多年的機械工程還只屬于發展的初期，現在我們看到的許多問題隨著時間的發展用后世的眼光看也許根本不是問題，到時候“打通工具，實時協同”也許就是基本操作了，至于雙方達成共識的依據是ASPICE或是其他的標準，那就交給時間來回答了。

登錄后免費查看全文

立即登錄