Sono un manager Come posso migliorare i rapporti di lavoro e la comunicazione con i programmatori? [chiuso]

Prima un po 'di background. Sono un project manager presso un'azienda di medie dimensioni. Ho iniziato come CS major e ho avuto una piccola esposizione alla programmazione, ma dopo alcuni mesi ho capito che non era il mio percorso, quindi sono passato al management. È stata una buona decisione, e dopo la laurea ho lavorato nella gestione del software in varie aziende (ormai da 5 anni).

Di recente, abbiamo avuto un progetto molto doloroso. È stato il peggio del peggio, con molti errori sia dalla nostra parte che da parte dei clienti e ha appena terminato senza perdite. Ha portato a molte situazioni frustranti, una delle quali si è intensificata al punto in cui uno dei nostri sviluppatori senior ha lasciato la compagnia dopo una discussione vocale con noi (la direzione). Questa è stata una bandiera rossa per me: ho fatto qualcosa di terribilmente sbagliato. (per la cronaca, l'argomento riguardava diverse stime temporali errate)

Ho cercato risposte in molti luoghi e un amico mi ha indicato questo sito. Ci sono molte domande qui sulle frustrazioni con la gestione. Posso capire che le brutte esperienze generali portano a una generale riluttanza contro "quei ragazzi in giacca e cravatta".

Sono quel ragazzo in giacca e cravatta. Potrebbe non sembrare, ma tutto ciò che voglio è un progetto di successo e con risorse limitate prende decisioni dolorose. È il mio lavoro. Una delle cose di cui il suddetto sviluppatore senior si lamentava era l'attrezzatura di lavoro. Francamente, non avevo idea che i computer che avevamo non erano adatti per funzionare. Dopo ciò, ho chiesto a molti programmatori e il consenso generale era che abbiamo bisogno di macchine migliori. L'ho risolto da allora, ma c'era ovviamente un enorme divario comunicativo tra me e i programmatori. Alcuni degli sviluppatori più brillanti sono le persone più timide e silenziose. Lo so, e non è mai stato un problema durante un'intervista. Le persone sono diverse e hanno punti di forza in diverse aree.

Il caso dei PC sottodimensionati è solo uno dei tanti che mi hanno portato a pensare che ci sia un problema di comunicazione. Come posso migliorare la comunicazione con i programmatori senza essere intimidatorio e ripetitivo?

Ciò che spero è che le persone non si lamentino delle cose buone. Se ami il tuo posto di lavoro e ami (o almeno come :)) il tuo manager, per favore parlamene. Cosa stanno facendo bene? Allo stesso modo, se lo odi, descrivi in ​​dettaglio perché. Sto cercando risposte su come migliorare la comunicazione perché penso che sia un mio problema, ma potrei sbagliarmi.

Wow! Grazie per avermelo chiesto. Tecnicamente, come te, immagino di essere un manager, dal momento che passo molto più tempo a comunicare e guidare team che a scrivere codice .... ma ecco il mio punto di vista da entrambe le estremità dell'orizzonte di gestione. Che io sia uno sviluppatore o un manager che lavora per un altro manager, ecco alcune cose che aiutano nella mia comunicazione con la mia direzione:

• Perché? è una domanda molto importante: quasi ogni risposta concreta ha un "perché" dietro e quel "perché" potrebbe essere più importante della domanda reale. Ci sono alcune tangenti a questo:
  • Lo sviluppatore Perché - Gli sviluppatori avranno molte risposte che non hanno assolutamente senso per il management. Certamente l'ho fatto e uno dei modi in cui sono entrato nel management è stato davvero bravo a spiegare i "perché" dei team in termini che il management potesse capire. Se non hai un "oratore per i geek" a portata di mano, puoi imparare a parlare geek riaffermando le loro risposte alla domanda sul perché nelle metafore più comunemente comprese. Continuate fino a quando entrambi capirete e sarete d'accordo su ciò che sta succedendo.
  • La gestione Perché- il tuo "perché" è altrettanto importante. Perché hai bisogno delle stime del tempo? Per cosa li stai usando? Quanto saremo fregati come azienda se sono troppo alti o troppo bassi? Questa è roba di cui probabilmente hai una profonda conoscenza da parte del manager, ma è tutto voodoo per lo sviluppatore. Il trucco è che lo sviluppatore potrebbe non chiedere. Il management gli ha chiesto qualcosa e farà del suo meglio per essere accurato, puntuale e premuroso, ma se non conosce il "perché" potrebbe ottimizzare in modi che preferiresti non aver fatto. Offri il tuo perché e chiedigli di fare la stessa cosa - ribadisci la risposta alle sue condizioni.

Riguardo alle stime dei tempi in particolare - Ho dovuto fare un sacco e ho tratto grande profitto dal dire al mio team di sviluppo "Ne ho bisogno perché chiederò più soldi per pagare i nostri stipendi, mi fiderò di ciò che mi dirai e Userò i tuoi numeri ... ciò significa che se mi lanci una palla bassa, saremo tutti fregati perché non potrò chiedere soldi una seconda volta, dobbiamo convivere con ciò che proponiamo ". In quel contesto, gli sviluppatori sono passati da stime basse che hanno tentato di mostrarmi quanto fossero sicure e brillanti a stime elevate che si sono avvicinate molto di più alle aspettative reali.

• Nessuno ha torto - La domanda "perché" va molto a lungo con un corollario - chiedere "perché" invece di dire "è scandaloso! Assolutamente!" mantiene la conversazione fluente. A volte c'è una forte disconnessione tra ciò che viene chiesto a qualcuno e ciò che il richiedente chiede. Il mio miglior management è stato orribilmente sorpreso dalle mie risposte, e quando sono sorpresi, sbattono le palpebre per lo stupore e poi chiedono "perché lo dici?". Non dicono (immediatamente) - "devi cambiarlo". Ho ridotto il numero delle proposte per raggiungere un obiettivo competitivo, ma solo dopo aver parlato intensamente di come potremmo cambiare la scena e creare un contesto diverso per la domanda.

