Technologia telekomunikacyjna zmienia się na naszych oczach. To co kiedyś było marzeniem, dziś staje się rzeczywistością. SDN (Software-Defined Networking), czyli sieć definiowana programowo, to Święty Graal telekomunikacji XXI wieku. Filozofia SDN nabrała kształtu w okolicach 2010 roku, a dziś podbija świat technologii telekomunikacyjnych na całym świecie i tworzy nowy rynek, którego wartość w 2027 roku szacowana jest na aż 43 miliardy dolarów. W praktyce SDN oznacza telekomunikacyjną rewolucję. Dzięki filozofii SDN, firmy takie jak EXATEL, które samodzielnie piszą oprogramowane i tworzą własne technologie, mogę kreować elastyczne rozwiązania na najwyższym światowym poziomie. 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. Sylwia Buźniak, HR Biznes Partner EXATEL.

Sylwia: Dzień dobry. Moim i Państwa gościem dzisiaj jest Michał Mąkosza, Scrum Product Owner w zespole rozwoju Software-Defined Networking. Cześć Michał!

Michał: Cześć!

Sylwia: Fajnie, że zgodziłeś się porozmawiać. Chciałabym dzisiaj kontynuować z tobą rozmowę z poprzedniego podcastu, ale tym razem zejść na większy poziom szczegółowości i poznać twoją pracę od kuchni. Nie skupiać się tylko na teorii, ale porozmawiać o tym jak wygląda twoja rola w praktyce.

Michał: Dzięki za zaproszenie. Poprzednio dobrze się bawiłem, więc chętnie też tutaj przyjechałem. Jest to dla mnie ciekawe doświadczenie. Chętnie opowiem. Mam nawet przygotowany kawałek materiału, co to w praktyce znaczy.

Sylwia: Co znaczy rola Scrum Product Ownera?

Michał: Scrum Product Owner – dla przypomnienia – to jest ten most między deweloperami a biznesem. Czyli z jednej strony muszę wiedzieć co jest wartością biznesową i co firma chce żebyśmy zrealizowali. Jestem wtedy przed resztą organizacji głosem zespołu wytwórczego. Z drugiej strony, dla zespołu wytwórczego mam być głosem organizacji i przekazywać to i z oboma stronami rozmawiać w taki sposób, żeby mnie rozumiały. Co jest specyficzne, bo język jest jednak inny w biznesie i inny u deweloperów.

Sylwia: Dokładnie tak. Jesteś takim łącznikiem między biznesem a techniką, mówiąc wprost. Czyli przekładasz język biznesowy na taki, który będzie zrozumiały dla deweloperów. Powiedz w takim razie jak to wygląda od góry, tak strategicznie. Jak wyglądają ustalenia na poziomie biznesu, które potem musisz konwertować i tłumaczyć na język zespołu wytwórczego?

Michał: W poprzednim podcaście opowiadałem jak to bardziej jest od strony rozmowy z deweloperami. Teraz jak będę mówił, to będę się starał mówić o tym, jak ta współpraca wygląda od strony biznesu. Skąd się biorą innymi słowy materiały, które potem przedstawiam deweloperom. I jak się zastanawiałem nad tym o czym opowiedzieć, pojawił mi się taki pomysł, by powiedzieć o portalu operatora. To jest jeden z komponentów naszego ekosystemu SDN-owego i dotarliśmy z nim dosyć daleko. Mam taką pewną historię, która według mnie dosyć ładnie pokazuje projekt od momentu pomysłu, do momentu realizacji. Skąd się w szczególności bierze ta wola biznesowa, żeby to robić. Może tę opowieść zacznę od takiej małej dygresji.

Sylwia: Bardzo proszę.

Michał: Jak przyszedłem do EXATEL, to pierwszym bardzo pozytywnym zaskoczeniem było to, że EXATEL zdecydował się na stworzenie takiego wewnętrznego software house’u. Bardzo fajny ruch. Bardzo mi się to spodobało.

Sylwia: Mi również, dlatego tu jestem.

