概述
問題/ issue 是Jira 系統中最基礎的單元，從中文角度出發，事務是比問題更準確的翻譯，對日常理解來說，問題一次更關注的是分析原因，需要有一個回答，而且問題本身與故障/bug有近義詞嫌疑。而事務偏中性，強調的是過程跟踪。由於歷史原因，中文翻譯往往把issue 翻譯為問題。
本文介紹問題類型的設計經驗，操作說明。
問題類型如同款式各異的餐具，裝入不同的食物
名詞解釋
| |
|
|
|
|---|
| 1 |
問題
|
Issue
|
代表對象，包含內部的字段，備註，工作流狀態等一系列信息
|
| 2 |
問題類型
|
Issue Type
|
代表類型，如任務，需求，故障，史詩等
|
| 3 |
問題類型方案
|
Issue Type Schemes
|
一些問題類型組成的方案
|
| 4 |
子任務
|
Sub-tasks
|
標準問題issue 向下一級的子問題/問題sub-tasks
注：子任務默認只有一級
|
操作說明
定義問題類型
擁有Jira admin 的用戶，進入後台【問題】→【問題類型】，對問題類型進行增刪改。
注意問題類型的圖標
定義子任務類型
與問題類型一樣，可以定義多個，圖標和父任務最好視覺上有所關聯。
定義問題類型方案
增刪改查問題類型方案，通過拖拽的方式把問題類型拖進去，如果問題類型太多，滾動查找麻煩，推薦使用鍵盤ctrl+f 快速定位，設定完成後將問題類型綁定到項目
常用問題類型說明（示例）
通用管理型
| |
|
|
|---|
| 1 |
任務
|
一般性事務，如開會，採購商品，無特殊流程，
|
| 2 |
子任務
|
|
人力資源服務
說明：人事，財務，CRM 屬於專業型系統，人少可以用JSM過渡，人多盡量用專業系統，保證各類數據一致性。
| |
|
|
|---|
| 1 |
變更管理
|
如合同，工作崗位變更等
|
| 2 |
僱員入職
|
如題所示
|
| 3 |
僱員離職
|
如題所示
|
| 4 |
向HR提問
|
代替郵件，提出通用性問題
|
研髮型
1-5級屬於參考建議的分層，並非強制；下一級通過hierachy levels 設定，自定義的1-5級界面上通過parent link 字段關聯，系統內置的上下級直接通過界面正常錄入即可；
一般管理瀑布硬件研發項目時，多層級具有實際生產力意義，當涉及戰略分解時，往往匯報作用大於實際。
| |
層級類型
|
層級
|
問題類型
|
說明
|
|---|
| 1 |
自定義
|
1
|
Purpose
|
願景
|
| 2 |
2
|
Vision/Objective
|
使命
|
| 3 |
3
|
Goal/Strategic Initiative
|
目標
|
| 4 |
4
|
Strategy/Workstream
|
策略
|
| 5 |
5
|
Initiative/ Roadmap Project
|
史詩組合
|
| 6 |
系統內置
|
6
|
Epic/Milestone/Risk
|
里程碑/風險
|
| 7 |
7
|
Story/Task
|
故事/任務等標準問題類型
|
| 8 |
8
|
Sub-task
|
子任務，子類型
|
ITSM 型
在ITSM 項目中，除了問題類型，還有把問題類型分組的請求類型，在訪問服務台中區別展示。
在Cloud 版JSM中，事件和變更管理還會涉及到一些外部系統集成，將會在下章JSM 展開介紹
| |
請求類型
|
問題類型
|
|---|
| 1 |
服務
|
獲得IT 幫助
|
| 2 |
修復賬號問題
|
| 3 |
獲得訪客wifi 賬號
|
| 4 |
設定連接到辦公室的VPN
|
| 5 |
申請管理員權限
|
| 6 |
申請新賬號
|
| 7 |
入職新員工
|
| 8 |
申請新的軟件
|
| 9 |
申請新的硬件
|
| 10 |
郵件生成的請求
|
| 11 |
申請新移動設備
|
| 12 |
事件
|
報告系統問題
|
| 13 |
報告破損的硬件
|
| 14 |
問題
|
調查問題
|
| 15 |
變更
|
請求變更
|
| 16 |
事後回顧
|
創建事後回顧
|
客戶服務型
| |
|
|
|---|
| 1 |
授權和賬單
|
買license和賬單金額，週期等問題
|
| 2 |
其他問題
|
問題不能被現有問題類型包含時選擇
|
| 3 |
產品試用
|
提交產品試用申請
|
| 4 |
報告故障
|
使用中遇到的問題
|
| 5 |
新功能建議
|
產品新需求，如期望confluence 可以支持懸浮目錄，以及編輯時內嵌目錄
|
| 6 |
改進建議
|
改進需求，如期望Jira 的中文翻譯可以更貼近中國用戶使用習慣，中文文檔可以更加多
|
| 7 |
技術支持
|
如期望預約工程師遠程或上門服務
|
| 8 |
郵件生成的請求
|
通過郵件收單生成的工單
|
SAFe 規模敏捷型
下圖為Hive 插件推薦的問題類型，注意，千萬不要削足適履全部使用，聽完敏捷培訓，務必根據自己公司實際情況來調整，所有的問題類型都可以增刪改。一般來說，推薦早期從最小的問題類型試跑（如下圖的Essential），大家習慣後再加新的類型。
經驗
不要設置太多問題類型
通常第一次打開未優化過的Jira 後台往往都會看到大量有差異，但又有相關性的問題類型。比如變更，變動，完全相同；
問題類型，屬於頂層設計，如果這塊早期沒規劃好，後期要在保證數據完整性前提下，完全整理很困難。
Jira 不是技術玩具，而是管理工具，完全把定義問題類型的工作交給一個運維工程師是不可能完成的任務，特別是涉及到非研發類項目。往往超多的問題類型並不是一開始就產生的，而是在使用的過程中，不加評估/審批的變更直接應用到系統，導致的後果。
如何解決Jira 問題不方便樹狀展開
問題類型除了做基礎分類，還有層級，Jira 默認是三級Epic→Issue→Sub-Issue，所以Jira 被人詬病數據網狀，過於分散，不適合樹形展開查看。人的習慣往往是總分結構，逐層展開查看。
如想做項目組合，長周期管理，需查看更多層級，建議使用插件，如原生Advanced Roadmaps 或Structure - Project Portfolio Management for Jira
管理VS 技術實現
注意，管理問題，先看本身管理方式是否符合團隊現狀，標準功能有沒有用對，再考慮插件，二次開發，不要遇到問題就想技術解決方案，插件和二開如得病去醫院吃藥輸液，有用，但不能亂用。找根因也得看看是否平時有定時作息，健康飲食。
先吃飽，再吃好，先走路，再跑步，循序漸進，才符合科學。
看到過很多用戶吐槽Atlassian 產品功能弱雞，後端裝一堆插件，往往深入了解後發現，這類用戶往往基礎的項目和問題類型定義就很混亂，管理的水準完全沒有達到需要用插件或二開這一步，沒有搞清楚管理和技術實現的因果關係。
見過很多用戶迷戀華為管理，IBM IPD，SAFe，這些管理方法論歸納總結出來當然有道理，然而這些在基本功沒練好的前提下去談，都是愛慕虛榮，不切實際的邯鄲學步，非但不會給公司帶來提效降本，反而很快會把公司整垮，比如喊學華為的口號的公司，不去做市場戰略分析，不去優化薪酬績效，不改良流程規章制度合理性，光談加班，不給加班費，幹活事情做完了還要求坐在公司裡做樣子，基本6-12個月裡，喊學華為口號的公司，都會得到逆向淘汰的結果，亂加班導致正常員工身體弄壞，有能力不願意無效加班員工離職，喊口號的職業經理人騙完一個公司接著去下個公司行騙。
參考鏈接
