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

A volte non lo sopporto quando i project manager mi chiedono di stimare il tempo necessario per completare varie attività. Una stima è un'ipotesi e le ipotesi possono essere sbagliate. Generalmente, i requisiti e la documentazione errati porteranno a ipotesi errate.

Quindi spesso mi chiedo se i project manager siano mai stati nei miei panni cercando di indovinare quanto tempo impiegheranno X e Y e quanto sia difficile assegnargli un numero in base a quanto poco è noto e raccolto dal cliente.

La mia domanda allora è: i bravi project manager devono avere un background di programmazione?

O forse la domanda dovrebbe essere : i bravi project manager devono essere stati un buon programmatore prima? C'è qualche correlazione?

La gestione dei progetti IT non è sicuramente la stessa della gestione di altri tipi di progetti. Una volta ho sentito parlare di un project manager senza esperienza IT. Alla fine ha frustrato i programmatori e sostanzialmente li ha spaventati.

D'altra parte, un programmatore che diventa un Project Manager può diventare un maniaco del controllo, pensando di poter sistemare le cose se non riesce a convincere i programmatori a farlo correttamente (che è stato il mio problema in situazioni simili)

Un manager con un forte background tecnico di solito capisce meglio come "pensa" il suo team. È sempre meglio avere un manager che ti capisca, 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 le attività associate e un buon motivatore non dipendono affatto dalla capacità di programmare.

A parità di altre condizioni, preferirei un project manager con una forte esperienza tecnica aggiornata . Tuttavia, nel mondo reale, i programmatori che si diplomano in project management a tempo pieno hanno maggiori probabilità di consentire al loro set di competenze di diventare obsoleto e obsoleto, il che non è molto meglio di loro che non hanno un background tecnico.

Ho lavorato con buoni project manager e alcuni terribili, e posso onestamente dire che ho visto poca correlazione tra la loro capacità di gestione e il loro background tecnico. Il fattore più importante non è il background tecnico, ma quanta esperienza hanno nella gestione di progetti software . Se hai due persone che gestiscono il loro primo progetto, il programmatore che si laurea in project management sarà altrettanto cattivo del project manager senza background IT. Entrambi passeranno attraverso un ripido processo di apprendimento.

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

Sinceramente penso che la risposta sia no. C'è un intero bagaglio di competenze richieste per essere un buon project manager ed essere un programmatore non è uno di questi. Un buon project manager potrebbe gestire qualsiasi progetto di qualsiasi tipo dato che ci sono brave persone nel team di progetto che sanno cosa stanno facendo. La qualità principale che un project manager dovrebbe avere sono le capacità comunicative . Il compito di un project manager è quello di coordinare le attività del progetto e mantenere le comunicazioni tra il cliente, i team di progetto e tutti gli altri stakeholder. Dovrebbe sapere in ogni momento i progressi della squadra e se stanno vivendo blocchi, ma non ha bisogno di sapere qual è il problema o di cosa hai bisogno per risolverlo, a meno che non implichi un'altra persona nella squadra il cui tempo lo farà deve essere modificato per aiutare a risolvere il problema.

Per quanto riguarda le stime, questa è una realtà della vita in qualsiasi lavoro. Non potresti mai costruire una casa in tempo se l'elettricista non potesse dirti quanto tempo ci vorrà per fare il cablaggio - quando sapresti prenotare il tuo ragazzo delle pareti? Concordo tuttavia sul fatto che è davvero difficile fornire stime dell'IT a causa dell'elevato numero di imponderabili. I clienti non sanno sempre cosa vogliono e tendono a dimenticare di dirti un sacco di cose. Quello che ero solito fare è stimare approssimativamente quanto tempo avrei pensato, quindi moltiplicarlo per 2! E un buon manager di programma non dovrebbe crocifiggerti quando il tuo preventivo si rivela sbagliato, gli farà venire il mal di testa per riorganizzare il programma, parlare con il cliente, spiegare ai capi che costerà di più, ecc ... Ma fa parte del loro lavoro - di nuovo, sono principalmente ciò che è richiesto.

