Czego programiści oczekują od PM, a PM od programistów

Zespoły, w których członkowie próbują z zasady dokuczać sobie nawzajem raczej nie istnieją. Jednak często zdarza się, że PM i programiści przysparzają sobie nawzajem dodatkowego stresu. Konflikty powstają z powodu nieuzasadnionych oczekiwań i niezrozumienia roli każdego uczestnika.

Dlatego w artykule «przyjrzeliśmy się problemowi z obu stron» — pokrótce przedstawiono zadania programistów i PM nad projektem. Oprócz opisu obowiązków, w artykule wyjaśniono, w jaki sposób menedżer projektu powinien wyznaczać zadania i jakich informacji udzielać, aby zespół pracował płynnie i przejrzyście.

Wskazówki zostały oparte na praktycznym doświadczeniu naszych rozmówców: Project/Product Managera Denisa Shamantazhi i Tech Lead Leonida Neugodnikova.

Czym się zajmuję PM przy projekcie

Zadaniem PM jest realizacja pomysłu klienta wraz z zespołem. W tym celu PM wykorzystuje wszystkie swoje umiejętności menedżerskie, zarządzając różnymi komponentami projektu. Obowiązki kierownika projektu:

• Budżet: ile pieniędzy musisz wydać na opracowanie iteracji wydania dla pewnej funkcji.
• Czas: jak szybko PM może uzyskać pożądaną funkcjonalność. W niektórych projektach terminy nie są z niczym związane: możesz to zrobić «nie do środy, ale do piątku» — i nic złego się nie stanie. W innych — stosunek do terminów jest bardzo poważny, ponieważ terminy są «związane» z procesami marketingowymi lub PR klienta.
• Funkcjonalność dostawy: PM musi szybko podjąć decyzję dotyczącą funkcjonalności, gdy jeden z właścicieli lub inwestorów powie: «Zrób cokolwiek, ale musimy uruchomić produkcję do środy».
• Oczekiwania: Menedżer projektu musi zmierzyć się nie tylko z oczekiwaniami klienta, ale także z oczekiwaniami przełożonych i zespołu.
• Interakcja wewnątrz zespołu: zapewnienie efektywności i spójności pracy wszystkich członków zespołu — jest również zadaniem PM.
• Zasoby: świadomość tego, ile osób PM potrzebuje w danym momencie i zapewnienie projektowi tych zasobów.
• Planowanie zadań: wszystko dotyczące klasycznego Scrum-a: planowanie, realizacja, demo, retrospektywy. Wyznaczenie najbliższego zakresu, zgłoszenie go zespołowi, ułatwienie i minimalizacja ryzyka.
• Raportowanie projektu: zarządzanie dokumentacją.

Okazuje się, że praca PM polega na rozwiązaniu jak największej liczby zadań w ciągu dnia. Programista ma inny cel: wykonać jedno zadanie na raz z maksymalnym rezultatem. Dlatego skuteczność PM polega na wielozadaniowości, podczas gdy programista koncentruje się na jednym procesie.

Co na pewno powinien robić Tech Lead

Dla leada zakres codziennych zadań w zespole będzie znacznie szerszy niż dla developera. Oprócz pisania kodu odpowiada za:

• Code review z zespołem: pozwala uniknąć koncepcji «code owner», ponieważ wszyscy zaangażowani w rozwój widzą kod i rozumieją, co się dzieje. Jeśli ktoś zachoruje, łatwiej będzie znaleźć zastępcę. To lider jest odpowiedzialny za jakość kodu, więc szczegółowo podchodzi do przeglądu kodu i decyduje, ile poprawek jest potrzebnych, aby code review mógł trafić do produkcji.
• Wsparcie jakości kodu: dzięki code review, zautomatyzowanym narzędziom, które sprawdzają jakość kodu w oparciu o predefiniowane metryki.
• Planowanie zadań/terminów, czyli kosztorysy w klasycznym sensie. Lead lub programista musi uczestniczyć w planowaniu zadań wraz z PMem, ponieważ nawet najprostsze zadanie techniczne może mieć nieoczekiwane konsekwencje. Lead może przewidzieć potencjalne problemy, zanim się pojawią, a brak jego udziału w planowaniu może skutkować rozwiązaniem w stylu konstruktora, który próbuje dopasować trójkąt do okrągłego otworu.
• Wybór technologii/architektury: z czego będzie się składać aplikacja, jak będą współdziałać jej komponenty.
• Koordynacja interakcji technicznych: Tech Lead decyduje, kiedy funkcja jest uważana za gotową do testowania, co dokładnie powinni sprawdzić QA, które komponenty kodu muszą zostać objęte unit-testami.
• Zarządzanie długiem technicznym: dług techniczny — to rozwiązanie, które na początku działało dobrze, ale teraz należy je poprawić, ponieważ nie pasuje do obecnego stanu projektu. Dług techniczny i tak się pojawi, to tylko etap rozwoju, konsekwencja tego, że ludzie piszą kod. Dlatego jednym z zadań leada jest zarządzanie długiem technicznym w projekcie.
• Podział zadań: oprócz tego, że na juniora nie zrzucamy poważnych zadań, pojawia się również pojęcie ekspertyzy: lead wie, kto w zespole lepiej radzi sobie z systemami płatności, kto lepiej zna się na obróbce zdjęć , kto lepiej radzi sobie z  długiem technicznym — i odpowiednio rozdziela zadania.
• Wsparcie klimatu w zespole: lead wraz z PM wchodzi w interakcję z członkami zespołu deweloperskiego i dba o to, aby wszyscy dobrze się czuli w pracy, nikt nie został pominięty.
• Rozmowy kwalifikacyjne z potencjalnymi pracownikami: bez względu na to, jak doświadczony jest rekruter firmy, to właśnie lead jest osobą, która zadaje kandydatowi niezbędne pytania techniczne i podejmuje ostateczną decyzję, czy nowy pracownik będzie pasował do zespołu.

Jeśli w zespole nagromadziło się zbyt wiele zadań, terminy gonią, lub pojawił się zupełnie nowy projekt, to część pracy leada może przejąć menedżer projektu.

PM nie zajmuje się sprawami czysto technicznymi, ale może: wchodzić w interakcje z zespołem, rozdzielać zadania w zespołach technicznych, utrzymywać wewnętrzny klimat, podejmować niektóre czynności związane z rekrutacją kandydatów na wolne stanowisko.

Jak PM przydziela zadania programistom

Aby programiści poprawnie zrozumieli zadanie i dobrze je wykonali, ważne jest nie tylko «opisanie» wymagań, ale uwzględnienie kilku warunków. Ułatwia to wszystkim pracę, a proces tworzenia produktu przebiega szybciej.

Co powinno znaleźć się w zadaniu, aby programista wykonał pracę z entuzjazmem i zrozumieniem:

• Treść zadania jest najważniejszym punktem. Kiedy PM mówi, że zadanie brzmi «Zmień kolor przycisku na ekranie», programista nie rozumie: «Na jaki kolor zmienić, na którym ekranie, który przycisk?» Treść zadania powinna być wyczerpująca, zawierać definition of done lub skrypty, które odróżniają zadanie zakończone od zadania nieudanego. Jasne kryteria pozwolą ci zrozumieć, że zadanie zostało wykonane, a ponadto zostało wykonane poprawnie.
• Terminy — kiedy zadanie powinno zostać wykonane.
• Priorytety — świadomość tego, w jakiej kolejności programista musi wykonywać codzienne zadania.
• Interakcja z resztą członków zespołu — ważne jest, aby backend rozumiał, kto opracuje frontend dla tej funkcji, aby omówić i zrozumieć, jak skleić pracę w całość.
• Zrozumienie celu zadania. Zarówno lead, jak i programista są w stanie zrozumieć potencjalne problemy i zagrożenia związane z funkcją, której firma nie widzi. Dlatego zawsze konieczne jest przekazanie programistom znaczenia zadania: jaką potrzebę biznesową lub problem użytkownika rozwiązuje produkt. W przeciwnym razie możesz otrzymać kilka błędów, których można było uniknąć od samego początku dzięki odpowiedniej komunikacji.
• Bufor czasu na bugi/infrastrukturę. Ludzie popełniają błędy po prostu dlatego, że są ludźmi, więc bugi i tak się pojawią — jest to nieunikniony proces rozwoju. PM musi mieć pewien margines czasu na naprawienie błędów.
• Przejrzystość procesu. Jedna z najważniejszych rzeczy. Jeśli wyobrazisz sobie standardową tablicę w Jira, w której bilety przesuwają się od lewej do prawej, to proces jest absolutnie przejrzysty. A jeśli proces nie jest zbyt dobrze skonfigurowany, trzymiesięczne bilety mogą trafić do przeróbki  bez żadnego opisu. Taki proces jest nieprzejrzysty i nie jest jasne dla programisty, jak właściwie pracować z zadaniami.