Michał: Natomiast oprócz tego miałam doświadczenie jako Scrum Product Owner, więc automatycznie z tyłu głowy miałem, że będzie to wyglądało tak samo – tu Scrum, tam Scrum. Drugim zaskoczeniem, bardziej ambiwalentnym, było coś, do czego musiałem się przystosować. To było to, że projekt wytworzenia całego ekosystemu, urządzenia, systemu operacyjnego, kontrolera i portalu operatora SDN-go – o którym zaraz będę więcej mówił – to jednak inna skala czasowa niż ta, do której byłem przyzwyczajony. Miałam akurat doświadczenie przy tworzeniu aplikacji na Androida i iOS i tam Scrum rotował naprawdę bardzo szybko. Co każde dwa tygodnie dostarczaliśmy jakiś inkrement, który dla biznesu był zrozumiały i widoczny. Tutaj dla mnie tym pierwszym szokiem – to co musiałam się dostosować i jak współpracować z biznesem i deweloperami – było to, że skala czasowa jest totalnie inna. To troszeczkę tak jak budujesz model samochodu. W dwa tygodnie i możesz zbudować cały model samochodu i go pokazać: „świetnie, tylko chcemy żeby teraz ten samochód był zielony, a nie czerwony”. Więc w następne dwa tygodnie przemalowujesz. Tutaj raczej budujemy cały samochód, taki 1:1. W dwa tygodnie zbudujemy jedną klamkę, pokażemy ją biznesowi, a biznes mówi: „świetnie, chcę zobaczyć całość zanim cokolwiek będę oceniać”. Więc to był taki pierwszy szok – skala czasowa. Ta historia zaczyna się w 2020 roku. Projekt był już dosyć zaawansowany i mam tu na myśli cały ekosystem, ale na poziomie research. Tak jak wspominałem – robimy tutaj Research and Development. Patrząc tak całościowo, strategicznie, z punktu widzenia Scrum Product Ownera, to byliśmy raczej na tym etapie, że szukaliśmy jak coś zrobić, niż faktycznie to robiliśmy. Mieliśmy więc zaawansowane prace w różnych komponentach, w różnym stopniu. Doszedłem do wniosku, że to już jest ten moment, że musimy to sproduktyzować. Nawet jeżeli to nie będzie produkt w znaczeniu komercyjnym i nie wystawimy go na półkę żeby sprzedawać poza firmą, ale żeby to był jakiś działający konkret, a nie jakiś PoC, który w jakimś laboratorium sobie podziała, żeby udowodnić koncepcje. Ma być to coś konkretnego, już działającego. Udało nam się wtedy wykoncypować tzw. MVP-0. W dewelopmencie scrumowym to MVP-0 mówi o skali iluś sprintów, tak tutaj mówiliśmy, że MVP-0 nam zajmie rok z leciutkim hakiem. Żeby to zrobić musieliśmy się też do tego przygotować. Przygotować materiały wstępne, zanalizować, przeprowadzić rozmowy z resztą organizacji, więc pojawiło nam się okienko czasowe u deweloperów. Kiedy powiedzieliśmy „uwaga, teraz będziemy iść w MVP-0”, to nie było to „już, teraz, starujcie!”, tylko „musimy jeszcze coś dla was przygotować, więc macie chwilę czasu”. Pojawiła się taka opcja: to może tę chwilę czasu poświęcimy na taki komponent, który dotychczas mieliśmy w bliżej nieokreślonej przyszłości, który w tym MVP-0 byłby już bardzo przydatny, nie absolutnie niezbędny, ale bardzo przydatny. I to był właśnie portal operatora.

Sylwia: Jak rozumieć portal operatora? Co to miało być i komu służyć?

Michał: Tworzymy nasze urządzenie i cały ekosystem urządzeń telekomunikacyjnych w filozofii SDN czyli pod software’owym kontrolą kontrolera. Budujemy to na ONOS-ie, ale stwierdziliśmy że chcemy żeby operator sieci miał od strony GUI interface graficzny jeden dla całej sieci SDN-owej. Ten interface graficzny, to właśnie portal operatora. Czyli można by powiedzieć, że w tym naszym Stacku, najniżej tam jest oczywiście jakiś krzem zamknięty w urządzeniu, urządzenie ma swój firmware, nad firmwarem jest system operacyjny tego urządzenia (to zamyka urządzenie), ale nad tym systemem operacyjnym jest centralny kontroler SDN-u (na centralnym serwerze) i po drodze do użytkownika (człowieka, który operuje tą siecią), jest właśnie jeszcze ten portal operatora.

Sylwia: Czyli to jeszcze nie jest poziom użytkownika, tylko pomiędzy, tak?

Michał: To jest najbliżej użytkownika. Użytkownik używa portalu operatora.

Sylwia: I co w nim widzi?

Michał: Po pierwsze widzi w nim sieć. Po drugie może sczytywać parametry co się dzieje na sieci i co się dzieje na urządzeniach. Może tam zakładać usługi i oczywiście sprawdzać jakie są parametry tych usług. Musi także robić tak przyziemne rzeczy, jak móc się zalogować, sprawdzić log operacji wcześniejszych od strony tego co tam klika, czy założyć konta dla innych użytkowników.

