Marcin Zaremba

Ten wpis można czytać także w formie PDFa (35 stron, 8mb) . Do ściągnięcia tutaj

Swoją drogą to tylko jedna z kilku Dekompozycji, które zrobiłem w ciągu ostatnich 8 lat. Wszystkie znajdują sie tutaj

Zamiast wstępu

DobryMechanik.pl (dalej DM) to portal, który agreguje warsztaty samochodowe i prezentuje je kierowcom, którzy potrzebują naprawy. Serwis powstał w 2013 roku, a w 2018 roku zainwestował w niego fundusz  Market One Capital.

O firmie dowiedziałem się od Marcina Kurka z MOCy. Rozmawialiśmy z Marcinem przez ostatnie lata kilkakrotnie o jego spółkach portfelowych, które potrzebują wsparcia produktowego, ale do tej pory timing był niekorzystny. Tym razem było inaczej.

Następnie miałem kilka rozmów z Filipem Goździewiczem (COO) i Krzyśkiem Chudzikiem (CEO i founderem). Sytuacja z jaką zmaga się DM wyglądała interesująco: zdominowali lokalny rynek, rozwiązali jeden (kluczowy) element customer journey, ale mają zbliżający się sufit rozwojowy do przebicia którego potrzebna jest inwestycja w technologię. Firma potrzebowała kogoś, kto wymyśli i wdroży rozwiązania produktowe uniezależniąjace ją od SEO, zwiększając przy tym lojalność warsztatów i kierowców.

Oto kejs rozciągający się na półtora roku mojej pracy dla DM i moje zmagania z tym zadaniem, której finalnym efektem było Zilo, oprogramowanie do zarządzania rezerwacjami w warsztacie samochodowym. Ale zacznijmy od początku

Gdybym był konkurencją…

Na początku kwietnia 2020, po przeprowadzeniu kilkudziesięciu rozmów z kluczowymi pracownikami i warsztatami byłem gotowy do przedstawienia mojej idei rozwoju produktu. Postanowiłem podejść do tematu przybierając rolę potencjalnej konkurencji, która chce zdobyć całkowitą dominację nad rynkiem DM (czego boleśnie doświadczyłem przy PizzaPortal i iTaxi).

Wyobraziłem sobie, że jestem szefem produktu w młodym, dofinansowanym kilkoma milionami $ startupie, bez długu technologicznego, bez zespołu i bez rynku. Jak bym strategicznie podszedł do ataku na DM?

DM to marketplace. Po jednej stronie jest popyt – kierowcy, którzy potrzebują naprawy bądź serwisowania samochodu. Po drugiej podaż – warsztaty, które szukają klientów. Po środku jest platforma technologiczna, która pozwala na łączenie jednych i drugich.

Najsensowniej więc byłoby popatrzeć gdzie są słabe punkty i lewary każdej z części składowych DM.

Kierowca

DM zbudował swoją pozycję na ogromnym doświadczeniu Krzyśka (twórcę i CEO DM) w SEO. Pod względem ruchu to największy serwis agregujący warsztaty samochodowe w Europie (ma tyle odwiedzin co dwóch największych konkurentów łącznie). To w ten sposób kierowcy się o DM dowiadują.

Znaczenie SEO spada z każdym miesiącem, bo Google coraz mocniej monetyzuje ruch organiczny lub, mówiąc inaczej, spycha go w dół kosztem wyników płatnych. Jak to robi? Przez upodobnianie wyników organicznych i płatnych do siebie:

Oraz przez promowanie tzw. „zero-clicków” czyli dawania odpowiedzi bez wychodzenia ze stron Google’a:

Te dwa trendy powodują, że pozycjonowanie jako strategia zdobywania rynku sięga swojego sufitu, a odpowiednio spreparowane kampanie reklamowe mogą osiągnąć lepszy wynik krótkoterminowy niż SEO. Ergo: będąc konkurencją DM nie trzeba się bić contentowo, wystarczą dobrze targetowane kampanie i duży budżet marketingowy.

Rozwój serwisu zoptymalizowanego na SEO ma także inne konsekwencje: najważniejszym użytkownikiem jest google’owy pająk, a nie biologiczny człowiek. Preferencyjne traktowanie miały funkcje zwiększające pozycje na wynikach wyszukiwania, a te związane z czytelnością dla ludzkich gałek ocznych miały drugorzędne znaczenie. Dlatego na stronie głównej DM jest pełna siatka miast i kategorii usług, a nie te dopasowane do oglądającego kierowcy, a na wizytówkach warsztatów lepiej pokazać wszystkie obsługiwane marki samochodów niż posiadaną przez użytkownika.

Nothing personal, po prostu taka była (skuteczna do tej pory) strategia.

W konsekwencji konwersja (rozumiana jako relacja osób rezerwujących wizytę do wszystkich wchodzących) była bardzo niska: zarówno z powodu tego, że DM zbiera dużo „niskokalorycznego” ruchu, jak i UX daje wiele do życzenia.

Platforma

Drugi obszar to serce każdego marketplace’u: platforma. To miejsce spotkania popytu i podaży. Ta „przestrzeń”, której kuratorem jest startup, może być różnie zaprojektowana w zależności od charakterystyki produktu i usługi. Inaczej wyglądają platformy, z których skorzystasz dwa lub trzy razy w życiu (kupno mieszkania), a inaczej te, z których prawdopodobnie będziesz korzystać raz w miesiącu lub częściej (dostawa jedzenia). Do tego dochodzą kwestie różnicy średnich koszyków czy metod realizacji lub dostarczenia usługi/produktu.

W każdym razie możemy analizować jak rozwinięta jest platforma, odpowiadając sobie na pytania jak daleko sięga jej ingerencja (kontrola) w relację między popytem a podażą:

• Czy platforma weryfikuje użytkowników po stronie popytu?
• Czy platforma weryfikuje użytkowników po stronie podaży?
• Czy platforma dynamicznie optymalizuje łączenie popytu z podażą?
• Czy platforma uczestniczy w płatnościach za usługę/produkt?
• Czy platforma stosuje mechanizmy obniżające koszty/czasochłonność transakcji?
• Czy platforma ułatwia realizację usługi / dostarczanie produktu?
• Czy platforma kontroluje jakość świadczonych usług / sprzedawanych produktów?
  

Platformy mają swoje subtelności i nie wszędzie da się przejąć pełną kontrolę nad procesem ze względu na specyfikę rynku. Na przykład OLX zupełnie inaczej wypada w tych odpowiedziach niż Glovo. Niemniej przejście przez te punkty ułatwia sprawdzenie jak bezpieczna jest platforma na wykorzystanie wyłomów w customer journey.

W przypadku DM wcześniej opisana ścieżka rozwoju przez SEO spowodowała, że sam marketplace jest otwarty- nie trzeba zakładać konta, aby podejrzeć wszystkie treści w środku. To znaczy, że wszystkie treści są publiczne, dzięki czemu DM jest wyżej w wynikach wyszukiwania.

