控制“庫存”，組織軟體生產的有利武器

絕對沒有錯，庫存在軟體項目生產也是存在的！庫存就是指部分完成的工作，廣義上講就是指已經開始但尚未給客戶創造價值的全部工作。在軟體項目生產，我們可以容易地指出“庫存”：

1. 尚未與使用者進行確認的需求或者需求變更列表是庫存；
2. 尚未被開發階段驗證的設計工作是庫存；
3. 沒有被提交測試的代碼是庫存；
4. 已經“做完了”，沒有通過驗收的開發工作、分析設計等工作也是庫存；
5. ...

理論上講，軟體開發中的庫存量是一次交付中的全部工作量。 這可能是1個月的工作量，也可能是半年，甚至是一年的工作量，但是長期大量持有“庫存”將給我們帶來很多的風險。譬如：使用者A要求我生產100個零件，要求我在一個月內生產完畢，我有以下兩種可能的做法：（當然還有更多）

1. 組織生產，等一個月後，100個零件一次性交付；
2. 組織生產，平均每天向客戶交付3個零件；

以上兩種生產方式看似結果一樣，但是結果差別很大。採用第一種方法的方式與成本潛在的風險更大，因為第二種方法有以下的優點：

1. 減少了庫存管理的壓力，我不需要最大100件容量的倉庫，即便是我有多批生產同時組織，我的組態管理壓力也會少一些；
2. 直到最後一天之前，我的生產一直在開展，如果使用者每天交付的3個零件不滿意，有次品打回，我也能夠快速調整生產，及時修正或者修訂；避免等我最後一天交付，等使用者清點完畢後，告訴我回去再把工人找回來修改！

呵呵，這個例子很簡單，誰聽了都能懂！不如舉舉發生在我們身邊IT系統的庫存故事：

 

故事一：需求變更的故事

昨日開會，某同事談到了項目的超出計劃工作量，需要使用者確認從1月份到9月份，共發生了10人月，但是談到了客戶對10人月有疑義，可能追不回來。是的，可能很難追得回來。原因何在？拋開具體的工作內容的細節，共9個月的庫存現在才交付給客戶，客戶能輕易認嗎？如果這9個月的庫存象其他項目一樣，通過周例會或者月度備忘的方式進行庫存交付的確認，結果可能很不一樣。

故事二：系統開發的故事一

某項目，開發了近一年，然後才交付給終端使用者試用，計劃跟使用者談上線，就發現很多困難。是的，因為共一年的庫存一次交付給客戶，客戶沒有這個信任的基礎，生產了一年，才看了兩眼，就要談上線，很困難。猶抱琵琶半遮面，才剛看一下，就要你結婚，你也不敢啊！（當年慈恩威脅楊過娶公孫綠萼，方可拿到解藥，楊過還不從呢！）

 

軟體品質方面也有庫存的故事，我的體會是品質主要不在於你投入了多少人組建了一個多麼大的後期測試隊伍，而在於測試的時機和方式，等所有功能都做完了再測試就太晚了。

是的，這些都是軟體庫存的故事。掌握好方法，製造“頻繁”交付就是減少庫存的有利手段！從軟體系統來講，零庫存這種極限是每次提交給客戶都是交付就緒的成果。

管理者，你做好控制庫存的準備了嗎？