• ascolta il rumore ambientale, la scelta delle parole e lo spazio tra le parole - Ecco un mucchio di cose che mi sono piaciute e rubate per usare me stesso:

  • esci nell'area di lavoro, fai qualcosa di produttivo per conto tuo (non cercare di entrare nel lavoro degli sviluppatori, sanno che non sei uno sviluppatore) e ascolta e basta. In che modo il team risolve i problemi? Quali sono i loro grandi problemi? Non sentirai mai il vero magro nella loro valutazione diretta di te o della gestione in generale, ma potresti avere davvero un'idea di dove siano le aree problematiche. Assicurati di fare qualcosa di tuo che sia produttivo. A nessuno piace spiare, ma a meno che il morale non sia così basso da non poter essere vicino a loro senza evacuare tutti, la produttività nelle vicinanze dovrebbe essere tollerabile.
  • cercare le parole scelte - spesso sono importanti quanto le parole stesse. Quando ho usato parole particolarmente positive o negative, la mia direzione mi chiede spesso perché ho scelto quelle parole quando è una situazione che non conoscono.
  • cercare pause, lacune e linguaggio del corpo. Se c'è una distanza di potere tra te e gli sviluppatori (e sembra che ci sia) potrebbero non voler contraddire o confrontarti. Ma l'istinto di base per dire "hey, ti sbagli" di solito si manifesta da qualche parte.

• aprirsi al maggior numero possibile di mezzi di comunicazione - essere pronti a chattare di persona, al telefono, via e-mail, tramite messaggistica istantanea - qualsiasi cosa per stabilire il flusso di comunicazione. Le persone sono così diverse che solo un trucco non funzionerà. E vedo come compito del manager essere il comunicatore multiformato, non lo sviluppatore.

• vale la pena parlarti Se qualcuno ti parla di un problema e forse di una possibile soluzione, dovrebbe e probabilmente accettare che tu sei il manager e quindi potrebbe decidere a favore di una soluzione diversa, o nessuna soluzione perché non lo fai penso che ne valga la pena. Ma dopo la terza volta ciò accade, soprattutto se accade senza una spiegazione, circa il 99% delle persone smetterà di dirti qualcosa.

Ed eccone uno che è incredibilmente difficile per me, ma ha funzionato benissimo quando posso farlo - siate consapevoli della differenza tra introversi ed estroversi . È probabile che tu sia un estroverso - ecco perché il tuo lavoro sembrava buono e una posizione di sviluppo no. Gli sviluppatori sono, per la maggior parte, introversi. "Introverso" non significa "impossibile comunicare", ma significa che il loro modello, processo e velocità sono significativamente diversi e l'impulso di comunicare incessantemente è praticamente inesistente. Pianifica nel tempo e nello spazio tranquillo (ma collocato) per far emergere i pensieri basati sull'introverso. Molti dei miei amici introversi mi dicono che stanno solo aspettando che io "zitto per circa 5 minuti" in modo da poter mettere insieme un pensiero e rispondere. Qui'5 cose che gli estroversi dovrebbero sapere sugli introversi e sui Rands in Repose on the Nerd Cave - un esempio particolarmente elaborato dagli sviluppatori di ciò che è fantastico per gli introversi . A proposito, Rands è piuttosto fantastico. È un fanatico di se stesso, quindi ci arriva da un focus dello sviluppatore, che può essere scoraggiante se non è il tuo stile, ma è divertente e ha delle intuizioni davvero buone sullo sviluppo del team.

Penso che la prima cosa che ho amato dei miei manager preferiti sia stata:

• erano profondamente impegnati ed entusiasti del progetto quanto me (se non di più)

• Non ho mai avuto dubbi sul fatto che mi avessero le spalle: sapevo con certezza che quando sarebbero stati di fronte al prossimo livello di autorità che io (o i miei coetanei) non saremmo mai stati i capri espiatori. Sarebbe sempre un fallimento del gruppo, se ci fosse un fallimento.

• Mi è stata data la proprietà di qualcosa di significativo e appropriato per le mie capacità in quel momento, ma con risorse sufficienti per espandere le mie capacità e svolgere il lavoro.

• mi vedevano sia come un individuo che come parte della squadra - erano attivamente impegnati a conoscere i miei punti di forza e di debolezza e lavorare per aiutarmi a giocare sui miei punti di forza e aumentare le mie debolezze.

• erano consapevoli dei miei obiettivi personali e interessati a incorporarli il più possibile

• erano in anticipo quando rendermi felice non poteva e non sarebbe stata una priorità. C'è un vero valore nell'udire "So che odi questo tipo di lavoro, ma ho bisogno che tu lo faccia - ecco come non sarà per sempre ...".

• c'era sempre tempo in una settimana (forse non nell'istante) per spiegare il quadro generale

• c'era un feedback e uno stato quasi costanti senza puntare il dito ma un sacco di riconoscimento per il lavoro individuale.

• c'era sempre la verità. Se qualcosa era sensibile e non poteva essere discusso, dissero così in bianco. Se qualcosa era incerto, davano un livello di sicurezza.

La parte facile prima: c'è una bandiera rossa tecnica nel tuo post: rabbrividisco alla tua menzione di "stime errate" - è una stima, NON PU CAN ESSERE MISTA , ecco perché si chiama stima. Può essere un po 'spento, può essere molto spento, ecco perché si chiama stima. Se stai prendendo delle stime come vangelo, questo sarà uno dei problemi principali che i "tuoi" sviluppatori stanno avendo con il tuo stile.

Tuttavia, sono d'accordo al 100% con te sulla difficoltà di comunicare con gli sviluppatori. Ho avuto una rivelazione diversi anni fa, come sviluppatore in una formazione sulla gestione di progetti. Ho visto molti dei miei colleghi sviluppatori assolutamente contrari alla direzione dopo la creazione di un'atmosfera aperta di discussione (la direzione era presente qui). Tutto ciò che era sbagliato era colpa dei gestori agli occhi degli sviluppatori. Il kicker era che il management non aveva idea di quasi tutti gli enormi problemi sollevati quel giorno. Gli sviluppatori presumevano che fosse così ovvio che il management non avrebbe potuto perderlo, e il management supponeva che gli sviluppatori avrebbero detto loro ciò di cui avevano bisogno.

Pertanto, IMHO la prima parte della risposta deve essere quella di far sapere ai tuoi sviluppatori che non sei un sensitivo, e in effetti probabilmente decisamente stupido quando si tratta del lato tecnico. Ti stai affidando, contando e fidandoti di venire da te in modo tempestivo. Sei lì per rendere la loro vita più facile, non più difficile.

E qualunque cosa tu faccia, NON porre loro domande a cui in realtà non vuoi conoscere la risposta - facendo riferimento alle "stime errate" sopra ;-). Questa è la kriptonite di uno sviluppatore.

Ci sono un sacco di cose buone qui, ma sento che bisogna dire quanto segue .. ..Ci dispiace essere duro .. Ma questo deve essere detto:

• 5 anni come PM e non sapere di che tipo di PC necessita uno sviluppatore, è scandaloso.
• Avere uno sviluppatore chiuso a causa di cattive condizioni di lavoro come la tua prima vera bandiera rossa, è folle.

