Prawdziwe oblicze pracy CTO w startupie. Rozczarujesz się, jak wiele w niej rutyny

Często spotykam się ze specjalistami technicznymi, którzy założyli startup lub właśnie się za to zabierają. Mówi się, że taki scenariusz dla programisty jest idealny. W rzeczywistości oczekiwania często odbiegają od rzeczywistości. Dowiedz się, jak od środka wygląda praca dyrektora technicznego.

Zdjęcie główne artykułu pochodzi z stocksnap.io

Mam nadzieję, że moje doświadczenie, które zdobywam na stanowisku CTO w Preply, pomoże młodym dyrektorom nie popełniać starych błędów. W końcu kamienie, o który potykają się osoby o umyśle technicznym, zwykle są bardzo podobne.

Sprawy osobiste: Czy programiście potrzebny jest startup?

Zanim zaczniemy pracę nad własnym startupem, najpierw należy zapoznać się z tzw. błędem przeżywalności — survivalship bias. Istota survivorship bias tkwi w tym, że otrzymujemy dużo informacji na temat grupy „ocalałych” i prawie żadnej o „pokonanych”. Wszystkie zasłyszane historie sukcesu startupów to kropla w morzu opowieści z całkowicie innym zakończeniem. Istnieją setki tysięcy tych, którzy nie przetrwali. Jeśli o nich zapomnimy, istnieje wysokie prawdopodobieństwo, że nie wymierzymy swoich sił na zamiary i prawie na pewno szybko wypadniemy za burtę.

Kiedy w 2015 roku trafiliśmy do akceleratora TechStars w Berlinie, na pierwszej prezentacji pokazano nam wykaz problemów, o których nie piszą media specjalistyczne. Startup może zetknąć się z depresją lub problemami rodzinnymi założycieli, pozbawieniem wolności, alkoholizmem oraz mnóstwem innych zdarzeń. Wszystkie te sytuacje to prawdziwe przypadki, a do tego to tylko niewielka ich część.

Stworzenie startupu to skomplikowane i ryzykowne przedsięwzięcie. Od samego początku musisz rozumieć, po co Ci to wszystko. Żeby szybko zarobić? W tym wypadku nie tędy droga, lepiej wybrać outsourcing lub emigrację. Przez pierwsze kilka lat w startupie pieniędzy nie będzie i trzeba się na to przygotować. W Preply czasami nie wystarczało na pensje, dlatego zespołowi potrzebny był inny rodzaj motywacji.

Chcesz być bajeranckim szefem? Również nie tędy droga. Na początku szef ds. technicznych będzie samodzielnie zajmował się instalacją systemów operacyjnych, konfiguracją firmowej poczty bądź SIP infolinii. Wszyscy będą musieli wykonywać tego rodzaju rutynowe zadania.

Jeśli jednak jesteś świadomy ryzyka i gotowy wziąć na siebie odpowiedzialność, to rezultat jest tego wart. Startup to znaczący poziom swobody twórczej oraz duma z wyników. Wiara w projekt i radość ze stworzenia własnego przydatnego produktu to rzeczy pomagające trzymać się w trudnych sytuacjach i odrzucać oferty pracy, w których oferowane wynagrodzenie jest zwykle większe niż bieżące.

Rozpoczęcie pracy: jak na początku podejmować właściwe decyzje?

Początkowe fazy pracy i pierwsze podjęte decyzje są jednymi z najważniejszych rzeczy dla dyrektora technicznego startupu. Pierwsze kroki to wybór platformy programistycznej, języka programowania i reszty technologicznej sterty, na której podstawie będzie budowany projekt.

Na tym etapie często pojawia się pytanie, a nawet dyskusja: pisać projekt na tym, co już znasz, czy zabrać się za nową technologię? Oczywiście pierwsza opcja jest szybsza, za to druga ciekawsza z punktu widzenia rozwoju zawodowego. Miałem okazję pracować w obu wariantach (w swoim czasie uczyłem się Groovy w podobnych warunkach). Jednak „ciekawsze” to nie parametr, który decyduje o wszystkim.

Aby zbudować udany biznes, logiczniej byłoby zadać sobie pytanie: Czy jestem w stanie stworzyć architekturę dla skalowalnego projektu na podstawie technologii, którą już opanowałem? Czy na etapie rozwoju startupu i dużego obciążenia zespołu będę w stanie optymalizować, przepisywać lub skutecznie utrzymywać projekt w danej technologii?

