獨孤木 2006/04/17
可以預測，真的那麼重要嗎？
很多很驚人的東西，一開始的開發，都來自於一個簡單的念頭。比如說Linux，Napster，或是iPod。像是Napster這樣的東西，是由一個人獨力完成第一個版本的研發，這對很多人來說，其實是件蠻不可思議的事情。
尤其是當你開發一項前無古人的產品時，大概任何嘗試準確預估未來，可以按部就班遵循project plan的正統開發方式，都會面臨不斷的修正。也就是說，你花一堆心血在做的project plan，有可能一做完就馬上過時了。
改成是按照時間來切割，不斷推出新的版本，然後修正產品的開發方向，可能會是一個比較好的開發方式。比如說每兩到三個月就推出一套新版本，然後不斷讓這套軟體，跟隨時間而演化，對於開發產品來說，應該是一條比較可行的路。也就是說，當你要開發的產品複雜度不會太高，規模不會太大時，用精簡的人數，不要預設太多立場，改成是定期做出新版本，這樣且戰且走的方式，可能是一個很好的作法。
在這種狀況下，你不做任何預測，改成會是不斷地有一套東西可以評估它的效用，並且修正他開發的方向。這對開發概念還不成熟的產品，其實是很好的開發模式。當然，如果你做的是需要在一定時間內交出最終版本的專案，那就不能套用這種作法了。
不過任何從事軟體開發的人都應該要仔細想想，你如果都做一些可以事先預估的很精準的開發工作，其實就表示你所做的東西是重複性比較高的東西。做專案可以讓你餓不死，不能夠讓你做出一些流芳百世，萬人稱頌的東西。當你規避風險，追求安定的同時，其實就是跟高報酬說bye bye了。專案可以預測，真的有那麼重要嗎？我想每個人，會有他自己的答案。
結論
量化的管理在幫你評斷現在的狀況時，可以起不小的功用。不過當你要進行估計(estimation)時，那就不太一樣了。估計常常就會被解讀為承諾(promise)，而承諾則會影響我們解讀真實狀況的角度。當你估計出一個案子要做三個月，常常就會被解讀成三個月內就要把案子結束掉。接著你就會不斷被這個數字，拿來檢視你的進度。你會花很多時間去解釋這個目標為什麼沒辦法達成，你為什麼會有這樣錯誤的預估，這類的問題，而不是你實際上完成了那些東西。接下來又應該要怎麼做。
這樣的管理模式，其實並沒有對於軟體開發有什麼實質的幫助，反倒讓很多人把心力集中在怎麼樣在一開始的時候浮報數字，以及到中期要如何編造數據，推諉卸責。可悲的是，在大多數目前我所看到的專案團隊中，這種情況還蠻普遍的。
不久之前看了一本很棒的書 『魔球(Moneyball：The Art of Winning an Unfair Game) 』。裡面提到了奧克蘭運動家隊採用了跟別人截然不同的客觀量化標準，來選擇他們的成員，然後用極為精簡的預算，持續好幾年達成別的球隊，花上好幾倍的金錢，也得不到的好成績。
在軟體工程這個領域中，其實有太多人不斷在嘗試找出類似的指標。就如同股市之中，所有分析師都在尋找萬無一失的必勝法則一般。每個人都在期待，透過別人所不知道的算牌絕技，可以找到正確預估未來，或是可以讓專案成功賺大錢的勝利方程式。
不過以我的經驗來說，我並不覺得我們目前的量化評量方式，在估計這件事情上，可以幫我們多大的忙。我個人認為，量化專案管理數據，然後進行技術分析，有它的賣點，不過這種管理方式，依照目前的學說拿得到的數據來看，大概就僅能提供參考。尤其是影響專案開發的變因這麼多，你很難從幾個簡單的指標中，就找出專案預估方程式。目前看到的理論，只是希望可以幫你找出比較可能的落點。頂多只是在你頭一次進行預估的時候，可以讓你在沒有太多東西可以提供判斷的時候，先有一個看來比較科學的推估，可以當做基準。至於日後進行專案管理。其實技術方面的指標就只能當做參考，基本面才會決定一切。
專案的基本面是什麼？其實就是人。很多時候，專案會不會成功，會不會做得很順，從它的團隊名單，有時候有經驗的人，瞄一眼就大概知道了。如果你把重點繼續放在量化各項專案指標，期待從不同專案中找出通則，通常這樣的預測還是不如你從團隊組成份子不同來進行猜測來得準確。
這其實跟職業籃球隊很像，上一季還是很強的球隊，到了這個球季，有幾個明星球員被人挖角後，很有可能就會從此一蹶不振。每個人都很強，也不見得可以拿到總冠軍，不對的人組合在一起，即使你有郵差Karl Malone(卡爾‧馬龍)，Shaquille O'Neal(俠客歐尼爾)，Kobe Bryant(小飛俠布萊恩)，跟手套Gary Payton (蓋瑞裴頓)，你還是贏不到NBA 總冠軍。籃球之神Michael Jordan到了巫師隊，也是只能乖乖認命。
所以當我們在進行專案管理時，如果你把重心改成如何評鑑每個人的才能與特性，然後尋找組成一支夢幻球隊的秘訣，從這個角度來看的話，可能就可以組合出屬於你自己的總冠軍球隊。
我前一陣子去看了「冰爆好萊塢」在台北的表演。所有的表演者必需在整個表演進行的過程中，非常緊密地協調與結合在一起。大家必需要有共同的節奏，而共同的節奏，又必需跟上音樂的節拍。有時候空中轉了好幾圈，不小心跌倒了，還要若無其事地繼續跟上音樂的節拍。
我在那個時候的感覺很深刻，如果我們的專案團隊，可以有這樣的共同默契，開發一套軟體，應該就是一件輕而易舉的事了。讓所有的人，都意識到相同的節奏，並且能夠讓彼此跟隨著這個共同的節奏來進行各項專案的工作，這應該是在專案進行中，一件最重要的事吧。像這樣的默契，其實在各種量化的指標中，是很難看得到的。
如果我們遇到問題，就像溜冰的表演者不小心跌倒一樣，其實我看到很多專案的團隊都會花很多時間交相指責，或者不斷窮究原因。如果當跌倒的人一跌倒，音樂就馬上停止，所有團員圍過來公幹，這樣的戲碼有人要看嗎？那為什麼我們在專案進度趕不上時，卻會不斷要求專案成員做很多沒有正面生產力的事呢？
當不懂得基本面，不了解現況的人越是認為自己掌握到的資訊不夠，又越想幫忙時，就越容易出現這種狀況。這樣說來，可能怎麼樣來配合最簡化的技術面資料，來評估專案的基本面就是一件很重要的事情了。專案管理的基本面該怎麼看，那就又是另外一個主題了。
沒有留言:
張貼留言