Czy warto outsourcować zespół produktowy? – rozmowa z Tomkiem Woźniakiem z Future Mind

W szesnastym odcinku podcastu „Zwinne organizacje” Paweł Tomkiel i Tomasz Woźniak z Future Mind rozmawiają o pracy software housów, o tym, czym różni się współpraca ze startupami od współpracy z korporacjami. Jakie są wyzwania, zalety i wady takiej współpracy. I czy bardziej się opłaca budować swój własny zespół produktowy, czy może warto uzupełnić brakujące kompetencje osobami „wynajętymi” z zewnątrz.

Gościem odcinka jest Tomasz Woźniak - CEO Future Mind. Założył firmę w roku 2008 i konsekwentnie nią zarządza oraz aktywnie uczestniczy w projektach klientów, skupiając się na walidacji modeli biznesowych i planowaniu strategicznym. Jest też wykładowcą na uczelniach wyższych, między innymi Akademii Leona Koźmińskiego i Collegium Civitas. Jest członkiem rady nadzorczej notowanej na GPW Digitree Group S.A. (dawniej SARE S.A.).

Transkrypcja podcastu:

Paweł: W dzisiejszym odcinku rozmawiam z Tomkiem Woźniakiem. Tomek jest współwłaścicielem i prezesem firmy Future Mind. Firmy, która ma za sobą ponad dwieście projektów z obszaru digital. Nadal jest aktywnie uczestniczący w tych projektach klienckich. Również Tomek jest wykładowcą kilku uczelni wyższych.

Tomek: W Warszawie, w Białymstoku.

Paweł: I chyba jesteś uznawany też za mentora polskiego środowiska startupowego, prawda?

Tomek: Tak, faktycznie doradzam młodym przedsiębiorcom, staram się pomagać im na drodze do bycia przedsiębiorcą z prawdziwego zdarzenia.

Paweł: Zaprosiłem Tomka do rozmowy, bo jest osobą, która ma dosyć dużą wiedzę o rynku software house’ów w Polsce, w Warszawie i nie wiem, czy też na świecie.

Tomek: No na pewno rynek polski jest mi rynkiem bliskim, natomiast, ponieważ próbujemy od jakiegoś czasu wychodzić też z naszymi usługami za granicę, więc troszeczkę tutaj, przynajmniej w regionie, orientuję się, jak wygląda sytuacja.

Paweł: Powinniśmy chyba zacząć od tego, czym jest zespół produktowy. Jak Ty, Tomek, definiujesz zespół produktowy?

Tomek: Zespół produktowy to jest trochę taka rzecz, że każdy chciałby go zbudować, ale bardzo trudno jest go skonstruować tak od ręki, dlatego, że jest złożony z wielu osób, które mają różne kompetencje i w zależności od tego, kto ten zespół buduje, czy buduje go start up, czy buduje go przedsiębiorstwo, czy korporacja, to ta budowa wygląda troszeczkę inaczej. Tak na to patrzę. I poczynając od startupu, czyli troszeczkę od historii też naszej działalności, kiedyś zespołem produktowym był founder, który pozyskał finansowanie od inwestora i przychodził do software house’u (po nieudanej próbie zrekrutowania zespołu inhouse’owego) z prośbą o to, aby ten produkt mu dowieść z reguły w czasie krótszym, niż to było możliwe. I te parę lat temu, kiedy zaczynaliśmy pracować jako firma usługowa i naszymi klientami były głównie startupy, szczególnie polskie, które pragnęły budować szybko tego polskiego unicorna, to tak naprawdę myśmy stanowili trzon tego zespołu, no i był jakiś człowiek na koniec, który tym zespołem próbował zarządzać. Natomiast niestety wielu founderów, którzy do nas przychodzili w tamtym czasie, to byli ludzie mający raczej biznesowy background, raczej przedsiębiorcy, a nie ludzie techniczni. W związku z tym, w tym modelu współpracy pomiędzy naszą firmą a takim startupem kluczowe było zaufanie, a jego brak skutkował po prostu porażką po obu stronach, często po naszej stronie finansowo, po stronie foundera brakiem produktu.

Paweł: Jak wyglądała taka współpraca, jeżeli mogę Cię zapytać?

Tomek: Wszystko jest kwestią tego, jak founder podchodził do rozmowy z nami. Bo niestety tak było, że przychodził z tą samą prezentacją, którą wykorzystywał do pozyskania finansowania i w oparciu o kilka slajdów próbował otrzymać od nas informację, ile będzie kosztować zrobienie tego projektu. Co więcej, bardzo często się okazywało, że założenia które poczynił, opierające się głównie o jakiś taki prosty PNL, że musi zatrudnić paru programistów i jakiegoś CTO, jakiegoś project managera, (może ten CTO będzie tym project managerem), były może nie tyle błędne, ale wynikały z braku doświadczenia, o którym przed chwilą powiedziałem.

Paweł: Niedoszacowane.

