Odcinek 6 | SDN od kuchni – Zaplanuj pracę programistów czyli projekty R&D oczyma Scrum Product Ownera – cz. 1

Kim jest Scrum Product Owner? Jaka jest jego rola w firmie? Zapraszamy na drugą część rozmowy z Michałem Mąkoszą, który opowie o tym, jak to jest być pomostem pomiędzy biznesem a techniką, jak udaje mu się przełożyć język techniki na biznesowy i na odwrót oraz czym jest zespół AnArch i co go przyciągnęło do EXATEL.

Technologia telekomunikacyjna zmienia się na naszych oczach. To, co kiedyś było marzeniem, dziś staje się rzeczywistością. Jak SDN, czyli Software-Defined Networking (sieć definiowana programowo), filozofia, która nabrała kształtu w okolicach 2010 roku, a dziś podbija świat technologii telekomunikacyjnych na całym świecie i tworząca nowy rynek, którego wartość w 2027 roku szacowana jest na aż 43 miliardy dolarów. W tym programie rozmawiam z osobami, które tworzą rozwiązania oparte na filozofii SDN: programistami, architektami, analitykami. Czyli praktykami, którzy o technologiach sieci programowalnych wiedzą po prostu najwięcej.

Serdecznie zapraszam na kolejny odcinek podcastu SDN bez tajemnic. Piotr Mierzwiński.

Piotr Mierzwiński: Dzisiaj naszym gościem jest Michał Mąkosza, Scrumowy Product Owner w projekcie SDN EXATEL. Cześć Michał!

Michał Mąkosza: Cześć!

Piotr: Chciałem się Ciebie zapytać o specyfikę twojej pracy. Kim jest w ogóle Scrumowy Product Owner? Jest to dosyć nietypowe stanowisko, a przynajmniej tak mi się wydaje.

Michał: Poniekąd tak. Może dla osób które na co dzień pracują w Scrumie, z jednej strony może się wydawać dziwne użycie słowa Scrum w nazwie stanowiska. Z drugiej strony upieram się, żeby to dodawać, bo dla większości osób Product Owner jest kimś troszkę innym niż Scrum przewiduje. Specyfika tej pracy polega na tym, że w Scrumie Product Owner jest mostem między biznesem a deweloperami. Specyfika jest więc taka, żeby mówić oboma językami naraz.

Piotr: Językami programistów i techników?

Michał: I biznesu.

Piotr: Jeszcze dodatkowo biznesu?

Michał: Tak, dokładnie. To jest to największe wyzwanie. Z jednej strony Product Owner musi rozumieć wartość biznesową. Po co coś jest robione i tak dalej, gdzie w tym leżą pieniądze, jaki jest plan i wykonanie tego planu. Z drugiej strony, według mnie w fundamencie Scruma leży to, że ten Product Owner jest blisko zespołu deweloperskiego. Blisko osób, które znają się na technice, na technologii która tam jest i programowaniu. Scrum stara się rozwijać poza IT, poza programowanie. Obecnie w Corze jest najbardziej popularny właśnie przy programowaniu. Więc z drugiej strony mamy ten język programistów.

Piotr: Zanim przejdziemy do opowieści o tym jak w ogóle Scrum wygląda przy tworzeniu produktu SDN, to wspomniałeś o takiej jednej rzeczy… Tłumaczysz język biznesowy, język techniczny – telekomunikacyjny. Wiadomo, że technologia Software-Defined Networking ma przede wszystkim swój odpowiednik w świecie telekomunikacyjnym na język programistów. Jak Ci się to udaje, skoro są dwa różne światy? Z drugiej strony wiem, że jesteś jednak taką osobą, która ma trochę doświadczenia i w jednym i w drugim miejscu, prawda?

