Z góry przyznaję, że tytuł tego artykułu jest... kłamstwem. Nie będzie on opowiadał o ideale, który jest receptą każdego software house’u na doskonałe prowadzenie projektów (a właściwie produktów - do tego jeszcze wrócimy). Powód jest prosty - ideały nie istnieją. Nawet jeśli jakimś cudem bylibyśmy w stanie wyróżnić najlepsze osoby w branży w jakiejkolwiek dziedzinie, to i tak zawsze znajdą się elementy, w których mają coś do poprawy lub znajdzie się lepszy specjalista od nich. Nawet najlepszy proces rekrutacji okraszony masą szczęścia oraz samorozwój nie doprowadzą nas do perfekcji. Ale to nie oznacza, że nie można się starać.

Nie jest tajemnicą, że w Wilda Software mamy managerów - nie jest to dziwne z uwagi na to, że zawsze, nawet w stosunkowo niewielkiej firmie, osoby kierujące pracami są potrzebne, a poza tym widzieliście pewnie nasze ogłoszenia, w których poszukiwaliśmy osobę na rolę Product Ownera. Przez ten czas mieliśmy kontakt z różnymi stylami prowadzenia projektów lub produktów, z dobrymi i złymi momentami, więc siłą rzeczy wypracowaliśmy wnioski, z którymi chcielibyśmy się z Wami podzielić.

Jaki zatem powinien być idealny Product Owner? Żeby odpowiedzieć na to pytanie, musimy najpierw zdefiniować sobie, o kim właściwie mówimy.

Kim jest product owner?

Zacznijmy nietypowo - zapytajmy najlepszego (niestety) przyjaciela wielu z nas o definicję tej roli. Oczywiście, mowa o ChatGPT:

Product Owner (PO) to kluczowa rola w ramach metodyki Scrum, odpowiedzialna za maksymalizowanie wartości produktu. PO działa jako łącznik między interesariuszami a zespołem deweloperskim, dbając o to, aby produkt spełniał wymagania biznesowe i użytkowników.

Jest to właściwa definicja, to znaczy rzeczywiście w taki sposób określa się ten zakres obowiązków w zespole. To termin ściśle związany z metodyką scrum, gdzie rozróżnia się właśnie PO oraz Scrum Mastera (SM). Do tego jeszcze dzisiaj przejdziemy - na razie skupmy się na naszym ownerze.

Człowiek pełniący tę rolę zarządza powstawaniem produktu i jest odpowiedzialny za dostarczanie płynącej z niego wartości. Jednak teraz musimy wyjaśnić sobie jeszcze jedną rzecz - dlaczego "produktu", a nie "projektu"? Z jednej strony jest to kwestia stricte terminologiczna, gdyż zazwyczaj zespół pracujący zwinnie tworzy właśnie produkt, a więc jeden kawałek oprogramowania lub przynajmniej pewien spójny ekosystem, który jest oferowany klientowi - projekt to szersze zagadnienie i cały proces powstawania produktów oraz ich projektowania. Z drugiej strony, często kojarzymy produkt jako coś, co jest przeznaczone do radzenia sobie w pewnym środowisku i trzeba tak umiejętnie sterować jego rozwojem, aby wpasował się w oczekiwania użytkowników, a przede wszystkim klientów. Czyli niekoniecznie jest to zarządzanie w sensie harmonogramu, budżetu i czymś, co zostało określone z góry i po prostu trzeba to doprowadzić do końca - tutaj mówimy o zarządzaniu w sensie analizy i zaproponowania czegoś, czego być może klient nie zdefiniował wprost (nakreślając jedynie swoje oczekiwania), ale my jesteśmy odpowiedzialni za zaproponowanie i dostarczenie odpowiedniego rozwiązania. W tym miejscu niektórzy mogą skojarzyć określenie "Product Manager", które pewnie nieraz widzieliście na profilach na LinkedInie - to określenie z kolei jest bardziej związane z produktami, które są proponowane na rynku, a nie powstają na zamówienie. Co za tym idzie - tutaj taka osoba musi również śledzić trendy i umieć proponować rozwiązania bez jasnych wskazówek, opierając się na analizie biznesowej, technicznej, ale też marketingowej. Lub być wizjonerem, tak jak Steve Jobs.