Jeśli twoja odpowiedź brzmi „tak”, oto moja rada: pisz w tym, co już znasz. Popracować nad rozwojem zawodowym jeszcze zdążysz, na przykład przy wielojęzykowej architekturze mikrousług. W naszym przypadku podstawowy projekt w Python był uzupełniony funkcjonalnościami Java i Java Script, a komunikacja z głównym projektem realizowana była przez RabbitMQ (przy okazji, polecam książkę Sam’a Newmana o tworzeniu mikrousług, można uzyskać do niej bezpłatny dostęp tutaj).

Od początku warto wybrać dobrą platformę programistyczną dla swojego języka programowania, ponieważ pisząc projekt od zera, zestaw zadań jest bardzo podobny i co do większości z nich była już podjęta decyzja. Scaffolding, społeczność programistów, dobry zestaw bibliotek (najlepiej z dużą ilością gwiazd na GitHub) — to rzeczy, na które należy zwrócić szczególną uwagę.

Szybkość działania platformy i samego języka programowania nie są już tak istotne, chociaż kilka lat temu było to niezwykle ważne. Wyjątek stanowią projekty, gdzie wydajność leży u podstaw sukcesu.

Wypuszczenie MVP i wybór funkcji projektu

Główne zadanie na etapie początkowym to wypuszczenie MVP. Radzę szybko pisać dobry kod i przy tym nie zapominać o komunikacji ze współpracownikami odpowiedzialnymi za część biznesową projektu. Jest niezwykle ważne, aby część zespołu odpowiedzialna za stronę biznesową była zaangażowana w sprzedaż jeszcze przed premierą.

Jeśli taka organizacja nie ma miejsca, jeśli strona biznesowa czeka tygodniami lub miesiącami, aż dyrektor techniczny z deweloperami przygotują kod, to jest to „czerwona flaga” ostrzegająca o problemie w zespole. W naszym przypadku było tak: pisaliśmy MVP, posiadając tylko prostą stronę docelową, na którą trafiały zgłoszenia. Nasz dyrektor generalny Kirill Bigaj siadał i samodzielnie obdzwaniał potencjalnych klientów, starając się sprzedać produkt.

Drugi ważny moment to określenie funkcji projektu. Strona biznesowa zawsze będzie wymagać więcej funkcji w danym odstępie czasowym, niż możliwe jest w ogóle wypuścić. Trzeba wybrać. Ponieważ startup ma mało czasu i pieniędzy a klienci i wykonawcy to te same osoby, trzeba zrozumieć, jakie konkretne opcje są potrzebne projektowi oraz jakie funkcje mogą pomóc w ich osiągnięciu.

Dla firm technologicznych nastawionych na realizację przez zakup, ważne jest, aby funkcje mogły wpasować się w daną strategię. Jeśli nie jest to firma spieniężająca, dla niej ważna będzie baza użytkowników tzw. user base, natomiast dla projektów na rynkach lokalnych od pierwszego dnia ważne będą zarobki.

Wybrane funkcje należy dobrze ocenić. Niewłaściwe oszacowanie czasu na ich realizację, jest najczęściej popełnianym świadomym lub nieświadomym błędem. Z doświadczenia mogę powiedzieć, że przeciąganie terminów to zła opcja. Jeśli nie dajecie rady, zmniejszcie ilość funkcji, zmieńcie ich objętość tak, aby nie wypaść z grafiku. Wszystko, czego nie zdążycie przygotować w terminie, powinno zostać przeniesione do następnej iteracji rozwoju.

Przy czym od nagromadzenia „długu technologicznego” nie ma ucieczki. Należy też pilnować, aby nie dopuścić żadnych błędów krytycznych w architekturze na początkowych etapach rozwoju. Polecam nawiązać kontakt z doświadczonym mentorem bądź utrzymywać więzi z dyrektorami technicznymi innych projektów, którzy przeszli już ten etap i są w stanie coś doradzić.

Mnie pomogły spotkania z innymi dyrektorami ds. technicznych, meetupy, hackathony oraz inne eventy. Pozwolę sobie również przypomnieć, że nie należy zapominać o zasadzie give first: koniecznie pomagaj kolegom po fachu z mniejszym doświadczeniem, kiedy mają pytania, ponieważ w ten sposób buduje się wspólnotę.

Wspólnota pomoże również w doborze baz danych. Na początkowych etapach warto regularnie rozmawiać na ten temat z kolegami, którzy pracowali nad podobnymi produktami. Źle dobrany schemat danych oznacza konieczność ich migracji w przyszłości, co trudno jest nazwać przyjemnymi chwilami.

