這篇整理去年公車上寫的三段 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，就是另一種垃圾。
• 不要相信人類的記憶力，不管你有多聰明

相關文章：

• 需求管理 (Requirement Management)
• Software Development Lifecycle
• Issue Tracking in Redmine
• 分類的哲學

議題管理的層次

這段想法^{(原文, 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)，然後，就沒有然後了。
• 組織化與結構化需要透過：制度規範、教育訓練。
• 所以買系統，只是有功能，功能要用對，要靠制度規範。

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

• 一個人的 Working Backwards
• 閱讀能力的重要性
• 為什麼寫文件？
• 再談『為什麼寫文件？』
• 分類的哲學
• Spotlight 現象
• 文件的持續交付

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

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

一個任務溝通的維度：

• 人 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 …

資訊管理

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

延伸閱讀

站內延伸

• 協同合作系統建制與導入 - 以 Redmine 為例
• Software Development Lifecycle
• Issue Tracking in Redmine
• 需求管理 (Requirement Management)
• 分類的哲學
• 為什麼寫文件？

更新紀錄

• 2019/09/10: 加入兩篇隨筆的整理 談議題管理層次, 複雜的資訊流，造成的資訊落差