Trattare con programmatori inflessibili

Sei il nuovo membro del team e vuoi cambiare alcuni aspetti fondamentali del funzionamento del team. Buona fortuna, sento una squadra felice nel tuo futuro.

Ok, qualche consiglio pratico:

Mettiti alla prova con il team. Dovrai farlo da un punto di vista tecnico e di affidabilità. Se vuoi che le persone ti seguano, devi dare loro una ragione per farlo.

Comprendi la cronologia della metodologia. Perché esiste? Che problema stava risolvendo in quel momento? Assicurati che la tua soluzione sia davvero un vantaggio per il team. Forse le tue modifiche sono migliori, ma potrebbero non risolvere in realtà un problema che il team ha.

Conosci i tuoi blocchi stradali. Scopri i motivi della resistenza e del lavoro su questi elementi.

Se vuoi essere un agente del cambiamento, impara come essere un agente di cambiamento di successo . Decine di libri e altre fonti disponibili per fornirti molte più informazioni di quelle che otterrai qui.

E, sì, ti auguro buona fortuna. Ma per favore, per il bene della tua felicità e della felicità della tua squadra, sii intelligente. Il tuo desiderio di trasformare un processo, senza investire l'energia per creare la strada giusta, potrebbe fare molto più male che bene.

Sono stato nella posizione che hai menzionato. Ho trascorso anni come sviluppatore Java e alla fine ho iniziato a lavorare in un ambiente in cui tutti utilizzavano Smalltalk. La mia prima reazione è stata "OMG, stanno usando questa tecnologia antiquata" e ho iniziato a provare a risolvere i problemi specifici Smalltalk con le soluzioni Java. Posso solo immaginare che mal di testa devo essere stato agli altri sviluppatori e hanno odiato Java con passione.

Non è stato fino a quando mi è stato dato un progetto di medie dimensioni su cui lavorare mentre sono stato mentore da due sviluppatori senior nel corso di alcuni mesi che ho iniziato a prendere confidenza con il linguaggio Smalltalk e ho imparato ad apprezzarlo. Da quando ho lasciato Job e sono tornato a fare lo sviluppo di Java, mi sento molto più flessibile nel fatto che posso prendere un progetto e implementarlo in qualsiasi lingua l'azienda utilizzi. La cosa fondamentale per far capire a queste persone è che la lingua non è altro che il mezzo. Ho anche avuto il tempo di insegnarmi Lisp ed Erlang, ma potrebbe non funzionare con tutti.

Come strategia di team building, consiglierei Seven Languages in Seven Weeks alle persone che stai avendo problemi con.

Credo che dipenda anche da quanto tempo queste persone sono disposte a investire per diventare più flessibili. Il problema con la maggior parte delle università (almeno quelle che ho visto) è che sono prevenuti verso una lingua specifica e che i suoi studenti diventano "istituzionalizzati" come hai detto. Penso che parte della tua strategia dovrebbe essere quella di coltivare la flessibilità nella tua squadra. Questo potrebbe essere integrato con Sviluppo guidato dal dominio .

(1) Modella un dominio (A semplice) (2) Implementalo utilizzando due linguaggi diversi (cioè Java e Lisp)

Anche in questo caso, si presume che siano motivati a fare quanto sopra e siano disposti a investire il proprio tempo per raggiungere questo obiettivo.

Spero che questo aiuti

Potrei essere su una pista totalmente sbagliata qui, ma mi sembra che gli stessi problemi siano comuni su una scala più ampia e si riferiscono al conservatorismo umano. Le persone si rifiutano spesso di cambiare i modelli di comportamento noti, per ragioni che sono troppo numerose per essere citate.

Essendo uno sviluppatore russo (e quindi vedendo meno di un pragmatismo occidentale razionale), vedo che il ragionamento pratico è molto meno convincente di cercare di calpestare le scarpe di qualcun altro.

In altre parole, hai detto che il programmatore senior valuta la sua posizione relativa allo schema di lavoro corrente. Forse dovresti convincerlo che il nuovo modo di fare le cose renderà la sua posizione ancora più preziosa, e ci sono molti modi per farlo. Ad esempio, puoi fargli effettivamente pronunciare la tua idea e ottenere il merito, oppure potresti trovare un punto specifico nel processo che può controllare esclusivamente ecc.

Credo che essere flessibili al di fuori dei vantaggi apparenti della tua idea, potrebbe essere il tuo incantesimo magico qui.

