我最近隨手拿起書架上一版多年前的商管漫畫看，裡面的主角遇到的問題是，她負責的公司面臨倒閉危機，這間公司一條龍從成衣的設計、製造，到銷售，都一條龍包下來。但是由於銷售狀況不好，現金流不足，快要無法償付銀行的貸款利息。銀行端要求主角在半年內想辦法生出十五億現金還貸款，才不抽銀根，不然公司就要破產了。

主角嘗試了很多方法，最後，她在實地探訪工廠時，找到了藏在裡面的「現金」，這個現金就是：半成品庫存。

原來在生產的流程當中，除了產品的銷售之外，還有幾件事情會造成庫存的「淤積」：

1.在每道工序之前抓的「緩衝」

2.每道工序要到下一階段時的「累積」

什麼意思呢？

成衣的製造流程很長，包含：

材料準備->裁剪->縫製->品質測試->出貨

每一個工序又分成許多幾個小工序，例如「縫製」，可能就有縫製扣子、縫合不同部位的布料......等不同的工序，而這間工廠為了運作上的效率，會統一大量準備一批半成品之後，再往下一個關卡送，例如裁剪，會統一裁剪某個部位，例如袖子，裁完一批之後再裁剪其他部位，例如和袖子接起來的衣服，然後都累積一百件之後，再送到縫製關卡，而縫製關卡，則要等袖子和衣服本體都到了，才能將兩者縫起來，所以就會有中間斷層等待的情況發生，這樣一來，工廠將會堆滿半成品，成品要等待很久才能真正出貨賺錢。

同時，每一個關卡又需要保留一些備品，以免有不良品的情況發生，加上訂購量大較便宜，就造成「預備品的浪費」，所以推到源頭，原本出一百件衣服的貨，可能下單時要下到好幾倍的原物料，原本計畫可能大量採購的布料，可以重複使用到其他的產品上，但也往往閒置在倉庫裡，造成資金的浪費。

看到這邊我突然想到自己的軟體開發專案管理經驗，有了一些感觸，也有自我檢討，跟大家分享。

關於專案上抓的「緩衝」

做PM的一定知道壓schedule要多壓緩衝時間，因為專案一般不確定性高，緩衝期可以做為應變時間，我自己大概是都會壓個20%的緩衝，也就是說，工時預估一個月的話，我會多壓一個禮拜的緩衝。

但是這個緩衝時間不是只有我會壓，可能真正的工時是兩個禮拜，但開發的RD回報給RD leader的時候，就抓了一個禮拜的緩衝，RD leader跟我說的時候，再多抓一週，我回報給業務時，再多抓一週，業務回報給顧客窗口的時候，又多抓了一週，顧客窗口也有自己內部要溝通的部門，可能窗口跟他老闆再多抓一週，最後整體時間變成六、七週，膨脹三倍以上，兩個禮拜的小功能變成快兩個月，就跟訂布料要多訂一些當作不良品的準備一樣。

抓緩衝合理，但是當抓的緩衝已經超過原本的工時數倍，就是個問題了。

怎麼減少這種問題呢？

首先，先思考為什麼大家都要抓緩衝？

這常常是因為歷史的教訓，交付時間真的不準，導致安全感不足造成，也就是工廠的「良率」不夠高，只好多備一些緩衝，為不良品做準備。

在專案上，可能工程師之前答應的專案時間，延遲之後被釘翻天，下次就會多抓幾個禮拜，以免出包自己扛，業務對客人也是，時間到了東西交不出來，一定被客戶釘在牆上，為了避免這種冏境，就會造成這種層層緩衝的情況。

如果源頭的開發時間能越來越準確，或是各部門越來越能接受「專案總是有些無法預期、不準確的因子存在」，不要在delay時大家怪來怪去，而是一起解決問題，可以減少一些抓緩衝的誘因，或是抓的時候，會少抓一點。

接著，「緩衝的使用」需要被控制，讓緩衝真的只是緩衝，要努力不動用到。

有時一旦準備了緩衝，常常就會把它當成正常工時用掉XD

就好像小時候為了避免自己遲到，我會將錶調快十分鐘，結果最後自己在看時間時，還是會無意識扣掉，很快就失去效果。抓了緩衝後，有時我做專案遇到風險時，常會不自覺想說有緩衝，就會比較容易讓它過了，最後緩衝都不緩衝了，總是變成真正的工時，對這樣的情況，PM必須有自覺去控制自己對緩衝的使用。

