Kategoria: Dłuższy wywód

To, co nam się udaje, udaje się podwójnie ponieważ chcemy się tym chwalić. To, co się nie udaje chcemy ukrywać, bo pokazuje nie-100%-skuteczność, a to źle działa na wizerunek na fejsie. Nassim Nicholas Taleb w „Fooled by Randomness” walczy z archetypem zwycięzcy na wiele sposobów, ale najwyraźniej widać to na przykładzie giełdy. Opisuje wiele mechanizmów prowadzących ostatecznie do tego, że ludzie, którym wielokrotnie udało się dobrze obstawić uważamy za geniuszy o nadprzyrodzonych mocach mimo tego, że to, po prostu, statystyka (i survival bias).

W 2014 roku byłem zaproszony jako gość na Olcamp, olsztyńskie spotkania branży technologicznej. Paweł Harajda przedstawiając mnie poprowadził prostą linię pokazującą moją ewolucję zawodową – najpierw Aula Polska, później Proseed, później o2.pl, później Senfino (wtedy jeszcze książka była na bardzo wczesnym etapie). Nawiasem mówiąc, to była bardzo innowacyjna forma konwersacji – po każdym zadanym pytaniu osoby na scenie musiały wypić shota wódki (takie rzeczy tylko w Olsztynie). Uderzyło mnie wtedy (ze zdwojoną siłą dzięki alkoholowi), że patrząc z perspektywy czasu na moją przeszłość to faktycznie, wszystko ładnie się układa i do siebie pasuje. Poprzednie doświadczenia przydają się w następnej pracy: organizacja w Auli Polskiej dała materiały na łamy Proseeda. Praca w Proseedzie otworzyła drzwi do mnóstwa zamkniętych gabinetów… i tak dalej.

Ktoś patrząc z zewnątrz może mieć wrażenie, że to perfekcyjnie przygotowany masterplan a każdy kroczek przybliża do przysłowiowej dominacji nad przysłowiowym światem (dokumentuję ją na moim vanity page). Ale to bullshit, bo ta droga usłana była mnóstwem zakrętów i problemów, przez które do tej pory zgrzytam zębami (ale tego już w vanity page nie ma).

Dzisiaj zobaczyłem w sieci artykuł o anty – CV profesora z Princeton: listę wszystkich nagród, programów i grantów, których nie otrzymał. Czytając zacząłem sięgać do moje pamięci i tworzyć własną listę. Im dłużej grzebałem tym więcej sobie przypominałem:

• Nie dostałem się na studia dzienne. Wpakowałem w maturę całą moją energię i po wzorowym jej zdaniu puściły mi wszystkie nerwy. Zresztą uważałem, że skoro matura poszła super, to egzaminy na studią będą błahostką. NOPE. Nie dostałem się nigdzie, zawaliłem wszystkie wymarzone kierunki (tak się akurat złożyło, że chciałem iść na ekonomię na UW, SGGW i SGH –  mieszankę trudnych egzaminów i dużej popularności, not smart). Załamany tym wszystkim wybrałem pierwsze studia, które brzmiały sensownie, ale były na publicznej uczelni – wieczorową Europeistykę. Studia były płatne, więc przyjmowali wszystkich,
• 2009 rok, studia. Uważam, że musze skupić się na nauce (=imprezowaniu) i nie jestem stworzony do pracy. No chyba, że załapię się na jakiś program staży managerskich. Wziąłem udział w rekrutacji na taki program do firmy Emperia. Wyglądało to tak, że na przedmieściach Warszawy 10 studentów przez pół dnia siedziało w salce próbując rozwiązać wspólnie (ale rywalizując) case study. Nie miałem pojęcia co to case study. W każdym rogu pokoju siedziała osoba z HR skrzętnie notując nasze zachowanie. Nie dostałem się. Ale nie to było najgorsze, bo na koniec otrzymałem wyniki mojego „assessment center”: Skala była następująca: 0 (brak ujawnienia się kompetencji), 1 (bardzo niski poziom), 2 (niski poziom), 3 (przeciętny poziom)… dalej skala już mi się nie przydała.