"Ale to zagmatwane", pewnie niektórzy powiedzą. I co ciekawe, zgadzamy się - tak naprawdę główny czynnik odróżniający typowego Project Managera od Product Ownera to fakt, że ten drugi zarządza powstawaniem produktu i jest "bliżej" go, ale w zamian nie jest aż tak zaangażowany w sprawy budżetowe. Co nie oznacza, że nie powinien rozumieć, że niektóre działania mają też podłoże bardziej biznesowo-finansowe, a dodatkowo wypada, żeby zainteresował się harmonogramem. W mniejszych firmach, gdzie nie ma wielopoziomowej drabinki zarządzania, siłą rzeczy owner jest trochę managerem, ale w mniejszym stopniu odpowiada za kwestię rozliczeń - te nadal przechodzą przez wyższe kierownictwo.

Proponuję również nie zastanawiać się, czy bardziej powinniśmy nazywać taką osobę "Product Ownerem", czy "Project Ownerem" - dlatego u nas często mówimy po prostu "owner", co pewnie będzie gryzło purystów scrumowych, ale jakby nie patrzeć, scruma, jak każdą metodykę, też się dostosowuje pod swoje potrzeby.

Zarządzanie backlogiem

W dawnych czasach, gdy uczyłem się zarządzać projektami najpierw teoretycznie, a później w praktyce (dzięki programowi SDS) na specjalności Software Engineering na Politechnice Poznańskiej, dzieliło się zarządzających na:

• kierownika projektu - pilnował harmonogramu, dbał o komunikację, reprezentował zespół na zewnątrz, miał najszerzej zakrojone umiejętności miękkie.
• analityka - zarządzał wymaganiami, analizował oczekiwania klienta i przekładał je na język techniczny, potrafiąc ocenić nie tylko poprawność obliczeń, ale też stopień spełnienia wizji odbiorcy.
• architekta - projektował architekturę oprogramowania, był głównym konsultantem technicznym i dbał ogólnie o technikalia, wraz z konsekwencjami wyborów.

Z oczywistych względów Product Owner nie jest architektem, gdyż tym zajmuje się CTO lub inna wyznaczona osoba w danym projekcie. Natomiast - czy bliżej mu do kierownika projektu, czy analityka? W pewnym stopniu posiada cechy jednego i drugiego, ale na pewno umiejętności analityczne są bardzo mile widziane u takiej osoby. Zwłaszcza, że o analityku można powiedzieć, że jest "proxy klientem", czyli kimś, kogo można zapytać o to, co klient by powiedział w danej sytuacji.

Właściciel produktu to ktoś, kto ma pełną wiedzę o tym, czym produkt ma się stać, jakie są cele klienta i całego projektu, a także nad czym aktualnie mają trwać prace i w jaki sposób są realizowane. To na ownerze spoczywa odpowiedzialność za:

• ustalenie z klientem zakresu sprintu (oraz, szerzej, projektu),
• opis i zrozumienie wymagań (zarówno funkcjonalnych, jak i pozafunkcjonalnych),
• konsultację z klientem w sprawie wybranych wersji wymagań oraz ich zakres godzinowy (czyli, mówiąc wprost, zarządzanie wyceną),
• priorytety zadań,
• analizę różnych opcji i doradzanie zespołowi w przypadku wątpliwości,
• walidację zrealizowanych zadań pod kątem biznesowym,
• kontrolę zadań, które czekają na realizację, a chwilowo zostały wstrzymane,
• dystrybuowanie zadań wewnątrz zespołu, także biorąc pod uwagę zgłoszenia serwisowe.

Krótko mówiąc, owner ma wiedzę o wszystkich zadaniach, które były realizowane, obecnie są wykonywane lub tych, które czekają zespół w przyszłości. To ta osoba jest często adresatem pytań programistów w stylu "czym się teraz warto zająć?" lub "jak to powinno być zrobione?" albo "co klient powiedziałby na to?", co wymaga odpowiedniego stopnia samoorganizacji i doboru odpowiednich lub wykorzystania istniejących narzędzi. Owner często żongluje też poprawkami serwisowymi lub gwarancyjnymi w taki sposób, aby z jednej strony nie kazać klientowi długo czekać, ale z drugiej też nie zaniedbać aktualnie zleconych prac. Dodatkowo, musi tak ułożyć zadania, aby w razie niemożliwości skończenia wszystkiego w terminie, zrobić jak najwięcej realnie potrzebnych i wartościowych rzeczy.

