Kategoria: Dłuższy wywód

Jak powstawały aplikacje iTaxi 3

Ś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:

  1. 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
  2. Diagnoza
    • Aplikacje są rozwijane ad hoc mimo tego, że wiemy, że to musi być nasz główny kanał sprzedaży
  3. Priorytety rozwoju
    • Uproszczenie korzystania z aplikacji
    • Ustabilizowanie cykli rozwojowych iOS i Android
    • Priorytetyzacja user-facing features
    • Konwertowanie klientów B2B także na B2C
  4. 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:

B3E5A6AF-B8D6-43E2-ABBE-C0D801E7D634

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

2017

Zgodnie z wieloletnią już tradycją (2013, 2014, 2015, 2016) piszę podsumowanie ostatnich 12 miesięcy

Ciężary

Prawdopodnie jedną z najbardziej odczuwalnych zmian w tym roku było u mnie zainwestowanie czasu w siłownię i podnoszenie ciężarów. Z pominięciem dwóch dużych dziur związanych z wyjazdami ćwiczyłem siłowo 2-3 razy w tygodniu przez 9 miesięcy, a w szczycie formy udało mi się w martwym ciągu podnieść 142,5kg i 132,5kg w przysiadzie. Czuję z tego dużą satysfakcję i ciągle siedzą mi w głowie słowa Marka Rippertoe, który dobrze podsumowywuje także moje podejście:

“Physical strength is the most important thing in life. This is true whether we want it to be or not. As humanity has developed throughout history, physical strength has become less critical to our daily existence, but no less important to our lives. Our strength, more than any other thing we possess, still determines the quality and the quantity of our time here in these bodies.”

Jedyne zdjęcie na którym widać, że faktycznie coś podnoszę

Odcięcie

Drugą największą zmianą jaką odczułem w tym roku było odcięcie od (social) mediów. Zaczynałem od małych kroczków: zainstalowałem aplikację “Moment” sprawdzającą ile czasu spędzam na telefonie (wyszło 4-5h dziennie). Przeraziło mnie to odrobinę. Aby temu zaradzić zainstalowałem inną: “Freedom” – VPN, który pozwala filtrować w jakim czasie jakie aplikacje mają dostęp do Internetu (to taka kontrola rodzicelska nałożona na samego siebie). Odciąłem wszystkie serwisy newsowe, Youtube, Facebooka, Twittera, Amazona, Instagrama, Linkedina itd. Zaczynałem od kilku godzin dziennie, później robiłem sobie czas na media podczas lunchów w pracy. Teraz jestem na etapie, że w dni robocze mam blokadę 9:30-16:00 a w weekendy 12:00-19:00. Do tego w każdy wieczór między 20:00 a 21:00 – wtedy, gdy moje dziecko powinno (teoretycznie) zasypiać.

Cały czas czuję syndrom odstawienia, ale widzę w tym ruchu dużą wartość osobistą. Mam poczucie, że umiejętność odcięcia się od internetowego fastfoodu stanie się (staje się?) jakąś formą personalnej przewagi konkurencyjnej.

Smog

Co poszło nie tak? Największe pogorszenie mojego życia jakie odczułem to jakość powietrza w Warszawie i w sumie całej Polsce. Oczywiście zdaje sobie sprawę z tego, że to nie jest nowy fenomen, ale w 2017 był dla mnie szczególnie istotny bo uświadomił mi, że wychodząc w zimę na spacer po stolicy zmuszam moje dziecko do biernego palenia kilku papierosów. Najbardziej frustruje mnie bezsilność. Co mogę zrobić? Wstawić kilka oczyszczaczy do domu i przeczekać najgorsze, ale przecież to nie rozwiązanie, bo problem jest systemowy.

Jeśli miałbym się wyprowadzać z Warszawy, to jedną z głównych motywacji byłaby jakość powietrza.

Książki

Zaużyłem ciekawą zmianę w moim guście książkowym: w tym roku pojawiły się na liście biografie (Halik, Lem, Sat-Okh). Niespodziewałem się, że zaczne czerpać przyjemność w głębokim poznawaniu życia konkretnych jednostek. Do tej pory interesowały mnie bardziej tematy makro (idee, procesy, systemy, ) a nie mikro. Nie wiem z czym to jest związane, może to próba odnalezienia się w świecie, w ktorym nie istnieje platoniczny puryzm? Ludzie-wzory mają swoje ciemne strony, ideały nie są idealne, a dobre intencje mają niezamierzone konsekwencje…

Podmywanie fundamentów

W zeszłym roku pisałem o tym, że buduje osobiste ideologiczne fundamenty. Ten rok z kolei to czas ich podmywania na kilku poziomach. Szymon (w ramach Otwieracza) od samego początku atakował moją wiarę w technologiczny solucjonizm, ale w tym roku trafiał bardzo celnie. Moja wiara w obiektywizm nauki została zweryfikowana przez NN Taleba, opisującego jak ludzie się kaleczą siebie i innych metodą naukową. Moja wiara w samokorekcyjny mechanizm systemów państwowych została nadszarpana przez obecną sytuacją polityczną.

Ostatecznie jednak uświadomiłem sobie jedną rzecz: “puryzm” nie istnieje, to pojęcie platoniczne. Nie ma złych i dobrych ludzi – spektrum jest znacznie szersze i wszyscy się na nim poruszamy świadomie i nieświadomie (to mi pokazują przeczytane biografie)

Mam więcej wątpliwości niż rok temu. Nie czuję jednak, aby to było złe. Choć posiadanie ich jest mentalnie nieprzyjemne (nic tak nie ułatwia życia jak fanatycznie niewzruszony światopogląd) to jednak traktuję to jako coś pozytywnego. Tegoroczne lektury dały mi do zrozumienia, że posiadanie wątpliwości jest potrzebne do rozwoju.

Ewolucja myślenia

2017 to był klejny rok mojej ewolucji myślenia o sobie w kontekście rozwoju zawodowego. Mam poczucie, że kontynuuje proces jednoczesnego pogłębiania, ale i uogólniania tego, co czuję, że: powinienem robić, wnosi wartość i przynosi mi satysfakcję.

Na początku moich podsumowań opisywałem siebie jako specjalistę od aplikacji mobilnych (o tym napisałem w końcu książkę). Moje wnioski i doświadczenia zacząłem przenosić na pole rozwoju produktów technologicznych, a teraz czuję, że powinienem skupić się konkretnie na polu metod podejmowania decyzji w zarządzaniu produktami technologicznymi. To jest sfera, która mnie w tym roku najbardziej interesowała: dlaczego konkretne firmy podejmują konkretne decyzje; co pcha ludzi w stronę strategii A a nie B; jak dobrze decydować w przypadku niepełnych danych; modele podejmowania racjonalnych decyzji; sposoby dekompozycji decyzji i tym podobne. Mam poczucie, że to otwiera przede mną nowe obszary i daje nowe narzędzia do pracy.

Bycie ojcem, cz. 2