• W tym samym 2009 roku pomyślałem, że skoro polskie firmy się na mnie nie poznały to trzeba poszukać szczęścia na zagranicznych uczelniach. Ambitnie wybrałem sobie dwa programy wymiany studentów: Monbukagusho Scholarship i stypendium Fulbrighta – nie mając ani odrobiny realnego researchu (o tym, żeby porozmawiać z absolwentami tych programów przyszło mi do głowy kilka miesięcy później). Najbardziej bolała negatywna odpowiedź z Fulbrighta – zabrakło mi 1 punktu, żeby się dostać. To było nawet zastanawiające, biorąc pod uwagę, że zapytany przez ambasadora USA nie wiedziałem jakie jest tuition na wybranej przeze mnie uczelni. Przy Monbukagusho trzeba było mieć formalną rekomendację Ambasady Japonii (ale o tym dowiedziałem się dużo po fakcie), więc nawet mi nie odpisali,
• Moją niechęć do pracy kontynuowałem w wyszukiwaniu sobie coraz to nowszych programów wyjazdowych. Studiując we Wrocławiu wkręciłem się w AISEC (międzynarodowa organizacja studencka) tylko po to, żeby móc wyjechać jak najdalej, najlepiej do Chin albo Indii. Aby to się mogło udać, trzeba było znaleźć w bazie danych organizacji kogoś, kto chciałby się ze mną zamienić miejscami i postudiować w Polsce tyle, co ja u niego. Uwziąłem się, żeby dziennie wysyłać 20 personalizowanych wiadomości i tak – było mnóstwo Chińczyków i Hindusów, którzy chcieli studiować za granicą, ale nikt nie chciał wymienić się ze mną. Nawet po 400 próbach,
• Cały czas będąc na moich wieczorowych studiach szukałem sposobu, aby przenieść się na dzienne, więc startowałem w rekrutacjach z nadzieją, że mi przepiszą wyrobione przedmioty. Rekrutacja po drugim roku – pudło na UW i pudło na SGH, rekruatacja po trzecim roku i znów pudło na UW i pudło na SGH,
• Gdy wreszcie zakończyłem studia Europeistyki po pięciu latach mój własny tata się mnie zapytał: „No dobrze synu, co teraz?”. A ja miałem pustkę, bo to, co potrafiłem wymienić to całkiem niezłe portfolio epickich pijackich imprez (lokalnie i zagranicą), kilka zwiedzonych krajów i siatkę znajonych z Erasmusa. Ale pytanie, jak zamierzam spieniężyć te assety pozostawało otwarte…
• …w związku z tym zrobiłem jedyną rzecz jaka przyszła mi do głowy: po raz czwarty wystartowałem w rekrutacji na SGH,
• aby znów się nie dostać. Ale „zapraszają na studia wieczorowe”,
• Zacząłem więc studia uzupełniające z „Finansów i Rachunkowości” na SGH, aby wreszcie nauczyć się czegoś, co da mi realne, potrzebne na rynku pracy umiejętności. „Finanse”, które były matematyką i „Rachunkowość”, która była dla mnie najnudniejszą rzeczą na świecie. Ale cieszyłem się bardzo, bo to SGH i znów byłem studentem,
• Jakimś cudem, przy piątej próbie, udało mi się dostać na studia dzienne na SGH – z których zostałem wywalony rok później przez błąd w systemie zaliczeń egzaminów,
• Gdy udało mi sie wywalczyć powrót na pełni praw stwierdziłem że nic mnie na tej uczelni nie trzyma. Moja ambicja dostania się na SGH została spełniona, ale do tego, żeby tam wytrzymać już nie miałem serca,

[mija kilka lat]

• Po jednej z burzliwych dyskusji z moim ówczesnym szefem zostałem poproszony na rozmowę z szefową HR. Szefowa HR w małym pokoiku bardzo delikatnie zakomunikowała, że w wprawdzie docenia moją pracę, ale jednak nie mam w sobie „tego czegoś”. Jestem za mało wytrwały, zbyt szybko się irytuję i powinienem mieć grubszą skórę – po prostu nie jestem dobrym materiałem na managera, szczególnie w nowych technologiach.

Nie, tutaj nie będzie porywającego, coachowego podsumowania typu „mogę wszystko!”. No, nie mogę wszystkiego. Ale na pewno znacznie więcej niż mówi mi ten pieprzony assessement center.

Wraz z objęciem roli szefa produktów w PizzaPortal.pl jednym z moich pierwszych zadań było zweryfikowanie stanu obecnych stron i aplikacji oraz przygotowanie planu ich rozwoju.