Sylwia: Brzmi super. Wspomniałeś, że był to najmniejszy moduł, który mogliście sobie wydewelopować, ponieważ pojawił się slot w cyklu życia produktu i akurat zespół wytwórczy miał moce przerobowe. Ile czasu to trwało? Na jaki czas było to rozłożone? Jak dużo tasków było rozpisanych?

Michał: To jest właśnie to, co chce przedstawić – jak wygląda praca na tym komponencie, który niekoniecznie jest najmniejszy. Natomiast o co mi chodziło, że pojawił się slot czasowy? Wiedzieliśmy co chcemy zrobić od strony ekosystemu SDN-owego, jako funkcjonalności – to mięcho, które ma tam działać – najważniejsza sprawa czyli przerzucać ruch, kontrolować te urządzenia itd. Natomiast zanim deweloperzy będą implementować te elementy, potrzebowaliśmy kawałek czasu aby przygotować działania AnArchu (czyli analityków i architektów), tej głównej części funkcjonalności. Teraz pojawiło się pytanie: co zrobić z czasem u deweloperów? I to nie to, że w tym miejscu wkleiliśmy cały portal operatora – to jest właśnie ta piękna historia, którą chcę opowiedzieć – tylko w tym miejscu stwierdziliśmy: mamy dwa sprinty. Dotychczas, drodzy deweloperzy, nie rozmawialiśmy o portalu operatora. Nie mamy całej rozkminki AnArchowej gotowej do tego, ale to jest świetny moment żebyście przeprowadzili PoC-a (*Proof of Concept). Dwa Sprinty w cztery tygodnie i wasz cel jest taki: „zróbcie wow”. Cokolwiek najbliżej jesteście w stanie do tego dojść. Więc to był o tyle specyficzny pierwszy epik – z tej serii epików do wytworzenia tego komponentu jakim jest ten portal operatora – którego celem nie była konkretna funkcjonalność, tylko który miał Timebox, czyli w cztery tygodnie zróbcie co potraficie. Dodatkowo jeszcze pożyczyliśmy z innego projektu R&D (Research and Development) w EXATEL osobę, która już miała doświadczenie z Frontem, bo większość naszych deweloperów zajmuje się tym „mięchem”, przerzucaniem ruchu, telekomunikacją, siecią itd. Więc to nie jest ta sama specjalizacja, co ktoś kto umie tworzyć graficzny interface użytkownika.

Sylwia: I jeszcze żeby UX-owo się spinało, nie?

Michał: To też jest ciekawe zagadnienie. Oczywiście tak, żeby UX-owo też się spinało. Natomiast tutaj potrzebowaliśmy – nawet pal sześć polerowanie od strony UX i UI – by ktoś potrafił napisać to. Kolokwialnie rzecz ujmując, pożyczyliśmy kolegę z innego zespołu, żeby przez te cztery tygodnie z nami popracował. To co przez te tygodnie stworzyli koledzy przy tak zadanych parametrach wejściowych, było naprawdę zdumiewające. I pokazało, że w MVP-0 jak najbardziej jesteśmy w stanie zamieścić ten portal operatora.

Sylwia: Chyba podeszliście do tego trochę od drugiej strony, że nie była wykonana analiza w zespole analityczno-architektonicznym. Czyli architekt nie wykonał całej architektury tego rozwiązania, tylko zaczęliście od dołu i zespół miał powiedzieć co jest w stanie zrobić w danym czasie?

Michał: Nawet więcej. Nie miał powiedzieć, tylko miał to zrobić. Jest to nietypowe przy tym klasycznym podejściu, ale korzystamy z tego, że pracujemy w Scrumie i on się idealnie nadaje właśnie do takiego zagadnienia, jakie tutaj zastosowaliśmy.

Sylwia: No to powiedz z ciekawości jak zespół zagregował. Bo to nie jest typowe. Zwykle dostają zadania zdekomponowane przez architektów na mniejsze, sami się podejmują i je wyceniają, a tutaj dostali zadanie „wymyślcie coś i zaproponujcie rozwiązanie”.

Michał: Generalnie tak jak wspomniałem to był 2020 rok, początek 2021, kiedy to faktycznie zabraliśmy się za ten PoC portalu operatora. Z tego co zapamiętałem z tego czasu to odpowiedź zespołu była bardzo pozytywna. Oczywiście niektóre osoby wolą mieć wolną rękę, inne zaś wolą mieć jasno powiedziane od A do Z to jest do zrobienia. Więc to nie jest tak, że wszyscy przejawili ogromny entuzjazm. Ale generalnie zespołowi się to bardzo podobało z dwóch powodów. Po pierwsze to jest Scrum w czystej postaci, co jest generalnie przyjemniejszym sposobem do pracy. Po drugie kryterium sukcesu było umożliwienie nauczenia się czegoś nowego. U większości osób, w szczególności jak sama wiesz gdy kogoś rekrutujemy, jedną z rzeczy na które bardzo patrzymy, to czy dana osoba ma otwarty umysł i czy chce się nauczyć czegoś nowego. Czy to tę osobę kręci. Bo jednak w R&D nie da się uniknąć uczenia się nowych rzeczy.