W naszym wypadku źle dobrany sposób przechowywania sum w różnych walutach wymusił na nas prace uzupełniające w trakcie skalowania na inne rynki. Koledzy z zaprzyjaźnionego projektu do tej pory mają problemy z danymi w MongoDB, ponieważ NoSql nie jest panaceum na problemy z systemem, jeśli produkt otrzymuje określony stopień więzi.

Etap rozwoju: Co powinni i nie powinni robić deweloperzy

Gdy tylko waszym produktem zacznie posługiwać się ciągle rosnąca grupa odbiorców, automatycznie pojawi się pytanie, czy projekt jest w stanie poradzić sobie z rosnącym obciążeniem. Pamiętam słowa Donalda Knuth: «Premature optimization is the root of all evil». Trzeba dwa razy zastanowić się, czy stoicie już przed podobnym problemem.

Ogólna zasada mówi, że kody są przepisywane wraz ze wzrostem obciążenia. Przy rozwoju liniowym często bardziej skuteczne okazuje się rozwiązanie z pomocą skalowania pionowego oraz baz danych. Na tym etapie, jeśli naprawdę chcesz zadbać o rozwój zawodowy, polecam przekierowanie wszystkich procesów, które mogą rozpraszać zespół deweloperów i nie dotyczą bezpośrednio programowania, na barki innych osób.

Oto przykłady zadań, których nie powinni wykonywać deweloperzy:

1. Lokalizacja produktu

Startupy ze Wspólnoty Niepodległych Państw w większości wypadków są skazane na wyjście na rynek globalny, ponieważ tworzenie produktów wyłącznie dla rynku lokalnego jest w ich wypadku niepraktyczne z ekonomicznego punktu widzenia. Sam często widziałem, że koledzy z innych projektów regularnie proszą o modyfikacje jakiegoś tekstu, ponieważ znaleziono błąd w lokalizacji lub przesłano nowe teksty na stronę. Implementacja podstawowa continuous localization — oto czego potrzeba, aby nigdy więcej nie marnować czasu programistów na rutynowe aktualizacje tłumaczeń.

2. Wsparcie techniczne

Co prawda, na początku trzeba zająć się tym samodzielnie, ale kiedy liczba zapytań rośnie, należy w końcu zatrudnić zespół do działu obsługi klienta. W naszym wypadku specjalista działu obsługi klienta był pierwszą osobą, która dołączyła do naszego zespołu i ta decyzja okazała się jedną z najlepszych. Chcę jednak uściślić, że mimo wszystko wciąż jeszcze będziesz mieć do czynienia z obsługą klienta, w końcu to ty ostatecznie odpowiadasz za wszystkie bugi. Będziesz mógł natomiast zapomnieć o rutynowych zadaniach jak ustalanie wersji przeglądarki, czy sugerowanie klientom czyszczenia plików cookies.

3. Marketing

Przenieś redagowanie stron docelowych do administracji witryny oraz skonfiguruj narzędzia, które pozwolą na zdjęcie pracy marketingowej z barków programistów: Na przykład, menedżera tagów Google.

4. Statystyki

W startupach często próbuje się tworzyć wewnętrzny system statystyk. My również na to chorowaliśmy. Jest to skrajnie nieefektywne wykorzystanie zasobów, ponieważ przewidzenie wszystkich metryk i innych kwestii jest niemożliwe. Lepiej zrobić spis wszystkich danych w profesjonalnych programach do analityki biznesowej.

5. Panel admina

Skonfiguruj prawa do edytowania potrzebnych modeli dla reszty zespołu. Szczególnie polecam upewnić się, że wasza platforma obsługuje scaffolding.

Przydatność zadań administracyjnych

Musisz zdecydować, czy chcesz rozwijać kompetencje DevOps. Często można częściowo zrezygnować z zarządzania technicznego projektem, korzystając z pomocy dowolnego systemu PaaS lub zatrudniając odpowiednich specjalistów. Czasem jednak, ze względu na specyfikę techniczną, trzeba mieć bogatsze doświadczenie w infrastrukturze.

W naszym wypadku ważna była kontrola na każdym etapie, dlatego w trakcie procesu musiałem nauczyć się konfiguracji Nginx i VPN, wdrażania Docker na serwerach oraz zajmować się innymi zupełnie nie-programerskimi kwestiami. Jest to doskonała okazja na poprawę konkretnych kompetencji i lepsze zrozumienie współczesnych technologii. Taka praca wymaga jednak dużo czasu i poświęcenia.

