Zarządzanie projektami IT - tak aby odnieść sukces - Automation Talk #8

W tym odcinku dowiesz się:

• Czym jest projekt IT?
• Remote Work - jak wpływa na projekt?
• Agile vs Waterfall
• Czym różni się Projekt od Produktu?
• Jak skutecznie zarządzać projektem?
• Dlaczego projekty się udaja? A dlaczego niektóre się nie udają?

Posłuchajcie, zmotywujcie i wyciągnijcie z tej rozmowy to, co dla Was teraz najlepsze.

🎧 Zapraszamy na Spotify, Apple Podcasts, Google Podcasts, Spreaker. Enjoy!

Listen to "#8 Zarządzanie projektami IT - tak aby odnieść sukces" on Spreaker.

Transkrypcja

Sebastian Grzesik: Cześć i dzień dobry! Nazywam się Sebastian Grzesik.

Bartek Podolski: Witam, Bartek Podolski.

Sebastian Grzesik: Witamy Was ponownie w Automation Talks. Tematem dzisiejszego podcastu będzie zarządzanie projektami IT. Brzmi to dość enigmatycznie. Pewnie część z Was ma doświadczenia z tą tematyką. Chcielibyśmy jednak poruszyć ten temat z perspektywy osiągania sukcesu. Porozmawiamy o tym, czym jest projekt IT, jakie znamy rodzaje tych projektów. Przeanalizujemy czas pandemii i wpływ pracy zdalnej na świat zarządzania projektami IT. Poruszymy tematy związane z agile oraz projektami typu waterfall. Porozmawiamy o tym głównie w kontekście projektu oraz produktu. Na samym końcu zdradzimy nasz secret source i powiemy, jak można skutecznie zarządzać projektami, aby odnosić sukcesy w branży IT. Tak więc zaczynamy!

Bartku, czym — Twoim zdaniem — jest projekt IT? Gdybyś miał w najprostszych słowach zdefiniować to pojęcie, to co byś powiedział?

Bartek Podolski: Cześć Sebastianie. Najpierw odniosę się do tego, co powiedziałeś na początku. Działając w IT, uważam że niemal każdy spotkał się z tego typu projektem. Nie wyobrażam sobie osoby pracującej w IT, która albo nie uczestniczyła w takim projekcie albo taki projekt w jakiś sposób na nią nie wpłynął. Myślę, że mnóstwo ludzi wie, czym jest projekt IT albo przynajmniej miała styczność z tego typu projektem. A czym jest projekt IT dla mnie? Z mojej perspektywy? Jeszcze na wstępie zaznaczę, że nie jestem Project Managerem. Co za tym idzie, moja perspektywa może być cenna, ponieważ brałem udział w wielu projektach IT w różnych konfiguracjach: byłem wykonawcą takich projektów, wdrożeniowcem, solution architektem, a teraz działam z poziomu executive, czyli doglądam projektów i sprawdzam, czy zmierzają one w dobrym kierunku. Wydaje mi się zatem, że mam szeroką perspektywę, natomiast niekoniecznie da się to włożyć w ramy Project Managera.

Wracając do Twojego pytania odnośnie tego, czym dla mnie jest projekt IT. Myślę, że jest to zestaw czynności i rzeczy, które się muszą zdarzyć, aby osiągnąć określony cel. Dla mnie projekt musi mieć określony cel, początek i koniec oraz powinien dostarczyć albo zbudować coś, co ma działać i generować dodatkową wartość.

Sebastian Grzesik: Jeszcze spróbuję to uzupełnić.

Bartek Podolski: Bo Ty chyba wiesz więcej, czyż nie?

Sebastian Grzesik: Nie wiem, czy wiem więcej, ale dodałbym jeszcze, że każdy projekt, nie tylko ten z branży IT, posiada również budżet. Może on mieć formę albo zasobów wewnętrznych (czasu, pieniędzy) albo zewnętrznego finansowania. Niemniej jednak jest to nierozłączny element każdego projektu.

Bartek Podolski: Jakkolwiek by na to nie patrzeć, budżet może się przejawiać także w zaangażowaniu pracowników, poświęconej przez nich energii czy czasu. Nie zawsze muszą to być pieniądze. Zgadzam się, że zawsze w jakiejś formie ten budżet się pojawia.

