I buoni project manager hanno bisogno di un background di programmazione? [chiuso]

Gestire i progetti IT non è sicuramente la stessa cosa che gestire altri tipi di progetti. Una volta ho sentito parlare di un project manager con no esperienza IT. Ha finito per frustrare i programmatori e fondamentalmente spaventarli via.

D'altra parte, un programmatore che diventa Project Manager può diventare un maniaco del controllo, pensando di poter aggiustare le cose se (s) non può ottenere che i programmatori lo facciano correttamente (questo è stato il mio problema in situazioni simili )

Un manager con un strong background tecnico di solito capisce meglio come la loro squadra "pensa". È sempre meglio avere un manager che ti capisca, non è vero?

No. Due abilità completamente diverse. Un cattivo project manager non è necessariamente qualcuno che non capisce l'IT, e viceversa.

Essere ragionevoli, razionali, organizzati, comprendere gli obiettivi del progetto e il business associato, e un buon motivatore non dipende affatto dalla possibilità di programmare.

A parità di condizioni, preferirei un project manager con una strong esperienza tecnica up-to-date . Tuttavia, nel mondo reale, i programmatori che si sono laureati in project management a tempo pieno hanno più probabilità di lasciare che il loro set di competenze diventi obsoleto e obsoleto, il che non è molto migliore di quelli che non hanno background tecnico.

Ho lavorato con buoni project manager e alcuni terribili, e posso dire onestamente che ho visto poche correlazioni tra le loro capacità di gestione e il loro background tecnico. Il fattore più importante non è il background tecnico, ma quanta esperienza hanno gestito i progetti software . Se hai due persone che gestiscono il loro primo progetto, il programmatore che si laurea in project management sarà altrettanto pessimo come il project manager senza background IT. Entrambi stanno per passare attraverso un processo di apprendimento ripido.

L'argomento sulla capacità dei project manager senza uno sfondo tecnico mi ricorda un po 'di questo:

Onestamente penso che la risposta sia no. C'è un intero bagaglio di competenze richiesto per essere un buon project manager e essere un programmatore non è uno di questi. Un buon project manager può gestire qualsiasi progetto di qualsiasi tipo visto che ci sono brave persone nel team di progetto che sanno cosa stanno facendo. La qualità principale che un project manager dovrebbe avere è capacità di comunicazione . Il lavoro di un project manager è quello di coordinare le attività del progetto e mantenere le comunicazioni fluide tra il cliente, i team di progetto e qualsiasi altro stakeholder. Lui / lei dovrebbe conoscere in ogni momento i progressi della squadra e se stanno vivendo dei blocchi stradali, ma non ha bisogno di sapere qual è il problema o cosa è necessario per risolverlo, a meno che non implichi un'altra persona nella squadra il cui tempo sarà bisogno di essere regolato per aiutare a risolvere il problema.

Per quanto riguarda le stime, questa è una realtà della vita in qualsiasi lavoro. Non si potrebbe mai ottenere una casa costruita in tempo se l'elettricista non è in grado di dirti quanto ci vorrà per fare il cablaggio - quando sapresti prenotare un ragazzo sulle pareti? Sono d'accordo, tuttavia, che è davvero difficile per l'IT fornire stime a causa dell'elevato numero di imponderabili. I clienti non sempre sanno quello che vogliono e tendono a dimenticare di dirti un sacco di cose. Quello che facevo era stimare approssimativamente quanto tempo pensavo che sarebbe occorso, quindi moltiplicarlo per 2! E un buon program manager non dovrebbe crocifiggerti quando la tua stima si rivela sbagliata, gli causerà dei grattacapi per riorganizzare il programma, parlare con il cliente, spiegare ai capi che costerà di più, ecc ... Ma questo fa parte del loro lavoro - di nuovo, le buone capacità di comunicazione sono principalmente ciò che è richiesto.

E direi anche che non avere competenze di programmazione è ancora meglio - un ex programmatore potrebbe tentare di fare la stima da solo o secondo le stime. E sappiamo tutti che le competenze informatiche diventano obsolete molto velocemente. Hai bisogno di iniziare a fare domande quando il tuo project manager è più interessato a come stai andando a fare un compito che a quanto tempo ci vorrà e quando avrai finito. Potrebbero chiederti di valutare le alternative e lasciarti sfuggire i dettagli, ma il punto principale è sapere come influenzerai il programma del progetto.

