開單系統規劃 Proper Plan for the issue tracker

 This is the discussion and my experience in setting jira


  1. 公司應該有自己的jira server和設定,並能夠定期備份。
  2. Jira server應開啟@ mention人物的通知信設定
  3. Assignee的通知應及時。
  4. Developers欄位類似email CC或論文的共同作者,因為該任務涉及多人或相關人士,應設定一併及時通知。
  5. 自動通知信理想狀態下為1~3小時內收到,最晚不可超過10小時(目前為10小時,不甚理想)
  6. 通知信之目的在於公開狀態下可使公司同仁皆能看到專案進度和共用開發資源,同時可來回拋接完成之任務給下一階段團隊。
即時通訊軟體
  1. 若無法禁止及時通訊IM的使用,則需以開單系統上資訊為準和最優先更新
  2. 若無法參加該工作群組的IM group,則可拒絕撰寫文件
  3. 若無正式開專案於jira,未事先確認專案成員和可動用資源,則不得私拉私創群組,或強制拉任何人入群。
  4. 若無先正式開單或分析,則不得實作或修復bug
  5. 除P1等級,不可於未開單的情況下事先上hot fix或逕自關閉遠端伺服器或調整部屬之容器規格(此為舉例)
  6. 不得於IM中交辦事項。(否則開單系統等於廢棄,且無法於IM內追蹤長達半年的專案內容進度或多群尋找特定資訊)
  7. 不得以創立私群方式交辦正式工作與文件,因公司將無法彙整資料於同一系統上或確保其正確性、即時性
  8. 訊息正確性以jira單上狀態
  9. 口頭會議必須要有開單紀錄結論。不可只有開會參與者和時間。
  10. 工作交辦以"非同步"為主。意思是請盡量使用開單系統,對於IM或線上會議這種需要多方同時在場,時間成本較大,卻又難以用證據澄清或精研問題所在的溝通方式,請勿拿來做為分析任務或trouble shooting的依據。
同上,此種溝通過程易流於參加者認知不同,散會後沒有人負責該做且問題核心之任務。故會議必定要有會議決議與時間。否則便成為浪費時間和人力資源的嚴重管理問題。

口頭與當面討論之紀錄
  1. 不得於口頭交辦專案任務,此為避免無謂人力資源浪費和無法追蹤責任者
  2. 開單系統應視為最高優先度之任務堆疊
  3. 不得將已完成之文件和任務,與未完成之任務和功能混於一文件中。需求和未來規劃必須於開單系統中登錄,而非混入簡報或IM、知識庫文件、個人權限之網路文件(office 365, google doc, notion等)。造成資訊斷裂和混亂。
  4. 不得使用無法透過搜尋、時段選擇或版控紀錄維持文件內容的系統,做資訊儲存。
  5. 因開單系統不支援OCR,不可使用截圖直接取代報告打字內容。

工時登錄與績效評估

  1. 每張task單,其工時不該超過20小時。若超過20小時則應另拆分作為新單。
  2. 員工之工作能力和品質評量,應視其性質和產出作紀錄評估,而非單純以主管回憶之評量或匿名互評問卷,以保持公正正確有效。

團隊性質

各公司或團隊視經營性質,有可能以維運監控流量作重心,也可能以微服務開發或客服支援等作為重心。各團隊有不同的知識庫和文件交接性質,撰寫者以己身所屬團體立場和使用方式出發,難免有偏缺。鼓勵各團隊以小段文件方式從己身團隊紀錄,最後文件則重新由營運之商業角度,或應利於公司營運之高度補足,重新整合。

為此,規劃公司的文件流程和資訊紀錄方式。以及因應之硬體、軟體與人員資源、訓練手冊內容、相應之委外資源或社內支援管道、橫向聯繫管道帳戶

前言
 
由於BnosK的特殊形式,可以視為與其客戶公司緊密結合的一個專門部門。多數公司有自己的MIS或IT維運,也有產品或工程開發部門、專利委外或內部的研究團隊。但很少有配置資訊管理、流向控制規範的部門,以及撰寫Knowledge base的維護和專門研究相關軟體和撰寫技術的討論群組。
 
 

留言