Szybkość infrastruktury: 5 lekcji wyciągniętych z budowy interkomu w Europie

W grudniu ogłosiliśmy hosting danych w Europie, wynik jednego z największych projektów infrastrukturalnych w historii Intercomu. Lekcje, których nauczyliśmy się podczas budowania infrastruktury, są bezcenne, ponieważ nadal rozwijamy Intercom na całym świecie – od kwietnia 2022 r. gościmy również Intercom w Australii.

Do tej pory Intercom był aplikacją wielodostępną hostowaną w jednym regionie w AWS. Jednak od dłuższego czasu rozmawialiśmy z naszymi klientami i potencjalnymi klientami o europejskim hostingu danych – wiedzieliśmy, co musimy dostarczyć i problem, który musimy rozwiązać : Interkom, ale z danymi przechowywanymi i przetwarzanymi w Europie.

Co wiedzieliśmy – a czego nie wiedzieliśmy

Zaczęliśmy od wielu „ znanych informacji”; problemy, o których wiedzieliśmy, że musimy rozwiązać, takie jak wdrożenia oprogramowania w wielu regionach. Zidentyfikowaliśmy również kilka „ znanych niewiadomych” ; problemy, które musieliśmy rozwiązać, ale jeszcze nie wiedzieliśmy, jak – na przykład integracja nowego regionu z naszym systemem rozliczeniowym. Byliśmy też pewni, że na odkrycie czeka mnóstwo „nieznanych niewiadomych”. Te nieznane niewiadome sprawiły, że trudno było oszacować, jak długo projekt będzie trwał lub ilu ludzi będziemy musieli mu poświęcić. Zakres był zbyt szeroki, aby można go było porównać z innymi projektami lub pracą, którą podjęliśmy w przeszłości, a droga do sukcesu niejasna.

Jedną z rzeczy, które zrobiliśmy na początku, była rozmowa z zespołami w podobnych firmach, które wcześniej podejmowały tego rodzaju projekty. W wielu przypadkach projekty te okazały się jednymi z największych, jakie te firmy kiedykolwiek podjęły, a ich ukończenie zabrało większości ich zespołu inżynierów ponad sześć miesięcy.

„Nie chcieliśmy spowalniać naszych zespołów badawczo-rozwojowych w środku pandemii – więc zbudowaliśmy nasz plan projektu tak, aby odzwierciedlał sposób, w jaki lubimy pracować w Intercomie”

Niektóre firmy posunęły się tak daleko, że przy okazji zmieniły swoją architekturę. Niechętnie dokonywaliśmy zmian na taką skalę i spowalnialiśmy nasze zespoły R&D (w środku pandemii!), więc zbudowaliśmy nasz plan projektu, aby odzwierciedlić sposób, w jaki lubimy pracować w Intercomie.

Oznaczało to szybkie poruszanie się, pomimo skali projektu. Szybkie działanie przy jednoczesnej optymalizacji długoterminowej , a także stosowanie naszej zasady „wysyłaj szybko, wysyłaj wcześnie, wysyłaj często” pomogło nam nie tylko uruchomić produkt, ale ostatecznie dostarczyć go naszym klientom wcześniej niż planowaliśmy dla.

Lekcja 1: Po prostu zacznij budować – szybko

Nasze zaangażowanie w szybkie poruszanie się doprowadziło nas do pierwszej lekcji i decyzji , która naprawdę otworzyła początek tego projektu. W niedawnym podcaście Intercom on Product nasz współzałożyciel Des opowiedział o starym memie z krzywą dzwonową Jedi io tym, jak często odnosi się on do szybkości start-upów. Większość startupów przechodzi przez etap „instalowania większej liczby procesów”, aż w końcu zda sobie sprawę, że po prostu muszą działać tak szybko, jak to możliwe. Szybkość i pośpiech miały nam pomóc odkryć te „nieznane niewiadome” i znaleźć rozwiązania, gdy je napotkaliśmy.

I tak nasz były CTO i współzałożyciel Ciaran Lee zdecydował, że dopiero zaczynamy. Mieliśmy zacząć budować i działać naprawdę, bardzo szybko, z małym zespołem ad hoc poświęconym projektowi – z informacją, że porażka jest całkowicie w porządku.

„Pozwolenie na porażkę zmieniło nasze podejście do projektu”

Gdyby nasze podejście nie zadziałało, zdobylibyśmy cenną wiedzę, która pozwoliłaby nam zaplanować coś, co może zadziałać w przyszłości. W najlepszym przypadku zbudowalibyśmy coś szybko, co zadziałało na tyle dobrze, że moglibyśmy zacząć zastanawiać się, jak przekazać to w ręce naszych klientów. Pozwolenie na porażkę zmieniło nasze podejście do projektu i pozwoliło nam ruszyć do przodu. Zamiast próbować przewidywać problemy i patrzeć w przyszłość, aby zagwarantować sukces od samego początku, po prostu zaczęliśmy budować, dopóki nie trafimy na problem, a następnie wymyśliliśmy rozwiązanie.

Należy również zauważyć, że nie tworzyliśmy prototypów, które mogłyby być później wykorzystane jako klocki do późniejszej pełnej implementacji – budowaliśmy prawdziwe, zastanawiając się, jak postępowaliśmy. Tempo, które w rezultacie utrzymaliśmy, okazało się kluczowe dla powodzenia projektu.

Lekcja 2: Trzymaj się swoich zasad

Kiedy zaczęliśmy budować, nasze zasady inżynieryjne pomogły nam w szybkim rozwoju. Istniało wiele sposobów, w jakie mogliśmy zbudować Intercom w Europie, w tym wymyślić na nowo naszą architekturę, ale zgodnie z naszą zasadą „ Bądź technicznie konserwatywny ”, zdecydowaliśmy się na to samo podejście, które zastosowaliśmy do budowy istniejącego środowiska produkcyjnego.