Infine, non sto dicendo che non sono necessarie competenze informatiche per gestire un progetto IT - le persone IT sono il tipo che proprio non riescono a essere in grado di volgarizzare ciò che stanno dicendo per la gente comune (!), aiuta per conoscere il gergo di base per poter comunicare con loro! Inoltre conoscere i passaggi di base è fondamentale - devi configurare un server prima di eseguire un sito web su di esso. Non potrei gestire un progetto di costruzione se non sapessi che l'elettricista deve terminare il cablaggio prima di chiudere i muri !!

Un PM ha davvero bisogno di sapere cosa farà il progetto, il che probabilmente richiede un background tecnico ma non in via di sviluppo.

Oltre a questo, si tratta di avere rispetto per il campo e gli sviluppatori, più della conoscenza effettiva. Un PM ha bisogno di prendere sul serio gli sviluppatori, di cosa hanno bisogno, cosa possono fare, cosa non possono, quanto tempo ci vorrà. Un PM che ha qualche idea di ciò che lui o lei non sa può essere molto efficace. Un PM che pensa di avere tutte le risposte è cattivo. Questo può essere un ex-sviluppatore che crede di sapere tutto o no, o uno che non ha mai sviluppato e non crede di aver bisogno di conoscenze tecniche particolari da gestire.

Non penso che un project manager di un progetto IT richieda un background IT. Ma lui / lei deve capire definitivamente l'IT e dovrebbe sapere come funzionano i progetti IT.

Sebbene il background IT sia un vantaggio aggiunto, la sua mancanza non fa di un project manager IT non molto bravo. Anche avere uno sfondo IT non è il fattore decisivo.

Ho lavorato con entrambi i tipi e ognuno di loro ha il suo insieme unico di qualità e problemi.

Con backround IT:
 - Capirebbe quando diciamo errore di prestazione perché il codice non è multi-threaded  - Ma in alcune situazioni, direi "hey dai, sta solo aggiungendo 4 righe di codice, puoi farlo in 10 giorni"

Senza background IT:
 - Sarebbe molto comodo negoziare per cambiare una scadenza constrongvole
 - Per un progetto senza requisiti (ancora), a volte direi "possiamo dare una stima approssimativa di 100 giorni e menzionare un buffer del 30%.

Credo che abbiano bisogno di un po 'di programmazione. In caso contrario, faranno sempre pressione sui programmatori per le loro attività in fretta e si aspettano che venga fatto entro poche ore, quando in realtà l'attività richiede molto pensiero e dedizione. Queste qualità sono note e ben conosciute con i programmatori, quindi se il project manager ha un background di programmazione, allora capirà quanto tempo impiegherà un compito specifico e non ci saranno argomenti all'interno del dipartimento e quindi alla fine si evolverà un buon progetto. / p>     

@NimChimpsky Sono d'accordo.

