Czy dobrzy kierownicy projektów potrzebują podstaw programistycznych? [Zamknięte]

Czasami nie mogę tego znieść, gdy kierownicy projektów proszą mnie o oszacowanie czasu na wykonanie różnych zadań. Szacunek jest domysłem, a domysły mogą być błędne. Zasadniczo złe wymagania i dokumentacja prowadzą do zgadywania.

Często więc zastanawiam się, czy kierownicy projektu kiedykolwiek w moich butach próbowali zgadnąć, jak długo zajmie zadanie X i Y i jak trudno jest przypisać mu liczbę na podstawie tego, co niewiele wiadomo i zebrano od klienta.

Moje pytanie brzmi zatem: czy dobrzy kierownicy projektów muszą mieć doświadczenie w programowaniu?

A może pytanie powinno brzmieć: czy dobrzy kierownicy projektów musieli wcześniej być dobrym programistą? Czy jest jakaś korelacja?

Zarządzanie projektami informatycznymi zdecydowanie nie jest tym samym, co zarządzanie innymi rodzajami projektów. Kiedyś słyszałem o menedżerze projektu bez doświadczenia informatycznego. Skończyło się to frustracją programistów i po prostu ich odstraszenie.

Z drugiej strony programista, który staje się Project Managerem, może stać się maniakiem kontroli, myśląc, że może naprawić rzeczy, jeśli nie może zmusić programistów do zrobienia tego poprawnie (taki był mój problem w podobnych sytuacjach)

Menedżer z dużym zapleczem technicznym zazwyczaj lepiej rozumie, jak „myśli” ich zespół. Zawsze lepiej jest mieć menedżera, który cię rozumie, prawda?

Nie. Dwie zupełnie różne umiejętności. Zły kierownik projektu niekoniecznie musi być kimś, kto nie rozumie IT, i odwrotnie.

Bycie rozsądnym, racjonalnym, zorganizowanym, zrozumienie celów projektu i powiązanego biznesu oraz dobry motywator wcale nie zależą od umiejętności programowania.

Wszystko inne jest jednakowe, wolałbym kierownika projektu z silnym, aktualnym doświadczeniem technicznym. Jednak w prawdziwym świecie programiści, którzy ukończyli zarządzanie projektami w pełnym wymiarze godzin, są bardziej skłonni pozwolić, aby ich umiejętności stały się przestarzałe i przestarzałe, co nie jest dużo lepsze niż ich brak wiedzy technicznej.

Pracowałem z dobrymi menedżerami projektów i niektórymi okropnymi i mogę szczerze powiedzieć, że widziałem niewielką korelację między ich umiejętnościami zarządzania a ich zapleczem technicznym. Najważniejszym czynnikiem nie jest zaplecze techniczne, ale ilość doświadczenia w zarządzaniu projektami oprogramowania . Jeśli masz dwie osoby zarządzające pierwszym projektem, programista przechodzący do zarządzania projektami będzie tak samo zły jak kierownik projektu bez doświadczenia IT. Obaj przejdą intensywny proces uczenia się.

Spór o umiejętności kierowników projektów bez wiedzy technicznej przypomina mi trochę o tym:

Szczerze uważam, że odpowiedź brzmi „nie”. Aby być dobrym managerem projektu, potrzebny jest cały bagaż kompetencji, a bycie programistą nie jest jedną z nich. Dobry kierownik projektu może zarządzać każdym projektem dowolnego typu, biorąc pod uwagę, że w zespole projektowym są dobrzy ludzie, którzy wiedzą, co robią. Główną cechą, jaką powinien mieć kierownik projektu, są umiejętności komunikacyjne . Zadaniem kierownika projektu jest koordynacja zadań projektu i utrzymywanie komunikacji między klientem, zespołami projektowymi i innymi zainteresowanymi stronami. Powinien on / ona zawsze znać postępy zespołu i czy występują przeszkody na drodze, ale nie musi wiedzieć, na czym polega problem ani co należy go naprawić, chyba że implikuje to inną osobę w zespole, której czas będzie należy dostosować, aby pomóc rozwiązać problem.

