我們如何開始以兩倍的速度發布功能（案例研究）

當企業依賴您的應用程序進行日常工作時，您必須足夠敏捷以快速滿足他們的需求。 如果你不這樣做，其他人肯定會。 在無情的 SaaS 世界中，延遲一個關鍵功能（或匆忙編寫一段充滿錯誤的代碼）將意味著失去客戶。 一個可靠的敏捷工作流程可以讓一切變得不同。

我們是Active Collab背後的團隊，這是一個項目管理應用程序，具有不斷增長的功能集和龐大的用戶群。 這意味著即使是最小的功能變化也會影響到大量的人。

關於 SmashingMag 的進一步閱讀：

• 如何在不傷害忠實用戶的情況下推出新功能
• 網站啟動清單 – 上線前的 15 項基本檢查
• 以用戶為中心的移動設備網頁設計方法
• 如何啟動任何東西
  

因此，開發過程需要平穩運行並達到標準，將延遲減少到最低限度。 在任何更改到達最終用戶之前，它都會經歷五個關鍵階段：反饋、設計、開發、質量保證和部署。 在本文中，我將分享我們從八年多的業務中學到的（艱難的）每個階段的經驗。

叫醒電話

在詳細介紹之前，讓我們先看看這一切是如何發生的。 經過多年在沒有足夠審查的情況下添加功能，我們的應用程序遭受了功能膨脹的困擾。 多年來，我們添加瞭如此多的功能，以至於新用戶被 UI 的複雜性嚇倒了（再也不會回來了）。 我們知道我們必須從頭開始重建，即使這意味著從頭開始重寫每一個功能。

然後是延誤。 新版本的功能總是落後於計劃。 例如，初級開發人員應該開發與 QuickBooks 的集成。 我們沒有準確預測所需的複雜性、技能或知識。 再加上，他是唯一一個被分配到這個任務的人，沒有人可以快速跳出來幫助他。 結果，原本應該為期兩週的工作最終只需要五個。 那是一些危險信號。

顯然是時候改用更敏捷的方法了。 我們從各種敏捷（而不是那麼敏捷）方法中汲取了我們喜歡的東西，將其與經驗相結合，並提出了我們自己的版本，從那時起它一直在提供很好的結果。

讓我們仔細看看一個功能在提供給最終用戶之前必須經過的路徑。

從建議到特色

在我們的工作流程中，一個新功能在它到達開發團隊之前就已經開始形成，它通常是由用戶反饋產生的。 這不是巧合——我們過去常常發布不需要的功能，通常只是因為一個用戶特別吵，或者我們只是認為擁有一些東西會很棒。 我們現在不是想像用戶可能需要什麼功能，而是根據實際需求做出決策。

如果您從事精益製造，您會說我們的客戶通過比其他人更頻繁地請求某些功能來“拉動”某些功能。 我們的支持和銷售團隊是這個過程的重要組成部分，因為他們經常與分享他們的需求和想法的用戶保持聯繫。

根據反饋，我們的團隊更新了一個如下所示的表單：

當我們沒有所需的所有信息時，我們將直接與客戶聯繫。 這通常是通過對精心挑選的樣本進行有針對性的調查來完成的。 重點是我們傾聽。 我們不會丟失任何反饋。 它總是得到承認和記錄。

下一步是分析。 我們每個月都會統計分數，看看哪個功能獲得了最多的選票。 此外，通過適當的分類，我們可以更廣泛地了解我們軟件的哪些部分需要工作。 例如，如果日曆收到很多投訴，我們將考慮修改整個部分，而不是引入獲得最多票數的功能（例如日曆導出）。

然而，即使結果出來了，引入一項功能的決定也不是最終的。 在它進入我們的待辦事項列表之前，我們總是會進行徹底的完整性檢查：

• 這個功能會給用戶帶來什麼好處？
• 它符合我們的產品理念嗎？
• 它會增加不必要的複雜性嗎？
• 它是否與現有的界面和功能很好地融合在一起？
• 我們是否有資源在合理的時間範圍內交付它？

當一個功能通過檢查表並且產品所有者批准它時，就該去繪圖板了。

為用戶設計

經驗告訴我們，添加新功能並不僅僅意味著將其粘貼在 UI 之上——您必須將其與現有設計融為一體，並考慮到用戶。 如果你不這樣做，你很快就會得到一個如此復雜的應用程序，以至於只有少數勇敢的人才能通過試用的前五分鐘（是的，我們一直在那裡）。 美學對於良好的第一印像也很重要，但我們主要關心的是易用性。 需要以用戶感覺自然的方式添加功能。

我們通過詢問，用戶期望這個選項在哪裡？

對於現有用戶來說，重要的是新設計遵循他們熟悉的模式並且不會破壞他們的工作流程。 此外，還有我們都（無意識地）習慣的行業標準和慣例。 永遠不要期望您的用戶完全改變他們的習慣。 如果界面不直觀，他們更有可能在別處尋找。