Tomek: Myśmy wtedym jako mała firma mówili, no dobrze, to spróbujmy. I podejmowaliśmy się takich zadań. No i na bazie często braku specyfikacji, tylko kilku slajdów, takiego one pagera niekiedy nawet, próbowaliśmy zaczynać pracę. Potem, po kilku latach, jak już tych startupów nam się udało zrobić z sukcesem kilka, to w ramach referencji pojawili się pierwsi klienci korporacyjni. I tutaj znowu mieliśmy inną sytuację. Tak już trochę odpowiadając na pytanie, jak się zawiązuje zespół produktowy – w tamtych czasach w pewien sposób walczyliśmy o fragment rynku, jakim były aplikacje mobilne, bo to był nasz core business. Wykorzystywaliśmy zarówno tą wiedzę zdobytą w relacji ze startupami, jak i naszą unikalność w postaci kompetencji, do tego, żeby wyedukować klienta korporacyjnego. W tamtych czasach pojęcie, np. time-in-material, czy pracy w metodykach zwinnych nie funkcjonowało w mentalności nikogo w takich organizacjach. Powiedzmy też szczerze, że nie było dyskusji na temat pracy w takich modelach. Była dyskusja na temat tego, że powstały jakieś RFP, powstała jakaś specyfikacja, czasami nawet bym powiedział dokładna i oczekiwało się od nas deklaracji fix rise, która generowała tak samo dużo ryzyka, jak ta niedoszacowana i nieokreślona wizja foundera w startupie. Więc tej różnicy praktycznie pomiędzy tymi dwoma modelami nie było. Niemniej, klient korporacyjny był trudniejszy. No bo tutaj trzeba było często wziąć na siebie odpowiedzialność, często trzeba było wziąć rolę takiego Dawida w walce z Goliatem w sytuacji powiedzmy stresującej, w sytuacji rozjazdu oczekiwań. Ryzyko konfrontacji z taką korporacją dla małej firmy, jaką wtedy byliśmy, było dość sporym ryzykiem i niejednokrotnie wiele nas kosztowało. Firma nawet w pewnym momencie stała na dość trudnym gruncie, bo jeden z klientów, duże konsorcjum realizujące wspólnie z nami projekt, nie był w stanie dostarczyć pewnych wymagań. Gdzieś tam duża firma, która za te wymagania była odpowiedzialna, zewnętrzna firma, stwierdziła, że woli zapłacić karę umowną niż procesować projekt. No i to nas postawiło w dosyć trudnej sytuacji. Natomiast dzisiaj patrzę na to troszeczkę inaczej. Bo ta edukacja za sprawą wielu rzeczy jest na coraz wyższym poziomie. Są uczelnie, które już kształcą. Pojęcie Scrum Mastera czy Product Ownera wydaje się być zdefiniowane. W związku z tym może się też wydawać nam, że ta sytuacja uległa poprawie. I ona faktycznie uległa poprawie, ale to jest nadal sytuacja daleka od idealnej, tak na to patrząc. W korporacjach z reguły w odróżnieniu od startupów było tak, że trafiała się osoba troszeczkę z łapanki, która w danym obszarze wydawała być się z perspektywy korporacji świadoma tego, co powinno być zbudowane i ona była typowana jako taka osoba, która ma ten projekt zawiązać. Natomiast znowu, myśmy nie mieli takiej sytuacji, że po drugiej stronie był zespół klienta, tylko byli raczej ludzie, którzy rzucali kłody pod nogi takiej osobie wyznaczonej przez korporację i poniekąd nam, czyli na przykład właśnie IT czy dyrektorzy różnych pionów. Konkludując, ten zespół projektowy, w zależności od tego, jaka to jest organizacja, wygląda inaczej. W startupach pewnie częściej zdarzają się osoby CTO czy jakieś zalążki zespołu deweloperskiego, w korporacjach z reguły jest twarde IT, które ma swoje priorytety, ma swoje zadania i ciężko się z tym IT współpracuje w przypadku nowego produktu cyfrowego, który w korporacji powstaje. A osoba Product Ownera czy osoba zarządzająca, może nawet jeszcze niezdefiniowana, czy odpowiedzialna za dowiezienie produktu jest osobą, która jest narażona na wiele, wiele trudności wewnątrz organizacji, jak i na zewnątrz. W związku z tym konstruuje ten zespół często na podstawie tego, co ma na stole i jakie zasoby dostała od poszczególnych komórek w organizacji. I to tak wygląda, taki byłby, powiedziałbym, moment status quo, a do momentu idealnego mam nadzieję, że dojdziemy podczas rozmowy.

Paweł: Czyli z tego, co mówisz, rozumiem, że wasi klienci z wami, ale też zakładam, że z innymi software house’ami, pracują w takim modelu, gdzie jest jakaś osoba z biznesu od klienta, która ma tu pomysł czy biznes case, czy przychodzi w ogóle w planie strategicznym stworzenia jakiegoś produktu i to ona jest waszym klientem, i to ona pracuje z wami jako deweloperami, a de facto IT potem w takiej korporacji, w takiej organizacji musiałoby wam postawić infrastrukturę i utrzymywać dany produkt. Stąd się rodzą te napięcia, tak?

Tomek: Ja myślę, że musimy się odrobinę cofnąć i sobie troszkę odpowiedzieć na pytanie, co to jest software house, okej? Bo ja mam nieustanny problem z wytłumaczeniem, nie tylko naszym niektórym klientom, czy wytłumaczeniem w ogóle rynkowi, że software house to jest takie słowo trochę, które jest bardzo, bardzo szerokie i każdy się próbuje tym software house’m nazwać, a nie każdy nim jest. Więc ustalmy może na potrzeby tej naszej dzisiejszej rozmowy, jakie mamy podmioty, które lubią albo mogą nazywać się software house’ami. I teraz, jakby nie rozwodząc się jakoś specjalnie, zdefiniowanie software house’u troszeczkę zależy od modelu biznesowego, który taka firma przyjmuje. I tych modeli biznesowych jest kilka, o tym za sekundę. No i te modele biznesowe mają naprawdę bardzo duże znaczenie w przypadku definiowania tych ram współpracy, o których rozmawialiśmy chwilę temu i pewnie jeszcze będziemy rozmawiać. Poczynając od prostego założenia, że jest to firma informatyczna, która zatrudnia u siebie informatyków, których wynajmuje klientowi na godziny, czyli to jest firma, która, jak to nazwano z angielskiego body leasinguje ludzi czy dokonuje tak zwanego team argumentation, co jest, wracając do Twojego pytania, outsourcingiem, tak? Więc jakbyśmy mieli trochę cofnąć się do Twojego pytania, bo pytałeś o outsourcing, my tutaj mówimy o wynajęciu ludzi na godziny, którzy będą pracowali prawie tak samo jak pracownicy inhouse, tylko są różne powody dla których organizacja decyduje się na ich zatrudnienie. Jakie to są powody? Czasami to jest kwestia capex, opex, czasami to jest kwestia, tak jak w przypadku Covida, szeroko popularnego w ostatnich miesiącach hiring freeze, czyli zamrożenia zatrudnienia. Czasami jest to kwestia braku czasu i skalowalności tych zespołów inhouse’owych, albo na przykład sytuacja, w której na potrzeby projektu trzeba szybko zwiększyć capacity zespołu. I to jest jakby pierwszy model, tak? Wynajmujemy ludzi na godziny i zarządzamy nimi tak, jakbyśmy zarządzali własnymi pracownikami, mimo że oni naszymi pracownikami nie są. Oni często siedzą u nas, a dzisiaj pracują zdalnie, ale są zasymilowani z zespołami, tak naprawdę w wielu organizacjach, często nawet nie wiadomo, że to są osoby, które są zatrudnione na zewnątrz, gdyby nie jakiś tam przedrostek przed emailem. Są też firmy, które próbują pracować na zakresach typu RFP, czy specyfikacjach, które próbują dowozić poszczególne etapy, czyli są zapraszane jako dostawca, który ma się zdeklarować, że w określonym czasie, określonymi zasobami dowiezie jakiś zakres. I to jest jakby kolejny model, i to są firmy, które blisko są tej definicji software house’u. Wydaje mi się, że najbliżej, bo wytwarzają konkretny produkt, na który się obie strony umawiają. No i na końcu są takie firmy, którą my się staramy być, czyli to są takie firmy, które odwzorowały całą drogę produktu cyfrowego, od początku do końca, i próbują świadczyć taką usługę kompleksowo end-to-end. W praktyce okazuje się, że często klienci korzystają tylko z poszczególnych podproduktów takiego procesu wytwarzania produktu cyfrowego, natomiast mamy też modelowe współprace, w których de facto, jak to kiedyś jeden z moich przyjaciół Piotrek Biegun powiedział, realizujemy wszystko, łącznie z CTO and service. Czyli pełnimy rolę takiego CTO dla startupu, czy korporacji, tylko należy pamiętać, że takich firm jest stosunkowo niewiele. To nie jest tak, że ja chcę się tutaj jakoś specjalnie reklamować czy chwalić unikalnością, bo to jest droga, którą przyjęliśmy jakiś czas temu z czysto kulturowych powodów. Patrząc na kulturę naszej organizacji, patrząc na to, co sprawia nam przyjemność. To nie jest jakiś unikalny model, ale jest to model, powiedział bym, zbilansowany finansowo. Nie daje on takich profitów jak body leasing, czy przeszacowane duże wyceny fix price’owe, na których się zarabia duże pieniądze, bo ktoś tam na to ma taki budżet i się za ten budżet próbuje coś zrobić, tylko to jest taka praca, w której bierzesz odpowiedzialność równolegle z Twoim klientem za to, co zostanie dowiezione. I ta odpowiedzialność jest bardzo, bardzo wyrównana po obu stronach. I taka współpraca nam najbardziej do tej pory odpowiadała.