Dwanaście miesięcy w życiu dziecka to bardzo długo, ale mi minęło bardzo szybko, bo nie ma tygodnia, aby mój syn nie nauczył się czegoś nowego. Niemal naocznie widać jak formują mu się nowe umiejętności kognitywne, katalog rozpoznawanych rzeczy i czynności, rozpoznawanie emocji, kontrolowanie własnego ciała czy umiejętność mówienia “nie” (to pierwsza oznaka samoświadomości i poczucia odrębności). Co to oznacza? Że mogę mu powiedzieć, żeby wyrzucił papierek do śmieci i to zrobi. I jestem z tego dumny.

Staram się ze Stasiem spędzać jak najwięcej czasu, ale ma to swoją drugą stronę: przestałem być właścicielem tego czasu. Coraz mniej udaje mi się “oszukiwać” – dać dziecku zajęcie i samemu się zrelaksować. Młody już to wyczuwa. I tutaj znów nauczka z pochopnego oceniania innych: bardzo mnie oburzało jak widziałem matki i ojców rozmawiających w kawiarniach, gdy dziecko ogląda bajkę na Youtube. Jak oni mogą tak olewać jego wychowanie? Teraz już wiem: może oni po prostu zrozumieli, że najpierw sami muszą się dobrze czuć, jeśli ich dziecko ma się dobrze czuć.

Miałem w tym roku kilka sytuacji, gdy na parę dni byłem daleko od Stasia. I, przyznam się szczerze, czekałem na te momenty bo “odzyskiwałem” mój czas. Jednak po maksymalnie dobie docierało do mnie tak mocne poczucie tęsknoty, że traciłem energię do robienia tych wszystkich rzeczy, które tak bardzo chciałem w spokoju zrobić (a nie jestem ckliwym człowiekiem). Najbliższa rzecz do jakiej mogę to porównać to syndrom sztokholmski. A może po prostu to zwyczajna bezinteresowna, organiczna miłość.

Podróże

Mój dysonans spowodował, że niemal zapomniałem jak dużo miejsc udało mi się w tym roku zobaczyć. Zaczynając od pierwszego wspólnego wypadu na narty do włoskiej Marillevy 1400 (najbardziej brutalny brutalizm architektoniczny jaki widziałem), chwilę później powrót do San Francisco znów na zaproszenie Google’a, wakacje w Toskanii z całą rodziną w miejscu tak pięknym, że do tej pory nie mogę uwierzyć. I końcówka roku odwiedziny u mojego studiującego brata w Holandii.

Większość tych podróży odbyła się ze Stasiem. Jesteśmy żywym przykładem, że z dzieckiem, nawet najmniejszym, da się podróżować.

Na opak

Jako, że czerpiemy z Pauliną przyjemność z robienia rzeczy na opak to postanowiliśmy z Pauliną wziąć ślub, rok po tym jak urodził nam się syn. Zamast robić z tego pompę zorganizowaliśmy małe wydarzenie dla najbliższych w parku. Czy to coś zmienia w naszym życiu? Nie. Czy było nam potrzebne? Nie. Czy było warto? Tak, i niebagatelną rolę miało w tym dla mnie to, że wyszliśmy poza schemat i stereotyp.

Widzę ostatnio wyjątkowo dużo plusów społecznego “przesunięcia fazowego”: robienia rzeczy nie w czasie, w innej skali, w odwrotnym kierunku, po sezonie, poniżej radaru, poza algorytmem. Poza satysfakcją osobistą są także plusy ekonomiczne: rzeczy są tańsze i łatwiej dostępne a infrastruktura nie jest rozgrzana do czerwoności. Polecam na przykład wypad na basen, gdy wszyscy stoją w kolejce po zakupy świąteczne.

Podsumowując

Zabawna sprawa, która w tym roku odkryłem: faktycznie jest lepiej niż uważam, że jest. Gdy siadałem do tego podsumowania myślałem, że w tym roku mało podróżowałem, a tymczasem wyjeżdżałem częściej niż raz w miesiącu. Myślałem, że siedzę ciągle nieruchomo w pracy a 5-7h w tygodniu spędzam na intensywnej aktywności fizycznej (nie licząc bieganiem za dzieckiem:). Byłem przekonany, że mam mało czasu na czytanie a przecież mam przeczytane 23 książki (4 więcej niż w 2016). Skąd ten dysonans?

2017 to rok, który potwierdza jeden z moich wcześniejszych wniosków: dorosłość dla mnie oznacza zrozumienie, że jest się częścią większej całości. Nie byłoby mnie tutaj, gdyby nie ogromne wsparcie mojej wspaniałej żony, niekończącej się cierpliwości rodziców (i teściów!) i całej rzeszy ludzi, którzy czynnie i biernie pomagają mi realizować moje plany. Macie moją wdzięczność, nawet jeśli nie potrafię tego okazywać.

2018

Wchodziłem w 2017 rok zaniepokojony tym, co przyniesie nowy rok. Mam poczucie, że moje obawy są ciągle uzasadnione, ale odłożone na wysoką półkę. Mogą się zmaerializować, spaść i rozbić się z hukiem, ale to chyba jeszcze nie jest ten moment. Natomiast przyzwyczaiłem się, że one ciągle tam są i trzeba z nimi żyć.

Wchodzę w 2018 rok z poczuciem, że to nie będzie standardowy rok. Kilka osobistych i zawodowych inwestycji rozpoczętych we wcześniejszych latach może się w nim zrealizować co w połączeniu z sytuacją dookoła może mieć piorunujący efekt na życie moje i moich najbliższych.

Albo i nie. Przekonamy się!

Jak powstawały nowe produkty PizzaPortal.pl

To prawdopodobnie mój najdłużej pisany i najczęściej zmieniany tekst. Zacząłem w styczniu 2016 i pisałem go do teraz - na bieżąco uzupełniając o kolejne zwroty akcji. W związku z tym może się wydawać chaotyczny i niepoukładany - to efekt dodawania kolejnych zwrotów akcji.

Wstęp

Pierwszym punktem planu modernizacji produktowej PizzaPortal.pl była zmiana strony mobilnej. Opisałem to w poprzednim wpisie.

Następny etap to zmiana strona desktopowej. Około 70% wszystkich zamówień pochodzi u nas z “dużej” strony, więc wiedzieliśmy, że właśnie tutaj mieliśmy najlepszą dźwignię. Wdrożenie nowej funkcji na desktopie ma dziesięciokrotnie większy wpływ na biznes niż ta sama na stronie mobilnej (MW). Oczywiste jest więc, że ulepszanie desktopu to nasz najważniejszy cel produktowy – ale też jednocześnie największe ryzyko. Aby jednak nie wypuszczać się na głęboką wodę od razu rozpoczęliśmy zmiany od mniejszego kanału sprzedaży.

Nasza stara strona mobilna na dużym ekranie

Choć o tym nie mówiliśmy głośno, to tak naprawdę nasza nowa strona mobilna miała drugie dno. Jej rozkład był tak przemyślany, aby (koślawo, ale jednak) działała także na dużych ekranach. Choć nie było to optymalne rozwiązanie, to miało dla nas ogromne znaczenie strategiczne.  To fundament, na którym zbudowaliśmy nasz docelowy serwis www i z czego garściami czerpały nasze aplikacje mobilne.