Sylwia: Tutaj turbo ważna jest elastyczność.

Michał: Dokładnie. To nie jest tylko wytwarzanie ciągle tego samego, robienie w kółko tego co już umiemy, tylko po prostu uczenie się nowych rzeczy. Więc odzew był bardzo pozytywny w tym względzie, przynajmniej to co ja zapamiętałem. Od strony biznesowej to był bardzo duży sukces, bo po pierwsze pokazaliśmy, że jest to coś co możemy już w MVP-0 wrzucić. Coś, co nie było na takim etapie dojrzałości produktu w absolutnym minimum, ale rozwiązywało nam parę elementów, które musielibyśmy zrobić w inny sposób. Po drugie pokazało nam, że umiemy pracować w tej sposób. Efekt końcowy tego dwusprintowego epika był taki, że część rzeczy była na sznurkach, część funkcjonalności na zasadzie „tutaj jest przycisk”, który kiedyś będzie to robił, ale pokazało to, że jesteśmy w stanie to zrobić i przy okazji koledzy pozyskali tę wiedzę, umiejętność, doświadczenie w robieniu tego interface’u graficznego. Więc od tego momentu zaczęliśmy wpinać to w standardowy strumień prac, czyli poszło to do AnArchu. Zobaczcie mamy tu taki Proof of Concept i teraz skoro wiemy, że chcemy by był elementem MVP-0, to przekujcie to w wymagania, w epiki, w story, które będziemy potem normalnie wytwarzać. I powstał następny epik , tak zwany Portal_v1, który w AnArchu został przeanalizowany, przygotowany co potrzebujemy na MVP-0 i zostało wytworzonych dziesięć historii użytkownika. Dużo i mało, w zależności od tego na jakiej operuje się skali. U nas to są dosyć duże historie i ta skala czasowa na której pracujemy jest naprawdę spora. Bardzo często jeden sprint to taka jedna historia użytkownika. Nie pamiętam ile dokładnie trwał ten epik, jak już trafił do developmentu, ale to było z sześć sprintów. Koledzy z developmentu zrobili dekompozycje na 135 tasków. Tutaj się podpieram statystyką, którą wcześniej spisałem. To nie tak, że ja potrafię wymienić ile tasków miały wszystkie epiki robione przez ten rok.

Sylwia: Odnieś się chociaż czy to dużo, czy mało?

Michał: To znaczy tak. Jeden task to jest coś (statystycznie rzecz biorąc, bo one są oczywiście różne) nad czym jeden deweloper musi pracować przez parę dni.

Sylwia: Rozumiem.

Michał: Więc mówimy tutaj o między 100 a 300 osobodniami i to jest tak spod grubego palca oceniane, żeby pokazać skalę.

Sylwia: Ale daje punkt odniesienia.

Michał: Więc na podstawie tego PoC, tam gdzie robiliśmy tunelowanie tego ONOS’a (kontrolera), wyciągaliśmy jakby do warstwy wizualnej, opakowywaliśmy w naszą aplikację z której użytkownik będzie korzystał i na podstawie tego PoC stwierdziliśmy: „dobra, to teraz wiemy już jak to robić – zrealizujmy wymagania biznesu, użytkowników końcowych w tym absolutnym minimum”. W tym v1, w tych 135 taskach, zostało to przez zespół wykonane. Znowu dotarliśmy do jakiegoś etapu z tym konkretnym komponentem i zespół zabrał się za inny komponent, inny epik został przygotowany przez AnArch i zaczęliśmy testować co tam jest. Wyszło, że parę rzeczy fajnie działa, ale parę rzeczy jeszcze trzeba dorobić. Biznes z innej strony oglądając to stwierdził: „zapomnieliśmy, albo dopiero teraz nam się rzuciło w oczy, że coś takiego jest potrzebne”. Albo najlepsza sytuacja: „zainspirowaliście nas do tego, fajnie by było jakbyście nam to dorobili”. To jest najlepsze jak od biznesu coś takiego słyszysz. To nie jest tak, że oni nam to mówią, a za 2 tygodnie to oglądają. To oznacza, że musimy to teraz przygotować, przeanalizować jak to wpływa na architekturę i jak to się łączy z innymi komponentami.

