Jak stworzyć software house?

Subskrybuj nas: | |

 

 

 

 

Streszczenie odcinka:

⚫️ Jak definiujesz siebie w IT? Jako biznesmen, organizator, specjalista, inżynier, …?
⚫️ Skąd wziął się pomysł na pierwszy własny biznes?
⚫️ Jak zaczęło się Pragmatists? Co było wtedy największym wyzwaniem?
⚫️ Jakie elementy dotychczasowego doświadczenia najbardziej Ci się przydały?
⚫️ Czego nauczyłeś się, pracując nad rozwojem firmy?
⚫️ Gdzie poszukujesz wiedzy umożliwiającej rozwój jako osoba zarządzająca firmą?
⚫️ Skąd pomysł na nowy “startup” – Talkie AI?
⚫️ Czy zestaw problemów, który pojawił się przy rozwoju Talkie był podobny do tego, który rozwiązywałeś w początkach Pragmatists?
⚫️ Gdzie widzisz najciekawsze obecnie perspektywy w IT?

 

 

Transkrypcja odcinka:

Cześć! Witaj w 40. odcinku podcastu Stacja IT. Zapraszam Cię do wysłuchania rozmowy z Pawłem Lipińskim.

Paweł Lipiński jest współzałożycielem firmy Pragmatists, software house’u, stąd postanowiłem zatytułować ten odcinek „Jak założyć software house?”. Mam nadzieję, że wyniesiesz z niego tak dużo ciekawych informacji jak ja. Zapraszam cię również do wysłuchania kolejnych odcinków z tej serii. W następnych rozmowach będziemy dyskutować z innymi prezesami, współzałożycielami firm o tym, jak zrobić własny biznes w IT.

Starsze odcinki znajdziesz na stronie stacja.it/podcast, natomiast jeśli nie chcesz przegapić kolejnych odcinków, zapraszam Cię do zasubskrybowania tego kanału w aplikacji do słuchania podcastów, na platformach typu Spotify, iTunes czy też po prostu na YouTube.

Cześć, Paweł.

Cześć.

Zacznę od tego, że cię przedstawię: Paweł Lipiński, absolwent Politechniki Warszawskiej. Zaczynał pracę jako Developer, ale już od początku angażował się w organizowanie zespołów, brał udział w konferencjach, szkolił innych pracowników, interesował się też zwinnym podejściem do tworzenia oprogramowania, które wykorzystywał w kolejnych miejscach zatrudnienia, a od 2009 r. CEO software house’u Pragmatists ze zwinnym podejściem do programowania – Pragmatists zatrudnia obecnie ok. 40 programistów – a od 2018 r. CEO startupu Talkie.ai.

Jeżeli liczyć Talkie i Pragmatists razem, to jesteśmy na poziomie 55 programistów. Niełatwo to policzyć, bo troszeczkę współdzielimy, ponieważ przede wszystkim ja jestem współdzielonym zasobem między tymi dwoma bytami, natomiast takich czystych usługowców jest faktycznie ok. 40 osób.

Takie główne pytanie, które sobie dzisiaj stawiamy, to jak stworzyć software house, jaka droga prowadzi do takiego celu, jakie problemy się z tym wiążą, dlaczego to jest fajne, a dlaczego potencjalnie niefajne. Zacznijmy od twojej drogi i od tego, jak ty siebie w tej chwili definiujesz. Czy uważasz się bardziej za biznesmana, specjalistę czy inżyniera, który stopniowo przekwalifikuje się na osobę zarządzającą, czy też od samego początku widziałeś siebie w biznesie, i bycie programistą było tylko początkiem tej drogi?

To niełatwe pytanie, ponieważ to był proces, który się jeszcze nie zakończył. Skończyłem informatykę na Politechnice Warszawskiej i bardzo długo szedłem nurtem stricte technicznym. Zacząłem pracować już na pierwszym roku studiów. Przechodziłem przez szereg różnych firm – od zupełnie garażowych przez produktowe i software house’y. Dość dużo pracowałem w projektach i firmach związanych z telekomunikacją na stricte technicznych stanowiskach, czyli przede wszystkim jako programista, potem architekt rozwiązań. Zajmowałem się prowadzeniem zespołów, agile coachingiem. Tych różnych kompetencji na przestrzeni lat dochodziło, ale one były często dodatkiem do tego głównego obszaru, którym się zajmowałem, czyli de facto programowaniem.

Do czwartego bądź piątego roku prowadzenia Pragmatists jeszcze w aktywny sposób zajmowałem się programowaniem, potem już się nie dało. Skala działania Pragmatists i potrzeby w innych obszarach sprawiły, że wraz z zespołem doszliśmy do wniosku, że moje uczestnictwo w projektach delikatnie mówiąc, nie pomaga, ponieważ byłem zupełnie nieprzewidywalny, jeśli chodzi o moją dostępność. A poza tym technologie się bardzo szybko zmieniają, jeżeli naraz chciałoby się zajmować i tematami technicznymi, i kwestiami biznesowymi oraz na bieżąco się kształcić, a ja mam rodzinę, to doby by nie starczało.

Natomiast na pewno w mojej drodze zawodowej bardzo pomogły różne dodatkowe elementy, które robiłem, wykonując zawód programisty. Miałem takie szczęście, że pracowałem przez ok. sześć lat w warszawskim software housie, który nazywał się Javart (potem zmienił nazwę na Javeo, rok temu dołączył do grupy TenderHut). I w czasie, kiedy ja tam pracowałem, było to bardzo ciekawe miejsce pracy, które bardzo aktywnie się rozwijało. Mieliśmy bardzo dużą wolność szukania ścieżek rozwoju, pomysłu na siebie. Ze względu na predyspozycje osobowościowe dość mocno poszedłem w kierunku parcia na szkło, faktycznie już wtedy dość dużo występowałem na różnych konferencjach. Wtedy te wystąpienia związane były z technologiami, ich wykorzystaniem. Również ze względu na moją łatwość w nawiązywaniu kontaktów bardzo często wysyłano mnie na pierwszy front do klienta; jak mawiał mój ówczesny szef: żeby pójść zrobić dobre wrażenie, a następnie przekazać projekt w ręce zespołu, który będzie go realizował.

Miałem dość dużo takich greenfieldowych projektów, w których spotykałem się z kimś i robiliśmy pierwszą wersję oprogramowania, którą potem przekazywaliśmy zespołowi do kontynuacji. W związku z tym udało mi się wytworzyć bardzo dużo kompetencji równolegle do tych działań programistycznych, np. prezentacyjne, związane z wyrażaniem swoich myśli, z budowaniem komunikatów sprzedażowych, opisywaniem tego, co robię, czy tego, co dostarczaliśmy. One się potem przydały w biznesie. Brałem udział w ofertowaniu klientów, więc bardzo wcześnie w mojej karierze zajmowałem się takimi rzeczami, które raczej w wielu firmach, przynajmniej wtedy, były zarezerwowane dla takich bardziej zaawansowanych stanowisk programistycznych, czyli Leadów, Seniorów, Architektów itd.