Michał: Tak, zgadza się. Specyfika historii mojego zatrudnienia jest taka, że pochodzę ze świata telekomunikacji. To studiowałem i nawet może jeszcze coś pamiętam ze studiów. Przez pierwszą połowę mojej kariery pracowałem w firmie telekomunikacyjnej, a potem przeniosłem się bardziej w obszary IT, programowania, analizy, analityki systemowej. Przychodząc do EXATEL, zafascynowało mnie to, że firma telekomunikacyjna zbudowała taki wewnętrzny software house. Swoją drogą poniekąd startup, ale bardzo nowoczesną wewnętrznie jednostkę. I to mi bardzo odpowiadało, ponieważ łączyło te dwa światy, które gdzieś tam mam w swojej historii zatrudniania.

Piotr: Jesteś osobą, która z jednej strony tworzyła te technologie telekomunikacyjne, światłowody, szafy i wszystkie rzeczy związane z takim ekosystemem urządzeń i rozwiązań technologicznych. Z drugiej strony, zajmujesz się tą analizą biznesową, rozwojem potrzeb i na samym końcu skończyłeś na Software-Defined Networkingu, przy SDN. Jak tak naprawdę udało Ci się połączyć te trzy rzeczy i czy ta różnorodność doświadczenia, znajduje tak naprawdę swoje odzwierciedlenie w tym, w jaki sposób tworzysz technologię SDN?

Michał: Uczestniczę w tym procesie. Nie mogę sobie przypisać tego, że tworzę to tymi rękoma. Niestety. Zajmuję się rozmawianiem. W tym się specjalizuję – w tłumaczeniu z jednej strony na drugą jak do tego podejść. Filozofia SDN zakłada łączenie tych dwóch światów – telekomunikacji (tego, co od dawna jest już opanowane) i IT (programowania Software-Defined Networking). To są dwa światy, które są poniekąd pokrewne, ale tak naprawdę nie przenikały się aż tak bardzo dotychczas. Dopiero teraz zaczynają się przenikać. To, że EXATEL zdecydował się na coś takiego i to, że filozofia Software-Defined Networking zakłada właśnie łączenie tych dwóch światów i połączeniu tego, że w swojej historii miałem właśnie wgląd do obu tych światów, spowodowało u mnie ogromne zainteresowanie tym tematem, firmą i projektem.

Piotr: Mamy 2022 rok. SDN jest już jakiś czas tworzony w EXATEL. Jak to się przekłada na praktykę?

Michał: To temat rzeka o którym mógłbym opowiadać godzinami, więc zatrzymaj mnie jeśli bym za bardzo odpłynął.

Piotr: Właśnie dlatego jesteś dzisiaj naszym gościem.

Michał: To może zacznę od tego, że pracujemy w tym projekcie w Scrumie. Niewielkie zaskoczenie, skoro jestem Scrum Product Ownerem. Programiści pracują w dwutygodniowych Sprintach w których na początku jest planowanie i ustalanie co jest do zrobienia. Na koniec jest Sprint Review – pokazanie co zrobili. Tutaj staram się trzymać bardzo zasad scrumowych, czyli nie wchodzić tam z butami, micromanagement, ani nic takiego. Równocześnie staram się trzymać biznes jak najdalej od programistów. To jest ta piękna rzecz w Scrumie.