Paweł: I to jest najbliżej zespołu produktowego, współodpowiedzialność. I to jest chyba też to pytanie, na które szukamy dzisiaj odpowiedzi. To znaczy, czy do firm w takim modelu biznesowym można wynająć taki zespół produktowy, który dba o produkt? Bo bierze za ten produkt odpowiedzialność i go ciągle ulepsza z perspektywy klienta, czy jest możliwa współpraca między organizacją a firmą, która działa w takim modelu?

Tomek: To jest trudne pytanie. Ona jest możliwa, ale organizacja musi osiągnąć pewną dojrzałość, pewną świadomość, aby móc zaufać firmie zewnętrznej. I to trochę w sumie nie ma znaczenia, jak bardzo duży zasób z tej firmy zewnętrznej wykorzysta, bo uświadomienie sobie problemu zaczyna się troszeczkę wcześniej. W momencie, w którym powstaje decyzja o tym, żeby taki produkt zbudować, my zawsze zadajemy pytanie, gdzie ta decyzja została podjęta i kto tą decyzję podjął. Bo każda organizacja działa w inny sposób, a my troszeczkę sobie je podzieliliśmy gdzieś tam w procesie sprzedażowym na takie, które są firmami prywatnymi, na takie, którymi zarządza fundusz private equity, czy takie, które są typowo family business, tak? Czy firmy, które powiedzmy, nie wiem, są regulowane, czyli pracują na rynku regulowanym i ich funkcjonowanie jest takie, a nie inne. I teraz, cofając się troszeczkę do tego modelowego klienta, w sytuacji, której o godzinie dwudziestej trzeciej dostajesz smsa od prezesa zarządu albo od właściciela firmy, która ma, nie wiem, tysiąc razy większe obroty niż Ty, z informacją, że na którejś becie, na którymś bildzie coś mu tam za przeproszeniem nie działa, to jest sytuacja, która wbrew pozorom w naszym przypadku i w naszych relacjach dość często się zdarza. Oczywiście to nie jest tak, że te smsy idą do mnie i ja to tam potem eskaluję w organizacji, tylko one są już kierowane do właściwych osób czy też trafiają na Slacka, czy trafiają za pomocą różnych narzędzi do jakichś paneli. Natomiast ten fakt zaangażowania tej osoby na samej górze, on jest wstępem do tego uświadomienia. Jeżeli ta decyzja o produkcie cyfrowym jest świadomą decyzją osoby decyzyjnej, to od razu możemy powiedzieć, że mamy pierwszy dobry początek potencjalnej współpracy. Druga kwestia, która jest nieco trudniejsza, no bo jeżeli mamy silną osobę zarządzającą w organizacji, to jak teraz ta osoba sceduje odpowiedzialność za produkt cyfrowy na tego product ownera wymarzonego, którego tak bardzo trudno znaleźć, to zadajemy sobie pytanie, czy ten product owner posiada, tutaj użyję słowa prawniczego, legitymację, do tego, żeby tym produktem zarządzić. No bo jak wspomniałem, pierwotnie było tak, że te osoby trafiały na to stanowisko trochę z łapanki. Takie były nasze obserwacje.

Paweł: W moim świecie to chyba byłby empowerment.

Tomek: Ja to trochę spłaszczałem zawsze do takiego dowcipu, że kto tam ma iPhone’a na sali, to Ty będziesz robił apkę mobilną. Ale to powiedzmy, że taki bardzo skrajny dowcip, wręcz bym powiedział, że suchar, ale nie ukrywam, że nawet ostatnio mieliśmy taką sytuację, że jeden z klientów wystartował produkt, nie mając w ogóle zespołu, nie mając w ogóle Product Ownera. Produkt się udało skończyć. Dopiero w momencie, w którym produkt trafił na rynek, zaczęły się poszukiwania tego Właściciela produktu, więc da się to zrobić. To nie jest tak, że się nie da. Tylko po prostu to generuje stres i budzi dosyć spore ryzyko braku komunikacji pomiędzy klientem a dostawcą. I teraz, co to jest ta legitymacja? Ta legitymacja to jest rzecz, która jest fundamentem do tego, żeby Product Owner mógł realizować produkt. Michał Jaskólski z Morizona, który od samego początku zarządzał cyfrowymi produktami swojej firmy, pełni rolę wiceprezesa. I oczywiście w nie każdej organizacji, szczególnie tej największej, da się Product Ownera zrobić wiceprezesem i nie mówię, że to jest jakiś sposób na to, żeby tą legitymację uzyskać, ale bardzo często okazuje się, że ten Product Owner, nawet jeżeli jest zrekrutowany z zewnątrz i ma kompetencje, to nie zostaje wprowadzony do organizacji we właściwy sposób. To znaczy to jest trochę tak jak minister bez teki, nie? Że wchodzi taki Product Owner i on sobie ma teraz skonstruować zespół produktowy. Tak jak wspomniałem, jest wokół niego sporo struktur, które przez ileś tam lat były tworzone, jakieś siły, jakieś silosy. I teraz, jak ta osoba ma się przez to wszystko przebić? Jak ona ma uzyskać właściwe zasoby wewnątrz organizacji, jak ona ma móc podejmować autonomiczne decyzje, co w definicji product ownera jest kluczowe, skoro ona ma osoby często wyżej w strukturze firmy, które nie zawsze są przychylne zmianom? No bo zmiana jest rzeczą trudną i dla ludzi, którzy, jakby to coachowie powiedzieli, są w swojej strefie komfortu i zawsze w niej będą, i nigdy z niej nie wyjdą, to brak zmiany jest dobrym sposobem na funkcjonowanie. I teraz ta legitymacja to jest, tak jak powiedziałem, sytuacja, w której osoba, która wymyśla produkt, czyli idąc tutaj przez początek naszej rozmowy, jeżeli ten produkt powstaje gdzieś tam na górze w organizacji czy potrzeba tego produktu powstaje i mamy ten pierwszy odhaczony pozytywny start, i potem dochodzi decyzja o zatrudnieniu takiego Product Ownera, no to teraz od tego przedstawienia, od umocowania, od dania temu człowiekowi kompetencji, budżetu, tej samodecyzyjności, niezależności będzie zależał sukces produktu cyfrowego. I jeżeli taka osoba w organizacji jest, to odpowiadając na Twoje pytanie, ta współpraca ma duże szanse powodzenia. Ale oczywiście zdarzają się sytuacje, w których takiej osoby nie ma i trzeba sobie wtedy radzić. No tak to niestety jest, że to nowe stanowisko Product Ownera jest stanowiskiem, które, wydaje mi się, konstruuje się. No bo mamy osobę stricte z IT, powiedzmy osobę techniczną, która w swojej ścieżce kariery gdzieś tam z product managera, dochodzi do wniosku, że chciałaby robić coś więcej, coś szerzej, coś bardziej niż tylko zakres projektu, tylko faktycznie mieć coś namacalnego na końcu, nie tylko ukończony projekt, ale coś, co wpłynie na organizacje, i ona idzie w tą ścieżkę Product Ownera. A z drugiej strony mamy tą sytuację taką troszkę patologiczną, czyli tą łapankę osób z biznesu, których nagle próbuje się nazwać Product Ownerami, mimo to że oni niekoniecznie zawsze muszą mieć ten pierwiastek technologiczny, który potrzebny jest, mimo wszystko, do tego, żeby zespołem programistów czy zespołem architektów, inżynierów zarządzić. Bo bez względu na to, czy weźmiemy sobie firmę z zewnątrz, czy weźmiemy sobie zespół wewnętrzny, trzeba umieć ocenić, czy ten zespół pracuje we właściwy sposób, z należytą starannością, i czy rekomendacje, które daje, przynajmniej gdzieś świta nam, że są to rekomendacje właściwe. Jeżeli tych umiejętności nie ma, no to to bez względu na to, czy weźmiesz sobie firmę z miasta, z ulicy, czy weźmiesz sobie trzydziestu ludzi ze swojej organizacji, to nie zarządzisz tym. Wydaje mi się, że odpowiedziałem na to pytanie, że jest możliwe, a to, czy jest łatwa, no to bez spełnienia przynajmniej tych dwóch kryteriów może być trudna. Ja bym powiedział tak, bez Product Ownera na pewno jest bardzo trudno pracować jako firma zewnętrzna, ale bez też świadomości, jaki ten produkt może mieć wpływ na organizację, też jest trudno współpracować. To jest trochę zamknięte koło.

