大家中秋節快樂！
管事是技術管理的另一個一個專業項目，大部分的技術組織雖然有PM的角色，但技術管理者仍然會需要管理工作項目，尤其是跟技術相關的事項。這次想跟大家討論「預估」這件事。
預估的準確性
在我的經驗裡面，在軟體開發中，如果這件事情曾經作過，這樣預估就會非常準確。但通常開發軟體就是為了要將某些流程（商業邏輯）自動化，如果流程已經自動化了那其實也不太需要重新開發軟體，因此幾乎所有的預估都是不準確的。這個不準確包含有：
所需要的工程師人數
需要的時間
而且軟體開發有個特性，就是「可用的軟體」不等於「按照規格開發的軟體」。通常需求也是在軟體開發的過程中不斷的釐清、調整後，才慢慢接近「可用的軟體」這個狀態。這樣也表示所需要的時間會隨著需求的變更（requirements change）而不斷變動。在這個狀態下，預估時間變得沒有意義了，因為若很準確的預估出時間，但交付的卻不是可用軟體，是沒有辦法產生商業價值的。
如何作預估
但這樣表示我們不做預估了嗎？話也不能這樣說。我認為即使預估不準確，但仍然要嘗試作預估的原因有二：
可以相對地比較工作量與難度
預估和實際結果能作為比較，當回顧會議時能夠討論當初預估時沒有考慮到的地方，作為之後工作上的參考
也就是說，在軟體開發中，預估是用來作相對比較用的；並不是指一個軟體開發專案能在三個月做完，而是兩個專案可以相互比較出工作量的多寡與難易度的高低。
通常我作預估的方法有兩個：
點數制：類似 Scrum 的點數單位，將工作以難易程度量化
區間制：預估是以區間為單位，規模越小的工作越精確。例如一個小型的工作可能需要 3~4 個工作天，而一個中型的工作可能需要 2~3 周
這樣的預估方式，可以很容易地讓團隊按照以前曾經作過的經驗，相對評估出這個新的工作可能的工作量與工作時間。
預估的應用
當預估的規模被估計出來後，常見的用法是，團隊會跟預期的交付時間比較，決定是否能夠準時交付。這是一個很直覺的作法，但通常的問題是：如果比較後，不能趕上預期交付時間，那要怎麼辦？加人嗎？還是加班呢？
我覺得這樣的作法都不太好。我會比較建議的作法是，交付的時間、使用的資源固定，但調整交付的範圍，在滿足商業需求的前提下，提供可用的軟體。也就是專案管理金三角，主要調整 Scope 的部分。
舉例來說，開發一個問卷系統，如果要在兩週內以兩個工程師的資源完成，那可能會先不開發管理後台，先以定期報表的形式將資料傳遞給需求單位。這是因為問卷系統的商業需求，主要是為了收集客戶回覆資料，而整理與統計資料並不是核心的需求。白話一點來說，沒有整理或統計的功能，並不會讓問卷系統無法工作，只是操作起來比較麻煩一點而已。
因此，延伸這樣的概念，每次開發軟體的時候，都是在開發當下的 MVP（最小可行性產品），並解決以下三個問題：
這解決了什麼樣的核心問題？提供了什麼價值？
這件事最大的風險是什麼？
如何用最少的資源去完成？
Minimum Viable Product (Source)
然後每次的迭代都重複這樣的流程，並且注意兩件事：
每次迭代都要是可用的產品（不是上圖中的第一列）
新的產品並不是砍掉重練（上圖中的第二列），而是對舊的產品作調整（上圖中的第三列，先用人力推車，再來放入動力與調整外觀）
如此一來，就能夠持續提供價值給客戶，並且客戶也能夠預期在某一個時間點能得到一個改善後的版本（因為交付的時間固定了）。
接下來，固定每週一會推出一篇技術管理相關文章。如果你有興趣，歡迎留下 Email 來訂閱電子報喔！