Aby jednak dobrze opisać ten proces, muszę najpierw zrobić jeden krok wstecz i opisać naszą strategię produktową.

Strategia produktowa PP

Po jednej z niezliczonych dyskusji o przyszłości PP zapisałem sobie w notatniku, że nie wiem jakie nasze produkty mają być, ale “za każdym razem coraz lepsze”. To okazał się dobry punkt zaczepienia.

Im dłużej obracałem w głowie to stwierdzenie tym bardziej mi pasowało. Podobały mi się konsekwencje takiego postawienia sprawy, bo to oznacza, że:

  1. Nasze produkty nigdy nie są skończone. Widzimy swoje braki i ciągle je poprawiamy,
  2. Nie jesteśmy bezduszną maszyną; mamy charakter. Jesteśmy ludźmi, którzy korzystają ze swojego produktu,
  3. Jesteśmy częścią ekosystemu, zarabiamy na nim, ale “lepszy” nie oznacza tylko “generujący więcej pieniędzy”.

Brzmi górnolotnie, prawda? Ja jednak lubię mieć nad sobą konkretny sztandar i wiedzieć za czym stoję. Istotne teraz stało się przełożenie tych założeń w praktykę.

PizzaPortal.pl jest usługą masową, skierowaną w domyśle do każdego człowieka z dostępem do Internetu w Polsce. To oznacza, że produktowym imperatywem jest zapewnienie jak największej kompatybilności produktu z urządzeniami użytkowników teraz i w przyszłości.

Do tej pory byliśmy zmuszeni stopniowo “zamrażać” nasze kanały sprzedaży w celu zapewnienia ich zgodności z aktualnie najpopularniejszymi urządzeniami. To jednak zamykało nam coraz bardziej drogę do nowych technologii i typów urządzeń, czyli równaliśmy w dół.

Dodatkowa komplikacja wynikała z mnogości typów urządzeń użytkowników. Nasz statyczny serwis dawał nam bardzo małe możliwości w obsłudze coraz to nowych rozdzielczości, wersji systemów operacyjnych i przeglądarek. Zostawaliśmy w tyle, zamiast być coraz lepszymi.

Sposobem na rozwiązanie tego problemu było podejście catch-all. W systemach mailowych catch-all pozwala na przechwycenie poczty nawet gdy nadawca maila pomyli się w adresie – wystarczy jedynie, że @domena.pl będzie poprawna. To, co przed małpką już nie musi – system będzie wiedział, że mail miał przyjść do kogoś w ramach tej domeny, przechwyci go i wyśle pod adres “catch-all”. Dzięki temu poczta nigdy nie zaginie przez literówkę.

file-1

W przypadku PizzaPortal takim mechanizmem “catch-all” ma być właśnie nowy serwis www. To właśnie tam ma być zawsze możliwość zamówienia: gdy nie możesz (lub nie chcesz) zainstalować aplikacji mobilnej lub jeśli korzystasz z wyjątkowo egzotycznego urządzenia, masz po prostu normalny komputer, Smart TV, gogle VR czy telebim. Nie ważne, strona www zawsze ma działać, zawsze będzie wspólnym mianownikiem.

Z tej perspektywy nasza strona www ma być jednocześnie naszym najpopularniejszym kanałem sprzedaży, ale także planem awaryjnym (tzw. “fallbackiem”) jeśli inne, bardziej zaawansowane albo eksperymentalne kanały sprzedaży zawiodą.

Bycie coraz lepszym w internecie i w aplikacjach oznacza dwie różne rzeczy. Stało się dla nas oczywiste, że:

  1. Strona służy do budowania zasięgu, gdyż pozwala na najłatwiejsze odkrywanie nowych miejsc,
  2. Aplikacje służą do budowania lojalności, bo są bliżej użytkownika i gwarantują lepszy user experience.

Biorąc to pod uwagę wraz z podejście “catch-all” doszedłem do wniosku, że naturalnym rozwiązaniem będzie budowanie ścieżki, gdzie strona jest platformą, której zadaniem jest ułatwić pierwsze zamówienie (odkrywanie) natomiast każde następne powinno odbywać się w aplikacji (lojalność).

Trzeba zrobić dwie rzeczy, aby ten plan mógł się udać: nową stronę według zasad RWD i dwie bardzo dobre aplikacje mobilne (iOS i Android). Tutaj skupiam się głównie na kwestii RWD, ale przeplatam też tekście wątki o aplikacjach, które powstawały równolegle.

RWD

RWD (Responsive Web Design) to zestaw zasad, mechanizmów i wspierających technologii, które pozwalają tworzyć serwisy internetowe optymalnie wykorzystujące wielkość ekranu i typ interakcji. W dużym uproszczeniu: silnik strony sprawdza parametry urządzenia i serwuje na nie wersję serwisu, który najlepiej wyświetla się na komputerze, tablecie czy smartfonie. Zaleta tego podejścia leży w tym, że silnik i logika jest ciągle ta sama, więc nową funkcję wdraża się raz i jest dostępna we wszystkich wersjach.

Wadą jest jednak to, że wymaga znacznie większych zasobów w początkowym okresie, aby stworzyć spójną logikę systemu: na tyle elastyczną, aby dopasować się do różnych metod interakcji, ale także na tyle spójną, aby gwarantować poczucie ciągłości wśród użytkowników i minimalizować chaos organizacyjny w zespole produktowym.

Z moich obliczeń wynika, że inicjalne koszty (czyli czas) stworzenia naszego serwisu RWD były 2.5 wyższe w stosunku do postawienia trzech niezależnych wersji na smartfona, tablet i desktop.

Co daje nam taka inwestycja? Obniża się (w długim okresie) koszt obsługi kodu, czyli czas poprawy błędów i integracji nowych funkcji będzie relatywnie krótszy.

Przede wszystkim jednak stajemy się “screen agnostic”. Jednym produktem jesteśmy w stanie obsłużyć każde nowe urządzenie, niezależnie jakim miksem technologicznym jest – ogromnym smartfonem (phabletem), laptopem udającym tablet (MS Surface) czy tabletem o mocy laptopa (iPad Pro). Będziemy na to gotowi.

Zaczynamy

Nasz serwis mobilny dał nam dobre fundamenty w postaci opisanego wcześniej serwisu mobileweb – ale tylko tyle. Niemal z biegu, zaczęliśmy budować na tych samych zasadach i tej samej bazie serwis RWD (styczeń 2016).

Na bazie własnych wniosków z wywiadów i statystyk oraz dobrych praktyk w ramach DeliveryHero Holding zaczęliśmy przelewać pierwsze idee na papier wykorzystując Google Design Sprint. Tygodniowy proces zakończył się mnóstwem szkiców i wspólną wizją idealnego produktu.

Jeden z wielu szkiców stworzonych podczas Design Sprintu