Jak już miałem za sobą bardzo dużo doświadczeń programistycznych, to zaczął interesować mnie kierunek na różnym poziomie i w różnych obszarach działań agile’owych, z jednej strony procesów wytwarzania oprogramowania, tego, co najczęściej kojarzy się z agile’owymi metodykami, czyli w jaki sposób organizować zespoły, ich pracę, tak, żeby działać jak najefektywniej zarówno z punktu widzenia efektywności wytwarzania oprogramowania, jak i budowania oprogramowania, które będzie wartościowe dla użytkowników, klientów, ale jeszcze mocniej po tej stronie, która myślę, że ciągle nie jest bardzo doceniana, czyli w technicznych praktykach agile’owych pochodzących z nurtu, metodyki eXtreme Programming.

Miałem taki okres, kiedy pracowałem w Nokia Siemens Network. Zaletą pracy w korporacji jest to, że można bardzo często angażować się w wiele różnych rzeczy, nie tylko w swój projekt. I ja miałem okazję zaangażować się – byłem do tego zachęcany przez mojego szefa – w taki wewnętrzny team zajmujący się agile coachingiem. W związku z tym zajmowałem się jeżdżeniem po świecie, po różnych zespołach w Nokii. Żeby pomagać jej się organizować, sam zdobywałem różne kompetencje w obszarze organizowania zespołu, organizowania produktu, obserwowałem, co powoduje, że jedne zespoły dostarczają lepiej, inne gorzej, że dostarczają w wyższej jakości, inne w niższej.

I te różne doświadczenia, które zbierałem od 1997 r. do 2009 r., sprawiły, że wystartowaliśmy Pragmatists z pomysłem takiego mocno książkowego stosowania eXtreme Programming – używam tu liczby mnogiej, bo od pierwszego dnia ja, co prawda, byłem właścicielem i CEO, ale razem ze mną wystartowało dwóch kolegów, z których jeden ciągle z nami pracuje. Nikt z nas w takiej formie nie pracował ani nie znał ani jednej firmy w Polsce, która pracowałaby w taki sposób. Miałem już trochę doświadczeń agile’owych oraz trochę doświadczeń z Test-Driven Development, miałem trochę doświadczeń z Perl Programming, z continuous integrations – wtedy jeszcze nie istniał termin „continuous delivery”. Zaczęliśmy wykorzystywać moje różne prywatne doświadczenia z poprzednich firm i doświadczenia Michała i Kamila, kolegów, którzy ze mną zaczynali. I bardzo szybko zorientowaliśmy się, że ten sposób wytwarzania oprogramowania bardzo nas kręci, czyli takie praktyki procesowe, blisko SCRUM-owe, bo to jest w tej chwili chyba najbardziej znana metodyka, połączone z praktykami technicznymi z eXtreme Programming. To był ten nurt, który wtedy na pewno powodował, że byliśmy bardzo efektywni, pracowaliśmy bardzo blisko klienta, zapewnialiśmy bardzo wysoką jakość tego rozwiązania.

Projekt, który wtedy zaczęliśmy, w sumie trwał osiem lat. Było to osiem lat aktywnego rozwijania i tworzenia tego oprogramowania. Przechodził z rąk do rąk, a mimo wszystko tam w żadnym momencie nie było tak, że ktoś strzelił ręką w stół i powiedział: „Tu już się nie da dopisać ani jednej linijki kodu”. Projekt był bardzo aktywnie, stabilnie i równomiernie rozwijany. Więc to był taki zlepek doświadczeń, które zebrałem w czasie mojej kariery zawodowej i które doprowadziły do tego, czym Pragmatists jest teraz, czym ja się teraz zajmuję, czyli zdecydowanie głównie biznesem.

Gdybyś poszukał tej motywacji, dla której założyliście firmę, to czy była to bardziej chęć wykorzystania tych wtedy nowatorskich podejść do tworzenia oprogramowania, czy też chęć bycia na swoim, zarabiania więcej pieniędzy czy jeszcze coś innego?

Przede wszystkim w tamtym momencie dla mnie najważniejsze było to, żeby móc pracować w taki sposób, w jaki chciałem pracować. Czułem, że mam za sobą 12 lat pracy zawodowej, bardzo dużo różnych doświadczeń, więc absolutnie byłem gotowy startować w biznes, iść na swoje, brać pełną odpowiedzialność za projekty klienckie, zamiast być tylko w jakiejś maszynie produkcyjnej. Ale muszę przyznać, że takim argumentem numer jeden było pracować tak, jak sobie to wymyśliłem. Trzeba pamiętać, że 2010 r. to był środek kryzysu, który rozpoczął się w 2008 r., a my wystartowaliśmy w kwietniu 2009 r. Firma, w której pracowałem, bardzo ograniczała moje możliwości wykonywania pracy zawodowej, z tym że ja właśnie zajmowałem się tym agile coachingiem, byłem Architektem w dużym systemie bilingowym. Zespoły miałem w sześciu miastach poza Polską. Nie mogłem do nich podróżować, spotykać się z nimi. ZOOM-a wtedy nie było, technologie wideo były na dużo gorszym etapie, niż są teraz. W związku z tym nie byłem w stanie wykonywać mojej pracy. Więc na dobry początek zacząłem szukać firm, w których mógłbym pracować w wymarzony sposób, właśnie programując w parach, stosując Test-Driven Development, mając prawo do tego, żeby zapewniać jakość produktów, które buduję, oraz czuć dumę z tego, co robię. Nie udało mi się znaleźć wtedy takiej firmy. Nie twierdzę, że ich nie było. Był taki moment, że takich agile’owo działających firm wtedy w Polsce było bardzo, bardzo mało.

Oczywiście, jak w wielu takich przypadkach, był tu też splot wydarzeń. Na przełomie stycznia i lutego byłem na nartach, mój były szef zadzwonił do mnie z pytaniem, czy znam jakiś dobry zespół w Polsce, który mógłby poprowadzić im ważny projekt. Powiedziałem mu, że znać to nie znam, ale mógłbym zrobić taki zespół. I tak to wystartowało. Wymyśleliśmy, w jaki sposób chcemy ten projekt zbudować. Muszę przyznać, że miałem najlepsze kwalifikacje do tego, żeby ten projekt wygrać, bo tam był typowy przetarg. Ponieważ znałem wszystkie systemy tej firmy, więc miałem komplet informacji i najlepsze kwalifikacje do tego, żeby zbudować architekturę tego systemu. I wygraliśmy ten przetarg. Jeszcze wtedy Pragmatists nie istniało, więc w try miga trzeba było postawić spółkę, znaleźć księgowość i nauczyć się tego wszystkiego, co było niezbędne do tego, żeby wystartować.

Zaczynaliśmy na samym początku maja. Projekt był w Luksemburgu, natomiast naszym Product Ownerem był Polak, który akurat przebywał w Warszawie, więc pierwszego dnia wpadł do nas do biura, podczas gdy ja, Kamil i Michał rozpakowywaliśmy pudła od komputerów, skręcaliśmy stoły. Myślę, że wyglądało to dla niego dość przerażająco, że te chłopaki, co tam dłubią w tych maszynach i śrubokrętami skręcają biurka, mają zaraz budować system, przez który przechodziły ogromne pieniądze związane z telekomunikacją, roamingiem. I tak to się zaczęło.