Michał: Na pewno ta część jest ważnym elementem mojej pracy, dlatego od tego może zaczynam. Czyli z jednej strony ten most pomiędzy dwoma światami, a z drugiej strony pilnowanie aby te światy się ze sobą nie gryzły, bo tak to zwykle bywało. Biznes chce wszystko „na wczoraj”, a deweloperzy chcieliby mieć jak najwięcej czasu na spokojne dopieszczenie kodu itd. Ale wracając do tego co było tutaj dla mnie ciekawym wyzwaniem na początku, to właśnie połączyć tutaj te światy. Projekt jest z kategorii Research and Development (badania i rozwój). To nie jest tak, że był już gotowy szablon, tylko trzeba zaimplementować, wpisać i pozamiatane. Tutaj jednak trzeba było dużo wcześniej rozpoznać. Biznes lubi mieć plan i wiedzieć dokładnie co się wydarzy w przyszłości. Biznes nie cierpi niewiadomych. W badaniach i rozwoju (R&D) mamy z miejsca dokładnie coś odwrotnego. My nie wiemy co będzie jutro, bo badania które dzisiaj przeprowadzamy, być może zmienią zupełnie kierunek. Powstał więc proces, który łączy nam te wszystkie kierunki. To było moje pierwsze wyzwanie – stworzyć taki proces, w którym wszyscy jesteśmy w stanie rozumieć. I działa to efektywnie. Mamy ten proces zapisany i funkcjonuje. Polega on na tym, że dla developerów jest Scrum. Oni mają na początku planowanie. To co mają na wejściu tego planowania, to są elementy. Pracujemy z bardzo popularnym narzędziem, Jirą, w której mamy artefakty jirowe i tam są też user stories. Dostają te stories na wejściu i w którymś momencie muszą sobie segmentować je na poszczególne taski. Umawiamy się więc, że coś jest w Sprincie do zrobienia i na koniec pokazują co udało się zrobić. Jest inkrement wartości biznesowej. Muszę tu od razu postawić gwiazdkę. W tym projekcie jest naprawdę masę rzeczy do zrobienia. Masę już zrobiliśmy, ale ambicje i apetyt mamy na wiele więcej. Więc te inkrementy, które się pojawiają, nie są dla końcowego użytkownika biznesowego tak duże. To następna warstwa trudności do tłumaczenia między tym co dzieje się tu i teraz, a tym co biznes chciałby widzieć. Używając słowa biznes, używam go jako bardzo szerokiego pojęcia. Mamy więc user stories, które są na wejściu. Te stories są produkowane przez funkcjonujący u nas zespół AnArch.

Piotr: Zespół AnArch? Anarchiści?

Michał: Jest to nazwa własna, którą stosujemy. Wywodzi się ona z konkretnej funkcji: An+Arch = analitycy i architekci. Analogia do anarchii i chaosu jest o tyle adekwatna, że to ich rolą jest opanowanie tego chaosu, który jest na wejściu i przekucie go w bardziej usystematyzowane „co jest do zrobienia”, żeby programista nie musiał teraz siadać i się doktoryzować z telekomunikacji. Bo często jednak ktoś, kto zajmuje się programowaniem, jest ekspertem w programowaniu, a niekoniecznie w telekomunikacji, protokołach i tym podobnych. Wygodniej i efektywniej jest jak programista na wejściu ma jakiś bardziej strawny materiał.

Piotr: Jak wygląda taki proces? Dostajemy jakieś wymogi biznesowe? Biznes przychodzi i mówi ,,chciałbym żeby była jakaś funkcja, która robi daną rzecz, np. kontroluje, sprawdza, weryfikuje, rozdziela transfer czy cokolwiek innego”? Jak to wygląda w praktyce? Taka informacja trafia do zespołu AnArch i jak oni próbują to zdekompilować, rozłożyć na takie części i jednocześnie wytłumaczyć to dla osób, które tak naprawę nie za bardzo rozumieją w jaki sposób to działa na tak wysokim poziomie, bo oni tak naprawdę tworzą poszczególne funkcjonalności, poszczególne elementy.

