如果學過編程,大概知道,其實語法,字段類型並不復雜,難在怎麼把現實中的事情優雅抽象定義+使用恰到好處的命名既讓用戶一目了然,又讓方便後期維護。
字段如寫字,入門容易精通難,學會拼音和比劃一年級就行,但想要寫好字,寫出好文章,是一輩子都學不完,永無巔峰的攀登。
此文拋磚迎玉,掛一漏萬,期望後續與大家交流字段定義的經驗。
自定義字段:創建(字段標題,描述,字典等細節)
字段配置:組成字段配置(配置上下文,必填,翻譯等)
字段配置方案:字段配置和問題類型綁定,並掛載到項目上
字段名 |
類型 |
描述 |
使用須知 |
---|---|---|---|
概要 |
單行文本 |
問題/事務的標題 |
技術上限定可以寫兩百多個字符,但實際使用建議別寫太多,寫太多=沒寫,沒重點 |
描述 |
多行文本 |
對標題的解釋,富文本。 |
|
報告人(reporter) |
用戶選擇器(單人) |
問題提交者 |
|
經辦人(assignee) |
用戶選擇器(單人) |
問題處理人 |
|
關注人(watcher) |
用戶選擇器(多人) |
關注問題的人,默認設定下,此列表中的用戶會在問題更新時收到郵件提醒 |
交互需注意
|
參與人(request participant) |
用戶選擇器(多人) |
功能與關注人類似 |
ITSM 服務台項目中比較常見,功能與關注人類似,加入此字段的用戶,可在服務台查看到相應工單信息及評論。 |
表決(voter) |
用戶選擇器(多人) |
為需求或問題點贊 |
|
附件 |
文件 |
各種格式均支持,如果圖片會顯示縮略圖 |
|
環境 |
多行文本 |
根據情況填寫,綜合信息,比如服務器環境操作系統,CPU、網絡,軟件版本等等 |
如需要下拉選擇的環境,類似生產/預生產/UAT/Staging,需新增自定義字段,建議名稱改為環境類型 |
到期日 |
日期 |
任務到期日 |
默認為非必填,此日期和JQL以及多個內置報表關聯,建議不要額外創建其他日期字段來管理截止日期。 |
優先級 |
單選 |
顧名思義,排優先級。 |
|
標籤 |
自由定義文本(多個) |
為問題打上簡短標籤,用戶後期篩選 |
|
時間跟踪 |
綜合時間類 |
綜合記錄時間:預計時間,已用時間,剩餘時間 |
|
故事點 |
數值 |
用於數字量化評估任務的大小 |
用戶總會有意多估算自己工作,無意中忽略問題/難度; 數字雖客觀,但任務大多數主觀,使用此功能多數情況反而會延長任務交付時間;以下三種按需採納
|
鏈接的問題 |
URL |
存放關聯信息,一個問題可關聯多個 |
|
安全級別 |
單選 |
|
系統僅支持限定到問題/事務級別,如果要限定到字段級別,默認無此功能,也不建議做二次開發。技術上雖可以實現,但從實操上建議把需要隱藏的信息通過問題/事務來做。 |
影響版本 |
版本選擇器(多選) |
選擇受影響的版本 |
只有在項目信息中維護過版本號,才能選到版本信息 |
修復版本 |
版本選擇器(多選) |
發布功能或故障修復的版本 |
同上 |
解決結果 |
單選 |
問題解決的時候手工選擇或由工作流/自動化規則賦值 |
此字段很重要,對於問題解決結果分析,問題解決時間等重要指標都有參考作用。 注意:如果自己增加的工作流環節轉換到最後關閉,記得要在後處理中增加更新解決結果字段,否則會導致問題工作流狀態為關閉,解決結果還是空。 |
字段名 |
類型 |
描述 |
使用須知 |
---|---|---|---|
EPIC Name/Color/Link/Status |
綜合 |
界面上EPIC(史詩)相關的信息 |
|
organization(組織) |
單選 |
客戶相關的組織信息 |
JSM 的服務台使用,純文本字段,如需更進一步客戶組織信息,需要Altas CRM 插件增強 |
flag (標記阻礙) |
是否 |
積壓工作中標記阻礙(顯示為黃色) |
可作為比優先級最高之外更高級的標記,顯性突出展示 |
評級(rank) |
純文本(索引) |
界面上不展示,系統自動生成的索引,用於排序 |
無需關注,此字段無法編輯 |
滿意度 |
數值 |
工單完成後推送給客戶填寫的滿意度調查評級 |
建議別放到界面上讓agent 客服維護,一方面不符合流程,另一方面會引發一些未知錯誤(現有一些bug尚未修復,如界面滿意度展示消失) |
parent link(父鏈接) |
內部問題鏈接 |
單獨應用於Advancedroadmap 的父鏈接,專門應用於自定義的問題層級,不僅限定於問題和子問題。 |
注意,此鏈接不同於常規問題鏈接,epic link,父子問題類型,可應用於各類問題類型,常用於長周期瀑布項目的多層級優化展示。 |
評論 |
多行文本 |
問題下方的評論信息流,可區分外部評論和內部評估(僅特定項目角色可見) |
有時系統會不明原因把渲染器從維基渲染器改為純文本,會導致富文本丟失 |
審批人(approvers) |
用戶選擇器(多人) |
JSM 特有字段,用於定義審批人 |
不要過度依賴JSM 的審批,Jira 不強調組織樹,有意打破部門牆,僅支持簡單規則或自主選擇下一環節審批人。 |
第一響應時間 |
數值 |
系統自動計算的首次響應 |
被應用於報表,評價客服響應速度,如果系統自動規則自動回复,不應被判定為首次響應,應當排除機器人的自動回复避免統計失效。 |
類型 |
描述 |
---|---|
標籤 |
|
單選 |
|
複選 |
|
日期+時間/日期選擇器 |
|
數值域 |
|
文本框(單行/多行) |
填文本 |
選擇列表(多行) |
類似單選的多選版本,區別在於一次可選多個 |
選擇列表(級聯) |
聯動菜單,如一級A 對應二級1,2, 一級B對應二級3,4 系統內置字段僅支持2級聯動 |
選擇用戶(單選/多選) |
盡量在系統用戶字段不能滿足需要的時候才添加。 |
URL |
外部鏈接 |
版本選擇(單選/多選) |
盡量在系統用戶字段不能滿足需要的時候才添加。 |
只讀文本 |
內嵌式公告 |
組選擇器(單選/多選) |
這個組指的全局用戶組,用的很少,因為用戶組大都和功能權限綁定,問題/事務中的屬性主要和項目角色和用戶綁定 |
系統卡頓多數因為全局上下文的自定義字段太多,此功能在Datacenter版本中用於幫助用戶識別,哪些字段可能需要被優化,具體優化方式還是需要用戶自己來判斷,一刀切不可取。
確定不用的:先取消與所有項目關聯,過段時間沒人跳出來說有問題再刪除
不需要全局上下文的:把字段關聯制定項目
如果問程序猿最討厭的事情,除了和產品經理/客戶開會,客戶撕扯莫名其妙的需求,修復不可複現的故障,還有估計就是命名,甚至於還有屬於相關詞,幫助給變量命名的網站,儀式感不亞於給娃生辰八字起名。
不要重複造輪子
如果沒有經驗豐富的管理員維護系統,或企業內部有多個管理員且沒有合適的變更流程,打開後台看,大概率會看到一堆長得相似,但綁定了不同項目的字段,比如解決結果,解決方式,關閉類型。
重複的字段意味著統計不准確,理解難度陡增。這塊需要經驗豐富的管理員+變更流程一起發揮作用,才能解決此問題,如後台已有冗餘字段,修復的時候務必小心,做好數據備份,轉移,不要因為因為合併字段導致流程中斷,盡量在測試環境試一下再去生產做變更。
減少黑話
隨著互聯網應用發展進入尾聲,群雄爭霸結束,原來濃眉大眼的互聯網公司也變身油膩中年大叔。
內部發展空間變小,對外資本故事難講,各種不說人話,越來越像官僚國企,政府。甚至於網上專門出現了互聯網黑話生成器。
人與人的交流,本來因為背景習慣差異,就有信息磨損,系統流程的初衷就是降低磨損,而黑話是企業高層對外塑造科幻泡沫形象,員工內部在內捲工作中美化自己績效的一種生存技巧。
理想狀態下對外創造價值,對內數據驅動,簡化溝通。知易行難,需要企業管理者有大刀闊斧的決心。
系統原生無法實現,可以通過外部插件以及二次來做增強,需評估增強的必要性以及相關的成本(插件授權,開發,維護),一切皆可做,但並不代表做啥都有正向收益。
名稱 |
類型 |
功能 |
---|---|---|
配置類 |
|
|
配置類 |
|
|
配置類 |
項目附屬信息字段增強 |
|
配置類 |
通過界面配置/groovy 實現可計算的字段 |
|
配置類 |
檢查清單增強,比子任務的操作簡單 |
|
配置類 |
|
|
開發類 |
|
|
開發類 |
|
Tom Zhu
Consultant
Shanghai Jingxianginfo Co., Ltd
Shanghai
7 accepted answers
0 comments