Czułeś gotowość do stworzenie zespołu, pojawił się ten pierwszy klient, bo było zlecenie. Czy coś jeszcze utkwiło ci w pamięci jako taki największy problem w tym początkowym okresie, czyli przy starcie Pragmatists? Czy na coś trzeba było zwrócić jeszcze uwagę, żeby nie wyłożyć się na tym pierwszym zleceniu, np. dostać drugie?

Myślę, że największym problemem wtedy było to, że my jednak współpracowaliśmy z międzynarodową korporacją, która nie była chętna, żeby ryzykować więcej, niż wtedy ryzykowała, więc nie dostaliśmy żadnej zaliczki. Wszystkie oszczędności, które miałem, wsadziłem w sprzęt, zapłacenie pierwszych pensji kolegom, czekając na przelewy. Jak zaczyna się biznes i ktoś posiada niesamowite zapasy gotówki, to może ma łatwiej, ja jej zdecydowanie wtedy nie miałem. Więc przyszedł taki moment, kiedy pojawiły się opóźnienia w płatnościach. Musiałem pożyczać pieniądze od rodziny, żeby zapłacić kolegom pensje, tylko po to, żeby przeczekać kilka tygodni, zanim spłyną płatności.

Było dużo wyzwań logistycznych oraz stresu ekonomicznego. Projekt zbudowany był tak, że oni mieli do nas duże zaufanie, skoro dali nam ten projekt, natomiast prawda jest taka, że mieliśmy gwarancję tylko półrocznego jego finansowania. Więc nie mieliśmy głębokiego przekonania, że ta przygoda się uda, że znajdziemy równolegle innego klienta albo że ten projekt będzie kontynuowany. Więc moi koledzy mieli do mnie duże zaufanie, żeby na taką przygodę się pisać, zrezygnować z pracy w stabilnej firmie i dołączyć do takiego wariackiego pomysłu tylko dlatego, żeby pracować w trochę inny sposób.

Zdecydowanie na tamtym etapie największym wyzwaniem była logistyka i zorganizowanie finansów tak, żebyśmy byli bezpieczni. Pojawiały się oczywiście wyzwania programistyczne. Żaden z nas nie miał za sobą 10 lat pracy w parze czy testowania automatycznego na różnych poziomach. Tego też musieliśmy się nauczyć. Mieliśmy pewne doświadczenia z unit testingiem i testowaniem integracyjnym, jakieś end to end pewnie też, natomiast nie byliśmy od tego jakimiś wielkimi ekspertami, my dopiero zbieraliśmy te doświadczenia. I jak patrzę na to z perspektywy 12 lat pracy w ten sposób i dziesiątek osób, które przewinęły się przez Pragmatists, pracowały w parach, stosując Test-Driven Development, to poziom kompetencji, którą mają pracujący u nas programiści, na pewno przewyższa ten, który był kiedyś. Są to wyzwania techniczne i wiadomo, że rośliśmy w czasie.

Mieście już to zlecenie i pracowaliście. Czy to dawało komfort czasowy, w którym można było skupić się nad projektem i go robić, czy pojawiła się jednak refleksja, że jak chcemy utrzymać firmę, to powinniśmy szukać kolejnego zlecenia, klienta i jak się za to zabrać? Czy twoją rolą było to, żeby szukać tego kolejnego klienta?

Tak, to było moja rola, aczkolwiek nie mogę powiedzieć, że się z niej jakoś super dobrze wywiązywałem. Przez pierwsze trzy lata wisieliśmy na tym jednym kliencie i na tym jednym projekcie. Projekt był duży i oczekiwania co do niego rosły, więc nasz zespół także rósł. Natomiast widoków na kolejny projekt nie było. Nie miałem żadnych sprzedażowych czy marketingowych doświadczeń. Próbowaliśmy różnych rzeczy. Ja występowałem na prawie wszystkich javowych konferencjach, które były w Polsce. Bardzo dużo opowiadałem o naszym sposobie pracy, o eksperymentach, które robimy w zakresie procesów, technik testowania, pracy w parach – różnych rzeczy. I powoli te działania zaczęły przekładać się na duże zainteresowanie programistów, którzy też chcieli w ten sposób pracować, więc przez pierwsze kilka lat wcale nie szukaliśmy nikogo do naszego zespołu. Bo po samych konferencjach pojawiało się wystarczająco dużo osób, które słysząc to, odnajdywało się w tych moich pomysłach na tworzenie oprogramowania, co wsparło organiczny rozwój firmy do poziomu kilkunastu osób. Natomiast utrzymać go nie jest już tak łatwo i muszę powiedzieć, że ogromnym stresem była świadomość tego, że jest ten jeden klient, który przedłuża z nami projekt na kolejne trzymiesięczne okresy – ta perspektywa nigdy nie była większa niż trzy miesiące – że zaufało mi kilkanaście osób, które ze mną pracują.

Była taka sytuacja, w której faktycznie były zatory płatnicze po stronie naszego klienta na trzy miesiące i ja nie miałem z czego płacić pensji. Wiedziałem, że pieniądze kiedyś spłyną. To był bardzo mocny sygnał, że bez dywersyfikacji nie ma szansy racjonalnie prowadzić tego biznesu. Ale po trzech latach zaczęły spływać do nas różne projekty od osób, które mnie widziały na konferencjach. I to zaczęło działać. Marketing w ramach środowisk programistycznych zaczął przynosić projekty. Programiści polecali nas swoim szefom. Razem z wami zaczęliśmy robić szkolenia w zakresie Test-Driven Development, agile’a i podreperowaliśmy sobie tym budżet. To nam pozwalało robić także coś innego niż tylko siedzieć w projekcie. Szkolenia, warsztaty, konferencje stanowiły odskocznię i pozwalały cały czas rozwijać nasze kompetencje.

W Pragmatists od samego początku mieliśmy świadomość, że bardzo dużo musimy się nauczyć, wchodzimy w zupełnie nowy obszar, którego nikt z nas dobrze nie znał. W 2009 r. w Polsce może była jedna, dwie firmy, które tak naprawdę stosowały zwinne techniki programistyczne, nawet firm, które powiedziałyby otwarcie: „Stosujemy SCRUM-a”, było wtedy strasznie mało. Więc mieliśmy ogromną otwartość na to, aby cały czas się rozwijać, i powiedziałbym, że bardzo aktywnie ją rozwijamy. W tej chwili jest to element naszego procesu i dbania o to, żeby utrzymywać i rozwijać swoje umiejętności tak, żeby nasz zespół był na maksymalnym możliwym poziomie i żeby usługi, które świadczymy naszym klientom, wyróżniały się.

Czyli ta strategia pokazywania się na konferencjach, opowiadania o tym, jak się tą pracę wykonuje dobrze, zadziałała i klienci się pojawili. Czy zatem ta strategia utrwaliła się na przyszłość i nadal jest to główne źródło pozyskiwania klientów, czy też musieliście zainwestować stricte w sprzedaż i w bardziej handlowe ich poszukiwanie?

