Zasady produktu Intercom: Budowanie małymi krokami, aby zapewnić maksymalną wartość dla klienta

Duże zmiany są trudne do zrozumienia i trudniejsze do debugowania.

W Intercom dostarczamy złożone zmiany w serii małych, kontrolowanych, łatwych do zrozumienia kroków. Małe zmiany są łatwiejsze do zbudowania i szybsze do sprawdzenia, co pozwala nam szybciej dostarczać wartość klientom.

To siódmy post z serii, w której badamy zasady dotyczące naszych produktów . Tutaj Aidan omawia naszą zasadę inżynierską „Buduj małymi krokami”.

Nikt nie ma racji przez cały czas

Błędy zdarzają się w każdym zespole, w każdej firmie na świecie. Gdy zaakceptujesz, że nie będziesz przez cały czas robił tego dobrze, możesz to zmienić na dwa sposoby:

• Spróbuj poprawić błędy przed ich wysłaniem, podejmując kroki w celu weryfikacji lub sprawdzenia swojej pracy.
• Pozwól sobie na pomyłkę, ucz się na błędach i szybko dostosuj się, aby to naprawić.

Jeśli pogrążyłeś się już kilka tygodni w zmianie, często jest mniej miejsca na pomyłkę. Może to prowadzić do polegania na walidacji, aby uniknąć niespodzianek podczas wysyłania zmiany. Walidacja ma swoje miejsce, ale jest kiepskim substytutem wdrożenia czegoś w rzeczywistości. Im więcej walidacji musisz przeprowadzić przed wysyłką, tym dłużej trwa iteracja lub przejście do następnej funkcji – to ostatecznie spowalnia.

Wysyłając zmianę, staramy się kontrolować:

• Liczba zmiennych, których dotyczy zmiana: Im więcej zmiennych dotyczy zmiany, tym trudniej jest ustalić, która część zmiany spowodowała problem. Zmniejszając rozmiar każdego kroku, zacieśniamy pętlę sprzężenia zwrotnego i przygotowujemy się do szybszego uczenia się i dostosowywania, jeśli zajdzie taka potrzeba.
• Rozmiar zmiany: Zmniejszając rozmiar naszych zmian, zmniejszamy również promień wybuchu każdej zmiany. Testowanie zmian jest bardzo ważne, ale walidacja z góry będzie obejmować tylko tyle. Mniejsze zmiany pozwalają nam skoncentrować naszą uwagę na stopniowym osiąganiu celu i nie dać się zbytnio pochłonąć zapewnieniu, że każda zmiana jest idealna.
• Którzy klienci doświadczają zmiany: Opieramy się na flagach funkcji, aby weryfikować zmiany w produkcji i stopniowo udostępniać je klientom.

Nie wiemy na pewno, czy funkcja rozwiąże problem klienta, dopóki nie będzie miał go w swoich rękach. To zobowiązanie do wysyłania małych iteracji szybko łączy się z inną zasadą interkomu: statek do nauki.

Zarządzanie złożonością

Budowanie w złożonych systemach jest wyzwaniem. Gdy błędy pojawiają się w dużych zmianach lub rozdęte funkcje chybiają celu, trudno jest wskazać konkretny problem. Małe kroki ułatwiają walidację, zmianę i kontynuowanie — masz pewność, że budujesz na solidnym gruncie.

Duże zmiany obejmują wiele założeń:

• Zewnętrzne założenia dotyczące tego, jak Twoja zmiana wpłynie na przepływy pracy Twoich klientów.
• Wewnętrzne założenia dotyczące interakcji i zależności między różnymi częściami zmiany.

Chociaż możesz zrobić wszystko, co w Twojej mocy, aby sprawdzić zewnętrzne założenia, często szybciej i bardziej niezawodnie jest wysłać zmianę i zweryfikować lub skorygować. W założeniach wewnętrznych może wkraść się złożoność. Gdy zmiana staje się wystarczająco duża, aby objąć kilka bloków konstrukcyjnych, które są od siebie zależne, testowanie ich razem może być ryzykowne. O wiele bezpieczniej jest uwalniać je stopniowo, budując jeden na drugim i monitorując wpływ na bieżąco.

Trwała prędkość buduje rozpęd

Szybkość jest świetna, ale trwała, niezawodna prędkość zmienia zasady gry. Wysłanie dużej zmiany oznacza, że ​​sukces jest znacznie większy i większe ryzyko niespodzianek w porównaniu z serią małych, szybkich iteracji.

„ Wąski cykl wysyłania małych zmian, uczenia się i iteracji buduje silny rozmach”

Wąski cykl wprowadzania małych zmian, uczenia się i iteracji nabiera silnego tempa. Eliminuje potrzebę uzyskania racji za pierwszym razem, zachęca do szybszego podejmowania decyzji i zmniejsza promień wybuchu błędów. Co więcej, dzielenie pracy na mniejsze jednostki oznacza, że ​​inżynierowie mogą równolegle rozwijać pracę, co pozwala zespołowi działać szybciej jako całość.

Budowanie małymi krokami wymaga odpowiedniej kultury zespołowej

Budowanie małymi krokami nie jest dziełem przypadku, wymaga przemyślanej intencji i odpowiedniego otoczenia. Nasza kultura zespołowa i stos infrastruktury odgrywają kluczową rolę w naszej zdolności do szybkiego wprowadzania małych zmian.