另外，對工程師來說，即使提早做完，也總是不想讓PM知道，以免下次被壓時間，不如把多的時間拿來「看看能多做一些什麼」，但這最後常常變成「鍍金」，增加許多無意義的優化，所以，緩衝也不緩衝了。

對這樣的情況，除了我會用溝通慢慢讓工程師理解，我依然會尊重他們的評估，不會因此壓之後的工時，同時，讓他們理解，早一點上線、他們趕快釋放到其他專案，對專案變現其實是很重要的，他們也可以做更多有價值的事。

另外，減少關卡也是一個方法，既然每一關都會抓緩衝，是否有機會能減少關卡，例如PM直接對客戶承諾工時，而不再經過業務，或是用自動化測試，減少QA這邊抓緩衝的可能。

對於工序「累積」的一些思考

書中關於庫存的案例提到，他們會一次做大量再往下一關，造成大量半成品的累積，這讓我想到傳統在做瀑布式開發時，也會開發許多功能再一次上線，這部分能不能優化？

大量做再往後交付的好處是，有些工序會有時間的固定消耗，而累積多一點再一次做，可以分攤掉那個固定消耗，所以瀑布式開發會一次規劃許多功能、一次多人同時開發、一次全部測試、一次一起上線，這就好像家庭主婦每天煮菜很花時間，每天可能花兩個小時，但有些主婦會在週末一次煮一個禮拜的份量，一次花一個下午四個小時就搞定，週間再熱就好，一週省五、六個小時。

但是這樣做的問題就是，很多功能「累積半成品」在開發團隊身上，無法趕緊測試完畢上線，就無法先搶到市場，或是帶來銷售利潤，這也可以看成是現金「淤積」在開發團隊身上，其實是一種浪費。另外一個風險是，幾個月過去終於上線，但可能市場需求已經改變，就像衣服的流行已經改變，或是已經換季，原本的需求都冷掉了，整個專案變成更大的浪費。

再往細看，由於功能累積在每一個關卡，下一關就在「等待」，會有資源浪費，例如PM還在設計一大批功能時，時間卡在PM身上，RD沒辦法做，但還是要花許多時間開會討論內容，在實際做的時候由於距離規劃時間較久、規模較大，又無法很正確地同步要最後的結論。

同樣地，開發時，功能在開發團隊身上也會卡一段時間，無法到下一關「測試」，那時就是工程師昏天黑日加班時，卻是測試人員較閒置的時間，也造成資源的浪費。

當然RD／QA也可能會在不同專案中被調來調去，以避免浪費，但若是要開始做時調不回來，又變成專案的風險，或是又有某個關卡要等待－－PM最怕的就是聽到「這個功能估計一個月可以做完喔！」之後緊接著聽到：「但是現在在做其他專案，要排隊三個月」，這要如何去跟業務以及客戶說！

但是敏捷式開發卻可以解決這個問題，它用「短週期衝刺出一個功能，快速交付，再快速迭代」的方式，減少了中間閒置的浪費，就像成衣廠原本是要一次裁剪一百件衣服再交付到下一關縫製，變成一次裁10件衣服就往下一關交付，可以更快產出「成品」，立刻銷售帶來現金，有現金就能再做下一輪投資，整個「現金流」才真的流暢了起來，而不是一攤死水。

不過，中間的固定成本怎麼辦？這樣就回到家庭主婦每天花兩個小時的問題了呀？

我認為軟體開發過程中，最大的「固定成本」，在QA測試－－每次開發一個功能後進測，QA要測的其實不只那個功能，而是要測該功能影響的全部層面，還有基本的穩定性測試、相容性測試等等，如果每加一個功能就要全跑一次，QA一定會崩潰，但不測又無法上線，怎麼辦？

這就是為什麼敏捷式開發常會搭配「自動化測試」－－測試不用全由QA跑，用程式想測幾次就測幾次，也就是家庭主婦每天煮飯，但是搭配「洗碗機」，可以自動洗碗盤，每天可以再省下半小時的時間，媽媽就又能每天做菜，還能提供新鮮的餐食了（變成媽媽之後舉的例子都變成媽媽了！）

以上就是我從庫存管理、會計現金流的思維，延伸到軟體專案管理的一些體悟，很多線上課程的學生問我，沒有相關產業經驗，如何跳槽到該產業？我認為其實很多思維是共通的，端看你有沒有去觀察與思考，希望這篇文章可以給我的學生們一些範例與幫助！

本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。