Jednym z największych wyzwań każdego RWD jest przedstawienie sensownego układu stron przy zachowaniu spójności wizualnej, ale jednocześnie wykorzystać unikatowe przewagi każdej z platform. No i oczywiście zagwarantować dostępność technologiczną oraz zgodność z brandbookiem.

No pressure.

Kolorowa makieta Lo-Fi w Adobe Comp
Kolorowa makieta Lo-Fi w Adobe Comp

Mieliśmy na to kilka sposobów. Już przy pierwszej wersji strony mobilnej PP pojawił się górny czerwony pasek, który szybko stał się naszym znakiem rozpoznawczym. To szybka wizualna podpowiedź, że użytkownik korzysta właśnie z naszej strony. Ten czerwony pasek towarzyszy użytkownikowi na każdej wariacji strony i przy każdej rozdzielczości – tak samo jak niebieski pasek Facebooka.

Czwarty dzień tygodniowego Design Sprintu
Czwarty dzień tygodniowego Design Sprintu

Oprócz myślenia responsywnego trenowaliśmy projektowanie przepływu. Użytkownik rozumie korzystanie z serwisu jako serię logicznych i następujących po sobie akcji. Chcieliśmy więc zachować ten proces: najbardziej na lewo jest filtrowanie po kuchniach, później wybór restauracji oraz przeładowanie strony, następnie na nowej stronie menu tej restauracji i najbardziej na prawo koszyk. W ten sposób użytkownik mentalnie “przesuwa” się wraz z serwisem od lewej do prawej, od największego ogółu do faktycznego wyboru. Towarzyszą mu bardzo proste wizualne sugestie: akcje negatywne są zawsze w asyście czerwonego (wracanie, odejmowanie), a akcje pozytywne (dalej, wybierz, dodaj) w asyście zielonego.

Przepływ użytkownika
Przepływ użytkownika

Trafiliśmy więc szybko na jeden z największych problemów z przestawieniem się na myślenie RWD: element strony musi być zaprojektowany i wdrożony tak, aby był użyteczny niezależnie od szerokości ekranu. To wymaga modularności – większość przycisków, ekranów, mechanizmów musi być samodzielnymi jednostkami, niewymagającą wspierania się na innych, bo możliwe, że w innej rozdzielczości wspierające elementy będą już w innym rogu ekranu.

Szkice zaczęły się zamieniać w makiety, makiety w designy i szybko rozpoczęliśmy prace nad zamianą naszych pomysłów na faktyczny produkt, tak aby po zachować balans między wytycznymi.

Zmiana siatki w zależności od szerokości ekranu

Niestety nie wszystkie smaczki dało się powtórzyć na mniejszych urządzeniach ze względu na wielkość ekranów. Dlatego zarówno filtry jak i koszyk są ukryte pod dodatkowymi warstwami, które wjeżdżają nad główną treść strony gdy jest to potrzebne. W tym wypadku skorzystaliśmy ze sprawdzonych wzorców Material Design – języka wizualnego stworzonego w Google’u.

Strona RWD 320px i Android
Strona RWD 320px i Android

Zrobiliśmy tak, ponieważ Android ma dominujący udział w naszym ruchu mobilnym. Material Design został stworzony tak, aby był użyteczny zarówno na www jak i w aplikacjach, nie gryzie się też z naszą identyfikacją ani podejściem RWD. W ten sposób użytkownik, który wykonał pierwszą operację na webie nie będzie zaskoczony aplikacją na Androidzie. Wracamy tutaj do wyżej wymienionej potrzeby zamiany zasięgu w lojalność.

Wraz z uproszczeniem procesu zamawiania zmieniliśmy też strukturę informacji w serwisie – i to od razu na kilku frontach. Po pierwsze: wdrożyliśmy schema.org. Teraz dane dostępne w PP są łatwo przekładalne na wyniki wyszukiwań, więc użytkownik będzie widział, na przykład, godziny otwarcia restauracji lub oceny w naszym systemie jeszcze na poziomie wyników wyszukiwania w Google’u.

Poza tym zmieniliśmy mapowanie URLi i teraz ktoś, kto mieszka na Wąwozowej 11 w Warszawie może od razu trafić na listę wyników wpisując https://pizzaportal.pl/warszawa/restauracje/wawozowa/11 zamiast przechodzić przez cały flow.

Inna zmiana to bardzo intensywne stosowanie walidacji i wizualnych podpowiedzi. Chyba najlepiej to widać na ekranie checkoutu. Popełnienie błędu na tym poziomie jest dla wszystkich stron bardzo szkodliwe, dlatego robimy co możemy, aby użytkownik skupił się na poprawnym wpisaniu swoich danych i numeru telefonu. Robimy to przez oczywiste walidowanie ilości wyrazów i cyfr, ale także przez tunelowanie uwagi na tym, co właśnie teraz jest ważne.

Przykład tunelowania
Przykład tunelowania

Transformers

Nasze wewnętrzna badania potwierdziły dosyć oczywistą prawdę, że im strona jest szybsza tym konwersja się zwiększa. Dlatego na poziomie infrastrukturalnym zależało nam posiadaniu platformy, która jak najszybciej zaserwuje nam potrzebne dane. Aby zrozumieć co to znaczy, muszę pokazać większy kawałek układanki – jak już wspominałem we wpisie o MW: produkt to nie tylko produkt, ale także jego infrastruktura.

W naszym przypadku były dwa kluczowe elementy tej infrastruktury: nowa platforma z bazą danych oraz nowe API (“API 2.0”). Cały projekt zamiany infrastruktury spoczywa na barkach szwedzkiego zespołu OnlinePizza (to nasza spółka-matka; współdzielimy z nimi backend) i nosił nazwę kodową “Transformers”.

Nowe platforma i API to dla nas bardzo ważna sprawa: pozwala na dwukrotnie szybsze wdrażanie zmian, nie mówiąc o skalowalności i otwarciu na zupełnie nowe technologie i lepsze zarządzanie obciążeniem systemu.

W idealnym świecie te elementy powinny być gotowe na samym początku, zanim zaczniemy prace nad nowymi produktami dla konsumentów. Ale każdy product owner Wam powie, że nie istnieje idealny świat (to jest argument za tym aby wyrzucić do kosza większość teorytycznych porad jak powinno się tworzyć produkty cyfrowe). Tworzenie produktów zawsze odbywa się w mało sterylnych warunkach.

Nasze nowe API spóźniało się na tyle, że podjęliśmy decyzję o stworzeniu pierwszej wersji nowej strony w oparciu o starą infrastrukturą z okrojoną funkcjonalnością. Z tyłu głowy mieliśmy myśl, że w tym czasie przyjdzie moment, że backend dojedzie, a my tylko podmienimy wcześniej przygotowaną warstwę komunikacji na API 2.0 i będziemy na tym wdrażać już czekające funkcje.