Strategia zmieniła się w czasie. Na którymś etapie przestałem, bo zmęczyło mnie latanie po tych konferencjach, opowiadanie 10 razy tego samego. Moja praca stała się strasznie rwana – od spotkań z klientami przez rozmowy z zespołem i próbę zadbania o to, co się z nim dzieje, po latanie po świecie na konferencje. Doszedłem do wniosku, że trzeba zacząć szukać inaczej. Zaczęliśmy szukać zleceń aktywnie, outbandingowo, zupełnie na czuja. To zaczęło działać. Ja jestem w dość szczególnej sytuacji, ponieważ wystartowałem, mając za sobą już kilkanaście lat pracy zawodowej w wielu różnych krajach, z wieloma osobami, więc jak ta firma miała już trzy lata, to te różne znajomości zaczęły działać. Ludzie, z którymi kiedyś pracowałem, przychodzili do mnie ze swoimi projektami, projektami swoich też relacji, przekierowywali do mnie różne kontakty. W ten sposób, tych projektów robiło się coraz więcej.

Natomiast my od samego początku jasno sobie powiedzieliśmy, że nas interesuje tylko wzrost organiczny, więc nie chcieliśmy budować wielkiej maszyny sprzedażowej, bo wiedzieliśmy, że jeżeli zaczęłoby to działać, to w efekcie będziemy musieli bardzo szybko się skalować. W software house’ach jedyny sposób skalowania to liniowy – skalowanie liczby osób. Nie chcieliśmy tego robić. Nie wierzyłem, że można zapewnić taką jakość usług, jaką zawsze zapewnialiśmy, rekrutując na potęgę, bo nasz sposób pracy wymagał tego, że jak ktoś do nas dołącza, to potrzebuje się trochę wdrożyć, nauczyć TDD, przyzwyczaić się trochę do pracy w parach. Ludzie, którzy do nas dołączają, nawet tacy, którzy mają za sobą wiele lat doświadczenia, przyzwyczajonych jest do standardowego pisania oprogramowania, bardzo warstwowego, bez wyróżnionej domeny, bez złożonych obiektów, tylko takiego serwisowego tłuczenia CRUD-ów. I nawet jeśli mają umiejętności, kompetencje, ambicje, żeby pracować inaczej, to bardzo często w poprzednich zespołach nie mieli takiej możliwości. Więc nawet jak znajdujemy kogoś, kto bardzo dużo umie, jest świetnym fachowcem, to i tak mimo wszystko po dołączeniu do nas wielu rzeczy musi się jeszcze nauczyć. Bardzo mocno promujemy i tworzymy oprogramowanie z wykorzystaniem domain-driven design zarówno na niskim, jak i na wysokim poziomie. Duża część naszych projektów, jeśli nie zdecydowana większość, to projekty długie, które idą w lata. To są duże systemy, w związku z tym te umiejętności dizajnersko-architektoniczne na poziomie poszczególnych programistów są też bardzo ważne.

Wracając do biznesu, to na pewno na dobry początek zaczęły działać relacje, a potem sama marka Pragmatists, czyli to, że byśmy niezawodni. Dostarczaliśmy to, co obiecaliśmy. Jak ognia wystrzegaliśmy się ściemniania w zakresie np. oszacowań. Od samego początku powiedzieliśmy sobie, że taki klasyczny model tworzenia czy zdobywania projektu, w którym zaniżamy cenę, a potem tłuczemy klienta na change requestach, w ogóle nas nie interesuje. Bardzo idealistycznie podchodziliśmy do tego biznesu. Ale dzięki temu klienci pracowali z nami długie, długie lata. I mamy takich klientów, z którymi pracujemy sześć, osiem lat, co jest absolutnie normalne w naszym modelu. To również powoduje, że nie musimy tak aktywnie zdobywać nowych klientów ani robić 10 projektów rocznie, żeby utrzymać 50-osobową firmę.

To całe nasze podejście bardzo jakościowego tworzenia oprogramowania powodowało, że nawet jeżeli ktoś robił z nami jakiś mniejszy projekt i był zadowolony z tego, w jaki sposób to robiliśmy, to zaczynał opowiadać o nas i to całkiem nieźle działało. Natomiast zaczynaliśmy podejmować różne działania sprzedażowe. Mniej więcej pięć lat temu zatrudniliśmy pierwszą osobę na stanowisko sprzedażowe typu: znaleźć klienta, dotrzeć do niego, jak on jest zainteresowany rozmową, to przekazać do mnie. I dlatego bardzo dużo zajmowałem się wsparciem sprzedaży. Nawet jeśli nie zajmowałem się czesaniem LinkedIna i znajdowaniem tych firm, to prawie od samego początku w procesie sprzedażowym brałem udział. I tym się w tej chwili dość dużo zajmuję.

Ze względu na ten unikatowy zlepek kompetencji biznesowych, kilkunastu lat prowadzenia biznesu, dobrego zrozumienia oczekiwań klientów zarówno na poziomie produktowym, jak i budżetowania, bo pracowałem w enterprise’ach, ale też w software house’ach, w firmach produktowych, usługowych, to ten zlepek kompetencji łącznie z moim backgroundem bardzo ściśle technicznym – tak naprawdę przeszedłem całą ścieżkę od takiego szeregowego programisty do Principal Architekta – powoduje, że mogę pójść do dowolnej firmy i rozmawiać z prezesem CFO, CTO. To na pewno bardzo pomagało w rozwijaniu tego biznesu do tego momentu, w którym jesteśmy teraz.

Obecnie jesteśmy na takim etapie, że zaczynamy działać w obszarze profesjonalizowania obszaru rozwijania biznesu, ponieważ moje zaangażowanie w Talkie jest znaczące. Tamten startup bardzo szybko się rozwija i wymaga bardzo szybkich decyzji i bardzo dużego mojego zaangażowania. Zorientowaliśmy się, że Pragmatists potrzebuje kogoś, kto wejdzie na moje miejsce prowadzić ten dialog biznesowy z potencjalnymi klientami, spojrzy trochę na to, co zebraliśmy przez te 12 lat, na kompetencje, które mamy, usługi, które możemy świadczyć, nie tylko związane z tworzeniem oprogramowania, ale takie jak przez wiele lat w Sages, czyli szkolenia, warsztaty w różnych obszarach, którymi się zajmujemy, mentoring, audyty. Obecnie mamy świetną bazę do tego, żeby to opakować i komunikować, że to są te elementy, w których jesteśmy naprawdę mocni. Więc tak naprawdę dopiero teraz doszliśmy do takiego momentu profesjonalizowania tych działań stricte marketingowo-sprzedażowych.

Mówiąc o profesjonalizacji, to czy takim punktem zwrotnym był ten moment, w którym przestałeś programować, aktywnie brać udział w projektach, tylko zająłeś się sprzedażą, zarządzaniem? To pewnie był ten pierwszy moment, teraz jest drugi etap. Czy to oznacza, że trzeba szukać tych nowych ról w zespole, osób, które przejmą twoje dotychczasowe obowiązki – taki poziom managementu czy middle-managementu?

