---

您即將獲得一個內部的導覽，了解 Blue 如何構建 Blue。

在 Blue，我們吃自己的狗食。

這意味著我們使用 Blue 來 構建 Blue。

這個聽起來奇怪的術語，通常被稱為「狗食」，常常被歸因於 1980 年代微軟的經理 Paul Maritz。他據報導發送了一封主題為 「吃我們自己的狗食」 的電子郵件，以鼓勵微軟員工使用公司的產品。

使用自己的工具來構建工具的想法是，它會導致積極的反饋循環。

使用自己的工具來構建工具的想法導致了一個積極的反饋循環，創造了許多好處：

• 它幫助我們快速識別現實世界的可用性問題。 由於我們每天使用 Blue，我們遇到的挑戰與用戶可能面臨的挑戰相同，這使我們能夠主動解決這些問題。
• 它加速了錯誤的發現。 內部使用通常會在錯誤到達客戶之前揭示它們，從而提高整體產品質量。
• 它增強了我們對最終用戶的同理心。 我們的團隊獲得了 Blue 的優勢和劣勢的第一手經驗，幫助我們做出更以用戶為中心的決策。
• 它推動了我們組織內的質量文化。 當每個人都使用該產品時，對其卓越性有共同的利益。
• 它促進了創新。 定期使用通常會激發新功能或改進的想法，使 Blue 保持在前沿。

我們之前談過為什麼我們沒有專門的測試團隊，這又是另一個原因。

如果我們的系統中有錯誤，我們幾乎總是在對平台的持續日常使用中發現它們。而這也創造了一個強迫功能來修復它們，因為我們顯然會覺得它們非常煩人，因為我們可能是 Blue 的主要用戶之一！

這種方法展示了我們對產品的承諾。通過依賴 Blue，我們向客戶展示我們真正相信我們所構建的東西。這不僅僅是我們銷售的產品——這是我們每天依賴的工具。

主要流程

我們在 Blue 中有一個項目，恰如其名為「產品」。

所有 與我們產品開發相關的內容都在這裡追蹤。客戶反饋、錯誤、功能想法、正在進行的工作等等。擁有一個追蹤所有內容的項目的想法是 促進更好的團隊合作。

每個記錄都是一個功能或功能的一部分。這就是我們如何從「如果...會不會很酷」轉變為「看看這個令人驚嘆的新功能！」的方式。

該項目有以下列表：

• 想法/反饋：這是一個基於通話或電子郵件交流的團隊想法或客戶反饋的列表。隨時在這裡添加任何想法！在這個列表中，我們尚未決定是否會構建這些功能，但我們會定期檢查以尋找想要進一步探索的想法。
• 待辦事項（長期）：如果我們決定某些功能將是 Blue 的良好補充，則這些功能將從想法/反饋列表中移至此處。
• {當前季度}：這通常結構為「Qx YYYY」，顯示我們的季度優先事項。
• 錯誤：這是一個由團隊或客戶報告的已知錯誤的列表。添加到這裡的錯誤將自動添加「錯誤」標籤。
• 規範：這些功能目前正在被規範。並非每個功能都需要規範或設計；這取決於功能的預期大小以及我們對邊緣情況和複雜性的信心水平。
• 設計待辦事項：這是設計師的待辦事項，每當他們完成進行中的某個項目時，可以從這個列表中選擇任何項目。
• 進行中的設計：這是設計師正在設計的當前功能。
• 設計審查：這是正在審查設計的功能所在的地方。
• 待辦事項（短期）：這是一個我們可能在接下來幾週內開始工作的功能列表。這是分配發生的地方。首席執行官和工程部門負責人根據以往經驗和工作負載決定哪些功能分配給哪位工程師。團隊成員可以在完成當前工作後將這些拉入進行中。
• 進行中：這些是目前正在開發的功能。
• 代碼審查：一旦功能完成開發，將進行代碼審查。然後，如果需要調整，將被移回「進行中」，或者部署到開發環境。
• 開發：這些是目前在開發環境中的所有功能。其他團隊成員和某些客戶可以對這些進行審查。
• 測試版：這些是目前在 測試版環境 中的所有功能。許多客戶將其用作他們的日常 Blue 平台，並將提供反饋。
• 生產：當一個功能達到生產階段時，則被視為完成。

有時，在我們開發一個功能時，我們意識到某些子功能的實施比最初預期的要困難，我們可能會選擇不在我們部署給客戶的初始版本中進行。在這種情況下，我們可以創建一個新記錄，名稱遵循格式「{FeatureName} V2」，並將所有子功能作為檢查項目包含在內。

標籤

• 移動：這意味著該功能特定於我們的 iOS、Android 或 iPad 應用程序。
• {企業客戶名稱}：該功能是專門為企業客戶構建的。追蹤很重要，因為每個功能通常都有額外的商業協議。
• 錯誤：這意味著這是一個需要修復的錯誤。
• 快速通道：這意味著這是一個快速通道變更，無需經過上述完整的發布週期。
• 主要：這是一個主要功能開發。通常保留給主要基礎設施工作、大型依賴升級和 Blue 中的重要新模塊。
• 人工智慧：該功能包含人工智慧組件。
• 安全性：這意味著必須審查安全影響或需要修補。

快速通道標籤特別有趣。這是為較小、較不複雜的更新保留的，這些更新不需要我們的完整發布週期，並且我們希望在 24-48 小時內發送給客戶。

快速通道變更通常是小的調整，可以顯著改善用戶體驗，而不改變核心功能。想想在 UI 中修正錯字、調整按鈕內邊距或添加新圖標以提供更好的視覺指導。這些是雖然小，但能對用戶感知和互動我們的產品產生重大影響的變更。如果這些變更需要很長時間才能發佈，那麼這些變更也會讓人感到煩惱！

我們的快速通道流程非常簡單。

它從從主分支創建一個新分支開始，實施更改，然後為每個目標分支（開發、測試版和生產）創建合併請求。我們生成一個預覽鏈接以供審查，確保即使是這些小變更也符合我們的質量標準。一旦獲得批准，這些變更將同時合併到所有分支中，保持我們的環境同步。

自定義字段

我們在產品項目中沒有很多自定義字段。

• 規範：這鏈接到一個包含該特定功能規範的 Blue 文檔。這並不總是完成，因為這取決於功能的複雜性。
• MR：這是我們在 Gitlab 上托管代碼的合併請求的鏈接。
• 預覽鏈接：對於主要改變前端的功能，我們可以為每次提交創建一個獨特的 URL，以便我們輕鬆審查更改。
• 負責人：這個字段告訴我們哪位高級工程師負責代碼審查。這確保每個功能都能獲得專家的關注，並且總有一個明確的聯繫人以解答問題或關注。

檢查清單

在我們的每週演示中，我們會將討論的反饋放入名為「反饋」的檢查清單中，還會有另一個檢查清單，包含該功能的主要 WBS（工作分解範圍），以便我們可以輕鬆告訴什麼已完成，什麼尚未完成。

結論

就這樣！

我們認為，有時人們會對我們的流程如此簡單感到驚訝，但我們相信簡單的流程通常遠比過於複雜的流程優越，因為後者難以理解。

這種簡單性是故意的。它使我們能夠保持敏捷，快速響應客戶需求，並保持整個團隊的一致性。

通過使用 Blue 來構建 Blue，我們不僅僅是在開發一個產品——我們是在生活它。

所以下次您使用 Blue 時，請記住：您不僅僅是在使用我們構建的產品。您正在使用一個我們每天都依賴的產品。

這一點使一切都不同。