Sebastian Grzesik: Powiedzieliśmy sobie, że projekt IT to pewna encja, która posiada początek i zakończenie, zasoby albo w formie finansowej albo w formie ludzkiej...

Bartek Podolski: Oraz cel! Dla mnie to jest najważniejsza rzecz w projekcie. Bo trzeba wiedzieć, co chcemy zbudowa

Sebastian Grzesik: Gdybyśmy mieli spróbować stworzyć dla naszych słuchaczy mapę, to — z perspektywy typograficznej — jak odróżniłbyś projekty? Dla mnie podstawowym rozróżnieniem projektów IT niezależnie od tego, czy organizacja jest mniej lub bardziej innowacyjna, jest rozgraniczenie na projekty wewnętrzne, które dzieją się najczęściej wewnętrznymi zasobami i środkami oraz na projekty zewnętrzne, czyli takie, w których udział bierze więcej niż jedna firma. Dla mnie jest to jeden z najbardziej oczywistych podziałów, który można zastosować w kontekście projektów IT.

Bartek Podolski: Jeżeli mogę się do tego odnieść, to powiedziałbym, że projekty wewnętrzne są z reguły traktowane po macoszemu. Niestety, tak wynika z mojego doświadczenia.

Sebastian Grzesik: A jak myślisz, dlaczego projekty wewnętrzne są w ten sposób traktowane? I żeby była jasność: my nie uważamy tego za słuszne...

Bartek Podolski: Dokładnie, nie tak powinno być. Widzimy też wiele potrzeb i przypadków wewnątrz firm, kiedy te projekty powinny być traktowane co najmniej tak samo, jak projekty zewnętrzne dla klientów. Jednak nie oszukujmy się — tak nie jest. Ciągle żywa jest idea, zwłaszcza w korporacjach, traktowania pracowników wewnętrznych tak samo, jak klientów zewnętrznych. Jednak to jest tylko teoria. Praktyka jest inna. Do klientów ludzie podchodzą poważniej. Myślę, że w ludziach jest przekonanie, że wewnętrznie dostarczany projekt nie wymaga tak dużych starań. Być może jest on łatwiejszy do implementacji, bo zna się współpracowników, można się dogadać odnośnie do wymagań, nie ma tak ścisłej kontroli, budżety są mniej wyrażone w pieniądzach, a bardziej w czasie ludzi. Co za tym idzie, wszystko się rozchodzi. Pewnie zależy to od firmy, jednak widziałem kilka albo kilkanaście firm i z reguły te wewnętrzne projekty wyglądały właśnie tak kompletnie niekonkretnie.

Sebastian Grzesik: Widzimy tendencje rynkowe opisujące sposób traktowania projektów wewnętrznych jako te, które zazwyczaj mają nieco mniejszy priorytet. Jakbym miał odpowiedzieć na pytanie „dlaczego?”, to wydaje mi się, że jedną z przyczyn może być fakt, że jeśli projekt jest realizowany w kolaboracji i ta kolaboracja jest finansowana konkretnymi pieniędzmi, to przykładasz do niego większą atencję. Pracownik wewnętrzny też generuje koszty, ale najczęściej są one innego działu albo czegoś, co można nazwać „żywym accountem” lub „zbudżetowanym etatem FTE”. Co za tym idzie, jest to trudniejsze do policzenia. Myślę, że podobną analogię widzimy w firmach produkcyjnych, prawda? Jeśli takie firmy mają zatrudnionych pracowników na etacie, to mają też bardzo dużą trudność z rozliczaniem ich czasu pracy. Moim zdaniem jest to taka nie wprost analogia do kontekstu projektów IT. Kiedy realizujesz przedsięwzięcie biznesowe, nawet takie, które może być kluczowe dla organizacji, ale za pomocą zasobów wewnętrznych, które nie są traktowane wystarczająco dobrze, a ciężka i wymagająca praca jest niedoceniana, to możesz otrzymać niezadowalający efekt działań teoretycznie mających na celu wygenerowanie zysku lub pewną formę optymalizacji.

