Natura przełomowej innowacji

Ten artykuł powstał na podstawie mojego wykładu „Wstęp do innowacji” prezentowanego 25.11.2018 podczas studiów Innovation and Technology Project Management na Collegium Civitas


Czym jest innowacja? To nowa metoda, idea, produkt. Pojemna definicja – na tyle szeroka, że można nią szastać na lewo i prawo, nazywając każdą ładną rzecz i sprytne zastosowanie innowacją.

Jest też pojęcie Disruptive Innovation („przełomowa innowacja”), które ma dokładną i konkretną definicję, a mimo to także używane jest jako frazes, a co gorsza, zamiennie z powyższym.

Chciałbym więc przeprowadzić Was przez fascynującą teorię Disruptive Innovation Claytona Christiensena i pokazać co naprawdę oznacza przełomowa innowacja i dlaczego powinna być podstawą przy strategicznym myśleniu o produktach technologicznych.

Teoria dyfuzji technologii

Teoria dyfuzji technologii mówi nam, że gdy na rynku pojawia się nowy produkt to reakcje ludzi można podzielić na pięć kategorii i korespondujących im worków:

  • Innowatorzy – mała procentowo grupa ludzi, którzy muszą od razu przetestować każdą nowinkę, nawet jeśli jest niedopracowana,
  • Prekursorzy –  trendsetterzy, którzy szybko adoptują nowe rozwiązania, aby podnieść swój status społeczny – mają wysoki poziom zaufania u innych grup,
  • Wczesna Większość – jeśli ta grupa zaczyna korzystać z technologii to znaczy, że stała się umasowiona i weszła do świadomości społecznej (przekroczyła tzw. „przepaść” z książki Geoffreya Moore’a),
  • Późna Większość – tak jak wczesna większość, ale mniej chętna zmianom w swoim życiu, 
  • Maruderzy – ostatnia grupa, najbardziej konserwatywna i nieufna rynkowi i technologiom
Rozkład normalny typów uczestników rynku

Jeśli zmodyfikujemy ten wykres tak, aby pokazywał popularność (lub efektywność) w czasie to zamiast rozkładu normalnego pojawi się charakterystyczna krzywa (żółta linia):

Taką krzywą nazywamy krzywą „S”. Jest to jedno z kilku podstawowych elementów potrzebnych do zrozumienia teorii przełomowej innowacji.

Pierwsza krzywa „S”

Co pokazuje krzywa „S”? Prześledźmy ją na bazie życia produktu. Gdy produkt debiutuje to zbiera inicjalną grupę użytkowników. Producent otrzymuje od użytkowników i rynku informacje czy i na ile produkt jest dobry i jakich poprawek jeszcze wymaga. Dzięki temu zaczyna się wspinać w kategorii jakości (lepsze materiały, lepszy proces produkcyjny) i popularności (lepiej odpowiada na potrzeby, poszerza grupę odbiorców). Produkt mocniej nasyca rynek i coraz lepiej realizuje potrzebę użytkowników aż do momentu osiągnięcia szczytu popularności

Rozpatrzmy przypadek firmy Kodak. W 1888 roku Kodak stworzył rewolucyjną innowację: rolkę fotograficzną, która zastąpiła szklaną płytę. Dzięki temu stały się dwie rzeczy. Po pierwsze profesjonalni fotografowie mogli robić zdjęcia szybciej i wygodniej mimo tego, że rolka miała gorsze parametry w stosunku do standardowych płyt do dagerotypów. Po drugie dzięki rolce aparaty fotograficzne stawały się użyteczniejsze także dla amatorów (którzy mieli dużo pieniędzy na takie zabawki) bo sama logistyka naświetlania i wywoływania zdjęć się poprawiła. To była prawdziwa przełomowa innowacja, zmieniające zasady gry.

1888 rok – pierwszy aparat Kodakam, z rolką filmową zamiast szklanej tacki

