這是個很多人有討論過的主題，我也來說說我的想法吧
時程的預估可以分成
1.專案進行前的預估
2.專案進行中的預估
首先講講專案進行前的預估
為什麼時間要能被估算呢?
通常專案是要先報價，報價完，客戶同意，簽了約之後，開發團隊才開始進行開發(不然做完後客戶不想付錢，不就白做了?)
報價要報多少才合理呢?這會需要考慮成本也就是完成時間，完成時間不可能做了再說要多久，一定是要先預估
這個時候的預估通常是不會準的
1.變數太多
要用的技術可能有地雷沒考慮到
實際上能用的人力可能沒那麼多
2.不會想好好估
能不能接到案子都不知道，所以估時間的人通常不會想得太仔細
甚至估完後可能時間又會為了方便接到案子所以砍時間，但就算肯定不準，這時間肯定要預估的，能做的只是多考慮風險與多加些緩衝(不考慮風險，勇敢往前衝是常見的台灣老闆風格)
再來談專案進行中的預估
如果有接到案子，開始進行專案，通常這時會訂好專案的里程碑，甚麼時間到甚麼時間要做好甚麼事情，我記得這部分在PMP的書也有提到
時程的規劃和里程碑的定義往往是還沒做之前就已經預定好的，通常一開始也會訂得很粗糙，不會訂得很細
有的管理者會用菜市場砍價的方式去跟工程師砍時間，他們也知道實際時間可能會超乎預估，所以通常會要工程師答應個完成時間
要是完成不了就可把責任推向工程師，時間壓得越低，就有更多充裕的時間處理客戶預料之外的需求
這時的時間預估，關鍵其實並不在到底需要多久，而是雙方談判結果
這時候估不準會有很多可能原因
1.PM隱瞞資訊
如果工程師因為資訊不足，少考慮到該考慮的事情，導致時間估太少，PM可以說「這時間你答應的」，然後要工程師就算加班也要做完
2.出現預期外的問題
寫程式總是會出問題的，一般人是無法寫之前就知道會產生多少bug，更無法預知需要多少時間解決這些bug，這會增加額外的時間
3.出現預期外的需求
很多人看到實際的成果比較有感覺知道自己要甚麼，這時就會出現預期外的事情要做。有的人可能會說:「這就該算需求變更，應該要加時間與加錢啊」。但台灣文化常常不講道理的，有時關係與人情會導致加量不加價。
4.其他專案風險
像是有人跑掉啊、被客戶或第三方廠商拖累啊。前面就說台灣老闆都很勇敢，視風險於無物的，出問題是很正常的。
預估要準要靠甚麼
1.每次規模不能太大
越小規模的需求，因為變數較少，所以較容易預估
雖然規模小仍然會有預估的誤差，但這誤差也較容易控制(你們覺得幾天的誤差和幾週的誤差哪個好控制?)
另外所謂規模不能太大，也包含著要能控制住每次預估要做的事情，不能邊做邊想把範圍做得更大
2.評估者越中立越好
我認為最好的狀況是「可能」負責處理的人
如果時間估太短，有可能他自己要承擔後果
如果時間太長，那可能就是看別人爽
3.多人共同評估
就算沒有私心，一個人也可能在思考問題時腦袋打結轉不過去
導致判斷失誤(我會這樣)，多點人一起思考，比較能往多種角度看問題
4.相關知識與經驗
知識與經驗，可以讓人知道許多問題的解決方式，以及可能造成的地雷
如果正確使用scrum，1~3點都能解決，但正確是一個問題
很多事情，即使知道該怎麼做，要實現是很困難
就像很多人知道該減肥，也知道怎麼樣能減肥，但是就是沒有好好地做減肥該做的事情(為什麼我會舉這個例子呢?我最近剛好想減肥，又開始有些惰性了XD)
留言列表