Zdecydowałem się zacząć od stworzenia zupełnie nowej strony mobilnej. To był wtedy (jeszcze) względnie mały procentowo kanał sprzedaży więc pozwalał na odważniejsze eksperymenty – nawet jeśli efekt finalny okaże się słaby to wpływ na bottom line byłby do przełknięcia. Z drugiej strony miałem przeświadczenie, że mobile web to klucz do odblokowania potencjału tego fragmentu rynku.

W połowie czerwca przejąłem więc kontrolę na rozwojem nowej strony mobilnej PP ustawiając jej powstanie jako podstawowy priorytet na 2015 rok. 21 grudnia, czyli prawie pół roku później, serwis publicznie wystartował i po miesiącu generuje 2.5-3 krotnie więcej zamówień niż poprzednia wersja. Poniżej przeczytacie jak do tego doszło.

Sytuacja zastana

Sam koncept na nową stronę mobilną pojawił się w organizacji jeszcze przed moim przyjściem. Jednak brak jasnej ścieżki spowodował, że kształt produktu wynikał z doraźnych potrzeb zaangażowanych działów. Gdy brakuje faktycznego właściciela filtrującego potrzeby interesariuszy to efektem jest „design by committee”. Prowadziło to do sytuacji, gdy nad jedną dostarczoną grafiką wypowiadało się dziesięć osób z których każda dodawała swoje 3 grosze. Dużo było opinii, mało decyzji.

Efekt był taki, że strona główna była przeładowana informacjami do tego stopnia, że na smartfonach naszych klientów nie mieściła się cała. Ale za to mamy duże logo! I do tego mówimy jak zamawianie u nas jest proste zamiast pokazać to na faktach.

 

Pierwszym krokiem jako Product Owner było zrewidowanie tego, co już zostało zrobione z tym, co faktycznie ma być zrobione. Każdy interesariusz dowiedział się, że to ja teraz ponoszę odpowiedzialność za produkt, co też daje mi prawo (i obowiązek) podejmowania decyzji o rozwoju produktu. Stałem się też SPOC (Single Point of Contact) dla wszystkich, którzy w jakikolwiek sposób byli zaangażowani w rozwój nowej strony mobilnej – niezależnie czy chcieli dodać istotną dla nich funkcję czy pytali się jaki ma być kolor przycisku.

W praktyce oznaczało to, że ciągle mówiłem „nie” we wszystkich możliwych odmianach („nie teraz”, „świetny pomysł na future dev”, „nie, dopóki X jest nie zrobione” itd.). Choć brzmiało to czasami oschle to jednak było potrzebne, żeby faktycznie wyklarować co ma faktyczną wartość i musi być zrobione najpierw.

Sprinty i maraton

Rytm pracy wyznaczały tygodniowe sprinty. W każdy poniedziałek kończył się jeden sprint i zaczynał następny. W tym czasie robiliśmy Review – podsumowanie zmian z ostatniego tygodnia oraz Planning czyli określenie pracy na nowy tydzień.

Pół dnia zajmowały nam te dwie czynności, ale dzięki temu reszta tygodnia była spokojna – choć pierwotnie narzut komunikacyjny wydaje się duży to wraz w wejściem w rytm pracy znacznie ułatwia komunikację a mi dawał kontrolę nad losem produktu.

Tygodniowe iteracje mają jeszcze jedną przewagę: jeśli prace idą w złym kierunku to można szybko reagować i robić korektę kursu minimalizując straty czasu i energii.

Każdy członek zespołu miał dostęp do backloga w Pivotal Trackerze, który stanowił nasze główne narzędzie planowania. W czasie tych 6 miesięcy pracy zostało dowiezionych 35 userstories podzielonych na niezliczoną ilość zadań.

Połączyłem Pivotala z naszym firmowym Slackiem więc każdy zainteresowany w organizacji widział od razu jeśli konkretne userstory zostało wzięte na sprint lub zmieniło swoje miejsce w backlogu.

Ślepe zaułki