Bartek Podolski: Myślę, że wynika to z tego, że projekty wewnętrzne czy też rozliczanie wewnętrznego czasu pracy nie przekłada się bezpośrednio na wynik finansowy firmy. One się przekładają, ale tylko pośrednio i to jest za mało widoczne dla pracowników. Kiedy realizowany jest projekt zewnętrzny przynoszący realne pieniądze do firmy, to jest to bardziej zauważalne i motywujące niż realizacja projektu wewnętrznego, który usprawni na przykład realizację projektów później. Porównałbym to do przykładu z ekonomii okrężnych środków produkcji: można coś robić bezpośrednio albo stworzyć narzędzie wspomagające wytworzenie końcowego produktu bezpośredniego. Wiadomo, że z każdym kolejnym narzędziem będzie lepiej i prościej, ale wcześniej trzeba zainwestować. Z reguły człowiek jednak patrzy krótkowzrocznie, czyli zwraca uwagę na „tu i teraz” a nie na „później”. Taką mamy naturę i trzeba się pilnować, aby tworzyć coś, co nam pomoże w przyszłości. Trzeba też znaleźć teraz powód, aby inwestować czas i energię w tego typu rzeczy. Nie wiem, czy to odpowiada na Twoje pytanie…

Sebastian Grzesik: Myślę, że tak... Chciałbym jednak sięgnąć głębiej i zastanowić się wspólnie nad tym, jak typograficznie moglibyśmy opisać przebieg projektu. Z czego składa się projekt? Pomoże to nam przejść dynamicznie do elementu związanego z tym, w jaki sposób skutecznie prowadzić projekty. Rozumiejąc, z czego składa się projekt, łatwiej jest dostosować odpowiednie narzędzia. Chciałbym zatem sprecyzować i ustalić wspólny fundament tego, co Ty i co ja rozumiemy przez pojęcie projektu oraz z czego on dokładnie się składa. Osobiście zacząłbym klasycznie od fazy discovery. Nie wchodząc w szczegóły określania rodzaju czy stylu prowadzenia projektu, każde nasze zadanie, niezależnie od tego, czy wymieniamy żarówkę w żyrandolu, czy rozpoczynamy budowę domu, najczęściej rozpoczyna się od fazy researchu, analizy oraz ogólnie pojętego discovery. Próbujemy wtedy zrozumieć, z jaką materią mamy do czynienia. Nazwałbym to pierwszą fazą każdego projektu. Bardzo często, przy pracy z klientem, jest ona powiązana z procesem sprzedaży, Faza discovery jest realizowana zarówno z klientem wewnętrznym, jak i z klientem zewnętrznym. Jest to element odkrywczy oraz bardzo pasjonujący, bo wtedy może się wydarzyć bardzo wiele. Wtedy właśnie jesteś w stanie tak naprawdę najbardziej wpłynąć na wszystko to, co wydarzy się później.

Bartek Podolski: Tak, to jest ta faza, w której firma dostarczająca projekt stara się zrozumieć, co i jak trzeba zrobić, aby spełnić oczekiwania klienta. W tym czasie klient stara się zrozumieć koszty danego projektu oraz sprawdza, czy wybrana firma posiada zasoby potrzebne do zrealizowania projektu, czy jest ona w stanie podołać zadaniu. Myślę, że to jest bardzo ważny etap, który potem wpływa na dalszą współpracę.

Sebastian Grzesik: Można powiedzieć, że elementem fazy discovery jest dokument, raport lub oferta. Forma zależy od przyjętego modelu współpracy, jednak głównym celem jest podsumowanie działań na początkowym etapie.

Bartek Podolski: Później przeszedłbym do kolejnej fazy. Co prawda mam doświadczenie praktyczne, a nie teoretycznie, więc mogę mówić głupoty. Możesz mnie poprawiać, jeśli to, co mówię, nie pokrywa się z teorią. Jednak najczęściej obserwuję, że kolejna jest faza designu, czyli projektowania tego, co ma potem nastąpić. I ta sytuacja ma miejsce niezależnie od metodologii. Wiem, że w zarządzaniu typu waterfall te fazy wyglądają nieco inaczej, a czas projektowania niekoniecznie jest istotny. Natomiast myślę, że — przynajmniej w mojej pracy — jest to dość kluczowa faza, podczas której zastanawiamy się nad rozwiązaniem. Wtedy spotykamy się zewnętrznie z klientami oraz wewnętrznie na burzach mózgów i myślimy nad tym, jak wprowadzić projekt w życie, aby rozwikłać problemy oraz zaprojektować najlepiej działające, spójne i efektywne rozwiązania. Z własnych obserwacji wiem, że ważne jest też przygotowanie podsumowania poprzedniej fazy. Dobrą praktyką jest przekazać klientom i interesariuszom dokumenty opisujące to, w jaki sposób dane rozwiązanie będzie później działać. Warto też wtedy opisać zakres projektu. Tego typu podsumowanie pozwoli uniknąć późniejszych problemów związanych ze zmianą zakresu działań w projekcie.

