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

enter image description here

在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的最好辦法。

留言

這個網誌中的熱門文章

使用 Airtable 在小型需求上取代傳統資料庫

使用Semantic Kernel 建立自然語言請假系統

精彩(且驚人)的Semantic Kernel入門範例

在 LINE Bot 開發中使用Semantic Kernel建立自然語言請假系統

專業的價值...