Gdy zespoły przekonają się, jak ważne jest szybkie wysyłanie niewielkich zmian, wzajemne recenzje są traktowane priorytetowo i szybciej kończone. Ponieważ małe zmiany są łatwiejsze do zrozumienia i przeglądu, istnieje większe prawdopodobieństwo, że błędy zostaną wyłapane na każdym etapie. To zrozumienie i pilność zespołu przyspiesza cały proces.

„ Znacznie zainwestowaliśmy w zapewnienie, że po sprawdzeniu i scaleniu zmiany w celu jej wprowadzenia do produkcji zajmie mniej niż 15 minut, w tym zautomatyzowane testowanie i walidacja etapów”

Gdy czas wdrażania zwalnia, inżynierowie są bardziej skłonni do zmian wsadowych, co skutkuje cyklem większych zmian. Znacznie zainwestowaliśmy w zapewnienie, że po sprawdzeniu i scaleniu zmiany do poziomu głównego przejście do produkcji zajmie mniej niż 15 minut, łącznie z automatycznym testowaniem i walidacją etapów. Jest to całkowicie wyłączone, a inżynierowie otrzymują automatyczne powiadomienie o Slack, gdy zmiana zostanie wprowadzona.

Zastosowanie zasady „buduj małymi krokami” do integracji z Salesforce w Intercomie

W zeszłym roku staraliśmy się głębiej zintegrować Intercom z Salesforce, umożliwiając klientom automatyczne tworzenie przypadków Salesforce na podstawie rozmów Intercom. Szybko zrozumieliśmy złożoność; rozmowy i sprawy nie zawsze są mapowane bezpośrednio, a synchronizacja danych w relacji wiele-do-wielu byłaby trudna zarówno z perspektywy inżynierskiej, jak i projektowej. Do tego dochodziło duże zróżnicowanie w sposobie, w jaki klienci chcieli korzystać z tej funkcji i konieczne było dopasowanie się do istniejącej integracji, na której klienci w dużym stopniu polegają.

Po przeanalizowaniu wielu implikacji i kompromisów projektowych zaparkowaliśmy projekt na rzecz czegoś, co naszym zdaniem zapewni bardziej niezawodny efekt. Prawie tego nie zbudowaliśmy, ponieważ potraktowaliśmy to jako dużą zmianę, a nie serię małych kroków.

Powróciliśmy do projektu z innym podejściem

Nie minęło dużo czasu, zanim nasz zespół sprzedaży powrócił, aby podkreślić, jak ważna jest ta funkcja dla naszych klientów – i postanowiliśmy nadać jej inny wygląd. Tym razem przyjęliśmy inne podejście, zaczynając od najmniejszej możliwej wersji i unikając pewnej złożoności, aż mogliśmy dowiedzieć się, czego naprawdę potrzebują klienci.

„ Klienci, z którymi współpracowaliśmy, naprawdę docenili tempo, w jakim zespół iterował i jak funkcja ewoluowała na co dzień, kierując się ich opiniami”

W ciągu dwóch tygodni z innym inżynierem zbudowaliśmy najbardziej podstawową wersję tej funkcji, którą mogliśmy udostępnić klientom. Zrobiliśmy to w wielu małych krokach, upewniając się, że nie złamaliśmy żadnego z istniejących przepływów pracy, z których korzystali już klienci. Dzięki temu funkcja była znacznie bardziej namacalna, a klienci mogli przekazać konkretną opinię na temat luk i ulepszeń produktu.

Gdy klienci już z niej korzystali, zespół wykonał iterację małymi krokami, szybko czyniąc tę ​​funkcję bardziej elastyczną. Wraz ze wzrostem elastyczności wzrosła liczba korzystających z niej klientów i szybko rozszerzyliśmy wersję beta.

Okazało się, że relacja wiele-do-wielu nie przeszkodziła klientom w korzystaniu z tej funkcji i pomyślnie uruchomiliśmy ją bezpiecznie i bez tej dodatkowej złożoności, co odkryliśmy dopiero rozpoczynając od małych i szybko powtarzając. Klienci, z którymi współpracowaliśmy, naprawdę docenili tempo, w jakim zespół iterował i jak funkcja ewoluowała na co dzień, kierując się ich opiniami.

Budowanie małymi krokami działa dla każdego

Budujemy małymi krokami przede wszystkim dlatego, że pomaga nam to szybciej dostarczać klientom wartość w bezpieczniejszy i trwalszy sposób. Ale poza tym dla inżyniera jest to przyjemniejszy sposób pracy. Jest to o wiele mniej stresujące niż wysyłanie dużych zmian, w których wiele zależy od tego, czy masz rację za pierwszym razem – i otrzymujesz regularne uderzenie dopaminy za każdym razem, gdy wysyłasz do produkcji to, nad czym pracujesz.

Tak więc, jeśli nic w tym poście na blogu nie przekonuje Cię do optymalizacji pod kątem redukcji ryzyka i dostarczania dodatkowej wartości, powinieneś to zrobić, ponieważ jest to po prostu przyjemniejsze.

Chcesz dowiedzieć się więcej o tym, jak pracujemy w Intercomie? Dowiedz się więcej.