„Nie tylko kopiowaliśmy i wklejaliśmy, zamiast tego zmniejszaliśmy i upraszczaliśmy”

Nie wprowadziliśmy praktycznie żadnego nowego oprogramowania, usług ani podejść do naszej europejskiej budowy. Jednocześnie drastycznie uprościliśmy naszą architekturę, przejmując elementy naszej amerykańskiej infrastruktury i ponownie wykorzystując je w naszym nowym środowisku w sposób, z którym praca była znacznie łatwiejsza. Nie tylko kopiowaliśmy i wklejaliśmy, ale zmniejszaliśmy i upraszczaliśmy, zgodnie z naszą zasadą „ Utrzymaj to w prostocie ”.

Lekcja 3: Naginaj zasady, kiedy musisz

Musieliśmy zapewnić dużą elastyczność w naszych procesach planowania i strukturach zespołów, aby obsadzić personel i rozpocząć ten projekt, naginając „zasady” i jednocześnie informując wszystkich o tym, co robimy. Zbudowaliśmy zespół projektowy ad hoc składający się z doświadczonych inżynierów z istniejących zespołów, aby rozpocząć pracę nad projektem.

Oczywiście ta decyzja miała konsekwencje: zespoły miały mniejsze możliwości; członkowie projektu musieli zmagać się z wieloma codziennymi przygodami; a inne projekty musiały zostać zdegradowane. To nigdy nie może być naszym domyślnym podejściem do wszystkich projektów, ale kiedy wiedzieliśmy, co musimy osiągnąć i chcieliśmy zacząć od razu, sensowne było omijanie naszych procesów z szacunkiem na rzecz postępu.

Lekcja 4: Utrzymuj pracę tak lokalnie, jak to możliwe

To może być najważniejsza decyzja, jaką podjęliśmy, aby projekt przebiegał szybko. Pomimo dotknięcia wszystkich części Intercomu w ramach projektu, postanowiliśmy nie pracować w wielu zespołach i zamiast tego zachowaliśmy jak najwięcej pracy lokalnie dla naszego zespołu projektowego ad hoc. Oprócz unikania szerszych procesów planowania oznaczało to, że nie musieliśmy prosić naszych zespołów badawczo-rozwojowych o ułatwienie wdrażania naszych funkcji w Europie. Uniknęliśmy niezliczonych spotkań, dokumentów i wiadomości ze Slacka, wykonując tę ​​pracę samodzielnie jako domyślne podejście.

„Przyjęliśmy odpowiedzialność za problem i umożliwiliśmy sobie poczynienie postępów w jego rozwiązaniu”

Przyjęliśmy odpowiedzialność za problem i zapewniliśmy sobie możliwość poczynienia postępów, minimalizując ogólne koszty Intercomu poprzez minimalizowanie zakłóceń w zespołach nie pracujących nad Projektem Europa. Kilkakrotnie musieliśmy prosić o pomoc osoby z doświadczeniem i sprawiliśmy kilka niespodzianek dla niektórych zespołów – ale ogólnie było to bardzo udane podejście.

Lekcja 5: Utrzymuj elastyczne terminy

Po zbudowaniu infrastruktury i upewnieniu się, że Intercom Europe działa, przeszliśmy do innej fazy projektu i pracowaliśmy z wieloma zespołami w Intercom, aby koordynować uruchomienie skierowane do klientów.

Nasze blokery uruchamiania były w dużej mierze naszymi własnymi procesami wewnętrznymi i kilkoma integracjami skierowanymi do klientów, których nie uważaliśmy za krytyczne dla uruchomienia. Zadaliśmy więc sobie pytanie, czy moglibyśmy po prostu uruchomić bez funkcji WhatsApp i wypełnić te luki w trakcie? Co tak naprawdę nas powstrzymywało?

„Patrząc na oś czasu i oceniając, co pozostało do zrobienia, doszliśmy do wniosku, że możemy przesunąć uruchomienie do grudnia”

Nasz plan projektu został uruchomiony w styczniu, ale patrząc na oś czasu i oceniając, co pozostało do zrobienia, stwierdziliśmy, że możemy przesunąć go do grudnia. Potrzebowaliśmy pomocy ze strony obsługi klienta, sprzedaży, analityki, marketingu, prawa, badań i rozwoju i innych, ale wszyscy zebrali się razem, aby działać szybko.

Mamy kanał Slack pokazujący, kiedy nasz zespół sprzedaży zamyka transakcje z klientami korzystającymi z platformy, przynosząc realny dochód dla Intercomu. Opłacalność walki o adopcję na tych ostatnich etapach staje się jasna w tym kanale – zwiększa wartość całej pracy, którą włożyliśmy, aby zajść tak daleko. Byłoby znacznie łatwiej podążać za naszą obecną osią czasu, ale przepychając się, udało nam się dostać go w ręce klientów miesiąc wcześniej niż planowaliśmy.

Nasza nauka pomoże nam poruszać się szybciej

To był tak ekscytujący projekt do pracy – jestem dumny z pracy, którą wykonaliśmy i że zminimalizowaliśmy wpływ projektu na zespoły w Intercomie. Nadal jest wiele do zrobienia, ale wnioski, które wyciągnęliśmy z tego doświadczenia, były bezcenne, gdy budowaliśmy nasz australijski hosting i rozwijaliśmy infrastrukturę w innych jurysdykcjach.

Dowiedz się więcej o europejskim hostingu danych z domofonem