Sebastian Grzesik: Podsumowując, ta faza designu jest tak naprawdę opracowaniem planu, tak?

Bartek Podolski: Dokładnie tak.

Sebastian Grzesik: Na tym etapie opisuje się sposób, w jaki sposób projekt ma zostać zrealizowany, jakimi zasobami, jakimi środkami oraz w jakim czasie będzie on ukończony.

Bartek Podolski: Patrzę na to z bardziej technicznej strony. Dla mnie jest to etap opisujący, co ma być końcowym rezultatem, jakie funkcjonalności powinny się pojawić. Czasem jest to też czas na przygotowanie technicznych specyfikacji. Jeżeli projekt miałby być realizowany za pomocą metodologii waterfall, to etap designu powinien być bardzo szczegółowy i z dokładnym opisem technicznym. Natomiast patrząc na projekt z perspektywy agile, to myślę, że dokładne określenie wszystkiego w tej fazie, a następnie zniknięcie na 5 miesięcy albo nawet na rok, aby coś zbudować nie zadziała. Wydaje mi się, że takie rozwiązanie nigdy nie zadziała i cieszę się, że agile został wymyślony.

Sebastian Grzesik: Warto podkreślić, że wszystko jest systemem naczyń powiązanych. Jeżeli jest dokumentowany rezultat, podpisywany zakres oraz definiowany sposób działania, a po 5 miesiącach jest spotkanie z klientem, to trzeba być przygotowanym na to spotkanie. Dokładnie taka sama sytuacja może mieć miejsce w momencie, kiedy jest pokazywany projekt budowlany albo urządzenia wnętrza, a później analizowane są tylko końcowe rezultaty.

Bartek Podolski: Niby tak, tylko tutaj jest trochę gorzej. Przy budowie grunt się nie zmienia co dwa tygodnie, technologia nie ewoluuje co trzy tygodnie a materiały, choć się zmieniają, to nie następuje to tak szybko, jak w IT. Kiedy ktoś mówi, że potrzebuje trzypiętrowego budynku, to jest mała szansa, że później powie, że potrzebuje tylko piwnicy. W projekcie IT taka sytuacja może się zdarzyć...

Sebastian Grzesik: Czasem zdarza się, że klienci życzą sobie, aby ten budynek lewitował...

Bartek Podolski: Tak albo nawet latał na księżyc. W związku z tym myślę, że w IT zmienność założeń projektowych jest znacznie większa niż w innych branżach. Wracając do tematu faz, to mamy zdefiniowane etapy discovery, design. A potem co?

Sebastian Grzesik: Development.

Bartek Podolski: Tak, czas budowy. Najlepiej jednak takiej, która jest przemyślana.

Sebastian Grzesik: To jest możliwe na podstawie dokumentacji lub planu.

Bartek Podolski: Dla mnie tutaj bardzo dobrze sprawdza się agile. W sumie jest to metodologia rozumiana jako iteracyjne budowanie końcowego rezultatu przy dużym współudziale klienta. Komunikacja, rozmowa, codzienna wymiana myśli między członkami zespołu, sprawdzanie tego, gdzie jesteśmy czy pokazywaniu tego, co właśnie zostało zbudowane — to są kluczowe działania, dzięki którym klient czy interesariusze mogą zweryfikować pierwotne założenia. Papier wszystko przyjmie i wiele różnych rzeczy można opisać w fazie designu. Natomiast rzeczywistość się zmienia. Budując rozwiązanie w sposób zwinny, unikamy pułapki, że stworzymy coś, czego nie chcemy. Znana jest analogia samolotu, który nie leci prosto do celu, tylko cały czas schodzi z kursu w lewo albo w prawo i ciągle jest naprowadzany. Z projektami agile jest podobnie, bo są one realizowane z odchyleniami. Jednak współudział klienta naprowadza na kurs i pozwala zbudować to, czego klient finalnie oczekuje.

