Co robi typowy PM w typowej firmie z typowej branży? 

Typowy PM w firmie nienależącej do branży IT – zarządza projektem. Tylko tyle i aż tyle. Wykonuje działania, które w większości oparte są o komunikację ze wszystkimi uczestnikami projektu. Nie ma znaczenia, czy projekt jest związany z IT czy nie.

GŁÓWNE ZADANIE JEST ZAWSZE TAKIE SAMO: maksymalnie efektywnie doprowadzić projekt do końca, mieszcząc się przy tym w określonym czasie, budżecie i zakresie. 

W realizacji zadań Project Managerowi pomagają metodyki, narzędzia i technologie odpowiednio dobrane do specyfiki branży, firmy czy samego projektu. 

Specyfika pracy w firmie zajmującej się DevOps 

W tym miejscu warto zaznaczyć, że firmy zajmujące się usługami DevOps/SysOps, przynajmniej te o odpowiedniej skali, przywiązują dużą wagę do kwestii: 

• bezpieczeństwa,
• automatyzacji,  
• dobrych praktyk IT  
• i standaryzacji procesów.  

Co to oznacza dla Project Managera? 

To, że projekty muszą być wdrożone nie tylko zgodnie z wymaganiami klienta, lecz również z wymaganiami wewnętrznymi. Powinny być odbierane zewnętrznie, ale i wewnętrznie, ponieważ większość projektów po przejściu w fazę utrzymania trafia pod opiekę tej samej firmy.  

Każdy pracownik działu IT Delivery musi również:
 

• być zaznajomiony z podejściem secure by design, 
• znać dobre praktyki (ITIL),  
• znać wewnętrzne standardy projektowania infrastruktury i środowisk.  

Tylko wtedy projekt ma szansę stać się bezpieczny i łatwy w późniejszym utrzymaniu, co jest kluczowe z punktu widzenia klienta. 

Co robi PM w firmie devopsowej?  

Co najmniej 6 różnych rzeczy: 

1) Zbiera wymagania projektowe 

Choć klientem końcowym jest zawsze biznes, to głównym interesariuszem projektu jest osoba techniczna (developer, zespół programistów). Jeśli PM posiada techniczny background, to obie strony mogą komunikować się w żargonie technicznym, mając pewność, że zostaną zrozumiane.  

PM powinien znać nie tylko podstawową, ale i zaawansowaną terminologię z zakresu usług IT świadczonych przez jego firmę. To pozwala mu przekształcić ustalenia w konkretny task do wykonania w backlogu. Pomaga również sprecyzować definition of done. Wymagania powinien oczywiście zbierać ktoś taki jak Tech Leader czy Senior DevOps Engineer. Tym niemniej dobre zrozumienie tematu przez Project Managera jest tutaj kluczowe z racji jego komunikacyjno‑dokumentacyjnej roli. 

2) Planuje, budżetuje, przygotowuje harmonogram 

Po zebraniu wymagań należy je wycenić i zaplanować w czasie. W przypadku zadań technicznych decydujący głos należy do Tech Leada lub osoby z największym technicznym seniority w projekcie. Wpływ na ten proces ma jednak również Project Manager, czyli osoba, która rozumie biznes i potrafi analizować ryzyko. PM potrafi również autonomicznie podjąć decyzję o tym, czy dany task należy włączyć do zadań typu must have, czy go z nich wyłączyć. Odbywa się to niekiedy intuicyjnie, na podstawie doświadczenia zawodowego lub dzięki umiejętnościom miękkim PM‑a. 

Osoby techniczne, dysponujące ograniczoną wiedzą o całości projektu, mogą nie być w stanie samodzielnie podejmować takich decyzji. Mogą wręcz nie wpaść na to, że zmiana priorytetu w danej kwestii jest realna. 

3) Komunikuje i raportuje 