Niestety ogromny sukces w SEO spowodował, że ścieżka użytkownika ma dużo dziur, które stały się istotne lata od startu portalu. DM zdobywa klientów przez treści i długi ogon wyników wyszukiwania, następnie użytkownik trafia na listing warsztatów bądź wizytówkę w domenie DM, wybiera usługę i zostawia swoje dane, a DM kontaktuje się z warsztatem i weryfikuje w imieniu klienta dostępność warsztatu. Następnie dochodzi do podstawienia samochodu, naprawy oraz zapłaty (w której DM nie uczestniczy). Na koniec jest ewentualne zostawienie opinii o usłudze przez kierowcę na portalu.

Już na pierwszy rzut oka widać sporo dziur do eksploatacji. Brak kont użytkownika powoduje brak personalizacji, a przez to obniżoną powracalność. Drugą konsekwencją jest brak dynamicznego sortowania warsztatów w zależności od preferencji kierowców (te preferencje DM zna dzięki frazom wpisywanym w Google’u, ale jest to bardzo płytka wiedza). Brak głębszej integracji z warsztatami powoduje, że DM nie może prezentować z dużą dokładnością dat i godzin dostępności warsztatów. Manualne umawianie jest dużym kosztem, który skaluje się liniowo ze wzrostem skali biznesu. Brak pośrednictwa w płatnościach uniemożliwia efektywne stosowanie promocji. Warsztaty rozliczają się płacąc za wyróżnienie swoich usług na listingach więc jest dla warsztatów po prostu kolejnym kanałem marketingowym, a nie istotną częścią biznesu.

Do tego dochodził dług technologiczny (legacy), który nieubłaganie się powiększał z każdym miesiącem. Kod był pełen wyjątków od wyjątków jako konsekwencji doraźnych zmian i dopasowań do dynamiki rynku. Sama struktura i jakość danych także dawały wiele do życzenia. W efekcie jakakolwiek zmiana dotycząca bazy warsztatów, ich dynamicznej agregacji, sortowania bądź filtrowania, była także związana ze sporym dodatkowym narzutem czasu i energii.

Każdy z tych elementów to potencjalny punkt zaczepienia i szukania przewagi konkurencyjnej.

Warsztat

Intensywna dyskusja wśród produktowców zajmujących się marketplace’ami o tym co powinno być pierwsze, popyt czy podaż, została w moim odczuciu ostatecznie rozstrzygnięta przez strategię rozwoju Ubera, Lyfta i fali podobnych startupów: najpierw budujemy podaż, a do niej przychodzi popyt. Więcej na ten temat warto przeczytać w świetnej książce o historii Ubera „Super pumped” Mike’a Isaaca.

W przypadku DM podażą są oczywiście warsztaty oferujące usługi mechaniczne. Dla nich DM jest skutecznym kanałem zdobywania klientów: wizytówka w domenie DM lepiej się pozycjonuje od samodzielnie hostowanej strony, jest łatwiejsza w administracji i zazwyczaj po prostu ładniejsza i łatwiejsza w obsłudze dla klientów. To wszystko jednak nie miałoby znaczenia, gdyby DM nie przynosiło klientów.

Inne działania warsztatów w Internecie jak samodzielne tworzenie kampanii Facebooku czy Google’u lub zlecenie tego agencjom reklamowym nie były tak efektywne. Albo trzeba mieć spore kompetencje i dużo czasu, albo liczyć się z dużym narzutem agencji.

Niestety minus takiego podejścia jest niska lojalność. Jeśli DM dla warsztatu jest po prostu jednym z kanałów reklamowych to szybko go porzucą jeśli na horyzoncie pojawi się nowy, nawet na chwilkę skuteczniejszy, mechanizm. Analogicznie do rynku dostaw jedzenia lub transportu gdzie rabaty i promocje były tak duże, że faktyczne usługi były sprzedawane poniżej kosztów. To popularny sposób zdobywania rynku przez startupy z mocnym finansowaniem.

Dziura do eksploatowania na tym polu to niska lojalność warsztatów. Dopóki DM będzie w oczach właścicieli warsztatów po prostu kanałem marketingowym to ich przywiązanie będzie nikłe –  koszt zmiany na inny kanał także jest niski.

Co teraz?

Diagnoza postawiona, a jakie powinno być leczenie?

Do każdej z tych trzech części przygotowałem listę możliwości, układające się w konkretny backlog.

Kierowca

Uznałem, że najważniejsze jest obniżenie kosztu kognitywnego korzystania z DM. Widziałem takie możliwości w trzech polach:

• UX gdzie znaczenie ma szybkość ładowania, harmonizacja interfejsu, personalizacja, budowanie alternatywnych ścieżek zakupowych,
• Konwersja: zbudowanie presetów procesów bookingowych, rozdzielenie scieżek w zależności od kohort i motywacji (fast-fit vs. złożone naprawy) oraz automatyzacja bookingu,
• Lojalność: potrzebujemy kont użytkowników, w których zbierać się bedzie historia napraw na bazie których będziemy mogli w merytoryczny sposób o sobie przypominać („Hej, widzimy, że czas sprawdzić olej!)

Platforma

w tej części widziałem cztery obszary poprawy:

• Dane gdzie potrzebne jest zapewnie spójności i ustabilizowanie uniwersalnego słownika pojęć (aby odwołanie i anulacja wizyt się żadnemy pracownikowi ani systemowi nie myliła) oraz ostateczne ustalenie, który z systemów jest źródłem prawdy o użytkownikach, naprawach, warsztatach i statusach płatności,
• Matching czyli mechanizmy usprawniające łączenie popytu i podaży, którego centralnym elementem będzie nowy dynamiczny algorytm promujący lepsze jakościowo warsztaty, 
• Ruch w którym zależy mi na przyśpieszeniu renderowania strony, ale także serwowania informacji z naszej bazy do naszych wewnętrznych systemów oraz potencjalnie zewnętrzny dostęp do API).
• Automatyzacja związana z ograniczaniem manualnej pracy wymaganej do procesowania kwestii związanych z wizytami, raportowaniem, księgowością i finansami.

Warsztat

• w tym wypadku moja odpowiedź jest krótka: potrzebujemy Booksy dla warsztatu. Musimy zbudować narzędzie do zarządzania wizytami, które jest proste w używaniu, ma bazę klientów i pozwala na dodawanie wizyt spoza DM. Z kolei DM będzie z tego systemu dostawać informacje o wolnych terminach w warsztatach więc nasza strona będzie miała dokładniejsze dane.

Wszystkie te klocki pięknie ze sobą grały i były od siebie zależne (np. harmonizacja danych wewnętrznych i szybkie ich przesyłanie do API pozwoli zrobić lepszy algorytm; narzędzie do bookingu zmniejszy manualną pracę naszego BOKu itd) i widzieliśmy w środku kilka pozytywnych sprzężeń zwrotnych (lepszy UX -> większa lojalność -> więcej danych -> lepszy UX).