Quello che penso tu abbia è un problema di fiducia , più che un problema di comunicazione. Nessuno dice cosa c'è che non va perché non si fidano di ciò che farai con quelle informazioni, e potrebbero anche temere che vengano usate contro di loro. Lo sviluppatore che ti ha parlato di tutti questi problemi lo ha fatto perché non ci sono state conseguenze nel farlo, ha smesso.

Personalmente non assumerei mai un PM che non avesse esperienza di sviluppo nel suo background. Penso al tuo prossimo progetto, dovresti dedicare una piccola parte del tuo tempo come parte del Dev. squadra . Di '8 ore a settimana, lavorando come sviluppatore Jr sotto la guida del team.

Questo ti aprirà davvero gli occhi sulle dinamiche di un team di sviluppo, perché in questo momento, non fai nemmeno parte di quel team, sei un estraneo. Il fatto che il tuo dev smesso sia stato uno shock per te, lo dimostra. Tutti nella squadra sapevano che era infelice. E nessuno di loro ti ha detto:

"Perderemo il nostro ragazzo migliore se non fai qualcosa"

Dovrebbe essere la bandiera rossa n. 2.

Come manager sono sicuro che hai sentito parlare di kaizen , uno dei principi del Toyota Production System che significa miglioramento continuo .

Hai ammesso di avere un problema, quindi è un ottimo inizio.

Kaizen ha cinque elementi principali:

• Circoli di qualità : gruppi che si incontrano per discutere i livelli di qualità riguardanti tutti gli aspetti della gestione di un'azienda.

• Morale migliorato : un forte morale tra la forza lavoro è un passaggio cruciale per raggiungere l'efficienza e la produttività a lungo termine e il kaizen lo pone come compito fondamentale per mantenere un contatto costante con il morale dei dipendenti.

• Lavoro di squadra : un'azienda forte è un'azienda che mette insieme ogni passo del cammino. Kaizen mira ad aiutare i dipendenti e i dirigenti a guardarsi come membri di una squadra, piuttosto che concorrenti.

• Disciplina personale : una squadra non può avere successo senza che ogni membro della squadra sia forte in se stesso. Un impegno nella disciplina personale da parte di ciascun dipendente garantisce che il team rimarrà forte.

• Suggerimenti per il miglioramento : richiedendo feedback a ciascun membro del team, la direzione assicura che tutti i problemi vengano esaminati e affrontati prima che diventino significativi.

( Fonte )

Se osservi a lungo questo aspetto, una costante rispetto a questi elementi è l'enfasi sul lavoro di squadra e sul feedback.

Un esempio, dici di avere avuto un argomento nel tempo stimato. Sei il responsabile di tali stime temporali? Ne parli con il team? Mi dispiace ma ho visto i manager estrarre un numero dal loro as-. Una cosa cruciale: non contrattare mai nel tempo le stime che la tua squadra ti dà. Molti manager immaginano che se riescono a rispettare scadenze più brevi se la loro squadra lavora di più. Questa è una bugia. Nove donne non possono avere un bambino in un mese, ricordalo.

Quindi, il mio primo consiglio:

Ascolta : inizia con una semplice e-mail al team: "Qual è il modo migliore per il team di sviluppo di fornire feedback alla direzione sulle prestazioni della gestione?". Scorrere con il team e attuare il consenso. Il tuo compito è quello di consentire al team di sviluppare un ottimo software, non di mandarli a capo. Tienilo a mente.

Onestà e lealtà : se nessuno risponde quando chiedi qualcosa, è perché non credono che ascolterai o, peggio ancora, credono che li punirai per quello. Quindi sii onesto. Se qualcuno dice che fai schifo, prendi questo come feedback e non vendicarti. Comprendi le loro ragioni, migliorale.

E, finalmente, anche se ho visto alcune critiche al riguardo qui, vorrei raccomandarti di leggere un libro intitolato The Mythical Man-Month: Essays on Software Engineering . Il libro parla dell'esperienza di Fred Brooks in IBM durante la gestione dello sviluppo di OS / 360. Mentre alcune cose qua e là potrebbero essere datate, è il passo iniziale per capire come funziona il processo di sviluppo di software complessi. S.Lott cita il Manifesto Agile , che non mi piace particolarmente, ma vale anche la pena di leggerlo.

Leggi questo:

http://agilemanifesto.org/

• Individui e interazioni su processi e strumenti

• Software funzionante su documentazione completa

• Collaborazione con i clienti sulla negoziazione del contratto

• Rispondere al cambiamento seguendo un piano

In molti casi, l' organizzazione (cioè il tuo capo) ti richiede

• seguire un processo chiaramente interrotto fino alla sua logica conclusione che porta a una "marcia della morte". Ciò porta a sua volta a discussioni e dimissioni.

• creare documentazione eccessiva, di basso valore, non utilizzata.

• impegnarsi in complesse modifiche di controllo a / k / a negoziazione del contratto. Ogni modifica dell'utente richiede un rituale elaborato per "qualità" e "priorità" della modifica. In realtà, si tratta solo del "blocco", che impedisce il cambiamento.

• seguire il piano indipendentemente dalle conseguenze. Alcune organizzazioni apprezzano la consegna puntuale di software non funzionante (o addirittura inutile). È il piano che viene valutato, non la soluzione di un problema aziendale.

È possibile che il problema non sia la tua capacità di comunicazione personale.

Può darsi che l'intero "ambiente" o "metodologia" di sviluppo sia fatalmente spezzato e che i cattivi sentimenti siano solo un sintomo di cattive pratiche generali.

Per me sembra che tu non abbia mai parlato con gli sviluppatori in un'atmosfera facile. I tuoi colloqui con loro erano solo di natura ufficiale? È troppo male.

Perché non li conosci personalmente e quindi conosci ciò che è buono e ciò che è negativo per l'azienda, il loro posto di lavoro e i loro progetti? Rispettali e guadagna il loro rispetto, mostrando sincero interesse e apprezzamento per il loro lavoro.

Se si fidano di te e non hanno bisogno di temere di essere offerte di pegni, molto probabilmente ti diranno anche verità poco attraenti.

Sono un caposquadra e la mia squadra si fida di me. Li proteggo. Mi prendo tutta la colpa e condivido la fama con loro. La nostra gestione mi protegge. Questo aumenta il morale. Avevamo un progetto davvero duro e un cliente quasi malvagio, quasi impossibile da finire, ma alla fine l'abbiamo fatto, perché parliamo di tutto in modo molto franco e aperto.

Clap! Clap! Clap! Dovresti certamente essere una brava persona, perché sei uscito apertamente per vedere cosa si può fare per migliorare il proprio lavoro.

