一般的IT 公司都有需求、任務追蹤器的歷史記錄、來源(甚至可能在程式碼中包含註釋)、生產中典型、重要和複雜案例的說明、業務流程的描述(從入職到“如何去度假” ) 」)、聯絡人、存取金鑰、人員和項目清單、責任範圍的描述 - 以及一堆我們可能忘記的其他知識,這些知識可以儲存在最令人驚奇的地方。
知識=/=文件。 這無法解釋,必須記住
如何確保那些需要從中了解資訊的人知道在哪裡以及如何找到它,並且每個需要了解個別事物和協議的人都可以立即準確地了解其中的變化。
在“Team Lead Will Call”播客的最後一集中,Skyeng 的人員與 Igor 談論了知識管理
完整錄音可作為
第一個技巧:您不再需要知道要查看哪個系統
「我獲取了我們的知識來源並對它們進行了一般搜尋:帶有過濾系統的單一視窗以縮小搜尋範圍。 是的,與此同時,您仍然需要監控其質量,補充知識庫,並打擊重複和錯誤訊息。
一張紙就能找到一切
但已經有大約 60% 的 Flant 工程師每天至少使用此搜尋 1-2 次 - 並且通常在第一或第二位置找到答案。 概念驗證的形式是 Google 文件的索引:所有 dox、文件夾、貨車驅動器等 - 所有這些也很容易進入內部搜索。”
第二個技巧:如何在一堆聊天中不錯過至關重要的事情
「如果你在分散式團隊中工作,那麼你一天的很大一部分時間可能都花在Slack 上- 在這種情況下,你習慣於做這樣的事情:『@myteam,幫助/查看/輸入正確的.... ”。” 但資訊豐富存在一個問題——在其他訊息中可能會遺漏單獨的提及。
在 Skyeng,我們得到了一個機器人的幫助,您可以透過它編寫訊息並標記任意數量的人員或群組。 我們在人們閱讀或做出反應非常重要的情況下使用它:它會無休止地戳戳,直到你按下“我讀”按鈕 - 你將無法跳過或忽略它。”
要回答的問題:如何處理文件?
「很多知識都來自技術人員,但並不是每個人都知道如何很好地描述它們。
畢竟,您沒有任何編譯器或 linter 可以告訴您是否做得正確 - 而且我們的輸出通常是難以理解的、格式不正確且不完整的文字。 當然,你需要正常地做,而不是因為有人過來說「這是必要的」——你自己做的很好:一兩個月後你就會讀它並理解。 而另一個人,打開一個文檔,不會立即永遠關閉它,意識到它是無用的。
播客的一部分專門討論“需要多少人才能編寫良好的文檔或製作正常的演示”
但問題仍然存在:為此分配多少時間以及如何有效地完成它?
如果這裡有一個誠實的答案:除非業務人員參與其中,並且除非他們憑經驗體驗到良好文件的影響,否則這種努力可能會產生很少的回報。 這更多的是一個改變文化的故事。
對於其餘的,經驗和指導將拯救你。 結對程式設計、進度追蹤和程式碼審查的類似方法可能適合這裡——展示最佳實踐、找出錯誤並最終感到無聊。”
額外獎勵:“好吧,我會這樣告訴他們,他們會理解的”
「在這方面花費多少時間以及在什麼層面上這樣做」的問題不僅在文件框架內很重要,而且對於任何知識的轉移來說通常都很重要。 這個演示也是共享資訊的一個很好的例子。 但也存在一些細微差別:例如,如何確保它們佔用最少的時間。
開發間的知識分享管道:內部報告、有用的書籍、文章等。 結構化摘錄也儲存在 Notion 中。
這些問題在一定程度上可以透過內部報告的做法來解決。 每週一次,他們會在不太忙的時間花 40 到 60 分鐘,為來自不同專案的同事製作影片報告。 重點產品Vimbox前端團隊-
該名單自 2018 年 120 月起維護,共有 XNUMX 多個條目
所有會議均透過公司 Google Meet 開始、錄製並在 1.5 小時內出現在共享 Google 驅動器上的資料夾中,並且指向錄製內容的連結會在同一個 Slack 中複製。 也就是說,如果有緊急情況你不必來,而是稍後以 20 的速度觀看 - 通常報告本身持續長達 XNUMX 分鐘,以及討論 - 結果如何。 但我們不會超過這個時間)
聚苯乙烯 什麼對你有用,什麼沒用?
相關鏈接:
- 卡巴斯基實驗室的 Rodion Nagornov 關於
什麼是知識管理 以及為什麼這不是文檔(感謝 Igor 的頻道提供的鏈接“舒適的 IT 地獄” ,類似的還有很多)。
- 來自 Flant 的 Igor Tsupko 對此的看法
如何實施知識管理 在我公司
- 來自 Skyeng 的阿列克謝·卡塔耶夫
關於如何監控和調節低音因數 (技術和特定領域的知識差距)在分散式團隊中。
- 來自 Flant 的 Sergey Goncharuk 關於傳達訊息 -
如何知道何時向誰詢問 ,如果你在分散式團隊中遇到問題。
來源: www.habr.com