Cześć wszystkim!
Jestem Junior PMem i zastanawiam się czy Project manager w ogóle powinien umieć pisać kod lub mieć wiedzę techniczną? Przecież zawsze można podpytać u Tech leada jak coś jest nie jasne. Oprócz tego to programiści są od tego żeby wiedzieć o stronie technicznej projektu.
Chyba że ktoś ma inna opinię. Założyłem się z kolegą, on twierdzi że PM ma mieć wiedzę techniczną (jest QA). Ciekawy jestem kto jednak ma racje :)
Adam2020 napisał(a):
Założyłem się z kolegą, on twierdzi że PM ma mieć wiedzę techniczną
Ok, to robimy tak - ja pisze że mój aktualny PM nie ma wiedzy technicznej i dzielimy się wygraną po połowie.
Mój aktualny PM nie ma wiedzy technicznej
Wg mnie, PM powinien mieć wiedzę techniczną, ale często nie ma i nic z tym nie zrobisz (chyba, że ustalasz wymagania i rekrutujesz PMa) ;).
Połowa ludzi nie jest w stanie rozróżnić product managera od project managera, więc radzę się spytać kogo ten QA miał na myśli.
To już zależy od firmy. Książkowo PM nie musi mieć wiedzy technicznej bo jego rolą jest robienie wykresów i harmonogramów. Tyle, że w wielu firmach PM to człowiek orkiestra - rozmawia z klientem, devami, jest trochę BA, trochę PO i trochę sprzedawcą. W tej drugiej sytuacji jak najbardziej powinien więc mieć wiedzę techniczną z zakresu procesu wytwarzania oprogramowania (ale nie samego programowania) jak i samego produktu.
Ja zazwyczaj pracuję z tym drugim rodzajem PM i tacy bez wiedzy technicznej zazwyczaj są bardzo destrukcyjnie dla projektu obiecując klientowi nierealne rzeczy czy próbując wpływać na wyceny nie mając odpowiedniej wiedzy.
Z drugiej strony są firmy w których dev nie widzi PM na oczy bo PM zajmuje się faktycznie zarządzaniem projektem a nie zarządzaniem developmentem.
Mmoże odwróćmy pytanie. Bo to trochę jakbyś coś takiego napisał:
Jestem Junior developerem i zastanawiam się czy programista w ogóle powinien umieć rozmawiać z biznesem lub mieć wiedzę dziedzinową? Przecież zawsze można podpytać u PMa jak coś jest nie jasne. Oprócz tego to PMowie są od tego żeby wiedzieć o stronie biznesowej projektu.
Czyli ogólnie: niby można być ignorantem nie wychodzącym ze swojej działki, jednak w cenie jest znajomość wielu aspektów tworzenia oprogramowania.
No i gdzie twoja chęć do rozwoju?
Jestem Junior PMem i zastanawiam się czy Project manager w ogóle powinien umieć pisać kod lub mieć wiedzę techniczną?
To brzmi jak udało mi się wbić na stanowisko juniora PM i teraz myślę, jak zrobić, żeby się specjalnie nie narobić.
No i nic osobistego, ale nie mam dobrej opinii o PMach, którzy nie mają ani skillów technicznych ani wielkiego doświadczenia w zarządzaniu (jeśli to jest "junior PM").
Doświadczone nietechniczne osoby ratuje fakt, że mają dużo doświadczenia biznesowego i mogą myśleć pragmatycznie i ułatwiają komunikację.
Techniczne osoby, które wchodzą w temat zarządzania ratuje fakt, że przynajmniej rozumieją techniczną stronę.
A jeśli ktoś ani nie jest dobry technicznie ani nie umie dobrze zarządzać, to co go ratuje? Czemu taka osoba miałaby zarządzać jakimkolwiek projektem?
Można powiedzieć "dobra postawa" i "chęć do rozwoju", ale tutaj nawet tego nie widać :(
Powinien zdecydowanie. Nie zrozumiesz programistów i ich problemów nie mając backgroundu technicznego. Np dlaczego danego taska nie udało się zamknąć w sprincie mimo że miał tylko 5 SP.
IMO PM / PO powinien posiadać minimum wiedzy technicznej albo chociaż zrozumienie na czym polega projekt, czy jak działa produkt. W obecnym projekcie (jestem na wypowiedzeniu) na co dzień pracuję z totalnie zielonym PO + miałem okazje współpracować z gościem, który tą wiedze miał - Nieporównywalna jakość/komfort pracy na korzyść tego drugiego. Chłop był kumaty i rozumiał co się do niego mówi, przez co spotkania były o połowę krótsze w porównaniu do mojego standardowego PO. No i pod kątem pomocy, tudzież komunikacja techniczna w innym teamie itp ten drugi bardzo często brał na siebie i przynosił nam wartościowy i zrozumiały output.
Nie ukrywam, że jednym z powodów wypowiedzenia był właśnie nie ogarnięty PO.
Powiedz więcej o organizacji:
Project management będzie bardzo różny w organizacjach z produktem i bez. W żadnym wypadku wg mnie bycie technicznym project managerem nie jest wymaganiem, ale trochę łatwiej jest opisać czemu jak wiadomo jaki kształt ma organizacja.
Dobrze, widzę że jednak mogłem się mylić w swojej ocenie zadań PMa. Ale nadal szczerze nie rozumiem jaka to powinna być wiedza, ponieważ nie uważam że umiętność pisania kodu jest mi potrzebna, nawet wydaje mi się że będę tylko przeszkadzał naszym developerom.
Jak macie jakieś konkretne sugestii to chętnie przeczytam!
@LukeJL, ja akurat mam tą chęć do rozwoju tylko ewidentnie nie wiem od czego zacząć.
Kluczowe jest tutaj, co rozumie się przez „wiedzę techniczną” ;) kodowanie raczej Ci się nie przyda, ale odróżnić kolumnę w Hibernate od kolumny na stronie webowej już warto umieć.
Jasne, ze możesz wszystko zdelegować i założyć, ze jakoś to będzie. Natomiast będzie Ci o wiele łatwiej w życiu, jeśli będziesz wiedział „jak działają rzeczy”. Najlepsi PM-owie z jakimi pracowałem znali podstawy architektury systemów informatycznych, wiedzieli jakie są zależności techniczne, które potem przekładają się na harmonogram itd. Wiedzieli z kim o czym rozmawiać. Warto wiedzieć, czym się zarządza.
Jak zacząć? Np. zrozumieć jak architektura techniczna przekłada się na zależności i harmonogram właśnie. Nie podejmujesz decyzji technicznych, ale rozumiesz co się dzieje na wyższym poziomie abstrakcji.
Czy Ty w ogóle przeczytałeś cokolwiek o zarządzaniu projektami IT?
W ogóle co to są za pozycje w stylu Junior PM? Masz jakieś blizny wojenne? Czy wiesz w ogóle jakie masz obowiązki i jakie są obowiązki innych?
Podstawowe pytanie - w jakim modelu pracujesz? Są firmy, gdzie PM to taka bardziej sekretarka, są firmy gdzie PM to najwyższa instancja i są firmy gdzie PM to taki tech lead zarządzający zespołem.
Drugie pytanie - w jakim modelu chciałbyś pracować? Wydaje mi się, że zawód czystego PMa odchodzi w zapomnienie, ale to może błąd mojej percepcji.
PM to nierówna rola. Czasami reszta teamu jest na tyle ogarnięta i sytuacja na tyle dobra, że nie ma co robić poza cyklicznymi rozmowami i dawaniem podwyżek. A w innych przypadkach musi być wszystkim po trochu. I w takich przypadkach przydaje się ogarnięcie techniczne
przecież zawsze można podpytać u Tech leada jak coś jest nie jasne
@Adam2020: a co jak tech lead jest czarodziejem i jego postawa i działania dążą do destrukcji zespołu i produktu? Jak się na czymś nie znasz to dowiesz się o tym po fakcie. Rolą PM jest zarządzanie ludźmi, jak nie wiesz jak pracują ludzie to na jakiej podstawie możesz podejmować jakiekolwiek decyzje? To tak jakbyś na budowie wciskał kit kierownikowi, że beton trzeba mieszać przez kilka dni, bo w tym czasie wolisz owalić kilka flaszek z kumplami. Jakby kierownik nie miał pojęcia o pracy to pewnie by przeszło
Większość nietechnicznych lub słabo technicznych PMów, których znam działała na takiej zasadzie, że mieli zaufane osoby, które pomagały im w decyzjach na tematy o których nie mieli pojęcia. I to zazwyczaj działa, zazwyczaj ludzie nie są źli lub problematyczni.
Niektórzy twierdzą że PM nie musi być techniczny, bo on jest od zarządzania pracą, więc liczą się miękkie umiejętności a techniczne są nieistotne. Czaicie co by było jakby to samo przenieść np. na budowlankę? Zrobić takiego Oskarka brygadzistą na budowie?
"Jak to płyta fundamentowa musi schnąć dwa tygodnie? A jak ci dorzucę kilku ludzi to wyschniecie ją do wtorku?"
"Betoniarka się zje*ała? To nawet lepiej, powinniśmy rezygnować z narzędzi third-party, weź dwóch praktykantów i poskładajcie nową in-house"
"Nie potrzebujesz uprzęży, musisz być bardziej agile"
"Po co te rury w kuchni? Klient chce wodę bezprzewodowo, wiem że się da bo czytałem o tym na jednym blogu"
"Wiem, że nie dowieźli zbrojenia, ale piętro musi być dokończone w tym sprincie, wylejcie beton normalnie a zbrojenie doda się w refaktorze w przyszłym kwartale"
"Mieliśmy już robić odbiór, ale przyszedł change request, na ile wyestymujecie dobudowanie piwnicy i przesunięcie klatki schodowej o 15 metrów w lewo? UX mówi że dla nich to nie problem poprawić plany, więc mam rozumieć że uwiniecie się do końca miesiąca?
"Biznes uznał że dźwigowy z uprawnieniami jest za drogi, za te same pieniądze zatrudniliśmy do zespołu 6 praktykantów"
"Do wykonania fundamentów zatrudniliśmy kontraktora, wy róbcie ściany a oni fundamenty zrobią u siebie na budowie w Bengaluru a potem się zintegruje"
Oprócz tego codzienne daily gdzie pyta każdego z osobna co robił wczoraj, co będzie robił dzisiaj i czy coś go nie blokuje na którym 56-letni Zbyszek mówi że wczoraj nosił cegły, dzisiaj będzie nosił cegły, a blokuje go czasem Rychu bo leży naje*any, potem kawka i krótki wpis na Muratorze o nowych trendach w budownictwie
Rychu bo leży naje*any to pewnie przez ten nowy protokół - rusztowanie over flacha
Każde stanowisko pracy, bez znaczenia czy jest to Product Manager, Project Manager, etc. powinno mieć określony zakres obowiązków znany wszystkim wokół.
Wtedy wiadomo jakiej wiedzy można oczekiwać od danej osoby.
Adam2020 - może opisz coś więcej o sobie i jak i dlaczego zostałeś PM w IT. Może Ci się tylko wydaje że nie masz wiedzy technicznej, bo np nie masz doświadczenia, ale np. skończyłeś studia informatyczne i jednak coś tam kojarzysz?
i tak wszystkiego się uczysz na praktyce xd
Od deva się wymaga, że będzie posiadał wiedzę domenową odnośnie projektu. Jak programuje urządzenia medyczne, to coś o medycynie, Jak w finansach, to coś o finansach. Jak w transporcie, to coś o logistyce. A od PMa ma się nie wymagać, żeby miał wiedzę techniczną? To po co komu w ogóle taki PM? Może i w niczym nie pomoże i podejmie złe decyzje, ale za to będzie przeszkadzał w pracy i pytał co chwilę "jak progress?", bo nic więcej nie potrafi. Praca z takim ananasem musi być doprawdy przyjemnością.
Adam2020 napisał(a):
Dobrze, widzę że jednak mogłem się mylić w swojej ocenie zadań PMa. Ale nadal szczerze nie rozumiem jaka to powinna być wiedza, ponieważ nie uważam że umiętność pisania kodu jest mi potrzebna, nawet wydaje mi się że będę tylko przeszkadzał naszym developerom.
Jak masz zero technicznego skilla i zaczniesz coś kodować a potem się mądrzyć na spotkaniach to:
a) prawdopodobnie będziesz opowiadać farmazony
b) zrazisz do siebie ludzi bo nie lubią jak im błędy wytyka ktoś kto nie odróżnia bitu od bajtu
Najlepiej zrobisz jak zaczniesz się interesować ogólnie zarządzaniem projektem programistycznym, w tym SDLC, programistami, jakością, bezpieczeństwem, dokumentacją, architekturą, zmianą, wymaganiami, konfiguracją, budżetem, szkoleniami, umowami.
Toksyk napisał(a):
Od deva się wymaga, że będzie posiadał wiedzę domenową odnośnie projektu. Jak programuje urządzenia medyczne, to coś o medycynie, Jak w finansach, to coś o finansach. Jak w transporcie, to coś o logistyce. A od PMa ma się nie wymagać, żeby miał wiedzę techniczną? To po co komu w ogóle taki PM? Może i w niczym nie pomoże i podejmie złe decyzje, ale za to będzie przeszkadzał w pracy i pytał co chwilę "jak progress?", bo nic więcej nie potrafi. Praca z takim ananasem musi być doprawdy przyjemnością.
W praktyce się zgadzam, w teorii nie. W teorii PM powinien zarządzać projektem z lotu ptaka - czyli harmonogramy, zasoby etc. Często taki PM ma kilka projektów pod sobą jednocześnie. Nie musi mieć zbyt dużej wiedzy technicznej. W praktyce jednak PM rzadko jest tylko PM, zazwyczaj to jakaś hybryda PO/SM/BA i wtedy faktycznie PM nie rozumiejący zagadnień technicznych bardziej przeszkadza niż pomaga.
Lepiej żeby nie miał żadnej wiedzy technicznej, bo jeszcze zacznie dawać porady w stylu robienia wszystkiego jako struct, a nie class, bo na stosie jest wydajniej, albo jak synchronizować wątki w asynchronicznym kodzie.
IMO - PM nie potrzebuje wiedzy technicznej, w sensie "sam to zakoduję", ale potrzebuje mieć doświadczenie w tworzeniu oprogramowania, Nie ważne, czy jako programista, analityk, tester. Inaczej będzie miał duże problemy w komunikacji z zespołem i narazi się na spore ryzyko błędnych decyzji. Trzeba mieć chociaż minimalną wiedzę o pracy wykonywanej przez zespół, którym się kieruje.
Przykłady z życia:
Zróbmy to bez testów?
Po co mamy poprawiać ten kod, skoro działa?
Kwestia czystko ludzka, to "przydatność" dla projektu. Dostarczenie oprogramowania to analiza, implementacja, testowanie, utrzymanie. Jeżeli ktoś nie tylko nie robi nic z tych rzeczy, a często "przeszkadza", to raczej ciężko będzie mu zdobyć szacunek zespołu.
Jako że Elon Musk aktywnie czyta to forum, postanowił odnieść się do rzeczonej kwestii:
https://twitter.com/elonmusk/status/1522609829553971200
I strongly believe that all managers in a technical area must be technically excellent.
Managers in software must write great software or it’s like being a cavalry captain who can’t ride a horse!
Oczywiście nastąpił supershitstorm :)
Najgorsi są Produxt Ownerzy i Projekt Managerowie, co nie mają pojęcia o produkcie.
Płatają się pod nogami jak takie biedne sieroty, nie wiedzą gdzie co kliknąć w systemie, klientowi nic nie pokażą. Dupę ciągle programistom zawracają i ich ściągają na spotkania, żeby pokazali i wytłumaczyli coś, co taki człowiek powinien sam wiedzieć.
Takze najwazniejsze to znajomość produktu, co można zrobić, a czego nie, żeby najdurniejsze pomysły od razu gasić jak peta, albo proponować klientom inne rozwiązanie, a nie jak zagubiona sierota spamować programistom spikami i spotkaniami.
Rowniez warto znać nomenklaturę, żeby nie siedzieć i nie potakiwać głową jak pacynka, tylko rzeczywiście rozumieć, czemu dodanie przycisku na stronie zajmuje 5 dni, a nie 5 minut.
@Adam2020: jestem PMem z doświadczeniem już ponad 5 lat i mogę z pewnością powiedzieć że wiedza techniczna u PMa powinna być. Nie musisz umieć sam pisać kod, ale warto wiedzieć w jakim języku programowania jest pisana aplikacja lub oprogramowanie i czemu ten język wybrany a nie inny, wiedzieć jaki jest proces projektowania i napisania kodu żeby rozumieć na jakim etapie jesteście z realizacją zamówienia i td. W sumie trzeba dobrze orientować się w całym procesie developmentu.
Ja na początku swojej kariery jeszcze dodatkowo miałem kursy dla PMów w IT, i też dodatkowo przeczytałem nie mało artykułów i książek na temat kierowanie zespołem programistów i ogólnie o tworzeniu aplikacji/oprogramowania i radzę tobie zrobić to samo :)