Di seguito trovi ciò di cui ho assistito in un grande manager e che ho adottato personalmente quando sono a capo del team come membro senior.

• M entor più che gestire.
• A membri del team llow di esprimere i loro pensieri e preoccupazioni. Siate tutti orecchi. Prendi quelli costruttivi.
• N mai tradire i membri del team giocando a politiche divisive. Questo fa fuoco prima e in silenzio.
• Una Non dito. Non avere mai smorfie in faccia quando sei con la tua squadra, vieni che cosa può. Questo è davvero difficile.
• G enuinely e apertamente apprezzare il vincitore per la sua / il suo buon lavoro. Allo stesso modo, molto delicatamente e tatticamente criticano il lavoro, non la persona per eventuali torti, alla persona responsabile, isolata e non aperta.
• E la proprietà ncourage e la leadership in ogni individuo. Questo aumenta il morale e l'impegno della persona, perché si sentirebbe rispettato.
• R OAM in giro con la vostra squadra una volta ogni tanto. Questo induce / aumenta il legame tra i membri del team.

Ti auguro buona fortuna per il tuo impegno sincero :)

In generale, i ragazzi nelle trincee iniziano a sentirsi ammutinati quando sentono che le loro lamentele non vengono ascoltate da persone che possono e risolveranno le situazioni. Quando non si sentono nemmeno in grado di lamentarsi senza rischiare la propria posizione in azienda, è ancora peggio.

Sono un tipo Theory-Y, e la maggior parte dei "knowledge worker" tende ad esserlo; Data una possibilità, ci piace il nostro lavoro e vogliamo farlo bene. Tuttavia, l'aspetto negativo di un ambiente di lavoro Theory-Y è che potrebbe non essere immediatamente evidente che c'è un problema, perché le persone, che vogliono fare bene e quindi non vogliono fare onde, troveranno il modo di aggirare quel problema o semplicemente lo ignorano. Questo porta a una frustrazione repressa, che alla fine esplode in faccia all'intera squadra. Un negozio gestito da un manager di Theory-X avrebbe probabilmente ragazzi che si lamentano molto prima; i dipendenti ci sono solo per i soldi, quindi se il lavoro fa più schifo del solito mancheranno.

Per quanto riguarda quello che puoi fare, in un ambiente con anziani e guide nella stanza che fanno il lavoro, sono la tua risorsa migliore. Parla con loro. Potresti programmare 30 minuti a settimana per "due vie", in cui i lead ti forniscono aggiornamenti e preoccupazioni in merito alla quotidianità del progetto e dai loro aggiornamenti sul lato aziendale e pianifichi con loro per risolvere i problemi prima che diventino problemi che incidono seriamente sulla squadra.

