時間就是金錢,有道理,但不完全是真理,準確來說時間約等於金錢,畢竟方向錯誤,亂卷,划水都不會因時間流逝而產生正向價值;
對於管理來說,項目管理大體面向兩類,結果沒問題時,可以暫時忽略過程,當結果出現問題倒退分析過程;當可能存在明顯風險的時候,更加需要對過程進行監控,時間追蹤的無疑是在團隊變大後,當無法通過主觀判斷時,客觀傳遞信息的一個重要指標。
中國的老闆普遍喜歡控制(提升服從性),而不是管理(提升生產力)喜歡聽報告,看考勤,其實非結構化數據的報告很主觀,考勤對只能證明人在,並不知道時間到底花在什麼事情上。
依靠彙報能力對上輸出信息往往導致上層對實際發生的情況出現誤判,比如一家公司裡,如果遇到研發總監巧舌如簧,售後和項目交付累死累活,實際問題是出在產品故障多,不符合客戶需求,但由於最終統計沒有通過數據反饋上去(即問題出現原因,實際消耗時間分類),老闆會得出結論,客戶不滿意是交付側問題,而不是研發側。
面向結果:到期日(due date),解決結果(resolution),發佈(release) 面向結果進行管理,剩餘就是 time tracking
面向過程:時間,人力成本,ROI 分析
問題:團隊的人力分佈在哪些項目,產品,衝刺,版本?
建議:在需要統計的問題上打標記,記工時,後續通過報表工具導出。
問題:自己團隊分別在哪些項目,問題類型上投入精力最多?
建議:在需要統計的項目上,用自定義字段或 Insight對象進行標記,解決結果更新的轉換界面請用戶選擇解決方式或問題出現原因等有助於最終分析的字段。
問題:如何判斷一定數量的問題需要多少人,多久處理完畢
建議:首先人力經驗主觀判斷,其次根據過去故事點/問題數量與花費時間的對比,對未來進行預測,避免出現里程碑交付風險或人力短缺問題(當出現人力短缺就會導致急招人成本陡增,項目交付延期)
中文 |
英文 |
說明 |
---|---|---|
初始估算時間 |
Original Estimate |
第一次錄入的時候預估 |
已用時間 |
Logged |
實際錄入工時的加總 |
剩餘估算時間 |
Remaining Estimate |
後期更新的預估 |
默認狀態下,時間追蹤開關是打開的,Server/Datacenter本地部署版本若要調整參數配置,需要先關閉時間追蹤,調整完畢後再打開,Cloud 雲端版本可以直接修改。一般需要設定的就是 每天工作時長和一週工作幾天。
以下幾個為錄入相關的權限,實際更多權限參考鏈接 (time tracking permission 部分說明)
中文 |
英文 |
說明 |
---|---|---|
解決問題 |
Work on issue |
允許錄入工時 |
編輯所有工作日誌 |
Edit all worklogs |
編輯已存在的工時記錄 |
為其他人錄入 |
Log Work for Others |
Tempo 插件安裝後出現的權限,管理員可以為其他人錄入工時 |
下圖設定會影響到界面的顯示以及報表統計
主觀估算僅適用團隊內部有非常統一的估算標準,互相信任的文化氛圍,否則建議使用客觀估算避免偏差。
類型 |
名字 |
說明 |
---|---|---|
主觀 |
Story Points |
故事點定義取決於團隊成員的理解 |
混合 |
Business Value |
可以定義多少商業價值對應多少錢,但往往一個開發任務很難與商業價值綁定,要綁定也是幾個產品/版本/模塊的項目組合發佈 |
自定義字段 |
|
|
客觀
|
Original Time Estimate |
根據預估和實際發生的時間記錄 |
Issue Count |
根據問題數量 |
可錄入的界面 |
說明 |
---|---|
編輯界面 |
點擊編輯問題,當界面上有時間追蹤字段的時候,即可以編輯初始預估,剩餘預估。 |
查看界面 |
在查看界面右下角的【時間追蹤】,【合作人】點擊➕號 |
記錄工時按鈕 |
填入開始時間,消耗時間,工作描述,剩餘時間可選擇自動計算,也可手工設置 |
工作流轉換 |
類似編輯界面的錄入方式,在彈出窗口錄入工時 |
進入項目中,導出time tracking 報告,查看原始預估和實際預估/時間花銷的偏差。
插件市場排名第一的工時插件,分為工時記錄,人力資源管理,預算(小財務系統)三個模塊;用戶體驗好,功能強大
僅支持雲版本,很適合用於管理工時消耗為主的乙方交付項目,用於追蹤服務合同過程中發生的的人天成本,收益。
個性:技術人員天性自由,不喜歡被管
操作難:入口藏得深,操作麻煩
反覆操作:很多管理團隊不考慮技術人員,讓別人加班之餘還反覆填各種報告和工時
正確方法:減少一切無必要的報告和工時填寫,儘量收集有效數據,通過IM或郵件定時推送填寫通知
Jira 工時每次錄入,保存都會觸發後臺的剩餘工時計算,且沒有關閉開關,設計初衷就是希望每個issue定期關閉,不會保持太長時間。 在 Jira 問題清單中有此記錄,但十幾年過去,依然開著,看起來這問題不太會被處理。如果想要在把單一 issue 變成一個 中長期項目工時記錄,建議定期關閉問題,並重開新 issue,避免卡頓。
需求清單中用戶有提到,但暫未進入開發階段,目前僅支持全局打開或關閉
經典模式,4.2 版本後默認關閉,初始剩餘預估和剩餘預估時間兩個值強關聯,若更新一次只能更新一個值。
不能要求上個廁所也記錄工時,但只要1小時以上,如開會,做公共技術支持,培訓,團建,這些非對外交付,對內研發的工時也需要被記錄,儘管這些不直接產生收益的時間,本身消耗了成本,對企業也有間接收益,如果沒有被統計進去,整體數據就會出現較大程度失真。
Tempo 或其他增強 插件 才有設定,比如中國每年假期不同換休,外國不同國家的假期也不同
Tom Zhu
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
0 comments