To bardzo demotywujące, gdy PM stale przychodzi do programistów z zadaniem o dużym znaczeniu. Wtedy okazuje się, że zadania mają «wysoki priorytet», «najwyższy priorytet», «krytyczny» i «ultrakrytyczny».

Doświadczony PM ma dwa statusy: normalny i ważny (zadanie poza kolejką). Kiedy wszystkie zadania mają high-priorytet, następuje dewaluacja, ponieważ ciężko uwierzyć, że wszystko na raz może być pilne.

Co PM i programiści muszą rozumieć nawzajem ze swoich obszarów wiedzy

Jaka wiedza programisty jest ważna dla PM

Debata na temat tego, czy PM potrzebują wiedzy technicznej i czym ona jest, nigdy się nie skończy, ponieważ każda kłócąca się osoba może podać przykłady udanych/nieudanych PMów, którzy wywodzą się ze środowisk humanistycznych lub technicznych.

Przy pierwszym projekcie nikt nie będzie wymagał od menedżera gruntownej znajomości rozwoju. Ale dalej, aby skutecznie zarządzać, PM i tak będzie musiał dowiedzieć się, co wiedzą programiści.

Co trzeba wiedzieć:

1. Technologie — to z czym zespół pracuje bezpośrednio: na przykład z rozwojem Androida lub IOS. Jeśli menedżer rozumie podstawowe niuanse, rozumie szczegółowo, co się dzieje, to nie trzeba mu wyjaśniać, dlaczego na przykład nie można umieścić jakiejś funkcji w powiadomieniach push lub dlaczego nie można tworzyć trackerów torrentów na IOS.
2. Ryzyko i ograniczenia technologii: jakie rozwiązanie można wdrożyć, a które nie. Kiedy PM rozumie technologię — to przynosi kilka korzyści: zrozumienie, czy programista prawidłowo podaje oszacowanie; minimalizacja ryzyka, ponieważ PM jest w stanie ocenić niektóre niuanse techniczne już na etapie zatwierdzania; możliwość niezależnego omawiania przez PM przyszłych funkcji z klientami eliminuje dodatkowe obciążenie na programistów.
3. Wersjonowanie i jak wszystko działa pod maską: PM nie potrzebuje głębokiej wiedzy na poziomie technicznym, tylko na poziomie koncepcyjnym. Wiedza, dlaczego używać różnych wersji lub jak aplikacja współdziała z serwerem, pomaga PM zrozumieć istotę pracy i brzmi przekonująco podczas rozmów z programistami.
4. Wspólna infrastruktura: czym jest «klient-serwer». Prawie wszystko we współczesnym rozwoju to «klient-serwer». PM musi wiedzieć, że «klient» — to wszystko, co widzą użytkownicy, takie jak aplikacja mobilna, przeglądarka lub gadżet z oprogramowaniem, a serwer to jakieś zdalne miejsce, w którym odbywa się większość działań logicznych, interakcji z użytkownikiem i kierowania nim w aplikacji.
5. Obszary odpowiedzialności każdego uczestnika: jeśli PM rozumie, kto co może robić i gdzie czyja odpowiedzialność kończy się w zespole technicznym, pomoże to zmniejszyć liczbę konfliktów: PM będzie wiedział na przykład, czy warto przychodzić do programisty z problemami logiki użytkownika i innymi kwestiami.