Takie jest właśnie zadanie ownera - doprowadzić zespół do dostarczenia wartości biznesowej dla odbiorcy. To siłą rzeczy wymaga wiedzy i umiejętności kolejkowania zadań w backlogu (a więc rejestrze zadań), a czasem nawet bycie swoistą bazą wiedzy o produkcie, nierzadko uwzględniającą historię rozmów ze zleceniodawcą. Różni właściciele produktu podchodzą do tego w różny sposób - ci bardziej techniczni lepiej radzą sobie z niuansami każdego zadania i są bliżej myślenia programistów, natomiast są osoby, których kwestie techniczne mniej interesują, natomiast potrafią lepiej zrozumieć nietechniczny punkt widzenia klienta. Oczywiście, bardzo to upraszczam, ale faktem jest, że każdy ma trochę inne doświadczenia i predyspozycje.

Wśród powyższych punktów pojawił się temat walidacji i spokojnie - nie chodzi o to, aby product owner był najbardziej wytrwałym członkiem zespołu QA, natomiast fakt jest taki, że powinien w miarę możliwości przeklikiwać oprogramowanie i to z co najmniej trzech względów. Po pierwsze, uspokaja się przy tym, że wszystko działa, a to owner jest główną osobą, która w razie czego dostanie "bęcki" od klienta (ale też pochwałę, gdy ten będzie zadowolony). Po drugie, siłą rzeczy w ten sposób uczy się systemu, co bardzo ułatwia późniejsze prezentacje lub generalnie rozmowy o rozwoju, zyskując zaufanie w oczach zleceniodawcy. Po trzecie i najważniejsze - w ten sposób może wyłapać błędy nie na poziomie technicznym, ale w zrozumieniu oczekiwań klienta. Zdarza się bowiem, że programista realizuje wymaganie w pełni zgodnie z kryteriami funkcjonalnymi i obliczeniowymi (weryfikacja przeszła poprawnie), ale to wszystko jest widoczne w systemie w taki sposób, że użytkownik na pewno z tego nie będzie mógł wygodnie korzystać (walidacja wykazała błędy). Product Owner, jako osoba mająca wiedzę o tym, jak użytkownicy będą korzystali z systemu i jakie mają kompetencje techniczne, może zareagować i to w dwojaki sposób:

• wcześniej uczestnicząc w powstawaniu makiet, aby przedstawić obrazowy plan,
• przygotowując DoDy, pomagające programiście w autoweryfikacji swojego dzieła.

Szczególnie na DoDy warto zwrócić uwagę, gdyż owner jest naturalną osobą, które może rozpisać takie punkty, dodatkowo określając powiązania logiczne pomiędzy różnymi zadaniami. Jednak bywa też tak, że owner musi stworzyć prościutką, amatorską makietę, aby pokazać programiście "tak to ma wyglądać".

Wizja produktu i jego cele

Wyżej wspominałem już o tym punkcie, ale trzeba powtórzyć - Product Owner ma pełną wiedzę o tworzonym produkcie, nawet większą pod kątem biznesowym niż technicznym. On najlepiej z całego zespołu rozumie, do czego klient chce dotrzeć i jak wyobraża sobie narzędzie, które dla niego tworzymy. Nie ma z tym problemu, gdy jest to w miarę standardowe przedsięwzięcie, gdyż software house wie, jakie są pewne trendy na rynku. Gorzej, jeśli klient daje do zrozumienia, że on będzie korzystał z oprogramowania w inny sposób niż standardowy lub ma bardzo specyficzne wymagania (wynikające czasem z branży). Może też zaistnieć sytuacja, że do tej pory korzystał ze starszego systemu, do którego się przyzwyczaił lub z którego trzeba przenieść dane o pewnej strukturze.

Product Owner musi to wszystko wiedzieć i - co ważniejsze - rozumieć. Jeśli nawet coś wydaje się mniej szablonowe niż w innym oprogramowaniu, to konieczne jest zrozumienie, czy to bardziej niewiedza zleceniodawcy dotycząca tego, jak teraz się rozwiązuje pewne kwestie (bywa i tak), czy przemyślane, rzeczywiste wymaganie, które trzeba spełnić. W pierwszym przypadku owner ma większą swobodę propozycji zrealizowania określonej kwestii lub nawet zapunktowania tym, że wychodzi naprzeciw klienta i jest kreatywny. W drugim - musi przyjąć wizję odbiorcy jako wymaganie pozafunkcjonalne i wokół tego ułożyć inne rzeczy.