使用鍵盤快捷鍵。 您可以創建自己的一組快捷方式並期望用戶學習它們（他們可能不會）。 或者您可以添加人們已經使用的那些。 例如，我們的許多用戶已經使用 Slack，因此我們添加了一個他們已經熟悉的快捷方式（ Command + K用於快速跳轉也適用於Active Collab ）。

當用戶流程到位後，我們的 UX 設計師會在 Sketch 中模擬設計。 我們很少在早期使用 HTML。 經過深思熟慮的 Sketch 可視化為我們提供了足夠的靈活性，以至於我們在開始編碼時無需進行任何回溯。 最初的設計通常最終匹配最終產品的 80%。 其餘部分在此過程中添加和調整。

設計過程的另一個重要步驟是複制。 我們的撰稿人對每一個字都非常關注。 我們甚至有自己的風格指南，聽起來平易近人，並且盡可能容易理解。 例如，說“安全證書”而不是“SSL 證書”，用通俗的話來說就是普通用戶可能不熟悉的東西。

完成所有這些後，該功能將分配給開發團隊。 該團隊由一名項目經理、一名首席開發人員和一些後端和前端開發人員組成，具體取決於工作量。 項目經理確保一切按計劃順利進行，而首席開發人員則負責技術方面的工作。 他們還協調和指導初級開發人員。

是時候開始了

我們的啟動會議不是無聊的激勵性聚會。 它們是開發團隊（由初級和高級開發人員組成）與項目經理和產品負責人會面的機會。

我們不會允許空洞的獨白，而是專注於將每個人的話變成可操作的任務。 一整天，三個重要的會議發生：

• 產品負責人向團隊展示給定的功能、其背後的想法、初始設計和預期結果。
• 然後，團隊有自己的會議，討論行動計劃、潛在問題和測試時間表。
• 最終會議由所有相關人員參加，計劃最終形成。 在本次會議結束時，團隊會給出演示的估計和最終截止日期。

一天的三個會議聽起來可能很多，但這就是我們確保及早解決問題的方式。 在這個階段填補空白可以為我們的開發人員節省大量時間、錯誤開始和回溯。 會議還鼓勵團隊合作，讓每個人都感到他們的貢獻受到歡迎。

會議結束後，團隊將獲得所有必要的信息：

1. 什麼？ 這是該功能的範圍，包括需要完成的所有內容，以及潛在的障礙和瓶頸。 我們試圖預測盡可能多的場景和邊緣情況。 預測所有這些並不容易。 他們經常在我們走的時候出現。
2. 為什麼？ 產品負責人估計一個功能的商業價值，並解釋為什麼值得付出努力。 這樣，團隊就可以清楚地了解對客戶和產品的好處。 這裡的主要動機是每個人都應該了解他們的工作為何重要以及它如何為整個公司做出貢獻。
3. 如何？ 通過概述完成一項功能所需的步驟，我們確保我們的開發人員永遠不會失去他們的指南針。 我們還通過添加複雜性標籤來設定現實的期望。 我們選擇了 T 卹尺寸 - S 可以在幾個小時內解決，而 XXL 需要數週或更長時間才能完成。
4. 誰？ 團隊負責人負責按時完成功能或任務，並負責向產品負責人更新進度。 其他團隊成員被分配到他們自己的子任務集，因此非常清楚誰對什麼負責。 盡可能保持透明有助於我們了解是否有人在苦苦掙扎或造成延誤。
5. 什麼時候？ 考慮到所有因素，預計到期日。 如果一項任務被延遲，我們會分析原因並在下次使用該經驗。 這樣，錯過的最後期限就變成了學習的機會，而不是壓力的來源。

開球日可能會很忙碌，但也非常富有成效。 每個人都提出想法和評論。 一項任務從一個空白的列表轉變為一個評論、編輯和更新的中心。 到一天結束時，開發團隊對未來的工作有了清晰的認識，並有了堅實的基礎。

在開始工作之前，我們會檢查此清單：

• 功能解釋，
• 概述完成的步驟，
• 產品所有者分配的商業價值，
• 團隊分配的複雜性，
• 已識別功能和錯誤依賴項，
• 確定的性能標準（如果需要），
• 已安排演示，
• 由團隊負責人設定的開始和結束日期。

這是任務移動到“進行中”列的時刻。

現在是編碼時間！

團隊合作展示

我們的開發人員從不單獨工作——這始終是團隊的努力，也是迄今為止發布新功能的最有效方式。 在引入團隊之前，（初級）開發人員會遇到一個問題，並且可能會在圈子裡轉來轉去好幾天（沒有人意識到這一點）。 或者，如果他們不是獨行俠類型，他們會經常分散同事和經理的注意力。

另一方面，在團隊中，我們將具有不同技能和經驗水平的人混合在一起。 這意味著每個人都被分配了一組適合他們水平的任務。 此外，老年人還可以從學習如何管理和指導初級隊友中受益——而後輩則可以尋求幫助。 因為這是一個團隊的努力，每個人都在朝著同一個目標努力，所以問題不會被視為分心，團隊可以更有效地解決任何問題。 團隊成為一個自組織實體，將工作分成階段（或衝刺）並在演示期間展示他們的工作。