Sylwia: Czyli rozumiem, że trafia do backloga którym zarządza…

Michał: Backlogiem zarządzam ja.

Sylwia: No właśnie. Więc trafiło do backlogu i rozumiem, że ty się już zajmujesz rozpisaniem harmonogramu i kalkowaniem wymagań z biznesu, tudzież przygotowanych przez analityków, tak?

Michał: Tak. W takiej codziennej pracy jak najbardziej tak. W tej konkretnej historii, ciągu zdarzeń o którym opowiadam, to byliśmy na tym etapie, że zamykaliśmy epik. Czyli zespół wytworzył i my teraz oglądamy co w efekcie udało się wytworzyć. Więc są tutaj zadania znowu dla AnArchu, żeby obejrzeć to co zostało wytworzone. Już wtedy wiedzieliśmy, na podstawie chociażby tego co powiedziałem, że od biznesu zaczęły spływać jakieś dodatkowe informacje, że przed dostarczeniem MVP-0 będziemy musieli jeszcze jeden epik zrobić, taki doszlifowujący. Czyli mieliśmy pierwszy epik, taki timebox – „zróbmy co się da i się nauczmy” – na podstawie tego mieliśmy taki główny – „to zróbmy teraz to porządnie” – i na podstawie tego co zrobiliśmy porządnie było: „musimy to doszlifować”. I tak powstał trzeci epik, który nazywał się Portal_EPL. Został on wciśnięty w harmonogram do MVP-0 gdzie mieliśmy zafiksowaną datę releasu, gdzieś ją  scommitowaliśmy dla reszty organizacji kiedy to będzie dostępne. Więc powstał ten epik i znowu AnArch przygotował rozbicie, tym razem na 8 user stories, zespół rozbił to na 78 tasków i ten epik już był taki bardziej konkretny. Bardziej tutaj użytkowanie tego, szlifowanie. Wyszło, że mieliśmy jeszcze 75 bugów, ale koniec końców efekt był taki, że jak dostarczyliśmy MVP-0 – na takie pierwsze uruchomienie, żeby zobaczyć czy ta cała koncepcja działa – to portal był już integralną częścią tego rozwiązania.

Sylwia: Brzmi to bardzo fajnie. A jaka była finalnie reakcja biznesu? Mieli jeszcze jakieś uwagi? Jak zawsze wygląda odbiór końcowy po stronie biznesowej?

Michał: Ucieknę od określenia „odbiór końcowy”, ponieważ tak jak mówiłem, budowanie tego całego ekosystemu to ogromny temat. Naprawę ogromny.

Sylwia: Nigdy się nie skończy?

Michał: Może nie nigdy, ale stanowczo nie nazwałbym tego finalnym odbiorem z tego powodu, że chce być spójny z tym co mówiłem wtedy, w 2021 roku, kiedy MVP-0 do biznesu przedstawialiśmy i tam im wielokrotnie powtarzałem – to nie jest finalny produkt. To jest nasze pierwsze podejście do czegoś już finalnego, namacalnego, a nie jakiegoś elementu, który kiedyś w przyszłości będzie. To już coś robi, ale nie oczekujcie od tego, że będzie robiło wszystko czego potrzebujecie.

Sylwia: Czyli rozumiem, że podejście jest trochę takie jak do pracy projektowej czy zadaniowej – żeby nie prokrastynować to przyjmijcie sobie datę końcową, zobaczcie ile da się zrobić w tym skończonym czasie i tym sposobem uciekamy od takiego perfekcjonizmu, bo inaczej projekty były by trudno kończące się, tak?

Michał: Tak, w szczególności w badaniach i rozwoju (R&D) gdzie zawsze będzie coś ciekawego do zresearchowania i zrobienia. Od strony biznesowej bardzo potrzebowałem żebyśmy się skonkretyzowali, czyli zaprzestali robienia, a zrobili coś. Nawet jeśli to nie będzie doskonałe.

Sylwia: To w takim razie jak tłumaczysz to „ty”, jako osoba tego pierwszego kontaktu dla biznesu i dla deweloperów, szczególnie temu biznesowi, który jednak ma te cechy perfekcjonistyczne, mocno wyśrubowane. Zadowolić ich jest trudno, więc musisz to jakoś wytłumaczyć, tak?

Michał: No tak. Perfekcjonizm w pewnych obszarach jest bardzo mile widziany i w utrzymaniu sieci jest stanowczo postrzegany pozytywnie. Chcemy jednak, żeby sieć była perfekcyjnie działająca. Więc masz rację, rozmowa z kolegami z tego obszaru firmy do najlżejszych z mojej perspektywy nie należy.