Zespół musi wiedzieć, że może polegać na ownerze jako osobie, która zawsze wie, czego chce klient, a jeśli nawet nie wie, to potrafi o to "efektywnie" dopytać, tj. pokazać, że rozumie ideę, ale potrzebuje jej uszczegółowienia. Umie też odfiltrować rzeczy, o których zleceniodawca mówi, że "fajnie by było" od tych, które realnie są mu potrzebne (nawet, jeśli nie zostaną powiedziane wprost). W razie potrzeby umie pokazać inne możliwości i w ten sposób upewnić się, czego klient rzeczywiście chce. O te aspekty zahaczymy w kolejnych punktach tego artykułu.

Klienci mają często tendencje do przypominania, po co tak naprawdę uruchomili projekt i trudno im się dziwić - to są konkretne pieniądze, które wydają w celu doprowadzenia do sukcesu w postaci przyspieszenia pracy, zmniejszenia kosztów, wyskalowania firmy lub po prostu dostarczenia wartości użytkownikom. Dlatego niedopuszczalną sytuacją jest brak zrozumienia tych celów przez ownera oraz sugerowanie, że jest nimi zaskoczony, zdezorientowany lub zapomniał o wcześniejszych wysokopoziomowych ustaleniach (pomijając sytuacje, kiedy owner w projekcie pojawił się po czasie i dopiero go poznaje). Z drugiej strony, warto umieć rozpoznać, kiedy klient chce zmienić kurs lub nieświadomie to robi i upewnić się, czy taki jest rzeczywiście jego zamiar.

W przypadku produktu, który ma trafić na rynek z inicjatywy firmy, której częścią jest Product Owner, taka osoba powinna też być świadoma obecnie panujących rozwiązań i umieć rozpoznać, które funkcje rzeczywiście są pożądane przez użytkowników, a które będą “selling pointem". Natomiast to jest raczej sfera wychodząca poza "ownerowanie", bardziej wchodząca w sferę obowiązków wspominanego wcześniej Product Managera.

Współpraca i komunikacja

To z kolei aspekt, który bardziej kojarzy się z kierowaniem projektem. Wspominałem o tym, że Product Owner jest najczęściej pierwszą osobą, która dostaje pochwałę lub burę od klienta, gdyż też jest niejako reprezentantem zespołu na takich spotkaniach, a także głównym reżyserem procesu oddawania prac. To nie oznacza, że jako jedyny w nich uczestniczy i koresponduje, ale na pewno jest tym, który powinien uczęszczać we wszystkim, co dzieje się w związku z danym przedsięwzięciem.

To oznacza, że właściciel produktu powinien:

• umieć przygotować rozsądnie brzmiącego maila i mieć pewną łatwość w formułowaniu swoich myśli (niekoniecznie posiadać “lekkie pióro", ale też nie być totalnie niepiśmienny),
• umieć rozmawiać w taki sposób, aby osiągać cele - to nie oznacza, że musi być duszą towarzystwa, ale trudno wyobrazić sobie mrukowatą osobę na tym stanowisku,
• nie bać się odezwać na spotkaniu z klientem, ale jednocześnie wiedzieć, kiedy należy słuchać,
• robić dobre notatki i trzymać je w jednym miejscu, dostępnym dla wszystkich, którzy potrzebują,
• umieć proponować rozwiązania i argumentować je,
• umieć się zachować, w tym wiedzieć, kiedy żartować, a kiedy być poważnym (podstawowa sprawa, ale warto o tym wspomnieć, zwłaszcza, że niektórzy spojrzą tutaj znacząco na mnie),
• rozwiązywać różnice zdań, zarówno w zespole, jak i pomiędzy klientem oraz zespołem.

Ważna uwaga - to nie oznacza, że te cechy mają przeważać i Product Owner powinien być nie tylko analitykiem, ale też literatem, negocjatorem policyjnym i ekstrawertykiem. Natomiast nie należy ukrywać, że osoba w tej roli będzie dużo rozmawiać, korespondować i - mówiąc kolokwialnie - ogarniać komunikację wewnętrzną i zewnętrzną, choćby po to, aby wytyczne były znane i klarowne. Także sam opis zadań, mimo że jest kwestią bardziej techniczną, wymaga pewnej biegłości w pisaniu. Podobnie rzecz się ma z opowiadaniem o projekcie i jego celach, co przecież czeka ownera choćby przy przyjmowaniu nowej osoby do zespołu.

Natomiast to, co osobiście bardzo cenię w Product Ownerach, to coś, co młodzież by nazwała "poczuciem vibe'u klienta". Doskonale wiemy, że każda osoba ma swoje przyzwyczajenia, poziom akceptacji żartu, temperament, sposób wypowiadania się, styl rozmowy itd. Krótko mówiąc - każdy jest inny. Umiejętność dostosowania się do komunikacji z daną osobą jest według mnie bardzo ważna, a przynajmniej przydatna. Inaczej pisze się maile do osoby, która ma ułożoną wizję projektu, inaczej do “wizjonera", a jeszcze inaczej do kogoś, kto wyraża się bardzo precyzyjnie i analizuje każde zdanie. Inny "klimat" panuje podczas rozmów z pasjonatami w swojej dziedzinie, typowymi biznesmenami oraz osobami technicznymi. Wiedząc, na co klient zwraca uwagę, na jakie terminy lub wątki reaguje alergicznie, jak wysoką tolerancję na ewentualne błędy w zrozumieniu jest w stanie znieść, możemy lepiej zaplanować komunikację i dostroić ją do warunków. To, oczywiście, nie oznacza, że Product Owner musi być przy tym wszystkim jeszcze aktorem i niczym kameleon dostosować się do sytuacji, natomiast musi mieć świadomość, że szybciej osiągnie porozumienie rozmawiając w konkretny sposób i rozumiejąc, jak przebiegają negocjacje. Są klienci, którzy machną ręką na informację wysłaną z kilkudniowym opóźnieniem, ale też tacy, dla których będzie to powód do wzmożonych negocjacji na temat przyszłości współpracy. Będą momenty, w których Product Owner będzie mógł postawić na swoim, ale też takie, gdzie będzie musiał się ugiąć - umiejętność podjęcia właściwej decyzji to coś, co niektórzy mają lub potrafią "przykryć" pewnością siebie, a inni muszą nauczyć się jej w praktyce. Nie zapominajmy, że w tym wszystkim są jeszcze osoby stojące “wyżej", czyli szefowie firmy lub pion biznesowo-sprzedażowy, który często bierze na siebie trudniejsze rozmowy dotyczące poważniejszych wątpliwości klienta.

Ustalanie priorytetów

Wróćmy na chwilę do backlogu oraz wizji produktu - wspominałem już o tym, że Product Owner ma w głowie wyobrażony przez klienta projekt i zorganizowane to, co trzeba zrobić, aby to wyobrażenie ziścić. To naturalnie oznacza, że często będzie potrzeba ustalania priorytetów, zarówno przy udziale klienta (tak jest najlepiej), jak i samemu koncypując drogę do upragnionego celu. To owner, przy wsparciu zespołu technicznego, dysponuje wiedzą, że jeśli celem jest A i B, ale łatwiej je osiągnąć najpierw robiąc C, to warto tak zaplanować prace i przekonać do tego mocodawców. Cały czas zachodzi balansowanie pomiędzy dostępnym czasem, zasobami, celami długo- i krótkoterminowymi projektu, a także zdrowiem relacji pomiędzy zleceniodawcą oraz wykonawcą (temat bardzo szeroki, którego tutaj nie będę rozwijał, ale tutaj warto przypomnieć, że to bardziej odpowiedzialność wyższego pionu kierownictwa, a nie tylko PO).

Samo ustalanie sprintu wymaga dobrej wiedzy o tym, co warto zrobić wcześniej, ale jednocześnie przy wzięciu pod uwagę, czego klient się spodziewa. A ten nie zawsze umie wyrazić swoje potrzeby w odpowiedni sposób i z tym też trzeba się pogodzić - wówczas na głowie Ownera jest takie przestawienie klocków, aby odbiorca był jak najbardziej zadowolony. A jeszcze do tego pozostaje kontrola tych priorytetów podczas realizacji i albo klarowne ich przedstawienie zespołowi (dzięki czemu ma “samograj"), albo stałe monitorowanie tego, które zadania są aktualnie wykonywane.

Usuwanie przeszkód na drodze zespołu

To kolejna kwestia, która jest bliższa typowym managerom, ale nawet w Scrumie jest to raczej powinność innej roli, czyli Scrum Mastera. Tym niemniej, Product Owner również powinien mieć baczenie na to, co blokuje zespół w realizacji sprintu, szczególnie jeśli ma to związek z samymi wymaganiami. Może się bowiem zdarzyć, że:

• nie ma zasobów (np. osób), które mogą się danego zadania podjąć,
• zadanie nie jest jasne lub - co gorsza - już jest realizowane w sposób odbiegający od założeń,
• brakuje materiałów od klienta,
• nie wiadomo, jak testować dane wymaganie.

Dlatego PO ma do dyspozycji kilka narzędzi, którymi może się posługiwać - system do zarządzania zadaniami (u nas Feedybacky), wspomniane DoDy, SUMy, testy akceptacyjne, a także po prostu dokumentacja w różnej formie, która pozwoli przypomnieć sobie o ustaleniach, uspokoić i naprostować sytuację. Czasem blokady mają źródło w zewnętrznych dostawcach, ale bywają też w samej firmie - umiejętność szybkiej identyfikacji i realizacji takiego problemu również jest bardzo cenioną cechą Product Ownera. Podobnie jak proaktywność - mało jest gorszych i bardziej demotywujących widoków niż PO, który wie, że jest problem i biernie czeka, aż sam się rozwiąże. Bo "jakoś to będzie". Otóż, nie zawsze.

O harmonogramie i budżecie

O ile PO rzeczywiście nie jest od tego, aby przejmować się pieniędzmi, to warto, aby wiedział, które zadania są szczególnie wartościowe także z tego punktu widzenia oraz jakie są ustalenia dotyczące finansowania projektu. To również wpływa na decyzje dotyczące ułożenia zadań, sprintu, a także relacji pomiędzy software housem i klientem. Owner nie jest od tego, aby ustalać stawkę za godzinę, ale powinien być świadomy tego, jak rozliczany jest projekt.

Natomiast harmonogram to trochę bajka - właściciel produktu powinien mieć najbardziej aktualną wiedzę o tym, które zadania są nie tylko istotne, ale też kiedy mają zostać oddane, biorąc pod uwagę np. dodatkowe zobowiązania klienta (np. plany kampanii marketingowej), granty czy zwyczaje panujące na rynku. Oczywiście, ta wiedza ma posłużyć do prawidłowego określenia priorytetów, ale też monitoringu realizacji, gdyż pewne zadania stają się szczególnie istotne pod tym kątem.

Pewnie Was nie zdziwi, że kontrola na koniec sprintu nie jest wystarczająca - najlepiej byłoby śledzić sytuację na bieżąco, jednak zajmuje to czas i też demotywuje, gdy postępy nie zawsze są zauważalne, szczególnie dla osoby nietechnicznej. W naszym Feedybacky mamy do tego specjalny raport, który pozwala określić postęp wykonania poszczególnych fragmentów projektu - spokojnie, opiszemy go niebawem.

Podsumowanie

Biorąc to wszystko pod uwagę, idealny Product Owner:

• doskonale orientuje się w celu projektu oraz zleceniodawców,
• rozumie wizję przedsięwzięcia, ale też potrafi spojrzeć na nią krytycznie,
• dobrze organizuje wymagania i zadania,
• umie wyznaczać priorytety i monitorować je,
• trzyma rękę na pulsie, walidując to, co robi zespół techniczny,
• dobrze się komunikuje, umie słuchać i notować,
• "czuje atmosferę" relacji z klientem,
• zauważa kłopoty i przeciwdziała im, jeśli może,
• umiejętnie dobiera narzędzia do prowadzenia projektu.

Oczywiście, nie istnieje ktoś, kto jest perfekcyjny w każdym z tych elementów, choć na pewno praktyka czyni mistrza i pozwala takiej osobie być świadomym swoich ograniczeń oraz umieć z nimi walczyć. Nie jest to łatwa rola - to jedna z tych, które trudno wyćwiczyć samemu w domu (jak programista lub inna techniczna specjalizacja), a wiedza z książek może być niewystarczająca, gdy pojawią się realne problemy, a zespół liczy, że dasz mu spokój i zadziałasz. Tym niemniej, warto próbować, gdyż satysfakcja z dobrze poprowadzonego projektu jest wspaniałym uczuciem i mam szczęście, że mogę mówić o tym z doświadczenia.

Pozdrawiam i dziękuję - Jakub Rojek.