Wraz z sukcesem aparatu na rolkę rozpoczyna się kaskada zmian: firma musi przygotować się na zwiększenie produkcji, co oznacza konieczność posiadania większej struktury sprzedażowej i logistycznej, większych nakładów na reklamę, możliwe, że dodatkowej fabryki, która wymaga zewnętrznego finansowania i tak dalej…

Rewolucja rolkowa się zaczyna

To jest początek krzywej „S” tego produktu. Następnie popularność rolki wzrastała – rynek zaczął się przekonywać do tej innowacji, pojawiało się coraz więcej profesjonalnych i amatorskich fotografów, którzy z kolei generowali coraz większe zapotrzebowanie na rolki fotograficzne, które Kodak zaspokajał zwiększając produkcję.

Umasowienie produktu (czyli przeskoczenie przepaści między Prekursorami a Wczesną Większością) spowodował subtelną transformację strukturalną Kodaka. Widząc coraz większy sukces rolki, oczy i mózgi wewnątrz organizacji zaczęły budować procesy, które czynnie i biernie wspierały kurę znoszącą złote jajka: szkolenia sprzedawców, długoterminowe kontrakty z dostawcami, dystrybutorami i innymi partnerami, umowy z inwestorami i kredytodawcami, budowy nowych linii produkcyjnych… Ta naturalna odpowiedź podaży na popyt stworzyła w Kodaku zupełnie nową sieć wartości (Value Network, więcej o tym za chwilę)

W 1935 roku Kodak poszedł krok dalej i zaprezentował rolkę fotograficzną 35mm, której unowocześnione wersję możemy spotkać do tej pory w sklepach na całym świecie. Ta rolka była mniejsza i przyjaźniejsza w użyciu – mieściła się w kieszeni spodni i pozwalała na robienie 36 zdjęć na jedną sztukę. Wyparła z rynku poprzednią rolkę stając się światowym standardem – ale nie była przełomową innowacją.

Dlaczego?

Bo w sumie nic się nie zmieniło poza unowocześnieniem tego samego produktu: rolka jest mniejsza i przyjaźniejsza, te same procesy służą do jej produkcji, te same maszyny i fabryki, sprzedawcy sprzedają w ten sam sposób. Rynek kupuje „to samo, tyle że lepsze”. Ten typ innowacji nazywamy  Sustaining Innovation („innowacja podtrzymująca”).

Rolka fotograficzna przeszła więc przez krzywą „S” – jej początek to przedstawienie na rynku przełomowej innowacji elastycznej rolki, środek to proces ewolucyjnej, podtrzymującej innowacji. A to, jak wyglądał koniec dowiecie się niedługo.

Druga krzywa „S”

Teoria mówi, że prawdziwa przełomowa innowacja pojawia się w nieoczekiwanym miejscu i korzystając z odpowiedniego miksu warunków zewnętrznych (rynkowych) i wewnętrznych (organizacyjnych) zacznie wygrywać ze starymi, ustabilizowanymi, majętnymi graczami (którzy sami kiedyś byli innowatorami)

Dlaczego?

Dawny innowator wypierany przez nowego

Firma z produktem 1, który wygrał rynek i sprzedaje jego masowe ilości ma na sobie ciasny kaftan: użytkownicy przyzwyczaili się do jej oferty i nie chcą w nim radykalnych zmian (po co zmieniać coś co, działa?), z drugiej strony jednak liczą na to, że właściwości niefunkcjonalne bedą coraz lepsze (jeszcze lżejsze, jeszcze tańsze, jeszcze przyjaźniejsze itd). Firma, wbrew obiegowym opiniom, nigdy nie jest głucha na te słowa i robi co może, usprawniać swój produkt, nie niszcząc swoich procesów (zatrzymanie choć na chwilę fabryki produkującej masowo to ogromny koszt) . Robi to tworząc podtrzymujące innowacje zaspokajając coraz bardziej wymagające oczekiwania, daleko poza punkt w którym produkt jest „wystarczająco dobry”.

