我們如何在一周內消除 44 個錯誤

作為一家公司，Buffer 每年都會在每年的最後一周關閉，從歷史上看，作為一個工程團隊，我們會在關閉之前的一周進行代碼凍結，這樣在假期之前就不會出現任何問題。 （我們很聰明。）

今年，我們做了一些不同的事情，但仍然有效。 我們將今年的最後一周作為整個工程團隊的「固定馬拉松」。

Fixathon = 我們 29 人的工程團隊花了整整一週的時間專注於修復錯誤。

到週末，我們不僅修復了 44 個錯誤，而且在過程中也沒有破壞任何內容。 😎

以下是有關我們設定 Fixathon 的過程和結果的更多資訊。

為什麼我們花了一周修復錯誤

與任何產品一樣，Buffer 也存在錯誤。 我們遇到它們，我們的倡導團隊注意到它們，我們的客戶標記它們。 我們相信，在解決錯誤的同時進行這些看似微小的改進最終可以對使用者體驗產生巨大的影響，這是我們團隊目前的一個大目標。 但這週不僅僅是修復錯誤，而是藉此機會將整個工程團隊聚集在一起，改進我們的工作方式。 我們花了一周的時間在發布變更、改善溝通以及與客戶倡導團隊和彼此之間更密切的合作方面養成了更好的習慣。

Fixathon 的運作方式

在修復馬拉松之前，我們為我們的團隊制定了一份任務清單，需要非常仔細地工作，以確保中斷的風險盡可能小。 從那時起，我們編寫了一套指導方針，供所有工程師在修復馬拉松開始後立即投入使用。

首先，我們開啟了一個名為 Bugsnag 的工具

我們的工程師每天都從使用 Bugsnag 開始，這是一款專為監控和管理自動錯誤報告而設計的工具。 此階段的主要目標是對這些自動錯誤報告進行分類。 我們的團隊審查、分類並在可能的情況下解決了 Bugsnag 直接報告的問題，我們的目標是在進入下一階段之前對至少 15 個錯誤報告執行操作。 這個過程對於了解我們系統的狀態以及系統中可能存在的問題至關重要 – 特別是因為我們因為沒有儘早持續這樣做而感到內疚。

接下來，我們轉向產品錯誤報告並解決它們

在花了一上午的時間對 Bugsnag 報告進行分類之後，我們的工程師將注意力轉移到了產品錯誤上，其中一些錯誤是在產品團隊的幫助下先前預先選擇的。 這些是先前在 Jira 中發現並記錄的問題。 工程師們在他們熟悉的領域選擇了任務，並確保安全地完成這些任務，互相審查程式碼並仔細檢查一切是否以正確的方式完成，以避免在這個敏感時期出現任何問題。

然後我們讓宣傳團隊了解狀況

修復馬拉鬆的一個重要部分是確保我們的倡議團隊了解我們正在做出的改變。 我們每天都會在更新頻道中發布消息，其中匯總了前一天的修復情況。

我們在 Fixathon 的最後一天討論了品質保證 (QA)

我們沒有在假期結束前的最後一天進行更多更改，而是花了一天時間通過一些品質檢查來確保一切保持良好狀態。 我們正在檢查我們的產品並確保一切按預期工作，花了一些時間一起打電話以追趕進度，並度過了愉快的時光。

我們第一次 Fixathon 的結果

最終，我們透過修復馬拉松學到了很多。 我們學會瞭如何作為一個團隊在 Bugsnag 中更好地運作以減少數量，我們更好地相互協作和倡導，並且我們了解了許多原本會被忽視的問題。 我們希望這個過程一直伴隨著我們，並且我們將持續清除新的 Bugsnag 問題，使我們更容易管理我們的錯誤並在我們的客戶之前註意到它們！

Fixathon 的另一部分是修復實際的錯誤！ 我們總共解決了 44 項任務，其中許多是我們今年早些時候沒有時間處理的小錯誤。 雖然其中大多數都很小，很難單獨注意到這些變化，但它們都有助於我們實現消費級體驗的願景。

我們解決的一些值得注意的錯誤包括：

• 將計費頁面連結新增至帳戶設定下拉清單中
• 使「建議媒體」可捲動
• 進行了大量的樣式更改，以使整個產品的邊距和外觀保持一致

作為 Fixathon 的一部分，我們也即將發布 LinkedIn 的「第一則評論」功能，我們已經為 Instagram 提供了該功能。 （加入我們的測試版計劃以獲得首次存取權限。）

我們非常仔細地制定了要完成的任務清單，以確保中斷的風險盡可能小。 最重要的是──我們交付了； 過去幾週沒有發生任何與 Fixathon 相關的事件！

我們認為 Fixathon 是一項非常成功的舉措，雖然這是第一次，但我們希望這不是最後一次！ 我們解決了錯誤，一起度過了一些時間，並學到了很酷的東西。 最重要的是 – 我們因此改進了我們的產品！