I wtedy API 2.0 zaczęło się spóźniać jeszcze bardziej (kwiecień 2016). W związku z tym dodaliśmy etap “Product gap” czyli czas, gdy nasze frontendowe minimum jest już gotowy, ale czekamy na API 2.0. W trakcie tej przerwy budowaliśmy następne funkcje z naszego backlogu, także te, które miały się pojawić już po Transformersie.

Jednocześnie rozpoczęliśmy A/B testy nowej strony zwiększając po malutku jej udział w ruchu z 1% do 5%. Dzięki temu mogliśmy na żywym organizmie sprawdzić wszystkie podstawowe metryki nowej strony jak bounce rate, czas ładowania, konwersję, ścieżki przepływu użytkowników itd.

Timeline prac nad produktami PP
Timeline prac nad produktami PP

Ostatni etap to faktyczne przejście na nową platformę. Ze względu na specyfikę tej zmiany switch musi się odbyć jednocześnie na wszystkich platformach, aby wyeliminować duplikację danych w różnych bazach danych. Ale z perspektywy kwietnia 2016 mieliśmy jeszcze dużo czasu na pracę nad naszymi odcinkiem: przyśpieszaniem i uszczelnianiem i upraszczaniem aplikacji klienckich.

Przyśpieszanie

Po wdrożeniu testowej wersji zacząłem zbierać informacje o szybkości działania stron podobnych usług – naszej konkurencji i naszych znajomych z DeliveryHero. Korzystając z Webpagetest.org zbierałem dane o szybkości ładowania strony listy restauracji dla przykładowego adresu. Webpagetest jest dobrym narzędziem, bo badania odbywają się na faktycznym komputerze z faktyczną przeglądarką w kraju gdzie usługa jest aktywna. Jest więc wiarygodnym sposobem na porównywanie jakości stron.

Moim celem było doścignięcie szybkości strony naszego flagowca czyli niemieckiego Lieferheld. Jako bazę dałem sobie wtedy dostępną desktopową stronę PizzaPortal.pl, której loadtime wynosił 17,64 sek.

Zmiany w szybkości ładowania nowej strony PP
Zmiany w szybkości ładowania nowej strony PP

Jak widać nasza pierwsza wersja RWD jest niewiele lepsza od starej strony. Jednak po każdym refactorze kodu było coraz lepiej, aż dotarliśmy do loadtime ponad trzykrotnie lepszego od bazowego desktopu. Co więcej: przez chwilę nieznacznie wyprzedziliśmy nawet Lieferheld i Grubhub! Ostatecznie jednak czas się nieznacznie wydłużył ze względu na konieczność dostosowania się do docelowych serwerów, dodania marketingowych trackerów i wykorzystania grafik o większej rozdzielczości.

Jeszcze sporo przed nami, ale postawiłem tutaj nowy cel do osiągnięcia: przekroczyć psychologiczną barierę dwóch sekund. Jeśli nam się uda, będziemy najlepsi w branży na całym świecie. A widzimy jeszcze sporo miejsc, w których możemy optymalizować, choć wchodzimy już w dywagacje o obciążeniu infrastruktury dostawców Internetu w Polsce.

Uszczelnianie

Innym wyzwaniem jakie przed nami stało to eliminacja wszystkich istotnych błędów związanych z renderowaniem stron. Nie ma znaczenia jak szybko działa strona, jeśli wyświetla się niepoprawnie. Tym bardziej, że jak najszersza dostępność naszej usługi jest kluczowym elementem strategii produktowej.

Po głębszym badaniu danych z Google Analytics stworzyliśmy listę 37 kombinacji urządzenie + przeglądarka w których widzieliśmy duże niekorzystne odchylenie od średniej konwersji. Aby wiedzieć, które przypadki badać najpierw zrobiliśmy przy każdym przypadku symulacje ile więcej zamówień (oraz pieniędzy) miesięcznie by nam przybyło, jeśli konwersja wróci do standardowej wartości (przy założeniu, że ruch będzie podobny).

Lista najgorzej performujących wariacji
Lista najgorzej performujących wariacji

Mając to pod ręką zaczęliśmy pracować nad uszczelnianiem RWD uwzględniając przeglądarki z listy. Często jednak okazywało się, że pewne aspekty renderowania stron, które dla nas są kluczowe nie współgrają z daną wariacją urządzenia i przeglądarki. Wtedy patrzyliśmy na jakie ryzyko biznesowe się wystawiamy i jeśli nie była to popularna kombinacja odcinaliśmy fragment długiego ogona wiedząc, że w ten sposób zyskamy czas na uszczelnianie tam, gdzie jest większe natężenie naszych użytkowników.

O stacku technologicznym i procesie produkcji samego kodu Senfino napisało dwuczęściowy artykuł tutaj i tutaj.

Upraszczanie

Szybkość wyświetlania stron i ich poprawne renderowanie i tak nic nie da, jeśli serwis jest chaotyczny i nieprzewidywalny.

W tym wypadku byliśmy brutalni i obcinaliśmy do kości wszystko, co nie było kluczową funkcją systemu. Pierwsza wersja strony wystartowała bez jakiejkolwiek opcji sortowania oraz bez możliwości logowania i rejestracji użytkowników (co oczywiście oznacza brak historii zamówień i opcji ponownego zamówienia).

Skoro nawet tak fundamentalne rzeczy są niżej na backlogu, to praktycznie każda funkcja mogła iść pod nóż. To dobrze, bo zmusiło nas do odświeżenia myślenia i pozwalało zadawać twarde pytania “czy to jest przydatne?”. Dużo rzeczy okazało się po prostu nieprzydatne, ale dzięki temu zyskaliśmy klarowność, prostotę i spokój, tak potrzebny w dzisiejszej sieci.

Innym aspektem naszego upraszczania było rozpoczęcie współpracy z Fundacją Integracja, której pracownicy i testerzy pomogli nam zrozumieć jak wygląda Internet oczami i uszami osób niewidzących bądź niedowidzących. Jest to fascynujący świat, pełen niesamowitych rozwiązań i kultur.

W 2015 roku w Polsce żyło 1,8 mln osób niewidomych bądź słabowidzących. Już nawet pomijając kwestie czysto biznesowe (to świetny rynek dla takich usług jak nasza) uważam, że jest naszym obowiązkiem moralnym i etycznym, aby tworzyć produkty, które nie dyskryminują mniejszości, tak samo jak architekci obok schodów stawiają podjazdy dla wózków inwalidzkich.

Wszystko, co może pójść źle

Jednym z dokumentów, na który ciągle patrzyliśmy nazywał się “Missing features” – zbierał wszystkie funkcje, których brakowało do odtworzenia możliwości starej strony. Dotyczyło to głównie kwestii administracyjnych i logistycznych (jak zmiany w wystawianiu faktur dla restauracji). Głównym celem było zapewnienie naszym działom jak najszybciej ciągłości procesowej i ograniczać zamieszanie związane ze zmianą.

Na przykład: nasz dział sprzedaży sprzedaje coś, co nazywa się “premium placement”. To gwarancja pojawienia się na liście wyników na samej górze dla danego adresu (tak jak reklamy w wynikach Google). Ta sprzedaż odbywa się z góry za następne tygodnie i miesiące, co oznacza, że miejsca w nowym systemie zostały już sprzedane – a więc muszą się pojawić