W trakcie prac wpadliśmy na wiele pułapek. Dla mnie największa z nich to myślenie o zamawianiu jak o jednorodnym i jednokierunkowym procesie – tak jak przyzwyczaiły mnie do tego aplikacje mobilne. Jednak strona rządzi się swoimi prawami – użytkownik może pojawić się na niej w innym miejscu niż tylko strona główna – na przykład po wpisaniu w wyszukiwarce „Bobby Burger Kabaty” trafia na stronę tej restauracji w naszym systemie. Witryna wtedy musi w sprytny sposób przeprowadzić użytkownika przez proces uwzględniając, że wcześniej nie podał istotnych dla nas informacji.

Problem polegał na tym, że nie mieliśmy jego adresu więc nie mogliśmy mu powiedzieć czy może z niej zamówić – trzeba było przemyśleć jak obsłużyć taką sytuację, żeby nie zamknął strony wkurzony. W aplikacji jest to prostsze: nie zobaczysz listy restauracji jeśli nie wpiszesz swojego adresu.

To zbudowało w nas potrzebę myślenia „nieliniowego” przy korzystaniu z serwisu. Rozpisaliśmy jeszcze raz poszczególne etapy i podstawową logikę zamawiania uzupełniając ją o „zewnętrzny” ruch, który wchodzi na stronę gdzieś w trakcie zaprojektowanego procesu. Na to nanieśliśmy możliwość skakania między etapami i nasze możliwości przenoszenia danych wraz z użytkownikiem.

Taka wizualizacja była ważna, abyśmy wiedzieli gdzie powinniśmy utrzymywać zawartość koszyka użytkownika a gdzie możemy go już wyczyścić. Lub też, tak jak opisałem wyżej, kiedy wymagać podania adresu – przed pokazaniem restauracji czy dopiero przy próbie dodania jedzenia do koszyka. Długo się spieraliśmy co go wkurzy bardziej: brak możliwości sprawdzenia menu bez podania adresu czy poczucie straconego czasu po wybraniu dania gdy okazuje się, że restauracja nie dowozi do miejsca zamieszkania użytkownika.

Takich dyskusji mieliśmy mnóstwo – na przykład czy pozwalać usuwać produkty w checkoucie lub jaką ikona powinna przedstawiać filtrowanie.

Dodawanie, usuwanie i kompromisy

Każdy Planning to zderzanie priorytetów: czy lepiej poprawić design czy popracować nad SEO? Czy ulepszyć obsługę błędów, a może dodać filtrowanie? A może sortowanie wcześniej?

Dyskusje na ten temat długo ciągnęły się podczas naszych poniedziałkowych spotkań. Czasami ich efekty były sprzeczne z intuicją. Na przykład zdecydowaliśmy się wystartować stronę bez jakiejkolwiek opcji sortowania i filtrowania listy restauracji. O wiele ważniejsze było dla nas uruchomienie nowego serwisu, który już przy inicjalnych testach dawał lepsze wyniki niż zwlekanie aż dojedzie nowa funkcja.

I wiecie co się okazało? Nikt nie narzekał na brak filtrowania.

Staraliśmy się sprytnie przyśpieszać cały proces zamawiania. Jedna z największych trudności to wpisywanie adresu na klawiaturze telefonu. Dlatego zawsze pokazujemy podpowiedzi miast i ulic na bazie wpisanych liter.

Teraz jednak poszliśmy krok dalej i nawet bez żadnego wpisywania (wystarczy, że znacznik pokaże się w polu wpisywania, tzw. „focus na inpucie”:) pokazujemy pięć miast z największą liczbą zamówień w naszym systemie. Jest bowiem ponad 75% szansa, że zamówienie będzie pochodzić właśnie z jednego z tych miejsc.

Podczas prac nad mobile webem przeprowadzaliśmy znany z Google Ventures Design Sprint (książka na ten temat) zupełnie innego produktu. Jednym z wniosków, których się nie spodziewaliśmy (takie są najlepsze) było to, że użytkownicy często boją się zamawiać, jeśli nie mogą podać swojego numeru mieszkania na samym początku. Mają bowiem przypuszczenie, że nikt się ich o to nie zapyta w dalszym procesie zamawiania, więc ostatecznie ich jedzenie trafi do sąsiada albo na inne piętro.

Intuicja podpowiada, że im mniej pól do wypełnienia tym lepiej, ale nasi użytkownicy dali nam do zrozumienia, że jest pewna granica, po przekroczeniu użytkownik której traci kontrolę, a w efekcie zaufanie do procesu. Rozwiązaniem tego dylematu było dla nas dodanie nieobowiązkowego pola „nr mieszkania” na pierwszym ekranie.

