l

2010年4月22日 星期四

軟體庫存

4/21 23:07~ 4/22 00:33

2009 年下半年金融海嘯發生的時候,國內某家以產品品質『以卵擊石 堅若磐石』為賣點的電腦公司發生了創業以來第一次的虧損,據報導主要的原因在於該公司對於景氣過於樂觀,製造了一大堆的庫存。沒想到金融海嘯席捲全球,這些庫存賣不出去,造成不少庫存跌價損失。

公司的(成品或半成品)庫存水位很高,其實是一種警訊,它會掩蓋許多流程上的問題。例如,公司的行銷或是業務部門沒有做好市調或是市場研究,因此生產了一堆沒人要買的產品堆在倉庫。而公司為了打消庫存,可能會想一些『手段』想辦法把客戶不需要的產品『塞』給他們。對公司與客戶來講,都是一種浪費。因此『精實生產』(Lean Production)的一項重要改善活動就是要降低庫存,期望達到『訂購生產』(客戶下了訂單才開始生產,但是要想辦法在很短的時間交貨給客戶)的目標。

***

那麼,軟體呢?如果軟體庫存太多會怎樣?

鄉民甲:騙肖ㄟ,軟體看不到也摸不著,那裡會有庫存的問題?

以下 Teddy 列幾項軟體庫存的例子給鄉民們參考,參考:

  • 部份完工的功能(partially done work):這種類型的庫存量在開發中的軟體系統中佔了非常大的量,例如,沒有測試的程式碼,沒有整合的模組,沒有重整過的程式,沒有說明文件的功能,無法安裝的系統,沒有解決的 bugs。這一類的軟體只能算是『半成品庫存』,看起來好像系統開發的進度很不錯,但是實際上沒有一項功能可以真正被使用。
  • 額外功能(extra features):這種『沒有列在需求中的額外功能』通常是開發人員『預留伏筆,以求自保』的招數。『既然都做到這裡了,以後 users 應該也會需要這個和那個,所以就順便一起做一做好了』。這種『要五毛給一塊』的情節也不算少見。
  • 過度設計(over design):做軟體的人都知道 users 和需求都是善變的,因此傳統的軟體工程教育我們要『為未來做好打算』(搞得這些做軟體的人好像都要變成算命師)。因此,很多人習慣在軟體開發之初便要設計一個可以『應付未來』的架構。所以,這邊增加一個 XML 設定,那邊套用一個 pattern,上面加個 MVC,底下補個 OR-Mapping,中間再應用 SOA + Cloud + Plug-ins + 龜派氣功 + 無敵風火輪 + 黯然消魂掌 + 芋頭牛奶 ... (有怪獸,有怪獸)。最後開發出一套不到 1000 行的留言板系統,寫程式花了三天,設計架構可能花了三個月。這些過度設計所造成的庫存當然也沒推銷出去,最後放到保存期限過期。
鄉民們如果仔細端詳一下,許多 agile methods 的精神與作法都與『消除軟體庫存』有關,而改善軟體流程的手段,也可以從『如何消除軟體庫存』來思考。例如,如果鄉民們採用 Scrum,發現經常性的在每個 sprint 中都有幾個 stories 是在解決之前 sprint 發生的 bugs,這就有可能是軟體開發團隊在之前的 sprint產生太多『半成品庫存』的現象。解決方法可能是要研究產生這些 bugs 的根本原因(root causes),針對這些原因提出改善方案。或是檢視每一個 story 是否有清楚定義出『DONE』的條件,這些條件是否需要修正?開發人員是否清楚這些條件且確實遵循?

軟體庫存也會隱藏流程上的問題,例如,因為流程規劃不當或是工作分派不均,造成團隊中有些 programmers 已經閒閒沒事做了。這些『櫻櫻美代子』的 programmers 只好沒事找事做(記得侏儸紀公園的至理名言:生命會自己找到出路),一不小心就製造了許多軟體庫存。乍看之下這些 programmers 的確有很努力的在工作啊,搞不好還加班到 11,12 點。但是如果這些產出只是增加不必要的軟體庫存,那麼很明顯地是開發流程出了問題,需要改善。Teddy 再強調一次,庫存會隱藏流程上的問題,需要密切控管。

***

庫存可能會漲價,也可能會跌價。對於軟體庫存而言,跌價的機會似乎比較高一點。此外,製造出這些軟體庫存也是要花成本的,這些成本都算是一種時間與金錢的浪費。鄉民們,抽空盤點一下你的系統,想辦法消除不必要的庫存。

友藏內心獨白:做軟體的人可真是會 抄襲 學習,建築的也抄,生產管理的也抄,算是現代版的吸星大法。

沒有留言:

張貼留言