很多小問題是大家習慣直接找到對應的負責人解決。對這個具體問題來說，當面溝通確實是最高效的，但沒有形成積累，只有直接參與這個問題的人知道問題的存在和解法。一旦人員調動就沒人知道了，或者時間久了連參與者自己都忘了。
當然，問題本身是否需要被記錄，也是需要評判的。有些問題，確實參考意義不大。
內部的研發系統上，很多問題，只有問題和簡單的解決結果。對客戶的系統好一點點，會有跟客戶的一些互動，對客戶的解釋也會更加完整清晰一些，但基本也是停留在結果上。對客戶是足夠了，但對內部其他人員的借鑑學習，我覺得還是不夠的。
不同部門各自有積累，但未能互聯互通。今年公司也在做一些這方面的工作，統一平台，加強知識庫建設，希望能真正起作用。
看到做的最好的，是以前遺留下來的一些問題解決的總結文件，會描述問題的現象，復現方式，然後進行初步分析，制定方案對可能的原因進行逐一排查，完整地寫出解決的思路，用到的工具和方法。一步步逼近根本原因，最後才得出結論。看這種文件，除了學到乙個知識點，更多的是學到了一些思路和方法。相當於別人手把手教你解問題，你會發現，哦，還能這麼幹，長見識了。下次你可能碰到的是乙個完全不同的問題，但思路和方法是可以借鑑的。正所謂授人以魚不如授人以漁，直接丟出乙個問題和結果，那就只是乙個知識點，讀者完全不知道如何從問題自行推導出結果，但如果寫出從問題到結果的過程，包括其中走的彎路，那對讀者來說，就是又掌握了一種解決問題的方法。前人花十天半月解決的問題，一篇文件就掌握了重要部分，再舉一反三，水平自然能迅速提高。
可惜這種文件太少了，而且寫一篇也不容易，估計只有疑難雜症或重要專案才能享有如此待遇。
當他人問問題時，判斷下是否是共性問題，是否其他人也會再問類似的問題。如果是共性的問題，且沒有現成的說明文件，那麼此時比起直接給對方解釋清楚，更好的做法是，先在wiki上形成乙個簡單的說明。再將這個鏈結發給對方。如果對方還有不明白的，再直接溝通，溝通清楚後，再針對剛剛溝通的內容，整理整合到wiki上，如此重複，不斷修改完善。等到這份文件確實夠完整清晰，再有其他人需要的時候，就可以乙個鏈結搞定，無需多費口舌，節約了大家的時間。
搭建了乙個部門內部論壇，用於記錄問題和解決方式。原本的期望是，每個問題報出來就可開一帖，描述問題，不要等到問題被解決掉再總結，而是隨著問題的進展，不停跟帖更新，直播解bug過程。中途其他人也可以給出意見建議。
效果是wiki很有用，總結過的問題，有人問的話，發個鏈結就可以解決。論壇的話，對個人回溯問題很有用，但沒有達到設想中的互動作用，僅作為另一種記錄問題的方式。且個人執行程度也不高，很多問題並沒有發到論壇上。
首先機制肯定是要有的，各種研發管理系統能解決部分問題，完善的流程，起碼保證問題和解決方式被記錄下來。但如果大家只是完成任務，那麼內容肯定質量高不到**去，容易流於形式。如何調動大家的分享的積極性，這才是最大的問題。要打造良好的團隊技術氛圍，讓大家都願意分享，習慣分享和討論。如果能引入一些激勵，那就更好了。
公司內部培訓的一些收穫
臨近年終，公司請來一位講師來給我們作培訓，題目記得是設計匠藝。說實話，我做不到像講師那樣，快講完課時能將自己所講的內容都有條理整理一遍。我就大致講講我所做筆記的一些內容吧。總的來說這位講師的實踐經驗很豐富，講得也很生動。觀點一 的可擴充套件性和可維護性是矛盾的。這是講師在上課之初所提的乙個觀點。說實...
公司內部培訓的一些收穫
分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！臨近年終，公司請來一位講師來給我們作培訓，題目記得是設計匠藝。說實話，我做不到像講師那樣，快講完課時能將自己所講的內容都有條理整理一遍。我就大致講講我所做筆記的一些內容吧。總的來說這位講師的實踐經驗很豐富，講得也很生動。觀點一 的可擴充套件性和可維...
關於公司內部培訓分享的思考
前幾天和同事討論如何在公司內搞培訓分享，提公升大家的學習，分享的意願和氛圍。其實以前也搞過一些培訓分享，也有一些效果好的分享，不過大多數效果都不行，分享的內容質量不高，大家的參與的意願不夠強烈。也有些分享，參與的人不多，聽過之後也就那樣了。沒有後續繼續了解的意願。還有一些由於分享人的原因，沒有做到乙...