Wtedy jednak pojawia się konkurent, najpierw śmiesznie mały i godny zbagatelizowania. Z czasem jednak coraz szybszy i sprawniejszy – a gdy już przegoni starszego brata jest już dużo za późno żeby coś z tym zrobić. Cały ten dramat odbywa się w tym czerwonym kwadracie:

Dwie krzywe „S” w skali makro

Powiększmy go trochę i popatrzmy co tu się faktycznie dzieje:

Co się dzieje w „czerwonym kwadacie” – Dwie krzywe „S” w skali mikro

Dzięki doświadczeniu branżowemu i wielu cyklach produkcyjnych stary producent zbudował produkt, który jest dobry nawet dla najbardziej wymagających klientów. W tym samym czasie nowy producent wchodzi na rynek z czymś co jest gorsze technicznie i zaspokaja potrzeby o wiele mniejszego wycinka rynku.

Jednak brak ograniczeń widocznych u dużych przeciwników, mały przełomowy innowator może działać szybko i sprawnie – nie spowalniają go kwestie techniczne konkurencyjnych produktów, zalegające stany magazynowe, nie ma tak dużych zobowiązań i wewnętrznej konkurencji. Nowa firma dopiero „uczy się” czym jest jej produkt i czego chce konkretna mała grupa użytkowników. Bez tych ograniczeń może rosnąć dynamiczniej i zwiększać swój rynek znacznie szybciej niż stara konkurencja jest w stanie reagować. To wspaniały mechanizm rynkowego doboru naturalnego.

Sieć Wartości

Wróćmy więc do historii Kodaka. W 1975 roku Steven Sasson, inżynier w Kodaku, wynalazł pierwszy poręczny cyfrowy aparat fotograficzny. Był brzydki a rozdzielczość jego zdjęć (0.01 megapiksela) była katastrofalna, dając nieporównywalnie gorszy efekt od tych na papierze.

Related image
Pierwszy fotograficzny aparat cyfrowy

Miał jednak jedną zasadniczą przewagę: nie wymagał rolek (zapisywał dane na taśmie magnetofonowej).

Inżynier pokazał swój wynalazek swoim szefom myśląc, że trzyma w ręku przyszłość Kodaka, nazywając swój wynalazek „Film-less camera”. Co zrobili jego przełożeni? Zainwestowali w przełomową innowację czy zabili jego projekt?

Kodak kazał zamknąć pracę nad projektem i nigdy do niej nie wracać. Uznali aparat cyfrowy za, w najlepszym przypadku, stratę pieniędzy nad badaniami, a w najgorszym – strategiczne ryzyko.

Dlaczego?

Bo Kodak był firmą nastawioną na sprzedaż rolek filmowych – na to były zoptymalizowane wszystkie najważniejsze procesy, na to patrzyli szefowie, inwestorzy i reszta rynku oceniając progres spółki. Jeśli fotografia cyfrowa nie potrzebuje rolek to dlaczego Kodak ma inwestować w taką technologię?

Oczywiście obecnie błąd tego myślenia widać wyraźnie. Fotografia cyfrowa i tak się rozwinęła, niezależnie od starań Kodaka. Ale trzeba też zrozumieć motywację osób, które podjęły decyzje rezygnacji z tego projektu.

Wyobraźcie sobie, że jesteście dyrektorami w Kodaku w tamtym momencie. Kwartał za kwartałem stabilnie i przewidywalnie dostarczacie coraz lepsze wyniki, dostajecie coraz większe budżety do dyspozycji jako nagrodę za skuteczność. Każdy ma jasność co jest wartością biznesową i co warto robić: wsłuchiwać się w głos klienta i po trochu rozwijać produkt i dystrybucję aby nasycić rynek.