Ale najważniejszy dokument nosił niezwykle przyjazną nazwę “All the things that could go wrong”. Lista szybko spęczniała do 70 bardzo poważnych lub krytycznych rzeczy, które muszą działać, abyśmy mogli uznać, że migracja odbyła się pomyślnie. Każda z nich, jako samodzielne wydarzenie, ma niskie prawdopodobieństwo na zaistnienie. Ale gdy mamy cały worek to ryzyko wzrasta. Zresztą, mówimy tutaj o migracji serwisu, który generuje sześciocyfrowe ilości zamówień miesięcznie, co przekłada się na dziesiątki milionów dokumentów w bazie danych. Nie ufajcie nikomu, kto mówi, że jest w stanie bezbłędnie przeprowadzić taki proces.

file-7
Wycinek listy rzeczy, które muszą działać

Takie wydarzenie to gwarantowany ból głowy, bo oznacza jakąś formę niewydolności systemowej, która odbija się na użytkownikach, a to rozpoczyna lawinę. Na przykład problem z mailem potwierdzającym zamówienie powoduje zwiększenie zapytań do naszego Customer Care, który powoduje wydłużenie czasu oczekiwania na połączenie innych dzwoniących. Naczynia połączone.

Od czasu stworzenia listy walczyliśmy z każdym punktem na liście. Lista była podzielona na kategorie: “Product”, “Marketing”, “Sales”, “Customer Care”, “Finances” i “HR”, a każdy element na niej był sprawdzany (checked) i dodatkowo sprawdzany (doublechecked) przez dwie niezależne osoby, aby wychwycić błędy ludzkie. Dopiero gdy element został pozytywnie zweryfikowany był traktowany jako checked positive.

Rozkład statusów krytycznych elementów systemu przed startem
Rozkład statusów krytycznych elementów systemu przed startem

Jak widzicie, nawet przy Final Check były rzeczy na “not sure” i co gorsza “checked negative”. Wynikało to z faktu, że niektórych elementów nie da się sprawdzić w 100% w testowym środowisku: na przykład płatności, struktury redirectów domen czy kampanii SEM. To mogliśmy sprawdzić jedynie na żywym organizmie, co mnie bardzo stresowało.

Lista 70 punktów to oczywiście rzeczy, o których wiedzieliśmy. A jest jeszcze katalog rzeczy o których nie wiedzieliśmy. Oraz tych o których nie wiedzieliśmy, że nie wiemy – ale dowiemy się po starcie.

I faktycznie po premierze katalog błędów wzrósł do 79. Wspominałem już, że nie istnieje idealny świat? Nie wyprzedzajmy jednak faktów, jeszcze przyjdzie na to czas.

Falstart

Start nowego systemu planowaliśmy na 29 czerwca. Już nawet nie liczyliśmy, który z kolei to był ostateczny deadline, ale prawdopodobnie około szóstego.

Dwa dni przed planowanym startem wszystkie zaangażowane strony rozsiane między Sztokholmem, Berlinem, Łodzią i Warszawą uczestniczyły w telekonferencji i deklarowały poziom gotowości.

Po tylu miesiącach pracy, ciągle odkrywanych nowych komplikacjach, czasami nieprzespanych nocach przez programistów oraz rosnących oczekiwaniach biznesu, każdy miał psychologiczną potrzebę wreszcie zakończenia tego bolesnego etapu i wyjścia wreszcie na głęboką wodę. Panowało ogólne przekonanie, że jesteśmy już tak blisko, że wszystkie obecne problemy to po prostu strach przed zmianą. Jeśli będziemy pozytywnie nastawieni wszystko nam się uda.

Wszyscy tak myśleli oprócz mnie. Choć czułem, że kopię leżącego (i w ten sposób także siebie) to jednak nie potrafiłem dać zielonego światła z czystym sumieniem. Zbyt dużo błędów jeszcze widzimy, zbyt duża jest niestabilność nowego API. Do tego nasze zespoły w Polsce i Szwecji zbyt długo pracowały i są po prostu przemęczone. Wykonali świetną robotę, ale nawet najlepsi programiści muszą kiedyś spać (ale zadziwiające ilu z nich jest w stanie oszukiwać samych siebie, że są nieśmiertelni).

Bałem się, że zaraz po premierze całe ciśnienie opadnie, wszyscy przybiją sobie piątki i wezmą urlopy. A właśnie wtedy będą najbardziej potrzebni. Premiera produktu brzmi jak dobry kamień milowy, ale to właśnie wtedy jest najwięcej pracy. Start to dopiero pierwszy test systemu w pełnej skali, dopiero teraz zaczną się pojawiać prawdziwe problemy, bo użytkownicy to najlepsze generatory wyjątków.

Kto więc będzie miał energię, aby znalezione problemy naprawiać, gdy wszyscy będą wypaleni sprintem na tą iluzoryczną datę premiery produktu?

Było mi bardzo ciężko być posłańcem złej nowiny, ale gdy wreszcie powiedziałem co myślę, klapki hurraoptymizmu powoli zaczęły opadać. Gdybyśmy byli świeżym startupem to wręcz naciskałbym na jak najszybszy start i naprawianie dziur w locie. Nie możemy jednak tak zrobić, gdy obsługujemy sześciocyfrową liczbę zamówień miesięcznie. To zupełnie inny poziom odpowiedzialności.

Nawiasem mówiąc to także przeoczony czynnik przewagi startupów nad dorosłymi firmami – brak (albo mała) baza użytkowników to mniejsze ryzyko i większa ochota na eksperymenty.

Tym razem, zamiast dawać sobie kilka dni więcej zdecydowaliśmy się na 2 tygodnie przerwy, podczas których zespoły będą miały czas na relaks, odseparowanie się od pracy i regenerację. Tak, wiem, że mało kto zdjął z siebie w pełni ten balast zbliżającej się premiery, ale była to niedogodność, którą musieliśmy zaakceptować.

Nowa data to 12 lipca. My tak zdobyte dwa tygodnie przeznaczyliśmy na bardziej agresywne testy stabilności, aby wykryć resztę niedociągnięć. Byliśmy w śmiesznej sytuacji: im mniej błędów znajdziemy tym lepiej… Ale zarówno im więcej błędów znajdziemy tym lepiej.

Proszę wyłączyć te błędy na produkcji

Największa migracja w historii naszych firm zacznie się o 0:01 we wtorek 12 lipca. Noc z poniedziałku na wtorek wybraliśmy specjalnie, bo na początku tygodnia rano mamy najmniej zamówień, ale też chcieliśmy, że każdy pracownik mentalnie wrócił już do pracy po weekendzie. Nasz release plan liczył 48 podpunktów z podziałem na rzeczy do zrobienia po stronie backendu i frontendu.

Nasz polski dział produktu w tym planie uaktywniał się o 8:00 rano, a o 9:00 według planu mieliśmy ruszyć z nową stroną. Faktycznie ten start odbył się dopiero o 10:30, w ostatnim momencie przed rozpoczęciem lunchowej fali zamówień.

