記Codes 研發管理平臺——日報與工時融合集中式填報的創新實現
市面上的研發管理軟件雖具備工時管理功能,卻往往忽略了日報的重要性,導致基層工作人員面臨諸多不便。如何解決用戶痛點,推動項目管理向更高效、精準的方向發展呢?本文將揭示如何在工時管理中融入日報的創新性解決方案,推薦閱讀。
市面上所有的研發管理軟件,大多都有工時相關功能,但是卻沒有日報功能,好像也沒什么問題,但是在使用過程中體驗非常不好,為什么呢?
項目管理對于基層工作人員來說,主要解決這三個問題:開展我的工作、協作我們的工作和匯報我的工作,也就是說日常的匯報也是剛需。平臺沒有日報就會有下面的問題。
第一、如果離開平臺,那么日報上羅列的事項和實際工作安排就沒有緊密關聯,“混子”對日報就有“操作空間”;管的人越多,越難記住每個人的具體工作。如果混子瞎編日報,也難以察覺,一看滿滿當當,以為產出還不錯,干的事項不少嘛。日報是項目管理中的剛需呀,難以理解為什么市面上的研發管理平臺都沒有這功能。
第二、本來能不開會就別開會,很多時候是通過早會來確認工作進展,但這要花更多的時間,為什么要開早會就是因為日報上的內容和工作安排沒有緊密關聯或是根本沒日報,只能當面說一說情況,有大家在場,混子沒法再瞎編了。有了和工作安排完全關聯的日報,這就可以不開沒必要的早會了,有問題點對點找人就行了??刹豢梢杂迷鐣蚴峭頃泶嫒請竽?,這使不得呀,后續沒法數字化,也不方便以后復盤及追溯??偨Y起來就是,和工作安排緊密關聯的日報可以減少不必要的日例會。
第三、本來填寫工時就是有點“反人類”的工作,再加上每個工作事項的工時,要一項一項的填,非常繁瑣;有時候還要一項一項的找,讓人煩躁得很。
第四、對PM也非常不友好,他要把大家提交上來的日報數據,再去匯總為項目日報等,如果再按時段統計大家的產出,這工作量就要命了。
歸納起來,項目管理中日報是少不了的,工時也要,且還想讓工時填報不煩人。既要又要,有招么?
招數就是:采用日報與工時融合集中式填報的創新實現。寫日報時集中式填報工時,一舉兩得,既能解決日報事項和工作安排關聯的問題,又能讓工時填報省時省力,最終可壓縮混子的摸魚空間,沒法瞎編日報了,工時也不能渾水摸魚了。
Codes 產品團隊始終以用戶為中心,從用戶的使用場景來思考問題,而不是做什么都先去JIRA等同類工具找參考“依據”(這是“小屁孩”的玩法),這樣是永遠沒法創新的,始終會被所參考的“依據”僵化思維。解決用戶痛點,如何讓用戶爽,就如何實現,這也是我們創新的源動力,換句話說就是,不固守陳規,擁抱零基思維。
一、招數有了,有些需求細節要補充一下
填寫日報時,要自動列出當日事項;工時主要用來計算進度和產出,那除了當日進行中的事項要填日報和工時以外,名下待處理事項且沒有預估工作量的也需估一個時間,如BUG修改,用例執行和開會等,作為其他事項填報進來。
通過日報中今日事項、待處理事項以及其他事項,計算進度時工時的范圍就比較全了;
不只是任務,日報中還要有明日計劃,同時日報還能發到第三方平臺,如郵件、企微、釘釘和飛書等。為了便于統計產出,既要有原始的明細數據又要有匯總類的數據,他們可以相互佐證,且可導出。
二、功能實現之日報填報及集中式工時填寫
日報由今日事項、待處理事項、其他事項、以及明日計劃組成。日報提交后可以按配置發往第三方平臺。
1. 日報今日事項
今日事項,顧名思義就是當日處理過或辦理過的事項或當日計劃的事項。
日報填寫:
- 自動列出當日處理過的事項
- 前一天提交日報時,明日計劃中的事項
- 當天在我的事項中設置為今日事項中的事項
- 如都沒有,那只能通過右上的“補選當日事項”,來手動選擇今日事項。
然后如下圖所示,填寫工作說明,及工時信息;如有風險還可關聯引起風險的事項,可以是潛在風險也可以是已發生的風險,工作臺上的風險拓撲圖就來自于這里的數據。
如在日報中填寫了明日計劃,在第二天,我的事項以及全局事項的列表中能看到今日計劃這一列為選中狀態,且在我的事項和全局事項的今日事項列的TAB中也集中顯示出來,方便查閱所有人當日的工作安排。
2. 日報待處理事項
待處理事項,主要是缺陷及沒有預估工作量的子需求(有些需求很簡單,不用拆分為任務,直接把需求當任務的需求)以及用例,只是對于用例不需要填寫預估剩余工時,通過用例執行成本自動計算,在日報中列出來是為了方便查看工時組成成分。
待處理事項的預估剩余工時填了之后,整體的進度才能算得準確,要不然只能開會時PM一個個問還要多久完成。
3. 日報其他事項
其他事項,指臨時開會或不在計劃內或是突發性的工作等。在日報中記錄下來,包括工時信息。
管理本身也有成本,如開會等,或是計劃外的其他事情,只要花了工時都記錄起來,讓一切成本都有據可查。
4. 日報發往第三方平臺
5. 日報中從我的事項下勾選了明日計劃后,次日在我的事項下相應TAB中今日事項顯示為“是”,也可在我的事項下今日事項中查看我的今日事項。如前一天忘了寫明日計劃,也可當天早上在我的事項下相應TAB中主動勾選今日事項。
6. 管理員可以從全局事項下,查看當日所有人的今日事項,如有優先級高的事項或快到期的事項沒排在今日事項中可以及時進行干預。全局事項下,其他列表中,如作為當日事項會顯示為今日事項為“是”。
可查詢今日到期以及本周到期的事項,然后查看是否作為今日事項以便進行干預,還可進行多種分組顯示,如按人員、按項目、按迭代、按狀態等。
三、功能實現之日報審批:按產出算工時,不是按打卡時間算工時。
Codes不提倡無意義的卷加班,為了加班而加班對公司和員工是雙輸,是管理無能的體現,管理層看不到數據,只能通過加班來緩解他的焦慮;
所以Codes的工時中增加工時審批這一流程,寫日報時員工可以填一個工時,但是PM或是部門負責人可以按產出來修改員工日報中的工時,這就是工時審批的目的,如果某個任務張三填了8小時的工時,但是審批時被認定為產出只有6小時,就可更改為6小時。
當然也可以關掉審批流程,缺省是打開的,且審批人可以設置為項目PM或部門負責人。
對于填報人來說,一天只填一份日報,但是可能是跨多個項目,如設置為PM審批工時,那審批時不同的項目是不同的PM來審批。
點擊狀態可查看審批情況,如需要多個PM審批,只要有一位PM還沒審批,就是審批中狀態。
在日報列表(填報列表中),或是審批詳情中,都可點擊詳情查看日報明細,以查看提交的原始日報內容。
四、功能實現之人員產出及工時統計
可按部門、按項目、按迭代、按人員匯總 ,還可層層下鉆到人,比如從項目可下鉆到迭代,從迭代可以下鉆到人。
五、功能實現之日報查看
分為項目日報和個人日報
先是按項目按天匯總,然后詳情中按人分組
1. 項目日報明細,按人分組
2. 個人日報
六、功能實現之工時明細及進度
既有原始的明細數據又有匯總類的數據,從項目到階段、到迭代、到部門、到人都有。
七、功能實現之工時趨勢
標準的燃盡圖中是兩條線 :一條是理想線,一條是實際線。但現實中,經常計劃制訂后,時不時會加“東西”進來,那燃盡圖的標準線就不一定準(且Codes中測試也納入到迭代中,缺陷的工時沒法提前預估),不如我們三條線:預估、實際和剩余(剩余用來反映進度),當然這是仁者見仁,智者見智。
有項目的工時趨勢,有階段的工時趨勢,還有迭代的工時趨勢,后續還支持個人的工時趨勢。
八、功能實現之工作產出匯總
KPI只有在產出精準的基礎上才能更好評判,產出也是KPI的大頭。Codes 按項目按人分組、實現的需求、完成的任務、解決的缺陷、編寫的用例、執行的用例(按執行成本算,不是按用例個數),其他事項以及上述各組數據對應的工時,一網打盡。如下圖所示,當然也可導出為excel。
九、功能實現之風險拓撲圖
根據日報中的風險,以拓撲圖直觀的方式顯示風險。
十、總結
上述的實現沒有技術門檻,抄也沒地方抄,只有想沒想到用戶的痛點,這是考驗產品經理的認知,也就是產品力。創新不是為了玩新奇,是為了解決問題。下一次我們來聊聊Codes獨有的流程驅動的缺陷管理,也是很酷的功能,欲知后事如何且看下回分解。
本文由 @兔仔7904 原創發布于人人都是產品經理。未經作者許可,禁止轉載
題圖來自 Pixabay,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務
- 目前還沒評論,等你發揮!