Od lokalnego serwisu do globalnej marki – wywiad z Grzegorzem Krysiakiem, CTO ZnanyLekarz.pl

7 lat to z perspektywy rozwoju produktu czy startupu lata świetlne. Z drugiej strony tylko tyle czasu potrzebował portal ZnanyLekarz, należący do międzynarodowej grupy DocPlanner, aby zdobyć pozycję globalnego lidera rynku umawiania wizyt lekarskich online. Wspólnie z Grzegorzem Krysiakiem, CTO firmy, postaramy się zrekonstruować drogę od lokalnego serwisu do globalnej marki, odwiedzanej przez miliony użytkowników miesięcznie.

Tak dynamiczny postęp niesie ze sobą szereg wyzwań, jakie stają przed zespołem IT. Jaka była historia rozwoju produktu, od kilku osób do połączenia zespołów programistów z Warszawy i Barcelony? O tym już za moment.

Opowiemy o wszystkich kluczowych decyzjach ze strony IT. Odpowiemy również na pytanie, w jakiej części sukces całego przedsięwzięcia determinowany jest przez zgrany zespół programistów.

Na początek – krótki zarys

W 2011 roku Mariusz Gralewski odkupuje działający od 2 lat serwis znanylekarz.pl. Kwota transakcji była dużo większa od realnej wartości portalu, ale twórca GoldenLine dostrzega w tym niszę. Wie, że ponad 3 miliony Polaków poszukuje lekarzy, a szczególnie tych najlepszych, przez internet, niestety w dużej mierze bezskutecznie.

Maj 2017 roku, grupa DocPlanner zamyka kolejną rundę finansowania, tym razem na poziomie 15 milionów dolarów. Łączna kwota inwestycji w DocPlanner do tej pory, uwzględniając ostatnią rundę, wynosi 46 miliony dolarów. W ubiegłym roku DocPlanner połączył siły z hiszpańską spółką Doctoralia, wchodząc tym samym na rynki Ameryki Łacińskiej i rozwijając swoje usługi w umawianiu wizyt lekarskich. Obecnie marka jest obecna w 24 krajach, a do jej “corowych” rynków należą Włochy (MioDottore.it), Polska (ZnanyLekarz.pl), Turcja (Doktortakvimi.com) oraz Hiszpania, Brazylia i Meksyk.

Rozmowa z Grzegorzem Krysiakiem

Piotr Nowosielski: Cześć Grzegorz, dziękuję, że znalazłeś czas na rozmowę. Przejdziemy długą drogę, od punktu wyjścia do pozycji, w której obecnie jesteście. Proponuję zacząć klasycznie, od początku. Cofnijmy się zatem do 2011 roku, gdy kupiliście serwis ZnanyLekarz. Przyświecał Wam wtedy jasny cel, aby zdominować polski rynek.

Miałeś już spore doświadczenie z GoldenLine, serwisem który rozwijałeś wspólnie z Mariuszem Gralewskim. Gdy deal związany z kupnem portalu był ostatecznie klepnięty, stanąłeś na czele zespołu IT, który miał to wszystko poukładać. Zastanawia mnie prosta sprawa – od czego trzeba było zacząć?

Grzegorz Krysiak: Od początku! 🙂 Serwis, który kupiliśmy, stworzony został w 2000 roku przez jedną osobę. Mnóstwo kodu i autorskich rozwiązań. Z naszej perspektywy w architekturze brakowało struktury, która pozwoliłaby na łatwe dokładanie nowych funkcjonalności i rozszerzanie istniejących. Dodatkowo, chcieliśmy też podrasować design. Podjęliśmy decyzję, aby przepisać wszystko praktycznie od zera. Otworzyliśmy zatem pusty projekt i zaczęliśmy pisać. Za główny cel, który pomagał nam podejmować decyzje obraliśmy: stworzyć serwis, który obsłuży duży ruch i będzie pozwalał na proste wprowadzanie nowych funkcjonalności.

Podejmując decyzję o zakupie serwisu, byliśmy nadal zaangażowani w GoldenLine, ZnanyLekarz był “side-project’em”. Musieliśmy znaleźć czas i osoby, które pomogą w przepisaniu serwisu.

