Wzorce, które ciągle widzieliśmy
Jedna z najczęstszych rzeczy, które klienci mówią nam podczas rozmów wstępnych, nie ma nic wspólnego z designem, developmentem ani cenami. Zwykle to historia o agencji, która zniknęła po oddaniu projektu, o projekcie opóźnionym bez słowa wyjaśnienia, o zespole seniorów, który po cichu przekazał pracę juniorom, albo o produkcie, który na początku wyglądał na dopracowany, ale stał się trudny w zarządzaniu, gdy zaczęło się prawdziwe użytkowanie.
I szczerze, po wielokrotnym usłyszeniu wersji tej samej historii przestałam traktować je jak pojedyncze złe doświadczenia. To były wzorce. Nie chodzi o krytykowanie innych agencji. Prowadzenie studia jest naprawdę trudne. Jednoczesne zarządzanie terminami, developerami, poprawkami, operacjami, komunikacją i oczekiwaniami klientów jest trudne. Dziś rozumiem to dużo głębiej niż na początku. Ale słuchanie w kółko tych samych frustracji zmusiło nas do starannego przemyślenia, jaką firmą ma stać się Outlier Labs. Wiele naszych dzisiejszych wewnętrznych systemów istnieje, bo klienci pośrednio nauczyli nas, co zawiodło ich gdzie indziej.
Agencje znikały zaraz po oddaniu projektu
Zdecydowanie największym wzorcem było porzucanie klientów po starcie. Klienci spędzali miesiące, budując coś z agencją, z powodzeniem kończyli projekt, płacili ostatnią ratę, a potem komunikacja nagle drastycznie zwalniała. Czasem wsparcie znikało całkowicie. Czasem każdy drobny problem stawał się osobną fakturą. Czasem po prostu przestawali dostawać odpowiedzi w rozsądnym czasie.
W rzeczywistości większość prawdziwych problemów nie pojawia się w trakcie developmentu. Pojawia się po starcie, gdy prawdziwi użytkownicy zaczynają porządnie korzystać z produktu. Pierwsze tygodnie po wdrożeniu to zwykle czas, w którym firmy odkrywają luki operacyjne, przypadki brzegowe, problemy w procesach, potrzebę zmian w treściach albo drobne błędy, których wcześniej nie było widać. To całkowicie normalne. Ale wielu klientów mówiło nam, że na tym etapie czuli się pozostawieni sami sobie, co szczerze nigdy nie miało dla mnie sensu, bo z perspektywy biznesu projekt nie jest naprawdę „skończony” w chwili, gdy wychodzi na produkcję. Wtedy dopiero zaczyna się prawdziwe użytkowanie.
Dlatego całkowicie zmieniliśmy podejście do wsparcia po starcie. Domyślnie zapewniamy dziś 90 dni wsparcia, utrzymania, pomocy, naprawy błędów i rozsądnych zmian po oddaniu projektu. Jeśli coś się zepsuje, naprawiamy to. Jeśli procesy wymagają korekt po rozpoczęciu prawdziwego użytkowania, przeprowadzamy przez to klienta. Jeśli zespoły potrzebują pomocy w zrozumieniu systemów, porządnie je prowadzimy. I szczerze, to ogromnie zmieniło relacje z klientami. Nie dlatego, że klienci po starcie ciągle potrzebują dużego wsparcia technicznego, ale dlatego, że przestają czuć się porzuceni w chwili, gdy zapłacili.
Prawdziwym problemem zwykle była komunikacja
Kolejną rzeczą, którą wielokrotnie zauważaliśmy, było to, że klientów nie zawsze frustrowały same błędy techniczne. Frustrowała ich niepewność. Wielu klientów opisywało agencje, które świetnie komunikowały się na etapie wdrażania i rozmów sprzedażowych, ale stawały się niekonsekwentne, gdy zaczynał się właściwy projekt. Odpowiedzi zwalniały, aktualizacje robiły się mgliste, terminy niejasne, aż w końcu nikt naprawdę nie wiedział, na jakim etapie są prace.
I szczerze, myślę, że słaba komunikacja czasem wywołuje więcej stresu niż problemy techniczne, bo niepewność jest wyczerpująca. To jeden z powodów, dla których bardzo świadomie ustaliliśmy wewnętrzny rytm komunikacji. Staramy się komunikować regularnie, jasno i na platformie, na której klientom jest najwygodniej. Niektórzy wolą Slacka, inni WhatsAppa, inni maila, inni uporządkowane spotkania. Dostosowujemy się do tego, zamiast wciskać wszystkich w jeden sztywny system.
Co ważniejsze, nigdy nie znikamy klientom. Nawet jeśli jesteśmy zajęci, nawet jeśli jest opóźnienie, nawet jeśli wewnętrznie rozwiązujemy problem, komunikacja nigdy całkowicie nie znika. Czasem prosta wiadomość, że właśnie nad tym pracujemy i jutro porządnie damy znać, buduje znacznie więcej zaufania, niż ludzie sądzą. Klienci nie oczekują doskonałości przez cały czas. Ale oczekują widoczności.
Klienci byli zmęczeni tłumaczeniem problemów biznesowych na język techniczny
Kolejny wzorzec, który ciągle słyszeliśmy, to wyczerpanie założycieli ciągłym ponownym tłumaczeniem kontekstu biznesowego zespołom technicznym. Wielu klientów czuło, że sami stali się tłumaczami między celami biznesowymi a realizacją developerską. Wyjaśniali te same priorytety wielokrotnie różnym developerom, ciągle doprecyzowywali procesy, a i tak mieli poczucie, że prawdziwy problem biznesowy nie został w pełni zrozumiany.
To trudna pozycja dla klienta. Większość założycieli świetnie zna swój biznes, ale nie powinna musieć przez cały projekt ręcznie mostkować luk komunikacyjnych między strategią a developmentem. To jeden z głównych powodów, dla których mocno opieramy się na dedykowanych PM-ach. Nasi PM-owie rozumieją projekt zarówno od strony biznesowej, jak i realizacyjnej. Rozumieją priorytety, terminy, procesy, komunikację i cele na tyle głęboko, by porządnie zamknąć tę lukę. Dzięki temu developerzy mogą skupić się na budowaniu, a klienci czują się zrozumiani bez ciągłego ręcznego tłumaczenia kontekstu.
Wielu klientów czuło się wprowadzonych w błąd co do tego, kto faktycznie wykonuje pracę
To pojawiało się dużo częściej, niż się spodziewałam. Klienci na początku rozmawiali z doświadczonymi seniorami podczas rozmów sprzedażowych, wdrażania i dyskusji o strategii, ale gdy projekt faktycznie się zaczynał, większość realizacji po cichu przechodziła za kulisami do juniorów lub stażystów.
I żeby być uczciwą, rozumiem, dlaczego agencje tak działają. Struktury oparte na juniorach szybciej się skalują, kosztują mniej i znacząco poprawiają marże. Z czysto biznesowej perspektywy to bardzo wydajny model. Ale w końcu klienci zauważają różnicę. Luki w komunikacji się powiększają. Drobne błędy się mnożą. Kontekst ginie między zespołami. Efekt końcowy zaczyna wydawać się oderwany od pierwotnej wizji omawianej na starcie.
To jeden z powodów, dla których zbudowaliśmy Outlier Labs inaczej. W Outlier Labs stażyści i juniorzy nie realizują samodzielnie, po cichu w tle, kluczowej pracy dla klientów. Strategią, pomysłami, developmentem, architekturą, przeglądami i realizacją zajmują się bezpośrednio doświadczeni ludzie, którzy pracowali już przy wielu projektach. I szczerze, doświadczenie zmienia więcej, niż ludzie myślą. Doświadczone zespoły popełniają mniej błędów, których da się uniknąć. Lepiej rozumieją kompromisy. Wcześniej rozpoznają słabe pomysły. Zadają mocniejsze pytania. Wiedzą, kiedy coś brzmi ekscytująco, ale później stworzy niepotrzebną złożoność.
Klienci stawali się działem kontroli jakości
Zaskoczyło mnie, jak wielu klientów opisywało poczucie, że stali się testerami niedokończonej pracy. Dostawali wersje pełne oczywistych błędów, zepsutych ścieżek, niespójnych sekcji, niedokończonej responsywności albo brakujących funkcji, a ciężar wyszukiwania problemów po cichu przechodził na nich.
To wyczerpujące dla klientów. Większość założycieli jednocześnie zarządza zespołami, operacjami, wzrostem, rekrutacją i presją biznesową. Nie powinni spędzać mnóstwa czasu na wyszukiwaniu podstawowych problemów z jakością, które powinny zostać wyłapane wewnętrznie przed oddaniem. Dlatego jedną z rzeczy, w których staliśmy się bardzo rygorystyczni, jest wewnętrzna kontrola jakości. Zanim klienci zobaczą ważne rezultaty, najpierw sami je przeglądamy i testujemy. Sprawdzamy ścieżki, responsywność, przypadki brzegowe, funkcjonalność, użyteczność i ogólną spójność, zanim cokolwiek przekażemy na zewnątrz.
Porządna dokumentacja okazała się dużo ważniejsza, niż się spodziewaliśmy
Kolejną powtarzającą się frustracją klientów było to, że po zakończeniu projektu ledwie rozumieli, jak cokolwiek działa od środka. Systemy były z powodzeniem dostarczane, ale dokumentacja była albo słaba, albo jej w ogóle nie było. Zespoły miały później problemy, bo wiedza zostawała uwięziona w agencji, zamiast zostać porządnie przekazana. To tworzy uzależnienie.
Chcieliśmy czegoś odwrotnego. Dlatego bardzo świadomie podeszliśmy do dokumentacji i procesu przekazania. Porządnie wyjaśniamy systemy, dokumentujemy procesy, prowadzimy klientów przez funkcjonalności i upewniamy się, że zespoły naprawdę rozumieją, co zostało zbudowane i jak potem pewnie z tego korzystać. Bo szczerze, dobra realizacja to nie tylko zbudowanie czegoś, co działa. To także sprawienie, by klienci czuli się swobodnie jako właściciele tego, gdy odejdziesz.
Problemy z zakresem zwykle zaczynały się przed developmentem
Kolejnym wzorcem były projekty, w których zakres stawał się chaotyczny w połowie realizacji. Klienci opisywali sytuacje, w których pierwotna wizja ciągle się zmieniała, terminy stawały się nieprzewidywalne, oczekiwania się rozjeżdżały, aż w końcu nikt jasno nie rozumiał, co właściwie jest w zakresie. I szczerze, większość problemów z zakresem zaczyna się dużo wcześniej, niż ludzie myślą. Zwykle zaczynają się od słabego etapu discovery.
Dlatego poświęcamy ogrom czasu na porządne zrozumienie firm, zanim cokolwiek zbudujemy. Zadajemy szczegółowe pytania o procesy, cele, zachowania klientów, oczekiwania odbiorców, struktury operacyjne i długoterminowe priorytety, zanim ustalimy kierunek. Czasem klienci są zaskoczeni, jak dużo discovery robimy na początku, ale ta jasność zapobiega ogromnemu zamieszaniu później. Wielokrotnie przekonałam się, że niejasne początki niemal zawsze tworzą bolesny środek projektu. Im bardziej przemyślane discovery, tym zwykle płynniejsza jest potem realizacja.
Czego naprawdę się nauczyliśmy
Po wysłuchaniu tylu powtarzających się historii zrozumiałam coś ważnego. Większość firm tak naprawdę nie szuka już dostawców. Szuka niezawodności. Chce ludzi, którzy porządnie się komunikują, jasno wyjaśniają, rozumieją kontekst biznesowy, myślą z wyprzedzeniem, zamiast ciągle reagować, i przede wszystkim nie znikają po oddaniu projektu.
I szczerze, to zrozumienie ukształtowało dużą część tego, jak zbudowaliśmy Outlier Labs od środka. 90-dniowe wsparcie wzięło się z poczucia porzucenia klientów po starcie. Dedykowani PM-owie wzięli się z rozproszonej komunikacji, z którą zmagali się klienci. Wewnętrzna kontrola jakości wzięła się z niedokończonych wersji, które dostawali klienci. Realizacja wyłącznie przez seniorów wzięła się z poczucia wprowadzenia w błąd co do tego, kto faktycznie wykonuje pracę. Szczegółowa dokumentacja wzięła się z dezorientacji klientów po zakończeniu projektów. Niemal każdą decyzję operacyjną ukształtowało rozpoznawanie wzorców.
Najważniejsze, czego nauczyli mnie klienci ze złymi doświadczeniami z agencjami, to to, że zaufanie zwykle niszczy się bardzo powoli. Nie jednym katastrofalnym błędem, tylko powtarzającymi się drobnymi frustracjami. Opóźnione odpowiedzi, przegapione aktualizacje, słaba komunikacja, niewidoczne przekazania pracy, cisza po starcie, słaba dokumentacja i zamieszanie wokół zakresu każde z osobna wydają się do ogarnięcia. Razem tworzą wyczerpanie. I szczerze, myślę, że właśnie tego najbardziej staraliśmy się uniknąć w Outlier Labs. Nie tylko budowania dobrych produktów, ale budowania spokojniejszego doświadczenia wokół samego produktu.