Wiedziałem, żeby to wszystko zrobić potrzebuje dużego zespołu. Naszkicowałem plan na trzy scrumowe teamy na początek – po jednym na Kierowcę, Platformę i Warsztat. Gdzieś w dalszej przyszłości każdy z nich podzieliłby się wewnętrznie na grupę odpowiedzialną za monetyzacje i za wzrost.

Zaprezentowałem moją diagnozę i wnioski przed managementem, wszystkimi pracownikami firmy i inwestorami. Czułem, że mam ambitne zadanie i mnóstwo pracy przed sobą. Chwilę wcześniej dołączył do nas Kamil Kosiński, nowy CTO i mocne wsparcie po stronie technologicznej. Nie wziąłem pod uwagę tylko jednej sprawy – to była połowa marca 2020.

Przycinanie

I wtedy stał się COVID-19. Zamknęli nam szkoły i przedszkola, musieliśmy nauczyć się pracować zdalnie. W moim przypadku dodatkową komplikacją było to, że spodziewałem się za miesiąc dziecka.

Zarząd zareagował szybko. Nie mieliśmy pojęcia jak lockdown wpłynie na nas biznes, więc założyliśmy najgorszy scenariusz. Szybko wprowadziliśmy cięcia wszystkich niekrytycznych wydatków. A nasz dział Produkt+IT musiał pozbyć się dopiero co zatrudnionego pierwszego nowego programisty.

Drogą eliminacji musiałem odchudzić mój plan o 2/3.

Obszar Kierowca został całkowicie zapauzowany. SEO działa i choć UX wymaga poprawy to obecny strumień klientów sugeruje, że tutaj grunt jeszcze nam nie ucieka spod nóg.

Obszar Platforma także został odłożony na półkę z drobnymi wyjątkami – przy okazji innych projektów robiliśmy małe usprawnienia związane z danymi, automatyzacją i płatnościami

Zdecydowaliśmy się skoncentrować na obszarze Warsztat. Taka inwestycja miał najwyższe koszty inicjalne i najdłuższy time to market, ale za to dawała największe nadzieje na transformację biznesową. Dlaczego? Bo miał…

Unfair advantage

Nasze „Booksy dla warsztatów”, w porównaniu do konkurencyjnych programów w branży warsztatowej, miało mieć zasadniczą przewagę: ogromny marketplace za sobą. Łącząc je uzyskujemy całe spektrum nowych narzędzi i pozytywnych sprzężeń wzrotnych:

• Poprawiona widoczność wolnych terminów na portalu, co przekłada się na większy i aktualniejszy inwentarz wizyt do wykorzystania dla klientów, to daje lepszy UX, a to daje więcej klientów. Więcej klientów to więcej chętnych warsztatów do skorzystania z naszej oferty. A to daje nam więcej warsztatów korzystających z naszego programu,
• Więcej warsztatów z naszym softem to skrócony czas obsługi manualnej zleceń, co obniża koszt jednostkowy zlecenia, co pozwala mieć lepszą marżę, co daje większy budżet na zdobywanie nowych warsztatów korzystających z naszego softu,
  
• Więcej warsztatów korzystających z naszego systemu do bookingu to mniejsze ryzyko rezygnacji z naszych usług, co oznacza zwiększenie lojalności, a to poprawiony Life Time Value i obniżony średni Customer Aquisition Cost. To z kolei pozwola na większe inwestowanie w skalowalne technologie

Równie ciekawe są też sprzężenia zwrotne po stronie warsztatu: zaczynając od łatwiejszego zbierania danych swoich klientów co pozwala na obniżenie średniego kosztu zdobywania nowego klienta, co daje miejsce na atrakcyjniejsze akcje marketingowe, co zwiększa liczbę klientów.

Poza oczywistym argumentem przesyłania kierowców od naszego marketplace’u do naszego systemu rezerwacji wizyt było kilka dodatkowych argumentów dających nam przewagę nad czystymi narzędziami bookingowymi. Na przykład mamy ogromną bazę historycznych wizyt już zrealizowanych dla warsztatów które są na naszej platformie. Te wszystkie dane, poukładane i łatwo wyszukiwalne, mogą być oddane warsztatom jako ich własna baza klientów. To robi mocny efekt wow.

Do tej pory większość warsztatów zarządza wizytami korzystając z papierowego kalendarza lub ze skomplikowanego systemu warsztatowego, w którym widok kalendarza był dodatkiem (a głównym ekranem to dodawanie zlecenia i zarządzanie magazynem części). Dla tych pierwszych warsztatów wartość będzię wynikać z pokazania się jako nowoczesny przybytek (wiedzieliśmy, że właścicielom dobrych warsztatów trochę wstyd gdy korzystają z papieru) oraz z możliwości szybkiego wyszukiwania historycznych wizyt i powracających klientów i samochodów. Dla tych ze skomplikowanymi systemami wartość będzie leżała w czymś innym: prostocie i elastyczności.

Mieliśmy zupełnie inną sieć wartości niż reszta komercyjnych produktów na polskim rynku. Dla tych najpopularniejszych najważniejsze było sprzedawanie części, a sama obsługa zleceń było dodatkową, a nie centralną funkcją. Inni sprzedawali cały zamknięty ekosystem, który zachowywał się w podejrzanie podobny sposób do programów księgowych. Większość z nich pobierała opłaty za wykorzystane stanowiska pracy bez powiązania z tym jak dużo wizyt przez nie przechodzi (nie mają więc spójnych motywacji ze swoimi klientami). Nasz biznes z kolei opiera się na generowaniu nowych wizyt dla warsztatów, więc nie przeszkadza nam, że nasz program może być oferowane za darmo lub po bardzo niskiej cenie.

Kickoff!

Kamil (CTO) wrócił do roli programisty, nasz CEO Krzysiek pełnił także rolę supportu technicznego, nasz senior developer Paweł był także devopsem i adminem. A ja szefem produktu, product ownerem, scrum masterem, grafikiem, uxowcem i analitykiem jednocześnie. W takim mikroskopijnym zespole, nie widząc się na żywo przez 95% czasu musieliśmy stworzyć nowy produkt i utrzymać te, które już mamy. Jak to zrobić?

Stało przede mną zadanie stworzenia produktu od zupełnego początku. W odróżnieniu od PizzaPortal i iTaxi, gdzie moim głównym zadaniem było stworzenie nowej wersji na bazie już istniejących produktów. Z jednej strony ta sytuacja dawała mi dużo wolności, a z drugiej więcej niepewności i mniej danych na temat tego co już działa, a co nie.

Na powierzchni taki system rezerwacyjny wydaje się prosty. Mogłem go sobie rozrysować z głowy na podstawie doświadczeń użytkownika Booksy, czy ZnanegoLekarza.

Zacząłem od podstaw wspólnych dla każdego systemu bookingowego:

1. Fundamentalnym klockiem jest wizyta – czas w którym zrealizowana jest usługa,
2. Wizyty dzieją się na przecięciu dwóch osi: czasu i stanowisk (foteli fryzjerskich, gabinetów, podnośników samochodowych, itp.),
3. Obydwie osie mają swoje ograniczenia: godziny dostępności i liczbę stanowisk. Im więc większa liczba wykonanych usług w ramach tych ograniczeń tym większa efektywność.

