如何讓老闆重視軟體品質，而非只是想趕時程快速上線?

在TW MVC舉辦的 .net conf mini中，現場學員問了一個問題:
『如何讓老闆重視軟體品質，而非只是想趕時程快速上線?』

這個問題，有些時候，換了不同的身分，你可能會有不同的答案。

在職涯中前十幾年我身為工程師，我很能理解工程師常常被時程追著跑的壓迫感，常常會覺得客戶(或老闆)要系統在很短的期限內上線，迫使我們沒有時間做好該做的事情。😣

『該做的事』有很多種不同的類型，從系統或架構設計、到單元測試、添加log或telemetry、甚至只是要多一點時間重構或調整程式碼改善品質(以後的可維護性)…族繁不及備載。

這些當然都是對的，也都是該做的，但常常在deadline面前，這些都顯得奢侈。看著自己的軟體作品被迫於期限而逐漸成為疊床架屋的怪獸，心裡確實很難過。

但，在老闆心裡可不是這麼想的。

老闆想的是，我答應客戶X月X日要能使用，我需要在記者發布會之前，讓XX功能出現，這個deadline都是訂好的，而且還需要留一點buffer，然而到今天，我甚麼都沒看到。工程師說已經完成了80%，什麼底層架構元件都做好了，最後只要把這些組在一起就可以給客戶用了，但…每次就是那該死的10%花了最久的時間(然後delay)，結果因為各種我聽不懂的意外(程式碼合併衝突? 套件衝突?OO框架有個XX的坑? 程式碼都是對的，我們這邊都可以用，但客戶環境有問題，找不到原因…這什麼鬼?)，導致無法準時交付。

過去有這麼多奇怪的延遲的經驗，而現在我(老闆、客戶)什麼都看不到，感到非常沒安全感。

我不知道這個是不是換了位置就換了腦袋? 但開始身兼專案資方身分幾年後，我對這件事情確實有了不同的感受。

老闆在意的常常是 time to market， 有時候，如果不能在某一個時間點推出產品，前面所有的努力(投資)基本上都是一場空。特別是這個競爭激烈且變動的時代，市場瞬息萬變，這幾年我們經歷過疫情，大家也開始能夠體會，許多時候，時間(或機會)是不等人的。

這讓過去瀑布式的軟體開發，顯得更力有未逮。

當天，我在會場對大家的回答是 : 這個問題本質上其實是一個『溝通問題』。

因為，雖然時程和deadline看起來是不可變動的，但老闆要的其實是敏捷度，是面對市場的機動性(彈性、選擇性)。而工程團隊要的呢? 是足夠的時間嗎? 如果有更多的時間，就一定能夠提升品質嗎? 其實不盡然! 開發軟體多年之後，你會知道，永遠沒有足夠的時間，就像系統永遠沒有完美的一刻一樣。工程團隊要的，其實是自由度。

軟體要能做的是持續改善，時間是永遠不夠的，也永遠沒有所謂的完美。一個活著(有人用)的軟體，就是必須持續調整、持續改善。

那如何縮短客戶(老闆)與開發團隊之間的落差??
我真心認為 『扎實地落實敏捷迭代式的開發』就是重點了。

每兩周(或每周，每一個迭代)把成果交付給老闆或客戶使用(注意，不只是看，是真的上正式機去使用)，老闆有責任提供反饋，不要再等上線前一周、前一個月，才去測試成品，要從專案開發kick-off後就開始，每兩周交付一次、使用一次，這樣才可以強化溝通，減少資訊落差，確認彼此的認知和需求。

而開發團隊也需要清楚的告知客戶(或老闆)，如果現在我們要趕時程、走捷徑，將可能付出什麼代價(技術債? 資安風險? 未來維護困難?)，把這些都攤開透明，讓客戶(或老闆)清楚的知道，縮短時程所需要附上的代價，然後大家一起來承擔，這就是敏捷了。

而採用敏捷式開發，只是把原本的開發方式變成更小的一個階段一個階段? 不!不!不!

如果你這樣想，就是天大的誤會，當開發要變成迭代式，例如改成兩周交付一次，那所需要調整的，絕不只是改改團隊開會的時間和頻率而已。而是，系統架構、框架的選擇、版控策略、團隊合作模式、系統設計方式、甚至UI/UX的做法，都會有所不同。(如果有興趣，請參考我們的敏捷/DevOps 課程)

所以回到上面的問題：
『如何讓老闆重視軟體品質，而非只是想趕時程快速上線?』

我的答案是，這是溝通問題，解決root cause的方式是增加專案透明度和溝通頻率，而實踐上最好的方式就是改成迭代式的開發，而迭代式的敏捷開發，絕對不只是專案團隊改一改作法就好，團隊的底子(技術能力)是否足夠支撐敏捷式的開發才是核心重點。

這也是為何我在研討上常說的 : DevOps實現了敏捷頻繁交付的承諾，而想要真正實踐DevOps，團隊需要技術能力，沒有技術能力支撐的團隊，就好像沒有體力支撐的球隊。

事實上，我在TW MVC這場『Azure DevOps高階工程技術實踐』的分享中，其實整個核心就是在談論這個議題。團隊的技術能力，支撐了DevOps的實踐，而DevOps讓敏捷承諾的頻繁交付有實現的可能。如此一來，才能夠time to market、頻繁交付、持續改善。

後話:
曾有過幾年老闆的經驗後，你可能也會發現，其實老闆不太可能真的不重視軟體品質，因為最終要付上代價的是出資的老闆，公司倒了工程師可以換工作，但老闆比較難。若你發現老闆看似在乎時程遠高過於軟體品質，大多是因為，老闆不知道這些品質犧牲所換來的時程，將來需要付上什麼代價。這一切，依舊還是溝通的問題。但『做好溝通』沒有想像的簡單，不是開幾個會把話講清楚就可以解決的。因此，迭代式的敏捷開發，才是解決root cause的最好辦法。