Sebastian Grzesik: Tak, myślę, że to jest bardzo ważny punkt widzenia. Poza tym dajesz kontekst praktyczny.

Bartek Podolski: Chociaż nigdy nie byłem pilotem… Tylko czytałem, że tak jest.

Sebastian Grzesik: Kiedyś nie trzeba było zdobywać uprawnień, aby zostać pilotem. Mam też nadzieję, że w branży IT jeszcze przez długi czas pilotem pozostaniesz.

Bartek Podolski: Teraz podobno automaty latają częściej niż piloci. Kiedyś siedziałem koło pilota, który był pasażerem w samolocie. Mówił mi, że oni rzadko lądują samodzielnie. A im gorsza pogoda, tym bardziej automat steruje procesem lądowania. Myślałem, że jest odwrotnie...

Sebastian Grzesik: Formę autopilota znam tylko z żeglarstwa. Na łódkach czy jachtach ten autopilot jednak bardzo rzadko dobrze działa. Mam więc nadzieję, że w samolotach jest bardziej sprawdzona technologia…

Wracając jednak do kursu w fazie developmentu oraz metodologii agile, to jeszcze tylko dopowiem słuchaczom, że kiedy mówisz o agile, to pewnie masz na myśli kilka kontekstów. Sam agile jest tylko i wyłącznie formą manifestu i postawieniem głównej tezy. Są takie pojęcia, które przez dekady tworzenia oprogramowania były wspólnymi dużymi problemami projektów IT. Do takich bolączek zalicza się między innymi dokumentację, ścisłe podążanie za planem, narzędzia czy ciągłe negocjacje na linii klient-kontrakt. Agile zweryfikował te wszystkie trudności i utworzył manifest, który z jednej strony jest dość odważny, a z drugiej jest zbudowany na szeregu niepowodzeń w obszarze realizacji projektów IT. Jeszcze niedawno mówiło się, że między 80 a 90% projektów IT się nie udaje przez to, że nie są one podobne do budowy domu, a grunt może się zmieniać. Potrzeby klienta w świecie IT mogą bowiem być zupełnie inne na przykład w kontekście czasu. Technologie i innowacje mają zupełnie inną dynamikę niż świat fizycznych produktów. Dlatego właśnie pojawił się manifest agile i próba jego adopcji w formie przeróżnych frameworków. Myślę, że warto tutaj wspomnieć o scurmie, w którym najczęściej pracujemy razem z Bartkiem. Warto też tutaj wspomnieć o kanbanie, czyli podejściu silosowym, w którym nie ma iteracyjności, ale są ograniczenia ilości zadań, nad którymi się pracuje. W tym miejscu można też powiedzieć o podejściu typowo korporacyjnym, ponieważ scrum również znalazł swoje miejsce w dużych organizacjach. Dla tych bardzo dużych projektów IT od 2010 roku powstają trzy frameworki. Każdy z nich czerpał ze scruma, kanbana oraz pryncypiów agile. Był to safe, był to less i był to nexus. Pewnie o każdym z nich będzie w przyszłości szansa opowiedzieć. Natomiast z ciekawostek powiem, że kiedyś zdarzyło nam się razem z Bartkiem pracować dla klienta ze Skandynawii, który wykorzystywał metodologię zarządzania dużych projektów programem safe i tam kontekst iteracyjności był dualny. Z jednej strony były dwutygodniowe sprinty, za pomocą których dostarczano działające fragmenty oprogramowania. Z drugiej strony był kontekst dużych iteracji, które nazywały się release train. Aby zaplanować tego typu działania i dostarczyć dużą, w pełni działającą część funkcjonalności, co miesiąc albo raz na dwa miesiące projektowaliśmy bardzo duże fragmenty i iteracje. Wówczas powstawał workroom, gdzie planowało kilkanaście zespołów scrumowych i kanbanowych z dowolną ilością interakcji. Było to bardzo ciekawe doświadczenie, ponieważ jednym z obowiązków było fizyczne uczestnictwo w spotkaniach.

Bartek Podolski: Ile razy latałeś do Finlandii?

