那天 CPK 報告出來，全場沉默了三秒
還記得前陣子，我們組裡有個新案子，客戶是某歐洲車廠。開案初期大家都很嗨，覺得終於能跟國際大廠合作了。結果咧？產品開發到一半，客戶突然空降一個 audit 團隊，直接點名要看我們的軟體開發流程。那時我們 PM 一臉懵，跑來問我：「老蘇，那個蝦咪 SPICE 的，你聽過嗎？他們說我們連 Level 1 都沒到，整個案子要停掉！」說實話，我那時候也傻眼貓咪，心想這哪招？以前晶圓代工，頂多就 ISO 9001、IATF 16949，現在連軟體都要被評鑑？
問題出在哪？
說穿了，ASPICE 就是一套評估你軟體開發流程「成熟度」的標準。想像一下，你今天要做一顆晶片給車廠用，除了硬體品質要穩，軟體更是靈魂。車上的軟體，你總不希望它跑一跑突然當機，或是踩油門沒反應吧？這可是會出人命的。所以，車廠對軟體的開發流程要求特別高，他們會看你從需求規劃、設計、實作、測試到維護，每個環節有沒有做到位，做得夠不夠嚴謹。
換句話說，它不是在評斷你寫的 code 有多炫炮，而是看你寫 code 的這個「過程」有沒有按照規矩來。比如說，你一個需求文件寫得不清不楚，後面設計當然會歪樓；或者測試報告亂寫一通，誰知道你有沒有測到該測的東西？這套標準就是把這些流程拆解成好幾個項目，然後給你的表現打分數。
實際上怎麼做？
ASPICE 把流程評估分成六個等級，從 Level 0（未完成）到 Level 5（最佳化）。我跟你說，剛開始我們連 Level 1 都摸不著邊。Level 1 最基本的要求就是「執行」。聽起來很簡單對不對？但光是「有文件」這件事就卡死一堆人。
舉個例，我們的軟體需求規格書（SRS）。客戶 Audit 時，會隨機挑選幾個功能，然後問：「這個功能的需求是從哪裡來的？你們怎麼確認這個需求是正確的？」如果你只說「喔，那是 PM 口頭跟我講的」，那直接 GG。他們要看到的是：
- 需求文件有沒有版本控制？ （文件標題、版本號、日期、作者）
- 需求有沒有明確定義？ （不能寫「操作流暢」這種模糊字眼，要寫「螢幕點擊反應時間小於 100ms」）
- 需求有沒有被審核過？ （要有審核人簽名或紀錄）
- 需求有沒有被追溯到測試案例？ （每個需求都要對應到至少一個測試案例，確保它被驗證了）
那時候我們團隊，很多需求都靠口耳相傳，或是在 Slack 敲一敲就當定案。Audit 團隊一來，直接看到我們的需求文件，連個版本號都沒有，就直接打槍。他們不是看你寫了什麼，而是看你「怎麼寫」的。
最常見的坑
最大的坑就是「覺得麻煩」。很多工程師會覺得，花那麼多時間寫文件、跑流程，不如多寫幾行 code。但說實話，你現在偷懶不寫文件，未來出包的時候，你就會知道什麼叫做「痛」。
我們曾經有一個 bug，產品上線後偶爾會出現畫面卡頓。追查了半天，才發現是當初一個需求變更，但只有口頭通知，沒有更新到需求文件，導致後續開發和測試都漏掉了這個環節。如果當初有確實執行 ASPICE Level 1 的文件管理，這個坑根本不會出現。那次為了修這個 bug，來來回回多花了快一個月，人力成本算一算，絕對比當初多花幾小時寫文件還要高好幾倍。
所以重點是，這不是為了寫文件而寫文件，是為了讓整個開發過程更透明、更可控，最終達到更好的產品品質。
今天能做的一件事
把你手邊的軟體需求文件，加上版本號和日期。