Jeśli chodzi o podawanie szacunków, jest to rzeczywistość życia w każdej pracy. Nigdy nie można zbudować domu na czas, gdyby elektryk nie był w stanie powiedzieć, ile czasu zajmie mu wykonanie okablowania - kiedy będziesz wiedział, jak zarezerwować ściany facetowi? Zgadzam się jednak, że naprawdę trudno jest podać dane szacunkowe z powodu dużej liczby elementów nieprzewidywalnych. Klienci nie zawsze wiedzą, czego chcą, i często zapominają powiedzieć ci wiele rzeczy. To, co kiedyś robiłem, to z grubsza oszacowanie, jak długo to potrwa, a następnie pomnożenie przez 2! A dobry menedżer programu nie powinien cię krzyżować, gdy twoje szacunki okażą się niepoprawne, spowoduje to pewne bóle głowy związane z reorganizacją harmonogramu, rozmową z klientem, wyjaśnieniem szefom, że będzie to kosztować więcej, itd. Ale to część ich pracy - znowu, są w większości wymagane.

Powiedziałbym nawet, że brak umiejętności programistycznych jest jeszcze lepszy - były programista może spróbować oszacować samodzielnie lub po raz drugi zgadnąć twoje oszacowania. Wszyscy wiemy, że umiejętności informatyczne stają się bardzo przestarzałe. Musisz zacząć zadawać pytania, gdy kierownik projektu jest bardziej zainteresowany tym, jak zamierzasz wykonać zadanie, niż tym, jak długo to potrwa i kiedy będziesz gotowy. Mogą poprosić cię o ocenę alternatyw i pozwolą ci poznać szczegóły, ale najważniejsze jest, aby wiedzieć, jak wpłyniesz na harmonogram projektu.

Wreszcie, nie mówię, że do zarządzania projektem informatycznym nie są potrzebne żadne umiejętności informatyczne - ludzie IT, którzy nie wydają się być w stanie wulgaryzować tego, co mówią dla zwykłych ludzi (!), Pomaga poznać podstawowy żargon, aby móc się z nimi komunikować! Istotna jest również znajomość podstawowych kroków - musisz skonfigurować serwer przed uruchomieniem na nim strony internetowej. Nie mogłem zarządzać projektem budowlanym, gdybym nie wiedział, że elektryk musi zakończyć okablowanie przed zamknięciem ścian !!

Premier naprawdę musi wiedzieć, co zrobi projekt, co prawdopodobnie wymaga zaplecza technicznego, ale nie rozwija się.

Poza tym chodzi o szacunek dla branży i deweloperów, a nie faktyczną wiedzę. Premier musi poważnie potraktować programistów, czego potrzebują, co mogą zrobić, czego nie mogą, ile czasu zajmie. Premier, który ma pojęcie o tym, czego nie wie, może być bardzo skuteczny. Premier, który uważa, że ​​ma wszystkie odpowiedzi, jest zły. Może to być były programista, który wierzy, że wie wszystko i nie wie, lub taki, który nigdy się nie rozwijał i nie uważa, że ​​potrzebuje specjalnej wiedzy technicznej do zarządzania.

Nie sądzę, aby kierownik projektu informatycznego wymagał wiedzy informatycznej. Ale on / ona musi zdecydowanie zrozumieć IT i powinien wiedzieć, jak działają projekty IT.

Chociaż zaplecze IT jest dodatkową zaletą, jego brak nie czyni z niego niezbyt dobrego kierownika projektu IT. Posiadanie zaplecza informatycznego nie jest decydującym czynnikiem.

Pracowałem z oboma typami i każdy z nich miał swój unikalny zestaw cech i problemów.

Z IT backround:
- Rozumie, kiedy mówimy o błędzie wydajności, ponieważ kod nie jest wielowątkowy
- Ale w niektórych sytuacjach powiedziałby „hej, daj spokój, to tylko dodanie 4 wierszy kodu, możesz to zrobić w ciągu 10 dni”