Sebastian Grzesik: Chyba ze 40 razy. Jeśli dobrze pamiętam, to było zorganizowanych 37 albo 38 spotkań w ciągu roku...

Po etapie developmentu mamy fazę, która różnie się nazywa z zależności od metodologii. W projektach zarządzanych metodą waterfall mamy etap testingu, z kolei w projektach prowadzonych według agile mamy mikroelement, który nazywa się UAP (ang. User Acceptance Test). Takie testy można robić albo w trakcie sprintów albo podczas zamknięcia bardzo dużej części funkcjonalności.

Bartek Podolski: Jeśli chodzi o testowanie, to nasza praktyka jest taka, że dużo testujemy i to jest dobre. Tak naprawdę testujemy w trakcie developmentu. Niemal na każdym kroku, w trakcie każdego sprintu chcemy, aby klienci przekazywali nam informacje zwrotne. Myślę, że tego testowania jest dużo. To jest dość istotna faza, która pozwala spać spokojnie w momencie przejścia na produkcję. Wiemy, że wtedy nie wydarzą się niespodzianki albo tragedie. Przy podejściu waterfall można założyć niemal z całkowitą pewnością, że nieplanowane sytuacje się pojawią. Takie jest moje doświadczenie w projektach IT. Tam, gdzie klient był blisko testowania, a projekt budowany był według agile, tym mniej było problemów na koniec i tym łatwiejsze było przejście w fazę produkcyjną i dostarczenie finalnego produktu.

Sebastian Grzesik: Można zatem powiedzieć, że mamy fazę discovery. Później mamy fazę planowania i opisywania naszego rozwiązania. Następnie jest faza developmentu, gdzie zespół ciężko pracuje nad dostarczaniem oczekiwanego rezultatu. Kolejna jest faza testingu, która może być połączona z fazą UAP, gdzie klient wewnętrzny lub zewnętrzny akceptuje proponowane rozwiązanie albo zespół dostosowuje te rozwiązanie po to, aby było finalnie zaakceptowane. A na sam koniec...

Bartek Podolski: ...szampany otwieramy! To jest czas na szampan, kolację, konfetti i wszystkie inne przyjemności pozwalające na świętowanie zakończenia projektu.

[29:53]

Sebastian Grzesik: Zanim przejdziemy do kolejnego tematu, to wydaje mi się, że warto wspomnieć, że po fazie uruchomienia produkcyjnego następuje etap business as usual. Ona często jest uzupełnioną formą gwarancji. Wówczas zespół, jako jednostka, zaczyna się rozwiązywać. Rozpoczynając projekt, nikt nie obiecuje zespołowi, że będzie cały czas razem pracować, przynajmniej w kontekście projektowym. Wtedy następuje defragmentacja i rozbiór tego zespołu.

Bartek Podolski: Myślę, że tutaj opisałeś idealną sytuację, Tak to powinno wyglądać. Oczywiście po go life trzeba zadbać o to, co się stworzyło. To jest czas na ewentualne poprawki lub ulepszenia. Myślę więc, że rozwiązywanie zespołu nigdy nie odbywa się tak zupełnie zero-jedynkowo. Natomiast mamy wtedy tak zwany scope fitting, którym się zabija nieudane projekty. Jednak to jest już trochę inny temat.

Sebastian Grzesik: Wracając do faz, to po go life przekazujemy projekt do supportu. W tym czasie zespół najczęściej przechodzi do innych projektów. I teraz jest ten moment, kiedy z poziomu ogólnego przechodzimy do szczegółów. Ponad rok temu branża IT zaczęła mierzyć się z dość sporym wyzwaniem. Wspomnieliśmy tutaj o wspólnym planowaniu, o podróży do klienta, o przekazywaniu do supportu. Jeszcze niedawno wszyscy byliśmy pozamykani w domach z rekomendacją, aby pracować zdalnie. Chciałem Cię tutaj zapytać, jak, Twoim zdaniem, praca zdalna wpłynęła na realizację projektów. Mam własne przemyślenia w tej sprawie, jednak chciałbym usłyszeć Twoje zdanie.