Michał: Postaram się namalować ten obrazek w miarę szczegółowo, ale to trzeba nawet pójść o krok dalej. Na początku jest idea: zrealizujmy jakąś funkcjonalność typu transmisja Elan (chcemy taka usługę świadczyć na naszych rozwiązaniach). Żeby deweloper usiadł i napisał pierwszą linijkę kodu, to trzeba naprawdę dużo poświęcić czasu i rozważań. Najpierw segmentujemy to na duże elementy – tutaj od razu zrobię zrzutowanie na język od strony deweloperskiej – na epiki . Mamy epiki, czyli worki poszczególnych stories w Jira i każde story dzieli się potem na taski. I dokładnie to robimy – najpierw idee zamieniamy na epiki, malujemy sobie wstępnie co w danym epiku jest do zrobienia i jaki jest tego zakres. To robią architekci. Potem jest faza analityczna. Analitycy zapisują do tego story. Potem trafia to do deweloperów, którzy we współpracy z AnArchem (analitykami i architektami), muszą zrozumieć dostarczony materiał i podzielić na poszczególne zadania, które mają do zrobienia. I te zadania oczywiście trafiają na Sprint.

Piotr: Brzmi to trochę jak taka szorstka przyjaźń. Przychodzi ktoś, próbuje powiedzieć ile jest rzeczy do zrobienia (jeszcze często rzeczy, które nie zawsze są zrozumiałe) i ktoś na samym końcu będzie rozliczany z tego, żeby to napisać. To naprawdę brzmi jak niezłe wyzwanie!

Michał: Wyzwanie bez dwóch zdań. Czy szorstka przyjaźń? Szorstkości bym tam nie dodawał. Mimo wszystko mamy u nas plus tego, że pracujemy w taki, a nie inny sposób i że w takim specyficznym projekcie jesteśmy, że nasz zespół AnArch, ci którzy zlecają co jest do zrobienia, są tak naprawdę bardzo blisko zespołu wytwórczego. To nie miałoby szans funkcjonować, jeśli byłby to tylko styk: „tutaj macie materiały, przeczytajcie sobie, a potem ja to od was odbiorę”. Takie rzeczy oczywiście się na świecie zdarzają, ale u nas na szczęście tak to nie funkcjonuje. To co muszą w zespole AnArch zrozumieć, tam jest o wiele więcej technicznej części, więc automatycznie jest im łatwiej rozmawiać z ludźmi, którzy też mają zacięcie techniczne po stronie programistów. Ale masz racje, trochę to tak funkcjonuje, że jak jest na początku osoba, analityk, który ma przygotować te story, potem odbiera to od deweloperów. Chociaż ten odbiór nie jest na takiej zasadzie, że ja wam podpisuję i teraz możecie wystawić fakturę. Wszyscy pracujemy wewnątrz jako pracownicy firmy. To raczej popatrzenie na efekt końcowy i stwierdzenie: „dobra, to nam funkcjonuje tak jak sobie wyobrażaliśmy” lub „nie, trzeba coś jeszcze zrobić”. Od strony tego co się dzieje w sprintach tak to dokładnie wygląda. Na wejściu jest to, co zespół AnArch przygotował, segmentował pomysł na epiki, epiki na story, wyjaśnione zostało programistom i oni podzielili to sobie na taski. Wytwarzają taski w Sprincie i na koniec pokazują całe story: „Zrobiliśmy. Podoba się wam?” Następuje rozmowa i albo tak albo nie. Jeśli nie, to co trzeba zmienić i klasycznie w Scrumie, nowe zadania są po prostu od tego. I tak to się kręci od tej strony.

Piotr: Cały ten proces wygląda na bardzo ułożony, książkowy. Ale mnie interesuje tak naprawdę twoja rola jako Product Ownera. Jako osoby, która jest gdzieś pomiędzy tym tłumaczeniem, a realizacją i jest jeszcze naciskana przez biznes. Nie powiedziałbym, że jest to kształtowanie produktu, ale wymyślanie pewnych rzeczy na nowo. Ktoś do ciebie przychodzi i mówi „ja chcę mieć jakąś funkcjonalność” i musisz ją tak naprawdę przełożyć na język SDN. Czy ty to robisz w zespole? Jak to w ogóle wygląda z punktu widzenia codziennej pracy? Drugie pytanie, które od razu mi się z tym wiąże, to jak w ogóle wygląda taka codzienna praca Scrumowego Product Ownera? Czym na co dzień w ogóle się zajmujesz? Sprinty są raz na jakiś czas, rozliczanie też, a wiadomo, że nie żyjemy od Sprintu do Sprintu.

