「知識管理」不是業績，而是根基。

這兩天有其他部門的朋友，寫信告訴我，有鑒於公司內的技術交流實在很少，他開了一個討論區，希望我用一下功能有沒有什麼問題，若沒有問題他就想公告給大家知道，希望大家把這討論區當作是公司專屬的Stack Overflow。

我回了一些這幾年我在部門內推行知識管理的經驗及感想給他，技術上並沒有什麼難度，有問題都能處理，就是要大家去寫，去整理，去輸出，實在是一件難如登天的事。早上在上班的路上，這件事就帶起了我許多回憶。

到底是「結案報告」還是「吃案報告」？

結果從以前做專案到我最後離開專案團隊，每當我有不少know-how想寫進結案報告時，我就會”接收”到專案負責人不安的情緒。他們都知道這是體制內的規範，也沒有人會去質疑這個要求，但大家就是不想要花時間在這件事上面。我收到的永遠是「在下週前結束」，「簡單寫寫就好」，「重點寫到就好」這樣的指示。就像以前還有聯考時的課程安排，絕對是把體育，音樂或是美勞課拿去補英文數學一樣，大家都知道這是不對的，但大家都會這麼做，也都知道理由是什麼：

沒．有．業．績。

產品是怎麼一路凋零的

之前看過一篇文章，可惜沒留下來。有人問技術牛人，我們大家把技術磨尖，把架構做好，既不保證產品賺錢，也不保證品質穩定，我們為什麼要做得這麼悲催呢？

牛人說了：「決勝點就在產品的生命」。

一個鮮明的例子是這樣的，我們用前人的模版，修修補補湊了一款遊戲出來，許多魔術數字，複製貼上的源碼，和命名不符的函式實作，雜交派對般的類別繼承…各種腥味(不只是異味了…)充斥在源碼之中。遊戲中的文字為求美觀快速，大多數都是直接貼圖，什麼多國語系？完全沒在考量範圍內。播放音效的方式，當然就是在源碼內直接播放，兵來將擋，水來土淹式的硬刻，聲音有出來就行了，偶爾漏個一、兩聲沒有關係。

一整個就是…金玉其外，敗code其中啊。

問題多的不得了…

這個遊戲上線之後營收很好，你很高興，興致勃勃的開始計劃接下來的版本及活動，惡夢就這麼開始了。

看著別人出了英文版，打向國際市場了，你也想做。但你的團隊告訴你，我們得有一堆字圖要換，不是找人翻譯完，打字打一打就行了，美術要出許多圖來換成英文版，別人再出了泰文版，上述的事情就是再複製貼上出現一次。

接下來人家辦了一個「打倒忍者龜，贈送大禮包」的活動，你也想做。但你的團隊告訴你，我們只有傑尼龜，它會很多技能，但要改成忍者龜的話，我們得把傑尼龜大缷八塊，把身體跟技能拆乾淨，才能再搞出一隻忍者龜。

接下來人家送法規市場了，這可是大單生意啊，你當然要做。你的團隊看了看規格後，臉色跟鐵達尼撞上的冰山一樣冷，告訴你遊戲現在還有一些奇特的bug還沒解，實作者覺得「世界這麼大，她想去看看」了；新人還在搞懂處理網路的函式庫中，怎麼會有秀出UI及播聲音的實作；為了加速載入資源的速度，我們開了超多的線程，而且這會吃掉整個主機的運算資源，這可能沒辦法保證在16ms和法規主機維持通訊…

此時我想你已經火冒三丈，為什麼這麼簡單的事情有這麼多問題啊？但這個火山可不能噴發，只能請團隊成員大家多努力加班趕工。一個月兩個月過去了，你看著別人家的產品越來越豐富，品質也算穩定，可以東打日本，西進大陸，怎麼你的產品就是在修bug跟重構呢？釋出的日期一再跳票，玩家不斷的在抱怨畫面延遲不順，程式會當掉，英文版的介面怎麼會配上中文語音等…最終，你的產品就默默的下架了。

Stack Overflow？好啊好啊，不要叫我寫就好…

剛剛講的故事跟重構，也就是「還技術債」較為相關，但「知識管理」又何嘗不是面臨一樣的困境？

公司內有一些牛人，對於遊戲的機率設計特別在行。他們就是可以弄出賭客要的感覺，何時該出獎，何時該咬錢，怎麼出小獎，怎麼放大獎，搔得玩家真是癢得不要不要的，心甘情願的一直把錢投進去。這些人做了好產品，建了功，立了業，當上主管，繼續以自己的know-how保持產品優勢(應該說是自己的競爭優勢)。但你會發現，公司的產品競爭力就輕輕的，以溫水煮青蛙的方式慢慢的下滑，沒人看出哪裡不對勁，只看到玩家越來越沒有沈迷的感覺，轉而也玩玩別人的遊戲，反正我們的產品也越來越沒什麼獨到的特色。