Bez wiedzy informatycznej:
- Byłoby bardzo wygodnie negocjować zmianę wygodnego terminu
- Dla projektu bez żadnych wymagań (w ogóle jeszcze), czasami powiedziałby „czy możemy podać przybliżony szacunek 100 dni i wspomnieć o 30% buforze.

Uważam, że potrzebują trochę doświadczenia programistycznego. Jeśli nie, to zawsze będą wywierać presję na programistów, aby szybko wykonali swoje zadania i oczekują, że zostanie ono wykonane w ciągu kilku godzin, podczas gdy zadanie to wymaga dużo myślenia i poświęcenia. Te cechy są znane i dobrze zaznajomione z programistami, więc jeśli kierownik projektu ma doświadczenie w programowaniu, zrozumie, jak długo zajmie określone zadanie i nie będzie żadnych argumentów w dziale, a zatem w końcu ewoluuje dobry projekt.

@NimChimpsky Zgadzam się.

To kwestia tego , a nie jak (Aktywne słuchanie to miłe narzędzie).

Szacowanie działa w przypadku małych zadań technicznych, ale przy planowaniu musisz współpracować, aby zobaczyć całą złożoność. A ty nie jesteś rywalem.

To zdecydowanie by pomogło, zwłaszcza jeśli nie jest to dobry kierownik projektu. Dla dobrego kierownika projektu ma to naprawdę znaczenie.

Nie.

Dobry kierownik projektu to ktoś, kto potrafi zrozumieć i zrozumieć potrzeby, preferencje i możliwości swojego zespołu, bez względu na to, czy będzie to na placu budowy, w hali produkcyjnej czy w domu programistycznym.

Dobry lub zły kierownik projektu może mieć dowolne podłoże:

Źli menadżerowie z wykształceniem technicznym mogliby być programistami asów, którzy nie doceniają trudności, z jakimi spotykają się nowicjusze, mając do czynienia z przyziemnymi, „łatwymi” koncepcjami, takimi jak wskaźniki.

Dobrym menedżerem może być przeciętny programista, który nie był tak błyskotliwy ani sprytny jak jego koledzy, ale miał głębokie zrozumienie struktury projektu, wymagań i na pamięć rozumiał lekcje Miesiąca Mitycznego Człowieka, ponieważ sam przeżył złe dni kodowania i przeżuł się, że nie skończył swoich produktów na czas.

Dobrym menadżerem może być ten sprzedawca oprogramowania, który dowiedział się, że jego przyjaciele od programistów nie mogli wychodzić z nim w weekendy z powodu nierealnych obietnic, które sam złożył klientowi.

Wiedza techniczna nie determinuje kwalifikacji programisty jako menedżera, ponieważ umiejętności wymagane w obu zadaniach są zupełnie inne. Więc nie.

Nigdy nie widziałem menedżera projektu bez doświadczenia IT, który mógłby zarządzać niebanalnym projektem rozwoju oprogramowania wartym cholerności. Widziałem bardzo niewielu kierowników projektów z doświadczeniem IT, którzy mogliby to zrobić, ale wydawało się, że mniej to popieprzyli.

Z mojego doświadczenia wynika, że ​​zarządzanie polega na skutecznej komunikacji i podejmowaniu decyzji. Mając to na uwadze, sensowne jest, aby ktoś, kto rozumie rzemiosło (przynajmniej podstawowe pojęcia i terminologię) wykorzystywane przez osoby, którymi zarządza, lepiej nadaje się do kierowania niż ktoś, kto ma mniej zrozumienia, ale zdecydowanie Brak powiązań. Widziałem menedżerów z doświadczeniem w programowaniu, którzy odnoszą sukcesy i porażki, tak samo często, jak menedżerowie bez doświadczenia w programowaniu.

W moim przekonaniu albo skrajność jest zła; Ludzie ze zbyt małym doświadczeniem w programowaniu mogą ślepo ufać swoim programistom (Shepard podąża za owcami); Ludzie ze zbyt dużym doświadczeniem mogą ciągle kwestionować wysiłki swojego zespołu (mikro zarządzanie).

