l

2017年3月13日 星期一

價值 VS 技術

March 12 21:10~22:28

屏幕截图 2017-03-12 22.17.55

 

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

價值驅動、價值驅動,口號人人會說,但請鄉民們想一下,(軟體)產品的「價值」來自於哪裡?

***

老闆觀點 

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

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

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

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

***

開發人員觀點

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

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

***

有價值沒技術,有技術沒價值?

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

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

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

***

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

Teddy:為什麼主管不讓你重構系統?

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

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

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

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

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

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

***

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

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

***

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

沒有留言:

張貼留言