Razem z Adamem obserwujemy start nowego serwisu
Razem z Adamem obserwujemy start nowego serwisu

W międzyczasie niemal wszystko co mogło nam popsuć start się wydarzyło – łącznie z niedziałającym chwilo Internetem w budynku i odkrytym w ostatnim momencie błędzie w aplikacjach mobilnych.

Gdy minął dzień mogliśmy oszacować nasze wyniki. Biorąc pod uwagę jak duża to była zmiana spodziewaliśmy się mocnych spadków zamówień wywołanych zamieszaniem. Mentalnie już dawno spisałem ten dzień (a nawet tydzień) na straty jeśli chodzi o liczbę zamówień. Byłem jednak zaskoczony, że mimo tylu krytycznych rzeczy, które się rozłożyły osiągnęliśmy średnio 65% zamówień z analogicznego dnia w poprzednim tygodniu.

Baliśmy się, że nowy wygląd strony będzie zbyt dramatycznie różny od tego, do czego przyzwyczaili się użytkownicy. Przyzwyczajenia jednak mają to do siebie, że ich zmiana boli tylko przez chwilę… A nowe i lepsze staje się przyzwyczajeniem bardzo szybko. Byliśmy za to często chwaleni za szybkość strony, minimalizm i łatwość zamawiania.

Na powierzchni było wszystko ładnie, ale pod spodem kipiało. Nasz Customer Care nie nadążał z odbieraniem telefonów i odpisywaniem na maile. Dzwonili restauratorzy, którzy nie połapali się w nowym systemie, użytkownicy, którym zamówienia nie przyszły (albo tacy, którzy dostali maile, że zamówienie anulowano, ale jednak przyszło). Do tego cały czas dochodziły problemy skali, których się spodziewaliśmy, ale na które nigdy do końca nie da się być przygotowanym.

Dodatkowo okazało się, że niezależnie od wcześniej wspomnianych nieoczekiwanych błędów jest jeszcze jeden, który potęguje pozostałe: z niewyjaśnionych przyczyn nasza baza danych zapycha się ze względu na zbyt dużo zapytań. Takie zapchanie powoduje, że pojawiają się rozbieżności między tym, co się faktycznie stało (zamówienie potwierdzone), a tym co mamy w systemie (zamówienie anulowane) bo dane nie docierają do bazy na czas.

Gdy osiąga się odpowiednią skalę, to takie problemy są gwarantowane (to jeden z powodów dlaczego systemy bankowe tak rzadko są aktualizowane; lepiej nie ruszać jeśli działa). Mamy tysiące restauracji, z których każde menu na minimum 20 pozycji. Liczba kombinacji zamówień jest tak duża, że fakt błędu technicznego bądź przy imporcie danych to nie jest coś nad czym się zastanawiamy – to, coś co na pewno się zdarzy.

Gdy ma się tego świadomość, to łatwiej się przyjmuje taki stan rzeczy; zdecydowanie łatwiej rozwiązuje się problemy skali gdy nikt nie biega panikując i machając rękami. Skrajne przypadki ze względu na swoją naturę są najgłośniejsze i wypływają na powierzchnie – mimo, że jest ich mniej to zajmują nieproporcjonalnie dużo energii umysłowej.

W środowisku lean startupowym lubi się mówić, że pierwszej iteracji każdego produktu powinno się wstydzić – inaczej wystartowało się po prostu zbyt późno. Tak właśnie było u nas. Cały tydzień od startu debatowaliśmy czy lepiej łatać nowy system czy wrócić do starego. Każdego dnia liczba zamówień oscylowała w granicach 50-70% poprzednich poziomów, ale teraz, gdy już nowa strona się opatrzyła powinniśmy zacząć przebijać stare wyniki zamówień, a nie ciągle się wykrwawiać.

Choć głosy o potrzebie powrotu do starego systemu były coraz mocniejsze to jednak zdecydowaliśmy się pozostać z nową infrastrukturą i systematyczne naprawiać największe błędy. Ustalaliśmy codziennie z zespołem top 3 największych problemów związanych z systemem. Na bieżąco, jeden po drugim je usuwaliśmy wygrzebując się z tej stresującej sytuacji. Na szczęście nasza nowa strona sprawowała się świetnie, więc całe nasze zasoby skierowaliśmy na pomoc szwedzkiemu zespołowi backendowemu. Wygrzebanie się z tych problemów zajęło nam pięć dramatycznych i wyczerpujących emocjonalnie tygodni.

Cztery tygodnie z tego zajęło nam przywracanie bazy restauracji do stanu standardowej używalności. Niemal co dzień znajdowaliśmy problemy wynikające z braku (bądź zbyt luźnej) walidacji danych: od brakujących sosów, przez brak adresów po konfliktujące godziny otwarcia. Stosowaliśmy wszystkie możliwe sposoby – walidację przy importach, skrypty scrapujące nasz własny serwis po zewnętrznych testerów. Kombinacja tych wszystkich metod i tytaniczna praca wykonana przez Adama (drugiego obok mnie product ownera w zespole) pozwoliła nam wrócić do poprzedniego stanu.

Gdy już wykaraskaliśmy się z problemów z bazą danych dostaliśmy sygnał od berlińskiego zespołu SEO, że coraz gorzej jest z indeksowaniem nowej strony – codziennie traciliśmy 2-3% ruchu z SEO. Było to dla nas szokujące, bo przeszliśmy trzy niezależne audyty SEO oraz tworzyliśmy strukturę dokładnie z wytycznymi Google’a.

Niestety okazało się, że dokumentacja Google’a jest trochę zbyt optymistyczna względem rzeczywistości i crawlery wyszukiwarki nie radzą sobie dobrze z dynamicznie renderowanymi stronami i cachem. Mimo tego, że Google utrzymuje, że potrafi takie strony indeksować to boleśnie przekonaliśmy się, że jest inaczej (zresztą tak samo jak Hulu).

Problemy z widzialnością strony
Problemy z indeksowaniem stron

W dużym skrócie problem polegał na tym, że choć użytkownik widział naszą stronę dobrze, że crawler Google’a nie potrafił jej wyrenderować i myślał, że tak samo ma żywy człowiek. Gdy jednak próbowaliśmy temu zaradzić narażaliśmy się na karę bo Google penalizuje (co jest zrozumiałe) witryny, które mają dwie różne wersje: jedną dla crawlerów i drugą dla użytkowników. Ostatecznie skorzystaliśmy z narzedzia prerender.io i nasz ruch z SEO zaczął się poprawiać.

Problem jest o wiele bardziej skomplikowany i wychodzi poza moje kompetencje, ale mam nadzieję, że ktoś to jeszcze dobrze opisze.

Wspominałem już, że nie ma świata idealnego? Trzeba się z tym pogodzić. Nie da się zrobić omleta bez rozbijania kilku jajek.

Branding