Ja jestem idealistą i to wychodzi w wielu różnych obszarach. Kiedy zorientowaliśmy się, że tego mojego czasu już nie starcza na tyle osób i tyle projektów, tylu klientów, którzy też potrzebują mojego zaangażowania, to ja bardzo dużo zastanawiałem się nad tym, w jaki sposób ustrukturyzować tę firmę, żeby działać efektywniej, ale nie zaburzyć naszej kultury organizacyjnej. Bo jednym z jej głównych elementów na tamtym etapie, zupełnie innych niż wiele software house’ów na takim etapie, była płaska struktura. My mieliśmy strukturę płaską – był Paweł Lipiński i cała reszta firmy. I ona do jakiejś skali pewnie fajnie działa, ma bardzo dużo ludzi, lubi pracować w takich firmach, bo wiesz, co się w takiej firmie dzieje, znasz wszystkich ludzi, jest to pewna „rodzina”, są relacje dużo bliższe i dużo bardziej osobiste niż w firmach ze strukturami menedżmentowymi. Więc żeby – z jednej strony – rozwijać ten biznes i go profesjonalizować, a z drugiej – nie zaburzać tej kultury, chcieliśmy w maksymalnym stopniu utrzymać to, że każdy w wolnym momencie może przyjść i wygłosić swoje zdanie i ono będzie wysłuchane. To, że każdy może mieć bezpośredni wpływ na to, czym to Pragmatists jest. U nas nowo przychodzący programista może w pierwszym miesiącu powiedzieć: „Nie podoba mi się to i to”, i on jest tak samo wysłuchany jak Kamil, który jest u nas od 12 lat. I to jest dla nas bardzo ważne. Ludzie, którzy przychodzą z zewnątrz, mają świeże doświadczenia z różnych innych miejsc, mają świeże pomysły, w związku z tym jak najbardziej chcemy korzystać z tej świeżości. A poza tym ta partycypacyjność rodzi motywację. Ludzie czują, że mogą wpływać na środowisko, w którym są. To jest tak jak mieszkać w domu a mieszkać w hotelu. Wiem, że są ludzie, którzy latami mieszkają w hotelu i sobie z tym radzą – ja miałbym z tym problem. Ja potrzebuję mieć wpływ na środowisko, które mnie otacza.

My zdecydowaliśmy się nie wprowadzać ścisłej, twardej struktury z rolami przypisanymi do osób, które są menedżerami takiego i takiego szczebla, tylko raczej pójść w kierunku takiego nurtu zbliżonego do holakracji. Żeby utrzymać partycypacyjność, zbudowaliśmy takie ciało, które nazywamy „naradą”, w którym może brać udział każdy, z takim zastrzeżeniem, że jak się decyduje, to musi brać w nim udział, bo zaangażowanie w to to jeden z elementów jego pracy. I to wspiera mnie w zarządzaniu ludźmi. Z jednej strony identyfikuje inicjatywy, które trzeba prowadzić, te elementy, problemy organizacyjne, kulturowe, z klientami itd., i powołuje grupy robocze, które już potem zajmują się tymi tematami i je realizują. Od rzeczy tak błahych jak zorganizowanie mikołajek dla dzieci, których mamy już 40 dzieci w firmie, po duże, poważne inicjatywy, jak np. rozwój liderów projektów, rozwój zawodowy pracowników w kierunku podwyższania kompetencji, w szczególności wspierania liderów projektów. Więc takich obszarów, które są do zagospodarowania w firmie jest bardzo dużo i ten model, który w tej chwili mamy od mniej więcej dwóch lat, nam się naprawdę sprawdza. Czuję ogromne wsparcie, a z drugiej strony nie utraciliśmy takiej partycypacyjności – do narady może przyjść każdy i na co dzień to są koledzy z zespołów i osoby z nie lepszą wizytówką, na lepszym papierze, tylko z tej samej krwi koledzy i koleżanki z zespołów. Wydaje nam się, że pod tym względem to unikatowe środowisko i że udało nam się mimo wzrostu nie utracić tej partycypacyjności.

Ale potem tę konkretną robotę ktoś musi wykonać – marketing, zmiana strony, ustawienie reklamy, kontakty z klientem, odbywanie rozmowy. Jak rozumiem, od tego są już te grupy robocze, delegowane przez tę radę.

Twardych, konkretnych kompetencji nic nie zastąpi. Jeżeli poszukujemy osoby do marketingu, to nie wyłaniamy jej spośród programistów, tylko szukamy kogoś, kto te kompetencje już posiada. Jak szukamy kogoś do rekrutacji, to kogoś, kto ma doświadczenia albo przynajmmniej chęć zajmowania się tym obszarem. Natomiast trzeba pamiętać, że w zakresie pracy operacyjnej, to oczywiście są to specjaliści z poszczególnych dziedzin, natomiast w zakresie działań zarządczych, to my nie mamy u nas nikogo, kto jest z zawodu menedżerem.

Jak się rozwijasz jako osoba zarządzająca, żeby takie pomysły móc wdrażać w życiu?

Odpowiedź jest złożona. Myślę, że odpowiedzią numer jeden na to pytanie jest to, że nie tylko ja jestem osobą, która się tym zajmuje. Ten model partycypacyjny służy m.in. temu, że z pomysłami na hipotezy, eksperymenty również zarządcze przychodzi cała firma, wiele osób. Ja tak odczytuję moją rolę, żeby budować takie środowisko i wspierać takie zachowania, które spowodują, że to będzie dobrze działało. Oczywiście nie jest tak, że wszystko to są pomysły zupełnie nowe i nigdzie na świecie więcej ich nie ma – nie przypadkiem padł termin „holakracja”, ponieważ trochę jest technik zarządzania turkusowymi organizacjami czy okołoturkusowymi organizacjami; nie inspiruję się tego typu stylami menedżmentu. Ja na pewno dużo czytam, nie tylko twardą literaturę w postaci książek, ale chyba przede wszystkim bardzo dużo artykułów, dość dużo korzystam z medium i myślę, że tam upatruję dużego obszaru mojego rozwoju zawodowego.

Te wyzwania, z którymi się stykam, wymuszają na mnie niejako bardzo aktywny rozwój w bardzo szerokim zakresie kompetencji. W Talkie na początku to był spin-off z Pragmatists. Po prostu jeden z zespołów, który robi projekt wewnętrzny, nie zewnętrzny, ale od zeszłych wakacji mamy dwa fundusze, które w nas zainwestowały. To oddzielny byt prawny, byt z zupełnie inną strukturą, organizacją, uwarunkowaniem. Powiedzmy sobie szczerze, inwestorzy nazywają się inwestorami, ponieważ inwestują, wsadzają pieniądze po to, żeby wyjąć ich jeszcze więcej, w związku z tym oczekują wyników. Takiej presji na wynik my w Pragmatists nigdy nie mieliśmy. Trzeba pamiętać, że Pragmatists było stworzone w takim celu, żebym ja miał dla siebie takie miejsce do pracy, w którym będę chciał pracować. A potem okazało się, że także wiele innych osób chce w nim pracować. Mamy ekstremalnie niską rotację, bo na poziomie 5%. Ludzie u nas pracują latami i nie chcą zmieniać tego środowiska, bo chcą mieć wpływ na to, co robią, i pracować w taki sposób.