È una questione di cosa , non come (l'ascolto attivo è uno strumento piacevole).

La stima funziona per piccoli compiti tecnici, ma per la pianificazione è necessario collaborare per vedere l'intera complessità. E tu non hai rivali.

Sarebbe sicuramente di aiuto soprattutto se non sono un buon project manager. Per un buon project manager è davvero importante.

No.

Un buon project manager è una persona in grado di comprendere e comprendere le esigenze, le preferenze e le capacità della sua squadra, sia che si tratti del cantiere, della produzione o della casa di sviluppo del software.

Un project manager buono o cattivo può avere qualsiasi tipo di background:

Cattivi manager con background tecnici potrebbero essere stati programmatori esperti che non apprezzano la difficoltà che i novizi devono affrontare quando si occupano di concetti banali, "facili" come i puntatori.

Un buon manager potrebbe essere quel programmatore medio che non era brillante o intelligente come i suoi colleghi, ma aveva una profonda comprensione della struttura del progetto, dei requisiti e ha capito a memoria le lezioni di The Mythical Man Month perché lui visse giorni di programmazione sbagliati e si morse per non aver terminato i suoi risultati in tempo.

Un buon manager potrebbe essere quel venditore di software che ha scoperto che i suoi amici programmatori non potevano uscire con lui nei fine settimana a causa di promesse non realistiche che lui stesso aveva dato al cliente.

Le conoscenze tecniche non predeterminano le qualifiche di un programmatore come manager, perché gli skillset richiesti in entrambi i lavori sono completamente diversi. Quindi no.

Non ho mai visto un project manager senza esperienza IT in grado di gestire un progetto di sviluppo software non banale che valga la pena. Ho visto pochissimi project manager con esperienza IT che potevano farlo, ma sembravano averli rovinati di meno.

Nella mia esperienza, la gestione riguarda l'efficacia della comunicazione e del processo decisionale. Con questo in mente, è logico che qualcuno che capisce i mestieri (almeno i concetti base e la terminologia) utilizzati dalle persone che gestiscono, è più adatto a essere un manager di qualcuno che ha meno di una comprensione, ma c'è sicuramente Nessuna correlazione. Ho visto manager con esperienza di programmazione avere successo e fallire, con la stessa frequenza dei manager senza esperienza di programmazione.

O estremo è cattivo, secondo me; Le persone con una scarsa esperienza di programmazione possono fidarsi ciecamente dei loro programmatori (Shepard che segue le pecore); Le persone con troppa esperienza possono continuamente mettere in discussione gli sforzi della loro squadra (gestione micro).

Personalmente, penso che qualcuno che ha una buona conoscenza dei concetti di programmazione di base, ma si rende conto che non sono un "hot shot", è il tipo di manager ideale.

Sicuramente.

Devo stare attento a questo perché è basato su storie vere ma cercherò di spiegare il mio dolore.

Lavoro come ingegnere software e abbiamo un project manager con cui sto lavorando molto ultimamente. Non ha un background tecnico e sembra che non lo interessi affatto ma non è questo il problema (ognuno ha i propri interessi). Se non ti piace avere un know-how tecnico è un po '"bizzarro" di quanto sia tuo, MA se è tuo compito parlare con il cliente a livello tecnico è essenziale avere un know-how tecnico che non avere.

Comunque c'è questo ragazzo che non capisce nulla su come funziona un server, come funziona una pagina web, come funziona la programmazione e così via. A volte mi sembra che non sappia NIENTE. Quindi ogni volta cerco di spiegargli cosa dobbiamo fare ora o quale sia il problema che abbiamo nel momento in cui non capisce nulla. E lui non è quel tipo di ragazzo che direbbe "Aspetta un attimo, puoi ripetere che non lo capisco davvero". No, lui è quel tipo di ragazzo che non vuole dimostrare di non aver capito nulla nell'intera conversazione.

Ma non finisce qui perché chiama quindi il cliente e parla di qualcosa che in pratica non è vero. Ed è finita che dobbiamo chiamare insieme il cliente per renderlo nuovamente chiaro.

Ecco perché dico che è ESSENZIALE avere un bagaglio tecnico di base e un know-how tecnico. Non dovrebbe essere in grado di scrivere codice ma dovrebbe essere in grado di capire cosa sta succedendo e quali processi devono essere eseguiti.

Dal momento che sto lavorando con lui, il mio lavoro non è più divertente.

Direi di sì, dovrebbe avere qualche background di programmazione. Se il manager non ha idea di cosa significhi programmare, si ritroverà con stime non realistiche per lo sviluppo e il bug fixing. Inoltre, non avrebbe capito alcun problema tecnico abbastanza bene da prendere una decisione. I programmatori del team potrebbero mentirgli e potrebbe non rendersene conto, anche i programmatori potrebbero dirgli un problema e potrebbe pensare che stiano cazzeggiando in giro

Le capacità tecniche non sono un buon manager, buone capacità di gestione. Può essere utile se un manager ha fatto il suo tempo nelle "trincee" in quanto può avere un apprezzamento del processo che i laici non possono avere. Tuttavia, può anche risultare in una sorta di mania del controllo che persino i maniaci del maniaco del controllo non hanno. Possono provare a fare tutto il lavoro da soli o scrutare il tuo in un modo estremamente scomodo.

Nella mia esperienza personale, il miglior manager che abbia mai avuto è stato abbastanza indiscusso sulla tecnologia, ma sapeva che le persone che lavoravano sotto di lui conoscevano le loro cose e sapeva come guadagnare la lealtà e il rispetto della sua squadra. Ho lavorato con lui per quattro anni, e ho lasciato l'azienda solo perché era partito e sostituito da un manager che non era altrettanto bravo.

Uno dei peggiori manager che ho avuto è versato nella programmazione (se non nella progettazione di software) e fa così tanto del lavoro da solo che lascia il resto di noi con poco più di scarti, bug fixing o progetti che non fa voglio fare se stesso

Sembra esserci un po 'di confusione:

Il PM non è il capo degli sviluppatori . Il responsabile del team di sviluppo (Team Leader, Manager) e le assunzioni e le valutazioni dovrebbero decidere se stai lavorando abbastanza duramente.

Le stime non sono perfette. Penso che il PM lo capisca più di quanto pensi. Ti aspetti seriamente che nessuno ti chieda mai quanto ci vorrà per fare qualcosa? Everyboy vuole sapere quando è finito e il compito del PM è di seguirlo.

Puoi essere un PM sei tu: A) capire come gestire i progetti B) capire il processo di sviluppo. Nessuno di questi richiede la conoscenza della codifica, ma può aiutare.