Przez „środkowe” miesiące naszej pracy niewiele zmieniało się wizualnie. Ja sam jako Product Owner zaczynałem się frustrować jak zadawano mi pytania jak idzie projekt i jedyne co mogłem powiedzieć to, że dobrze – „programiści programują”. Tymczasem ja nie miałem co pokazać – zmiany wizualne w prototypie nie odzwierciedlają ogromnej pracy wykonanej na poziomie logiki systemu co daje poczucie, że nic nie posuwa się do przodu.

Ostatecznie jednak, gdy przyszła pora na łączenie ze sobą elementów widocznych dla użytkownika z faktycznych silnikiem to szybkość zmian była więcej niż satysfakcjonująca.

Jednym z naszych wąskich gardeł jest ekran konfiguracji dania. Ze względów logiki systemu, zaszłości technologicznych a przede wszystkim liczby możliwych konfiguracji  jedzenia ten ekran potrafił się ładować i przesyłać dane z opóźnieniem. To, z perspektywy użytkownika, mogło oznaczać, że strona nie działa. Aby zniwelować takie poczucie dodaliśmy… cóż, dodaliśmy to co wszyscy lubią najbardziej – GIFy:)

 

Jedną z głównych motywacji zmiany strony mobilnej była jej niska czytelność dla crawlerów wyszukiwarek przez co musieliśmy zwiększać nasze nakłady na SEM, aby nadrobić niską skuteczność SEO. Faktyczny problem powstał jednak, gdy Google ogłosił w kwietniu 2015 zmiany w swoim algorytmie, czego efektem było stawianie w wynikach wyszukiwania wyżej stron, które mają wersje mobilne. Branża SEO nazwała to „mobilegeddonem”. Dlatego tworząc nową stronę od samego początku myśleliśmy o transparentnej strukturze danych, łatwej do przyswojenia przez Google’a.

Testowanie

Nawet jeśli mobile web nie jest najważniejszym kanałem sprzedaży w PP to jednak proces podmiany starego serwisu na nowy musi być przeprowadzany w przewidywalny i bezpieczny sposób.

9 grudnia rozpoczęliśmy współpracę z zespołem A/B testów z naszego berlińskiego biura. Do tej pory ten zespół zajmował się optymalizacją poszczególnych elementów, aby małymi krokami podwyższać konwersję (np. przez zmianę koloru przycisków albo wielkości zdjęć). My natomiast postawiliśmy przed nimi zadanie na zupełnie nowym poziomie: a co jeśli chcemy zrobić split testy dwóch zupełnie różnych stron, aby sprawdzić czy to, co stworzyliśmy faktycznie działa w dużej skali?

To było poważne wyzwanie, które wymagało naukowego badania i skoordynowania kilku systemów (Visual Website Optimizer i Advanced Segmentation w Google Analytics) do badania efektów statystycznych z uwzględnieniem odpowiedniej wielkości próbki i poziomu istotności. Postawiliśmy na środowisku produkcyjnym alternatywną stronę z przedrostkiem beta i codziennie patrzyliśmy na raport z fluktuującymi wynikami % Delta eCom CVR.

Chcieliśmy nasze testy wykonywać w jak najmniej inwazyjny sposób więc zaczynaliśmy z niskiego pułapu i zwiększaliśmy z czasem próbkę. Na samym początku z całego ruchu wyznaczyliśmy i oflagowaliśmy 10% użytkowników, którzy zobaczą nową stronę mobilną. Następne 10% zobaczy starą stronę ale także zostanie oflagowana – jako grupa kontrolna. Pozostałe 80% ruchu nie uczestniczyło w badaniu.

Wraz z pozytywnymi efektami zwiększaliśmy obciążenie na 20% – 20% i ostatecznie 50% – 50%. To było przydatne także dla naszego zespołu developerskiego, który mógł badań w kontrolowanym środowisku obciążenie i szukać błędów, które mogą stawać się widoczne dopiero przy większej grupie realnych użytkowników.

Ship it!

Efekty testów przeszły całkowicie nasze przypuszczenia. Lech (CEO PizzaPortal.pl) gdy zobaczył wyniki testów zapytał się, ile tracimy dziennie pieniędzy nie mając już zaimplementowanej nowej strony. Gdy to obliczyłem to trochę pobladłem.