Michał: Postaram się odpowiedzieć na oba pytania, ale użyłeś takiego określenia jak książkowy proces. Ten proces jest szyty pod nasze zapotrzebowanie. Z resztą jeszcze nigdzie nie trafiłem na implementację Scruma 1:1. Zawsze jest to lokalna implementacja. Jest to bardzo ważna rzecz, którą na każdym kroku powtarzam i możliwe, że zespół ma już trochę tego dosyć. Proces który stworzyliśmy i zasady na których funkcjonujemy, mają być szkieletem na którym budujemy nasze codzienne przyzwyczajenia, codzienne działanie, to co nam wchodzi w krew. To ma być szkielet, a nie ograniczający nas pancerz, że tylko odtąd-dotąd mamy działać. To ma być pewne usystematyzowanie, żebyśmy wszyscy wiedzieli mniej więcej o co chodzi i kto co robi. Jest to ważne. Proces o którym opowiadam, to nie litera prawa, że musi to być dokładnie tak zrobione, ale coś, co pozwala nam to usystematyzować. Teraz odpowiem na twoje dwa pytania. Może zacznę od tej drugiej części jeżeli bym mógł?

Piotr: Oczywiście.

Michał: Codzienna praca wygląda w ten sposób, że rano robię sobie kawę. To bardzo ważny  punkt dnia.

Piotr: Od czegoś trzeba zacząć.

Michał: Dokładnie. Oprócz tego siadam do naszego planu holistycznego. Jest to w dużym skrócie nasz plan, na którym z jednej strony patrząc na niego widzę to, co dzieje się od strony deweloperów, to co oni widzą – obecny sprint, zadania które składają się na epiki. Ale z drugiej strony ten sam plan jak na niego popatrzę, to informacja z punktu widzenia biznesu – kiedy będą mieli konkretne funkcjonalności. Od tej strony patrząc, ten plan wygląda już jak roadmapa. Czyli jesteśmy na dobrej ścieżce do tego co zakładaliśmy, a co poobiecywałem naszym mocowładnym – kiedy będą mogli czerpać korzyści z tego co tutaj robimy. Przez cały czas trzeba to aktualizować. To z czego osobiście jestem dumny, to że plan holistyczny jest taką samonakręcającą się maszyną. Czyli jeżeli z jednej strony jest input od strony deweloperów, że coś się przedłużyło w pojedynczych zadaniach (w story, w epiku), to od razu robi mi przełożenie na roadmapę. Jeżeli oczywiście to tak jednoznacznie się przekłada. A z drugiej strony (od strony biznesu) jak jest jakieś nowe zapotrzebowanie lub wymagania, czy to czasowe czy funkcjonalne, to od razu wiem jak to mi się przekłada na te zadania, albo wiem, które nowe zadanie trzeba teraz wytworzyć. Wracając więc do tego co codziennie robię. Patrząc na ten holistyczny plan, jak idzie ten sprint, wiem jak się to ma jedno do drugiego. Zapalają mi się na czerwono lampki, jeśli coś zaczyna gdzieś wybuchać. Jeśli później jest okazja do tego i w spotkaniach zrobi mi się luka, bardzo chętnie idę na nasze daily scrumowe zespołu, gdzie bardzo sobie biorę do serca to, co Scrum mówi, a czego zostałem nauczony na samym początku i z czym Scrumowy Produckt Owner ma zwykle problem – siedzieć cicho. Nie próbować mówić, że „będzie lepiej jak to zrobicie”. Daily jest dla zespołu. Tego też potrzebuję do tego, żeby wiedzieć co się dzieje i realizować to, co postrzegam jako główne moje zadanie od strony zespołu: na bieżąco móc oddzielać odpowiedzi i dostarczać to co zespół potrzebuje. Dalszy punkt dnia to są różne spotkania. Najczęściej są to spotkania „jeden na jeden” w różnych tematach, ale to się sprowadza do tego, że cały czas staram się monitorować to co się dzieje i jak to się przekłada na plan. I w drugą stronę: jak nowe wymagania przekładają się na to, co zespoły muszą zrobić. Oczywiście mógłbym tutaj poopowiadać o tym pozostałych scrumowych artefaktach – o review i retro. Uczestniczę w tych wszystkich elementach. Na co dzień natomiast pracuję właśnie z tym z planem holistycznym i z backlogiem, żeby to się wszystko spinało. Dużą część czasu poświęcam jednak na ten plan, mechanizm, proces o którym opowiadałem teraz. Trawienie tego, co jest na wejściu i co przychodzi od biznesu. Nie wiem czy zauważyłeś jak gładkie przejście do tej części biznesowej tutaj robię.