E direi anche che non avere alcuna abilità di programmazione è ancora meglio - un ex programmatore potrebbe tentare di fare la stima da solo o secondo le tue stime. E sappiamo tutti che le competenze IT sono superate molto velocemente. Devi iniziare a fare domande quando il tuo project manager è più interessato a come farai un'attività che a quanto tempo potrebbe richiedere e quando avrai finito. Potrebbero chiederti di valutare alternative e farti svelare i dettagli, ma il punto principale è sapere come influenzerai il programma del progetto.

Infine, non sto dicendo che non sono necessarie competenze IT per gestire un progetto IT: le persone IT sono il tipo che proprio non sembra essere in grado di volgarizzare ciò che stanno dicendo per la gente comune (!), Aiuta a conoscere il gergo di base per poter comunicare con loro! Anche conoscere i passaggi di base è fondamentale : è necessario 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 finire il cablaggio prima di chiudere le pareti !!

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

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

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

Sebbene il background IT sia un ulteriore vantaggio, la sua mancanza non lo rende un manager di progetto IT non così buono. Anche avere un background IT non è il fattore decisivo.

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

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

Senza background informatico:
- Sarebbe molto comodo negoziare per cambiare una scadenza comoda
- Per un progetto senza requisiti (per niente), 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 background di programmazione. In caso contrario, faranno sempre pressioni sui programmatori per far sì che i loro compiti siano rapidi e si aspettano che vengano svolti entro poche ore, quando in realtà l'attività richiede molta riflessione e dedizione. Queste qualità sono note e ben conosciute dai 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.

@NimChimpsky Sono d'accordo.

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

La stima funziona per piccoli compiti tecnici, ma per la pianificazione è necessario lavorare insieme per vedere l'intera complessità. E non sei rivale.

Sarebbe sicuramente utile soprattutto se il loro non è un buon project manager. Per un buon project manager è davvero importante.

No.

Un buon project manager è qualcuno che può comprendere e comprendere quali sono le esigenze, le preferenze e le capacità del suo team, sia che si tratti del cantiere, del reparto di produzione o della casa di sviluppo del software.

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

I cattivi manager con background tecnici avrebbero potuto essere programmatori di asso che non apprezzano la difficoltà che i novizi affrontano quando hanno a che fare con concetti banali e "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 comprendeva a memoria le lezioni di The Mythical Man Month perché ha vissuto lui stesso giorni di programmazione e sono stato masticato per non aver finito i suoi risultati in tempo.

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

Le conoscenze tecniche non predeterminano le qualifiche di un programmatore come manager, poiché le competenze richieste in entrambi i lavori sono completamente diverse. Quindi no.

Non ho mai visto un project manager senza esperienza IT in grado di gestire un progetto di sviluppo software non banale degno di nota. Ho visto pochissimi project manager con esperienza IT che potevano farlo, ma sembravano rovinarli di meno.

Nella mia esperienza, la gestione riguarda una comunicazione e un processo decisionale efficaci. Con questo in mente, ha senso che qualcuno che capisca i mestieri (almeno i concetti chiave e la terminologia) utilizzati dalle persone che gestiscono, è più adatto per 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, altrettanto spesso come manager senza esperienza di programmazione.

O l'estremo è cattivo, secondo me; Le persone con troppo poca esperienza di programmazione possono fidarsi ciecamente dei loro programmatori (Shepard segue le pecore); Le persone con troppa esperienza possono continuamente mettere in discussione gli sforzi del proprio team (micro gestione).

Personalmente, penso che qualcuno che abbia una buona conoscenza dei concetti di programmazione di base, ma si renda conto che non sono un "colpo grosso", è il tipo ideale di manager.

Decisamente.

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

Sto lavorando come ingegnere del software e abbiamo un project manager con il quale sto lavorando molto ultimamente. Non ha un background tecnico e sembra che non gli interessi affatto, ma non è questo il problema (ognuno ha i propri interessi). Se non ti piace avere un know-how tecnico perché è un po '"strano" di quanto lo sia MA MA se il tuo compito è parlare con il cliente a livello tecnico, è essenziale avere un know-how tecnico che lui non ha 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 ho la sensazione che non sappia NIENTE. Quindi ogni volta che sto provando a fargli capire cosa dobbiamo fare ora o qual è il problema che abbiamo al momento non capisce niente. E non è quel tipo di ragazzo che direbbe "Aspetta un secondo. Puoi ripetere che davvero non lo capisco del tutto.". No, è 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 sostanzialmente non è vero. E finisce che dobbiamo chiamare il cliente insieme per chiarire di nuovo.

