Time sheet discussions

在小魚那裡讀到關於廣告人對工時單(Time Sheet)的看法(subject:是广告公司还是财务公司？ ), 挺有趣, 關於"創意"到底能不能完全用時間來量化然後計算費用, 他們已經有很精采的討論, 那對於軟體公司或IT部門來說呢?

填time sheet對很多人來講的確是個惡夢, 尤其是沒有習慣每天寫的人, 像是在下小妹我, 就常常在月底的時候, 開始翻outlook的calendar、inbound outbound mailbox逐一對照每一天我到底幹了什麼事情?開了幾個會? 尤其要求嚴格的time sheet, 還會要你把工作內容的大概描述填上去, 這時候如果沒有信件往來當log, 絞盡了腦汁大概也想不出來上禮拜三下午到底幹了什麼正經事吧.

想起了項目以後, 還要填時數. 這場會議開了多久容易記, 可是呢, 這個design model到底花了多久的時間才完成? 只算我坐在電腦前面拉diagram的時間嗎? 為了先了解需求作requirement study的時間算不算? 那上廁所走路時思考哪一種pattern適合用的時間算不算? 翻書reference或找同事討論solution的時間算不算? 雖然說software engineering翻作軟體工程, 事實上中間的過程, 要叫做"工藝"會比較洽當, 因為人的思考畢竟和機器的製程不同, 儘管有些做法會很類似, 但是有太多不可預期的巧思會發生, 不但導致結果不同, 過程中所花的時間也沒有辦法很精確的被量化.

而且, 對大部分的software house來說, 人的cost是採人月來算, 而不是工時(這要歸功於萬惡的責任制, 加班也沒加班費啊!) 所以填工時表在resource和schedule management上的意義, 就大於在成本利潤的管理了. 例如, manager可以根據每個人在每項task上所花的大略時間, 去monitor配置的resource是不是overloading, 有沒有delay規劃時程的風險.

對於time sheet, 有一個想法是, 與其拿來作紀錄, 不如拿來作計劃. 把每一項預定要作的事情跟時間先作weekly plan, 再用review的方式調整每天的結果; 我見過一家公司將time sheet與project plan整合得很好, manager先做好專案計劃, 裡面包含每個phase的action item、所需的resource(unit: person)、所需的時間(unit: hours), 然後每個專案成員登入time sheet系統後所看到的畫面, 就是他在這個專案要執行的工作項目, 他只要把時間丟進去就可以了, 再另外填一些common的項目, 例如travel、idle time(沒有錯..雖然我真的不知道如果加班也沒錢拿的公司對於這個項目要作何處置..)、vacation、self study...etc.

沒有人喜歡作拖延自己下班時間的事:p 如果可以讓填timesheet變得比較方便(最好是不用填...), 同時也讓個人可以感受到這個看起來像是reporting的動作, 不但有助於self-management, 也對prj management有利(那當然是pm要會"關心"這些數字), 寫time sheet才會比較有意義吧.

Permalink | Comments (0) |