Co programista powinien wiedzieć z tego, co wie PM

• Jak działa proces: jakie etapy przechodzi funkcja od inicjacji do dotarcia do użytkownika.
• Jak menedżer ocenia pracę: pomaga zrozumieć, jak być skutecznym i według jakich wskaźników PM uważa programistę za fajnego i przydatnego.
• Do czego służy meeting: jakie problemy PM stara się rozwiązać podczas bieżących spotkań (tj. zrozumieć cel).
• Jakie problemy rozwiązuje produkt lub konkretna funkcja: ogólnie, dla kogo jest wykonywany.

Trzy porady dla PM, jak zaprzyjaźnić się z zespołem programistów

Zarządzanie stresem

Sam PM może być wyczerpany i zmęczony, jednak ważne jest, aby radzić sobie ze stresem w swoim zespole, aby uczestnicy nigdy nie myśleli, że PM zaraz zacznie panikować i jutro wszystko się zawali.

Doświadczony PM filtruje stres zewnętrzny do poziomu konstruktywnego komunikatu dla programistów, aby zespół nie czuł się nerwowo i spokojnie pracował.

Drugą stroną radzenia sobie ze stresem — jest ustanowienie odpowiedniej komunikacji, aby każdy członek zespołu mógł przyjść do PM i przyznać: «Jestem zmęczony, nie mogę już tego znieść, nie podoba mi się ta funkcja, jestem ogólnie zmęczony projektem». Ważne jest, aby pozwolić ludziom mówić wprost, tak aby negatywne emocje nie przerodziły się w rozmowy w palarni za plecami menedżera.

Otwartość na dialog i chęć bycia zawsze po stronie zespołu, obrona «swoich» bardzo pomaga zarówno zespołowi, jak i samemu PM w pracy nad projektem.

Rozwiązywanie konfliktów

Jeśli PM nie planuje dowiadywać się wszystkiego w ostatniej chwili, to lepiej wcześniej uzgodnić z zespołem: «Kiedy coś ci się nie podoba, przyjdź i powiedz, postaram się rozwiązać problem. Jeśli jest to uciążliwe ze względu na sytuację lub zespół, wyciągnij to zadanie na retrospektywie, gdzie omawiamy, jak dobrze lub źle minął dany okres czasu».

Ważne jest, aby programiści zawsze rozumieli, że można powiedzieć: «Jestem zmęczony — pomóż mi» lub «Chcę wziąć urlop», a nie polegać na tym, że PM czyta w myślach i sam odgadnie problem.

Zrozumienie wartości zadania

Każdy członek zespołu będzie oburzony, jeśli zobaczy, że pisze na marne, nieważne: interfejs, kod, czy coś innego. Zrozumienie wartości konkretnego zadania znacznie poprawia produktywność.

Oczywiście dobra pensja jest fajna, ale oprócz tego ludzie chcą być użyteczni. Kiedy programista rozumie grupę docelową, jeszcze łatwiej jest mu wyobrazić sobie, jak będzie działał kod, który pisze dla tych osób. To właśnie PM daje poczucie, że zespół robi coś ważnego.

Krótkie podsumowanie

W idealnym świecie wszyscy wykonują swoje zadania i wszyscy rozumieją się na pierwszy rzut oka. W rzeczywistości konflikty wciąż się zdarzają: z powodu napiętych terminów, długu technicznego, błędnych specyfikacji i innych nieprzyjemnych aktualizacji. Menedżer projektu i lider zespołu to ludzie, którzy muszą poprowadzić zespół do celu pomimo działania siły wyższej.

Umiejętności zarządzania zespołem można stale doskonalić, a zacząć należy od zrozumienia roli każdego z uczestników. Pomaga to dostosować oczekiwania i nie polegać na tym, czego nie mogą dać współpracownicy.