所有工程團隊都依賴某種文件工具來與同事溝通重要的產品資訊。 對於剛開始的小團隊來說，這可能就像是 Google 文檔，而對於擁有複雜產品的大團隊來說，這可能是一個層級式的 wiki。 根據他們公司的結構，其他團隊（如人力資源或市場部）也可能使用這個 wiki，或者有其他地方儲存他們團隊的資訊。

我們相信將公司所有知識集中在一個中心地點最有效，我們也知道工程團隊的需求是具體、細緻和技術性的。 讓我們來看看Guru 如何支持工程團隊的文件需求，比如我們自己的團隊和 Guru 客戶RS21的例子。

環境設置與入職

當加入一個新的工程團隊（無論是內部還是外部）時，入職過程對於確定新隊友多快能夠貢獻是至關重要的。 從設置他們的編程環境到瀏覽功能文檔，需要做的事情很多，以便他們能夠迅速熟悉並準備好接受新工作。

對於許多工程團隊來說，入職過程對於另一位被指派為新員工的「夥伴」的幫助往往是繁瑣的，這位夥伴會即時帶領他們了解這些資訊。 但通過向團隊提供專家驗證的最新 Guru 卡片，RS21的工程領袖讓新入職員工能夠靈活地按照自己的節奏入職。 這讓他們能夠節省時間，用於與入職「夥伴」進行更多的人際關係建立或處理未解問題。

當新的工程師加入 RS21 團隊時，他們登錄 Guru 開始處理他們的入職材料。 他們將查看「團隊資訊」板，在這裡他們可以了解有關隊友的一些資料，使用基礎設施卡正確設置環境，並查看團隊的編程標準，以便更好地與新同事合作。

同樣，在 Guru 中，當工程師加入或轉到新團隊時，他們的入職在 Guru 中完成。 他們將使用個人故事卡片來了解他們的隊友，查看如何相互合作的指導，並瀏覽他們新團隊的收錄以熟悉他們現在負責的產品特性和領域。

最佳實踐和團隊標準

一旦整個團隊入職，持續的資源，如編碼標準和文件最佳實踐，也能在 Guru 中找到。 當以一種在他們的工作流程中可訪問的方式進行記錄時，這使得工程師能夠更輕鬆地與他們的團隊和公司的其他人高效協作。 這還可防止他們需要記住任何政策或程序，或者更糟糕的是，對過期文件進行書籤和依賴。

RS21的工程集合在 Guru 中包括一個專門的過程指導板，包括有關合併程式碼、創建 bash 指令碼、請求程式碼審查等的卡片。 他們還擁有專門的面對其團隊約定的編碼語法樣式、AWS 設置指令和系統管理信息等的板塊。 他們甚至有經常使用的代碼片段可以在 Guru 卡中輕鬆複製和粘貼。

除了這些特定於工程的卡片外，Guru 還是工程師訪問跨功能最佳實踐和團隊間流程指導的好地方。 例如，RS21的團隊使用Guru進行異步討論，以便給予團隊成員更多時間進行深入的回覆，並提供每個人一個平等的貢獻平台。 如何設置和監控這些討論的指導保存在 Guru 模板中，因此任何人都可以在需要時輕鬆啟動其討論。

在 Guru，我們能夠徵集產品開發組外的團隊來協助我們的質量保證（QA）過程。 憑藉更多元的觀點，我們能夠更好地識別錯誤，探索潛在的客戶挑戰，並在發布前保護它們。 但是，像 QA 這樣的技術過程在涉及跨功能團隊時，必須有文檔指導和程序。 在開始對新功能進行 QA 前，工程團隊負責人將使用我們的QA 流程模板，為我們團隊和利益相關者創建一個一站式商店，以獲取端到端的 QA 所需的一切。 當我們準備開始 QA 時，他們將把這條消息作為公告發送給團隊和利益相關者，並在消息中包含活動 QA 的日期。

專案規劃與開發文件

每當啟動新的開發專案時，隨之而來的大量文件將確保每個人都擁有他們需要的完整上下文，以發揮自己的角色。 在啟動會議後，工程師依賴產品團隊的需求文檔、UX 團隊的最新功能設計、來自市場或文案團隊的文案等。

當然，他們經常需要參考影響他們正在為之工作的功能的任何技術文檔，或他們稍後需要在開發中進行更新的文檔。

在 Guru，我們追踪產品開發所需的各種資源，這是由每個項目的工程負責人主導的主動專案資源卡片。 這些卡片是工程團隊在產品開發生命週期早期階段的主要資源，並根據變更進行更新。

隨著開發過程的進展，工程與設計之間的協作必須保持同步。 但由於工作常常是非同步和遠程的，設計師和工程師並不總能立即開啟 Zoom 會議來討論任何問題或反饋。 為了確保他們遵循我們約定的內部協議以索取設計反饋，我們的工程團隊使用我們在 Guru 中記錄的設計反饋工作流程。

未來防範的文檔

文檔一直是並將永遠是工程師工作中的必要部分。 但曾經引起痛苦的呻吟和焦慮的嘆息的事情，當它直接融入工作流程時，可以變成他們日常生活中簡單、自然的一部分。 Guru 的瀏覽器擴展 將文檔帶到工程師所需的地方，而不是迫使他們切換上下文來訪問它，而短格式的專家驗證卡片則減輕了以往需要花費大量精力編寫和維護的長篇文章的壓力。 那麼為何要用過時的文檔來增加技術債務，而不乾脆就立即未來防範呢？ 今天就免費開始。