你的專案裡,卡了許多現金嗎?

你的專案裡,卡了許多現金嗎?

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

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

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

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跑,用程式想測幾次就測幾次,也就是家庭主婦每天煮飯,但是搭配「洗碗機」,可以自動洗碗盤,每天可以再省下半小時的時間,媽媽就又能每天做菜,還能提供新鮮的餐食了(變成媽媽之後舉的例子都變成媽媽了!)

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

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