W pewnym momencie dowiadujecie się o jakimś małym projekcie, który zbudowany siłami jednego inżyniera redefiniuje to, w jaki sposób zaspokajana jest potrzeba, na którą do tej pory odpowiadały rolki fotograficzne. Cały biznes, który stał się częścią Waszego życia zawodowego, może okazać się niepotrzebny. Nawet jeśli jesteście w stanie zaryzykować i chcielibyście przestawić powolne koła wielkiej maszyny to co powiedzą Wasi szefowie? I szefowie Waszych szefów? Dlaczego mamy przestać inwestować w jasną i rozpoznaną drogę do zysków i w zamian za to przeznaczyć nawet małe środki w coś, co jest niejasne, nie wiemy jak działa i podkopuje przez tyle lat budowane fundamenty biznesowe? To przecież popsuje nasze wyniki kwartalne. Zdecydowalibyście się na taki karkołomny krok wiedząc jak dużo jest na szali?

Niemal nikt się nie decyduje.

To prawdziwy dramat w całej tej historii – nawet najlepsi menedżerowie w najefektywniejszych strukturach nie byli w stanie powstrzymać nieubłaganego walca przełomowej innowacji. Ta historia powtarza się ciągle, ale nawet widząc pierwsze sygnały nadchodzących kłopotów niewiele można zrobić – tak jak ze statkiem, który za wolno zmienia swój kolizyjny kurs. Tak duża jest siła Value Network, ludzkiego odpowiednika legacy code.

Sieć wartości jest głęboko zakorzeniona w kulturze firmy (czyli w tym co firma uznaje za istotne), w jej procesach (co optymalizuje), relacji z rynkiem (z kim podpisuje umowy), że niemal niemożliwa do wyeliminowania. Z tego samego powodu, dla którego Kodak nie patrzył łaskawie na fotografię cyfrową: zbyt dużo było do stracenia jeśli firma wyszła by ze swojej ścieżki najmniejszego oporu.

Każda firma buduje swoją sieć wartości, wraz z postępem krzywej „S” jej produktów. Nie oznacza to, że któreś konkretne sieci wartości są złe – po prostu mogą nie być dopasowane do zmieniającej się rzeczywistości.

Przypadek Blackberry 

Opisywałem poprzednio jak wygląda krzywa „S” i jaką moc ma Value Network w organizacji. Spójrzmy na jeszcze jeden przypadek: RIM, twórca smartfonów Blackberry.

RIM to kanadyjska spółka, która stworzyła nowy rodzaj telefonu komórkowego dla biznesu: z pełną klawiaturą i zbudowanym protokołem szyfrowania komunikacji. To były znaki rozpoznawcze tego produktu, a biznes go pokochał, bo po raz pierwszy można było napisać całego maila nie wyjmując laptopa.

BlackBerry 5810
Blackberry 5810 – pierwsza wersja z funkcją telefonu

Historia Blackberry, po całym cyklu krzywej „S”, jest zadziwiająco podobna do Kodaka. W pewnym momencie z zupełnie innego rynku pojawia się nieoczekiwany konkurent: Apple. Apple w 2007 roku prezentuje swój pierwszy telefon: iPhone. Steve Jobs ze sceny mówi jasno: fizyczna klawiatura zajmuje zbyt dużo miejsca – przyszłość należy do telefonów, które mają dotykowy wyświetlacz od brzegu do brzegu (fragment na ten temat zaczyna się w 5 minucie poniższego filmu, polecam jednak obejrzeć całość).

Steve równo w 5 minucie mówi o problemie fizycznych klawiatur

RIM zachował się tak jak przewiduje teoria przełomowej innowacji (zresztą jak każdy inny gracz na rynku – Nokia, Microsoft, Motorola czy Samsung): nie uznał, że iPhone stanowi zagrożenie, bo po pierwsze Apple nie ma doświadczenia w produkcji telefonów, ani kontaktów z telekomami a poza tym tworzy urządzenie dla prywatnych konsumentów, a nie biznesu.

Do tej pory to co było „smart” w smartfonach było definiowane przez biznes. Stąd sukces RIM i ich pełnowymiarowych klawiatur w smartfonach. Nikt nie widział potrzeby, aby taką kategoria urządzeń oferować segmentowi prywatnemu. Value Network RIMa był w zupełnie innym miejscu.