怎麼會這樣呢？我們不是都有做「結案報告」嗎？為何我們的產品強度並沒有延續下去呢？公司曾經有意識到這個問題，請這些牛人辦了些簡報，說說他們是怎麼做出成功產品的。結果是簡報也做了，大家也聽了，隨著時間過去，並沒有什麼改善的效果出來。牛人的know-how依舊存在，產品也一樣有不錯的水準，但就只有那幾個人的產品靠譜，他們的意見靠譜，其他人的產品成績就是起起伏伏。

身邊還有另一類例子也很常見。A專案在進行的過程不算順利，大小問題不斷，時程一延再延，團隊人員長時間挑燈夜戰臭蟲三百回合，總算解掉一些找得到root cause的問題，繞掉一些找不到root cause的問題。結果他們在和B團隊閒聊的時候，才赫然發現他們遇到的問題，有些是B團隊也遇過的問題，有些根本不是A團隊造成的錯誤(但B團隊的人後來發現怎麼繞掉)。他們很洩氣，早知道應該多跟其他團隊的人們多聊聊問問。他們找遍了stack overflow，但就是找不到這種實務上才會遇到的問題解答。

大家都希望能有公司自己的stack overflow，能夠很快的查到公司自己的know-how，但吊詭的是不會有人花上大把的心力去輸出這些know-how。我要是有那種時間及心力，當然是趕緊投入到下個專案繼續賺錢啊。文件寫得多，寫得好，非但不會給我帶來業績，幫別人解決問題後，再來比一下我們倆的業績，反而變成我在偷懶了呢！而且，寫了又怎樣？我也不敢保證是對的，下次的狀況及環境若是不同，我還是要自己再去摸索，何必現在多寫呢？見招拆招吧。

寫了誰會看呢？下次吧…

這樣的惡性循環下來，劣幣驅逐良幣(工程師應該放心大膽地創造技術負債)，know-how的核心競爭力這邊漏一點，那邊少一塊，你只好投入更多的人在行銷上試圖多圈一些路人玩家，投入更多的工程師跟風打游擊戰(別人產品有什麼特色，你就隨即跟上)，除bug，重新發明輪子，你的產品根基極度不穩，何來業績？

或許你開始能理解，把公司內的「知識管理」做好是重要的事了。但你可能一下子不曉得要做些什麼，總不能大家放下手邊的事不做，都去寫文件吧？這裡就說說個人淺見，在公司裡做「知識管理」應該要做什麼，為什麼要做。

從任務開始

首先，要有光，就是要有任務追蹤系統。這個系統要能讓大家(團隊裡的成員或是你們的客戶)都能看到重要的任務資訊，像是要做什麼，何時動工，預定何時做完，目前進度等，而且能夠根據不同的欄位做搜尋或篩選。最最重要的是要有修改記錄可供查詢，能讓大家在修改任何資訊時(比如說要完成的規格或時程，呵呵)，能留下對應的記錄，能讓實作者在實作的過程遇到了什麼問題，如何解決問題(或繞過問題)，都能記錄到這個任務的版面上。如此一來，就不需要等專案結束才要寫什麼「結案報告」(前一個專案還屍骨末寒，你下一個專案通常已經開始了…)，你們在製作專案的過程就在寫報告了，而且還是最新鮮最熱騰騰的第一手資料。

有了任務追蹤系統後，知識管理的主幹就成形了，但要能起上實際的作用，就得靠管理者努力的跟催，實作者努力的輸出才行，這絕對是最重要的一件事。優先權可以不寫，狀態可以不更新，時程也可以不對(反正一定是不對的…呵呵)，但一定要強力要求實作者把重要的訊息馬上記錄上去，不管對錯(因為你既無法預知未來，又如何能定對錯？)，寫上去就是了。

剛剛說到「重要的訊息」，那什麼是重要的訊息呢？舉例來說，可能是發生了什麼問題，有什麼方法解決，查到了什麼連結，跟誰討論，改什麼做法之類的。各產業都有自己的domain know-how，但有一個原則是可以通用的：

你三個月後忘了一切，你需要什麼資訊再面對這個問題？

現在是訊息爆炸的時代，每個人每分每秒都在接收新訊息，不要說三個月你可能會忘記今天在做什麼，真的忙起來，三小時你就會忘了剛剛在做什麼。其實這狀況跟「別相信陌生人」的女主角一樣，一覺醒來她會全部忘記所有的事情，所以她得把重要的訊息一字一句都記在筆記本，才能讓reset過後的她可以快速進入狀況。