Sylwia: Czyli dobrze trafiłam?

Michał: Tak. I tak jak powiedziałem – to jest naturalne, bo taka jest ich rola. Moja jest taka, żeby jak najszybciej coś dostarczyć, jak najszybciej zebrać odpowiedzi. To jest ta rzecz, którą najbardziej podkreślałem: „Słuchajcie to nie jest finalny produkt. Rozumiem, że tutaj coś boli, tam coś nie działa, ale ja właśnie po to chce wam pokazać ten produkt, żeby od was to usłyszeć”. I to się świetnie sprawdziło, bo dużo się dowiedzieliśmy. Akurat dzisiaj skupiam się na portalu operatora, ale już mamy dwa następne epiki na podstawie tego, co widzieliśmy, że wiemy co zrobić z tym na przyszłość. Usłyszeliśmy też głos na podstawie tego pierwszego użycia. Nie na podstawie jakiejś demonstracji, tylko ci ludzie dotknęli już tego komponentu, tego narzędzia.

Sylwia: Czyli już wiem co miałeś na myśli mówiąc, że nie nastąpił odbiór końcowy. Bo to jest ciągle w fazie update’u, szlifu i doskonalenia, tak?

Michał: Tak.

Sylwia: O twojej roli już w kontekście rozmów z zespołem wytwórczym. Wiem ze ten temat już częściowo był omawiany w poprzedniej rozmowie z Piotrem. Nie mniej chciałabym zapytać jak tłumaczysz język biznesu zespołowi wytwórczemu, szczególnie jeśli mają wysokie oczekiwania, a zespół wie że się tego nie da. Twoją rolą jest wcielenie się w terapeutę, psychologa, osoby która tłumaczy język biznesu tak, żeby zespół wytwórczy odebrał to właściwie.

Michał: Tak, Jak najbardziej. Ja siebie nazywam pomostem pomiędzy tymi dwoma światami. Czyli tym, który umie tłumaczyć z jednego języka na drugi. Mi się rozmawia bardzo dobrze. Bardzo lubię rozmawiać z deweloperami. Tutaj akurat główną kwestią o której wcześniej wspomniałem, była kwestia wytłumaczenia biznesowi: „to nie jest produkt końcowy. Ale powiedz mi co więcej robić, w którą stronę iść, żebym ja miał materiał gdzie leżą te najniżej wiszące owoce, które chcemy zebrać z tego drzewka obietnic SDN-u”. Tak z punktu widzenia rozmowy z zespołem, główny nacisk jest na to, co jest realne do dostarczenia. Czyli ja im przedstawiam całą, bardzo daleką listę z wybranymi rzeczami, które biznesowo stwierdziliśmy, że są na teraz. I to co potrzebuję od nich pozyskać, to po pierwsze zrozumienie. Czyli oni potwierdzają: „tak, rozumiemy technicznie o co chodzi”. Po drugie: „to nam zajmie 8 sprintów”. To jest ta główna rzecz, którą w rozmowie z nimi prowadzę. Jako Scrum Product Owner, mam jeszcze tą drugą część, że rozmawiam z nimi jak im się tam pracuje, jakie narzędzia mogę im dostarczyć, żeby ułatwić im prace. Ale to oddzielny temat.

Sylwia: Zdecydowanie. A jeszcze jedno w takim razie pytanie, bo trochę rozdzielamy zespół wytwórczy (deweloperski) od zespołu AnArchowego, czyli analityczno-architektonicznego. Z kim rozmawiasz najpierw? Czy jest to jakoś ustalone? Jak wyglądają te rozmowy z zespołem wytwórczym i zespołem analityczno-architektonicznym?

Michał: To nie jest zero-jedynkowe. Rozmawiam oczywiście ze wszystkimi, tylko na różnych etapach tego co robimy. I to co dla mnie jest najważniejsze, to że nie schodzę na tyle głęboko, że jestem w stanie podyktować, że w te dwa tygodnie to napiszecie takie linijki kodu, które w taki i taki sposób działają. Właśnie po to jest zespół AnArchu, który jest w stanie opowiedzieć to ze strony technicznej. Dla mnie najważniejszą rzeczą jest, żeby zarówno AnArch jak i zespół wytwórczy rozmawiali ze sobą, a ja żebym mógł im dostarczać informacje: „to jest teraz biznesowo najważniejsze, w to idziemy”. Oczywiście padają pytania dlaczego w to, a nie w tamto. Wtedy też o tym rozmawiamy. Ale najważniejszą rzeczą o której rozmawiam to jest to, żeby AnArch i deweloperzy byli na tej samej stronie.

