poniedziałek, 6 stycznia 2014

PM - bóg czy nędzarz ?


http://andjuniorshakers.com/wp-content/uploads/2011/07/suicide-gun1.jpgZwinne projekty...
Agile, Scrum, Kanban, Crystal, XP, Lean, Prince2, PMBOK etc (o tym powiemy sobie też potem)

Chciałbym na samym wstępie zaznaczyć, że zarządzanie ludźmi nie interesuje mnie, prawdę mówiąc jeszcze się do tego nie nadaje. Ale przeczytałem w cholerę książek na temat zarządzania zespołem, prowadzeniu projektów, metodykach wytwarzania tylko po to, żeby osiągnąć jakiś poziom wiedzy.
W założeniu poziom ten miał być tyle duży aby żaden domorosły PM nigdy nie wszedł mi już na głowę. Wiedza jest jak miecz. To potężny oręż.
Poprzez odpowiednie zadawanie pytań i mając odpowiednią wiedzę możecie każdego PM postawić do pionu. Albo nie będzie chciał już z Wami zadzierać.

Ważne jest aby każde stanowisko od początkującego programisty po architekta czy PM zasiadali odpowiedni ludzie i to jest w głównej mierze główny wyznacznik sukcesu firmy.

To nie prawda, że firma musi składać się tylko z samych 'wyjadaczy'.
Tak to nie działa. Stanowiska, wiedza i płacę powinny być zróżnicowane. Muszą być też zatrudnieni początkujący programiści, którzy odciążą seniorów czy innej maści wyższej klasy fachowców pracami, które stają się już dla nich nudne lub powtarzalne.
Początkujący w ten sposób będą mieli sposobność zapoznać się ze sposobem wytwarzania, poznać lepiej warsztat i uczyć się od lepszych.
Bardziej doświadczeni będą mogli skupić się na rzeczach o większym priorytecie lub technicznie bardziej zaawansowanych np. wielowątkowość.

Wracając do tematu.
Metodyk jest sporo. Ktoś musi decydować co wybrać i co będzie odpowiednie dla danego zespołu i dla problemu jaki zespół będzie rozwiązywał.

Ktoś musi ukształtować team, wybrać odpowiednie zasoby, dobrać ludzi, zarządzać ryzykiem, kontaktować się z klientem i wiele innych tym podobnych spraw.

Kiedyś pracowałem w firmie w której główny architekt powiedział coś na kształt tego : 'Każdy PM musi mieć w sobie coś ze skurwysyna'.

Przez naszą salę przeszła cicha fala śmiechu. Ale tak naprawdę każdy zobaczył w większym czy mniejszym stopniu podobne zjawisko. Empirycznie.
Nie zawsze tak musi być. Spotkałem w swojej karierze zawodowej naprawdę paru świetnych PM, z którymi dobrze mi się pracowało.


Dobry PM spełnia następujące kryteria:
- dobrze wyznacza priorytety dla poszczególnych tasków
- jest szczery, elastyczny i obiektywny
- ochrania zespół przed zewnętrznymi naciskami
- jest otwarty na komunikacje z klientem i szanuje go, potrafi też  być asertywny
- jest odpowiedzialny za projekt i zawsze bierze tą całą odpowiedzialność na siebie

- nigdy nie krytykuje na forum ani w face2face jakiegokolwiek członka zespołu
   (raczej odbywa z nim osobistą rozmowę i zastanawiają się jak ulepszyć proces wytwarzania za który odpowiedzialny jest dany członek zespołu)

- podtrzymuje motywację zespołu
- jasno określa każdą rolę członków zespołu
- jasno określa rezultaty i funkcjonalność danych iteracji
- radzi sobie z opóźnieniami harmonogramu
- dąży do doskonałości w tym co robi - ciągła nauka
- przyznaje się do swoich błędów
- potrafi stworzyć komfortowe warunki dla pracy swojego zespołu (issue tracking, vpn, serwery, odpowiednie środowisko testowe, pomostowe ,etc)

I tak naprawdę to jest jego psi obowiązek. Tak jak moim jest pisanie kodu który działa.

Dobrego PM poznamy również wtedy gdy nie widzimy jego braku. Tzn czy jest obecny fizycznie czy go nie ma, my tego nie odczujemy. Ponieważ wszystkie formalności oraz inne rzeczy potrzebne do pracy zespołu są załatwione i nikt z członków zespołu nie musi się o nie martwić.

Aha jeszcze mała ściąga (oraz tutaj) dla tych PM, którzy chcą wytwarzać zwinnie. 
I tak naprawdę jest to lektura obowiązkowa dla każdego kto chce się zajmować dziedziną jaką jest zarządzanie projektem.

cdn





Brak komentarzy:

Prześlij komentarz