Talkie jest zupełnie innym bytem. Musi wzrastać szybko i bardzo szybko pozyskiwać klientów, bo jak nam się skończą pieniądze, to będzie trzeba zwinąć biznes. Więc zupełnie inne uwarunkowania i zupełnie nowy dla mnie obszar, z jednej strony stylu zarządczego, z drugiej – takiego delegującego bardziej bezpośrednio, a nie tylko wtedy, kiedy ktoś się zgłosi. Zupełnie nowe kompetencje w zakresie pozyskiwania inwestycji, rozmawiania o inwestycjach, całego tego obszaru związanego z VC. Nie mogę powiedzieć, że jestem ekspertem w tej dziedzinie, jestem na etapie zdobywania moich kompetencji i rozumienia, jak te wszystkie puzzle się ze sobą składają i co zrobić, żeby na koniec osiągnąć sukces.

Na razie rozmawialiśmy o software housie, o poszczególnych etapach jego rozwoju i o tym, jak to wygląda w chwili obecnej. I nagle pojawia się Talkie. Czy ono pojawiło się z okazji jakiegoś projektu Pragmatists, czy był to niezależny pomysł?

My w Pragmatists kładziemy bardzo duży nacisk na rozwój pracowniczy, mówiąc krótko: robimy szereg różnych rzeczy, żeby ludzie mieli przestrzeń do rozwoju zawodowego. Mamy budżet szkoleniowy, szkoleniowo-konferencyjny. Każdy ma prawo do spędzenia 10% swojego czasu pracy na różnych działaniach samorozwojowych i one nie są ukierunkowywane w żaden twardy sposób. Mają to być takie działania, które związane są z wykonywaną pracą, ale nie muszą być związane bezpośrednio z projektem. Poza tym mamy cotygodniowe półgodzinne, okołolunchowe spotkania, na których ktoś coś opowiada. Oczywiście nieograniczone książki i inne tego rodzaju rzeczy – to już zaczyna być standard, ale również robimy wewnętrzne hekatony. Staramy się, żeby dwa razy do roku był taki dwudniowy hekaton.

Na przełomie grudnia 2017 r. i stycznia 2018 r. mieliśmy taki hekaton pt. „AI” i wszystkie projekty musiały wpasować się w obszary machine learningu. Ale dość dużo hekatonów ma charakter ogólny. Niektóre zespoły pracują nad wewnętrznymi narzędziami. Pojawiają się także zajęcia niezwiązane z naszą główną działalnością. I w 2018 r. jednym z pomysłów była próba zrobienia voicebota. W związku z tym, że pracowaliśmy już wtedy z siecią fryzjerską Jean Louis David, a dokładnie z firmą Provalliance, która jest jej właścicielem. Pomysł był taki, że jak robić voicebota, to zróbmy takiego, który będzie umawiał do fryzjera. I ja temu zespołowi, który ten temat sobie wymyślił i zaczął się nim zajmować, obiecałem, że jeżeli wyjdzie z tego coś sensownego, to ja wezmę ten projekt, pójdę do zarządu Jean Louis David i zobaczymy, co się wydarzy. I faktycznie było tak, że w te dwa dni udało się zrobić voicebota związanego na sznurki. Koledzy wzięli dużo różnych API, połączyli je ze sobą, dopisali kilka linijek kodu, które zaimplementowały taki główny flow rozmowy w zakresie umawiania wizyt. I z tym poszliśmy do zarządu Jean Louis David i tam była euforia, bo oni mieli Contact Center, które działało 8–20 tylko od poniedziałku do piątku i w związku z tym ludzie dzwonili po godzinach, w weekendy i nie mogli się dodzwonić. Koszty rosły, bo rósł im biznes – klasyczny problem. Do tego zarządzanie tym działem, który nie jest kluczowy z ich punktu widzenia, tylko jest takim dodatkiem. W związku z tym ten pomysł bardzo im się podobał.

Zdecydowali się zainwestować w ten pomysł, żeby doprowadzić to z takiego powiązanego na sznurki, szybko zahakowanego rozwiązania do czegoś, co można by wykorzystywać produkcyjnie. I ja wtedy doszedłem do wniosku, że OK, skoro jest tak, że jednak to rozwiązanie powoduje taką euforię, to coś w tym musi być. Nie mogę powiedzieć, że to było jakoś super dobrze policzone, badania rynkowe przemyślane, ale doszliśmy do wniosku, że każdy software house w którymś momencie ma wielką potrzebę zbudowania jakiegoś produktu, bo każdy chyba czuje, że ma tyle kompetencji, że aż żal nie zrobić czegoś swojego, My też to mieliśmy, w związku z czym zdecydowaliśmy się wystartować ten projekt.

Myślę, że tajemnicą sukcesu tego projektu było to, że od samego początku powiedzieliśmy sobie bardzo jasno, że robimy ten projekt jako niezależny byt w Pragmatists, a nie jako taką implementację kliencką jak inne softwarehouse’owe projekty, tylko wtedy, jeżeli faktycznie zbudujemy do tego niezależny zespół. Ten zespół nie będzie zajmował się niczym innym, tylko tym projektem, podobnie jak wszystkie inne zespoły nie zajmują się żadnym innym projektem, tylko swoimi rzeczami. Traktujemy ten wewnętrzny projekt nie jako coś do zrobienia z doskoku, gdy ktoś ma akurat wolne przeroby, tylko jako taki super poważny projekt. Połączyło się to jeszcze z dużym zbiegiem okoliczności, dlatego że Product Managerka jednego z naszych projektów w Pragmatists, z którą pracowaliśmy już od dwóch lat od strony naszego klienta, zakończyła współpracę ze swoim pracodawcą, a że z nami pracowała dwa lata, siedząc u nas w biurze, to ja powiedziałem: „Ada, może to nie jest zły pomysł, żebyś została i poprowadziła ten pomysł”. Ada doszła do wniosku, że to jest dobry pomysł i dołączyła do nas jako Chief Project Officer tego nowego bytu. Szumna nazwa, bo tych osób tam na początku było bardzo mało, więc prawie każdy był dyrektorem. Ada ma fantastyczne doświadczenie i przez te dwa lata już wiedzieliśmy, co ona potrafi w zakresie prowadzenia produktu. Weszła z nami na tę drogę i poprowadziła ten produkt.

W tej chwili Talkie to kilkanaście osób w bardzo różnych rolach. Talkie jest platformą do budowania voicebotów SaaS-ową. Taką wersję SaaS-sową już otwartą na świat zamierzamy wypuścić w tym roku, na razie jesteśmy na takim etapie, że ta platforma jest dostępna dla naszych partnerów, którzy budują na niej rozwiązania. Mamy również swój wewnętrzny zespół – Conversation Design, który zajmuje się budowaniem voicebotów dla naszych klientów w oparciu o naszą platformę.