Sylwia: Czy przekazujesz informacje zespołu AnArchowego do zespołu wytwórczego, czy po prostu AnArch rozmawia z zespołem wytwórczym już bezpośrednio?

Michał: Bezpośrednio. To by było mega nieefektywne jeśli ja bym tam stał pośrodku. Właściwie dążę do tego – to idealny stan – żebym był praktycznie niepotrzebny w tej rozmowie. Ja bym tylko przychodził i mówił: „to teraz idziemy w stronę portalu operatora”. I tyle. Oczywiście to jest nierealne żeby tak było, ale to jest stan do którego staram się dążyć. Staram się tutaj być pomocą na ile to tylko możliwe, a nie tym poganiającym z batem i mówiącym „róbcie to albo robicie tamto”.

Sylwia: Powiedz Michał, jakie były twoje największe wyzwania w roli Scrum Product Ownera? Czyli na styku biznesu i techniki. Ale wyzwania zarówno ze stroną biznesową, jak i ze stroną techniczną.

Michał: Muszę się nad tym chwilę zastanowić. Ze stroną biznesową największe wyzwanie jakie posiadam, to żeby balansować pomiędzy tymi wszystkimi pięknymi obietnicami tego co w przyszłości możemy dostarczyć, a tym co dostarczamy teraz. Że to jest produkt nie do końca gotowy, niepełny. Jednocześnie chcę żeby ten produkt był już używany. To jest jedna rzecz. Druga rzecz, to wśród tych wszystkich obietnic przyszłości, co nam cały ekosystem będzie w stanie dostarczyć, to jest naprawdę dużo. To jest rewolucyjne z punktu widzenia EXATEL. A propos tej perfekcji – można ciągle robić, robić, robić, a ja bym chciał już mieć kawałek. Więc muszę wybrać który to będzie kawałek, który z jednej strony da się w miarę szybko dostarczyć, a z drugiej strony będzie miał wartość. Poza tym że jest wyzwanie z wycenieniem tego, podjęciem decyzji które jabłko chcemy zerwać w pierwszej kolejności, to drugie wyzwanie jest takie, żeby przedstawiając to jabłko, nie zniechęcić moje klienta (biznesu): „Ale chwila! Ja tutaj oczekiwałem całego stosu jabłek a ty mi dajesz jedno?”

Sylwia: A najchętniej szarlotkę.

Michał: Prawda. Ja to rozumiem i dlatego mówię, że to jest cienka linia na której się poruszam. Z jednej strony pokazywanie niepełnego produktu, a z drugiej nie spowodowanie zniechęcenia do tego, żeby ta komunikacja jednak się toczyła. A ze strony zespołu deweloperskiego największe moje wyzwanie jest chyba takie, że to jest spory zespół i są różne osoby. Dla jednej osoby to jest mega fajne jak może się zająć czymś, co nie zostało mu podyktowane, ma możliwość pójścia w różne strony, czy AnArch dostarcza jej bardzo dokładne dokumentacje co ma robić. Jedna osoba nie chce mieć dostarczonej takiej dokumentacji Ta osoba chciałaby sama taką dokumentację przygotować. Chce krok wcześniej włączyć się w te prace. Inna osoba woli pracować jednak z jasnymi kryteriami, skąd dokąd pracuje. I pogodzenie tego żeby jednak ludzie mieli komfort tej pracy – bo ten projekt za  nic nie ma szans wyjść jeśli ludzie będą zdemotywowani w robieniu tego, jeśli nie będą się dobrze bawić – to jest to przyznaję bardzo duże wyzwanie dla mnie.

Sylwia: Czyli tak naprawdę słuchanie zespołu i jego potrzeb, nawet indywidualnych. Bo nie mówimy nawet o słuchaniu zespołu jako grupy, tylko słuchaniu indywidualnych jednostek i ich potrzeb.

Michał: Tak. To jest największe wyzwanie, że jednak każdy jest inny. Każdy ma inne swoje potrzeby, a gdzieś tam końcowo trzeba podjąć decyzję, czy idziemy w prawo czy w lewo. Ze strony biznesu ważne jest żeby powiedzieli gdzie te złotówki leżą, w którą stronę – w lewo czy w prawo? Równocześnie muszę dorzucić na te szale informacje, ile czasu będzie to nas kosztowało, ile potencjalnej motywacji. Może jest coś bardzo fajnego dla biznesu, ale ciężkiego dla zespołu z jakichś powodów. Oczywiście powody mogą być różne. Powiedziałbym, że to jest najtrudniejsza część mojej pracy.

