Issue Tracking 在企業裡的價值 - KM


這篇整理去年公車上寫的三段 memo:

  1. 2018/10/16: 談 Issue Tracking 在組織裡的價值 - 知識管理
  2. 2018/12/05: 談議題管理層次
  3. 2018/11/28: 複雜的資訊流,造成的資訊落差

基本的概念如下圖:


Issue Tracking 在組織裡的價值 - 知識管理

這段原文是去年寫的 memo (2018/10/16),主要是討論 Issue Tracking 在企業裡的價值,我的結論:

隨著時間的前進與企業的發展,他 應該 是內部的 知識管理庫 (KM)

工作上很常發生的場景:

因為一些因素,突然要三個月前、一年前、兩年前某個事件、任務、專案、功能的結果、結論、故事。有八九成的機會,會因為 Email、Slack、這種垃圾工具,把整個問題越打越亂,因為:Email、Slack 是用來傳遞資訊,不是用來組織資訊、達成共識的。

以前我這樣做:

  • 討論過程放在 Issue Tracking (Redmine)
  • 達成共識 應該在 會議室(面對面)
  • 結論放在 Wiki

其實平常養成習慣,隨手紀錄五個 W,事後都可以很容易了解當時的為什麼,以及現在的為什麼。新人來自己去看就可以知道前因後果。

  • 文件的重要性,路遙知馬力。
  • Issue Tracking 如果無法變成內部的 KM,就是另一種垃圾。
  • 不要相信人類的記憶力,不管你有多聰明

相關文章:


議題管理的層次

這段想法(原文, 2018/12/05) 主要說的是企業內部的決策數據依據,想法一直在心裡演練過很多次了,主要描述的是軟體開發議題 (Issue Tracking) 管理的層次:

  • L0 口頭:問題沒有回報流程、標準化、輕重緩急,不知道 Priority & Severity、Email 滿天飛,文件到處亂丟。
  • L1 有記錄:用類似 excel / word 工具整理發現的問題,沒協作流程、議題沒有 生命週期規範
  • L2 有協作:系統化紀錄,用類似 Redmine、Jira 協做, 但沒有標準化流程/回報標準格式,開始有 Priority 概念,但沒有 Severity 概念。
  • L3 用流程效率化作業:有標準化流程、生命週期、回報格式、關連議題、有 Severity 概念, 知道如何判斷 Priority / Severity 的差異
  • L4 知識庫:生命週期有管理,歷史資料成為有參考價質的知識庫。能控 S & P
  • L5 守護與探索標準化:過去 Severity 1 的 bug 被寫成自動化測試,每次 release 前,在 regression 都能反複確認。有自動化測試開發程序。有專門團隊制定產品標準化流程,並切透過系統化實踐到現場。
  • L6 認證:L5 守護整個產品的可靠性,提升產品價值,形成認證標準,輸出最佳實踐,形成體制化,輸出給其他團隊,創造價值。
  • L7 獨立成為營收單位:可以對外輸出價值,產品化。

誤區一:以為導入 XXX Issue Tracking 就如何

很強的工具(如 VSTS, Jira, Redmine),但是流程與標準化沒做。工具很強,團隊不學習,舊思維配上新工具,跟不上。

誤區二:以為有很強的 IM (eg. Slack) 就不需要 Issue Tracking

IM 是用來快速溝通用的,跟 Email 的差異就是縮減時間差、介面不一樣,本質上跟 Email 是一樣的。

但是追蹤事情跟做資料分析一樣,同樣有蒐集(輸入)、分析,呈現、決策。大數據要做的是,在 Issue Tracking 是同樣要做的,他是企業決策的依據,我稱為 決策小數據

誤區三:買了 OOXX 文件系統,文件就高枕無憂

  • 文件是給人讀的,文件的價值在於組織化與結構化之後的樣貌,也就是下圖的 (3)。
  • 很多人共同修改文件,在沒有制度規範的前提:只會一團亂,也就是停留在下圖 (2),然後,就沒有然後了。
  • 組織化與結構化需要透過:制度規範、教育訓練。
  • 所以買系統,只是有功能,功能要用對,要靠制度規範。

講了那麼多,其實也要訓練員工閱讀與寫作能力,相關請參閱 學習、寫作、閱讀系列文章


複雜的資訊流,造成的資訊落差

組織訊息的流通與管理,是減少溝通成本之必要。以下用代數的方式描述溝通複雜度的問題。

一個任務溝通的維度:

  • 人 p:團隊成員、管理人員、協作角色
  • 事 o:任務、break down tasks
  • 資訊流 s:資訊傳播媒介,站立、會議、email、slack, tracking system …

資訊傳遞方向:

  • p -> o
  • o -> p

傳遞載體:

  • p - s - o
  • o - s - p

傳遞的時間複雜度 c:

C = p * s * o

O 需求會快速增加,不易控
P 增加很慢(聘人不易),不可控
S 可控,但要「意會」到要控

人會跟人溝通:p^2
事跟事有關聯:o^2

所以共識 c = (pxp) x o

很複雜吧,所以溝通成本,隨著人事的變動、變大,會越來越複雜。


結論

不管是使用 Redmine、Jira、VSTS (Azure DevOps),只要沒有辦法形成有用的知識體系循環,那工具就只是工具。實際上,大部分企業只能把它當作過水的工具,也就是追進度,然後裡面的功能都不會用。

大部分的企業是跟不上工具的進步,反而要客製化工具來配合企業既有的流程。

這狀況,就跟大部分的人其實是不懂軟體的,卻都要軟體越來越強大配合人類。所以實際的狀況,大部分的 Issue Tracking 在企業裡一點用都沒有,他唯一的功能只是想取代單機的 Microsoft Project 或者甘特圖,裡面實際上一點知識價值都沒有。

實際上這些工具本身就包含了很多 Know How 以及 Practice,換言之,企業必須拋棄既有看似可行的方法,調整步伐,了解工具為何如此設計,以及如何改變自己,跟上這些工具。隨著時間前進,幾乎任何問題、過去發生的問題、為什麼要這要解、為什麼不用 OXOX、問題與需求的關聯性 …. 都可以在裡面找到,就像現在的 StackOverflow …

資訊管理

  • 『掌握資訊』是一種能力、技術
  • 而『資訊傳遞的管道』其實就是一種武器
  • 『資訊落差』製造對立與衝突

延伸閱讀

站內延伸

更新紀錄



Comments

2019/01/21 23:30:00





  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
  • ▲ TOP ▲