project manager nie mający wiedzy technicznej

Somekind moze i masz racje - jesli PM nazywamy TL pelniacym role PM - dla mnie to nie jest jednak PM (choc przy malych projektach ze wzgledow kosztowych moze to miec jakis tam sens). PM nie mowi programistom co jak maja robic bo nie bedzie posiadal wystarczajacej wiedzy. Nawet jesli bylby mega wymiataczem od javy i byl w stanie ogarnac team to co z pozostalymi teamami znajdujacymi sie w projekcie i nie piszacymi w javie? W takiej sytuacji mozemy na sile zatrudnic kolejnych pmow (pelniacych role TL), ktorzy ogarna co i jak maja robic programisci albo zrobic to tak ze PM rozmawia z zespolami ogolnie a wizja i planem implementacji zajmuja sie programisci. Dodatkowo jesli PM mialby sie zajmowac decydowanie kto/co/gdzie ma pisac to w przypadku krotkich projektow co pare miesiecy teamowi moglaby sie zmieniac osoba zarzadajaca (ktora malo czasu poswieca na programowanie)... Dlatego wg mnie PM nie potrzebuje umiejetnosci technicznych, a skoro jego praca polega na komunikacji to lepiej zeby mial zdolnoscie miekkie.

Ale czemu PM w ogóle miałby się zajmować mówieniem co ktoś ma pisać?!
Rolą PM jest dbanie o wykonanie projektu w czasie. Tylko jeśli taki PM nie ma wiedzy technicznej, to często nie rozumie, że czasami występują niespodziewane utrudnienia, że czasem zadanie wyglądające na proste okazuje się bardzo trudne czy wręcz niemożliwe do zrealizowania, albo że do efektywnej pracy potrzebne są jakieś narzędzia. Taki PM utrudnia życie programistom i praca z kimś takim to mordęga.

Odnosnie pisanie - tak widocznie blednie wywnioskowalem z poprzedniego postu. A co do powyzszego - opisales PM ktory nie slucha innych, mysli ze sam wie lepiej. To nie jest opis PM bez wiedzy technicznej tylko osoby ktora nie powinna byc PMem bo sie do tego nie nadaje.

Myślę, że w i drugą stronę można pomyśleć i zamiast dyskutować czy PM powinien mieć wiedzę techniczną, można zadać pytanie czy programista powinien tylko programować, czy może jednak warto, żeby programista również:

• posiadał miękkie skille (żeby dogadać się z innymi członkami zespołu)

• znał jakieś podstawy UX i pisząc kod myślał o użytkowniku końcowym (niestety cała masa aplikacji internetowych wydaje się być tworzona kompletnie bez myśli o użytkowniku - strona PKP to chyba najlepszy przykład)

• posiadał wyczucie biznesowe na temat tego co jest ważne, a co nie do końca (wydaje mi się, że wiele programistów zagłębia się za bardzo w czysto techniczne aspekty tworzenia oprogramowania, a nie patrzy, że często nie ma to wiele sensu z perspektywy biznesowej (np. kłótnie o każdy przecinek w złym miejscu na code review))

Z drugiej strony może to nie są rzeczy potrzebne? Można zawsze powiedzieć, że za całość projektu odpowiada PM i to jego broszka, żeby dbać o komunikację, konsultować się z UX designerami, czy odpowiednio rozdzielać zadania programistom - ale jednak moim zdaniem to jednak nie do końca tak działa, bo jeśli efekt końcowy jest wynikiem pracy kilku osób, to zgrzyt w jednym miejscu (np. braki w komunikacji między osobą A a B w zespole) może położyć cały projekt...