價值 VS 技術

March 12 21:10~22:28

 

敏捷方法是一種價值驅動（value driven）的開發方式，強調團隊注重交付給使用者的價值勝於計算完成功能的數量。唯有交付對使用者有價值的產品或服務，滿足使用者的需要、解決問題，使用者高興之後爽快且持續買單，與公司之間建立良性循環，公司才可長久經營。

價值驅動、價值驅動，口號人人會說，但請鄉民們想一下，（軟體）產品的「價值」來自於哪裡？

***

老闆觀點 

大部分的老闆或高階主管，已經很少動手寫程式。他們把軟體開發視為一個「黑盒子」，主要只關注兩點：

• 輸入：接了多少案子
• 輸出：開發多少功能、賺了多少錢、增加多少客戶

至於產品是怎麼做出來的，只要東西可以動，錢收得到，其他都不是那麼重要。

曾經聽到不少老闆與主管跟Teddy抱怨：「開發人員過於注重技術，不管開發時程」。這種人雖然技術能力很好，但卻不一定是老闆心目中最佳戰將。

***

開發人員觀點

開發人員也想把產品做好，無奈軟體開發有太多「歷史共業」要處理。軟體雖然叫做「軟體」，但其實一點也不軟，而且還非常的硬，硬到開發人員改不動。有經驗的專業開發人員都知道，軟體要能要軟，一定要讓程式碼處於「乾淨」（Clean Code）的狀態。這絕對不是「只管技術不管時程」，而是為了走更長遠的路所以要打好基礎。

很多開發人員經常抱怨：「手邊的程式碼一團亂，公司也不給我們時間整理，每天看到這麼髒的程式碼真的很痛苦。不但開發快不起來，而且很容易出錯。」

***

有價值沒技術，有技術沒價值？

從「黑箱」的角度來看待軟體開開發，推到一個極致可能會變成「我只管交付給使用者的價值，技術不重要」。但這世界上有多少產品或服務是「不需要技術又可以帶給使用者很高的價值」？

反之，過於注重技術，只求用最新、最酷的技術來開發軟體，往往會因為低估新技術帶來的風險而導致時程延誤，影響價值交付的即時性。

N年前有個朋友想在一個產品開發中導入自動化驗收測試，但產品的開發時程很緊，不可能暫停開發只做自動化驗收測試。最後朋友想到用「預算制」的作法，開發團隊與Product Owner協調出每個sprint「編列若干小時的預算」來落實自動化驗收測試。這種作法關照到產品開發的需求，也漸進式的滿足開發人員對於「讓軟體變軟」的渴望。而這些自動化驗收測試，也在一年後某次軟體元件升級中「回報」開發團隊，快速找到好幾個bug，大大縮短了那次升級所花的時間並且也保證了釋出軟體的品質。

***

有一次一位畢業沒多久的學弟跟Teddy聊天，因為在學校學了一身「功夫」，上班之後想要好好施展，但公司主管卻不准他重構系統。他看到亂如義大利麵的程式碼卻又不能重構感到非常痛苦，於是心生離職的念頭。

Teddy：為什麼主管不讓你重構系統？

學弟：我也不知道啊，反正我提出來說程式很髒要安排時間好好重構一下，就被打槍了。

Teddy：如果只是小幅度重構，你在開發功能的時候直接重構不就好了，為什麼要主管安排額外時間？

學弟：當然不可能小幅度重構啊，整個系統運作了好幾年，一定要大大的重構才有可能改善。

Teddy：你才剛來公司沒多久就提出要「大大重構」，如果我是你主管我也會「大大害怕」啊。

學弟：總之我覺得這個公司不行，軟體開發方法過於落後，我已經決定要換工作了。

Teddy：下一間公司…不一定會更好。

***

軟體開發是一個經濟問題，要得到最佳的投資報酬率，要考慮的因素（force）很多。能力越強的人，越知道如何動態平衡這些因素。價值愈高的產品，通常需要越強的技術作為後盾。「技術」不光是寫程式的能力，軟體生命周期的每個環節都需要關照。

各行各業所需要的核心技術不同，找到自己行業的核心技術，不斷增強這個技術以支援價值交付，最後培養取捨的判斷力。剩下的事情，就只能交給老天爺了。

***

友藏內心獨白：基金投資有賺有賠，申購前請詳閱公開說明書。