Paweł: Tomek, z tego, co do tej pory powiedziałeś, można zrozumieć, że Product Owner, czyli osoba odpowiedzialna za wyniki biznesowe produktu, po pierwsze musi być umocowana w organizacji, musi mieć tą legitymację, musi być empowered i nie ma znaczenia, czy ona pracuje z zespołem wewnętrznym, czy zewnętrznym. Jaki jest set up współpracy, powiem tutaj w uproszeniu, z software house’ami, czyli z dostawcą programowania?

Tomek: Tak, to znaczy po pierwsze też dobry Product Owner nie ma znaczenia, czy ma background techniczny, czy ma background biznesowy. De facto nasz idealny klient musi mieć lidera, który ma budżet, który umie podejmować decyzje, umie rozwiązywać małe problemy i duże problemy. Małe to te w backlogu, duże to te w organizacji, o których powiedziałem. Blokery, które powstają poza zespołem produktowym to bardzo często, silosy, dług technologiczny, konflikty między wendorami – to się też bardzo często zdarza. Ten człowiek musi być bardzo skuteczny. Tak jak mówimy o ludziach skupionych na sobie egocentryk, to musi być człowiek, który jest produkt-centrykiem, jak ja to sobie nazwałem ostatnio, ze wszystkimi tymi złymi definicjami egocentryka. Czyli on musi być na tyle bezwzględny w budowaniu swojego produktu, że wręcz często narażony jest na konflikty i na konfliktowanie się. I teraz set up, bo o to pytasz, tak? Ja nie wiem, jak robią to inne firmy, szczególnie te, które definiujemy jako software house’y. One robią to w innych modelach biznesowych. My raczej podchodzimy do tego jako firma zewnętrzna, aby stworzyć taki core tego zespołu. Bo zobacz, każda organizacja, jak zaczyna ten produkt cyfrowy budować, ma inne zasoby. Niekiedy czas, niekiedy okoliczności biznesowe wymuszają na tej organizacji rozpoczęcie prac natychmiast. Nie ma czasu na rekrutację, nie ma czasu na zebranie trzonu tego zespołu. Czasami nawet, tak jak wspomniałem, nie ma czasu na zrekrutowanie Product Ownera. No, ale jest ktoś, kto danym pionem kieruje, nie wiem, pionem e-commerce’u, pionem sprzedaży internetowej, pionem digitalu… No i on mówi, no dobrze, tutaj w organizacji potrzebny jest produkt cyfrowy, bo tu nam dystrupcja zjada rynek i teraz trzeba zacząć tą pracę. I tak jak powiedziałem, my do tego podchodzimy w taki sposób, że oceniamy materiał wyjściowy. Troszeczkę na tym materiale, który nam klient wysyła, od razu wiadomo, kto ten materiał przygotowywał, jaka jest jego jakość. I podczas procesu ofertowego my już sobie troszeczkę zdajemy sprawę, z czym będziemy mieli do czynienia i w zależności od tego, abstrahując od bardzo szczerej rozmowy, o której za chwilę powiem, staramy się wystawić do projektu osoby, które będą jakby wypełniały luki po stronie klienta. W związku z tym to nie jest odpowiedź, że po stronie klienta powinni być ci ludzie, a po stronie dostawcy powinni być ci ludzie. My robimy to w taki sposób, jak dostajemy zapytanie, to po kilku tygodniach wiadomo, że tej organizacji brakuje odpowiednich osób i my te osoby po prostu przedstawiamy, i klient widzi w nich wartość. Bardzo szybko widzi w nich wartość, bo te osoby opowiadają na pytania, na które on nie potrafi odpowiedzieć.

Paweł: Czyli nie tylko dajecie deweloperów, tą siłę roboczą, przepraszam wszystkich programistów, którzy będą tego słuchać, ale też widzicie, jakich ról, jakich kompetencji brakuje w organizacji, która jest waszym klientem, tak?