Czyli zupełnie inny zestaw kompetencji okazał się tu potrzebny, ale też i szybsza rekrutacja nowych osób, które wcześniej stopniowo można było wyławiać z zespołu, budować taki organ zarządczy i stopniowo rekrutować specjalistów z różnych obszarów. Więc tu trzeba było szukać tych ludzi szybko i na odpowiednim już poziomie. Czy mieliście tu kontakt z Product Managerem czy też były inne role, które musieliście szybko zrekrutować z „ulicy”, czy były to osoby, które już znaliście i było łatwiej?

Rekrutowaliśmy z „ulicy” dość dużo. Myślę, że naszymi najciekawszymi rekrutacjami były te do działu Conversation Design. Po pierwsze dlatego, że w ogóle nie wiedzieliśmy, kogo rekrutować, jakie umiejętności, kompetencje powinna mieć taka osoba. A po drugie – jeszcze do niedawna nie istniał taki zawód. On jest zupełnie nowy. Trzeba mieć nie wiadomo jakie kompetencje – kogoś, kto z jednej strony będzie bardzo analityczny, będzie w stanie zrozumieć, o co temu klientowi chodzi, rozumieć proces obsługi klienta, w jaki sposób chce się kontaktować ze swoimi klientami, przełożyć to na de facto język programowania, bo my musimy te boty zbudować. Jest to wizualne narzędzie typu low-code, ale mimo wszystko bez takich podstawowych elementów programowania typu pętle, warunki nie da się zrobić takiego rozwiązania. Więc muszą być na tyle analitycznymi osobami. Z drugiej strony nie chcemy, żeby to były osoby techniczne, tylko nietechniczne, mające łatwość rozumienia klienta, empatię tych osób, które potem z tymi naszymi botami muszą rozmawiać – tak więc bardzo duża kreatywność. Bo tu nie można po prostu wziąć skryptu z Contact Center i przełożyć go bezpośrednio na rozmowy z botem, bo dynamika rozmowy z botem jest zupełnie inna.

To chyba były najciekawsze rekrutacje, bo nasz zespół jest w tej chwili wyłącznie damski, co w świecie IT jest dość rzadkie. Akurat tak się złożyło, że spośród wszystkich kandydatów, którzy do nas się zgłaszali na te stanowiska, to właśnie koleżanki, które pracują w tym dziale, były bezkonkurencyjne w tych trzech fazach rekrutacji (bo tak po kolei dodawaliśmy osoby do tego zespołu). Ciekawe jest także ich wykształcenie i wcześniejsze doświadczenie, które pochodzi głównie z miękkich nauk, takich jak socjologia, psychologia. Taki zlepek kompetencji na pewno bardzo pomaga. Natomiast z punktu widzenia rekrutacji to na pewno było bardzo ciekawe, bo zupełnie nie wiedzieliśmy ani kogo szukamy, jakie cechy powinien mieć, żeby dobrze radzić sobie z tą pracą, ani w jaki sposób zbudować ogłoszenie rekrutacyjne. To nie jest tak, że wiadomo, gdzie składać ogłoszenie, np. na Pracuj.pl. napisać, że potrzeba kogoś, kto będzie szkolił boty.

Na koniec chciałbym dopytać o wątek finansowania w kontekście Talkie. Wspomniałeś, że są inwestorzy, fundusze. Skąd taki pomysł i decyzja, że wpuszczacie inwestorów i chcecie iść taką drogą?

Były dwa elementy. Jeden był taki, że zorientowaliśmy się, że ten rynek zaczyna się zagęszczać. Jak startowaliśmy w 2018 r., to były firmy, które robiły jakieś voiceboty, ktoś gdzieś kiedyś rozmawiał z jakimś voicebotem windykacyjnym z Alior Banku, ale tak naprawdę nikt nigdy o nich nie słyszał. Więc jak weszliśmy na rynek z jednak rozpoznawalną marką Jean Louis David i voicebotem, który był centralnie na infolinii, nie gdzieś tam schowany na czwartym poziomie, tylko centralnie odbierał wszystkie telefony, to okazało się, że to w ogóle da się robić. I zaczęły pojawiać się firmy dotychczas chatbotowe, które dodawały sobie ten element voicebotowy, który ma zupełnie inną charakterystykę, ale mechanizm z grubsza wydaje się ten sam, więc przynajmniej rozumiem, skąd ten pomysł. Tym bardziej mam wrażenie, że chatboty trochę zawiodły. Kilka lat temu był taki bum chatbotowy, po czym okazało się, że jednak tak na koniec to jest taki if-else, który gdzieś tam jest za tym chatbotem i nie pozwala napisać dłuższego zdania, dowiedzieć się czegoś sensownego, tylko tak naprawdę klika się w jakieś klawisze; może troszkę wygodniejszy interfejs użytkownika, bo w środku Facebooka czy bezpośrednio na głównej stronie. Więc albo tego rodzaju firmy, albo firmy, które od zera doszły do wniosku, bo trafił im się projekt jak nam, że będą budowały voiceboty.

Rynek zaczął się zagęszczać, zaczęli pojawiać się duzi gracze – duże firmy wdrożeniowe, z technologiami mocno enterprise’owymi. Doszliśmy do wniosku, że albo przyspieszymy nasz wzrost, rozwój produktu, co oznacza zainwestowanie bardzo szybko bardzo dużej kwoty, bardzo szybko rozbudujemy ten zespół, albo nie ma szans, żebyśmy byli w stanie wyróżnić się na tym rynku. I to ewidentnie był dobry pomysł. Bardzo spodobał się naszym inwestorom. W dodatku mieliśmy dość dużo doświadczenia międzynarodowego. Przez 12 lat działaności 90% przychodów wygenerowanych było zagranicą. Te moje doświadczenia międzynarodowe, moje doświadczenia z Pragmatists oraz doświadczenia Ady – mojej cofounderki w Talkie, która ponad 10 lat pracowała w Londynie – spowodowały, że byliśmy przekonujący dla naszych inwestorów w tym, że naprawdę mamy potencjał działania międzynarodowego, a nie że tylko angielski na poziomie B1. Więc i inwestorzy byli zainteresowani pójściem w tę stronę, zainwestowaniem w spółkę, która ewidentnie ma potencjał wzrostowy, umie budować produkty i ma osoby na pokładzie, które tego dowodzą, umie tworzyć dobre oprogramowanie, ma doświadczenie międzynarodowe. A w dodatku te voiceboty ciągle jeszcze nie są mainstreamowe, ciągle tych firm jest jednak mało na polskim rynku. I to w dodatku Polska jest doliną voicebotową. W wielu krajach jest 1–2 dostawców, więc jeszcze jest o walczyć w takiej skali międzynarodowej; myślę, że w Polsce już jest trudniej. To były te elementy, które przekonały tych naszych inwestorów.

