估不準是大家都知道事情, 這也不能怪大家, 你看什麼時候學校教過? 上班以後也沒人跟你講怎麼做, 只是叫你趕快生一個時間出來. 所以在不教而殺的狀況下, 自然大家表現得都比較不好.
可是有人會說, 我平時也是有看些估算的書籍, 像是 agile 的 playing poker, relative estimation 我就學得不錯, 可是估出來來是不準. 這是為什麼呢? 根據網路上的一些意見, 基本上常見的有以下幾種
1. 需求不明確
這個是最常見的狀況, 當你連要做的東西, 都搞不清楚是什麼時, 怎麼會估得準呢? 其實, 這也很難怪誰, 因為在專案一開始時, 對需求的了解通常是不可靠的. 軟體開發本來就是一個探索和學習的過程, 伴隨著時間的進行, 你才會學到, 原來顧客要的是這麼一回事, 原來那個環境會有這種變化啊.
2. 混亂的開發過程
我想很多一定可以了解, 自己團隊在開發時有多混亂. 尤其是在專案火燒屁股時, 大家都不守王法. 常見的行為像是
不設計就開始寫程式
變數命名很隨意
不做自動化測試
自己寫完就好, 不管跟別人整合是否可以動
不對規劃, 設計或是程式碼做 review
…...
當你越不遵守工程實踐, 後面越是會帶出不可預期的副作用, 導致後面時程, 越來越不可捉模.
3. 只估寫程式的部分
簡單的說, 開發人員只看得到寫程式, 設計人員只重視設計, 測試人員只想到測試執行部分的工作. 大家忘記了, 除了這些主要的項目外, 還有些準備工作, 或是後續整理的事情要處理. 像是
產品安裝
產品輔助系統 (Help system)
測試資料準備
測試環境安裝
持續整合環境建置
參與別人的 review 會議
關鍵技術研究時間
…...
通常這些項目, 根據網路上的研究, 可能會佔到你原先估計時間的 20%-30%. 你說你要加多少的班才補得回來.
4. 沒有經過檢視
有時候我們在做評估時, 都是想當然爾, 或是一時想想, 就趕快給老闆一個答案. 但是如果我們可以坐下來, 大家互相討論檢視一下, 這就可以讓評估的準確率提高不少.
當然啦, 這個過程不是用來壓縮時程. 有些項目你會估的比較大, 可能是你不熟, 風險比較大的地方. 藉由拆解得更細, 或者先做些 POC 的嘗試, 都會讓增加評估結果的信心.
5. 以為所有時間是你的
你以為一週有五天, 每天有 8 小時可以完成工作. 但是莫名其妙的開會, 不小心的 FB/line 的打屁, 老闆臨時的交辦, 這些都讓你一天, 能花在你原先規劃要做的事情上, 其實是遠遠小於 8 小時的.
6. 對某些技術不熟
對要用到技術不熟, 對要處理的領域知識不懂, 在這種狀況下, 任何估算都沒有意義.
7. 太樂觀
這不用我多說了吧, 工程師就是天生的樂觀者, 認為事情應該不會這麼, 否則你以為老人卡是怎麼拿到的. 往往要死過好幾次後, 才會覺悟這一切都不靠譜, 還是 D 槽的好 (誤)
看到這裡, 你中了幾項呢? 基本上, 前面幾項是我們可以藉由改進做事方法, 來改善估算的準確度. 但是後面幾項, 可能就是靠北天了
全站熱搜
留言列表