Ad Agile, alla fine di ogni "sprint" o "iterazione" (che è un'unità di lavoro di sviluppo che dura di solito tra una e tre settimane), l'intero team, dai membri più junior fino al PM, ha una "retrospettiva ". Guardano indietro a ciò che hanno fatto, a ciò che è andato bene, a ciò che non ha fatto e identificano le cose da fare e le cose da cambiare. Esistono diversi formati e puoi inventarne uno tuo, ma il risultato del retrò dovrebbe essere che le persone sentono che la loro voce è stata ascoltata e che le cose cambieranno di conseguenza.

Parlando di Agile; il mio primo lavoro era per una piccola azienda, e per "piccola" intendo l'intera azienda non poteva schierare una squadra di softball. Quando ho iniziato, c'erano quattro programmatori e questo si è ridotto a due prima di partire. Il fondatore, il presidente, il CEO e il 95% delle parti interessate della società lo hanno governato con un pugno di ferro, ed è stata l'unica fonte di pianificazione nell'organizzazione, il che significa che non c'era molto. Il Boss era un maniaco del lavoro e si aspettava che lo fossero anche tutti gli altri; Tutto quello che dovevi dare non era più o meno delle sue aspettative, e per questo ha pagato uno stipendio entry-level alle persone che avevano lavorato per lui per un decennio.

Lasciai quella compagnia e iniziai a lavorare per un'altra ditta che faceva le cose MOLTO diversamente; hanno praticato la metodologia di base Agile SCRUM, con standup giornalieri, programmazione di coppie, squadre di sprint e retrospettive. Per un giorno ogni due settimane all'inizio di ogni sprint, non abbiamo fatto altro che pianificare le prossime due settimane di lavoro. Per un grosso pezzo di un altro giorno, non abbiamo fatto altro che guardare indietro a ciò che avevamo fatto e trovare modi per migliorare come squadra. Accanto a me c'erano sviluppatori che erano Microsoft MVP, che facevano il loro lavoro e incoraggiavano e completavano ciò che stavo facendo.

Notte. E. Giorno. La differenza principale? Primo, non mi sentivo come se mi aspettassi che mi uccidessi per il progetto; un principio fondamentale di Agile è il ritmo sostenibile dello sviluppo. In secondo luogo, ho avuto una voce nel decidere come mi sarei aspettato di fare il mio lavoro. Ho dovuto fare il lavoro, ma se avessi avuto "bruciori di stomaco" per quello che ci saremmo aspettati di fare nel prossimo sprint, avrei potuto esprimere quell'opinione e sarebbe stata ascoltata e data peso. Se sentissi che c'era un modo migliore, avrei potuto dirlo e sarebbe stato divertente.

Per quanto riguarda la ricerca di soluzioni e la risoluzione dei problemi, è necessario fare attenzione a non sembrare che si stia lavorando dall'alto verso il basso. Per computer; supponiamo che il tuo RMR (entrate mensili ricorrenti) consenta all'azienda di aggiornare solo quattro computer ogni due settimane. I primi quattro computer non dovrebbero andare tutti ai lead e agli anziani; dovrebbero andare alle persone con i computer più lenti. Se dai bonus alla squadra, non limitarteli ai "nostri preziosi senior e lead, senza i quali ciò non sarebbe possibile"; TUTTI nella tua squadra di sviluppo lo hanno realizzato. Se un junior ha un reclamo, ascoltalo; solo perché è un junior non significa che non sappia nulla.

Migliorare le relazioni:
hai appena avuto un progetto difficile? Dagli una pausa dopo. Tempo di vacanza per rilassarsi, riprendere fiato.
Coder bill of rights Queste cose sono un dato di fatto. Cose di base che dovrebbero andare senza dire. Se li violate, state abusando delle vostre chiavi di codice.
Il test Joel sono d'accordo con la maggior parte di loro. Ma alcuni dipendono davvero. Se ne manchi un po ', probabilmente stai rendendo la vita più difficile ai tuoi programmatori, quindi deve esserlo.
Debito tecnico . Quindi puoi spingere per il completamento, ma devi capire che tagliando gli angoli incorri in un debito tecnico che richiederà più tempo a quest'ultima data per risolvere. Se quella data arriva PRIMA della fine del progetto, hai davvero rovinato tutto.
RSA animate: motivazioneQuesta è una parte fantastica che mostra davvero come motivare i knowledge worker.
Giornata libera per codificare ciò che vogliono. Dal video RSA. Non ricordare il nome, ma la società menzionata ne ha una breve spiegazione sul sito. Mi sembra una buona idea. Nella maggior parte dei negozi ci sono cose che tutti sanno che sono state eliminate, ma nessuno ha il tempo di aggiustare e non è una priorità assoluta. Ciò consente loro di affrontare il debito tecnico. Inoltre permette loro di mostrare le loro idee geniali.

E per amore di Dio, cerca di mantenere una settimana lavorativa di 40 ore. Inoltre, flextime. Flextime può compensare un intero mondo di cazzate. Almeno per me.

Migliorare la comunicazione tra programmatori e capi
È più difficile per me. L'intera cosa sbalorditiva è più una competenza del boss che il focus di un programmatore. Potrei dire che alcune cose di base come le stime del tempo sono solo stime. Camminare sull'acqua e soddisfare i requisiti sono facili se sono congelati. Forse chiedere ai programmatori timidi di fare una presentazione del loro progetto durante una revisione del codice o qualcosa del genere. La pratica rende perfetti, vero? Ma mi inchino ai consigli degli altri su questo.

"Allo stesso modo, se lo odi, descrivi in ​​dettaglio perché."
Bene, questo aprirà i cancelli qui. E se non stessi usando un openID che ovviamente potrebbe essere collegato a me, probabilmente mi sfogerei anch'io. Se vuoi davvero un elenco gigantesco di cosa non fare, chiedi su un forum più amichevole per la pubblicazione anonima.

Ho sempre scoperto che le persone in generale non ti tratteranno meglio di quanto tu non li tratti (anche se potrebbero trattarti peggio). Personalmente (sono uno sviluppatore) rispondo all'onestà con onestà, rispetto con rispetto, fiducia con fiducia e così via. Dovresti fare una chiacchierata informale con la tua squadra in un'atmosfera neutra e dire loro cosa ci hai appena detto. Il punto che viene dimenticato negli ambienti tossici "noi contro loro" è che dovrebbe essere tutto "noi". Sia il management che i lavoratori devono saperlo e l'impresa deve supportarlo.

In bocca al lupo.

Ora hai una comprovata esperienza di non solo accettare feedback, ma anche agire su di esso. Hai dimostrato di avere influenza con i più alti responsabili delle decisioni e puoi fare le cose per la tua squadra. Questo fa una grande differenza. I programmatori possono essere più introversi, ma ci piace parlare di programmazione. Un ambiente informale è piacevole, ma tutti devono ancora essere professionali. Consentire alle persone di sfogare alcuni, ma assicurarsi che le discussioni siano produttive e non solo una sessione di cagna.

Dalla mia esperienza, il fattore più significativo per cui mi piace o non mi piace il mio manager è se capisce lo sviluppo in generale e capisce il lavoro che sto facendo. Alcuni risultati positivi sono elencati qui:

• Non devo perdere troppo tempo per giustificare il motivo per cui un cambiamento richiederebbe così tanto tempo o non può essere implementato. Bene, tecnicamente, qualsiasi cambiamento può essere implementato e il management di solito richiede l'implementazione in qualsiasi modo. Ma almeno in una situazione del genere, il tuo manager diretto è dalla tua parte, chiedendo più tempo (invece di spingerti o bruciarti).
• So di avere maggiori possibilità di essere supportato in caso di una brutta situazione (un hack WTF, un problema di produzione, ecc.). Di solito, una persona non tecnica tende a incolpare lo sviluppatore per una situazione del genere, mentre un buon manager COMPRENDE cosa sta realmente succedendo e supporta il suo sviluppatore (non solo sa o è disposto a prenderlo in quel modo per essere gentile).
• So che il mio lavoro e le mie prestazioni devono essere valutati da una persona adeguata.

Secondo me, se non programmate più e di solito con un programma o un budget ristretto, la possibilità per i vostri sviluppatori di apprezzare è molto bassa. In tal caso, è meglio che tu salga rapidamente e hai qualcun altro come direttore diretto. Mi dispiace di aver suonato male in questo paragrafo, ma è così che lo vedo. La tua sembra essere una brava persona e merita un po 'di verità.

Sono anche uno dei ragazzi in giacca e cravatta da più di 15 anni. All'inizio ero uno sviluppatore di software e scrivo ancora codice quando ne ho la possibilità. Quindi penso di poter parlare per entrambe le parti e ho un po 'di esperienza in queste situazioni. Ho anche credenziali, come "Dipendente dell'anno", elette dal personale, che mi rendono fiducioso nel gestire queste situazioni.

Ciò a cui assisto molto spesso è che esistono differenze sostanziali nei sistemi di valori e nei metodi / approcci operativi adottati tra management e sviluppatori.

Per molti sviluppatori, la sincerità, l'onestà e altrimenti un ambiente di lavoro flessibile sono in cima alla lista. Sfortunatamente gli stessi valori non sono molto in cima alla lista del top management. E questo porta inevitabilmente a enormi scontri, in particolare se il middle management (io e te) decidiamo di prendere completamente il lato del top management. L'unica via d'uscita da questo (dal mio punto di vista) è prendere una posizione ferma di fronte al tuo team, appoggiarli fino in fondo e costruire un rapporto di fiducia attraverso una comunicazione aperta e, soprattutto, facendo quello che stai dicendo (che è spesso l'opposto di ciò che si ottiene dal top management, in cui la politica sopraffà completamente la sincerità).

Allo stesso tempo, tu stesso devi rimanere operativo, quindi devi trovare un modo per comunicare con il top management in una lingua che capiscono e giocano il loro gioco. Questa è la vera sfida del middle management.

Credo che con la felicità degli sviluppatori la produttività sia dovuta alle piccole cose. La matematica funziona in modo fantastico per la gestione. Dammi una ciambella (-25 centesimi) al mattino e lavorerò due volte più duramente tutto il giorno (+ molti dollari). Non è che facciamo il sabato attivamente le cose lavorando lentamente quando siamo insoddisfatti, è che stiamo lavorando su sistemi estremamente complicati ed è estremamente difficile concentrarci quando siamo frustrati da qualcosa. Probabilmente è davvero meglio che non programmiamo tanto quando siamo arrabbiati.