Co zrozumiałe, Lech mocno argumentował, abyśmy nie czekali już dłużej i upublicznili stronę jak najszybciej. Ja chciałem jeszcze dać sobie i zespołowi trochę czasu na następne poprawki i resztę funkcji, ale ostatecznie przyśpieszyłem start z 28.12 na 21.12.

I dobrze, że dałem się przekonać. Dopiero presja Lecha pozwoliła mi zauważyć, że mógłbym cyzelować produkt dodając „jeszcze jeden ostatni feature” w nieskończoność. Zreszta, mam takie tendencje patrząc po doświadczeniach z Play24.

Dzień deploymentu – poniedziałek 21.12-  to jednocześnie czas naszej firmowej wigilii w firmie. Gdy inni się bawili my nerwowo zerkaliśmy na telefony pod stołem obserwując na żywo, czy wszystko idzie dobrze, koordynując warszawski zespół developerski, szwedzki dział backendowy oraz nasz łódzko-berliński dział marketingu.

Tutaj jeszcze jedna nauczka: produkt to nie tylko produkt, ale także jego infrastruktura. Nie doceniliśmy ile zamieszania może wywołać podmiana klucza API, podmiana domen i rekonfiguracja usług trzecich w nowym produkcie. Najgorsze jest to, że za każdym razem jest to niezwykle indywidualna sprawa i tak rzadko wykonywana, że brakuje uniwersalnej formuły, dzięki której wszystkie kroki w odpowiedniej kolejności zostaną wykonane.

Efekty

Efekt możecie sprawdzić  tutaj.

Minął już miesiąc od startu tej strony – historycznie jest to dla nas zarówno najgorszy (Gwiazdka) jak i najlepszy czas (1-2 stycznia) jeśli chodzi o zamówienia. Mieliśmy więc możliwość przetestować skrajne sytuacje działania strony. I co się okazało?

Z najgorzej działającego kanału nowy Mobile Web awansuje bardzo szybko w naszym wewnętrznym zestawieniu liczby zamówień na dzień – od razu wyprzedził iOSa a teraz, wraz ze wzmacnianiem się SEO, wyrównuje się już z Androidem. Konsekwentnie, dzień za dniem generuje 2.5-3x lepszą konwersję od poprzedniej wersji. Jest jeszcze jedna wyjątkowa rzecz: nowy Mobile Web ma też najlepszy średni koszyk ze wszystkich kanałów – 40,5 zł. Te dwa fakty powodują, że nowy mobile web nagle stał się zauważalną częścią strumienia przychodów.

I choć pod względem optymalizacji czasu ładowania jeszcze długa droga przed nami to bardzo miło się patrzy na wyniki automatycznych testów Google’a które pokazuję maksymalną liczbę punktów w zakresie wygody użytkowników.

Mój pierwotny plan zakładał stworzenie nowej strony mobilnej w trzy miesiące. Ostatecznie zajęło to prawie dwa razy więcej czasu, co też przekłada się na znacznie wyższe koszty. To jednak jest jeszcze akceptowalne biorąc pod uwagę, że w międzyczasie zespół developerski nam się rozpadł (z pierwotnych czterech osób została tylko jedna) i należało go odbudować niemal od początku – i to w połowie prac. W większości przypadków taka sytuacja prowadzi do zabicia produktu i konieczności rozpoczęcia od nowa. Na szczęście Scrum i transparentność procesu pozwoliły, że nowy zespół szybko wdrożył się w produkt i w znacznym stopniu zniwelował opóźnienia.

Co dalej

Mam silne poczucie, że udało nam się zbudować dobre fundamenty do dalszej pracy a z każdą nową funkcją otwierają się także nowe możliwości. I choć przez te pół roku zrealizowaliśmy 35 userstories to mamy jeszcze 32 następne do wykonania (i ciągle przybywają nowe!). Jednocześnie doświadczenia zebrane przy tworzeniu nowego Mobile Web są dla nas podstawą do prac nad następnymi projektami – tym razem o skalę wielkości większymi. Trzymajcie kciuki!

Dziękuję obydwu teamom dzięki którym ten projekt był możliwy oraz za wiarę Lecha i całej PizzyPortal.pl w moje metody.

ps. w 2013 roku napisałem podobny tekst, ale o powstawaniu innego mojego projektu – Play24.