Temat rzeka.
Bardzo dużo zależy od branży, tematyki, zakresu prac, fazy życia projektu lub produktu i wielkości zespołu. Pracowałem w zespołach <10 osób i w zespołach >200 osób w ramach jednego modułu. Pracowałem jako młody designer, senior, architekt, kierownik zespołu, lider produktu, itp... Po latach pasuje mi funkcja architekta, ale nie ograniczam się do pisania specyfikacji, ponieważ biorę bezpośredni udział w procesie tworzenia produktów.
W małym zespole łatwo jest o bezpośrednią wymianę informacji i łatwiej zyskać motywację. Trudniej zrealizować większy projekt i dopracować dokumentację do projektu, a dodatkowo dochodzi bardzo duża zależność powodzenia projektu od pojedynczych osób. Choroba, wypadek czy zły humor toksycznego osobnika mogą narobić sporo problemów.
Z dużym zespołem można dużo więcej osiągnąć, ale często problemem jest opóźnienie w przekazywaniu informacji, trudniej zebrać odpowiednie osoby do rozmowy na konkretny temat i trudniej utrzymać wysokie morale. W dużym zespole jest dość normalne, że następuje wymiana ludzi w zależności od fazy życia projektu.
Podział obowiązków w dobrym projekcie wynika z doświadczenia i umiejętności uczestników projektu, w słabym projekcie z obserwacji kierownika zespołu czy nawet lidera projektu, w najgorszym przypadku z arbitralnych decyzji o podziale obowiązków. I znowu dochodzimy do wielkości zespołu. W małym, wybór jest mocno ograniczony, przez co często trzeba przesuwać obowiązki, w dużym zmiany są dość rzadko, ale jeżeli już wystąpią, to mocno wpływają na strukturę i jakość pracy.
Standardy są stale tworzone i jeszcze nikt nie opracował jednej uniwersalnej metody. Miałem różnych PL i TL. Najbardziej nie lubię takich, którzy nie wiedzą co robimy, boją się podejmować decyzje albo kłamią. Wszystko inne jest do przejścia. Z Polski pamiętam, że popularna była mentalność poganiaczy i jednopalczastych. W Holandii takich nikt nie trzyma i albo są degradowani, albo wylatują. Project Leader albo Team Leader musi być z zespołem, musi wiedzieć jak wygląda sytuacja i bardzo często interesują się czy masz wszystko co potrzebujesz, aby realizować projekt. Rozmowy o prywatnym życiu nie są powszechne, ale jeżeli ma to wpływ na pracę, to starają się rozwiązać takie problemy bardzo szybko.
W małym zespole PL ma łatwy kontakt z każdym z ekipy. W dużym zespole, często PL jest trochę oddzielony z uwagi na specyfikę pracy: zbieranie informacji, przygotowanie raportów, dyskusje budżetowe, reagowanie na zmiany. W takiej sytuacji nadal ważne jest, aby prowadzący projekt był widoczny i przynajmniej raz na jakiś czas uczestniczył w spotkaniach.
Mikrozarządzanie to kwestia indywidualnych upodobań, ale wyznaczanie realnych i możliwych do osiągnięcia celów, to bardzo cenna umiejętność. Jeżeli do tego mieścisz się w budżecie (na ogół chodzi o czas), to warto świętować osiągnięcia. To jest forma motywacji pozapłacowej, ale jest dużo lepsza i stoi po drugiej stronie skali względem uścisku spoconej dłoni prezesa.
Jeszcze jeden istotny element całej gry to cykl życia samego produktu. Bardzo fajne jest tworzenie czegoś nowego, gdzie jest miejsce na innowacje, na implementację tego, czego się nauczyliśmy. W takich przypadkach PL musi oszacować ryzyko i wiedzieć kiedy powstrzymać radosną twórczość. W produktach dojrzałych, gdzie istotne jest tylko podtrzymanie go przy życiu, serwis, ew. jakieś dodatki, nie ma miejsca dla wirtuozów, a w perspektywie jest śmierć produktu, praca PL jest jeszcze bardziej wymagająca. Zmotywowanie ludzi do nudnej, czasem zbędnej pracy, ze świadomością braku perspektyw w rozwoju jest bardzo trudne. Jeżeli masz ten komfort i możesz wybierać, to nigdy nie idź do projektu typu sustain.