Komunikacja z zespołem projektowym czy zewnętrznymi interesariuszami to kluczowa część pracy każdego Project Managera. Aby zapewnić maksymalną efektywność pracy zespołu, musi być ona techniczna, by zespół nie musiał tracić czasu na tłumaczenie podstawowych zagadnień. Warto dodać, że dużo łatwiej jest wytłumaczyć kwestię techniczną klientowi, jeśli posiada się odpowiednią wiedzę na jej temat.  

Doskonale ilustrują to słowa Alberta Einsteina:  

„Jeżeli nie potrafisz czegoś prosto wyjaśnić, to znaczy, że niewystarczająco to rozumiesz”.  

4) Prowadzi dokumentację projektową 

Project Manager zaangażowany w prowadzenie dokumentacji potrafi, dzięki odpowiednim umiejętnościom miękkim, ubrać ją w zrozumiały język oraz czytelniejsze rysunki i grafy. Zdarzało mi się dostać od techników odręczny szkic infrastruktury klienta zawierający np. schemat połączeń sieciowych, który na pierwszy rzut oka był po prostu nieczytelny i niezrozumiały dla osób o mniejszej wiedzy technicznej. Oczywiście to nie jest zarzut w stronę tych osób! Osobiście wolę, żeby technik dostarczał jak najszybciej działające oprogramowanie niż dopracowany w każdym calu schemat infrastruktury. 

5) Zarządza backlogiem w trakcie projektu, zajmuje się „wrzutkami” od klienta 

Tak jak nigdy nie ma projektu bez tzw. „wrzutek” i modyfikacji, tak samo nie da się wszystkiego zaplanować na samym początku.  Nie można umiejętnie zarządzać „wrzutkami” od klienta, nie mając przynajmniej częściowej wiedzy na temat ich potencjalnej czasochłonności oraz realnego znaczenia dla projektu.  

Dobry PM potrafi odróżnić „wrzutki”, które są naprawdę ważne i na które musi znaleźć się miejsce, od tych, które są nieprzemyślane lub mogą zostać zrealizowane w kolejnej części projektu, a nawet po starcie produkcyjnym. 

6) Zamyka i rozlicza projekt 

Oprócz kwestii czysto formalnych i finansowych (np. zamknięcia, udokumentowania, końcowego rozliczenie projektu z klientem) równie istotne jest wyciąganie wniosków, dzięki którym będzie można jeszcze bardziej profesjonalnie prowadzić projekty w przyszłości.  

PM z backgroundem technicznym nie tylko będzie mógł wyciągnąć wnioski na temat metodyki czy procesu, ale też wskazać zespołowi R&D swoje uwagi: 

• gdzie pojawiły się kłopoty techniczne,  
• gdzie brakowało umiejętności,  
• a co warto byłoby podszkolić. 

Z jakimi zadaniami nietechniczny PM da sobie świetnie radę? 

Istnieją jednak takie zadania w firmie oferującej usługi DevOps, które nie wymagają wiedzy technicznej od Project Managera. Należą do nich między innymi:  

• rozliczenia z klientem, 
• odpowiadanie na pytania typu “how progress”, 
• nadzorowanie terminów 
• przekazywanie informacji bez wstępnej interpretacji. 

8 wniosków dla e‑commerce managera 

Dlaczego więc w firmie devopsowej warto zatrudnić technicznego Project Managera?
Ponieważ osoba taka będzie:  

1) kimś więcej niż tylko automatem do pingowania zgłoszeń, 

2) miała pewność, że projekt nie ma błędów w założeniach, 

3) potrafiła samodzielnie przeprowadzić rozmowę z klientem, 

4) oszczędzała czas własnego zespołu projektowego na wykonywanie tasków oraz pieniądze klienta, ponieważ nie trzeba będzie jej wszystkiego tłumaczyć „od zera”,

5) lepiej i szybciej zarządzała priorytetami, 

6) sprawniej reagowała na zmiany i ryzyka, 

7) bardziej harmonijnie łączyła świat biznesowy z technicznym, 

8) skuteczniej rozmawiała z klientem.

Podsumowując, Project Manager w firmie świadczącej usługi DevOps powinien być osobą z backgroundem technicznym. Tak będzie lepiej.  

Dla wszystkich.