Komiyama

上一篇文章被投訴說與上上篇太過於相近,所以今天就得跳遠一點來個不一樣的東西

所以很多人以為當主管只要看看報表,盯盯數據如此而已這麼簡單,誰不會當主管
其實報表確是個不簡單的東西,每張報表所要看的面向不同相對應的數據來源與結果也會不盡相同
如果用錯數據套到錯誤的報表,那可將是一個巨大的災難
除了無法確實的了解團隊的狀態之外,也會凸顯這個主管根本連報表都無法正確使用

本公司較特別的一點是,開發團隊分別在三個不同的地點而三個地方各自至少相距上千公里遠
所以主管並沒有辦法隨時親眼見到開發團隊的工作狀態及工作內容
只能夠透過報表的數字來反映工作的內容,所以某主管就要求導入了一套以Scrum精神為核心的專案管理軟體
但是總公司有人懂Scrum嗎?沒有!有要導入Scrum嗎?也沒有!但是不要緊,因為就當個派工軟體
我們也只需要發發工作,紀錄Bug管理需求文件,這些功能其實就足以應付了!這倒是不成問題

問題在於,該主管想看到每一個工程師每一天的工作時數及內容;這在一個以燃盡圖為專案驅動基礎的Scrum
專案管理軟體,可不是一個正常的舉動;在Scrum來說時數的估算是為了推算出每一個人對每一個專案可貢獻的
時間及使用率,而不是在計算這個工程師一天做了多少事情的數據;簡單來說,開會,解決bug,發佈版本這些
工作全部都沒有使用時數的計算

因此當該主管在看了第一個月報表之後,詢問人員使用率未何這麼低時有人反映了這個狀況.而主管為此下了
一道行政命令,要求每個技術部工程師在下班之前都要寄一封mail給他,交待今天的工作時數及內容.當然,
三天後他就放棄自己說過的話了.公司三地的工程師加起來夯不郎當也超過200個人,每天收這些mail事情就
做不完了.所以接下來又換了一個做法,要求再也不要使用Bug而將所有派工內容都用任務來處理,接下來就
換測試部門在頭痛,Bug的優先等級解決版本及驗證的資訊這些訊息在任務項是沒有定義的.

最後,身為主管的當然要解決此問題.所以請來了開發此專案管理的團隊到了總公司為大家講解系統的精神及
使用方法,當然也問了"為何Bug不能登載時數"的這種問題.想當然...就是沒有.工程師個人的造業個人擔,
Bug衝出了燃盡圖上,你就必須把他消化掉.所以該主管也只能接受了Bug沒有時數的這個概念.但就我來看,
他其實只是需要一套工作日誌的系統幫他解決這個問題,而不是把所有東西都想要綑綁在派工軟體上面.
用錯工具產生錯誤的數據,只會造成錯誤的解讀.

但是他仍然對本地的人員使用率感到不滿.就我以往的經驗,從事程式產出的工程師一天若有個40%的時間在
處理派工內容,算是可以接受的了,優秀點的會到60%.你要想想剩下的時間他要開會,解Bug,處理雜事,被其他
同事煩擾,幫忙救火之類的,還沒提到廁所,抽菸,下午茶...這樣真的50%的產能時間不錯了吧!這就是工作日誌
所紀錄的內容和派工軟體所消化的任務兩者巨大的差別.

不過上有政策下有對策,既然主管這樣規定那我們也只能乖乖遵循.所以除了派工的SA會將時數估計的寬鬆些
之外,我也會跟組員說沒事別那麼早把任務關閉,這樣你在報表上才有工作的感覺.但既使已經這樣灌水到平均
人員使用工時達到了85%...該主管仍舊不滿意,我百思不得其解到底數據要到多少才符合他心中的期望!
85%..任誰也不相信的數字居然還嫌低...有天我的主管就分我們幾個小組長分享了總公司的人員使用率數據
報表...不誇張,最低的是150%最高的有240%....你信嗎?