Tomek: Ja sobie zawsze jako jeden z największych naszych sukcesów jako firma ceniłem to, że udało nam się zaprosić do współpracy osoby, które wcześniej pracowały w dużych organizacjach IT, w dużych korporacjach. Dlatego, że te osoby rozumieją, jak te organizacje funkcjonują i te osoby de facto, mimo to że dzisiaj u nas pełnią jakieś tam role project managerów czy właśnie są tym CTO and service, czy właśnie Product Ownerem and service, te osoby są zaprawione na tyle mocno w bojach, że one w mig wypełniają tą lukę po stronie klienta i w mig dowożą tą wartość, o której wspomniałem. W związku z tym taka osoba zastępuje często, no to nie chcę się powtarzać, ale zastępuje te kluczowe braki i dzięki temu klient może, odłożyć troszeczkę w czasie te blokery, które powstały w momencie, w którym on chciałby ten produkt, zespół produktowy skonstruować po swojej stronie jak najszerzej. No bo to de facto jest fajnie, jak sobie ten zespół produktowy po stronie klienta wszystko wymyśli, a potem przyjdzie do software house’u i powie to jest wpis z dokładnymi widokami i tutaj proszę nam wycenić, i powiedzieć, kiedy to będzie dowiezione. I my nie mamy problemu, żeby pracować w takim modelu, natomiast umówmy się, to też jest tak, że papier wszystko przyjmie. Ty jesteś specjalistą od innych metod, ja się troszeczkę na tym aż tak bardzo nie znam, żeby się wypowiadać merytorycznie, natomiast wiesz doskonale, że na takiej specyfikacji jest sporo ryzyk i pewnych założeń, które nie zawsze w praktyce potem, już w trakcie projektu, są adekwatne do rzeczywistości. Co więcej, każdy produkt cyfrowy podlega w trakcie jego pracy modyfikacjom. W startupach mówi się na to pivot, pewnie w projektach korporacyjnych mówi się to zmiana wymagań i teraz wiesz, trudno jest na etapie, w którym zespół po stronie klienta jest złożony na przykład tylko ludzi z biznesu albo tylko ludzi z IT, od razu powiedzieć, kto od nas będzie tutaj właściwą osobą. My jesteśmy małą firmą, w sensie średnią, bo myślę ilościowo, założyliśmy sobie jakiś czas temu, że zatrudniamy osoby wyłącznie z doświadczeniem i to kilkuletnim, w związku z tym ten „marge” polega na tym, że tak naprawdę, jak podchodzimy do tego klienta, to dopasowując osoby, dopasujemy ich nie tylko doświadczeniem, nie tylko samą funkcją, tylko też jakąś taką wiedzą techniczno-biznesową.

Paweł: Takim obyciem.

Tomek: Odpowiadając też trochę na to pytanie, bo chyba trochę odeszliśmy od zadanego pytania, my sobie założyliśmy, że osoby, które stanowią trzon średniego, middle managementu u nas w firmie, to są osoby, które mają i doświadczenie w biznesie, i doświadczenie w technologii. I nieważne, czy to jest team lider, który zarządza zespołem mobilnym, czy to jest team lider, który zarządza zespołem backendu, czy to jest head of PMO, czy to jest osoba, która nie wiem, jest szefem architektów czy szefem UX-owców, to są osoby, które potrafią się postawić w obu tych sytuacjach i w związku z tym w momencie, w którym klient do nas przychodzi, to nie wyobrażam sobie sytuacji, w której przychodzi i mówi dobrze, tutaj powiedźcie nam ilu programistów nam wynajmiecie. Bo to nie jesteśmy my, to już żeśmy ustalili chwilę temu, że to nie jesteśmy my. W związku z tym raczej nawet takiej współpracy nie podejmiemy. Bo to upewnienie się powinno być po obu stronach. My też musimy wiedzieć, że ci programiści dowiozą. Bo bierzemy jako właściciele firmy odpowiedzialność za efekt końcowy, tak? Który jest spisany w formie umowy pomiędzy stronami. I teraz nie ma tego set up’u na początku, to powiedziałem, on powstaje w trakcie docierania się. Co więcej, mamy taką tendencję do mówienia klientom, żeby rozkładać tą pracę nad tym produktem cyfrowym na poszczególne etapy. No bo jak sobie odrysujemy od linijki taki greenfield dla projektu cyfrowego, to jest ileś etapów, które powinniśmy przejść, żeby ten produkt, nawet w formule MVP mógł trafić na rynek. I my dokładnie w ten sposób działamy, czyli patrzymy sobie na tą linię produktu, patrzymy, co jest do zrobienia i zastanawiamy się, gdzie są braki po stronie klienta, które my jesteśmy w stanie wypełnić. I to jest ten team merge. O projekcie, który nie jest greenfield’owy, to też pewnie za chwilę powiemy, no bo on jest troszeczkę inny, bo ma swój dług technologiczny, ma swoje jakieś tam legacy, ma jakieś procesy, które są ustawione i na pewno z takimi projektami jest trudniej. Ale nadal ta sytuacja jest bardzo podobna, czyli mówimy do klienta dobrze, to show me what you got, powiedz szczerze, masz tego Product Ownera czy go nie masz, czy go potrzebujesz, będziesz miał tych ludzi z IT, którzy ci te end pointy dowiozą, czy może jednak my byśmy coś napisali, zanim oni się ogarną. Bo to nie jest tak, że jedni są gorsi, drudzy są lepsi, albo że wewnętrzne IT jest gorsze, a firma z zewnątrz jest lepsza, bo to jest tylko kwestia doświadczenia i kompetencji. Kwestia tego, jakie są priorytety. Korzystasz wewnętrznie z zespołu IT, musisz się liczyć z tym, że ten zespół ma inne projekty, które trwają równolegle tyle, co projekty greenfield’owe. Projekty greenfield’owe już są bardzo, bardzo mocno zaawansowane, są na rynku, są nagrody za te projekty, są jakieś super efekty, a z drugiej strony mamy projekty, które rozpoczęły się dokładnie w tym samym czasie i ze względu właśnie na te ograniczenia wewnątrz IT, jakieś inne priorytety, które, żeby była jasność, są uzasadnione – to nie jest tak, że szef, który zarządza tym zespołem wewnętrznym, nie chce dać tych ludzi. On po prostu ich nie może dać, bo ma zobowiązania, bo nie wiem, podnosi ERP’a na przykład albo robi coś, co jest kluczowe dla operacji tej core businessowej. A produkt cyfrowy gdzieś tam powstaje z boku. On nie zawsze jest od razu podpięty pod organizację. Czasami to jest sight project, czasami to jest eksperyment, czasami jakaś próba innowacji. I nie zawsze, mimo świadomości tej legitymacji Product Ownera, mimo świadomości zarządu czy zespołu właścicielskiego nad tym, że ten produkt musi powstać, on jest od razu mocno z tą organizacją spięty. Wtedy warto zwrócić uwagę trochę na firmy z zewnątrz, bo one są w stanie być takim działem IT, tylko dla tego Product Ownera, a niekoniecznie jako short resources z organizacji.

Paweł: No jest jeszcze na pewno kwestia tego, że ten Product Owner, jeżeli jest wzięty z organizacji, to zazwyczaj ta rola jest dodatkiem do tego, co miał do tej pory.