Jeszcze raz powtarzam, rozmawiaj ze specjalistami, którzy robili to samo przed Tobą, proś o rady. Należy dodać, że prawie wszystkie platformy IaaS posiadają specjalne programy dla startupów, ze wsparciem na żywo oraz poradami w zakresie korzystania z produktów. Na przykład, na zaproszenie Amazon udaliśmy się na konferencję w Berlinie. Praktycznie w ciągu dnia przeszliśmy ekspresowy kurs skutecznego korzystania z ich usług.

Czy przygotowywać testy i kiedy to robić

Sprawdź listę kontrolną Joel’a Spolsky i zajmij się rzeczami, które nie zostały jeszcze zaimplementowane. Dyskusja dozwolona jest przy punktach dotyczących testów i dokumentacji. Startupy muszą być szybkie i przygotowywanie testów może znacząco spowolnić rozwój produktu.

Czasami koszta są tego warte, czasami nie. W niektórych przypadkach lepiej porzucić ogólne testowanie produktu i tylko później przy każdej iteracji wprowadzać niezbędne poprawki. Jednakowoż krytyczne części produktu zawsze muszą być dokładnie przetestowane, a te, które nie będą przepisywane, powinny być bezkompromisowo zamykane.

Sami dość często coś dopisujemy lub zmieniamy, choć nie jestem fanem TDD. Według mnie nie jest potrzebne 100%-owe natychmiastowe testowanie. Testy należy przygotowywać gdy mamy na to zasoby. Szczególnie ważne jest rozpoczęcie organizowania większej liczby testów w chwili, gdy do zespołu dołączają nowe osoby, gdyż trakcie zapoznawania się z produktem mogą napisać kod, który coś zepsuje. Testowanie to skuteczne narzędzie na równi z przeglądem kodu, pomagające zlokalizować podobne błędy.

Od startupu do firmy: odpowiedzi na pytania nietechniczne

Znajomi często pytają: „Jak długo jeszcze będziecie startupem? Macie już 3/4/5 lat i do tej pory zajmujecie się tylko PR”. To proste: Dopóki hipotetyczne odejście jednego z założycieli grozi zamknięciem projektu, jesteśmy startupem. Jednak w którymś momencie trzeba przekształcić startup w firmę. W praktyce wiąże się to z zabezpieczeniem wszystkich zagrożeń systemowych związanych z ludźmi.

Firma powinna działać bez względu na to, kto zajmuje się działalnością operacyjną. Wszystkie procesy w zespole powinny być zautomatyzowane i udokumentowane tak, aby główną wartością projektu były procesy i aktywa, a nie tylko zespół założycieli. Dyrektor techniczny powinien zebrać zespół ludzi zainteresowanych projektem z technicznego punktu widzenia.

Jego rola na tym etapie, to budowa zespołu, odpowiednia organizacja procesów z nim związanych oraz dbanie o ich ciągły rozwój zawodowy. Niestety na kodowanie pozostaje na tym etapie niewiele czasu. Kluczową funkcją jest praca z ludźmi.

Jak motywować zespół deweloperów

Moim zdaniem najlepsza motywacja dla zespołu programistów to wymagające i ciekawe zadania. Motywacja powinna być wsparta przez odpowiednie wynagrodzenie, chociaż liczby mogą być poniżej średniej rynkowej.

W takiej sytuacji szybko odpadają ludzie, którzy przyszli dla pieniędzy, a nie dla produktu. Na zachodzie zespół programistów często otrzymuje część firmy przez tzw. option pool — prawo wykupu akcji po minimalnej cenie w momencie, kiedy startup zaczyna odnosić sukces. U nas niestety instrument ten na razie nie cieszy się dużą popularnością, ponieważ nie możemy pochwalić się wieloma kultowymi historiami sukcesu. Dla porównania weźmy gang Paypal’a. Grupa byłych pracowników Paypal, w skład której wchodzą nie tylko założyciele, dzięki swoim akcjom z option pool została milionerami i stworzyła wiele innych udanych biznesów.

Istnieją też inne mniej znane „gangi”. Na przykład w Berlinie poznaliśmy byłych pracowników ZenDesk i Delivery Hero, którzy również inwestują i tworzą własne projekty kosztem akcji z option pool. Kolejny przykład jest nam trochę bliższy geograficznie, to polski serwis niania.pl, przeznaczony dla poszukiwania niani. Osoby opuszczające ten projekt kilka lat temu rozpoczęły aktywną działalność inwestycyjną w Europie Wschodniej, gdzie pomogły zbudować kilka dobrze prosperujących przedsiębiorstw.