Nawet gdy Blackberry zauważyło, że iPhone rośnie coraz szybciej to bagatelizowało problem. iPhone okazał się ogromnym hitem. User Experience stał się tak ważnym elementem motywującym do kupna telefonu, że nawet użytkownicy biznesowi zaczęli przynosić do swoich biur prywatne iPhone’y żądając podłączenia do firmowej infrastruktury (tak upowszechnił się trend BYOD: Bring Your Own Device). Nagle użytkownicy końcowi zauważyli, że nie muszą się użerać z topornymi przydzielonymi przez dział IT urządzeniami. Użytkownicy biznesowi zaczęli oczekiwać telefonów równie przyjaznych jak ich prywatne. Punkt ciężkości na rynku przesunął się znacznie.

RIM trwało przy swoim podejściu: mamy własny rynek, mamy jasny wyróżnik: fizyczną klawiaturę, która jest po prostu lepsza od ekranowej (bo, na przykład, ma wyczuwalne przyciski i można na niej pisać bezwzrokowo). RIM jednak nie rozumiał, że klawiatura ekranowa w iPhone’ach była „wystarczająco dobra” do pisania a jednocześnie oferowała o wiele większą elastyczność, na przykład mogła się chować aby pokazać pełnowymiarową stronę internetową lub zdjęcie. 

RIM niechętnie podchodził do pracy nad wersją bez fizycznej klawiatury. Szybko rosnący udział iPhone’a i niedługo później Androida był stresujący, ale dopiero 4 lata po premierze młodszych konkurentów było widać realną zmianę rynkową. W tym czasie jednak Blackberry praktycznie stało w miejscu (ale mówiło, że słucha swoich klientów, którzy są zachwyceni fizyczną klawiaturą) a Apple i konsorcjum Android wspinało się coraz szybciej. Wreszcie, gdy otrzeźwienie przyszło, to było juz za późno. Projekty zmian był wewnętrznie sabotowane – z tych samych powodów co fotografia cyfrowa w Kodaku. Widzicie analogię do mojego wcześniejszego wykresu z czerwonym prostokątem?

I znów, zgodnie z teorią – Apple wygrało ten pojedynek.

Jak uciec spod walca?

Czy można uciec od tego nieubłaganego losu Kodaka, Blockbustera lub Blackberry?

Aby na to odpowiedzieć musimy najpierw przedyskutować dwie kwestie:

Pierwszy obrazek pokazuje tempo dyfuzji technologii na przykładzie USA przez ponad 100 ostatnich lat. To, co jest tutaj istotne, to że czas osiągnięcia poziomu 90%+ skraca się z każdą następną innowacją.

Nowe technologie bazują na starych: powstanie smartfona nie było możliwe bez powstania telefonu komórkowego. Powstanie telefonu komórkowego nie było możliwe bez telefonu a to bez telegrafu i tak dalej. Stare technologie tworzą grunt pod nowe – edukują użytkowników i budują infrastrukturę. Jaki z tego wniosek? Każda następna innowacja będzie adoptowana z coraz mniejszym oporem i stanie się kulturową oczywistością z coraz większym tempem. Zresztą – zobaczcie jak szybko naturalne stało się dla nas korzystanie ze smartfona i zapytajcie swoich rodziców o ich wrażenia z korzystania z telefonów stacjonarnych.

Drugi obrazek przedstawia koszmar każdego, kto chce budować trały biznes:

Wykres mówi nam jak długo żyje amerykańska firma w ramach S&P500, czyli 500 najwiekszych firm na amerykańskiej giełdzie. Ten czas fluktuuje, ale trend jest jasny: firmy żyją coraz krócej i krócej.

Łącząc ze sobą wnioski z obydwu wykresów można dojść do takiej konkluzji: firmy mają coraz mniej czasu, żeby udowodnić, że trzymają w ręku prawdziwą innowację a coraz więcej ryzyk, że konkurencja w ekspresowym tempie zdobędzie rynek nie zostawiając miejsca na dalszy rozwój.

