圍繞一個模組一個主題，準備材料，做一場專門的完整的培訓或分享，是很有用的。其視訊和文件也是重要的技術積累。此處主要想討論的是，對日常研發過程的零碎問題和解決手段的積累，沒有那麼完整和重量級，但確實很難做好。

現狀

問題一：很多問題沒有積累。

很多小問題是大家習慣直接找到對應的負責人解決。對這個具體問題來說，當面溝通確實是最高效的，但沒有形成積累，只有直接參與這個問題的人知道問題的存在和解法。一旦人員調動就沒人知道了，或者時間久了連參與者自己都忘了。
當然，問題本身是否需要被記錄，也是需要評判的。有些問題，確實參考意義不大。

問題二：有積累的問題過於簡單

內部的研發系統上，很多問題，只有問題和簡單的解決結果。對客戶的系統好一點點，會有跟客戶的一些互動，對客戶的解釋也會更加完整清晰一些，但基本也是停留在結果上。對客戶是足夠了，但對內部其他人員的借鑑學習，我覺得還是不夠的。

問題三：不夠開放

不同部門各自有積累，但未能互聯互通。今年公司也在做一些這方面的工作，統一平臺，加強知識庫建設，希望能真正起作用。

好的例子

看到做的最好的，是以前遺留下來的一些問題解決的總結文件，會描述問題的現象，復現方式，然後進行初步分析，制定方案對可能的原因進行逐一排查，完整地寫出解決的思路，用到的工具和方法。一步步逼近根本原因，最後才得出結論。看這種文件，除了學到一個知識點，更多的是學到了一些思路和方法。相當於別人手把手教你解問題，你會發現，哦，還能這麼幹，長見識了。下次你可能碰到的是一個完全不同的問題，但思路和方法是可以借鑑的。正所謂授人以魚不如授人以漁，直接丟出一個問題和結果，那就只是一個知識點，讀者完全不知道如何從問題自行推匯出結果，但如果寫出從問題到結果的過程，包括其中走的彎路，那對讀者來說，就是又掌握了一種解決問題的方法。前人花十天半月解決的問題，一篇文件就掌握了重要部分，再舉一反三，水平自然能迅速提高。
可惜這種文件太少了，而且寫一篇也不容易，估計只有疑難雜症或重要專案才能享有如此待遇。

個人實踐

知識總結放wiki

當他人問問題時，判斷下是否是共性問題，是否其他人也會再問類似的問題。如果是共性的問題，且沒有現成的說明文件，那麼此時比起直接給對方解釋清楚，更好的做法是，先在wiki上形成一個簡單的說明。再將這個連結發給對方。如果對方還有不明白的，再直接溝通，溝通清楚後，再針對剛剛溝通的內容，整理整合到wiki上，如此重複，不斷修改完善。等到這份文件確實夠完整清晰，再有其他人需要的時候，就可以一個連結搞定，無需多費口舌，節約了大家的時間。

問題解決放論壇

搭建了一個部門內部論壇，用於記錄問題和解決方式。原本的期望是，每個問題報出來就可開一帖，描述問題，不要等到問題被解決掉再總結，而是隨著問題的進展，不停跟帖更新，直播解bug過程。中途其他人也可以給出意見建議。

實踐效果

效果是wiki很有用，總結過的問題，有人問的話，發個連結就可以解決。論壇的話，對個人回溯問題很有用，但沒有達到設想中的互動作用，僅作為另一種記錄問題的方式。且個人執行程度也不高，很多問題並沒有發到論壇上。

幾點思考

素材收集

要形成總結，我覺得首先需要能把素材積累下來。一個問題解決完畢後，很多中間的log，測試資料，問題現象是沒有儲存和截圖的，且關聯的材料可能散佈在郵件，聊天記錄，口頭交流等。巧婦難為無米之炊。如果要在總結文件中說清楚，那收集材料都是個問題，甚至必須重新做一遍測試。如果能讓大家在解決問題的過程中，方便快捷地把所有的分析和嘗試（包括無效的嘗試），以及關聯的材料（如問題描述，郵件往來，釘釘/微信記錄）都記錄下來。那起碼有了一份原始記錄。
一個設想是，設立一個公共郵箱，對於某個問題的郵件全部抄送該郵箱，那麼，即使沒有後續的進一步整理總結，其中的資訊也有很大的價值。在其中搜索到關鍵資訊，看看郵件往來，可能就能搞定一個問題，避免重複開發，重複解bug。

引入互動

最好能有互動，反饋，完善補充。有些問題和解決思路方法，你記錄下來的時候，可能自己覺得講得很明白了，但別人看到就不一定了。如果能有人在這個過程中積極參與討論，提出疑問和建議作為反饋，那麼對於這個問題的解決和後續其他人的借鑑，都會很有意義。腦補下大概類似於開源社群的郵件列表，或者技術論壇上的討論帖，或者部落格下方的一些留言探討。

積極性

首先機制肯定是要有的，各種研發管理系統能解決部分問題，完善的流程，起碼保證問題和解決方式被記錄下來。但如果大家只是完成任務，那麼內容肯定質量高不到哪裡去，容易流於形式。如何調動大家的分享的積極性，這才是最大的問題。要打造良好的團隊技術氛圍，讓大家都願意分享，習慣分享和討論。如果能引入一些激勵，那就更好了。