Dla nas możliwość zdobycia takiego kapitału, żeby móc bardzo szybko rosnąć, a nie tylko tak bootstrapować ten biznes, powoli go rozwijając z przychodów Pragmatists, to też jest zupełnie inna szansa. A prawda jest taka, że ja już jestem po 40, niedużo, ale jednak, co oznacza, że chętnie porobiłbym już coś innego, coś nowego, coś ciekawego, a to są zupełnie nowe rzeczy, zupełnie nowy rodzaj biznesu. Bardzo fajni są ci nasi inwestorzy, z ogromnym doświadczeniem, przedsiębiorcy, w związku z tym ludzie, od których my jako cofounderzy w Talkie mamy możliwość uczenia się rozmawiania, a w końcu ludzie, którzy mogą też nas przygotować na kolejne fazy rozwoju tego biznesu. Bo jak wchodzimy na tę ścieżkę, to nie po to, żeby dostać kilka milionów i je przejeść, stać się firmą, która będzie w miarę przędła. Cel jest taki, żeby jednak rosnąć i być międzynarodowo rozpoznawalnym bytem. I na pewno ktoś, kto przynajmniej od tej strony finansowej, fundraisingu ustawi nas odpowiednio i wesprze w tym, żeby pozyskiwać te kolejne rundy finansowania, budując równolegle stabilny biznes, to byłoby dla nas mega kuszące.

Gdzie widzisz dla siebie ciekawe perspektywy w IT? Powiedziałeś o tym nowym, wspaniałym świecie po 40, więc czy bardziej myślisz o startupach, czy o tym obszarze sztucznej inteligencji, czy jeszcze czymś innym?

Na pewno biznesy, które są ciekawe na jakimś rynku, to są te, które są proporcjonalne do rozwoju tego rynku. Dwanaście lat temu startowanie software house’u było świetnym pomysłem i myślę, że to, gdzie dzisiaj jesteśmy w Pragmatists, jest świetnym tego dowodem. Z firm, które wystartowały w tym samym okresie Software Mind, Polidea, która w tej chwili została sprzedana do Snowflake, ale również była mocnym punktem na mapie polskich software house’ów. Touk pewnie trochę wcześniej. Trochę takich software house’ów z pierwszych stron gazet, przynajmniej w zakresie naszych technologii javowych i okolic wtedy powstało. One mają się świetnie, tworzą bardzo fajne rozwiązania, na pewno mają świetnych ludzi na pokładzie. I to był wtedy taki moment, żeby budować software house.

Czy ja dzisiaj startowałbym software house jako programista? Chyba nie. To bardzo gęsty rynek z ogromną konkurencją międzynarodową. Trzeba naprawdę dobrze wiedzieć, w czym jest się dobrym, mieć bardzo dobry pomysł i to, jak go rozwijać, żeby nie odbijać się o każdego klienta, z którym się rozmawia o to, dlaczego tak drogo, a przecież w Dniepropetrowsku można za 20 dol. za godzinę. To są rzeczy, z którymi każdy, kto założy software house i zacznie mówić: „Ale ja mam chłopaków, co umieją dobrze programować”, będzie się odbijał od tego pytania permanentnie. A powiedzmy sobie szczerze, w Warszawie, Poznaniu, Krakowie i Wrocławiu nie ma żadnej szansy utrzymać software house, trzymając stawki wschodnioeuropejskie czy z takich mniej rozwiniętych technologicznie i gospodarczo krajów. Więc wydaje mi się, że na dzisiaj powinniśmy iść w kierunku gospodarki opartej na wiedzy. Więc taka podstawowa wiedza „umiem programować” przestaje być wyróżnikiem.

Na pewno jest tak, że ten nurt sztucznej inteligencji jest w tej chwili bardzo ważny. Nie wiem znowu, czy sztucznie inteligentny software house to na pewno ten kierunek, ale różnego rodzaju usługi wokół machine learningu to są rzeczy, które na 100% mają w tej chwili duży potencjał wzrostowy. Powiedziałbym, że startupy to fajny kierunek, natomiast na pewno trzeba sobie powiedzieć szczerze: dobry startup to nie tylko produkt. Produkt to może nieźle kuleć na początku. Najważniejsze to przekonanie rynku, biznes, elastyczność działania, szybkie podejmowanie decyzji – to niekoniecznie są kompetencje stricte programistyczne. Świetny produkt oczywiście ma rację bytu, on musi być bardzo dobrze zrobiony, żeby ludzie potem chcieli z niego korzystać, ale jest to tylko element tego, czym jest startup. I dlatego twierdzę, że same tylko kompetencje programistyczne w mojej ocenie na dzisiaj nie są wystarczające do tego, żeby budować biznes.

W Polsce na pewno problemem jest finansowanie startupów. Wszyscy zachwycają się Izraelem, jaki to wspaniały kraj startupów, ponieważ tam jest już jeden startup na 50 osób czy jakaś inna podobnie niesamowita statystyka – tylko jakie są powody do tego? To oczywiście jest naród ludzi szalenie przedsiębiorczych, w którym są wysokiej jakości uczelnie, wysokiej jakości edukacja. Ale przede wszystkim to jest kwestia dostępności dofinansowania i tego, na jakich warunkach jest finansowanie, jeżeli my z naszymi doświadczeniami, z tak mocnym zespołem zdobywamy dofinansowanie, które wiąże się z tak koszmarną ilością biurokracji jak to związane z programami NCBR-u, PFR-u, dominującymi na polskim rynku finansowania startupowego, do czego tak naprawdę trzeba by zatrudnić specjalistów, jeżeli chcesz się naprawdę skupić na biznesie.

My mamy o tyle dobrze, że jesteśmy fantastycznym zespołem, który tak sobie świetnie radzi w obszarze IT, budowania produktu, sprzedaży, że ja mogę wziąć na siebie najgorszą robotę robienia Exceli, raportów i całej tej koszmarnej biurokracji, tylko po to, żeby pokazać, że my rozsądnie wydajemy pieniądze. Jeżeli te innowacje trzeba półtora roku wcześniej zdefiniować z dokładnością do miesiąca i to, jak będziemy na nie wydawać pieniądze, to nie jest to żadna innowacja. To jest stary, waterfallowy model robienia projektów z lat 70. Tak długo, jak w Polsce tak będzie wyglądało finansowanie startupów, to jest dla wariatów albo ludzi, którzy mają tak dużo kompetencji wokół siebie zebranych, że stwierdzają: „OK, ja w to pójdę z pełną świadomością”. Jeśli idziesz w to z pełną świadomością, to musisz wiedzieć, że to nie jest tylko tak, że ja dostanę teraz trzy miliony, z którymi będę robić, co chcę. Naprawdę trzeba mieć świetny pomysł, bardzo mocny zespół, a na koniec mnóstwo biurokracji.

Na temat finansowania z NCBR nakręcimy jakiś odcinek, bo mamy znajomych, którzy takie finansowanie dostali, poza tym my sami w takim dofinansowaniu bierzemy udział, więc o problemach, które poruszasz, zrobimy osobny odcinek. Ale jak to mówią: na bezrybiu jak rak ryba, więc w Polsce rzeczywiście o takie dofinansowanie najłatwiej, jeśli ktoś chce zrobić coś nowego, na co do tej pory nie miał środków.

Paweł, wielkie dzięki za twój czas. Życzę dużo powodzenia związanego z projektem Talkie i może za jakiś czas będziemy mieli okazję jeszcze raz porozmawiać.

Wielkie dzięki, Łukasz, za zaproszenie.