Piotr: Perfekcyjne, rzekłbym.

Michał: To jest duża część mojego czasu. Jednak biznes przez cały czas ma oczekiwania i chciałby mieć wszystko jak najszybciej. Moją rolą jest reagować. Zmieniają się nam okoliczności, szczególnie w R&D.  Okazuje się, że ten nasz research i badania wykazują, że tą ścieżką którą dotąd szliśmy, coś nie działa. W tym momencie trzeba wyciągnąć spod stołu plan B, C, D. Nie da się zrealizować czegoś takiego idąc jednym planem. Trzeba uruchomić plan alternatywny, czyli z powrotem pójść do biznesu i powiedzieć: „teraz nasz plan wygląda w ten sposób”. Takie są okoliczności, takie zapotrzebowanie pieniężne na zasoby, na ludzi. Różnie bywa. Z biznesem w ten sposób współpracuję, że staram się jak najszybciej informować ich o zmianach i w drugą stronę – zrozumieć jakie jest obecne zapotrzebowanie. A to jest to, o czym mówiłem na samym początku. Gdzie leżą pieniądze i co trzeba by zrealizować jak najszybciej, żeby z tego korzystać.

Piotr: Powiedziałeś bardzo dużo o takiej codziennej pracy, o planowaniu, o pewnym procesie, który realizujesz każdego dnia. Pracujesz w firmie telekomunikacyjnej. W firmie, w której proces badawczo-rozwojowy nie stanowi core biznesu. Jest bardzo ważnym elementem, ale nie najistotniejszym elementem działania całej organizacji. Jak ma się więc planowanie versus rzeczywistość? Bo projekty w których bierzesz udział, projekty SDN, to projekty które trwają często po 36 miesięcy lub dłużej. Patrzę z perspektywy takiego długoterminowego planowania, nawet jeśli weźmiemy go z życia. Najłatwiej planuje się to co jest jutro. To co jest za tydzień jest problematyczne, a co za miesiąc, to już pisane palcem po wodzie. Planowanie na 36 miesięcy jest wyzwaniem. Jak wygląda tak naprawdę planowanie kontra rzeczywistość?

Michał: Masz rację, że w tym co robimy, w tym naszym wewnętrznym software housie R&D, jesteśmy trochę oderwani od reszty organizacji. Nie podłączamy się jednak na co dzień do usług, nie kładziemy nowych kabli światłowodowych, ani nic takiego. Nie rozmawiamy z tym klientem zewnętrznym. Użyłeś takiego określenia, ale z mojej perspektywy, to jest to kluczowe dla organizacji, tylko organizacja jeszcze tego nie wie, jeszcze tego nie czuje. To, co teraz tworzymy, będzie za dwa lata naprawdę czymś fundamentalnym dla EXATEL. Ale żeby tutaj nie popaść w samozachwyt nad projektem w którym uczestniczę…

Piotr: Który prowadzisz…

