Trattare con programmatori inflessibili

A volte i programmatori che lavorano a lungo su un progetto diventano inflessibili e diventa difficile ragionare con loro. Anche se riusciremo a convincerli, è improbabile che possano attuare i nostri suggerimenti.

Ad esempio, di recente mi sono unito a un progetto in cui il processo di compilazione e rilascio è troppo complicato e presenta blocchi stradali non necessari.

Ho suggerito di eliminare alcuni dei costi di sviluppo (come riempire alcuni fogli di calcolo) semplicemente integrando la gestione dei difetti e gli strumenti di controllo della versione (entrambi sono strumenti IBM-Rational, quindi l'integrazione può essere uno sforzo una tantum molto semplice). Inoltre, se utilizziamo strumenti come Maven & Ant (il progetto coinvolge Java e alcuni prodotti COTS), la generazione e il rilascio possono essere semplificati, il che dovrebbe ridurre gli errori e gli interventi manuali.

Sono riuscito a convincere gli altri e sono pronto a impegnarmi per sviluppare una prova di concetto. Ma lo sviluppatore "Senior" non è disposto, probabilmente perché l'attuale processo lo rende più prezioso.

Come gestiamo questa situazione senza sviluppare attriti nel team?

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

Ok, alcuni consigli pratici:

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

Comprendi la storia 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 effettivamente un problema che il team ha.

Conosci i tuoi blocchi stradali. Scopri i motivi della loro resistenza e lavora su quegli oggetti.

Se vuoi essere un agente di cambiamento, impara come essere un agente di cambiamento di successo . Dozzine 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 la tua felicità e la felicità della tua squadra, sii intelligente. Il tuo desiderio di fare un cambiamento di 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 un lavoro in cui tutti stavano usando Smalltalk. La mia prima reazione è stata "OMG, stanno usando questa tecnologia antiquata" e ho iniziato a provare a risolvere problemi specifici di Smalltalk con soluzioni Java. Posso solo immaginare che mal di testa devo essere stato per gli 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 seguito da due sviluppatori senior nel corso di pochi mesi che ho iniziato a prendere il controllo della lingua Smalltalk e ad imparare ad apprezzarlo. Da quando ho lasciato quel lavoro e sono tornato a fare lo sviluppo di Java, mi sento molto più flessibile in quanto posso prendere un progetto e implementarlo in qualsiasi linguaggio utilizzato dalla società. La cosa fondamentale per far capire a queste persone è che la lingua non è altro che il mezzo. Mi sono anche preso il tempo di insegnare a me stesso Lisp ed Erlang, ma potrebbe non funzionare con tutti.

Come strategia di team building, consiglierei Seven Languages ​​in Seven Weeks alle persone con cui hai problemi.

Immagino 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 orientati verso una lingua specifica e i suoi studenti diventano "istituzionalizzati" come hai detto. Penso che parte della tua strategia dovrebbe essere quella di coltivare la flessibilità nella tua squadra. Ciò potrebbe essere integrato con Domain Driven Development .

(1) Modella un dominio (uno semplice) (2) Implementalo usando due lingue diverse (ad esempio Java e Lisp)

Ancora una volta, si presume che siano motivati ​​a fare quanto sopra e che siano disposti a investire il proprio tempo per raggiungere questo obiettivo.

Spero che sia di aiuto

Potrei essere su una strada totalmente sbagliata qui, ma mi sembra che gli stessi problemi siano comuni su una scala più ampia e si riferiscano al conservatorismo umano. Le persone spesso si rifiutano di cambiare i modelli di comportamento ben noti, per motivi che sono troppo numerosi per essere menzionati.

Essendo uno sviluppatore russo (e quindi vedendo meno di un pragmatismo occidentale razionale), vedo il ragionamento pratico per essere molto meno convincente che provare a camminare nei panni di qualcun altro.

In altre parole, hai detto che il programmatore senior apprezza la propria posizione in relazione all'attuale schema di lavoro. 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 ottenerne il merito, oppure potresti trovare un punto specifico nel processo che può controllare esclusivamente ecc.

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

Sono riuscito a convincere gli altri e sono pronto a impegnarmi per sviluppare una prova di concetto. Ma lo sviluppatore "Senior" non è disposto, probabilmente perché l'attuale processo lo rende più prezioso.

Invece di lanciare aspersioni sul personaggio dello sviluppatore senior (mossa sbagliata), forse dovresti provare a capire perché non è entusiasta:

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

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

• Forse pensa che non afferrerai completamente i rischi tecnici.

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

• Forse lo hai solo fregato nel modo sbagliato.

Il mio consiglio sarebbe di metterti alla prova con lui. Ad esempio consegnando i progetti che ti sono stati effettivamente dati. Quando si fida maggiormente delle tue capacità e del tuo giudizio, rivedi questo problema.

Se vuoi perseguire subito la linea "miglioramento del processo", il mio consiglio è di farlo lentamente, a piccoli passi.

Tieni presente che c'è senza dubbio il rischio che le modifiche proposte abbiano un impatto significativo sulla produttività del tuo gruppo e persino sulla loro capacità di mantenere il software esistente. In tal caso, è probabile che il responsabile ottenga il massimo da parte dell'alta dirigenza.

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

Se sono stati nell'organizzazione / progetto per molto tempo, è probabile che siano sviluppatori senior e abbiano la responsabilità / esperienza per effettuare quelle chiamate e abbiano avuto esperienze nel progetto piuttosto che essere condizionati come l' esperimento con 5 scimmie .

La soluzione per convincerli dipenderà da quale sia il soggetto, poiché se un modello / tecnologia è già stato scelto, ci sarà una buona ragione, e ci dovrà essere una ragione migliore per cambiare per giustificare buttare via il lavoro e riqualificare ecc. In tal caso, una soluzione è per un architetto / sviluppatore senior che organizza un incontro per decidere democraticamente la soluzione migliore.

Se il team ha davvero blocchi stradali non necessari, probabilmente saranno molto felici di averti aiutato a risolverli. Nota comunque che potrebbe esserci un'ottima ragione per cui sono lì, e sembrerai stupido se dovessi dire "oh, beh, la mia fantastica idea non funziona allora" dopo averlo venduto a tutti per molto tempo.

Indaga prima e poi fatti avanti. Si noti inoltre che essere in grado di MOSTRARE come si suggerisce di migliorare è molto meglio del lavaggio a mano.

Sono propenso a dire che sei colui che è il "programmatore inflessibile". Sei nuovo nel progetto, ma insisti sul fatto che la tua idea sia la migliore e il ragazzo che sta guidando il progetto, che è stato il loro più a lungo e sa che il sistema dentro e fuori è appena fuori dal suo gioco.

Sono abbastanza esperto e molto apprezzato e spesso mi sono assegnato per risolvere progetti in difficoltà come membro del team tigre. Anche allora mi prendo ancora del tempo per imparare come, perché, dinamiche della squadra, il progetto e le loro pratiche e non entrare selvaggiamente e dire loro come questo e quello siano sbagliati. In realtà, non dico mai che ciò che stanno facendo è sbagliato perché ciò non ottiene la risposta che desidero e di solito ciò che stanno facendo non è sbagliato, ha solo bisogno di qualche modifica.

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

Il modo migliore per convincere le persone a fare quello che vuoi è far loro pensare che tutto sia la loro idea. Quindi, invece di dare direttamente suggerimenti, presenta le opzioni. Se le tue idee sono chiaramente migliori delle alternative, dai allo sviluppatore senior la possibilità di sceglierle e farle sue. Non preoccuparti di ottenere credito. Le persone che contano sapranno cosa sta succedendo.