展示並演講

根據時間表，團隊將為產品負責人進行演示。 演示的目的是展示一個功能在其當前狀態下的表現如何，以及在哪些方面需要進一步完善。 這是一個現實檢查，不允許找藉口，“它只需要一些最後的潤色”（需要一個月的潤色）。 此外，如果事情開始出現問題，產品負責人會迅速做出反應。

每週會議

我們從所有開發人員參加的定期簡短的每日會議開始。 每個開發人員都會簡要描述他們正在做什麼、他們的問題、他們的障礙以及他們是否需要幫助。 很快就很明顯，這些會議需要更加集中並提供切實的成果。 因此，我們改為每週與各個團隊開會一次。 這就是產品所有者和項目經理保持在循環中的方式，並且所有潛在的問題都在現場得到處理。

進行測試

代碼已編寫，演示已成功，一切似乎都很好地結束了……直到您發布該功能並看到應用程序崩潰。 這就是為什麼我們製作的每個功能都經過質量保證(Q/A)。 總是。 我們的測試人員會仔細檢查每一個可能的場景，檢查所有選項並在不同的環境中運行測試。 一個功能很少會在第一時間通過 Q/A。

為了提高生產力，我們過去常常讓開發人員在這個階段開始使用新功能，但這只會導致很多延遲的、半成品的功能。 因此，現在開發團隊在審查功能的同時忙於處理小型維護任務。 如果 Q/A 發現問題，開發人員會立即修復並重新提交。 重複該過程，直到該功能通過 Q/A 並繼續進行代碼審查。

這是高級開發人員確保代碼是按照我們的標準編寫的。 發布前的最後一步是編寫文檔——在發布一項沒人知道如何使用的功能後，您不希望被支持電子郵件淹沒。 我們的文案人員還會更新發行說明並撰寫營銷材料，例如電子郵件公告和博客文章。

這是我們對“完成”的定義：

• 編寫的自動測試，
• Q/A 已完成，所有由此產生的任務都已完成，
• 代碼審查完成，代碼合併到master，
• 發布說明已更新，
• 識別的功能和錯誤依賴項。

該任務已進入最後階段，稱為“發布 Q”。

發布日

在選擇發布新版本的日期時，我們立即決定避開週五和周一。 星期五不好，因為任何潛在的問題要到星期一才能解決； 另外，支持團隊當時已經很忙了。 星期一不是最好的時間，因為任何重大更新都需要準備，而這必須在周末完成。 留出一天進行最後的修飾總是好的。 這將選擇範圍縮小到三天——我們選擇了周二。 原因如下：

• 我們有星期一審查發布並在部署之前添加收尾工作。
• 如果有任何未翻譯的短語（我們的網絡應用程序支持七種語言），我們有足夠的時間來完成翻譯。
• 營銷團隊有足夠的時間通過社交媒體發送新聞通訊和公告。
• 我們可以在本週剩餘時間內快速有效地提供升級支持。
• 如果由於某種原因已經過了最後期限，我們還有周三或週四的時間來完成工作。

自由活動日

主要版本發布後的第二天是團隊的空閒日。 這是他們學習新技能或做任何他們覺得有趣的工作相關的事情。 儘管每個人都渴望知道我們將在第二天啟動哪個功能，但團隊還沒有討論這個問題。 相反，他們會放鬆一下，可能會觀看有關 Erlang 歷史的演示文稿，或者閱讀完有關為什麼 PSR-7 和中間件對現代 PHP 開發很重要的文章，或者進行自己的回顧性討論。 這是當之無愧的一天，可以為他們的電池充電並慶祝出色的工作。

捕蟲日

除了開發主要的新功能外，總是需要在現有功能上完成工作。 無論是錯誤修復、設計更新還是功能上的小改動，團隊都需要在合理的時間內處理好。

這就是為什麼我們每月至少有一次尋找錯誤的日子。 這是所有開發人員停止從事主要項目並將注意力轉向維護的時候。 事實證明，這種集中的努力取得了巨大的成功。 當每個人都在同一天單獨處理錯誤並且可以互相幫助時，團隊可以解決大量問題。

結果是什麼？

從啟動到開發、測試、代碼審查、文檔和最終發布，現在發布一個大功能平均需要大約三週時間。 一個具有同等複雜性的功能過去需要我們 45 天。 從我們的角度來看，這是生產力 100% 的提升。 我們使用相同的資源和人員完成了它，唯一的區別是改進了工作流程。

因此，如果我們對您有一個建議，那就是：培養一種消除對變化恐懼的公司文化，將使您的團隊在工作上做得更好。 無論您將其稱為 Scrum、看板還是精益都無關緊要，只要它有助於您的公司成長。 實驗和創新是任何敏捷方法的核心。 不要害怕測試不同的解決方案、衡量結果並根據結果修改現有做法。 好的結果會隨之而來。