Mam więc swoje wymagania graniczne. Co pod to pasuje?

Oczywiście kalendarz. Ten jednak jest zazwyczaj tworzony z perspektywy jednego użytkownika (który jest jedynym zasobem). Oś czasu więc zajmuje całość. A co z osią zasobów (stanowisk)? Co powinien mieć każdy taki system? Zarządzanie stanowiskami, zarządzanie pracownikami i zarządzanie klientami. Później konto użytkownika, pod którym ukryte są ustawienia.

Z tego wszystkiego najważniejsze będzie zarządzanie stanowiskami. To ten ekran będzie główny, to ten będą warsztaty codziennie (miałem wtedy nadzieję) otwierać zaraz po włączeniu komputera i przeglądarki.  I tutaj pierwsza decyzja: muszę zrezygnować z poziomej osi dni/tygodni/miesięcy i w to miejsce wstawię stanowiska. 

Wolne szkicowanie, bez zastanawiania się nad szczegółami pozwala poukładać myśli lepiej niż dowolny brief czy specyfikacja.

Ten ekran dał początek reszcie i ustawił strukturę, którą kaskadowo dziedziczyły kolejne ekrany i funkcje.

Po niecałych trzech miesiącach, w połowie lipca 2020 mieliśmy fundamenty architektury, prostą frontendową skórkę kupioną na ThemeForest oraz renderowanie kalendarza dzięki bibliotece FullCalendar. 

Pierwsza wersja miała ogromne ograniczenia. Nie pozwalała na dodawanie nowych wizyt ani oglądanie ich szczegółów, a każda wizyta musiała trwać dokładnie godzinę. Ale ważne było to, że wreszcie mieliśmy coś, co zaczyna wyglądać jak początek realizacji naszej wizji.

Biorąc pod uwagę tempo i wielkość zespołu zdawaliśmy sobie sprawę, że to co robimy to proof of concept. Lepimy wszystko na taśmę i gdzieś w przyszłości czeka nas czas spłacania ogromnego długu technologicznego. Kamil powtarzał to dosadniej co jakiś czas:

Marcin, ale pamiętasz, że to wszystko trzeba wywalić i napisać kiedyś jeszcze raz?

Tak, pamiętałem. Ta myśl wisiała nade mną przez całe półtora roku projektu.

Jednak nie kalendarz?

W sierpniu 2020 doszliśmy do wniosku, że idea oparcia zarządzania warsztatem o kalendarz jest błędna. Dopiero po przetestowaniu naszego prototypu zrozumieliśmy, że nie oddaje on istoty problemu z jak zmagają się warsztaty. Okazało się, że analogia do Booksy i DocPlannera jest niewystarczająca z kilku powodów:

• Kierowca planuje wizytę nie dla siebie, a dla swojego samochodu. W odróżnieniu od fryzjera czy lekarza klient nie uczestniczy w kluczowej części świadczenia usługi,
• Wizyty w warsztatach dzielą się na dwa diametralnie różne typy: szybkie powtarzalne usługi (tzw. fast fit tak jak zmiana opon) i długotrwałe, wieloetapowe naprawy (np. naprawa rozrządu)
  
• Dla kierowcy termin wizyty jest równy terminowi podstawienia samochodu do warsztatu (tak jak termin wizyty do dentysty jest równy wykonaniu terminowi wykonania usługi dentystycznej). Faktycznie jednak warsztat może długo zwlekać z usługą –  na przykład przez brak części.

Jak sobie z tym poradzić? Statusy. Bardzo długo zwlekałem z ideą ich wprowadzenia, bo bałem się, że podwyższy kognitywny i organizacyjny koszt korzystania z naszego softu. Poza tym nie wiedziałem do końca w jakim celu warsztaty miałyby dbać o to, aby zmieniać statusy zleceń zgodnie z rzeczywistością. Udawało im się przeżyć bez tego do tej pory więc po co mają pamiętać dodatkowo, aby coś przestawić w naszym narzędziu? Jaki mają mieć w tym interes?

Wtedy do mnie dotarło: co warsztaty lubią robić? Naprawiać samochody. Czego warsztaty nie lubią robić? Rozmawiać z klientami. Powiązaliśmy więc zmianę statusu z wysyłką powiadomień do klientów. Dzięki temu jeśli w naszym systemie wizyta zmienia status na „Naprawione” to właściciel zostanie o tym poinformowany przez SMSa i maila. To powinno pomóc w przekonaniu warsztatów do korzystania ze statusów.

Druga rzecz to nasze bardzo liberalne podejście. Intencjonalnie mamy tylko cztery: „nowe”, „przyjęte”, „naprawione” i „zakończone”. Jak widać nie ma, wydawać by się mogło, oczywistego statusu „w trakcie naprawy”. Wiedzieliśmy, że nie możemy zbyt mocno narzucać warsztatom procesu. Nam, z zewnątrz, wydaje się on logiczny, ale jesteśmy teoretykami. A praktyka lubi płatać figle teorii. Zostaliśmy więc przy absolutnym minimum – poczekamy i zobaczymy jak się przyjmą.

Trzecia rzecz, która do nas dotarła, że ustawianie wizyty w kalendarzu to tylko część procesu. Powinniśmy mieć też dwa dodatkowe worki: jeden dla wizyt, które jeszcze nie mają swojego terminu i stanowiska. Oraz drugi na samochody czekające na odbiór po wizycie. Jak to dodać do obecnego paradygmatu kalendarza? To zupełnie nie pasuje, bo wizyty niezaplanowane z natury nie mają swojego miejsca w kalendarzu, ale powinny być widoczne, aby móc je do kalendarza przenieść. Z kolei samochody naprawione nie powinny być w ogóle widoczne w kalendarzu – muszą mieć oddzielną sekcje, aby nie mieszały się z tymi w trakcie napraw.

W ten sposób powstała kolumna niezaplanowanych na lewo od kalendarza i zakładka „Do odbioru” w głównym menu.

Sprawy zaczynają się komplikować. Było widać początki końca radosnej twórczości, a w jej miejsce wyłaniał się wewnętrzny zestaw zasad determinujący logikę kolejnych funkcji.

Zaczęło do mnie docierać jak dużo pierwotnych założeń musiałem zrewidować. Przechodziłem przez ten proces już wiele razy przez ostatnie (ponad!) 10 lat, ale za każdym razem mnie to zaskakuje. Choć przecież to najbardziej oczywista rzecz w tej robocie.

Upraszczanie przez komplikowanie

Moja niechęć do komplikowania szybko stopniała, gdy okazało się, że komplikując system „podskórnie” możemy upraszczać interakcję z użytkownikiem.