Tomek: To jest inna historia. To znaczy absolutnie masz rację i tak jak powiedziałem, pewnie jakbym miał przedstawić jakąś statystykę, to osiem na dziesięć projektów, które zaczynamy, to są projekty bez Product Ownera. To nie jest komfortowa sytuacja ani dla nas, ani dla drugiej strony. No, ale takie jest życie. Tych ludzi na rynku po prostu jest stosunkowo niewielu. Moich trzech, czterech klientów aktualnie walczy o jednego człowieka, dosłownie, który się pojawił na rynku i się okazało kilka dni temu, że walczą o tego samego człowieka. Więc to pokazuje bardzo dokładnie problem, który mamy i z którym trzeba sobie z tym radzić. Zaczynamy te projekty, bierzemy za nie odpowiedzialność i dzięki temu budujemy długotrwałą relację z klientem. To jest nasza przewaga konkurencyjna, wydaje mi się, nad zwykłym software house’em, który przyjdzie i powie pokażcie wymagania albo tu jest CV, ona kosztuje tyle i tyle za Monday i proszę, bierz sobie tego człowieka, daj mu komputer i radź sobie.

Paweł: Czyli bierzecie odpowiedzialność i to wy się stajecie takim Product Ownerem?

Tomek: Wspomniany Piotrek Biegun, mój przyjaciel, jak prowadził swoją własną firmę, własny software house, na jego stronie było napisane „CTO as a service”. Myśmy mu powiedzieli, że też jesteśmy takim trochę CTO service, bo na etapie walidacji, czyli na bardzo wczesnym etapie budowania wymagań do produktu cyfrowego, czasami jest potrzebne coś więcej niż Product Owner. Czyli osoba, która jest na takim poziomie wiedzy, że ona rozsądzi, czy dany produkt jest realny. Mówi się na to chyba fizz build check czy też, jak to po polsku by powiedziano, studium wykonalności.

Paweł: Bardzo, bardzo ładne określenie.

Tomek: I teraz znowu, często jest tak, że my też przyjmujemy rolę takiej firmy, która na tym bardzo wczesnym etapie ocenia zasadność tej decyzji, no bo powiedzmy sobie szczerze, gdzieś tam na spotkaniu strategicznym ktoś przyniósł jakieś rozwiązanie konkurencji, pokazał je i pojawia się potrzeba, ale tak naprawdę nikt specjalnie sobie nie zadaje pytania, czy to ma sens, albo czy to się opłaci na koniec, czy ktoś to kupi, czy jest to jakiś owczy pęd za innowacją. No i my często dostajemy takie challenge w postaci tego, że nie tylko trzeba to technicznie, zbadać, czy to jest wykonalne, ale często się okazuje, że ktoś coś wymyśla, czego na przykład nie przemyślał pod kątem tego, czy Apple i Google w formie aplikacji mobilnej to zaakceptuje, albo czy koszt lub marża na tym produkcie de facto na koniec dnia będzie właściwa. I dlatego my od 2013, 2014 roku rozwijaliśmy mocny zespół konsultingowy, żeby on był takim bardzo wczesnym zespołem weryfikującym, takim zespołem, który jest złożony z analityka, z architekta, z bardzo dobrego developera, jeżeli sytuacja, nie wiem, dotyczy jakiejś bardzo trudnej technologii, np. streamingu albo jakichś takich skomplikowanych rzeczy. I ten zespół działa na takim bardzo wczesnym etapie, kiedy jeszcze nawet ten Product Owner nie jest potrzebny. No bo on zna wymagania biznesowe tego produktu, ale my mu jesteśmy w stanie powiedzieć, czy to w ogóle jest „robialne”, czy to w ogóle można dowieść i czy wejdzie na rynek. Oczywiście nie weźmiemy za to odpowiedzialności, bo jest ileś tam rzeczy po wypuszczeniu produktu, które są od nas niezależne, ale ten podstawowy proces sprawdzenia zarówno techniczny, jak i biznesowy, często też realizujemy. I to jest kolejna pewnie unikalna wartość, tak nie chwaląc się w stosunku do takiej klasycznej metody zatrudniania zewnętrznej firmy.

Paweł: To Tomek, żebyśmy teraz mogli podsumować to wszystko, o czym powiedzieliśmy, jakbyś miał wymienić wyzwania, plusy, minusy współpracy z wendorem?

Tomek: Okej. To przejdę może najpierw do tych wyzwań i podsumowania wyzwań. Przygotowując się, przemyślałem to sobie i trochę odwróciłem to pytanie, czyli bardziej z naszej perspektywy, jakie są największe wyzwania pracy software house’u z klientem, bo to jest moja perspektywa. Idąc od początku produktu, ale znowu z naszej perspektywy, nie z perspektywy sprzedaj i zapomnij. Po pierwsze, bardzo często klienci przychodzą do nas z brakiem dokładnego i dokładnie zdefiniowanego modelu biznesowego. Często się okazuje, że nawet nie policzonego. Więc przychodzą i mówią ja sobie wymyśliłem taki produkt. I to nie ma znaczenia, czy to jest startup, czy to jest korporacja. Ja bym chciał go zrobić, ale nie wiem, w jaki sposób będzie zarabiał albo przynajmniej wydaje mi się, że wiem, ale nie do końca to policzyłem. Druga rzecz, bardzo bolesna dla nas, sporządzanie wyceny, nawet często widełek, to już jest i tak sukces, jak się tego klienta da namówić na widełki, w oparciu o jakiś Napkin prototyping albo kilka zdań opisujących produkt, nie? Na zasadzie, a ile będzie kosztował Uber dla hydraulików na przykład. Rozumiesz, mój ulubiony przykład. I to, wiesz, ja nie mam z tym problemu, żeby powiedzieć milion albo pięć, tylko pytanie, czy klient na tym poziomie jest w stanie podjąć decyzję o takiej inwestycji. Co więcej, ja to mówię już dzisiaj z uśmiechem, ale pamiętam czasy, kiedy odpowiadając śmiertelnie poważnie klientowi, że nie da się tego zrobić, słyszałem, jak to, jesteś profesjonalistą, nie jesteś w stanie ocenić ile będzie kosztował Uber dla hydraulików. No to trochę tak jak z samochodem, że kupujesz samochód i to jest tak, że on może na zewnątrz wyglądać jak replika Lamborghini, ale w środku nadal to będzie jakaś Toyota albo coś, co, że tak powiem, nie ma nic wspólnego z tym, co jest pod spodem. Więc bez większych przykładów motoryzacyjnych myślę, że nie musimy, natomiast ten przykład repliki bardzo dobrze oddaje, o co tutaj chodzi. Bo na front-endzie można wiele rzeczy pokazać, ale to, jak to działa pod spodem, to jest inna kwestia. Trzecia rzecz, brak zdefiniowanego budżetu. O ile nie oczekuję tego, żeby ten budżet zawsze był, to jednak staram się tłumaczyć klientom, że o wiele łatwiej się dogadać, kiedy wiemy ile jest pieniędzy na stole. Bo to nie chodzi o to, że my chcemy go okraść i zabrać te wszystkie pieniądze.

Paweł: Wziąć max.

