Issue Tracking 在企業裡的價值 - KM


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

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

基本的概念源自底下這張圖:


Issue Tracking 與知識管理

工作上很常發生的場景:

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

以前我這樣做:

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

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

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

結論

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

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

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

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


延伸閱讀

站內延伸


Comments