I managed to convince others and I'm ready to put in the effort to develop a proof of concept. But the ‘Senior’ developer is not willing, possibly because the current process makes him more valuable.

Piuttosto che lanciare aspersioni sul personaggio dello sviluppatore senior (mossa sbagliata), forse dovresti cercare di capire perché non è entusiasta:

• Forse pensa che tu sia una di quelle persone che sovraintendono le loro idee. Forse dubita che tu possa consegnare loro.

• Forse pensa che stai esagerando con i problemi. (Non possono essere così male ...)

• Forse pensa che non comprendi pienamente i rischi tecnici.

• Forse pensa (sa) ci sono cose più importanti da fare in questo momento.

• Forse lo stai solo sfregando nel modo sbagliato.

Il mio consiglio sarebbe di dimostrarsi a lui. Come consegnare i progetti che ti sono stati effettivamente concessi. Quando si fida di più delle tue capacità e del tuo giudizio, quindi rivisita questo problema.

Se vuoi seguire la linea di "miglioramento del processo" in questo momento, il mio consiglio sarebbe farlo lentamente, a piccoli passi.

Ricorda che è indubbiamente un rischio che i tuoi cambiamenti proposti influiscono in maniera massiccia sulla produttività del tuo gruppo e persino sulla sua capacità di mantenere il software esistente. Se ciò accade, è probabile che il responsabile sia il peggiore responsabile dell'alta direzione.

Istituzionalizzato su cosa in particolare? Tecnologie, modelli, pratiche?

Se sono stati nell'organizzazione / progetto per un lungo periodo, è probabile che siano sviluppatori senior e abbiano la responsabilità / esperienza per effettuare tali chiamate, e abbiano avuto esperienze nel progetto piuttosto che essere condizionati come < a href="http://blog.stsaint.com/philosophy/2010/05/5-monkeys-experiment/"> 5 esperimenti sulle scimmie .

La soluzione per convincerli dipenderà da cosa è il soggetto, poiché se un modello / tecnologia è già scelto, ci sarà una buona ragione, e ci sarà un motivo migliore per cambiare per giustificare il buttar via il lavoro e la riconciliazione ecc., in tal caso, una soluzione è per un architetto / senior dev che organizza un incontro per decidere democraticamente la soluzione migliore.

Se la squadra ha davvero blocchi stradali non necessari, probabilmente saranno felici di averli aiutati a risolverli. Nota comunque che ci potrebbe essere una buona ragione per essere lì, e sembreresti stupido se dovessi dire "oh, beh, la mia fantastica idea non funziona poi" dopo averlo inviato a tutti per un lungo periodo.

Prima indaghi e poi fatti avanti. Inoltre, notare che essere in grado di MOSTRARE come si consiglia di migliorarlo è molto meglio del handwaving.

Sono propenso a dire che tu sei quello che è il "Programmatore inflessibile". Sei nuovo nel progetto, ma sei insistente nel dire che la tua idea è la migliore e che il ragazzo che sta guidando il progetto, chi è stato più a lungo e conosce il sistema dentro e fuori è semplicemente fuori dal rocker.

Sono abbastanza esperto e abbastanza ben considerato e spesso viene assegnato per sistemare progetti in difficoltà come membro di una squadra di tigri. Anche allora mi prendo ancora del tempo per imparare i come, i perché, le dinamiche della squadra, il progetto e le loro pratiche e non entrare selvaggiamente e dire loro come questo e quello sono sbagliati. In realtà, non dico mai quello che stanno facendo è sbagliato perché non ottiene la risposta che voglio e di solito quello che stanno facendo non è sbagliato, ha solo bisogno di qualche ritocco.

Ogni progetto è unico. Ogni squadra è unica. La tua soluzione potrebbe essere migliore per te e per gli sviluppatori, ma potrebbe non essere migliore per il lead, il cliente, l'azienda o il progetto, ma dal momento che non hai l'esperienza con il progetto per conoscere meglio, non sapresti la risposta a questo.

Il modo migliore per convincere le persone a fare ciò che vuoi è far credere loro che ogni cosa sia la loro idea. Quindi, invece di fare direttamente suggerimenti, opzioni presenti. Se le tue idee sono chiaramente migliori delle alternative, dai allo senior la possibilità di individuarle e renderle sue. Non preoccuparti di ottenere credito. Le persone che contano sapranno cosa sta succedendo.