Bartek Podolski: Praktyka pokazała, że się da w ten sposób prowadzić projekty IT. Osobiście wolę spotkać się na miejscu, zwłaszcza z klientami. Preferuję sytuacje, kiedy zespół się widuję regularnie. Tutaj jeszcze wspomnę, że kiedy mówię o zespole, to nie mam na myśli jedynie osób dostarczających rozwiązanie. To jest współpraca i klientów i firmy, która dostarcza rozwiązanie. Tam musi być zaangażowanie po obu stronach i łatwiej jest się angażować, kiedy ludzie się znają, widzą i współpracują na miejscu. Natomiast praca zdalna jest czymś dobrym w IT. Wiemy, że da się to zrobić tak, aby to działało. Myślę, że są zespoły, które z sukcesem działają zdalnie. Jednak kluczem są odpowiedni ludzie — nie każdy się do tego nadaje, a sama praca jest utrudniona. Wydaje mi się, że największą bolączką pracy zdalnej jest brak możliwości wymiany myśli, spostrzeżeń czy pomysłów między pracownikami. Spotykając się, łatwiej jest nam wypracować rozwiązania czy końcowe rozwiązania. Nieświadoma wymiana spostrzeżeń i myśli tutaj bardzo pomaga: ktoś coś usłyszy, ktoś coś powie i nagle okazuje się, że inni mieli już ten problem i jakoś go rozwiązali. Wtedy współpraca jest bardziej efektywna. Zdalnie jest się ciężej spotkać się tak na 100%. W ogóle zastanawiam się, czy jest to możliwe.

Sebastian Grzesik: Mieliśmy szansę i wykorzystaliśmy ją bardzo dobrze, ponieważ praca zdalna z mojej perspektywy stała się trudniejsza. Chodzi mi o to, że praca w 100% zdalna nad projektami niesie za sobą — moim zdaniem — większe ryzyko dostarczenia projektu, który nie był oczekiwany lub dostarczania projektu w nieodpowiednim czasie albo przy nieodpowiednim budżecie, który wcześniej był zakładany. Moim zdaniem tych ryzyk jest więcej, ale nie dlatego, że mamy pracę zdalną, ale dlatego, że ludzie mają mniej interakcji między sobą. Interakcja międzyludzka w formie zdalnej była panaceum na zło, nawet małżeństwa odbywały się w formie zdalnej. Niemniej jednak ludzie naturalnie dążą do tego, aby interakcje się odbywały w inny sposób. Z drugiej strony widzę ogromną szansę dzięki narzędziom. Jeżeli mamy zdalne komunikatory, czaty, video, systemy do zarządzania zadaniami i projektami, takie jak: Jira, Slack, Tello, to po prostu praca staje się łatwiejsza. Ekosystem narzędzi znacząco nam ułatwił zarządzanie pracą. Natomiast w przypadku relacji z klientem, która jest najtrudniejsze i niekoniecznie praca zdalna zdała egzamin. O ile relację pomiędzy współpracownikami da się na odpowiednim etapie uzupełnić za pomocą narzędzi czy sposobie komunikacji przez Project Managera lub Scrum Mastera, o tyle kolaboracja z klientem jest najtrudniejszym elementem w kontekście pracy zdalnej. Tak, jak Tobie brakowało mi przez długi czas, szczególnie na wstępnych etapach projektu tego personalnego kontaktu, którego nie da się zastąpić czy utrzymać na takim samym poziomie w formie spotkania online. Oczywiście zdajemy sobie sprawę, że tutaj mówimy pod prąd dla większości też o branży IT, ale moim zdaniem tak właśnie jest. Kontakt personalny i bezpośredni z klientem, wspólne planowanie, dobre zrozumienie celów biznesowych jest bardzo wartościowe i na pewno ten kontakt fizyczny to ułatwia.

Bartek Podolski: Nie wiem, czy Twoje zdanie jest pod prąd. Nie znam w ogóle statystyk na ten temat. Natomiast podsumowując dyskusję, chciałbym powiedzieć, że w tej chwili mamy najlepsze z dwóch światów, czyli możliwość spotkań tradycyjnych połączoną z dość dobrze przećwiczoną pracą zdalną. Jesteśmy dobrze wyposażeni na przyszłość i wydaje mi się, że hybrydowy model pracy działa dobrze. Pracując zdalnie można, na przykład, pracować dłużej.