Tomek: Wziąć max. Tylko chodzi o to, żeby obie strony wiedziały, do jakiego czasu mamy co dowieść, bo produkt nie jest do końca z gumy. Jeżeli ma się walidować rynkowo, to musi być co najmniej na tym poziomie MVP. Natomiast, bardzo często jest tak, że to takie zaszłe budżetowanie ma negatywny wydźwięk na dyskusję z software house’em. Bo ktoś mówi, no dobrze, to ja zabudżetowałem kwotę X, a my mówimy nie chcemy tej całej kwoty, my tylko chcemy dowiedzieć się ile jest potrzeba pieniążków albo czy tyle pieniążków wystarczy, żebyśmy ten produkt wasz dowieźli na rynek z sukcesem. I to jest trzecia rzecz, która mnie z perspektywy rozmów z klientami dość mocno frustruje, bo tłumaczenie tego, że my nie chcemy poznać budżetu, żeby go wyciągnąć w całości, tylko po to, żeby zgodzić się na jakiś efekt końcowy, jest trudne. I często wymaga wielokrotnego powtarzania, tłumaczenia, uzasadniania, dlaczego ja chcę ten budżet poznać, przecież ja mam się zdeklarować ile to będzie kosztować. Natomiast odpowiadając na pytanie odnośnie wad i zalet, wiesz, to jest pytanie, które jest bardzo trudne z mojej perspektywy, bo ja nie mogę być obiektywny. Bo odpowiadając Ci na pytanie, jakie są zalety, będę mówił pewnie o sobie czy o firmie, czy o branży naszej i starał się będę mówić na zasadzie samych superlatyw. I tak jak powiedziałem, wrócę trochę do tego team merge. Nasza kultura organizacji, którą udało nam się wypracować nie tylko w postaci ludzi, którzy z nami pracują od początku, czy od dziesięciu, jedenastu lat, tylko bardziej kultury w rozumieniu podejścia do relacji z klientem zakłada coś takiego, że my mówimy klientowi nam nie zależy na tym, żeby ci sprzedać wszystkich ludzi, bo na szczęście udało nam się taką pozycję wypracować, że ta kolejka może nie jest, za przeproszeniem, jak po Crocsy w popularnym hipermarkecie, tylko generalnie raczej ludzie się zgłaszają w miarę regularnie i nie narzekamy na brak pracy. Więc nawet z pragmatycznego, biznesowego punktu widzenia lepiej jest gdzieś ten zespół rozrzucić po klientach adekwatnie do jego potrzeb, niż próbować mu sprzedać wszystko na zasadzie nie przejmuj się, nie zatrudniaj Product Ownera, my tym Product Ownerem będziemy dla ciebie, będziemy tym CTO, zaprojektujemy, narysujemy, przeanalizujemy, zrobimy wam nawet API na waszym własnym systemie i generalnie wszystko zrobimy, będzie pan zadowolony. to nie na tym polega. Polega to na tym, że my sobie kulturowo założyliśmy, że będziemy te zespoły do klientów wystawiać na podstawie ich potrzeb i na podstawie realnej ilości zasobów, którymi oni dysponują. To jest pierwszy warunek, taki disclaimer trochę dla tych zalet i wad. Ja powiem tak, nie dam odpowiedzi wad, zalet, dam odpowiedzi na zasadzie, jak powinieneś ten software house wybierać. Czy to jest okej?

Paweł: To powinno być wartościowe dla naszych słuchaczy.

Tomek: Wybierz firmę, która ma track record w określonej materii. Nie musi być to firma z reguły najtańsza. Bo wiesz, napisać na stronie internetowej, że potrafisz zrobić aplikację mobilną albo zaawansowaną aplikację internetową może każdy. Papiery, tak jak strona internetowa, przyjmie wszystko. Ostatnio zdarzyła mi się taka sytuacja, że szukałem jakichś tam gadżetów, które chciałem wyprodukować stricte prywatnie, po czym trafiłem na stronę jakiejś agencji reklamowej, która zajmuje głównie się tymi gadżetami. No i patrzę na tę stronę, a tam w zakładce oferta – aplikacje mobilne. No to myślę sobie okej, spoko. Po czym, jak wrócę jeszcze trochę do tego, co dostaję na LinkedIn’ie, często jakieś propozycje cold mailowe na zasadzie, że robimy to, to, to i to, i potem wchodzę na tą stronę i mówię, no dobrze, to zobaczmy, co ta firma zrobiła, bo nigdy o niej nie słyszałem, no i się okazuje, że też ma napisane, że robi te aplikacje. Więc znowu warto jest sprawdzić track record, bo jeżeli tego nie sprawdzimy, no to bardzo często wprowadzamy dosyć duże ryzyko porażki. Druga rzecz, sprawdźmy dokładnie zespół, z którym będziemy pracować. To nie jest tak, że idziesz do gościa w software housie i jak jakimś lombardzie za wielką szybą ktoś ci podaje tam tych programistów, nie? Nie, no po prostu masz prawo wiedzieć, z kim będziesz pracował. Jeżeli masz się z tym zespołem dogadywać, wiedzieć, że wszystko zrobią we właściwy sposób, to masz prawo wiedzieć, kto to będzie. To tak jak, znowu podam przykład samochodowy, są takie samochody, gdzie jest napisane, że ktoś je składał ręcznie. Oczywiście to nie znaczy, że możesz pójść do dilera, jak się popsuje, i powiedzieć przyprowadźcie mi tam tego gościa, który składał silnik, niech on teraz weźmie za to odpowiedzialność. Natomiast w przypadku software house’a wbrew pozorom tak może być. No bo jeżeli bierzesz człowieka, który w ramach fizz build mówi ci coś, że coś jest do zrobienia i że to jest wykonalne, i nagle po jakimś czasie się okazuje, że jednak się pomylił, no to wiesz, kto się pomylił, nie? Możesz powiedzieć dostawcy to może następnym razem weźmy inną osobę, bo najwyraźniej ta osoba, no nie do końca była w stanie oszacować ryzyko.

Paweł: To jest ciekawe, co powiedziałeś, bo to oznaczałoby zniknięcie takiej ściany, gdzie de facto Twoja firma albo jakiś software house jest takim frontem dla klienta i z tyłu są programiści. Czasem jest taki model, nie?