一但研發過程都在上面的時候，下一個專案要找解答就很簡單了：搜尋。這一搜尋下去，你會看到當時的規格是怎麼要求，遇到了什麼問題，我們究竟是怎麼解/繞掉的，哪些步驟我們能用，哪些環境和現在的不同…你面對問題，再也不是瞎猜；要解決問題，也不會再去重建輪子。

別用死文件

第二，就是要有Wiki系統，用來取代你離線的那些doc,xls,ppt,pdf…檔案。不論是一個自架的Wiki，或是你乾脆就用Google Drive / Google Site自架一個，都遠比你用老舊的Office套裝好得多。

你可能會說，這些檔案怎麼了，它們免費，格式漂亮，功能好用，內容正確啊，為何不用？因為它們都是「死」的，你需要的是「活」的文件。這所謂的「死」，所謂的「活」，在網路如此發達的現代，就是很簡單的兩句話：我要用的時候，能不能「找得到」？有新版本出來的時候，我能不能馬上「看得到」？

這樣一對比你就知道問題出在哪裡了。離線的doc，得找個地方放它，這不打緊，但面對成千上萬個doc檔時，只看檔名的話，我肯定是找不到我要的資訊的；2個人以上要對同一個doc更新內容？很抱歉，我開著你就動不了，你更新內容了我也不知道，直到我下次再打開才會看到新版本的內容，而我還不知道2個版本差異為何？若不是2個人，而是20個人都可以更新同一個檔案，你可以想想那是一個多恐怖的存取情境。

只是有了Wiki系統並不能解決什麼問題，必須得整個專案團隊正視這個系統，把規格書，會議記錄，人物設定，遊戲玩法等內容都導進去後，所有的人就在上面作業。管理者要確保所有人不要再看e-mail寫的規格，不要再以xls的數值設定為準，一切都以Wiki上寫的為準，這才能確保整個系統是「活著」的。

能輸出的才是「高手高手高高手」

第三，鼓勵輸出。團隊中能力好的，一定有很多其他人不知道的know-how。透過剛剛提到的Wiki系統，或是我們再搭建一個論譠也行，強力要求這些牛人，把自己的know-how整理出來，輸出到我們的知識管理體系中。別小看這件事，徹底執行起來可是有不小難度，但能獲得的也絕對是超乎預期。

為什麼呢？我們都知道「台上三分鐘，台下十年功」。很多你自以為很熟悉的東西，若要你整理成簡報或文件給其他人閱讀，你會赫然發現有許多原來根本沒想過的問題就需要去釐清了，不然連你自己都說服不了，又如何去說服別人呢？辦個簡報，寫個文件，若是獲得一些掌聲，那很好，可以給作者不少虛榮及自信；若是能再獲得一些疑問，一些討論，讓作者再去釐清更多疑點，那就更好了。「輸出就是最好的輸入」是我非常喜歡的金句之一，若運用在組織內，你能獲得的效果更是倍數成長。一人輸出，至少有3倍以上的輸入(作者原先瞭解的，加上準備簡報時的整理，最後還有討論和釐清問題的認知升華，這能不是有3倍嗎？搞不好不止呢)，若團隊內有人因此在實務上提升效率，這倍數都不曉得怎麼計算了。

這個過程，還附帶了一個你一定會需要的insight，那就是看出你的組員究竟有多優秀，值不值得花重金留住他。在組織內大家各有所長，身為管理者的你，一定會希望能有塞亞人用的那種戰鬥力眼鏡，能夠馬上告訴你A的戰鬥力多少，B是多少，C是多少等。在Google還沒發明這種東西以前，你其實有更高效的方法辨識出來：能輸出的才是真高手。

「知識管理」可不是「理工科」的課程

大家從學校畢業時，不曉得有沒有想過一個問題？我們為什麼要讀「歷史」，又為什麼要讀「經濟」？

我們科技人，理所當然的被分類成為「理工科」，就不用再讀地理和歷史了，也不用讀統計或經濟了。但很有意思的是，我們面對的難題，不論是技術上的，還是策略上的，往往都不是什麼新問題，而是我們讀過的「歷史」中就有的問題，都是「經濟」中就有可以借鏡的解法。我們現在做「知識管理」，正是兩者的結合體：研發過程成為歷史，可明得失，知興替；努力輸出簡報及文章，回答問題，參與討論，就是在交易know-how，你知道什麼，我熟悉什麼，我的學習效果變得更好，你的問題解決的更有效率，不是零和遊戲，而是一個極佳的經濟運作模式。

「知識管理」不是馬上看得到的業績，而是決定一個企業能成長到什麼程度的根基，這條路很長，而且沒有盡頭，但我們一定要有複利效果的眼界，帶著信念繼續前進。