Tak jak się spodziewałem wprowadzenie wymiaru statusów wprowadziło dodatkowy poziom złożoności. Czy wizyta może zmieniać status z dowolnego na dowolny? No nie, to by było generowało dużo problemów. A więc może progresja może być tylko w jedną stronę: od „Nowe” do „Zakończone”? Ok, a co z przypadkami, kiedy warsztat naprawił, a klient przychodzi z reklamacją? Ah, to pozwolimy na możliwość cofnięcia się z „Naprawione” na „Przyjęte”…  i tym podobne wewnętrzne dialogi nurtowały mnie przez większość trwania projektu.

Mamy już kalendarz i statusy. Zajmijmy się dodawaniem wizyty – podstawowego procesu w tego typu systemach. Weźmy na warsztat prostą historyjkę i zobaczmy jak szybko wszystko się komplikuje:

Kierowcy psuje się coś w samochodzie. Dzwoni do warsztatu, aby umówić się na wizytę. Doradca klienta spisuje szybko jego dane do (naszego) systemu wraz z opisem usterki i ustalają termin podstawienia przyjazdu.

Proste prawda? To pogrzebmy trochę.

Czy ten kierowca był już kiedyś w naszym warsztacie? Jeśli tak, to powinniśmy szybko móc go odnaleźć i wstawić jego dane w formularz. To ważne, bo jeśli dodamy go jako „nowego” mimo, że już u nas był, to będziemy mieć duplikacje danych, która w dłuższym okresie generuje straszne problemy organizacyjne, nie mówiąc o marketingowych.

Z drugiej strony: jeśli klient jest u nas po raz pierwszy to musimy mieć flow z mocną walidacją danych, aby uchronić bazę klientów przed drugim problemem: szumem i brakiem struktury. Trzeba to jednak zrobić tak, aby zachować balans między jakością danych, a szybkością ich wpisywania. Zbyt dużo przeszkadzajek spowoduje, że doradca w warsztacie przestanie używać systemu, bo uzna go za zbyt trudny. Trzeba pamiętać, że te dane będą dodawane w trakcie rozmowy telefonicznej.

Mamy więc dwie różne userflows w zależności od tego czy klient jest nowy czy powracający… ale czy możemy ufać ludziom, że dobrze wybiorą? Możliwe, że klient nieomyślnie wprowadza doradce w błąd: mówi, że już był/ nie był w warsztacie, ale warsztaty mu się pomyliły. Dlatego system w userflow nowego użytkownika weryfikuje po wpisywanych danych istnienie użytkownika i w przypadku znalezienia przenosi do flow „Powracającego” – i odwrotnie: w przypadku braku danych użytkownika powracającego można szybko przenieść się do flow „Nowego”.