Michał: Tak, od strony scrumowej prowadzę. Nie mogę sobie przypisać całości zaszczytów w tym względzie. Żeby nie wchodzić w tę część, postaram się odpowiedzieć na to pytanie jak się ma planowanie do rzeczywistości. Zawsze, ale to zawsze plany są piękne i nie sprawdzają się w obliczu wroga.

Piotr: Niektórzy mówią, że plany są po to żeby je zmieniać.

Michał: Tak, to też jest bardzo ciekawe i coś w tym jest. Plany zawsze, ale to zawsze muszą podlegać rewizji, w momencie kiedy je realizujemy, bo jakoś uparcie przyszłość nie chce się zachowywać tak jak sobie wyobrażamy, że się zachowa. A w R&D trzeba to pomnożyć razy sto. Tak jak mówiłem wcześniej, bardzo często trzeba się zastopować na obranej ścieżce. Jakkolwiek jest to bolesne, trzeba podjąć decyzję, że idziemy inną ścieżką. W paru miejscach starałem się wpleść elementy, które budują tę możliwość. Proces o którym wspomniałem, że mamy segmentowanie. Analogicznie jak mówiłem, że mamy ten proces i jako szkielet na którym nadbudowujemy nasze praktyki. Analogicznie jest tak tutaj. To też jest szkielet, który umożliwia mi reagowanie na to, co się dzieje. To, że w Jirze mamy transpozycję pomysłu na coraz mniejsze elementy, aż do tego co trzeba zrealizować. Jeżeli pojawia się jakaś zmiana w zespole, coś trwa dłużej, trzeba dołożyć nowe zadania, to automatycznie te zadania trafiają mi do epiku. Epik mam zaplanowany na ileś Sprintów. Wydłuża mi to ten epik, w związku z tym widzę jak mi to kaskaduje aż do roadmapy. Jestem w stanie na to zareagować. Naruszyliśmy deadline który był dla mnie nienaruszalny? To wracamy w drugą stronę. Co z tego epiku wyciąć? Co jest absolutnie niezbędne? Może trzeba pójść do biznesu i o tym porozmawiać? A może z deweloperami zapytać jak możemy to zrealizować inaczej, żeby jednak tego deadline’u nie naruszyć. To jest bardzo płynne i proces o którym wspomniałem nie ogranicza mnie w tym co się tu dzieje, ale jest bardzo dużym ułatwieniem.

Piotr: Jest jedno pytanie, które zadaje wszystkim moim gościom którzy zajmują  się projektami badawczo-rozwojowymi, którzy pracują z ludźmi, z programami, z biznesem, z architekturą, Scrumem, z technologiami, z filozofią. Zwał jak zwał. To pytanie kieruje też do ciebie, ze względu na to, że oprócz tego ze jesteś Scrumowym Product Ownerem, to też zarządzasz gdzieś pewną częścią zespołu. Myślę właśnie o tym zespole, o którym rozmawialiśmy wcześniej – AnArch. Jest to dosyć specyficzny zespół. Łączy pewną wiedzę telekomunikacyjną z tym w jaki sposób wytłumaczyć to programiście, który tak naprawdę mówi całkowicie innym językiem. Jakiego rodzaju osobowość sprawdzi się najlepiej w tym miejscu? Jest to dość specyficzna rola, żeby połączyć te dwa, troszkę inne światy – ten stricte komunikacyjny, ze światem kreacji w postaci programistów.