Ecco perché dico che è davvero ESSENZIALE avere un background 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.

A proposito, da quando lavoro con lui il mio lavoro non è più divertente.

Direi di sì, dovrebbe avere un background di programmazione. Se il manager non ha la minima idea di cosa significhi programmare, finirà con stime non realistiche per lo sviluppo e la correzione dei bug. Inoltre, non avrebbe capito abbastanza bene qualsiasi problema tecnico per 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 cacciando in giro

Le competenze tecniche non sono un buon manager, come le buone capacità di gestione. Può essere utile se un manager ha trascorso il suo tempo nelle "trincee" in quanto può apprezzare il processo che i laici non possono avere. Tuttavia, può anche tradursi in una sorta di maniaco del controllo che persino i maniaci dei laici non riescono a controllare. Potrebbero provare a fare tutto il lavoro da soli o esaminare il tuo in modo estremamente scomodo.

Nella mia esperienza personale, il miglior manager che abbia mai avuto era abbastanza all'oscuro della 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 sotto di lui per quattro anni, e ho lasciato l'azienda solo perché era partito ed era stato sostituito da un manager che non era altrettanto bravo.

Uno dei peggiori gestori che ho avuto è esperto di programmazione (se non di progettazione di software) e fa così tanto lavoro da solo che lascia il resto di noi con poco più di scarti, correzione di errori o progetti che non vuole fare se stesso.

Sembra esserci un po 'di confusione:

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

Le stime non sono perfette. Penso che il Primo Ministro lo capisca più di quanto si pensi. Pensi seriamente che nessuno ti chiederà mai quanto tempo ci vorrà per fare qualcosa? Tutti vogliono sapere quando è finito ed è compito del PM seguirlo.

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

Determinare se i programmatori stanno facendo abbastanza non è compito del PM a meno che non diventi il ​​caposquadra. Per sapere se qualcuno sta "soffiando fumo" circa il tempo necessario per completare un'attività, un manager avrà sempre un vantaggio se capisce cosa è coinvolto.

Le stime migliorano con programmatori esperti che hanno una storia di lavoro su un particolare tipo di progetto. Nessuno si aspetta che siano perfetti, ma si aspettano che 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 necessario per un buon PM software, ma di solito è preferito. Ciò che è fondamentale per essere un PM capace è comprendere il processo di sviluppo (qualunque sia la metodologia utilizzata) e fidarsi che gli sviluppatori siano disposti e in grado di fare il loro lavoro. L'esperienza di sviluppo fornisce una conoscenza pratica di quel processo, quindi aiuta. I PM che si arrampicano su per le scale 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, motivo per cui IMO i migliori PM sono promossi dall'interno invece di essere portato dall'esterno. Se qualcuno al di fuori dell'azienda può gestire la squadra meglio di 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 pensare di poter portare problemi, sia tecnici che interpersonali, al PM, e il PM deve capire i membri del team di sviluppo quando descrivono un problema.

Quanto alla natura specifica della tua domanda, una stima è esattamente questo; un'ipotesi ponderata su una quantità (al contrario di un'ipotesi, che è una previsione più generale del risultato di un evento futuro). Il gestore di solito applica matematicamente o intuitivamente alcuni modificatori, in base alle stime recenti rispetto alle tempistiche effettive. Agile inserisce questo nel processo di stima; il client stima intuitivamente la complessità dei requisiti, quindi gli sviluppatori fanno lo stesso, quindi gli sviluppatori escono e sviluppano la soluzione, fornendo al gestore punti dati per calcolare un rapporto tra i requisiti requisiti e punti dev, e punti dev all'uomo - i tuoi requisiti.

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

• Sei stato abbastanza preciso con le tue stime di attività simili in passato.
• È sotto pressione per consegnare 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 ottenere.

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