Schemat PMI Talent Triangle® określa grupę pożądanych kompetencji dziedzinowych obejmującą metody, procesy i narzędzia zarządzania projektem jako tzw. Technical Project Management. Wydawać by się mogło, że „techniczność” Project Managera (PM) skupia się na znajomości metod i narzędzi, na przykład do zarządzania zakresem, budżetem czy ryzykiem. Jednak rzeczywistość rynku pracy w branży IT pokazuje inny obraz, gdzie Technical Project Manager to często ktoś pomiędzy managerem a programistą.
W organizacjach widoczne są zmiany polegające zarówno na tworzeniu bardziej specjalistycznych stanowisk technicznych (np. DevOps Engineer, AI/ML Engineer), jak i stanowisk hybrydowych, gdzie kompetencje managerskie czy liderskie uzupełniane są o te związane z technologiami i procesami do tej pory „zarezerwowanymi” dla ekspertów technicznych. Wśród tych profesji znalazł się także Project Manager, odmieniany w ostatnich latach przez wszystkie przypadki.
Oczekiwania pracodawcy
Analizując rynek pracy w branży IT w kontekście Project Managera, widoczna jest tendencja do łączenia u idealnego kandydata kompetencji miękkich z technicznymi. Wśród stanowisk bezpośrednio nawiązujących do zarządzania projektami znajdziemy na przykład Technical Project Manager (TPM), IT Project Manager, czy Software Project Manager. Wszystkie mają jeden czynnik wspólny – powiązanie z technologią. Stopień tego powiązania jest zależny od organizacji i nie istnieje referencyjny zakres kompetencji Technicznego Project Managera. Wśród oczekiwanych kompetencji znajdziemy między innymi: czytanie dokumentacji technicznej, praktyczne doświadczenie w analizie biznesowej i projektowaniu systemów IT, ale także czytanie kodu źródłowego, znajomość działania protokołów komunikacyjnych czy nawet wcześniejsze doświadczenie w programowaniu. Obraz dzisiejszego TPM jest zatem niespójny i mocno zależny od kontekstu danej organizacji.
Technologia dla bystrzaków
W organizacjach przyjmujących podejście zwinne do wytwarzania produktów IT, ale także do sposobu zarządzania, widać zmianę polegającą z jednej strony na zbliżaniu ekspertów technicznych (np. programistów) do tzw. biznesu i użytkownika, a z drugiej strony zbliżanie managerów.
Czy przypadkiem pominąłem kierownika projektu w poprzednim akapicie? Przecież w praktyce to kierownik projektu idzie na Zarząd z wnioskiem o uruchomienie projektu! Postawmy się w roli Sponsora projektu i odpowiedzmy sobie na pytanie, czy chcemy, aby nasz projekt prowadził efektywny organizator, który zaplanuje i dowiezie prace w projekcie, czy ekspert od rynku, branży i biznesu, który prowadzimy? Najlepiej oczywiście obu, ale jeżeli mielibyśmy wybrać? Wiele organizacji zwiększa swoje oczekiwania w stosunku do kierownika projektu i oczekuje od niego również zajęcia się aspektami uzasadnienia biznesowego, kreując kierownika projektu na menedżera ds. rozwoju biznesu. Jest to bardzo wygodne podejście (szczególnie dla Sponsorów, Właścicieli Departamentów czy Właścicieli Produktów), ale czy rzeczywiście chcemy zdjąć tę odpowiedzialność z innych ról i oczekiwać jej od kierownika projektu? Do projektów potrzebujemy efektywnego organizatora! Oczywiście takiego, który rozumie uzasadnienie biznesowe realizowanego przedsięwzięcia do ekspertów i zagadnień technicznych. W przypadku ekspertów technicznych polegać może to na próbie aktywnego włączenia ich w proces definiowania zakresu projektu, który realizują. Zaangażowanie tych osób może odbywać się przez zachęcanie do uczestnictwa w bezpośrednich spotkaniach z klientem lub użytkownikiem. W ten sposób eksperci techniczni uczą się rozmawiać językiem wartości biznesowych i językiem użytkownika. Działania te sprawiają, że lepiej rozumieją i identyfikują się z tym, co wytwarzają (np. funkcjonalność w systemie IT wspierająca dany proces biznesowy). Jak zatem wygląda zbliżanie Project Managerów do ekspertów i zagadnień technicznych? Kiedy Project Manager staje się Technical Project Managerem?
Język obcy – techniczny
Odpowiedzi na to pytanie trzeba szukać w jednym z kluczowych czynników sukcesu każdego projektu – komunikacji. Transparentna komunikacja w projekcie wychodząca poza ustalone silosy kompetencyjne wynikające z przyjętego w organizacji podziału stanowisk powoduje zwiększanie wiedzy i umiejętności wszystkich osób w nią zaangażowanych. Jeśli podzielimy wybrane czynności, znajomość możliwości narzędzi ciągłej integracji i dostarczania tzw. CI/CD).
Nie oznacza to jednak, że od TPM wymaga się wcześniejszego doświadczenia w programowaniu lub projektowaniu systemów IT. Sama umiejętność zadawania odpowiednich pytań natury technicznej stanowi dużą wartość dla zespołu projektowego. Pytań, na które często zespół znajdzie odpowiedzi samodzielnie.
Przychodzi programista do (T)PM-a
Przeanalizujmy następującą sytuację: zespół programistów konsultuje z Project Managerem potrzebę tzw. refactoringu kodu źródłowego systemu IT. Świadomy technologii (Technical) Project Manager wie, że refactoring to działanie zmierzające do poprawy jakości wewnętrznej produktu, a w efekcie pozytywnie wpływające na późniejszy koszt utrzymania i rozwoju systemu. Ten sam Project Manager wie, że to działanie niesie za sobą pewne ryzyko, ponieważ nie jest ono widoczne i wartościowe z punktu widzenia użytkownika (klienta), nie dając przyrostu funkcjonalnego ani zmian niefunkcjonalnych związanych ze zwiększeniem wydajności czy niezawodności systemu. Decyzja o zakresie tego działania powinna być świadoma i wypracowana razem z zespołem na bazie realnych potrzeb. W tej sytuacji poprawione mogą zostać jedynie wybrane elementy systemu, które potencjalnie będą rozwijane w przyszłości. TPM podejmuje decyzję rozumiejąc cel i konsekwencje refactoringu, znając jednocześnie potrzeby biznesu dotyczące planów dalszego rozwoju produktu, kosztu i czasu takiego działania oraz ryzyko ewentualnego opóźnienia w projekcie. Wniosek: Technical Project Manager powinien swobodnie rozmawiać z ekspertami technicznymi i podejmować trafne decyzje projektowe w wyniku tych rozmów.
Rozumiejący niepraktykujący
Czy można zostać Technical Project Managerem nie mając doświadczenia związanego bezpośrednio z daną technologią czy z procesem wytwarzania oprogramowania? Odpowiedź na to pytanie jest mocno zależna od kontekstu organizacji. W środowisku, w którym podejmowanie strategicznych decyzji dotyczących aspektów technicznych projektu wspierane jest na przykład przez architektów IT lub liderów technicznych (tzw. Tech Lead) udział TPM w podejmowaniu tych decyzji, a tym samym konieczność dogłębnego zrozumienia technologii, może być ograniczony. W niedoświadczonych zespołach lub w projektach, w których nawet niewielkie decyzje związane z doborem lub specyficznym wykorzystaniem konkretnej technologii wpływają znacząco na projekt, kompetencje techniczne TPM w tym zakresie stają się kluczowe.
W każdym z tych przypadków, TPM powinien znać możliwości konkretnej technologii i konsekwencje jej zastosowania. Nie ma co się oszukiwać, praktyczna znajomość technologii, procesów i narzędzi związanych z wytwarzaniem produktów IT zdecydowanie pomaga ułatwiając między innymi:
- komunikację z ekspertami (np. znajomość formalnych i nieformalnych notacji graficznych do schematycznego przedstawienia zagadnienia technicznego),
- zrozumienie struktury (Z jakich elementów składa się system?) oraz dynamiki systemu (W jaki sposób działa system?),
- świadome zarządzanie zakresem (np. współtworzenie driverów architektonicznych, zarządzanie wymaganiami, zrozumienie różnicy w postrzeganej a rzeczywistej złożoności zagadnienia technicznego),
- świadome zarządzanie jakością (np. zarządzanie długiem technologicznym, zrozumienie procesów zapewnienia i kontroli jakości QA),
- określanie wymagań i możliwości w zakresie skalowania, bezpieczeństwa i niezawodności tworzonego systemu (np. aspekty wirtualizacji, konteneryzacji, wykorzystania rozwiązań chmurowych),
- optymalizację procesów wytwórczych w celu redukcji marnotrawstwa (np. wdrażanie praktyk i narzędzi automatyzujących wybrane czynności, znajomość możliwości narzędzi ciągłej integracji i dostarczania tzw. CI/CD).
Nie oznacza to jednak, że od TPM wymaga się wcześniejszego doświadczenia w programowaniu lub projektowaniu systemów IT. Sama umiejętność zadawania odpowiednich pytań natury technicznej stanowi dużą wartość dla zespołu projektowego. Pytań, na które często zespół znajdzie odpowiedzi samodzielnie.
Podsumowanie
W projektach IT tradycyjny podział na „biznes” i „technologię” przestał być aktualny, a łączenie kompetencji miękkich, organizacyjnych z twardymi, inżynieryjnymi nikogo nie dziwi. Przy powszechnym stosowaniu zwinnych praktyk (Scrum, XP, Kanban), wzrasta potrzeba samoorganizacji zespołów, gdzie uzupełnianie luk kompetencyjnych powinno odbywać się w sposób organiczny i stymulowany przez jego członków. Dotyczy to także Project Managerów w kontekście zgłębiania wiedzy o technologiach wykorzystywanych w projektach, którymi zarządzają. Wiedza techniczna umożliwia podejmowanie przede wszystkim bardziej świadomych, szybszych i obarczonych mniejszym ryzykiem decyzji. Niwelowanie bariery „językowej” pomiędzy PM a ekspertami technicznymi jest tutaj kluczowym i pierwszym elementem zmiany do wdrożenia. Świadomi i rozumiejący potrzeby biznesowe inżynierowie wraz ze świadomym technologii Project Managerem wydają się przepisem na idealny zespół projektowy. Uważajmy tylko… żeby nie zamienić się rolami.
Lead IT Architect i Team Leader zespołu programistów w ITTI sp. z o.o. Z wykształcenia informatyk, z zamiłowania tłumacz pomiędzy światem biznesu i technologii. Od ponad 11 lat wspiera zespoły deweloperskie w różnych rolach – architekta IT, analityka systemowego, Technical Project Managera i Product Ownera. Uczestnik wielu projektów komercyjnych i badawczo-rozwojowych Europejskiej Agencji Kosmicznej, Europejskiej Agencji Obrony czy Komisji Europejskiej. Aktywny członek grupy zajmującej się zwinną transformacją firmy. Miłośnik rysowania wszelkiego rodzaju schematów i diagramów.