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