Szybko zaczęły się pojawiać nowe komplikacje. Jak szybko wyszukać już istniejącego klienta? Baza klientów w warsztacie nie jest duża – te najlepiej posperujące mogą liczyć na 1-2-3 tysiące rekordów. Można więc zastosować uniwersalną wyszukiwarkę po wszystkich polach (a nie jeden inputfield na imię i nazwisko, drugi na nr telefonu, trzeci na nr rejestracyjny itd.

Dzięki uniwersalnej wyszukiwarce doradca wpisując „Ford” powinien znaleźć wszystkie samochody Ford w swojej bazie jak i Ferdynanda Forda, jeśli ten się akurat w tym warsztacie serwisował.

Gdy już to rozłożyliśmy na części pierwsze to Kamil, dał mi nową historyjkę:

Wyobraźmy sobie, że jestem powracającym klientem tego warsztatu, ale przyjeżdżam nowym samochodem.

Doradcy w warsztatach najszybciej wyszukują po numerach rejestracyjnych więc gdy tak spróbują to baza będzie pusta, ale klient przecież już jest więc tworząc nowego mielibyśmy duplikat.

Co teraz?

Na tego typu problemy logiczne trafialiśmy ciągle i radziliśmy sobie na dwa sposoby:

1. Rozwiązywaliśmy w sposób, który w naszej ocenie będzie najprostszy dla użytkownika systemu,
2. Ignorowaliśmy jeśli problem wydawał nam się mało istotny, tj. oddalony od podstawowej funkcji systemu. Tutaj trafiło większość problemów.

Aby więc ułatwiać procesy z perspektywy użytkownika systemy mocno go komplikowaliśmy wewnętrznie. Logika się rozrastała, ale interfejs nie. Najważniejsze, aby trzymać w ryzach narzut kognitywny.

Oto Zilo

Równoległe do rozwoju funkcji systemu trwały dyskusje o tym jak pozycjonować nasz nowy produkt. Czy to ma być samodzielny system, niezależny od DM, a może dodatkowa marka pod wspólnym parasolem? Od tych decyzji zależy czy:

• produkt który ma mieć własną nazwę, być „powered by” czy też traktujemy go bardziej jak funkcję DM,
• uwzględniamy go w cenniku DM, sprzedajemy w pakiecie, czy też niezależnie,
  
• czy ma mieć własną nazwę i branding

Aby ustrukturyzować dyskusję zdecydowałem się skorzystać z uproszczonej wersji Impact Estimation Table jako narzędzia do podejmowania decyzji. Wypisaliśmy tam 7 najlepszych ścieżek, takiej jak:

• System bezpłatny, dostępny dla wszystkich warsztatów,
  
• Fremium dla wszystkich,
• Płatny tylko dla nowych kierowców (wpisów w bazie),

Oraz 9 najważniejszych wartości, które mają znaczenie dla naszego biznesu. Między innymi:

• Łatwe wprowadzenie systemu do warsztatu,
• Zwiększenie przychodu warsztatu,
• Wzmocnienie efektu sieciowego,

Następnie wspólnie ustaliliśmy jaki wpływ każdy z modeli ma na nasze wartości. Na początku września 2020 dostaliśmy wynik: na początek najlepszy model to pakietowa sprzedaż, w którą wchodzą dwa produkty: Wizytówka na DM oraz dostęp do systemu bookingowego, który jest niezależnym bytem.

Zdecydowaliśmy się nazwać nas system „Zilo”, co w sumie nic konkretnego nie znaczy (dla ciekawskich to „niebieski” po łotewsku), ale jest krótkie, proste do wymówienia nie tylko w języku polskim, a do tego ma wolną domenę .co. Marcin Jodłowski, nasz szef marketingu testował odbiór  nazwy Zilo wśród warsztatów pracowników i wykluczył jej negatywne konotacje, które mogły być dla nas nieoczywiste. Następnie do nazwy doszusował branding i paleta kolorystyczna, czekająca aż do początku 2021 na wdrożenie.

MVP1

Pierwsza minimalna wersja Zilo miała konkretny cel: grupa dwóch pierwszych warsztatów przejdzie przez nasze wdrożenie i zacznie korzystać z systemu . W tym czasie my zbierzemy ich odczucia i wyciągniemy wnioski co robić dalej.

W połowie listopada 2020 stanęliśmy przed decyzją: startować jeszcze w 2020 roku czy przeczekać okres świąteczny i wystartować na początku stycznia 2021?

Wysłałem wtedy maila o takiej treści (z delikatną redakcją)

Hej,
Jesteśmy teraz w połowie sprintu 20. Sprint 21 zaczyna się 24 listopada i kończy 8 grudnia. Uważam, ze jest szansa, że moglibyśmy wystartować 1-2 chętne warsztaty 8 grudnia lub kilka dni później. Chciałbym jednak żebyśmy się wspólnie zastanowili, czy to już odpowiedni moment. Jestem zainwestowany w rozwój SaaSa, wiec potrzebuje zewnętrznej opinii. Poniżej moje myśli na ten temat, dajcie znać co uważacie:

Argumenty za startem 8 grudnia:
1. szybko zaczniemy testować i zdobywać pierwszy rynkowy feedback
2. grudzień będzię spokojnym miesiącem więc będzie więcej czasu na testy po stronie warsztatu (i mniejsza strata jak coś się mocno popsuje)
3. Po stronie BOKu DM też będzie spokojnie więc narzut dodatkowej pracy obsługi SaaSa będzie łatwiej akceptowalny

Argumenty przeciw:

1. wystartujemy z produktem z dużymi niedoborami w zakresie integracji między Adminem i SaaS (obsługa bookingów online)
2. wystartujemy z produktem, któremu brakuje wielu istotnych funkcji więc możemy do siebie zrazić pierwszych użytkowników
3. wystartujemy w momencie ograniczonego dostępu do supportu IT po tygodniu od startu – święta i sylwester.

Co o tym sądzicie?

Irytowała mnie wizja startowania z tak okrojonym produktem. Coś mi w środku mówiło, że to będzie wstyd pokazać taką poczwarkę i liczyć na to, że ktoś zacznie z tego korzystać. Lista braków była… stresująca.

Wyobrażacie sobie wodować produkt w kategorii zbliżonej do CRMa bez przeglądania bazy klientów? Ba, bez możliwości dodawania nowego klienta (jeśli nie idzie w parze z nowym zleceniem). W samym kalendarzu nie było opcji zmiany długości wizyty – każda musiała trwać dokładnie 30 minut. Nie mówiąc już o tym, że nie istniało automatyczne tworzenie i konfigurowanie nowych kont (musieliśmy to pod spodem robić ręcznie, łącznie z dodowaniem logotypów warsztatów i ustawianiem liczby stanowisk). Albo tym, że ze względu na brak czasu nawet jeszcze nie wdrożylismy brandingu ani nowej nazwy systemu… No cóż, nie da się nie wstydzić pierwszej wersji swojego produktu.

Konsensus zapytanych w mailu osób był taki, że nie możemy czekać całego miesiąca zanim zdobędziemy pierwsze reakcje. Musimy zderzyć się z rynkiem i wyciągać szybko wnioski. To, co już mamy jest wystarczające do zwalidowania podstawowej idei, a to czego nie mamy będziemy dorabiać w następnych sprintach albo robić manualnie.

Bałem się takiej odpowiedzi, ale wiedziałem, że to słuszna rekomendacja.

9 grudnia 2020 wdrożyliśmy pierwszy prawdziwy warsztat w Zilo. Rafał – opiekun naszych najlepszych warsztatów – pojechał do warsztatu i wraz z doradcą klienta połączył się ze mną na Google Meet. Zestresowany poprosiłem o to, żeby udostępnił mi swój ekran i kliknął na link ze wcześniej przygotowaną dla niego wersją Zilo. Obok miałem otwarte okno z Kamilem, który w nocy dogrywał ostatnie rzeczy oraz Moniką (szefową obsługi klienta), na wypadek gdyby coś nie zadziałało.

Ale zadziałało! Przez ponad 30 minut przeprowadzałem przez poszczególne elementy naszego rozwiązania. W międzyczasie przyszedł do warsztatu kierowca i mój rozmówca obsłużył go korzystając z Zilo, a ja patrzyłem na pierwsze prawdziwe zlecenie na żywo. Dla takich momentów warto być produktowcem.

Tydzień później zrobiliśmy drugie wdrożenie. Później jeszcze kilka razy rozmawialiśmy z testerami i pytaliśmy o wrażenia. Tuż przed świętami mieliśmy pewność, że to, nad czym pracowaliśmy przez ostatnie pół roku faktycznie działa i na ten moment jest wystarczająco dobre mimo mojego pierwotnego sceptycyzmu. Ten wstyd siedział tylko mi w głowie.

Etap MVP1 uznałem za zakończony. Między świętami a sylwestrem rozpocząłem układanie backlogu kolejnej wersji.

MVP2

Pierwsze zetknięcie produktu z prawdziwym użytkownikiem zawsze jest otrzeźwiające: tam gdzie my myślimy o górnolotnych ideach, oni sprowadzają nas na ziemie wymagając, oczywistych z perspektywy czasu, funkcji. Zebrałem je wszystkie w jednym miejscu po starcie MVP1 i zderzyłem z moim wewnętrznym planem rozwoju Zilo.

Cel MVP2 był równie konkretny co pierwszej wersji: dowolny warsztat może zacząć korzystać z Zilo. Kluczowe tutaj słowo to „dowolny” – to znaczy, nie tylko taki, który jest nam przychylny i zainwestuje trochę czasu bo nas lubi, ale także ten „z ulicy”. Zilo ma się bronić samo. Styczeń, luty i marzec to czas aby to osiągnąć.

Zacząłem z całej góry funkcji usuwać nie pasujące do celu. Po eliminacji zostało pięć zadań, które nas do tego doprowadzą i byłem pewien, że damy radę je dowieźć w Q1:

• Mamy ekran Klientów
• Mamy ekran Statystyk
• Mamy wdrożony nowy branding i design Zilo 
• Mamy wdrożone prawdziwe konta użytkowników
• Mamy zautomatyzowany onboarding warsztatów
  

Dodawanie nowych ekranów poszło nam względnie bezproblemowo, więc pierwsza część kwartału była spokojna. Aby jeszcze przyśpieszyć zdecydowałem, aby wykorzystać konkurs na 99designs w celu wyłonienia grafika do stworzenia wyglądu Zilo spójnego z brandingiem. Cały proces poszedł sprawnie i wybraliśmy najlepszą propozycję, ale ostatecznie osoba, na którą się zdecydowaliśmy nie była wystarczająco responsywna. Z mojego doświadczenia 99designs nadaje się dobrze na szybkie i proste projekty, które nie wymagają długiego procesu nauki i iteracji na żywym organizmie (jak ulotki, wizytówki, logosy). Zdecydowałem się zacząć od początku, tym razem samodzielnie.

Uznaliśmy więc, że czas znów szukać. Po zebraniu rekomendacji z mojej siatki znajomych i pierwszych kontaktach miałem 16 chętnych. Do finału dotarły cztery. Ostatecznie zdecydowałem się na współpracę z Rewire Studio.

Ich propozycja mnie przekonała, bo była przemyślana pod dalszy rozwój produktu. Nie skupiała się jedynie na ładniejszej interpretacji status quo, ale antycypowała wprowadzanie wersji mobilnej, następnych funkcji, innych stanów i statusów już istniejących obiektów. Słowem wiedziałem, że stoją za tym ludzie, którzy mają doświadczenie, a więc rozumieją, jakie ich designerskie decyzje mają konsekwencje w przyszłości.

Za ich namową zrezygnowaliśmy z popupu z dodawaniem/szczegółami wizyty na rzecz sidebara. To spowodowało, że aktywne okno nie zasłania całego kalendarza i o wiele łatwiej jest całość złamać po wersję mobilną. Polecam, wysokiej klasy specjaliści.

Największym problemem ze wszystkich zadań okazały się konta użytkowników. Do tej pory tworzyliśmy nowe instancje Zilo manualnie, ale teraz, jeśli chcemy być gotowi do skalowania i udostępniania naszego systemu wszystkim warsztatom to musieliśmy przygotować się do głębszej integracji z panelem BOKu, wdrożenia bezpiecznych procesów rejestracji, logowania, nadawania i wysyłki haseł. Choć są to znane wzorce to jednak liczba scenariuszy była długa. Do tego dochodzi klasyczny problem integracji między silosowymi systemami: różniące sie wewnętrzne definicje oraz niemapujące się stany generowały dużo wyjątków i potrzebę translacji i mediacji zarówno na poziomie biznesowym jak i developerskim.

Z drugiej strony widzieliśmy, że względnie mało wizyt dodawanych jest do Zilo mimo naszych działań aktywizacyjnych. Rozmowy z testującymi warsztatami dały odpowiedź: „my tak nie rozmawiamy z klientami”. Nasz formularz dodawania wizyty, choć wydawał się prosty z obsłudze dzięki podpowiedziom i walidacjom, nie odzwierciedlał tego jak doradca klienta rozmawia z kierowcą: nikt nie chce podawać mnóstwa alfanumerycznych danych przez telefon. Dotarło do nas, że możemy to uprościć dzieląc formularz na dwie części: minimum informacji na początku (numer telefonu i powód wizyty) i uzupełnienie reszty jak już kierowca przyjedzie do warsztatu (marka, model, adres mailowy, cena itp). Dzięki temu rozmowy bardziej naturalny przepływ, a obsługa klientów szybsza.

W między czasie zwiększyliśmy liczbę testerów Zilo do 25 warsztatów. To pozwoliło rozszerzyć różnorodność warsztatów na te, które były niedoświadczone z podobnymi systemami, przez te które mają rozwiązania all-in-one dla całego biznesu. Mieliśmy także większe spektrum reakcji: od tych, którzy od raz odrzucili Zilo, przez tych, którzy mieli mieszane uczucia, ale korzystali, aż do poweruserów.

Niezależnie jednak od kontekstu właściciele warsztatów mieli mnóstwo pomysłów na kolejne funkcje – nazbieraliśmy ich ponad 60. Finalnie do wersji MVP2 weszło 8 z tej listy.

Ostatnia prosta

W styczniu 2021 założyłem, że jesteśmy w stanie zrobić cały pakiet do końca kwartału. Na początku marca jednak okazało się, że klocków do poukładania, jak zwykle, jest więcej niż pierwotnie zakładałem: z początkowych 5 zrobiło się 16 o różnej skali wielkości. Produkt to zawsze więcej niż sam <produkt> – to także całe jego otoczenie.

Wiedziałem już, że na wyrobienie się w na koniec kwartału nie ma szans. Ale gdybyśmy zwodowali projekt dwa tygodnie później, 13 kwietnia 2021, to wciąż będzie dobry wynik… Aby jednak to się udało musiałem znów okroić cały projekt.

Nic z tych rzeczy nie było trudne; problem polegał na tym, że były pracochłonne i wymagały ciągłego zmieniania kontekstu. Zacząłem od wycięcia wszystkiego co było nice to haves jak wersja demo. Kwestie prawne wydelegowałem poza mój zespół, landing page zdecydowaliśmy się zrobić w landingi.com zamiast samodzielnie kodować, obsługę multikont usunęliśmy całkiem, dodatkowe maile informujące przerzuciliśmy na sprint po starcie…

W ten sposób lawirując między tym, co konieczne, a tym co tylko się wydaje że konieczne, po jeszcze jednym przesunięciu startu ze względu na odkryte w testach problemy z integracją między systemami, udało nam się wreszcie zbudować finalną paczkę MVP2.

20 kwietnia 2021 późnym wieczorem zrobiliśmy release łączący ostatecznie Zilo z resztą naszych systemów a ja napiłem się wreszcie symbolicznej szklaneczki whisky, która czekała na ten moment już od miesiąca. Dzień później, gdy byłem już pewny, że nic nie wybuchło, wysłałem maila do całej firmy, że wreszcie, po ponad roku, osiągnęliśmy nasz cel.

Jak pracowaliśmy

Zanim pojawiłem się w DM, osobą która zarządzała backlogiem był CEO. Wymagania były trzymane w Github Board, w kilku niezależnych tabelkach Google Sheets i w ustaleniach mailowych.

Pierwszą moją decyzją było postawienie podstawowej wersji Jira Cloud oraz skonsolidowanie wszystkich wymagań w jednym miejscu.  Pierwszy ticket dodałem jeszcze w lutym 2020. Założyliśmy tam konta dla całego IT+Produkt i najważniejszych interesariuszy oraz przenieśliśmy wszystkie aktualne zadania do backlogu w Jirze. Standardowo też ogłosiliśmy, że od tej pory ja staje się SPOC (Single Point of Contact) jeśli chodzi o zmiany w produkcie. Ticket numer 1000 świętowaliśmy 20 kwietnia 2021, trochę ponad 14 miesięcy później. To daje średnio 14 nowych ticketów dziennie (licząc dni robocze).

Szybko dotarłem do porozumienia z CTO i określiliśmy wspólnie podział obowiązków: ja mówię „co”, Kamil mówi „jak”. Oznaczało to, że ja jestem warstwą pośrednią między wymaganiami pochodzącymi z zewnątrz działu IT/Produkt i decyduję, co powinno być na górze backlogu. Kamil z kolei ma na swojej głowie, które wybrać technologie i architekturę, jakie mamy procesy produkcyjne, jak releasujemy i tym podobne procesowe kwestie.

To był pierwszy projekt, który w praktyce w całości przeprowadziłem zdalnie. Raz siedząc w lesie, do którego uciekliśmy z rodziną przed pandemią, raz w warszawskim mieszkaniu. Codzienne żonglowanie obowiazkami domowymi, rodzinnymi i zawodowymi było cholernie trudne: zdarzało się, że przed kamerką pojawiałem się z młodszym dzieckiem w nosidle, a inne odbywałem pchając wózek przez park.

Generalnie dzieciom było wszystko jedno, że miałem ważny projekt na głowie więc starałem się układać dzień tak, aby jak najwięcej zrobić gdy śpią lub gdy starsze jest w przedszkolu (jeśli akurat nie ma kwarantanny bądź lockdownu)

To była ciągła walka z wiatrakami i puzzle których rozwiązanie zmieniało się każdego dnia: czasami dzieci nie spały do późnej nocy więc wieczorna praca odpadała, a za krótko spałem, aby wstać bladym świtem i głęboko popracować (wolałem się wyspać – polecam, to dobry lifehack). Czasami nam zamykali przedszkole więc znów trzeba zmieniać rozkład dnia… Nic tak nie uczy fundamentalnej zasady inspect&adapt jak dzieciaki podczas pandemii.

Po ponad 20 wspólnych sprintach poczułem, że wreszcie wypracowaliśmy sobie dobre rutyny:

• Zawsze o 10:15 mieliśmy daily meeting. Na pytanie „dlaczego tak późno?” odpowiadam: bo ludzie mają dzieci, które trzeba odstawić do szkół i przedszkól i jeszcze zjeść spokojnie śniadanie,
• Zaraz po daily robiliśmy jednogodzinny Refinement. W zależności od sytuacji między dwa a pięć razy na dwutygodniowy sprint. Idealnie byłoby omawiać na nich zadania na kolejny sprint, ale rzadko nam się udawało. Zazwyczaj na tapecie były niedokoładnie przeze mnie opisane tickety, które właśnie mieliśmy developować,
• W co drugie wtorki mieliśmy Review i Planning. Pierwotnie Retro mieliśmy w poniedziałki przed startem nowego sprintu, ale ostatecznie zdecydowaliśmy się je robić w środy, dzień po starcie sprintu – wyszło nam, że na koniec sprintu wszyscy są zbyt skupieni na zakończeniu swoich zadań, aby przestawić swoje głowy na myślenie o tym jak zespół może działać lepiej,
• Wprowadziliśmy system wyceny złożoności zadań oparty na  potęgach dwójki (1, 2, 4, 8, 16, 32 punkty) gdzie każde następne zadanie to skala wielkości wyżej. Niestety po jakimś czasie okazało się, że mamy bardzo duże wahania liczby punktów robionych na sprint więc po kolei ścinaliśmy skalę: na początku nie przyjmowaliśmy zadań za 32 punkty, następnie 16, później 8, aż Kamil zasugerował limit 4 punktów jako maksimum, aby już nigdy nie usłyszeć stwierdzenia na daily: „ja dzisiaj kontuuje wczorajsze zadania”. Pierwotnie byłem sceptyczny, ale okazało się, że to działa perfekcyjnie. Jedyny minus jest taki, że pojawia się na sprint backlogu tak dużo zadań, że ciężko je ogarnąć jednym spojrzeniem,
  
• Releasy zazwyczaj robiliśmy zaraz po zakończonym sprincie, około 21:00. To idealna pora: warsztaty już nie pracują, a dzieci śpią.

Tak ułożyliśmy pracę zespołową, natomiast ja jeszcze miałem dodatkowe punkty:

• Gdy miałem na sobie natężoną pracę koncepcyjną lub analityczną – na przykład projektując nowe ekrany lub planując nastepne sprinty-wstawałem o 6:30, aby móc w ciszy stworzyć nowe makiety i tickety.
• Spotkania z interesariuszami, które nie wymagały oglądania siebie w kamerkach, ustawiałem na 12-13:00 – tak, aby móc rozmawiając jednocześnie pchając wózek z dzieckiem przez park

Kilka dodatkowych przemyśleń:

• Tickety w Jirze przez cały projekt nie trzymały wysokiego standardu jakościowego. To był ciągły „work in progress” – odkrywaliśmy na bieżąco nowe wymagania oraz drugie dna i modyfikowaliśmy zadania z dnia na dzień. Niemniej nieporozumienia zdażały się niezwykle rzadko – to przywilej pracy z prawdziwie doświadczonymi programistami w małym zespole,
• Bardzo trudno jest przeprowadzić dobrą Retrospekcję zdalnie. Dopiero gdy Żona pokazała mi Mural służący do wspólnej pracy kreatywnej udało nam się odtworzyć atmosferę panującą podczas dobrego retro, gdy ludzie faktycznie zastanawiają się co mogą jako zespół robić lepiej.

Naszym podstawowym narzędziem była Google Meet. W większości przypadków w trakcie telekonferencji miałem otwartą Jirę – zespół pracował na wersji webowej a ja naprzemiennie w aplikacji iOS na iPhonie i iPadzie. Makiety, standardowo już, robiłem w Goodnotes a później łączyłem w klikalne wersje w Marvelu.

Gdy opadł kurz

Nasz release miał duże konsekwencje dla innych działów: sprzedaż musiała wdrożyć nowy cennik (w którym Zilo ma kluczowe miejsce) oraz nauczyć się nowych skryptów; dział obsługi klienta nauczyć się Zilo i pomagać warsztatom, które korzystają z niego po raz pierwszy.  Zmiany tych procesów i cenników zajęły nam kolejny miesiąc.

Raz na jakiś czas robiłem sobie odsłuchy rozmów wdrożeniowych Zilo i to co mniej najbardziej ucieszyło to fakt, że udawało się przeprowadzić warsztat przez cały proces podczas normalnej rozmowy telefonicznej, czasami nawet bez screensharingu (przypomnijcie sobie ile frustracji wywołuje instruowanie własnych rodziców co mają kliknąć rozmawiając przez telefon…).

Dwa miesiące po starcie do Zilo zostało dodanych 1000 wizyt. Bez ani jednego krytycznego błędu i z mikroskopijną listą błędów technicznych.

Wszystko wyglądalo na to, że dobiegliśmy do mety. Z tym, że dobrze wiedzieliśmy, że ta meta jest symboliczna. Praca nad produktem nigdy się nie kończy.

Już pukała do nas nasza kancelaria z listą rzeczy, które muszą być wdrożone, aby zapewnić nam zgodność z prawem w następnych etapach roadmapy. Backlog puchł od nowych możliwości otwartych przez start Zilo i integrację z DM. 

Tymczasem dała o sobie znać inna nienasycona hydra. Pozwolę sobie znów zacytować Kamila:

Marcin, ale pamiętasz, że to wszystko trzeba wywalić i napisać kiedyś jeszcze raz?

Postawiłem sobie za punkt honoru, że gdy już dostarczymy używalną wersją systemu zatrzymamy się, odetchniemy i zrobimy prawdziwy refactor. To wreszcie był ten moment. Moment spłacania długów.

Na szczęście to dług, który spłaca się z przyjemnością widząc jak pierwszy publiczny release sobie radzi na wolności.

Podziękowania

Dziękuję wszystkim, którzy dzielili się swoimi krytycznymi opiniami na temat tego tekstu. Dzięki Wam (mam nadzięję) udało się utrzymać moje ego w ryzach. Szczególnie dziękuję Krzysztofowi Chudzikowi, Filipowi Goździewiczowi i Kamilowi Kosińskiemu, którzy przeżywali to wszystko na własnej skórze razem ze mną.

Dalsze podziękowania należą się nieocenionej loży produktowców, którzy pomogli mi zredagować ten tekst, tak, aby był jednocześnie zrozumiały i merytoryczny. Najwięcej napracowali się nad tym Kasia Małecka, Michał Jaskólski, Kasia Wódka i Kamil Zych. Dzięki!