Le stime, tuttavia, devono essere affrontate da sole. Ogni problema che ho può essere risolto consegnandomi una ciambella, ad eccezione delle stime non realistiche . Vero o falso, è così che lo sviluppatore lo vede: il management ha tutto da guadagnare (come una nuova barca) con una stima più breve, mentre gli sviluppatori hanno tutto da perdere (come un mese di sonno). Il management è responsabile, quindi vincono sempre la guerra stimata. Penso che il sistema di stima funzioni meglio quando gli sviluppatori decidono la scadenza (è abbastanza difficile per noi dare una stima accurata, quindi come farebbe un manager?), Ma il management li motiva positivamente ad essere ambiziosi, con la consapevolezza che nessuno sviluppatore viene convocato per essere un po 'fuori.

Considera quale tipo di reazione dai a un programmatore che potrebbe avere una domanda, un commento o una preoccupazione. C'è un "Cosa vuoi adesso ?" o "Perché mi dai fastidio con questo ?" tipo di risposta? Sei bravo a incoraggiare gli sviluppatori a esprimere dubbi e commenti? Questo è solo un punto di partenza però.

In secondo luogo, fai attenzione a dove stai cercando di tenere queste discussioni. Dubito che sarei molto aperto a discutere della mia macchina di lavoro con qualcuno nel prossimo cubo se sapessi che il mio manager era a portata di mano per ascoltare tutto. Se si desidera che le persone forniscano un feedback aperto e onesto, è necessario garantire un po 'di privacy per sapere che le loro risposte non verranno trasmesse pubblicamente o utilizzate contro di loro.

Terzo, considera che tipo di abilità di Intelligenza Emotiva hai. Intelligenza emotiva per i project manager: le competenze delle persone necessarie per ottenere risultati eccezionali di Anthony Mersino sarebbe una raccomandazione del libro che ho ricevuto ieri da un pranzo e ho imparato a conoscere l'EQ. Se vuoi davvero approfondire la psicologia qui ci sono vari strumenti per il profilo della personalità che potrebbero essere utilizzati, ad esempio Enneagramma, stili sociali e MBTI.

Infine, considera qual è la cultura della tua azienda. Gli errori vengono spazzati sotto il tappeto? Le lamentele sono un grande no-no che potrebbe mettere qualcuno nei guai davvero facilmente? Quali comportamenti vengono premiati o incoraggiati e quali sono tollerati e accettati? Mentre alcune di queste sono osservazioni, alcune possono anche richiedere alcune conversazioni che dovrebbero essere tenute lontane dall'ufficio o in una stanza in cui non è probabile che si stia intercettando. Probabilmente sarai ripetitivo nel provare a usarlo all'inizio. Non è una brutta cosa se stai cercando di stabilire una nuova pratica e far parlare le persone se la cultura era principalmente quella in cui tutti sapevano solo "succhiarlo". Questo potrebbe essere più permaloso di altre risposte ma questo sarebbe quello che io '

Gli sviluppatori sentono che sei il loro avvocato? Con ciò intendo dire che sanno di essere liberi di condividere con te le loro preoccupazioni / frustrazioni senza essere picchiati? Sentono che combatti per loro? Ritengono che apprezzi il loro lavoro? Ritengono che tu voglia davvero che abbiano successo nella loro carriera?

Se si sentono apprezzati, probabilmente avrai una comunicazione migliore.

Come sviluppatore sono un grande secchione e non ho abilità sociali e non mi scuso. Dopotutto, sono il talento e mi hai assunto per il mio talento. Se avessi bisogno di social butterfly per fare il lavoro, avresti una stanza piena di project manager invece di sviluppatori.

So che alcuni sviluppatori sono molto socialmente astuti, ma penso che la mediana si inclini verso un nerd introverso.

Quando qualcuno mi chiede di fare qualcosa non faccio assolutamente inferenze e faccio ESATTAMENTE ciò che è richiesto. Sembra che con alcuni project manager finisca sempre con problemi perché si aspettano che io faccia delle deduzioni sul loro progetto che non farò assolutamente, quindi a volte le cose non vanno come si aspettano, anche se si rivelano esattamente ciò che hanno richiesto. Penso che il motivo per cui ciò accada con alcuni project manager sia perché non offrono HLD, BRD di alta qualità e danno troppo valore all'aspetto sociale della gestione del progetto piuttosto che a quello in bianco e nero.

Penso che sia qui che si scontrano i mondi. Penso che nel mondo del project management le abilità sociali e la qualità del candore personale siano fattori importanti, ma per gli sviluppatori come me non significa assolutamente nulla. Non mi impressiona a lamentarmi di quanto sia importante questo o quel compito. Non voglio nemmeno uscire per il pranzo o le birre come alcune persone qui hanno suggerito.

Quello che voglio veramente sono HLD e BRD di buona qualità. Voglio che i programmi e le scadenze siano raggiungibili e, se vengono introdotti nuovi progetti o piani, voglio che i programmi e le scadenze vengano adattati. Ho lavorato a progetti in cui i requisiti sembrano cambiare al volo - per me questa è la mia bandiera rossa che ho a che fare con una leadership di progetto di scarsa qualità. Come sviluppatore la cosa peggiore che puoi fare è portarmi nuovi requisiti di progetto su base giornaliera, specialmente dopo che abbiamo già un programma o abbiamo preso impegni. È intollerabile quando vengono introdotti nuovi requisiti, senza compensazione delle scadenze. Lavorare più ore, lavorare fino a tardi, non ho alcun problema, ma non è qualcosa di sempre quantitativo con lo sviluppo. Alcune modifiche possono richiedere alcune ore extra, alcuni cambiamenti potrebbero richiedere settimane per un'adeguata ricerca e sviluppo, test, controllo qualità ecc ... Non è sempre come cuocere una torta, a volte una singola modifica ai requisiti può essere come cambiare l'intera ricetta. Ho visto i project manager sciogliersi e avere collera nelle teleconferenze perché le loro scadenze non consentiranno lo sviluppo extra, ma stanno chiedendo uno sviluppo che non fosse nei loro requisiti iniziali del progetto.

Posso solo dare il mio giudizio personale e la mia esperienza come esempio, quindi per favore non dedurre che sto parlando a nome di tutti gli sviluppatori. Vedo queste cose solo attraverso il microcosmo della mia carriera, ma questo post descrive le condizioni esatte che mi hanno spinto a buttarmi nel proverbiale asciugamano.

Quanto spesso parli con i tuoi sviluppatori? Non intendo riunioni sullo stato del progetto, domande sui risultati finali o altri argomenti che porti a loro: quanto spesso ti siedi con uno dei tuoi programmatori, chiedi loro come stanno andando le cose e semplicemente ascolti .