Zmiana wizualna nowej strony i aplikacji nie byłaby pełna bez nowego brandingu. Na początku wydawało nam się, że inkorporowanie nowego logo, ikon i teł będzie proste i szybkie. Okazało się, że zrobienie tego jednocześnie na każdej platformie (web, iOS, Android) gdzie wymagane są różne rozmiary grafik, a sklepy mają różny czas reakcji nie jest już tak banalne. Szczególnie, że musieliśmy się zsynchronizować z marketingiem, który podobne zmiany zrobił w swoich kampaniach reklamowych, mailingach i social media.

Nasz marketing wraz z brand teamem w Berlinie przygotował 4 propozycje logotypów i fontów do wykorzystania. Następnie wszystkie zostały wysłane do testowania wśród użytkowników, którzy informowali nas jak emocjonalnie konotują nowe wersje i która podoba im się najbardziej. Na szczęście okazało się, że ta, która podobała się mi jest jednocześnie najlepsza w oczach userów :)

Wariacje fontu
Wariacje fontu
fullsizerender-1
Nowe logo i ikona

Za zmianę brandu zdecydowaliśmy się zabrać dopiero półtora miesiąca po starcie RWD, ale dokładnie z momentem wdrożenia nowej aplikacji na Androida. Ciężko nam było myśleć o brandingu, gdy mieliśmy na głowie palące problemy z bazą danych. Gdy już jednak kurz opadł mogliśmy się zająć także tym i efekt był lepszy niż się spodziewałem:

Efekty

Największą zmianę widać przede wszystkim w wyglądzie serwisu. Tak strona PP wyglądała przed zmianą:

Stara wersja (wariacja szwedzka)
Lista restauracji w starej wersji (web, wariacja szwedzka)

A tak po odświeżeniu:

Nowa strona PizzaPortal.pl
Lista restauracji w nowej wersji (web)

Aplikacja na Androida:

Stara wersja aplikacji (Android)
Ekran restauracji w starej wersji (Android)
Ekran restauracji w nowej aplikacji na Androida
Ekran restauracji w nowej wersji (Android)

Sam wygląd to tylko powierzchnia – to, co faktycznie nas interesowało najbardziej to konwersja. W przypadku serwisów do zamawiania jedzenia patrzy się nie tylko na końcową konwersję, ale także na jej składowe, czyli tzw. mikrokonwersje. Mikrokonwersje to przepływy użytkowników pomiędzy głównymi etapami interakcji z serwisem. W serwisach do zamawiania jedzenia online (niezależnie od tego z jakiej są szerokości geograficznej) znajdziecie takie:

  • Home Page (HP),
  • Restaurant Listing Page (RLP),
  • Details Menu (DM),
  • Checkout Page (CP)
  • Order Confirmation (OC).

A więc mikrokonwersje, które nas interesowały to: HP>RLP, RLP>DM, DM>CP i CP>OC. Trzy miesiące po starcie, gdy nasze statystyki się ustabilizowały uzyskaliśmy takie wyniki:

HP>RLP +25,41%
RLP>DM +4,78%
DM>CP +29,29%
CP>OP +9,32%

Suma przyrostów mikrokonwersji przełożyła się na około 70% wzrost konwersji końcowej. To efekt przede wszystkim trzykrotnego przyśpieszenie ładowania strony, zmiany architektury informacji, minimalizację szumu informacyjnego w procesie zakupowym oraz zwiększeniu spektrum obsługiwanych urządzeń.

Całkiem niezłe sukcesy osiągnęliśmy także na polu SEO, mimo wcześniej opisywanych problemów. Na wykresie widać niebieską i pomarańczową linię – im jest niżej tym lepiej dla nas bo to oznacza, że jesteśmy wyżej w rankingach słów kluczowych.

Wzrost indeksowanych fraz i poprawa średniego rankingu słów kluczowych
Wzrost indeksowanych fraz i poprawa średniego rankingu słów kluczowych. Im wyższy słupek tym lepiej, im niżej linia tym lepiej.

Przeniesienie naszej strony na nową infrastrukturę oznaczało konieczność ponownego crawlowania przez pająki Google’a naszej strony i wszystkich przyległości (jak strony white labels czy landing pages). Zawsze zajmuje to trochę czasu i może skutkować chwilowym pogorszeniem wyników – na wykresie wyraźnie widać to na przy nagłym skoku linii do góry. Ostatecznie jednak nasza pozycja zaczęła wracać do normy a chwilę później zaczęliśmy czerpać pierwsze korzyści ze wdrożenia schema.org – zajęło nam około miesiąca, aby uzyskać najlepszą średnią pozycję w SEO od początku tego roku.

Wraz z premierą nowej wersji aplikacji podniosły się też oceny w Google Play:

Zmiana proporcji ocen po premierze nowej aplikacji
Zmiana proporcji ocen po premierze nowej aplikacji na Androida

To wszystko było możliwe, dzięki niezwykle skomplikowanej i bolesnej migracji na nową infrastrukturę. Choć jeszcze dużo jest do poprawiania to najważniejsze kroki już za nami: zmigrowaliśmy na nowy backend, nowa strona www oraz dwie całkowicie zmienione aplikacje mobilne. I to wszystko w ciągu niecałych 8 miesięcy. To, co teraz czeka produkt to mozolne ulepszanie na nowych fundamentach.

Zespół

Podczas spotkań zespołu w pokoju konferencyjnym w zależności od sytuacji siedziało 5 – 9 osób jednocześnie (a przewinęło się w sumie ze 20); podobnej wielkości był zespół szwedzki. Dodatkowe kilka(naście) osób wspomagało nas w Berlinie w zakresie brandingu, SEO i UX.

Trzonem całej układanki był zespół stworzony specjalnie dla PP w Senfino (czapki z głów Dawid, Kamil, Piotr, Paweł, Sylwek, Marcin, Zbyszek, Kuba, Grzesiek, Marta, Zuza, Olga oraz cała reszta!).

Specjalne podziękowania dla Adama, który przez brał na siebie najmniej wdzięczne elementy pracy product ownera, ale dzięki temu zna teraz produkty PizzaPortal lepiej ode mnie.

The end

…a tak naprawdę wcale nie. Choć zmiana infrastruktury i strony jest dla nas ogromnym kamieniem milowym to w gruncie rzeczy to tylko początek wdrażania strategii. Ostatni rok skupienia na zmianie infrastruktury dał nam wszystkim mocno w kość, teraz czas na realizacje wszystkich rzeczy, które obiecaliśmy, że staną się “po Transformersie”.

Personalnie był to dla mnie bardzo intensywny czas. To był największy proces zmiany technologicznej, jakim zarządzałem i sam już się gubiłem kiedy mój optymizm był marzeniem ściętej głowy, a kiedy ma solidne podstawy.

Ostatecznie, dzięki współpracy wielu zupełnie różnych zespołów rozsianych między kilka miast i organizacji udało nam się osiągnąć coś z czego jestem bardzo, bardzo dumny. Nawet mimo tego, że (autentycznie) pojawiły mi się pierwsze siwe włosy.