Dlatego notujemy obecnie największy odsetek kapitału firm inwestowany w R&D. Firmy zrozumiały, że nawet jeśli tylko promil z tych prac obroni się na rynku to możliwe, że trafią na przypadek porównywalny do cyfrowego aparatu w Kodaku i tym razem nie przegapią tej okazji.

Trzecia krzywa „S”

Przejdźmy więc do zwycięzcy tego cyklu krzywej „S”. Apple zmiotło z rynku Blackberry i przy okazji Nokię (równie duże znaczenie miała też pojawienie się Androida i szybka ewolucja Samsunga, ale to historia na inny czas). Powstał rynek wysokomarżowych smartfonów łączących w sobie funkcje konsumenckie i biznesowe.

Pytanie brzmi: jeśli Apple zajął miejsce Blackberry, to kto będzie następnym Applem? Czyli, skąd przyjdzie następna krzywa „S”?

Oczywiście Apple chce, żeby następnym Applem był Apple. Tim Cook podsumował to najlepiej w 2013 roku:

Value Network tej firmy opiera się na założeniu, że Apple nie czeka aż ktoś go skanibalizuje, tylko chce zjeść samego siebie. Nie chce czekać, aż ktoś na nim wykona przełomowej innowacji. Ma tak zbudowane procesy, aby nie ograniczać swoich następnych produktów przez już istniejące na rynku.

Kilka historycznych przykładów:

  • iPhone posiada wszystkie funkcje iPoda Nano, najpopularniejszego odtwarzacza mp3 na świecie,
  • Pojawienie się iPada Pro z klawiaturą jasno uderzało w rynek Macbooków Air,
  • Obecnie Apple promuje Apple Watch z karta SIM i jasno mówi, że można z niego korzystać zostawiając swojego iPhone’a w domu.

W jaki sposób Apple uniknęło problemu wewnętrznej konkurencji? Przede wszystkim stosując inne metryki niż reszta firm. Tam gdzie Kodak liczył sprzedane rolki, a Blackberry sprzedane telefony, Apple liczy liczbę aktywnych użytkowników WSZYSTKICH swoich swoich urządzeń. Apple patrzy jak dużo nowych użytkowników może zdobyć i jak dużo zachować (artykuł na ten temat) i nie boi się zabić kurę znoszącą złote jajka jak tylko zobaczy potencjalne ryzyko przełomowej innowacji z nieoczekiwanej strony.

To jest pierwszy sposób na walkę z losem: być ciągle gotowym do ewolucji i umieć wyrzucać biznesowy balast gdy tylko się pojawi. Trzeba mieć do tego jednak odpowiednią kulturę organizacyjną, opartą na mierzeniu faktycznie trudnych rzeczy (satysfakcja użytkownika) zamiast powierzchownych „excelowych” faktów (sprzedaż).

Druga metoda jest jeszcze prostsza w teorii, ale jeszcze trudniejsza w implementacji: Ustabilizowany rynkowy gracz musi przede wszystkim zrozumieć cykl innowacji w którym się znajduje, następnie uświadomić sobie, że może być zniszczony przez nieoczekiwaną innowację a następnie konsolidować władzę nad każdym potencjalnym źródłem niebezpieczeństwa. Dzięki temu można zdecydować czy innowacja powinna być stłamszona w zarodku zanim dojdzie do dyfuzji technologii bądź dać wewnętrznie skanibalizować.

Nad żółtą linią źródła innowacji kupione przez Facebooka, pod żółtą linią te jeszcze nie kupione

Firmy takie jak Facebook rozumieją, że ostatecznym zasobem jest uwaga konsumentów. Ten, kto kontroluje interakcję z użytkownikiem jest w stanie przetrwać pojawienie się nieoczekiwanej innowacji, gdyż ta innowacja nie ma miejsca, aby zyskać pierwszych użytkowników a później przeskoczyć przez przepaść do umasowienia. Ale tutaj wchodzimy w temat Teorii Agregacji na którą przyjdzie jeszcze czas.

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ę!