Molte altre risposte sono davvero buone: dovresti cercare uno sviluppo agile. Hai bisogno che i tuoi sviluppatori imparino e crescano nei loro ruoli. Ma se in realtà non stai ascoltando ciò che i tuoi sviluppatori stanno dicendo (o non stanno!), Allora devi prima occupartene.

Buona referenza su one-on-one - http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

Breve e dolce Excel in quello che fai - questo genererà la comunicazione.

Cosa significa eccellere per i tuoi sviluppatori? .. Leggi, rileggi , sì, studia anche PeopleWare

Tutte le grandi idee e commenti nei post sopra!

Ecco un'idea: inviare il personale IT ai seminari di comunicazione presso il college della comunità locale, ovviamente a carico dell'azienda.

Assicurati che a) le officine abbiano una buona reputazione eb) non inviare insieme i tuoi dipendenti. Tenderanno a rimanere uniti e non si confonderanno con gli altri membri della classe, non solo riducendo il valore dei seminari, ma causando l'interruzione degli altri.

La comunicazione orientata al team produttivo è un'abilità che chiunque può imparare, ma è un argomento che ritengo manchi nella maggior parte dei percorsi scolastici.

Questa idea non è in alcun modo un proiettile magico, ma è un buon pezzo di base del puzzle. Non solo i tuoi collaboratori impareranno a comunicare meglio tra loro, ma il vantaggio sarà che cominceranno a capire e a rispettare meglio il TUO lavoro (la comunicazione è al centro di PM).

Solo i miei 2 bit :)

Giusto per dare una risposta a una raccomandazione che è già arrivata in alcune risposte . Michael Lopp (aka rand ) è stato iscritto sulla gestione sviluppatori e "ricevendo nelle loro teste" sul suo blog, Rands in Repose , e in un libro, Managing Humans ( fonti del libro ). Il libro contiene principalmente contenuti modificati dai suoi post prima del 2007 e fornisce un buon modo per recuperare il ritardo con le parti relative alla gestione del suo blog (parla anche del gioco d'azzardo e se vuoi leggere che è un'altra questione). La sua scrittura è generalmente fantastica e spesso divertente, quindi c'è poco rischio nel leggerlo.

Porta fuori la squadra per la birra (e stai comprando).

Sono in ritardo alla festa, ma ho appena visto questa domanda.

Una cosa che non vedo molto ben indirizzata è questa:

I grugniti non dicono mai tutta la verità ai semi. Rands lo dice nel DNA ma non lo affronta direttamente, è su un argomento diverso.

Indossi un abito e firmi gli assegni. Rappresenti l'interesse dell'azienda. Non stai rappresentando gli ingegneri. Se lo facessi, non firmeresti i loro assegni, loro firmerebbero i tuoi.

Questa ovviamente non è una novità per te o per gli ingegneri. Ma quando un ingegnere sa che sollevare determinati problemi - problemi - con il suo posto di lavoro causerebbe un conflitto significativo - il compromesso rischio / rendimento non favorisce l'ingegnere. Gli ingegneri sono pagati per produrre prodotti, non per dare il via a lotte di cultura sul posto di lavoro. Essere coinvolti in questi è una strada veloce per fare il lavoro sbagliato.

Quindi parte del compito di gestione è quello di fornire un modo per gli ingegneri di essere aperti sui problemi, senza incorrere in politiche aziendali e contraccolpi di carriera. È bello avere rilanci, dopotutto, e ci sono altre compagnie, se questa non si sente congeniale.

Sono sorpreso che nessuno abbia menzionato questo grande libro che tratta esattamente la tua domanda e il tuo argomento: "Peopleware: progetti e team produttivi" di DeMarco e Lister . Dall'editoriale: i principali problemi dello sviluppo del software sono umani, non tecnici . Le prime tre recensioni su Amazon sarebbero facilmente sufficienti a convincermi ad acquistare questo libro se mi trovassi nella tua situazione.

Molte delle risposte qui hanno dei punti molto positivi, ma vorrei solo aggiungere un paio di risorse che potrebbero aiutare. Sono stato in alcune situazioni che o si sono sbriciolate su se stesse in un pasticcio gigantesco o sono state risolte in modo molto efficiente a causa della comunicazione tra le persone coinvolte. Tre libri mi hanno aiutato a migliorare personalmente le mie capacità comunicative, soprattutto in situazioni di forte stress dove c'è molto sulla linea:

• Conversazioni difficili: come discutere di ciò che conta di più
• Conversazioni cruciali: strumenti per parlare quando la posta in gioco è alta
• Confronti cruciali: strumenti per risolvere promesse non mantenute, aspettative violate e comportamenti scorretti

Dalla lettura della tua domanda, penso che tu veda il valore della comunicazione. Personalmente ritengo che la comunicazione sia più importante per un manager o un leader rispetto alle competenze aziendali o tecniche. Le persone che stai guidando dovrebbero avere le competenze di cui hai bisogno per portare a termine la maggior parte del progetto. Un buon leader tecnico o project manager dovrebbe essere in grado di concentrarsi sulla comunicazione, sia all'interno del team o tra il team e il cliente o il team e l'entità aziendale (o anche una combinazione di questi tre).

Leggi un paio di grandi romanzi che danno un'idea delle prospettive della forza lavoro tecnica:

• Hackers, Steven Levy - http://it.wikipedia.org/wiki/Steven_Levy
• Microserfs, Douglas Coupland - http://it.wikipedia.org/wiki/Douglas_Coupland
• Cattedrale e il bazar, Eric Raymond - http://it.wikipedia.org/wiki/Cathedral_and_the_Bazaar

Questi sono importanti quanto qualsiasi tipico libro di memorie sulla gestione (Drucker et al).

Ho ricoperto vari ruoli per molti anni: sviluppatore, sviluppatore senior, responsabile tecnico ecc.

Dalla tua domanda - è abbastanza ovvio che i tuoi sviluppatori non ti dicono cose perché non pensano che tu possa aiutare.

Ciò può essere dovuto a 2 motivi.