PN: Jak wielkie tempo sobie narzuciliście, jakie były priorytety, jeżeli chodzi o część IT? Domyślam się, że z racji tego, iż portal GoldenLine bardzo dobrze funkcjonował, nie było presji na to, aby jak najszybciej zarabiać, tylko mogliście skupić się przede wszystkim na stworzeniu solidnego produktu. Czy jednak nie miało to aż takiego znaczenia?

GK: Tempo było faktycznie duże. Mieliśmy masę pomysłów, które chcieliśmy zrealizować i sprawdzić w praktyce. Tymczasem na istniejącym kodzie trudno było to zrobić. Byliśmy mocno zdeterminowani, żeby nowa wersja serwisu ruszyła jak najszybciej i była skalowalna na inne rynki.

Na początku nasza wizja ZnanegoLekarza dosyć znacznie różniła się od tego, co robimy teraz. Wcześniej miał być to portal promocyjny dla lekarzy. W skrócie: lekarz publikuje swój profil, uzupełnia ważne informacje o sobie i dzięki temu, w jakiś sposób, zyskuje pacjentów. Początkowo chcieliśmy po prostu sprzedawać lekarzom wizytówki.

To jednak nie zaskoczyło. Zaczęliśmy szukać dalej – wymyśliliśmy umawianie wizyt – to był kluczowy moment dla ZnanegoLekarza. Swoją drogą to ciekawa historia, mieliśmy już sporo doświadczenia, aby nie robić rozbudowanych produktów na start, także pierwsza wersja umawiania wizyt w ZnanymLekarzu polegała na tym, że Piotrek, który zajmował się produktem, siedział na słuchawce z kilkoma lekarzami, których prosiliśmy, aby udostępnili kilka terminów wizyt. Ja ręcznie wrzucałem je w kodzie, szedł szybki deploy, a jak już pacjent umówił się na wizytę, telefonicznie przekazywaliśmy informację lekarzowi.

Można powiedzieć, że zrobiliśmy totalne MVP. Chcieliśmy sprawdzić, czy ludzie są na tyle otwarci na nowe rozwiązania, że będą chcieli umawiać się do lekarza przez Internet.

Po tym jak umówiliśmy kilkaset takich wizyt, a pacjenci i lekarze byli super zadowoleni postanowiliśmy stworzyć już w pełni działający produkt, zautomatyzowany i “ładnie” zakodowany.

PN: Opowiedz coś więcej. Jakie technologie wykorzystaliście? Jak wiele czasu w praktyce pochłaniały prace nad kodowaniem i kluczowymi funkcjonalnościami na początku rozwoju ZnanegoLekarza?

GK: Stackiem tech jest PHP oraz MySQL (a konkretniej MariaDB). Znaliśmy się na tym jak zaczynaliśmy, wiedzieliśmy, że sporo ludzi w tym siedzi, to był dla nas oczywisty wybór. Wchodząc poziom niżej – PHP – jaki framework? – na początku zdecydowaliśmy się na użycie autorskiego frameworka, głównie dlatego, że to były czasy, gdy frameworki PHP’owe z trudem utrzymywały duże obciążenie lub wymagały mocnych serwerów. My chcieliśmy mieć szybki serwis na minimalnej infrastrukturze, zdolny do obsłużenia dużego ruchu.

Stworzyliśmy prosty i lekki framework. Sporą barierą okazało się wdrożenie nowych devów, ponieważ każdy musiał się uczyć całego środowiska od początku. Dużym minusem był też brak community, które pomogłoby nam rozwijać core naszego kodu. Natomiast szybko mogliśmy tworzyć nowe funkcjonalności – to wtedy było najważniejsze.

Właściwie od początku olbrzymie znaczenie miała wyszukiwarka w serwisie. Korzystaliśmy z SphinxSE, dzięki temu mogliśmy ograć wyszukiwanie pełnotekstowe w dosyć prosty sposób, dając całkiem dobre quality użytkownikowi. Jednak w tamtych czasach (2011) ta technologia nie dawała zbyt wielu możliwości – konieczność reindeksacji lub używania uciążliwych delta-indeksów, słabe wsparcie dla wyszukiwań prefixowych, itd.

PN: Przejdźmy nieco do pracy waszych programistów. Ile osób liczył na starcie zespół ZnanegoLekarza i jak wyglądała jego organizacja?