Determinare se i programmatori stanno ottenendo abbastanza risultati non è il lavoro del PM, a meno che non diventi il capo della squadra. Per sapere se qualcuno sta "soffiando fumo" sul tempo necessario per completare un compito, un manager avrà sempre un vantaggio se capisce cosa è coinvolto.

Le stime migliorano con i programmatori esperti che hanno una storia di lavoro su un particolare tipo di progetto. Nessuno si aspetta che siano perfetti, ma si aspettano che tu ti avvicini e migliori nel tempo.

Mi viene in mente il vecchio detto: "non devi essere pazzo per lavorare qui, ma aiuta".

La risposta breve è che l'esperienza pratica di codifica non è un requisito di un buon software PM, ma di solito è preferibile. Ciò che è fondamentale per essere un PM in grado è comprendere il processo di sviluppo (qualunque sia la metodologia utilizzata) e fidarsi del fatto che gli sviluppatori siano disposti e in grado di fare il loro lavoro. L'esperienza di sviluppo dà una conoscenza pratica di quel processo, quindi aiuta. I PM che si fanno strada nella scala in un'azienda conoscono inoltre la cultura aziendale (e la base di codice) e hanno un rapporto con gli altri membri di lunga data del team di sviluppo, ed è per questo che i migliori PM vengono promossi dall'interno di essere portato dall'esterno. Se qualcuno al di fuori della compagnia è in grado di gestire meglio la squadra rispetto a qualcuno dall'interno, le cose sono MOLTO sbagliate.

Una cosa che ho menzionato è un rapporto tra il PM e il team di sviluppo. Questo è sia a livello interpersonale che a livello tecnico. La chiave qui è la comunicazione; gli sviluppatori devono sentirsi in grado di portare problemi, sia tecnici che interpersonali, al PM, e il PM deve capire i membri del team di sviluppo quando descrivono un problema.

Per quanto riguarda la natura specifica della tua domanda, una stima è esattamente quella; un'ipotesi istruita su una quantità (al contrario di un'ipotesi, che è una previsione più generale dell'esito di un evento futuro). Il gestore applicherà in genere matematicamente o intuitivamente alcuni modificatori, in base alle stime recenti rispetto alle scadenze effettive. Agile crea questo nel processo di stima; il cliente stima in modo intuitivo la complessità dei requisiti, quindi gli sviluppatori fanno lo stesso, e quindi gli sviluppatori escono e sviluppano la soluzione, fornendo ai punti dati del manager il calcolo di un rapporto tra i punti di fabbisogno e i punti di dev per l'uomo -quattro requisiti

In breve, un gestore prenderà la stima al valore nominale solo in uno dei tre scenari:

• Sei stato abbastanza preciso con le tue stime di attività simili in passato.
• È sotto pressione per la consegna e la tua stima è migliore di quanto pensasse.
• Sta cercando un motivo per licenziarti.

Se è l'ultima situazione, ci saranno molti altri indizi sul posto di lavoro che forse dovresti andare fuori di testa.

Non ne ho idea, ma la mia mangiatoia ha bisogno di conoscenze tecniche. È impossibile spiegarlo a volte.