Michał: Pewnie mógłbym troszkę bronić tej tezy, że to nie są aż tak dalekie światy, ale postaram się skoncentrować bardziej na tym co mówiłeś. Ciężko mi tak jednoznacznie zdefiniować. To co na pewno powoduje, że mi się dobrze współpracuje z ludźmi których mam w zespole, to ich otwartość na wyzwania i chęć zaciekawienia tematem. Temat z mojej perspektywy jest bardzo ciekawy. Telekomunikacyjnie jest to przyszłość, jednak raczej z kategorii tych rzeczy, które wchodzą, niż czegoś co jest już opanowane. Taka osoba musi więc lubić się uczyć. Musi lubić rozpoznawać tematy, rozkładać je na czynniki pierwsze, wgryzać się w to. Jednocześnie nie robiąc tego sztuka dla sztuki, musi umieć też to przedstawić w sposób techniczny. Czyli umysł ścisły. Mamy pewne szablony do tego, do czego wbijamy tę wiedzę. Zespół AnArch to robi, a po tym jak zrozumie – zapisuje. Te szablony są po to aby nam ułatwić pracę, a nie nas ograniczać. To są takie dwa najważniejsze aspekty, które bym powiedział, że u osób w zespole AnArch są najważniejsze. Ciekawość świata i umysł techniczny.

Piotr: Przed rozmową wspomniałeś mi o samodzielność. Twoje podejście do realizacji tych projektów nie jest takie zero-jedynkowe. Kierownik-zespół wytwórczy. Działa to trochę na innej zasadzie: wszyscy ciągniemy ten projekt i każdy jest za niego tak samo odpowiedzialny. Prawda?

Michał: Masz rację, jak najbardziej. Przepraszam, że o tym nie wspomniałem, ale jest to dla mnie rzecz tak naturalna, na której pracuję na co dzień, że aż mi to umknęło, choć przez chwilę świtało żeby o tym wspomnieć. Jak wspomniałeś zarządzam zespołem AnArch. Ja zarządzam harmonogramem/planem. Ludzi u nas adaptujemy bardzo szybko. Podejście Scrumowe, Agilowe, to nie jest tak że zarządzamy ludźmi. Każdy powinien wiedzieć co chce teraz robić, a my dostarczamy do tego narzędzia. I tak samo jest w zespole AnArch. To nie jest tak, że ja dyktuję. Rozmawiamy o tym co warto zrobić dla projektu. Czyli tak jak wspomniałem, osoby ciekawią się, są nakręcane takimi tematami. O wiele łatwiej jest rozmawiać jak ktoś nakręca się tematem i przychodzi z pomysłem „to teraz ja się zajmę tym”. Ja do tego dodaję wartość biznesową, to co jestem w stanie zrozumieć i na koniec staram się pomóc to wyważyć, aby zdecydować „tak, idziemy w tę stronę, to jest fajny pomysł, tym się teraz zajmij”. Natomiast nie jest to takie czyste, starodawne zarządzanie: „jako kierownik zlecam”. Masz rację, to jest bardzo ważny aspekt. Ciężko jest u nas osobom, które oczekują że będą miały powiedziane: „kopiesz odtąd do dwunastej”. Te osoby musi kręcić osiągnięcie pewnego celu. O tym możemy rozmawiać, ale musi ta osoba mieć jednak mieć chęć do decydowania samemu o sobie, o tym co robi, żeby osiągnąć ten cel.

Piotr: Super. Myślę, że mamy jeszcze trochę tematów do przedyskutowania ale czas nam się już też kończy. Michał – bardzo ci dziękuję za dzisiejszą rozmowę i za przedstawienie nam tego jak wygląda świat oczami Scrumowego Product Ownera przy projektach badawczo-rozwojowych. Mam nadzieję, że jeszcze będziemy mieli okazję porozmawiać, bo jest jeszcze kilka tematów, które chciałbym z tobą poruszyć. Na dzisiaj bardzo ci dziękuję za twój poświęcony czas. Naszym gościem był Michał Mąkosza, Scrumowy Product Owner w projekcie SDN EXATEL. Dziękuję ci Michał.

Michał: Dziękuję.

Michał Mąkosza, EXATEL
Michał Mąkosza
Z-ca Dyrektora Departamentu Rozwiązań R&D, EXATEL
Piotr Mierzwiński
EXATEL