IDEA#105 少用直覺，多用計算

一直以來，都想做個可靠的員工，而"可靠"我認為就是在上司交托工作後，能即時判斷新增工作相對於整體工作的重要性，並能預測工作需時，交貨日期，及最重要的，對其他已有工作的影響, 如"新增工作G將令工作A延遲兩天，或需要將工作A簡化24%，以追回時間"。

想雖完美，但一直以來都想不到方法如何去做到如此精確。我工作的環境每天都是peak season, 工作日期一改再改，有時真不知如何應對。客戶服務部："這個什麼時候交？" 答："從今天的情況看來就4個星期後吧"。但通常的情況是三天後有會有趕急的工作，所以我手頭上仍然有半年前積壓下來的工作在"進行中"。

最近用了一個月的時間去設計和調試協助我在此等飄忽的工作環境下，都能妥善安排和預測工作進度的試算表。公司喜歡根據直覺調配資源我不能做些什麼，只管做好自己便算。

該表的意念源自一套稱為Scrum的軟件開發體系，最初由微軟的項目經理設計，以克服軟件開發中存有高度不確定性的問題。

Scrum的理念是在精確地計算團隊的作業速度(Velocity)和訂立項目的hard deadline，兩個先決條件下，利用每日和每月的進度檢討會議, 來訂立成果物的開發優先次序。也就是說，項目必定能如期完成，但產品功能的多寡，則完全取決於現場情況。

設計者除了將Scrum運用到軟件開發上外，亦成功將其運用到其他行業。我於是想能否將其原理，運用到管理自己的工作上。所以便根據Scrum的基本原理，設計了一張job backlog試算表。

試算表上主要有以下各項數據：

1. 工作項目的詳細breakdown, 以及根據過往紀錄所得出的baseline estimated hour：例如，工作A作業34屬於性質X，一般需時30分，便填上o.5
2. 作業實際比例：如作業A34的baseline時間為30分，但最終用了45分，則填上150%
3. 調整參數，用作計算每項作業的實質剩余工作時間，數值會根據各作業的實績時間自動調整： 如大部分工作都用了150%的時間才能完成，調整參數便會將其他類似作業的所需時間預測增加到大於100%)
4. 項目整體需時預測欄，用作計算每個工作項目的整體所需時間：如項目A有100個作業，每個的baseline為30分，整個工作項目的預測需時便是3000分，即50個工時
5. 作業剩余時間預測，每天一欄，紀錄工作的實際進度：如作業A36的工作需時為2.5小時，試算表便會自動將2.5填入所有的欄。當工作完成後，只要將當日欄的2.5還原為0即可

(待續)