Sebastian Grzesik: Tak, to może być dość przekonujący argument… Na zakończenie chciałem Ci jeszcze zadać pytanie: co Twoim zdaniem pomaga w tym, aby projekt IT się udał? Co przeszkadza w tej kwestii? Chciałbym zrozumieć Twoje najlepsze techniki i doświadczenia, z którymi się zetknąłeś, a które pomogły Ci w zrealizowaniu z sukcesem projektu. Z drugiej strony, chciałbym dowiedzieć się, czego unikać w procesie przygotowywania projektu IT i jego realizacji? Czego unikać, aby projekt się udał?

Bartek Podolski: Myślę, że wrócę na chwilę do projektów zwinnych i kaskadowych. Wydaje mi się, że aby projekt się udał, to musi być wystarczająca ilość elementów zwinnych. Mam tutaj na myśli przede wszystkim współpracę i bliskość interesariuszy, klientów i ludzi, którzy coś dostarczają. Jednak musi to być budowane iteracyjnie. Według mnie nie można zakładać podejścia big bang, czyli wielkiego designu oraz budowania wielkiego projektu, który zostanie dostarczony na sam koniec. Czasem w rozmowach z klientami słyszę niepewność odnośnie do zakupu jakiegoś rozwiązania, zwłaszcza jeśli do 5 lat planują wdrożenie wielkiego systemu, który rozwiąże wszystkie problemy. Wtedy sobie myślę, że 5 lat to jest bardzo długi okres czasu, którego nie potrzeba na wdrożenie. W takich sytuacjach myślę, że to nie może się udać. Podejście polegające na zebraniu wymagań, napisaniu najlepszego dokumentu, a potem zniknięciu na kilka tygodni, miesięcy, a nawet lat, i pojawienie się z gotowym rozwiązaniem nie może się udać. Podsumowując, aby projekty się udały, to muszą mieć możliwie największą ilość elementów z metodologii agile. Tutaj jeszcze dodam, że agile ma trochę baśniowości w sobie. Może się wydawać, że żyjemy w świecie, w którym są dostępne zasoby, każdy z nas może wybrać, co chce robić, a ludzie za to nam zapłacą, przez co nie myślimy o budżecie. Z mojej perspektywy taki stan rzeczy też nie działa poprawnie. Każdy chce wiedzieć, ile dane rzeczy będą kosztowały i ile czasu trzeba na nie czekać. Jeżeli jest forma iteracyjności, współpracy i pokazywania tego, co się dostarcza, a także korygowania kursu, przy którym pracujemy, to dopiero wtedy projekt się uda.

Sebastian Grzesik: Dodam jeszcze ze swojej strony, że razem z Bartkiem bardzo wierzymy w pryncypia związane z ograniczoną ilością dokumentacji, z ludźmi, interakcjami między nimi i ich wspólnymi działaniami ponad procesami czy narzędziami. Wierzymy w to, że da się dostarczać działające fragmenty danego projektu w iteracyjny sposób. Co więcej, mogą one działać, nawet przed dokumentowaniem i specyfikowaniem. Ze swojej strony dodam też jeszcze, że jedną z lepszych praktyk tworzenia projektów z sukcesem, to właściwe zamykanie i dokańczanie projektu. Często spotykamy się z sytuacją, kiedy mamy wrażenie, że projekt nigdy się nie kończy. Czasem pojawia się nowy budżet albo inne dodatkowe zasoby czy wymagania, przez co cały czas pracujemy nad tym projektem. Literatura i praktyka mówią, że dobry projekt to projekt skończony, zamknięty, z wyciągniętymi wnioskami. Co ważne, tego rodzaju projekty mogą przechodzić do fazy serwisowej lub mogą być transformowane w produkt. W takim momencie Product Owner nie jest odpowiedzialny  już tylko za proces wytwarzania i dostarczania, ale również za rezultat. To, co często zabija projekty po ich zakończeniu, to brak właściciela. Praktyka pokazuje, że późniejsza praca nad projektem w formie produktowej i przekształcenie zespołu projektowego w zespół produktowy to już praca na zupełnie innych celach, na ROI, revenue i innych mierzalnych i ilustrujących współczynnikach. I wierzymy, że tego rodzaju podejścia mogą się sprawdzić w Waszych organizacjach.

Dziękujemy za Wasz czas. Bartku, dziękuję za rozmowę. Do usłyszenia!