Osobiście uważam, że ktoś, kto dobrze zna podstawowe koncepcje programistyczne, ale zdaje sobie sprawę, że nie jest to „dobry pomysł”, jest idealnym rodzajem menedżera.

Zdecydowanie.

Muszę uważać na tę jedną, ponieważ opiera się ona na prawdziwych historiach, ale postaram się wyjaśnić mój ból.

Pracuję jako inżynier oprogramowania i mamy kierownika projektu, z którym ostatnio dużo pracuję. Nie ma zaplecza technicznego i wygląda na to, że wcale go to nie interesuje, ale to nie jest problem (każdy ma własne interesy). Jeśli nie lubisz mieć technicznego know-how, ponieważ jest to trochę „dziwaczne” niż twoje, ALE jeśli Twoim zadaniem jest rozmawianie z klientem na poziomie technicznym, niezbędna jest wiedza techniczna, której on nie posiada mieć.

W każdym razie jest ten facet, który nic nie rozumie na temat działania serwera, działania strony internetowej, programowania i tak dalej. Czasami czuję, że on nic nie wie. Więc za każdym razem, gdy próbuję wyjaśnić mu, co musimy teraz zrobić lub jaki jest problem, co mamy w tej chwili, on nic nie rozumie. I nie jest typem faceta, który powiedziałby „poczekaj chwilę. Czy możesz powtórzyć, że tak naprawdę nie rozumiem tego”. Nie, on jest takim facetem, który nie chce pokazać, że nic nie rozumiał w całej rozmowie.

Ale to się nie kończy, bo wtedy dzwoni do klienta i mówi coś, co w zasadzie nie jest prawdą. I ostatecznie musimy zadzwonić do klienta, aby to wyjaśnić ponownie.

Dlatego mówię, że naprawdę konieczne jest posiadanie podstawowego zaplecza technicznego i wiedzy technicznej. Nie powinien być w stanie pisać kodu, ale powinien być w stanie zrozumieć, co się dzieje i jakie procesy należy wykonać.

BTW, ponieważ pracuję z nim, moja praca nie jest już zabawna.

Powiedziałbym, że tak, powinien mieć doświadczenie w programowaniu. Jeśli menedżer nie ma pojęcia, jak to jest programować, skończy z nierealistycznymi szacunkami dotyczącymi rozwoju i naprawiania błędów. Ponadto nie zrozumiałby problemu technicznego na tyle dobrze, aby podjąć decyzję. Programiści w zespole mogą go okłamywać i może nie zdawać sobie z tego sprawy, a także programiści mogą powiedzieć mu problem i może pomyśleć, że wkurzają się

Umiejętności techniczne nie są dobrym menedżerem, dobre umiejętności zarządzania. Może być pomocne, jeśli menedżer poświęcił swój czas na „okopy”, ponieważ mogą docenić proces, którego laik nie może mieć. Może to jednak również prowadzić do pewnego rodzaju dziwactwa kontrolnego, którego nie mają nawet menadżerowie. Mogą próbować wykonać całą pracę sami lub zbadać twoją w wyjątkowo niewygodny sposób.

Z mojego osobistego doświadczenia, najlepszy menadżer, jakiego kiedykolwiek miałem, był dość nieświadomy technologii, ale wiedział, że ludzie pod nim pracujący znali się na rzeczy i wiedział, jak zdobyć lojalność i szacunek swojego zespołu. Pracowałem pod nim przez cztery lata i opuściłem firmę tylko dlatego, że odszedł i został zastąpiony przez menedżera, który nie był tak dobry.

Jeden z najgorszych menedżerów, których miałem, jest dobrze zorientowany w kodowaniu (jeśli nie w projektowaniu oprogramowania) i sam wykonuje tyle pracy, że pozostawia nam niewiele więcej niż wyrzucanie błędów, naprawianie błędów lub projekty, których nie chce robić samemu.

Wydaje się, że istnieje pewne zamieszanie:

PM nie jest szefem programistów . Osoba odpowiedzialna za zespół deweloperów (lider zespołu, menedżer) oraz zatrudniająca i oceniająca powinna zdecydować, czy pracujesz wystarczająco ciężko.

