對講的產品原則：以小步驟構建以提供最大的客戶價值
已發表: 2022-09-07大的變化很難理解，也更難調試。
在 Intercom，我們通過一系列小型、可控、易於理解的步驟來提供複雜的更改。 小的更改更容易構建和更快地審查，使我們能夠更快地為客戶提供價值。
這是探索我們產品原理的系列文章中的第七篇。 在這裡，Aidan 討論了我們的工程原則“逐步構建”。
沒有人總是正確的
錯誤發生在世界上的每一個團隊、每家公司。 一旦你接受了你不會一直做對，你可以通過以下兩種方式之一進行調整：
- 嘗試在發貨之前糾正錯誤，採取措施驗證或檢查您的工作。
- 允許自己犯錯，從錯誤中吸取教訓，並迅速調整以糾正錯誤。
如果您已經花費數週時間進行更改，那麼出錯的空間通常會更小。 這可能會導致您在發布更改時依賴驗證來避免意外。 驗證有它的位置，但它不是真正部署某些東西的糟糕替代品。 在發貨前需要進行的驗證越多，迭代或繼續下一個功能所需的時間就越長——它最終會減慢你的速度。
在發送更改時，我們的目標是控制：
- 受影響的變量數量：變更過程中受影響的變量越多，就越難以確定變更的哪一部分導致了問題。 通過縮小每一步的大小，我們可以收緊反饋循環，並讓自己在需要時更快地學習和調整。
- 更改的大小：通過縮小更改的大小，我們還減少了每次更改的爆炸半徑。 測試更改很重要，但前期驗證只能捕捉到這麼多。 較小的更改讓我們將注意力集中在逐步實現您的目標上，而不會太著迷於確保每個更改都是完美的。
- 哪些客戶經歷了變化：我們依靠功能標誌來驗證生產中的變化，並逐步將它們發布給客戶。
我們不確定該功能是否會解決客戶的問題，直到他們掌握它。 這種對交付小迭代的承諾很快與另一個對講原則聯繫在一起：交付學習。
管理複雜性
在復雜系統中構建具有挑戰性。 當在大的更改中出現錯誤，或者臃腫的功能錯過了標記時，很難確定具體問題。 小步驟使驗證、更改和繼續前進變得更加容易——相信您正在堅實的基礎上進行建設。
較大的變化包括許多假設：
- 關於您的更改將如何影響客戶工作流程的外部假設。
- 關於變更的不同部分如何相互作用和相互依賴的內部假設。
雖然您可以盡最大努力檢查外部假設，但交付更改並驗證或調整通常會更快、更穩健。 內部假設是複雜性可能蔓延的地方。當您的更改變得足夠大以包含多個相互依賴的構建塊時，將它們一起測試可能會有風險。 以增量方式發布這些內容要安全得多，將一個構建在另一個之上並隨時監控影響。
持久的速度創造動力
速度很棒但耐用，可靠的速度正在改變遊戲規則。 與一系列小而快速的迭代相比，發布一個大的變化意味著它的成功有更多的依賴，並且出現意外的風險更高。
“交付小變更、學習和迭代的緊密循環建立了強大的動力”
交付小更改、學習和迭代的緊密循環建立了強大的動力。 它消除了第一次就正確的需要，鼓勵更快的決策，並減少錯誤的爆炸半徑。 此外，將工作分解為更小的單元意味著工程師可以並行進行工作，從而使團隊作為一個整體移動得更快。
小步驟建設需要正確的團隊文化
小步驟的建設不是偶然發生的，它需要刻意的意圖和正確的環境。 我們的團隊文化和基礎設施堆棧在我們快速發布小更改的能力中發揮著至關重要的作用。
一旦團隊認識到快速發布小更改的重要性，同行評審就會被優先考慮並更快地完成。 由於小的更改更容易理解和審查，因此在每個階段都更有可能發現錯誤。 這種團隊的理解和緊迫感加快了整個過程。
“我們已投入大量資金來確保一旦更改經過審核並合併到主文件中，只需不到 15 分鐘即可投入生產，包括自動化測試和分段驗證”
當部署時間變慢時，工程師更傾向於批量更改，從而導致更大的更改週期。 我們已經投入大量資金來確保一旦更改經過審核並合併到主文件中，包括自動化測試和分段驗證在內的生產只需不到 15 分鐘即可完成。 它完全無需干預，一旦更改生效，工程師就會自動收到 Slack 通知。
將“逐步構建”原則應用於 Intercom 的 Salesforce 集成
去年，我們希望將 Intercom 與 Salesforce 更深入地集成，允許客戶從 Intercom 對話中自動創建 Salesforce 案例。 我們很快就理解了複雜性； 對話和案例並不總是直接映射，從工程和設計的角度來看，跨多對多關係同步數據將是一項挑戰。 除此之外，客戶希望如何使用此功能存在很大差異，並且需要適應客戶嚴重依賴的現有集成。
在考慮了許多影響和設計權衡之後，我們將項目停在了我們認為會產生更可靠影響的東西上。 我們幾乎沒有構建它，因為我們將它視為一個大的變化，而不是一系列的小步驟。
我們用不同的方法重新審視了這個項目
沒過多久，我們的銷售團隊就回來強調此功能對我們客戶的重要性——我們決定重新審視它。 這一次我們採取了不同的方法，從盡可能小的版本開始，避開一些複雜性，直到我們能夠了解客戶真正需要什麼。
“與我們合作的客戶非常重視團隊迭代的速度以及功能在日常基礎上的發展方式，並以他們的反饋為指導”
在兩週內，我和另一位工程師構建了這個功能的最基本版本，我們可以與客戶分享。 我們在許多小步驟中做到了這一點，以確保我們不會破壞客戶已經在使用的任何現有工作流程。 這使得該功能更加切實，客戶能夠就產品差距和改進提供具體反饋。
一旦客戶使用它，團隊就會以小步驟進行迭代，從而迅速使該功能更加靈活。 隨著靈活性的增長，使用它的客戶數量也在增加，我們迅速擴大了測試版。
事實證明，多對多關係並沒有阻止客戶使用該功能，我們成功地安全地啟動了它，沒有這種額外的複雜性，我們只是從小處著手并快速迭代才發現的。 與我們合作的客戶非常重視團隊迭代的速度以及功能在日常基礎上的發展方式，並以他們的反饋為指導。
小步驟建造對每個人都有效
我們以小步驟進行構建，主要是因為它可以幫助我們以更安全、更持久的方式更快地交付客戶價值。 但除此之外，作為一名工程師，這是一種更好的工作方式。 與交付重大更改相比，壓力要小得多，因為您在第一次就正確的情況下需要做很多事情 - 每次您將正在處理的工作交付生產時，您都會定期獲得多巴胺。
因此，如果這篇博文中沒有任何內容可以說服您進行優化以降低風險並提供增量價值，那麼您應該這樣做，因為它更有趣。
有興趣進一步了解我們在 Intercom 的工作方式嗎？ 了解更多。