Dyrektor techniczny powinien zaznajomić swój zespół z takimi historiami oraz wyjaśnić jak działa dany instrument. Poczucie własności produktu, a tym bardziej prawnie wiążące to doskonała motywacja dla zespołu. Trzeba to koniecznie wprowadzać, a im więcej historii sukcesów, tym bardziej popularne stanie się takie podejście.

Automatyzacja i bezpieczeństwo na etapie przejściowym

Mimo wymagających i interesujących zadań, w pracy programisty prędzej, czy później pojawia się rutyna. Na etapie przejściowym od startupu do dojrzałego biznesu należy maksymalnie zautomatyzować wszystkie zadania deweloperskie. Ważne jest przygotowanie dobrej wewnętrznej bazy wiedzy, która pomoże nowym pracownikom łatwo włączyć się w tok pracy. Procesy rozwoju muszą być dobrze udokumentowane, a testowanie produktu powinno stać się ważnym i nieuniknionym procesem.

Jeśli one-click-deployment dobrze działał wcześniej, teraz należy dokładniej przyjrzeć się praktykom immutable deployment. Sytuacje awaryjne nie są szczególnie krytyczne dla startupu, ale dla dojrzałego przedsiębiorstwa mogą być bardziej bolesne.

Ostatni kluczowy proces na etapie przejściowym to zadbanie o bezpieczeństwo projektu, poczynając od dobrej administracji praw zespołu, ochrony przed atakami DDoS i na podatności kodów kończąc. Stabilny fundament zbudowany na poprzednich etapach pomoże łatwiej rozwiązywać podobne problemy. Opcjonalnie można skorzystać z zewnętrznego audytu bezpieczeństwa.

Zamiast zakończenia – kompendium w czterech punktach

Praca w roli dyrektora technicznego startupu to niezwykle ciekawe doświadczenie pozwalające przejść całą drogę rozwoju produktu oraz przekształcić swoją umiejętność programowania w biznes. Ponadto będziesz mieć swobodę wyboru technologii oraz sposobów rozwiązywania problemów. Wymaga to jednak odpowiedzialności za podjęte decyzje. Rozwój zawodowy zachodzi bardzo szybko, ale i natłok pracy jest proporcjonalny.

We własnym startupie nie chodzi o pieniądze. Zacytuję naszego inwestora Semen’a Ducach: „Startup to nie najlepszy pomysł na zarobienie pieniędzy, lepiej nauczyć się programować i pójść do pracy w firmie outsourcingowej. Tam znajdziesz sukces materialny”. Miał na myśli ukraińskie startupy, ale w pewnym stopniu można odnieść te słowa również do innych krajów, szczególnie do tych należących do Wspólnoty Niepodległych Państw.

Zadanie dyrektora ds. technicznych to nie stworzenie kodu doskonałego, ale takiego, który pomoże zrealizować pomysł na biznes. W trakcie pracy trzeba będzie nie tylko programować, ale wdrażać dobre praktyki inżynieryjne i stworzyć mocny zespół, co w połączeniu da dużą przewagę nad konkurencją. Na to właśnie dyrektor techniczny ma największy wpływ.

Ważne jest być na bieżąco z nowoczesnymi technologiami i w miarę możliwości włączać je do projektu. Przede wszystkim jednak trzeba wykonać minimalną analizę zysków/strat z punktu widzenia przedsiębiorstwa. W swoim czasie rozważaliśmy możliwość migracji z Backbone na Angular, jednak koszta czasowe okazały się nieporównywalnie większe od potencjalnych zysków. Z drugiej strony przeanalizowaliśmy też przejście z self-hosted PostGreSQL na Amazon RDB i choć wymagało to od nas znacznego nakładu czasowego, to korzyści z nowej technologii podczas skalowania były o wiele większe.

Podsumowując, chcę powiedzieć tylko jedno: stanowisko dyrektora technicznego w startupie to niesamowite doświadczenie. Moja praca była ciekawa, nawet zanim Preply osiągnął sukces, a zapewniam, że zajęło to więcej niż rok. Myślę, że dlatego nam się udało: robiliśmy to, w co wierzyliśmy, a nie staraliśmy się wyłącznie zarobić. Tylko osoby pałające pasją do idei mają szansę na osiągnięcie swoich celów.

–