您還在使用研發記錄簿嗎?

一篇關於研發記錄簿的想法 , 讓我想起多年前進入一家做衛星接收器的一家公司的工作經驗, 我進入的第一天, 人事主管就給我一本研發記錄簿, 並跟我說明老闆每週都會抽檢, 而且離職的時候要交還歸檔, 在我離職的時候, 裡面確實記錄不少我所開發的軟體所遇到的問題與解法, 甚至還包含一個Windows Device Driver的原理與如何編譯的筆記, 過沒多久, 遇到以前的同事, 他告訴我, 公司的一些Device Driver後來改外包了, 因為後面的人還是接不起來, 我突然想起那本研發記錄簿, 裡面我可是很忠實的記錄Driver的開發流程, 怎麼會接不起來? 但是我很懷疑公司是如何處置我的研發記錄, 是不是鎖到某個櫃子永不見天日了?

寫到這裏, 又想到另一個親身經驗, 前年突然接到一通電話, 問我有沒有興趣接USB Scanner的Driver開發, 一問之下, 原來是以前同公司的老同事, 當年待的那家公司早已改組改做DRAM模組, 但是還有一小組在接Scanner的ODM , 我想起當初那家公司可是有過ISO 9000/9001的公司, 而且公司有一個很大的文管中心, 所有研發記錄, 與Source Code最後都要歸檔到文管中心, 如果有這些資料要開發新的Driver並不難, 所以問題是出在那裡?

人才很多, 我並不認為找不到人做, 如果經驗是有透過某種形式儲存, 要傳承並不難, 知識管理系統雖然有, 但是那些知識卻像一灘死水一樣, 無法重複使用, 例如Source Code有歸檔, 但是確無法Build, 原因出在工程師只將Source Code燒在光碟片交出去, 但是卻沒有記錄要用那個版本的compiler來build ? 或是要再安裝Third party library才能成功Compile, 其實這樣的潛在問題每一家公司都有, 沒有爆出問題, 是因為都有相對的"人"在處理, 但是人員的離職, 交接的不完全, 問題就慢慢出來了.

解決之道? 其實我覺得可以借鏡OpenSource的開發模式, 其實我認為OpenSource 雖然組織很鬆散, 可是卻沒有知識流失, 或是知識斷層的問題, 你會發現OpenSource的團隊分享文化, 其實間接的解決這種問題, 而且OpenSource的成員分散在各地, 於是更能善用Issue tracking , Wiki , Subversion , Auto Build等工具, 來解決溝通的問題, 在我的觀察, 運用這些工具也是在做知識管理, 而且這些工具是相互關連的, 所以累積的知識其重複利用價值也變高了.

我曾經在一個CMMI的論壇提及不妨學習OpenSource的開發模式來進行公司內部的專案管理, 會比導CMMI好很多, 而且有些OpenSource所開發出來的軟體品質與水準凌駕商業軟體,如Apache, MySQL, Subversion, 結果引來許多人的批評, 我前一陣子去上了一堂跟Coding Style有關的課, 講師也提到了CMMI, 同學就有人問了, 為什麼高鐵的票務系統是由一家CMMI Level 3的軟體公司承接, 但是品質似乎沒有預期的水準, 講師沒有說明為什麼, 我待過兩家都有過ISO 9000/9001的公司, 但是我對ISO 9000/9001還是不太了解, 也許當時只是一個小咖的,公司要過ISO 9000/9001好像跟我無關, 我現在回想起來是不是CMMI也跟ISO 9000/9001一樣, CMMI是管不到個人的Decipline :-) 我猜這也許是我那位上課同學所想要的答案.