GK: Na początku było dwóch developerów na full time. Ja byłem w tamtym czasie jeszcze zaangażowany w GoldenLine. Prowadzenie dwóch tematów na raz jest super trudne, wiedziałem, że muszę skupić się na jednym. Wybrałem ZnanegoLekarza, bo wierzyłem, że w przyszłości będzie to ogromny międzynarodowy projekt.

Zaczęliśmy w tamtym czasie bardzo szybko rozbudowywać zespół, mieliśmy sporo hipotez do przetestowania. Zatrudnialiśmy średnio jedną osobę na miesiąc. Z czasem team rozrósł się do około 8 osób. Większość czasu spędziliśmy na przepisywaniu ZnanegoLekarza. Nie przywiązywaliśmy zbyt dużej uwagi do organizacji pracy, chcieliśmy jak najszybciej wypuścić nową wersję serwisu.

PN: Jak dynamicznie zaczęliście się rozwijać? Pierwsze zewnętrzne finansowanie to 2012 rok, w wysokości $1M, część pochłonął marketing i wejście na zagraniczne rynki, lecz parcie na rozwój zespołu IT było również nie mniejsze. Przed jakimi wyzwaniami stanęliście w tamtym czasie?

GK: Cały czas przyświecał nam cel: jak możemy ZnanegoLekarza rozwijać jeszcze szybciej i dodatkowo przygotować serwis do odpalania w wielu krajach.

Zaczęliśmy zastanawiać się… czy nasz autorski framework to najlepsze rozwiązanie? Nowe osoby nie bardzo rozumiały, o co w nim chodzi. Coraz bardziej popularne stawało się Symfony (na którego mechanizmach zresztą wzorowaliśmy się, tworząc swój framework), a co najważniejsze niektóre z naszych problemów i wyzwań były już w nim rozwiązane.

Wybór był prosty – zdecydowaliśmy się przejść na SF2. Naszym pierwszym wyzwaniem było płynne przejście, bez zmniejszenia szybkości pracy nad projektami biznesowymi.

Drugim była wydajność – im więcej features tworzyliśmy, tym kod stawał się bardziej zasobożerny, generował więcej zapytań do bazy – każdy request zajmował trochę więcej czasu, serwis tracił płynność działania. Musieliśmy mocno rozkminić temat skalowalności: jak zapewnić super experience dla użytkownika poprzez bardzo krótki czas odpowiedzi serwera. Skalowanie sprzętem było trudne, nasza infrastruktura opierała się na dedykach i bardzo zależało nam na minimalizacji kosztów. Skupiliśmy się na cache’owaniu danych, zaczęliśmy wdrażać Varnish’a + ESI.

Kolejnym wyzwaniem była potrzeba zadbania o masę tematów technologicznych, które pojawiały się wraz ze wzrostem całej firmy: stworzenie narzędzi ułatwiających obsługę klientów, automatyzacja płatności i fakturowania, wsparcie narzędziami handlowców, którzy jeździli do lekarzy, itd. To są tematy, których często się nie docenia, a mają ogromny wpływ na sprawność całego zespołu.

Kluczowym momentem w drodze od start-upu do stabilnej firmy jest moment, kiedy obok produktu, który jest królem, ważne stają się tematy back-office’owe. Dużo z nich można załatwić dobrymi gotowymi narzędziami. Poświęciliśmy temu obszarowi sporo czasu i uwagi.

Oferty pracy z

PN: Ile osób wtedy było w firmie, z wyróżnieniem na poszczególne działy?

GK: Trudne pytanie, to było bardzo dawno temu 🙂 Z tego, co pamiętam łącznie było nas około 40 osób, z czego większość stanowiła sprzedaż. Dział IT liczył około 8 osób..

PN: Zostając przy części związanej z wyjściem poza Polskę. Z czym wiąże się wejście na dużo większe rynki? Włochy były swojego czasu dwukrotnie większe od naszego rynku, a tam również przejęliście lokalnego konkurenta.

GK: Krajem, od którego zaczęliśmy były Czechy. Później Turcja, Węgry, Rosja, Włochy. To było wyzwanie, wielu rzeczy się wtedy nauczyliśmy, zarówno technologicznie, jak i produktowo.

Na start należy bardzo dobrze ograć tłumaczenia. Dla nas największym bólem było oczekiwanie na przetłumaczenie elementów interfejsu – skutecznie zwalniało to każdy projekt. W pewnym momencie odkryliśmy ideę tzw. crowdsourcingu i usługę PhraseApp. Tłumaczenia mieliśmy praktycznie od ręki z jakością jakiej oczekiwaliśmy.

