Ściągnij PDF z tym tekstem (43 strony, 11.5 Mb)
Zamiast wstępu
iTaxi to polski startup oferujący przejazdy licencjonowanymi taksówkami dzięki aplikacji mobilnej. Został stworzony w 2012 roku przez Stefana Batorego. W 2016 roku firmą zaczął kierować Lech Kaniuk co wiązało się także z powstaniem w firmie działu produkowego pod moim kierownictwem.
W listopadzie 2016 roku, po kilkutygodniowym okresie analizy produktu naszkicowaliśmy z zespołem kierunki na pierwsze 12 miesięcy:
- Sytuacja zastana
- Za dużo zamówień z centrali telefonicznej
- Przestarzałe i rozdmuchane aplikacje mobilne
- Duże rozbieżności rozwojowe między aplikacjami
- Diagnoza
- Aplikacje są rozwijane ad hoc mimo tego, że wiemy, że to musi być nasz główny kanał sprzedaży
- Priorytety rozwoju
- Uproszczenie korzystania z aplikacji
- Ustabilizowanie cykli rozwojowych iOS i Android
- Priorytetyzacja user-facing features
- Konwertowanie klientów B2B także na B2C
- Kroki
- Backlog produktowy oprócz technicznego
- Usuwanie najmniej wykorzystywanych funkcji
- Stworzenie nowych wizualizacji aplikacji
- Wdrażanie poprawek do obecnych aplikacji
- Jednoczesna praca nad nowymi aplikacjami
Rozłóżmy to na części pierwsze.
To co zastaliśmy to był (w naszej ocenie) rozbudowany produkt, efekt dokładania funkcji budujących poczucie kontroli wśród pasażerów i dopasowania do potrzeb rynkowych właścicieli biznesowych.
Choć to zdanie brzmi dobrze, to wszystkie te pozorne pozytywy mają swoją mroczną stronę. Rozbudowany produkt to synonim problemów z zarządzaniem kodem – co z kolei zwiastuje powolny rozwój. Dodane funkcje wprawdzie zwiększały poczucie kontroli – ale to było, no właśnie, tylko poczucie. Zamiast zautomatyzować i skalować promowaliśmy manualne rozwiązania i ślepe zaułki. Przykład: ręczne zamawianie taksówek, które kończy się odmową kierowcy – zamiast wykorzystania algorytmów, które są w stanie znaleźć odpowiednią taksówkę nieskończenie razy szybciej. Poczucie dopasowania do potrzeb rynkowych było w tym wypadku synonimem braku rygoru i krytycznego spojrzenia na spójność całego produktu.
Innym problemem była nierówność rozwojowa aplikacji: Android był wyraźnie do przodu w stosunku do iOSa pod względem funkcji. Brakowało synchronizacji między platformami nie tylko na poziomie cyklów rozwojowych, ale też stylu i kierunku. Aplikacje rozwijane są przy okazji – mimo tego, że organizacja uznaje je za jeden z filarów strategii wzrostu. Nasz szybki rozwój przy obecnej strukturze generuje także równie szybki wzrost kosztów związanych z obsługą zamówień telefonicznych. Przy tej skali działalności każdy punkt procentowy zamówień przeniesiownych z centrali na aplikacje to realne oszczędności, bo koszt rozwoju aplikacji jest, uogólniając, niezależny od liczby zamówień z niej.
Dochodził jeszcze problem zespołu. W koordynacji z naszym CTO, mogliśmy korzystać z programistów jego działu – układ był między nami taki, że dział produktu decyduje o tym *co* ma być zrobione, a dział IT decyduje *jak* ma być zrobione. Jednak, aby faktycznie pójść do przodu z produktem iTaxi, musimy mieć ludzi skupionych na pracy stricte produktowej. Mieliśmy wtedy do dyspozycji programistkę Java/Android, która dzieli swój czas między aplikację pasażera, aplikację kierowcy i część prac serwerowych, developera iOS, który pracował u nas po godzinach, graficzkę pracującą dla nas zdalnie i głównie dla działu marketingu oraz wsparcie i dobrą wolę reszty działu IT w zakresie koordynacyjno-logistycznym. Jak z tego zbudować sprawny zespół?
Rozpoczęliśmy od wprowadzenia faktycznego Scruma, konsolidację zespołu i synchronizację sprintów iOS i Android. Udało nam się przekonać developera iOS do przyłączenia się do nas na stałe. Natomiast z graficzką miałem komunikację bezpośrednią – wspólnie przygotowywaliśmy materiały potrzebne do realizacji zadań do sprintu.
Nie poszliśmy jednak drogą zwiększania składu osobowego – to nie był najlepszy moment ze względu na cykl rozwoju firmy. Poza tym małe zespoły (mimo potencjalnego bus factora) mają przewagę elastyczności nad wielkimi machinami trawionymi potrzebą skomunikowania wszystkich ze wszystkimi.
Adnotacja do synchronizacji sprintów: „synchronizacja” nie oznaczała w naszym przypadku pełnego zrównania. Małe, zarządzalne przesunięcie między sprintami platform (ale o tej samej „długości”) ma swoje plusy: pozwala na rozpoznanie potencjalnych problemów mniejszym kosztem (druga platforma wchodzi wtedy na „gotowe” rozwiązanie).
Przed samym startem sprintów zaczęliśmy budować sobie lepsze rozeznanie szczegółów mechaniki aplikacji i jej interakcji z serwerem. Z pomocą dłużej pracujących w iTaxi osób naszkicowaliśmy userflow systemu i zaczęliśmy uczyć się języka i definicji specyficznych dla tego środowiska. Niezależnie powstawał nowy backlog w Trello. Wysłaliśmy do najbardziej obeznanych w kluczowych działach osób zapytanie o to, jakie najważniejsze funkcje chcieliby widzieć w produkcie, gdyby nie istniały żadne ograniczenia techniczne – potraktowaliśmy to jako drogowskaz na początek, gdy jeszcze brakowało pełnego obeznania z ograniczeniami samego systemu.
Do tego zaczęły szybko dochodzić elementy, które były czystym koncertem życzeń lub z drugiej strony: optymalizacje na poziomie kodu i poprawki małych błędów. Z czasem mieszanka tych elementów pozwoliła na wyklarowanie się najboleśniejszych problemów i (jak to się ładnie mówi) low hanging fruits.
Te ruchy miały jeszcze jeden, fundamentalny powód: iTaxi 3. Musieliśmy znaleźć sposób, aby nawiązać walkę produktową ze znacznie mocniejszą i bogatszą konkurencją. Stawka była wysoka, bo nie dość, że mocno odstawaliśmy to jeszcze mieliśmy poczucie, że dystans się zwiększa z każdym miesiącem. A więc skok jakościowy musi być ogromny – mamy do nadrobienia trzy lata w około rok.
Na końcu mojego planu zawarto potrzebę dualnego rozwoju: jednoczesne poprawianie obecnego produktu (iTaxi 2.x) oraz prace nad nowym (iTaxi 3). Ten, kto pamięta wcześniejsze zmagania z PizzaPortal kojarzy feature freeze (zablokowanie rozwoju obecnego produktu, aby skupić wszystkie siły na nowym). Tym razem chcieliśmy sprobować innego podejścia.
W listopadzie 2016 roku, mniej więcej w tym samym momencie gdy wysłaliśmy plan do reszty management teamu, przeprowadziliśmy w Senfino warsztat, którego celem było wyobrażenie sobie idealnego produktu iTaxi. Następnie strategia zakładała powolne przepoczwarzanie iTaxi 2.x tak, aby użytkownik małymi kroczkami przyzwyczajał się do zmian strukturalnych (kolejność ekranów, elementów w menu, mikrointerakcji, komunikacji aplikacja-serwer, logiki biznesowej itp), ale bez drastycznych zmian graficznych, które wejdą dopiero w finalnym etapie.
Zaraz po warsztatach wysłaliśmy makiety do najważniejszych osób w firmie i tym sposobem rozpoczęła się ponad roczne żonglowanie wymaganiami i zależnościami dwóch filozofii produktowych (manualna kontrola i skalowanie dzięki algorytmowi), trzech platform (iOS, Android i backend), kilkunastu interesariuszy i naszych ambicji.
Strategia
Od początku wisiał nad nami problem konkurowania z przeciwnikami, których kieszenie wydają się bez dna. Część z nas ma doświadczenia z pracy po drugiej stronie i obserwowania produktowego centrum organizacji o kapitalizacji ponad 1 mld Euro i tamtych metod radzenia sobie z konkurencją. Czy było tam cokolwiek, co mogę teraz wykorzystać w odwrotnej sytuacji?
Kluczem okazało się schowanie ambicji do kieszeni i twarde spojrzenie w rzeczywistość:
- nie zrobimy najlepszego produktu w tej branży, to jest fizycznie niemożliwe i nie ma co zakrzywiać rzeczywistości,
- tego typu produkt cyfrowy jest na tyle dobry jak jego rzeczywista, fizyczna dostępność,
- duże firmy mają różne kultury organizacyjne, ale wewnętrzne dynamiki ciągle się powtarzają,
A to oznacza, że:
- możemy doszusować do konkurencji, tam gdzie relacja progresu do kosztu jest przyzwoita,
- to jak wygląda aplikacja jest wtórne do tego czy wykona swoją pracę,
- możemy zmienić pole gry na takie, które nam sprzyja – takie, w którym duże ogranizacje są zbyt powolne,
To nam dało trzy główne kierunki rozwoju:
1. Mały zespół to szybki zespół
Naturalną cechą małych zespołów jest ich spójność i łatwość synchronizacji. Skupiliśmt się na tym, aby chronić zespół przed zewnętrznymi przeszkadzajkami. Mieliśmy jasno postawione cele i każdy fajerwerk, paraliż decyzyjny i inna dekoncentracja była po prostu stratą. Nie mieliśmy tolerancji na stratę czasu i energii. Prowadziło to do poważnego odgrodzenia zespołu od reszty firmy, z mocnymi, czasami autorytarnymi filtrami mówiącymi, co jest ważne a co nie. To ucięło wiele dyskusji, ale wprowadziło sporo napięć poza zespołem.
2. Punkt przegięcia funkcji jakości do kosztu
Tom Gilb lubi powtarzać, że kosztem perfekcji jest nieskończoność. Dla nas oznacza to, że krańcowy wzrost wartości jakości produktu będzie spadać wraz ze wzrostem kosztu (i odwrotnie):
Dwa punkty są ważne na tym wykresie: ten na górze to najlepszy produkt w swojej dziedzinie – najlepszy za każdą cenę. Ma to swoją wartość, gdyż będąc top of mind ma się dużą rynkową przewagę. Problem polega na tym, że koszty bycia w tym miejscu są niewspółmierne. Każdy następny progres produktowy jest robiony z coraz większym wysiłkiem, efektywność włożonej pracy spada z czasem.
Drugi (niższy) punkt na mapie to miejsce, które my wybraliśmy. To punkt przegięcia – miejsce tuż za którym zaczyna się spadanie inkrementalnej wartości. Skąd wiedzieć gdzie znajduje się ten punkt? Wykorzystywaliśmy do tego narzędzie Impact Estimation Table autorstwa wspomnianego wyżej Toma Gilba. Przykładowo moglibyśmy mieć lepiej rozwiązane podpowiadanie adresów tworząc samodzielny mechanizm lub kupując taki od Google’a. To jednak przekraczało nasz zasoby czasowe i finansowe, a więc stosunek wpływu do kosztu był dla nas zbyt niski. Gdyby chodziło o ambicje to byśmy o to mocno walczyli, ale personalne ambicje odłożyliśmy na bok. Aby zapewnić dostarczenie produktu na czas bez marnowania energii zespołu stawialiśmy intencjonalnie poprzeczkę niżej jeśli chodzi o fajewerski i wyżej jeśli chodzi o relacje wpływu do kosztu- tak, aby tego punktu przegięcia nie przekroczyć. Było nam ciężko pracować z takim kompromisem, ale w pełni rozumieliśmy jego potrzebę.
Ten wykres wydaje się prawdziwy także dla poszczególnych funkcji realizowanych w aplikacji. To był moment, w którym zrozumieliśmy, gdzie szukać naszych unfair advantages – tam, gdzie zaspokajanie potrzeb nie jest skorelowane z liczbą osób w dziale IT.
3. Skalowalna hiperlokalność
Jaki jest problem z wielorynkowymi firmami ze scentralizowanym produktem? Koszt alternatywny.
Gdy jesteś szefem produktu działającego na kilku(nastu) rynkach musisz ciągle podejmować decyzje na bazie kalkulacji kosztów alternatywnych. Czy wdrażać najpierw funkcję dla kluczowego, średniego czy peryferyjnego kraju? Co jeśli funkcja dla kluczowego rynku jest kosztowna a dla małego prosta?
Z naszych doświadczeń wynika, że w większości przypadków wybierany jest kluczowy rynek kosztem tych mniejszych – stoi za tym czysty rachunek ekonomiczny (szybciej się zwróci) i mechanizm psychologiczny (większa pewność dobrej decyzji).
Wiedząc, że żaden z naszych konkurentów nie ma programistów na miejscu i decyzje są podejmowane w San Francisco, Hamburgu i Tallinie/Pekinie zaczęliśmy myśleć o budowaniu backlogu biorąc pod uwagę jakie funkcje powinniśmy robić, aby być trudno replikowalnym przez konkurencję, tj. takich, które są dla nas ważne, ale mikroskopijne w oczach międzynarodowej konkurencji.
Chcieliśmy doprowadzić do sytuacji, w której konkurent proszący o replikację naszej funkcji został odesłany z kwitkiem ze względu na istotniejsze projekty. Centralizacja prac powoduje też, że lokalni przedstawiciele zawsze będą mieli związane ręce – sami sobie tych funkcji nie dorobią, bo nie mają kompetencji – a nawet jeśli mają, to ich przewalczenie nie jest warte ryzykowania swojej pozycji w organizacji.
Organizujemy się
Do tej pory w iTaxi pracowano na Redmine. Choć o zmianie na jakiś bardziej współczesny pakiet zarządczy mówiło się od dawna to jednak dwa argumenty przeważały: Redmine jest znany i darmowy. Zamiast z tym walczyć stwierdziliśmy, że łatwiej będzie nam zbudować między zespołem a Redminem lepszy interfejs. Stąd też Trello, które po kilku eksperymentach okazało się dobrym narzędziem, o ile mieliśmy czas na manualną synchronizację między obydwoma narzędzami.
Pierwszy sprint iOSa i Androida rozpoczął się 18.11.2016. Zespół postanowił pracować w sprintach dwutygodniowych. Po około 3 sprintach (1.5 miesiąca) zaczęła budować się rutyna i przewidywalność związana z rytuałami Scruma: sprint review, retrospektywa (tutaj było najtrudniej), planowanie nowego sprintu. Do wyceniania zadań przyjęliśmy potęgi: 1, 2, 4, 8, 16, 32; jeśli zadanie miało 32 punkty to uznawaliśmy je za zbyt duże i wymagające dekompozycji.
W chwili pisania tych słów kończymy sprint #31 z czego 25 było zarządzanych przez tandem Redmine+Trello. Trello stanowiło dobrą wizualną nakładkę na topornego Redmine’a. Ten jednak miał dla nas wielką wartość jako archiwum ponad 7000 wcześniejszych zadań do których mogliśmy się odwoływać. Po sprincie 25 przestawiliśmy się na JIRĘ ze względu na coraz większą kompleksowość podejmowanych zadań.
Każdy sprint backlog miał swoją kolumnę. W każdej kolumnie były zadania, większość z nich ma wskazany kolorem koszt (żółty 2 pkt, pomarańczowy 4 pkt itd). Te cztery cyfry na końcu to numer ticketu w Redmine, w którym są szczegóły techniczne i materiały potrzebne do realizacji zadania. Przesunięcie zadania pod DONE oznaczało, że zadanie zostało wykonane. Jeśli na koniec sprintu jakieś zostało ponad DONE to trafiało do następnego sprintu.
Na koniec każdego sprintu robiliśmy podsumowanie mailowe zawierające efekty naszego Review (listę zrobionych rzeczy wraz z liczbą wyrobionych punktów) i Planningu (lista rzeczy do zrobienia na najbliższy sprint) i rozsyłałem je do całej firmy. Poniżej fragment jednego z takich raportów na koniec sprintu:
Często bywało tak, że wypracowane przez nas funkcje muszą czekać, aż jakiś inny element systemu dojedzie na produkcję, a to oznacza że może minąć miesiąc lub więcej zanim będą widoczne. To co dla nas jest zakończone w lutym zostanie wdrożone w marcu, a w kwietniu stanie się zauważalną zmianą dla organizacji. Z drugiej strony wdrożenie Scruma i wzmocnienie zespołu produktowego szybko dało efekty w postaci dużych i szybkich zmian produktowych. Sporo osób jednak wyrażało zaskoczenie i niezadowolenie z tego, że nie wiedzą, czego i kiedy mogą się spodziewać – brak przewidywalności był stresujący.
Dlatego w maju 2017 roku rozpoczęliśmy tradycję Product Show – comiesięcznych spotkań dla wszystkich chętnych pracowników, gdzie pokazujemy, co robimy w ramach obecnego produktu jak i iTaxi 3. Product Show miało potrójną rolę:
- zaznajamianie organizacji z iTaxi 3,
- mechanizm sugerowania nowych rozwiązań,
- System wczesnego ostrzegania o zmianach.
Nasze spotkania trwały zazwyczaj godzinę naprzemiennych prezentacji zmian i pytań o ich konsekwencje.
Droga do iTaxi 3
Choć obecna transformacja iTaxi 2 na iTaxi 3 wydaje się dużą zmianą widoczną dopiero teraz, to przepoczwarzanie rozpoczęło się rok wcześniej. Podmienialiśmy najbardziej kompleksowe elementy stopniowo rozkładając ryzyko na wiele miesięcy zamiast robić jedną wielką aktualizację (tak musieliśmy zrobić w przypadku PizzaPortal ze względu na problem duplikacji danych w bazie). Dzięki temu mogliśmy testować fragmenty nowego kodu stopniowo i szybciej reagować na problemy.
Z perspektywy użytkownika iTaxi 3 miało premierę niedawno, ale faktycznie z wielu usprawnień tego produktu korzystali już dużo wcześniej. Aby dopasować się do wizji iTaxi 3:
- wyłączyliśmy zamawianie „z mapy” (12.2016)
- usunęliśmy samouczek (12.2016)
- uprościliśmy logowanie i rejestrację (03.2017)
- zmieniliśmy strukturę menu (05.2017)
- zreorganizowaliśmy kategorie taksówek (z czterech zeszliśmy do dwóch) (07.2017)
- usunęliśmy filtry (07.2017)
- zmieniliśmy logikę zamawiania (07.2017)
- zakopaliśmy głębiej wybieranie taksówki z listy (07.2017)
I to wszystko zanim jeszcze ktokolwiek zobaczył pierwszy działający prototyp iTaxi 3. Takie podejście spotkało się to ze spodziewanym oporem zarówno ze strony taksówkarzy (dlaczego zabieracie pasażerom kontrolę?), jak i pasażerów (dlaczego zmuszacie mnie do zmiany nawyków?). Te zmiany były potrzebne, choć wtedy, bez kontekstu, wydawały się mało sensowne i wręcz wrogie wobec użytkowników.
Nawiasem mówiąc to jedna z tych wielkich ironii pracy jako produktowiec: aby coś poprawić dla użytkownika, trzeba najpierw mu się przeciwstawić.
To były duże i odważne eksperymenty. W gruncie rzeczy odcinaliśmy fragmenty aplikacji i czekaliśmy na to, kto i kiedy zacznie głośno narzekać. Jeśli nikt, to znaczy, że nikomu na nich nie zależało – czyli postąpiliśmy dobrze. Jeśli pojawiały się negatywne komentarze to wspieraliśmy się danymi statystycznymi, aby sprawdzić czy ci, którzy są głośni są także liczni. To był też czas, gdy wreszcie mieliśmy okazję intensywnie przetestować Google DataStudio – narzędzie do Business Intelligence agregującego sygnały z wielu różnych źródeł (ale najlepiej google’owych). W efekcie zbudowaliśmy system raportowy w skali tygodnia, miesiąca i roku z podziałem na iOSa i Androida:
Oraz bardzo mikroskopijny obraz per platforma na najważniejsze kroki w aplikacji:
Traktowaliśmy te wykresy jak bicie serca u pacjenta. Każda zmiana rezonowała na wykresie, nawet te o których nie wiedzieliśmy – jak nagłe załamania pogody czy koncerty. Ten wzrost na wykresach to oczywiście efekt sylwestra i syndrom dnia następnego. Przy okazji pokazuje jak duże mogą być amplitudy popytu w tym biznesie.
Design i UX
W lutym 2017 wizualizacje stworzone przez Senfino zostały wykorzystane jako materiał referencyjny dla naszych własnych prac graficznych. Rozpoczęła się żmudna praca dekomponowania górnolotnego konceptu na realne zadania.
Naszym pierwszym zajęciem było rozpisywanie kolejnych kroków zamawiania i realizacji kursu taksówką: włączenie, logowanie/rejestracja, zamówienie, czekanie na przyjazd, w kursie oraz płatność. Wydaje się proste, ale im głębiej w las tym ciemniej. Userflow rozgałęzia się wielokrotnie ze względu na różne typy użytkowników (prywatni, biznesowi), różne sposoby zamawiania (z mapy, z algorytmu, z listy) czy różne sposoby płatności (aplikacją, gotówką, na fakturę). Celem było wyeliminowanie zbędnych elementów, ale musieliśmy uważać w naszym redukcjoniźmie, aby przypadkiem nie usunąć czegoś, co rozpocznie lawinę nieoczywistych problemów.
To była nasza nauczka przy wspomnianej już modyfikacji potrzebnej przed iTaxi 3 – zmianie kategorii taksówek z czterech do dwóch. Modyfikacja, która miała przynieść łatwiejsze rozeznanie i przyśpieszenie zamawiania, wprowadziła nieoczekiwane zamieszanie po stronie obsługi: taksówki, które do tej pory były w niższej kategorii wpadły do wyższej przez co spadła im liczba zamówień (bo naturalnie bardziej luksusowa kategoria miała mniej amatorów). Byli też taksówkarze, którzy poczuli się zdegradowani, gdy spadli ze zlikwidowanej kategorii środkowej do najniższej. Gdyby tego było mało ,musieliśmy ze względów technicznych i biznesowych utrzymać wewnętrzną nomenklaturę nazewnictwa, więc w efekcie zamiast zredukować problem to wydłużyliśmy katalog zależności i definicji do zapamiętania. Brak myślenia o efektach drugiego rzędu w praktyce – i nauczka na przyszłość.
Nasze makiety lo-fi powstawały z wykorzystaniem trio iPad Pro, Apple Pencil i aplikacji Goodnotes. Techniczna walidacja tak narysowanych idei nastąpi dopiero gdy developerzy wdrożą elementy przygotowane na ich podstawie – nie przywiązywaliśmy się więc do nich zbyt mocno.
Podczas wewnętrznych warsztatów i wywiadów z użytkownikami zebraliśmy listę najważniejszych problemów i frustracji. Było ich sporo, ale dominowało poczucie niepewności. Po zanalizowaniu wszystkich artefaktów badań powstało podsumowanie do managementu:
„iTaxi jest postrzegane jako usługa niepewna. To znaczy, że deklarowany czas różni się od faktycznego, jakość samochodu i profesjonalizm kierowcy to ruletka, nie wiadomo też czy kierowca faktycznie wykona to, o co się go prosi. W przypadku kursów B2C jest to rynkowo akceptowane ze względu na bardzo niską cenę i price dumping, ale podobne sytuacje w B2B mają o wiele gorsze konsekwencje (…)”
Na ten problem składało się mnóstwo elementów: od takich których nie kontrolujemy (percepcja zawodu taksówkarza), takie na które mamy wpływ (standard floty i zachowanie naszych kierowców) i takie, które są w pełni zależne od nas (interakcja z aplikacją). Na poziomie aplikacji mieliśmy ograniczone możliwości budowania zaufania (większość interakcji odbywa się podczas samego przejazdu, a najmocniej w głowie zapada zakończenie kursu) więc skupiliśmy się na tworzeniu interfejsu, który jest zgodny z oczekiwaniami, znajomy i wyglądający współcześnie. Co to oznacza w praktyce?
- upraszczanie likwiduje ślepe uliczki (minimalizuje niepewność związaną z brakiem zrozumienia logiki systemu),
- poprzestawianie przepływu ekranów i kolejności elementów na ekranach (lepiej informuje o istotności funkcji: najważniejsze jest najlepiej widoczne),
- dodanie bardziej dynamicznych animacji przy mikrointerakcjach (zwiększa zaufanie do szybkości aplikacji),
- zmiana designu i ikon (zwiększa przewidywalność przez znajomość – korzystaliśmy z zasobów Material Design i Human Interface Guidelines)
Rysowanie makiet Lo-Fi to była ciągła walka: dwa kroki do przodu, jeden do tyłu. Ekrany „płyną” – jeden zależy od drugiego i muszą trzymać się tych samych wzorców, aby użytkownik miał intuicyjne poczucie, gdzie się znajduje. Do tego dochodzi jeszcze następny wymiar skomplikowania – trzeci wymiar. Tutaj czuję, że poległem w odpowiednim rozplanowaniu osi Z w aplikacji. Nie udało się uprościć aplikacji na tyle żeby utrzymać tylko dwie warstwy głębokości aplikacji, co było moją pierwotną ambicją.
Rysowanie makiet przeplatało się z obserwowaniem jak konkretne problemy są rozwiązywane przez inne aplikacje okupujące podobną niszę – nie tylko bezpośrednią konkurencję, ale także interfejsy związane z przemieszczaniem ludzi lub przedmiotów w przestrzeni. Na przykład studiowaliśmy wnikliwie jak wygląda wpisywanie adresu startowego i docelowego – czy są to dwa oddzielne ekrany, jeden wielowątkowy czy sekwencyjny? Jak duże powinno być zagęszczenie informacji? Gdzie umieścić (jak wysoko w hierarchii) ulubione adresy w kontrze do historycznych adresów? Czy przy pojawieniu się ekranu adresu klawiatura powinna być (uwaga, anglicyzmy) od razu widoczna z focusem na inputfieldzie? Czy tooltip na inputfieldzie powinien znikać gdy pojawia się tam focus? Czy wyszukiwanie powinno odbywać się po wpisaniu jednej, dwóch czy trzech liter?
Decyzje na tym etapie kaskadowo roznosiły się na resztę aplikacji, bo użytkownik oczekuje, że każdy powtarzalny element interfejsu zachowuje się tak samo niezależnie od miejsca w systemie. To miało znaczenie nie tylko estetyczne, ale także biznesowe: im mniejszy wysiłek kognitywny związany z korzystaniem z usługi tym większy zysk dla użytkownika i potencjalnie większa jego powracalność.
Menu główne – przykład na przemodelowanie hierarchii funkcji. Z długiej listy elementów wizualnie sugerującej podobną istotność usunęliśmy część funkcji, zwiększyliśmy istotność (wielkość) kategorii głównych, przesunęliśmy dalej we flow inne oraz przenieśliśmy na wierzch opcję przełączania się między kontami.
Szczegóły kursu – ułatwiliśmy zamawianie przez szybkie adresy widoczne od razu, eliminacje natłoku niezrozumiałych ikon i mocniejsze kontrastowanie elementów. 
Filtry/opcje – wynieśliśmy kategorie taksówek z obecnych czterech (Economic, Comfort, Premium i Wszystkie jeśli nic/wszystko zaznaczone) do dwóch widocznych na ekranie wcześniej (Popularna, Luksusowa) z domyślnym zaznaczeniem Popularnej. Przemyśleliśmy na nowo wybór liczby pasażerów i zmniejszyliśmy liczbę filtrów, aby nie przytłaczać możliwościami.
Animacje – są bardziej dynamiczne dzięki czemu użytkownik czuje większą przyjemność w interakcji.
Aby dać Wam pewien obraz skali tego procesu: przetestowaliśmy w tym czasie fizycznie (tam gdzie są geograficznie dostępne) i wirtualnie (spoofując geolokalizację i resztę dopasowując na bazie tutoriali na Youtube i FAQu na stronach firm) 23 aplikacje – rynkowych liderów z każdego kontynentu oraz najpopularniejsze rozwiązania w Polsce. To, do czego dążylismy to asymilacja przydatnych rozwiązań, do których użytkownicy już się wystarczająco przyzwyczaili (pamiętając o tym, żeby obniżyć ich wysiłek kognitywny) przy jednoczesnym odrzuceniu niepasujących logicznie lub strategicznie resztek oraz nadaniu całości naszego własnego sznytu.
Mniej wiecej w połowie moich prac na makietami swoją część rozpoczęła nasza graficzka. Łącząc artystyczny kierunek nadany wcześniej z naszymi makietami lo-fi zaczęła wizualizować je w formie makiet hi-fi. Aby to ułatwić i pokazać progresję z ekranu do ekranu połączyliśmy je ze sobą korzystając z Marvela. Przygotowaliśmy też spis wymagań dla makiet hi-fi. Plik był krótki:
Im dalej w las tym grafiki powstawały szybciej. Tak samo jak w przypadku makiet lo-fi wiedzieliśmy, że w przeciągu następnych 8 miesięcy jeszcze sporo będzie się zmieniać, ale coraz większa baza elementów dawała coraz większą pewność co do kierunku i kształtu iTaxi 3.
Jest kilka rzeczy, które chcieliśmy zaznaczyć tym projektem. Pierwszą z nich jest przekonanie, że dobry design zwiększa lojalność użytkowników. Wierzymy mocno w to, że ludzie świadomie i podświadomie lubią obcować z ładnymi rzeczami, takimi, które mają swój przemyślany styl i rytm. Chcieliśmy też złożyć hołd dla fontu Lato autorstwa Łukasza Dziedzica. To jeden z najlepszych produktów jakie eksportujemy – powinnismy być z tego bardzo dumni.
Spalanie punktów
Wróćmy jednak do maja 2017 – do tego czasu wytrzymała idea dualnego rozwoju iTaxi 2.x i iTaxi 3. Chwilę wcześniej oszacowaliśmy sumę punktów potrzebnych do zakończenia iTaxi 3 w oparciu o dotychczasowe wyceny i uśrednione tempo spalania punktów w sprincie. Jedno stało się jasne: jeśli nic się nie zmieni to nie wyrobimy się w roku 2017 z premierą.
Było kilka możliwości do rozważenia – najpopularniejsze to zatrudnienie dodatkowych ludzi do zespołu lub wyniesienie części pracy na zewnątrz. Pierwsza jednak wcale by nie przyśpieszyła prac, bo nowi developerzy muszą dostosować się do metod pracy zespołu i zaznajomić z kodem, co trwa, a do tego także zajmuje czas obecnego zespołu. Druga propozycja była dla nas na tamten moment zbyt droga (i też wymagałaby czasochłonnej synchronizacji). Ostatecznie więc byliśmy zmuszeni znów zastosować feature freeze i generalne usztywnienie na wdrażanie nowych rzeczy w iTaxi 2.x poza szczególnymi przypadkami jak naprawa krytycznych błędów.
W sierpniu 2017 wiedzieliśmy, że nawet całkowite skupienie na iTaxi 3 nie gwarantuje nam dostarczenia na listopadowy termin. Wybraliśmy listopad ponieważ grudzień jest w tej branży bardzo chaotycznym miesiącem: zła pogoda oraz firmowe imprezy świąteczne jednocześnie generują duży popyt i ograniczają podaż. Następnie są święta i zapotrzebowanie na taksówki szoruje po ziemi. Chwilę później jest nowy rok i nasza infrastruktura grzeje się do czerwoności. Wydawanie nowej aplikacji w tym czasie nie pozwoli nam zrozumieć jak została odebrana przez pasażerów – zbyt mocne siły rynkowe zaszumiłyby nasze dane. Dlatego ostatecznie zdecydowaliśmy sie wystartować w połowie stycznia, gdy warunki zewnętrzne będą bardziej przewidywalne.
Burndown Chart to prawdopodobnie najczęściej wykorzystywane przez nas narzędzie przy pracy nad iTaxi 3. Przedstawialiśmy go co tydzień na naszych management meetings. Pokazuje jak szybko zespół pracuje („spala” zakres pracy). Burndown jest podzielony na dwa wykresy – iOS i Android. Zaczyna się w okolicach 320 punktów – na tyle oszacowaliśmy ciężar na platformę (na bazie wcześniejszych doświadczeń przy iTaxi 2.x). Niebieska linia to optymistyczny wariant tempa pracy a zielona pesymistyczny (choć wolę go nazywać realistyczym). Obydwie powstały na bazie wcześniejszego tempa pracy z uwzględnieniem bus factora, urlopów, narzutu komunikacyjnego i spowolnienia wynikającego z badań. Ostatecznie oznaczało to zdjęcie 30-50% z szybkości zespołu. Żółta linia to faktyczna szybkość pracy. Gdy linia osiągnie zero to teoretycznie oznacza, że prace są zakończone.
Kilka rzeczy więcej można z tych wykresów wyczytać – na przykład jak Android zaczął swoją pracę przed czasem a iOS był trochę do tylu i przez cały czas gonił. Poziome wypłaszczenia na żółtej linii to święta i urlopy a więc generalne spowolnienie. Widać też wyraźnie, że przez 2/3 czasu pracy szło nam gorzej niż się spodziewaliśmy, a później nastąpiło przebicie zielonej linii i przyśpieszenie. Jest to normalne (na tyle na ile możemy powiedzieć z naszego doświadczenia), bo ta pierwsza faza to pokrywanie całego flow projektu, a więc najwięcej nieoczekiwanych korekt, druga faza to przewidywalne poprawianie istniejącego kodu, a więc wzrost szybkości.
Samo spalanie punktów odbywało się wzdłuż flow użytkownika. To znaczy, że nie szukaliśmy największych ani najmniejszych zadań na początek tylko szliśmy kolejnością ekranów jakie widzi użytkownik. Po korekcie terminu startu z listopada na styczeń oraz coraz mocniejszym żonglowaniu zakresem prac im bliżej startu udało nam się dojechać do końca projektu dokładnie na środku między optymistyczną a realistyczną linią spalania punktów – co uznajemy za duży sukces.
Jobs To Be Done
Jobs To Be Done to metoda myślenia o produktach i usługach zaproponowana przez Claytona Christiensena, autora fenomentalnych książek biznesowych o disruptive innovation. Główne założenie jest takie, że ludzie nie *kupują* rzeczy a *zatrudniają* je do zrobienia konkretnej pracy (video prezentacją na ten temat można znaleźć tutaj). Aby wyobrazić sobie jak duże to ma znaczenie i jak stawia do góry nogami myślenie strategiczne pomyślcie o tym: o realizację pracy jaką jest „spotkanie twarzą w twarz z klientem na drugim kontynencie” konkurują ze sobą i linie lotnicze i software do telekonferencji, dwie zupełnie różne kategorie firm i branż.
Byliśmy przekonani, że możemy dużo zyskać korzystając z JTBD w praktyce. Do czego ludzie zatrudniają taksówki? Kto z nami konkuruje oprócz oczywistych przewoźników? W tym miejscu nie powiemy dużo więcej, bo wnioski stanowią ważną część naszej strategii.
Podczas wywiadów z pasażerami doszliśmy do wniosków, że przestrzeń taksówki jest traktowana przez pasażera i kierowce jako własność kierowcy. Świadczy o tym personalizacja jaką kierowcy nadają swoim samochodom: różne umiejscowienie taksometru, ulotki, naklejki, odświeżacze powietrza i inne osobiste dodatki odzwierciedlające charakter kierowcy tak, aby czuł się „u siebie”. Pasażerowie jednak, ze względu na brak standaryzacji i neutralności przestrzeni w jakiej się znajdują podczas kursu, świadomie i podświadomie unikają modyfikacji tej przestrzeni, gdyż nie czują się „u siebie”. Czują, że zasady tego 20-30 minutowego kontraktu zostały już z góry ustalone. Jednocześnie jednak kierowcy czują silną potrzebę dostosowania się do pasażerów. Mają misję i chcą dbać o dobre warunki pasażera, wiedzą, że jego przewóz ma kluczowe znaczenie dla całego dnia tej osoby. Są więc otwarci na sugestie i modyfikacje tego kontraktu. Wokół tego zbudowany jest etos taksówkarza.
W jaki sposób godzić takie rozbieżności?
Coraz większą grupą naszych użytkowników są klienci biznesowi. To ludzie, którzy jadą na spotkania biznesowe na drugą część miasta, aby zrobić prezentację, uczestniczyć w konferencji, walczyć w negocjacjach, wygrywać przetargi. Każdy z tych przypadków wymaga wcześniejszego merytorycznego przygotowania i, w odczuciu naszych klientów, czas w taksówce jest do tego idealny. To moment na ostatnie poprawki w prezentacji, ostatnie przećwiczenie przemówienia.
Łącząc te sygnały zdecydowaliśmy się wdrożyć jako jedną z ostatnich funkcji przed premierą opcję Cichy przejazd. Jeśli pasażer w swoim profilu zaznaczy opcję „Cichy przejazd” to kierowca w komentarzu do zlecenia dostanie informację, aby ściszyć radio i nie rozpoczynać dyskusji, bo pasażer potrzebuje skupić sie na pracy lub chce odpocząć. Choć ta funkcja spotkała się z kilkoma krytycznymi głosami (głównie o przedmiotowe traktowanie kierowców) to czuję, że to jeden z elementów negocjowania kontraktu – tak, aby osiągnąć win-win najniższym emocjonalnym kosztem.
Czas dojazdu na miejsce – na bazie wyżej opisanego wniosku o klientach biznesowych zdecydowaliśmy sie wdrożyć także inną pożyteczną funkcję: dynamiczne pokazywanie ETA (estimated time of arrival) podczas dojazdu. Jednym z największych lęków przy przejazdach biznesowych jest ryzyko spóźnienia na spotkanie – to nigdy nie buduje dobrego piewszego wrażenia. Klienci zamawiający przejazdy biznesowe zazwyczaj w głowie kalkulują ile czasu zajmie im przejazd, dodają sobie w pamięci kilka minut zapasu, ale nie mają pełni wiedzy o obecnym stanie przepustowości ulic. Aby obniżyć stres pasażera w trakcie kursu pokazujemy więc na dole ekranu czas do miejsca docelowego oraz godzinę, o której będzie na miejscu. Dzięki temu wie, czy wyrobi się na swoje spotkanie o 9:30 czy należy informować o spóźnieniu jeszcze gdy jest to społecznie akceptowalne.
Dalsze tego typu rozwiązania będą pojawiać się z czasem.
Testy
Jeśli mielibyśmy opisać różnicę w skomplikowaniu iTaxi i PizzaPortal to chyba najlepiej to porównać tak: iTaxi to tysiące restauracji, które ciągle zmieniają swoje adresy. To przemieszczanie się jest dużym problemem przy testowaniu naszych rozwiązań: czas reakcji systemu i szybkość parowania obiektów ma fundamentalne znaczenie dla odbioru usługi. Ten czas jest zależny od wielu elementów, zależnych i niezależnych od nas: pozycji geograficznej, jakości sygnału GPS, kierunku jazdy, korków, remontów drogowych, wypadków, specyficznych zachowań mieszkańców konkretnych miast i tak dalej. To wszystko jest dodatkowo potęgowane przez bardzo mocny efekt sieciowy: więcej taksówek to więcej pasażerów więc więcej taksówek. Poza tym o ile na pizzę ludzie są gotowi czekać 30 minut lub godzinę, to taksówkę chcą mieć w przeciągu kilku minut.
To wszystko powoduje, że testowanie nowych rozwiązań staje się bardzo kłopotliwe bo ciężko jest wyizolować grupę odniesienia: codziennie warunki się zmieniają więc wszystkie eksperymenty obarczone są dużym ryzykiem powstawania false positives.
W połowie listopada 2017 wysłałem do management teamu maila z planem testów:
Pierwszy testowy kurs wykonaliśmy 25.11, chwilę później zaczęła jeździć grupa 50 wewnętrznych betatesterów uzbrojonych w listę ponad 40 przypadków testowych. Ten moment dobrze ilustruje szybkość przyrostu zadań na wykresie kumulatywnym iOSa (poniżej). W kulminacyjnym momencie mieliśmy ponad 200 wykrytych błędów – od krytycznych jak zrywanie sesji w trakcie korzystania z aplikacji do trywialnych jak font niezgodny z designem. W tym samym czasie wydawaliśmy wersje średnio co 2-3 dni naprawiające po kilka-kilkanaście z nich.
Przykład na cyzelowanie aplikacji – dopasowywanie wersji beta do grafik. Przechodziłem razem z działem testów przez każdy ekran, aby wyszukiwać rozbieżności między „idealną” wersją aplikacji a stanem faktycznym.
Start!
Termin startu mieliśmy wyznaczony na poniedziałek 15 stycznia 2018. Ostatnie sprinty były usłane wieloma trudnymi decyzjami: co wchodzi, a co nie wchodzi do pierwszej wersji? 28 grudnia przygotowaliśmy listę rzeczy, które powinny znaleźć się w aplikacji przed startem:
Musieliśmy być realistami i powiedzieć sobie jasno co jeszcze możemy zmieścić, a co musimy odrzucić. Z każdym następnym dniem mieliśmy coraz mniejsze pole do manewru. Wiedzieliśmy jednak, że bez jasnej i namacalnej (choć sztucznej) daty startu będziemy rozciągać nasze prace w nieskonczoność mówiąc sobie, że zawsze możemy dać sobie jeszcze dzień, albo tydzień, albo miesiąc. Woleliśmy już wypuścić niepełną wersję niż czekać na ideał. Ostatecznie największe i najtrudniejsze rzeczy (jak usuwanie terminówki i rejestracja B2B) zeszły na sam koniec, co w praktyce eliminuje je z listy premierowych funkcji. Ktoś może zapytać jak to się stało, że ekran pomocy czy uśmieszek na pinie okazały się ważniejsze mimo swojej trywialności? Bo to są elementy, które 100% użytkowników doświadczy, a te powyższe rzeczy będą istotne, ale dopiero jak ktoś je zobaczy. Czego oczy nie widzą, tego sercu nie żal.
Mieliśmy do wykonania kilka żmudnych, nudnych ale potrzebnych rzeczy jak poprawa literówek i weryfikację angielskich tłumaczeń. Aby mieć pewność, że omijamy jak najmniej rzeczy (bo nie mamy złudzeń, że wszystko wychwycimy, nie przy tak złożonym projekcie) zrobiliśmy spotkanie przy dużym stole – po jednej stronie developerzy ze swoimi komputerami, marketing, ja i dwie osoby z działu testów. Sprawdzaliśmy ekran po ekranie obydwie platformy i jak tylko pojawiała się nieścisłość to programiści od razu je poprawiali w kodzie.
Mimo to nie wyrobiliśmy się. Ciągle odkrywaliśmy nowe niezałatane dziury, których nie chcieliśmy mieć w pierwszej publicznej wersji. Cały dzień spłynął nam na poprawkach.
16 stycznia 2018 do sklepu Google Play trafiła wersja na Androida. Chwilę później wersja na iOS. Choć mieliśmy jeszcze kilka problemów po drodze (jak szybkie napisanie poprawki na starsze wersje iOSa i niedziałający App Store w najgorszym momencie) to otworzyliśmy już wtedy szampana, żeby symbolicznie zamknąć klamrą ten 15 miesięczny projekt.
Miesiąc to za mało, żeby mieć pewność, że nowa wersja poprawia nasze wyniki jako organizacji. Choć widzimy znaczną poprawę w konwersji to nie wiemy w jakim stopniu wpłynęły na to zmiany pogody czy ferie. Musimy poczekać na inne dane, szczególnie analizy kohortowe, aby wyrobić sobie zdanie. Do tego czasu pozostają nam jedynie dane anegdotyczne:
Z których wynika, że chyba poszło nam całkiem dobrze :)
Jeśli jednak chcesz się sam(a) przekonać jak nam poszło to zapraszam do ściągnięcia iTaxi 3!
Nota od autora
Ten tekst to próba odtworzenia kilkunastu miesięcy pracy naszego zespołu w iTaxi. Pierwsza wersja tego artykułu miała bardziej personalny wydźwięk, ale teraz, pozbywając się tego liczę, że jest bardziej obiektywny i wyważony. Przez wszystkie akapity powyżej wypowiadałem się jako pracownik iTaxi, ale poniższa część to już moje osobiste posłowie, nie należące już bezpośredni do analizy.
Codziennie w biurze iTaxi przechodzę obok tego plakatu:
Jego przekaz wbił mi się w mocno w moją świadomość. Mam w głowię jakąś potrzebę do dążenia do szczerości produktu. Ta szczerość oznacza, że każdy naciśnięty przycisk spełnia swoją obietnicę. Wierzę w to, że drogą do tej szczerości jest prostota formy i funkcji. Z tym podejściem walczy jednak drugi z moich pryncypiów: odpowiedzialność za użytkownika. Często prostota jest błędnie zastępowana kontrolą. To znaczy, że zamiast upraszczać rzeczy użytkownikowi biorąc na siebie chaos, który jest pod spodem, przerzuca się na niego odpowiedzialność maskując to większą liczbą opcji, funkcji i innych symboli kontroli. Uważam to za błąd, bo wymusza na kliencie niepotrzebny kognitywny ciężar. Nasz świat już teraz jest zbyt kompleksowy i skomplikowany, aby jeszcze bardziej go utrudniać.
Nowa wersja aplikacji iTaxi to próba wzięcia tej odpowiedzialności za ten chaos, zatrzymanie i odwrócenie procesu komplikowania i ostatecznie obniżenie ciężaru kognitywnego. Ironia losu polega na tym, że nigdy nie będę wiedział czy to się udało. To co jest najważniejsze jest najtrudniejsze do policzenia i nawet liczby w Excelu i wykresy w Data Studio nie są wstanie pokazywać tylko mały fragment tej historii. Czas oceni te zmagania.
Dziękuję całemu zespołowi (Ania, Marcin, Kasia, Gaweł, Kamil, reszta działu IT) za zaufanie oraz ponownie Lechowi za danie mi wolnej ręki. Mam nadzieję, że było warto!
Marcin Zaremba
Chief Product Officer
iTaxi
