軟體庫存

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 再強調一次，庫存會隱藏流程上的問題，需要密切控管。

***

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

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