Szacunki nie są idealne. Myślę, że premier rozumie to bardziej niż myślisz. Czy naprawdę oczekujesz, że nikt nie zapyta Cię, ile czasu zajmie zrobienie czegoś? Każdy chce wiedzieć, kiedy to się skończy i śledzenie go jest zadaniem premiera.

Możesz być premierem, jeśli: A) rozumiesz, jak zarządzać projektami B) rozumiesz proces rozwoju. Żadne z nich nie wymaga wiedzy na temat kodowania, ale może pomóc.

Ustalenie, czy programiści robią wystarczająco dużo, nie jest zadaniem premiera, chyba że pełni on funkcję lidera zespołu. Aby wiedzieć, czy ktoś „wydmuchuje dym” o czasie wykonania zadania, menedżer zawsze będzie miał przewagę, jeśli zrozumie, z czym się wiąże.

Szacunki stają się lepsze w przypadku doświadczonych programistów, którzy mają historię pracy nad danym typem projektu. Nikt nie oczekuje, że będą doskonałe, ale oczekują, że zbliżysz się i poprawisz z czasem.

Przypomniało mi się stare powiedzenie: „nie musisz być szalony, żeby tu pracować, ale to pomaga”.

Krótka odpowiedź jest taka, że ​​praktyczne doświadczenie w kodowaniu nie jest warunkiem dobrego oprogramowania PM, ale zwykle jest preferowane. Kluczem do bycia zdolnym PM jest zrozumienie procesu rozwoju (bez względu na zastosowaną metodologię) oraz zaufanie, że programiści są gotowi i zdolni do wykonania swojej pracy. Doświadczenie programistyczne daje praktyczną wiedzę na temat tego procesu, dlatego pomaga. Premierzy, którzy wspinają się po szczeblach kariery w firmie, dodatkowo znają kulturę korporacyjną (i bazę kodów) i nawiązują kontakt z innymi długoletnimi członkami zespołu programistów, dlatego zamiast tego awansowani są najlepsi premierzy IMO od wewnątrz sprowadzenia z zewnątrz. Jeśli ktoś spoza firmy może lepiej zarządzać zespołem niż ktoś z wewnątrz, to BARDZO źle.

Jedną z rzeczy, o których wspomniałem, jest relacja między premierem a zespołem programistów. Jest to zarówno na poziomie interpersonalnym, jak i technicznym. Kluczem tutaj jest komunikacja; deweloperzy muszą czuć, że mogą wnieść problemy, zarówno techniczne, jak i interpersonalne, do PM, a PM musi zrozumieć członków zespołu deweloperów, kiedy opisują problem.

Jeśli chodzi o specyfikę twojego pytania, oszacowanie jest dokładnie takie; wykształcone domysły co do ilości (w przeciwieństwie do hipotezy, która jest bardziej ogólną prognozą wyniku przyszłego wydarzenia). Menedżer zwykle albo matematycznie, albo intuicyjnie zastosuje modyfikator na podstawie twoich ostatnich szacunków w stosunku do faktycznych ram czasowych. Zwinny wbudowuje to w proces szacowania; klient intuicyjnie ocenia złożoność wymagań, następnie deweloperzy robią to samo, a następnie deweloperzy faktycznie wychodzą i opracowują rozwiązanie, dając menedżerom punkty danych do obliczenia stosunku punktów wymagań do punktów deweloperskich i punktów deweloperskich do człowieka -godzinne wymagania.

W skrócie, menedżer weźmie twoje oszacowanie według wartości nominalnej tylko w jednym z trzech scenariuszy:

• W przeszłości byłeś bardzo dokładny w swoich szacunkach podobnych zadań.
• Jest pod presją dostarczenia, a twoje oszacowanie jest lepsze niż myślał.
• On szuka powodu, by cię zwolnić.

Jeśli to ta ostatnia sytuacja, w miejscu pracy będzie wiele innych wskazówek, które być może powinny się wydostać.

Nie mam pojęcia, ale mój żłób potrzebuje wiedzy technicznej. Czasami nie da się go wyjaśnić.