太上,不知有之;其次,親而譽之;其次,畏之;其次,侮之。信不足焉,有不信焉。悠兮,其貴言。功成事遂,百姓皆謂「我天然」。 --《道德經》前端
研發管理或者系統工具的指導思想我以爲就是依照上面這句話作到「不知有之」和「我天然」。若是管理方法是合理和高效的,它必定是符合(或者可以引導符合)大多數人的使用習慣,若是不止一我的提出以爲流程複雜或者難以理解,或者實際實施的過程當中時常會出現錯誤,那咱們應該從管理上找緣由,是否是不夠天然,彆扭。由於在實際工做中不少人沒有特別執拗的管理方法或者系統工具的要求,就像不一樣公司的企業文化,你們容易偏於適應,因此當有人提出問題,管理團隊的問題可能性更大。可是人是有惰性的,管理需求的複雜與人員使用的簡單之間,如何很好的去作平衡,個人思路是「大部分人作簡單的事情,小部分人作複雜的事情」。數據庫
Jira系統,或者說研發管理系統的服務對象有兩個:後端
迭代(一個標準的Scrum迭代)
運維
團隊(全角色研發團隊)
工具
迭代
迭代是在一個時間範圍內組織全部角色配合最終產出交付物的活動過程。角色不僅僅是內部的產品研發測試運維,還包括技術支持、客戶服務、銷售等等。迭代難點在於規劃和過程管控,因此核心指導思想我認爲是:規範、可控。我給出了實際生產使用的迭代節點說明:測試
有以下幾個場景:編碼
- 敏捷看板(待辦事項/進行中的sprint)
涉及需求邊界確認的均可能有影響,團隊內部使用敏捷看板來提交待辦需求,劃定最終需求邊界。
- 篩選器(filter)問題清單
經常使用於總體需求確認的時候編輯需求屬性,分配到對應研發人員。
也能夠整理出最終的發佈的需求清單用於製做改版說明和明確升級內容。
篩選器的問題清單頁面有列表和詳情兩種模式,還能夠自定義展現字段。
- 甘特圖(插件/二次開發)
針對全部人員的子任務的甘特圖,用於確認排期,過程跟進等。
團隊
Jira的核心指導思想須要覆蓋到全部目標人羣,對人羣的工做內容可以起到完善輔助、提升效率、全面覆蓋的做用。
一個團隊中主要包含三類常規角色:基層員工、中層管理、決策高層和外部單位。一類很是規角色:研發管理。插件
研發管理
研發管理通常來講是整個研發中心的規範制度建設和推進者,有些公司是有研發高層直接推進,有些公司會獨立出單獨部門來進行管理,根據不一樣公司的不一樣業務形態和團隊構成而定。可是這個部門的職責會制定研發規範,推進系統使用和規範檢查,還有績效考覈等管理工做。
本文中以單獨部門的形態給你們介紹,這樣區分會更加清晰。因爲研發管理是規則的制定者,是最合適的管理者,可以達到知行合一。因此複雜的事情會堆積到這裏來。有以下幾個場景:設計
- 規範管理(儀表盤)
經過儀表盤篩選出違反規範的信息,整理彙總報告給管理跟進。
- 工時管理(插件/第三方BI)
研發管理規範要求天天的工時完整上報,因此須要跟進填報狀況,記錄異常。
- 績效考覈(篩選器+導出excel+第三方BI)
績效要可以作到儘可能量化,有數有據可查。因爲Jira自己沒法進行績效的複雜規則制定和計算,因此須要導出excel來處理,後期規則固定則能夠直接接入rest接口或者數據庫鏈接進行計算。
- 系統改進
工做流、字段配置、腳本編寫等等,若是你有編碼的能力是一個極大的優點。
基層員工
不管是剛剛入職的新員工,仍是創始團隊的老員工,基層員工每每是被動的,須要安排工做。不一樣人員素質/經歷不一樣,複雜的研發內部流程可能也會影響效率。對於基層員工而已,咱們的核心指導思想就是:簡單、直接。
有以下幾個場景:rest
- 工做入口(儀表盤)
員工的工做場景,天天打開Jira,能夠在一個頁面上就獲取我今天的全部工做,包括:按照時間/重要程序排序的待辦工做,按照時間/重要程序排序的缺陷修復,管理規範異常任務(好比任務排期已經在今日以前還未完成),通知/公告類信息(如迭代排期、重要插入任務、修正發佈任務清單等等)。員工培訓很簡單,在這個入口頁面,你能夠按照研發預約的規則來完成任務,修復缺陷,瞭解重要通知信息。
- 任務/缺陷工做流
我多是一個產品/UI/後端/前端/測試,一個Story須要多個角色協做。如今有兩種實現方式:
第一種: 主任務在不一樣角色之間流轉,每一個角色維護好主任務在自身當前環節的狀態,而且在工做完成後流轉至下一環節。
第二種:不一樣角色在主任務下創建子任務,每一個角色維護好自身子任務狀態,父任務工做流經過外部環節觸發流轉(自動/手動)。
第一種須要每一個角色瞭解父任務的複雜流程,而且維護和觸發流轉工做流。第二種子任務工做流僅包含「待辦-進行-結束」三種,任務能夠並行無需關心先後流程。後一種與前一種相比對於員工的要求更低,出錯的概率也更小,可是對於系統有更高的要求(自動流轉),外部管理協調的要求也提升了。可是員工的工做流達到最簡單。
- 工做彙報
不少公司均可能有日報、週報、月報等彙報類型,多是郵件、excel等形式。缺點難以積累用於統計分析和改進,更貼近形式要求。彙報的部分能夠考慮使用任務工時代替,將單日花費工時記錄在任務上,可以在完成自身任務時候直接填報,天然的就完成了日報的工時填報,累計而成周報,月報。數據還能用於我的分析。
中層管理
中層管理通常身上會負擔必定程度的技術工做/技術指導,同時也會負責小團隊的管理跟進。技術的部分能夠參考基層員工,針對他們的管理職能,咱們但願可以給定一個規範成熟的管理模型引導他們直接套用,下降門檻和工做量,可是還可以達到比較好的最終管理效果。因此核心指導思想是:簡單管理。
有以下幾個場景:
- 評估/排期管理(儀表盤)
研發人員對任務的評估和排期的變動可能會形成整個排期波動,一些重要交付項最終延期而過程當中沒法瞭解到。因此咱們將任務的評估和排期修改權限提到了管理層,研發管理部會每日去跟進全部研發人員的任務狀態是否正確維護,而且通知主管跟進具體的任務異常。主管根據具體人員的實際狀況來調整任務或者上報風險。
主管也能夠(非必須)經過儀表盤瞭解本部門下屬人員的異常狀態。
- 折算工時(篩選器)
因爲不一樣人員級別不一樣,因此完成一樣任務花費時間不一樣,咱們須要確認以同一標準評估全部人的任務工時,從而計算出一個折算工時來進行橫向對比。
研發管理部生成好篩選器,提交給各個主管,評估一段時間內的部門人員的折算工時,最終用於生成績效考覈數據。
決策高層/外部單位
一方面,高層和外部單位其實都是在研發迭代循環的體系以外的,另外一方面,外部單位和研發的多是配合支持,高層則是更關心產出、團隊狀況和發展方向。
因此針對決策高層/外部單位,我思考的核心指導思想是:信息隔離,可視全面
- 信息隔離(項目分隔)
不一樣中心事務處理的流程不一樣,權限也有差別,因此最好將不一樣的流程體系拆分到不一樣項目進行隔離,若是有聯動的狀態要求,可使用關聯進行操做,自動觸發流程流轉。
- 彙報面板(第三方BI)
管理層在乎的是總體層面的產出和損耗,要可以儘快的發現問題並修正,可視化是很好方式。惋惜在Jira上並無找到很好的可視化BI報表,因此這塊須要依賴第三方數據報表。
總結
對第一節的內容進行一個總結,指導思想中最核心的其實就是兩個字「簡單」,可是這個簡單是須要以研發管理人員的「複雜」爲代價的。管理者不管在設計規範、流程或者制度時,都要考慮操做方的代價,要以少許人員的複雜換取大多數人的簡單,並且要在可以知足管理需求的基礎之上。
從Jira的模塊來看,最重要的幾個功能模塊包括:儀表盤、篩選器(JQL語法)、自動化工做流,分別對應統一入口、多維度清單、簡單操做推進複雜主流程。