Sylwia: Kwestia zaangażowania, stabilizacji zespołu w dobie dzisiejszych czasów i badania i rozwój, to temat rzeka, więc może innym razem. Jestem blisko w tych tematach, pracując w obszarze HR, ale to może zaproszę Cię na kolejną rozmowę w tym temacie.

Michał: Bardzo chętnie. Choć to by bardziej wyglądało tak, że sama będziesz ze sobą rozmawiać, bo to ty wiesz najlepiej, jakie są te zagadnienia.

Sylwia: Uczestniczysz ze mną w tych rekrutacjach, więc dobrze wiesz jak to wygląda. Także zostawimy sobie ten temat na oddzielny wątek. Dopytałabym cię jeszcze, żeby też nasi słuchacze wiedzieli, jak rozumieć biznes? Kto jest interesariuszem projektu? Wspomniałeś już, że są to zespoły sieciowe, ale być może nie tylko? Jakbyś pogrupował lub przedstawił ten obszar? Jakie to są obszary w SDN-ie?

Michał: Tutaj w ramach anegdotki powiem ci, że za każdym razem jak mamy takie spotkanie poza naszym zespołem Software-Defined Networking, pokazujemy to co robiłem. Porównuję tę klamkę, że zbudowaliśmy w dwa tygodnie i staramy się pokazać jak to się wpasowuje w te nasze drzwi. Jak mówię, mamy tutaj zespół wytwórczy, a tutaj biznes. Oczami wyobraźni widzę jak większość ludzi którzy tam są zgrzyta zębami i myśli: „jak ja, inżynier sieciowy, jestem biznesem? Ja jestem techniką!” Więc masz rację. To słowo „biznes”, którego tu używam, jest bardzo szerokie. Bo z jednej strony mamy tych naszych końcowych użytkowników, którzy faktycznie będą to użytkować, inżynierów. Więc oni mają inne spojrzenie niż patrzenie na złotówki. Jak mówiłem o biznesie, to raz mówiłem o tych inżynierach, naszych użytkownikach, raz mówiłem a propos złotówek – o osobach podejmujących decyzje, pilnujących budżetu i ustalających strategie dla całej firmy. Więc biznes jest tutaj naprawdę szeroko ujęty. Po prostu robię taką linię demarkacyjną: zespół który wytwarza w SDN-ie (nasz R&D) i cała reszta organizacji. I całą resztę organizacji nazywam biznesem.

Sylwia: Czy biznes jest wspierający?

Michał: Oczywiście, że wspierający. W znaczeniu takim, że pomagają nam w tym projekcie. Choć oczywiście na początku jak wiesz mamy dopiero te pierwsze elementy. Elementy tej klamki. To gdzie nam tutaj zawracacie głowę? Czym bliżej do produktu finalnego, tym bardziej jest to dla nich interesujące. Natomiast wspierający są jak najbardziej. Ciężkie westchnienie z mojej strony polega na tym, że tak jak wspominałem wcześniej – ja rozumiem też ich stanowisko. Oni mają znacząco inną pracę niż my. W związku z tym uspójnienie tego języka, podejścia, jest wyzwaniem samym w sobie. Czyli tak: wspierać jak najbardziej wspierają, ale jako wspieranie mam także na myśli takie rzeczy, jak krytyczne uwagi: „słuchajcie, tutaj poszliście w złą stronę, zróbcie to inaczej”. Jak tylko posłuchać takiej uwagi, to ciężko to nazwać wsparciem. Ale faktycznie to wsparciem jest. Bez tego można się pogubić.

Sylwia: Zdecydowanie. Zgadzam się, że jeżeli feedback jest konstruktywny, to jest to wartość dodana.

Michał: Tak, jak najbardziej. Dla mnie naprawdę jest to bardzo duża wartość.

Sylwia: Michał, moglibyśmy tak rozmawiać i rozmawiać, bo temat dla mnie jest również bardzo interesujący. Mimo, że jestem osobą z HR, to lubię kwestie techniczne. Nie mniej myślę, że na dziś ten wątek który poruszyliśmy, czyli portal operatora i część twojej pracy od kuchni. Jak sam powiedziałeś część, bo jest to dosyć szeroki zakres i zostawimy sobie trochę na kolejny podcast. Chętnie jeszcze z tobą porozmawiam. Za dziś bardzo ci dziękuję. Fajnie, że wpadłeś.

Michał:
Dzięki! Cała przyjemność po mojej stronie. Bardzo lubię rozmawiać, więc mam nadzieję, że uda nam się w przyszłości jeszcze pogadać.