1. Non pensano che tu abbia il potere di aggiustare le cose. Tuttavia, penso che questo sia improbabile perché probabilmente lo sapresti e anche gli sviluppatori si lamenterebbero per te.
2. Sei il tipo di persona che quando uno sviluppatore viene da te con un problema, fa una o più delle seguenti cose
   • Quando vengono da te con problemi, dici loro: mi piacciono le soluzioni, non i problemi.
   • Li ascolti bene e poi li incarichi di risolvere il problema. Dai loro un pep di quale onore sia loro assegnato la responsabilità di risolvere il problema. Nel corso del tempo i tuoi ragazzi capiscono che quando vengono da te con un problema, finiranno con un lavoro extra, quindi non vengono da te con problemi.
   • Neghi che sia un problema. Tu dai motivi convincenti per questo. Ma mentre questo continua a succedere, nel tempo i tuoi ragazzi apprendono che non ha senso avvicinarti a un problema.
   • Dici "Sì, ho capito". Dici che questo genere di cose succede di tanto in tanto e non c'è niente che si possa fare. Se questo è uno schema, allora i tuoi ragazzi lo capiscono.

Se si tratta di uno o tutti i precedenti, è necessario correggerlo.

La cosa che odio di più è che le persone si mettono tra me, lo sviluppatore e l'utente finale. I migliori gestori mi hanno permesso di fare questo e cambiare la nostra soluzione per adattarla a ciò che penso che l'utente voglia o possa fare.

La peggiore pratica per me è spesso vestirsi come "buona" - di solito il manager ha se stessi, o un BA o qualcuno che scrive specifiche che gli sviluppatori devono interpretare e implementare, con i tempi concordati in anticipo.

Se si tratta di una soluzione personalizzata spesso anche gli sviluppatori non sanno quanto tempo ci vorrà e di solito il cliente non ha idea di cosa sia meglio per loro. Ecco perché lo sviluppo iterativo è eccezionale. Non è il modo in cui la maggior parte degli affari viene fatta, quindi un buon manager si batterà per lavorare come sopra.

Infine, alcuni sviluppatori non sono bravi a comunicare e non possono relazionarsi con i clienti. Sono forse più adatti a problemi con requisiti chiari, in particolare requisiti tecnici chiari. Forse hai bisogno di sviluppatori che siano comunicatori migliori e che vogliano lavorare per risolvere problemi di business non puramente tecnici.

È molto facile mantenere la squadra felice

Prova ad ascoltarli molte volte anche se la loro domanda ha delle risposte. incoraggerei il membro del team a venire con i problemi e la probabile soluzione.

L'uscita di squadra è una buona idea (potrebbe essere un piano di gioco)

se il tuo progetto richiede serate notturne e lavoro nel fine settimana e pensi di non aggiungere molto valore alla squadra, sarebbe comunque una buona idea venire un po 'di tempo con qualcosa da mangiare e apprezzare la squadra per i loro sforzi e se possibile organizzare qualche PTO forthem

fai un bimestrale 1: 1 con ogni membro del team per assicurarti che siano a loro agio.

Ultimo ma non meno importante, potrebbe essere una buona idea per te comprendere il progetto in modo funzionale e in qualche modo anche tecnico.

Per favore fatemi sapere se avete altre domande

Sono anche un gestore di software (francese, quindi perdona il mio inglese) che ha una formazione scientifica di base ma non un background specifico di software IT in origine. Quindi non ho alcuna particolare affinità con la programmazione all'inizio, ma sono stato un ingegnere statistico della qualità della scuola di Deming che ha un insegnamento enormemente diverso per ogni scuola "moderna" che seguiva sebbene fingessero di ereditare da Deming. Il peggio è 6 sigma, lean è stato migliore, ma sfortunatamente quello che è successo è questo http://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-say :

“Originariamente Six Sigma è stato derivato dalla Toyota Quality Management (TQM) di Motorola per raggiungere i livelli di qualità six sigma, quindi attraverso Allied Signal e GE si è trasformato in progetti di Black Belts basati su statistiche per diventare un programma di riduzione dei costi — ogni progetto ha bisogno di un ROI chiaro. In altre parole, abbiamo denigrato il programma da una filosofia di leadership a una serie di progetti unici per ridurre i costi. Era una completa bastardizzazione dell'originale e raramente portava a cambiamenti duraturi e sostenibili perché mancavano la leadership e la cultura.

“Una cosa simile è accaduta quando si è ridotta a un toolkit (ad es. Mappatura del flusso di valore, schede KPI, celle, kanban).

"Lean e Six Sigma non riflettono in alcun modo il pensiero originale di eccellenti aziende giapponesi o dei loro insegnanti come Deming."

Oggi il movimento Agile è magro (vedi il corso di Jeff Sutherland e il suo onore per Deming http://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will-be-the -century-of-scrum / ), è meglio di Waterfall ma è ancora molto lontano dall'insegnamento originale di Deming perché invece di leggere Deming nel suo testo originale, i guru lo impacchettano quasi mai citando i suoi 14 principi di gestione, e vende strumenti e seminari che hanno poco valore da soli.

Ora, quando si tratta di software, i problemi sono che da un lato ci sono persone che conoscono i principi generali ma non hanno idee reali su come applicarli realmente e dall'altro persone che scrivono software ma ignorano i principi perché ascoltano falsi guru che vendevano loro strumenti senza dire loro i veri principi e dovevano infatti costruire i propri strumenti di gestione.

Quindi per me il project manager del software dovrebbe fare uno sforzo per approfondire l'operatività quotidiana della codifica software, non solo facendo una pianificazione in Microsoft Project (o grafico di burdown con Agile) o una bella presentazione in Powerpoint al management superiore ma avere anche alcuni valori per il team di sviluppatori. Quando il team di sviluppatori ha problemi anche se si tratta di problemi tecnici, il project manager può aiutare a orientare la diagnostica con occhi esterni. Può guardare il codice, anche se non capisce i piccoli dettagli, può fare alcune domande ingenue che possono indurre gli sviluppatori a rendersi conto che non hanno pensato a quell'indizio (ho numerosi esempi personali ma è troppo lungo, quindi lo farò piuttosto scrivere un articolo sul mio blog).

Un'altra cosa è che provo ad avere una consapevolezza generale dell'evoluzione nel campo come nuovi quadri, nuovi paradigmi di architettura leggendo articoli tecnici. Parteciperò ad alcuni test di integrazione, scriverò io stesso alcune documentazioni (cose che i programmatori odiano, quindi faccio per loro, ovviamente mi daranno da mangiare con il nucleo), tutto ciò che sono in grado di fare praticamente per aiutare il team.

In generale, gli sviluppatori si sentono come se stessero facendo il duro lavoro, ed è vero, spesso dico loro che sto facendo la parte facile rimanendo in astrazione, tuttavia cerco di aiutare concretamente quando necessario - perché la micro-gestione non va bene neanche perché può generare sensazioni di interferenza.

In conclusione: elimina gli slogan con gli sviluppatori (che in realtà è uno dei 14 principi di Deming), mostra loro che tieni al software concreto del progetto, non ai documenti o al tuo incontro solo con i dirigenti.