Tomek: To jest to pozytywne zapożyczenie z body leasingu, że dostajesz zespół i masz jakieś blindy konkretnych osób, tak to się mówi chyba w tym obszarze outsourcingu. One co prawda są zanonimizowane, no bo wiadomo, na początku współpracy jest jakieś ryzyko, że ktoś ci kogoś podbierze. Natomiast pokazujesz to klientowi i klient mówi, o patrz, no robił taki projekt w takiej technologii, z takiego obszaru, no to na przykład do platformy telematycznej będzie on spoko, bo wcześniej robił taką platformę. I to jest coś, co zwiększa Twój komfort zarówno na poziomie takich bardzo zerojedynkowych rzeczy, które są w CV, typu lata doświadczenia, ukończona uczelnia, ilość pracodawców i tak dalej, i tak dalej, versus też nawet dokładne, pogłębione sprawdzenie, czy ta osoba w danej technologii pracuje odpowiednio długo. No bo sam pewnie pamiętasz takie sytuacje, że były takie memy, które mówią, że chciałbym dwóch programistów, którzy mają osiem lat doświadczenia w React Native, a React Native jest trzy lata na rynku. Wiesz o co chodzi? To jest nagminne w tej naszej branży i dlatego masz prawo żądać i masz prawo to sprawdzić. Co więcej, uważam, że tak samo dobrą praktyką z body leasingu jest jakiś tam interview z tym zespołem, taki pre-kick off, kiedy ten zespół jest budowany. Kiedy firma zewnętrzna ten zespół dostarcza, należy się upewnić, że ten zespół będzie i tutaj znowu do punktu pierwszego wrócę redundantny. Bo sporo małych firm ma bardzo dobrych specjalistów. Natomiast w przypadku wydarzenia się jakiejś nieprzewidzianej historii, nawet stricte, wiesz, takiej życiowej, nagle się okazuje, że Ty, będąc zlecającym, powierzyłeś to firmie, która miała, trzech programistów w danej technologii, po czym Ty wziąłeś dwóch, trzeci się w międzyczasie zwolnił, o czym nie wiesz, a jeden z tych dwóch na przykład zachorował albo stwierdził, że projekt mu się nie podoba, no bo czasami tak jest i nagle masz oczekiwania w stosunku do tych gości, żeby oni Ci tego człowieka następnego dnia dostawili, no bo projekt jest zdefiniowany, jest praca potrzebna do zrobienia, jest jakaś tam lista rzeczy, które ten programista ma zrobić, a ta firma tego nie ma. Więc też w ramach skanowania takiego dostawcy powinieneś sprawdzić, czy ta redundancja w tej technologii jest. Szczególnie w technologiach, które są takie, wiesz, modne, fajne, fancy, a wcale nie jest dużo tych programistów i jeszcze trochę czasu upłynie, zanim ich będzie odpowiednio dużo. A ostatnia rzecz to to o co zapytałeś, czyli nie samymi programistami software house stoi. Kluczowe jest posiadanie architektów przez software house, kluczowe jest posiadanie analityków. W naszym przypadku, tutaj Future Mind’owym, również decyzja o zainwestowaniu w budowę zespołu doradczego, który jest w stanie robić te rzeczy na bardzo pierwszej takiej fazie właśnie sprawdzania bardziej wymagań biznesowych i uzasadnienia biznesowego dla produktu. To nie jest rzecz, który musi być konieczny, ale to jest nasza przewaga konkurencyjna. Pewnie jest kilka firm przynajmniej, które taką drogę obrały, i bardzo się cieszę, że coraz więcej jest takich firm, mimo że to są firmy konkurencyjne, bo to jest coś, co, tak jak powiedziałem, pozwala wziąć współodpowiedzialność. I to, że te osoby po stronie software house’u rozumieją, po co ten produkt powstaje, co ma robić, jakie są de facto KPI sukcesu tego produktu, i to wiedzą na początku, i rozumieją, co to jest ten KPI, a nie, że budujemy jakąś aplikację, która ma być wylansowana, a my tak naprawdę nie wiemy, po co ją budujemy. Kiedyś miałem taką super fajną rekrutację, jeszcze jak się zajmowałem rekrutacją, dawno, dawno temu, jak przyszła jedna osoba z firmy, w której pracowała sześć lat, ja zadałem jej pytanie, co ona w tej firmie zrobiła, a ona powiedziała, że w życiu nie skończyła żadnego projektu, że robiła chyba na czterech i ja mówiłem, ale masz taką rzecz, wiesz, takie pytanie stricte rekruterskie, jak z książeczki, na zasadzie powiedz rzecz, z której jesteś najbardziej dumny, którą zrobiłeś w życiu. Osiem lat tam pracowałem czy sześć, ale w sumie to nie wiem, bo niczego nie skończyłem. A to mi zabierali projekty, a to mi go oddawali. Trochę odbiegam od tematu, ale jakby trochę na tym to polega, że musisz mieć osoby, które potrafią wziąć tą odpowiedzialność. Ty musisz być… jako wybierający software house musisz mieć pewność, że ta osoba po tej stronie, która jest zarówno w zespole projektowym, ale też w zespole zarządzającym software house’m, jest osobą, która będzie w sytuacji stresującej traktować Cię po partnersku. No bo to nie jest tylko tak, że ta zasada Dawid – Goliat, ona ma znaczenie, bo czasami jest tak, że duża firma też może mieć problem. Przecież w przypadku Covida mieliśmy kilka takich rozmów, gdzie musieliśmy się wykazać empatią, mimo to że obroty tych firm są, nie wiem, dziesięć tysięcy razy większe od naszych, a jednak oczekiwano od nas, że my w pewnych sytuacjach przyjmiemy pewne postawy, które prawdopodobnie w takich, no wiesz, w innych okolicznościach byłyby też, trudne dla nas do zaakceptowania biznesowo. No bo było to też ryzyko po naszej stronie. Myśmy nie wiedzieli, czy to się zmieni, czy się nie zmieni, czy to się poprawi, czy się nie poprawi.

Paweł: Tomek, to jeżeli ktoś z naszych słuchaczy chciałby się więcej dowiedzieć o Tobie, o Twojej firmie, to gdzie powinien szukać?

Tomek: Wiesz co, na pewno jest tak, że ja, bez względu na to jak duzi będziemy, zawsze jestem do dyspozycji, można do mnie napisać na LinkedIn’ie, można do mnie napisać na maila. Jeżeli nawet to będzie jakaś tam skrzynka firmowa, to jeżeli ten mail będzie do mnie adresowany, to natychmiast do mnie trafi. Bardzo wam polecam też mój zespół doradczy, który tworzy fajne treści. Często, powiem szczerze, na dużo większym poziomie dokładności niż nasza nawet dzisiejsza, fajna, ciekawa rozmowa. Także pogłębienie wiedzy na temat tego, jakie są wady, zalety albo w jaki sposób tworzyć briefy, czy w jaki sposób zapytać software house o współpracę, to na pewno jest rzecz, która się znajduje u nas na blogu futuremind.com. Oczywiście jakby każdy, kto do mnie się zgłosi, nawet po tym podcaście, i poprosi o to, żeby z nim porozmawiać, ma taką możliwość. Ja w ogóle lubię rozmawiać, lubię pomagać. Myślę, że to jest czwarty faktor, który warto jest z tym software house’em sprawdzić, czy ta osoba, z którą masz kontakt w procesie sprzedażowym, procesie ofertowym, jest osobą, która się przejmuje tym, co chcesz zbudować. Więc ja zapraszam do siebie, zapraszam też do moich współpracowników i jeżeli ktokolwiek coś potrzebuje, to jestem otwarty na rozmowę.

Paweł: Jeżeli rozmowa wam się podobała, to dajcie nam znać na naszym LinkedIn’ie Delloite, zapraszam też na naszego bloga „Zwinne organizacje”. Możemy porozmawiać o zwinności w waszych organizacjach, śmiało, również zachęcam do kontaktu. A to był Tomasz Woźniak z firmy Future Mind. Tomek, bardzo dziękuję za rozmowę.

Tomek: Również dziękuję i do usłyszenia.