W czasie wchodzenia na nowe rynki, bardzo ważna była dla nas wydajność serwisu. Serwery mieliśmy we Francji, nie chcieliśmy rozpraszać infrastruktury do różnych data center. Zdecydowaliśmy się na spore zmiany w architekturze aplikacji i wprowadzenie mocnego cache’owania odpowiedzi serwerów – pozwoliło nam to zapewnić porównywalny experience dla użytkownika w Polsce i Turcji.

Dalej skupiliśmy się na różnicach produktowych pomiędzy krajami. Wiedzieliśmy, że stworzenie uniwersalnej usługi na wszystkie rynki było niemożliwe. Musieliśmy ograć nie tylko detale ważne z perspektywy użytkownika, takie jak np. odpowiednie formatowania daty, różnice w dniach wolnych od pracy/świętach, obrazki (porównajcie stronę główną znanylekarz.pl z wersją turecką – doktortakvimi.com), ale także duże projekty np. odpowiednie fakturowanie i rozliczanie klientów (zgodne z wymogami prawnymi), geolokalizacja podczas wyszukiwania (np. użytkownicy z Rosji, a konkretniej z Moskwy z reguły szukają lokalizacji wg odległości do stacji metra), itd.

Na koniec zdecydowaliśmy, że jeżeli chcemy utrzymać tak wysokie, jak dotychczas tempo rozwoju w tak wielu krajach, będziemy potrzebować mechanizmu umożliwiającego włączanie i wyłączanie wybranych funkcjonalności lub części serwisu, niezależnie, w różnych krajach. Tak powstał GateKeeper ( https://github.com/ZnanyLekarz/gatekeeper i https://github.com/ZnanyLekarz/gatekeeper-bundle ). Pozwala on za pomocą jednego kliknięcia zmieniać działanie, a co ważniejsze daje możliwość prostego wprowadzania i testowania nowych funkcjonalności w wybranych krajach.

PN: Rok temu przyjęliście też hiszpański serwis Doctoralia. To, jak się dogadaliście finansowo schodzi na drugi plan, interesuje mnie w tym momencie to, jak wyglądało to przedsięwzięcie pod kątem IT.

GK: To było bardziej połączenie, niż przejęcie. Jako ZnanyLekarz byliśmy mocni w Europie Środkowo-Wschodniej. Doctoralia dominowała w krajach Zachodniej Europy i Ameryki Łacińskiej. Chcieliśmy połączyć nasze siły. Jak już do tego doszło – najważniejszym pytaniem było: jak wykorzystać potencjał ludzi w obu firmach tak, aby działać jeszcze sprawniej.

Zamiast jednego zespołu technologicznego mieliśmy dwa. Jeden w Warszawie, drugi w Barcelonie. To były dwa bardzo dobre zespoły programistów i produktowców. Zakładając, że dotychczas robiliśmy bardzo podobne serwisy, musieliśmy zdecydować, jak podzielić się pracą.

Doszliśmy do wniosku, że nasz produkt da się podzielić na dwie części. To, co widzi użytkownik czyli Marketplace z lekarzami oraz drugi, równie ważny element – SaaS dla lekarzy, czyli dosyć rozbudowana usługa, dzięki której lekarz może zarządzać swoim gabinetem i pacjentami. Zdecydowaliśmy się odseparować te dwie części produktu od siebie. Padła decyzja, że team w Polsce będzie zajmować się Marketplacem, a ten w Barcelonie – SaaS’em.

Autonomiczność obu zespołów była dla nas dużą wartością, do tej pory cały nasz mindset opieramy na tym, że obie usługi są oddzielnymi systemami. Oczywiście komunikują się między sobą z wykorzystaniem różnych API, ale jesteśmy w stanie rozwijać je niezależnie od siebie, podejmując szybkie decyzje technologiczne oraz produktowe. Nasze zespoły są porównywalne liczbowo, w Polsce mamy 20 programistów, w Hiszpanii w granicach 15.

PN: Połączenie się z liderem na hiszpańskim rynku to Wasza furtka do Ameryki Łacińskiej, także z pewnością przykładacie wiele uwagi do rozwoju tej części grupy DocPlanner.

GK: Ekspansja do Ameryki Łacińskiej jest dla nas bardzo ważna. To ogromny rynek, bardzo podobny do Polski z punktu widzenia funkcjonowania służby zdrowia – sporo ludzi umawia się prywatnie do specjalistów. Jest tam również olbrzymi ruch, który przejmujemy.

Wyzwaniem dla nas w tej chwili jest przygotowanie infrastruktury do funkcjonowania w wielu regionach na świecie. Przenosimy się właśnie do “chmury”, starając się jednocześnie, aby być “cloud agnostic”, czyli nie uzależniać się od jednego rozwiązania dostępnego na rynku. Stąd mocno inwestujemy w technologie, takie jak Kubernetes czy Terraform.

PN: W Barcelonie macie team programistów, który przejęliście po połączeniu z Doctoralia.com. Są to jednak oddzielne zespoły, z drugim CTO. Jak to wygląda w praktyce?

GK: Technologicznie bardzo się od siebie różnimy. W Warszawie dominującą technologią jest PHP, a w Barcelonie .NET. W zasadzie jedyną częścią wspólną, nad którą pracujemy jest interfejs wymiany danych pomiędzy systemami. W każdym pozostałym projekcie jesteśmy totalnie niezależni, autonomiczni. W naszym przypadku taki podział sprawdza się dosyć dobrze, umożliwia nam szybszy rozwój bez komplikacji wynikających z zawiłości struktury organizacyjnej.

PN: Wejdźmy jeszcze głębiej w produkt! Podobno macie mikroserwisy, które równolegle rozwijacie i utrzymujecie. Jak wygląda ten podział? Rozpoczął się on wraz z wejściem na pierwszy zagraniczny rynek? Opowiedz proszę, jak wyglądał na początku i w którą stronę ewoluował. Jak wygląda teraz?

GK: ZnanyLekarz powstał w 2011 roku. W ciągu 6 lat działania, stworzyliśmy setki tysięcy linii kodu, jednak doszliśmy do ściany. Sposób, w jaki tworzyliśmy nowe funkcjonalności stał się zbyt skomplikowany, coraz trudniej było robić wiele projektów niezależnie. Zdecydowaliśmy, że musimy zmienić strategię, aby zlikwidować te przeszkody. Nowe funkcjonalności zaczęliśmy tworzyć jako mikroserwisy, a istniejące powoli przenosimy z “monolitu” do dedykowanych mikroserwisów.

Pierwszym mikroserwisem, który stworzyliśmy było: SSO (Single Sign On) odpowiedzialny za autoryzację. Teraz jesteśmy na etapie, kiedy mikroserwisów mamy kilka, część z nich jest dosyć mała, jak np. rozpoznawanie rodzaju frazy wpisanej w pole wyszukiwania, a część z nich rozbudowana – przykładowo mikroserwis odpowiedzialny za opinie.

Każdy zespół ma dowolność w wyborze technologii, których używa do tworzenia mikroserwisów. Oczywiście staramy się, aby język był w miarę stały (PHP), natomiast np. wybór frameworków czy technologii wspomagających, to już indywidualna kwestia każdego z teamów.

PN: Jak zmieniały się frameworki, z których korzystaliście na przestrzeni ostatnich lat? Na czym na początku stał serwis, a jak wygląda to teraz? Jaki wpływ na całą infrastrukturę mają wasze mikroserwisy?

GK: Od chwili, gdy wdrożyliśmy Symfony2 jesteśmy mu wierni 🙂 Pozwala nam utrzymywać dobrą jakość kodu i wprowadzać szybko zmiany. Jednocześnie jest na tyle rozbudowany, aby można było tworzyć dosyć skomplikowane funkcjonalności, a co najważniejsze, ma olbrzymie community, które cały czas rozwija projekt i tworzy masę przydatnych bibliotek.

Jedną z najważniejszych rzeczy, jakich nauczyliśmy się w ciągu ostatnich lat jest iteracyjne upgradeowanie technologii, z której korzystamy. Jak zmienialiśmy framework na SF2? Po pierwsze stworzyliśmy z Symfony swojego rodzaju proxy, które przepuszczało requesty na stary framework (w dużym uproszczeniu), a później dopiero przenosiliśmy funkcjonalność po funkcjonalności z “legacy” frameworka. Takie podejście pozwoliło nam na w miarę płynną migrację do nowego frameworka.

W podobny sposób przechodzimy na architekturę opartą na mikroserwisach. Przenosimy bardzo małe funkcjonalności lub w przypadku większych rzeczy tworzymy tzw. “walking skeletons”, które później rozbudowujemy.

Kluczowe w budowie infrastruktury opartej na mikroserwisach jest opracowanie dobrego sposobu wymiany danych między systemami – my stosujemy szynę danych opartą na RabbitMQ oraz umożliwienie prostego deploya każdego z mikroserwisów.

PN: Brzmi dość jasno i klarownie, ale łatwiej powiedzieć, a trudniej zrobić. Nie ustrzegliście się na pewno całej masy fuckup’ów, opowiedz o kilku najbardziej spektakularnych! 🙂

GK: Tym lepiej się nie chwalić 😉 Najbardziej spektakularnym fuckup’em jaki zrobiliśmy było pierwsze wdrożenie Symfony.

Konkretniej: Większość core’owych procesów przetestowaliśmy, ale masa edge case’ów posypała się, np. umawiałeś się drugi raz na wizytę tym samym mailem, a my tworzyliśmy ci drugie konto, co skutkowało nagłym pojawieniem się konfliktów, bo unikalne dane przestawały być unikalne. Przez to sypała się kolejna rzecz, pojawiały się kolejne edge case wpływające na kolejne pięć elementów serwisu, itd. Dojście do tego, od czego to się zaczęło było czasami super trudne.

To była dla nas ważna chwila w historii. Od tego momentu wdrożyliśmy masę systemów, które monitorowały najmniejsze błędy. Monitorujemy zarówno wyjątki, jak i anomalia w obciążeniu infrastruktury. To pozwala nam wyłapywać i naprawiać najmniejsze błędy zanim użytkownicy je zobaczą. Jest to super ważne, jeżeli działamy w tak delikatnej branży jak ochrona zdrowia.

PN: Odpowiedni ludzie na właściwym miejscu minimalizują ryzyko błędu. Są w stanie również szybciej ugasić wzniecony pożar. Jak podchodzisz do tematu rekrutacji programistów? Na co zwracasz uwagę, budując zespół, które cechy są dla Ciebie najważniejsze?

GK: Dla mnie podstawą są wartości. Bardzo dużo uwagi przywiązuje do pasji, zaangażowania, szczerości, chęci do wychodzenia poza swoją strefę komfortu. Jest to zbiór cech budujących w dłuższej perspektywie zgrany zespół, który chce realizować trudne zadania.

W praktyce, etapem każdej rekrutacji do Dev Teamu w DocPlannerze jest tzw. “dzień próbny”. Wpadasz do nas i masz okazję popracować na produkcyjnym kodzie, zmierzyć się z realnym problemem. Dzięki temu możemy poznać się, zobaczyć swój styl pracy, sposób podejścia do problemów, atmosferę w biurze. W efekcie zarówno my, jak i kandydat wiemy na co się piszemy, rozpoczynając dalszą współpracę.

Dodatkowo, budując zespół zawsze patrzę na umiejętność rozwiązywania problemów oraz doświadczenie. Im więcej godzin kodowania ma za sobą osoba, którą rekrutuję tym lepiej. Nie jest to jednak czynnik decydujący.

Mniejsze znaczenie przykładam do stacku technologicznego. Wierzę, że jeżeli ktoś ma wydajny procesor w głowie, nauczy się nowych rzeczy bardzo szybko.

Jeżeli czujesz, że te same wartości są dla Ciebie ważne i podoba Ci się to, co robimy w ZnanymLekarzu – odezwij się do nas, pogadajmy. Znajdziesz nas nie tylko na Facebooku czy Linkedinie, ale przede wszystkim na naszych meetupach i niebawem chociażby na phpCE. Historia z ostatnich miesięcy – przyszedł do nas chłopak, żeby pogadać o technologiach, z których korzystamy. Jaki był finał? Dołączył do teamu 🙂

PN: Wiadomo, że nie samą pracą człowiek żyje! ZnanyLekarz to po godzinach również ludzie mocno zżyci ze środowiskiem deweloperów. Mówimy tutaj o społeczności PHP-owców, dla której organizujecie w Warszawie wspomniane przez Ciebie meetupy. Powiedz coś więcej o tej zajawce.

GK: To zdecydowanie ciekawszy sposób dzielenia się wiedzą niż konferencje. Meetupy są krótkie, mniej formalne. Możesz wpaść któregoś dnia po pracy, napić się piwa, przegryźć coś dobrego i co najważniejsze dostać spory zastrzyk wiedzy.

Mamy sporo doświadczeń, którymi lubimy się dzielić oraz fajne biuro, w którym ludzie dobrze się czują. Pomyśleliśmy jakiś czas temu, że warto spróbować połączyć te dwie rzeczy i zorganizować meetup. Po wydarzeniu zebraliśmy feedback – podobało się. Pierwsze dwa spotkania były dedykowane PHP-owi, teraz rozszerzamy obszary, o których rozmawiamy, o Frontend oraz tematy z pogranicza technologii i produktu, o których był ostatni Meetup. Więcej informacji znajdziecie tutaj: https://www.meetup.com/pl-PL/DocPlanner-Tech/.

Budowanie community to bardzo miła rzecz. Dużo korzystamy z open source’owych rozwiązań, więc czujemy, że fajnie jest też dać coś od siebie, podzielić się. Dzięki temu wszyscy możemy iść szybciej do przodu.

PN: Tego typu inicjatywy z pewnością rozluźniają atmosferę, korzystnie wpływają na pracę w zespole IT. Oczywiście co firma, to obyczaj. Jak ZnanyLekarz dba o to, aby programista nie czuł się wypalony i nie musiał sam dla siebie zamawiać wizyty u psychoterapeuty? 🙂

GK: Po pierwsze wspomniana już wcześniej autonomia. Każdy w zespole developerskim ma dużo swobody i wpływu na to, w jaki sposób kodujemy, jakich narzędzi używamy, jak refaktorujemy, jak zmieniamy stack technologiczny. Dodatkowo, jesteśmy zorganizowani w Teamy Produktowe, w których obowiązują podobne zasady – najważniejsze są cele, a sposób ich osiągnięcia np. wybór projektów, zależy od wspólnych decyzji całego zespołu. Każdy zespół znajduje zarówno czas na realizację zadań typowo produktowych, jak i tych umożliwiających rozwój technologiczny serwisu, dzięki temu każdy developer może rozwijać swoje umiejętności.

Dbamy również o komfortowe warunki i dobry sprzęt do pracy (najnowsze MacBooki, dobre monitory, wygodne krzesła, biurka etc.). Bardzo dużo dzieje się też “po godzinach”, organizujemy wspomniane wcześniej meetupy, integracje, ciekawe eventy. Mam wrażenie, że praca u nas to pakiet: z jednej strony ambitne wyzwania i odpowiedzialność, z drugiej dobra zabawa i fajni ludzie. To połączenie sprawia, że na co dzień chce się przychodzić do biura 🙂

PN: Biorąc pod uwagę całokształt Twojej pracy nad ZnanymLekarzem… co uważasz za największe wyzwanie, którego dotychczas się podjąłeś? Oczywiście skala i ambicje obecnie są znacznie większe, niż były kiedyś, jednak wcześniej siły przerobowe były nieporównywalnie mniejsze. Innymi słowy – co uznajesz za swoje największe osiągnięcie? 🙂

GK: Bardzo trudno wybrać to największe, nowe wyzwania pojawiają się codziennie… Mam wrażenie, że ZnanyLekarz polega na wychodzeniu poza swoją strefę komfortu, bo tylko dzięki temu można osiągnąć cele, jakie sobie stawiamy. Każdy dzień jest ambitny, wczoraj np. byłem w Rzymie, gdzie rekrutowałem techniczny support – dosyć ciekawe wyzwanie ze względu na chociażby różnice kulturowe. Jutro przerzucamy kolejne kraje na nową infrastrukturę. Codziennie jest nowe najtrudniejsze wyzwanie 🙂

Myślę, że aktualnie najbardziej dumny jestem z teamu, jaki udało nam się zbudować. Bez dużego zaangażowania osób, które przez lata tworzyły ZnanyLekarz na pewno nie rozmawialibyśmy dzisiaj 🙂

PN: Czyli cały czas trudniej.

GK: To prawda, ale też satysfakcja z osiągnięć jest większa. Naszym celem jest sprawienie, aby doświadczenia pacjentów związane z opieką medyczną były bardziej ludzkie. Gdyby cel był mało ambitny, nie mielibyśmy co dzisiaj robić 🙂