Cosa si può fare se "guidare con l'esempio" non funziona? [chiuso]

Obiettivo per la testa : "Lead by example" dovrebbe avere un miglioramento in mente, ma dovrebbe essere mirato alle persone non sulla tecnologia. Forse hai investito troppo tempo nel migliorare la tecnologia, ma non abbastanza tempo in quello che sta succedendo nella loro testa. Pensa ai fattori trainanti perché c'è un'opposizione per cose nuove. In molti casi temono solo qualche rischio. Identifica quei rischi e trova i contrasti per loro.

Prendi la carne fresca : è più facile conquistare i dipendenti che vogliono cambiare le cose. Li noti immediatamente quando li vedi.

Evita la carne marcia : alcuni non potranno mai simpatizzare con le tue idee. Lasciali da parte.

Raggiungi una massa critica : trova persone che simpatizzano con le tue idee. Vincere l'uno per uno. Ad un certo punto se viene raggiunta una massa critica, sempre più persone seguiranno il tuo esempio volontariamente.

Vocabolario di gestione : i manager non sono interessati a progetti migliori. La loro lingua è denaro e tempo. Spiega quante ore sono sprecate per gli insetti. Spiega che i clienti insoddisfatti che incontrano bug non sono redditizi. Dimostra quanto più velocemente puoi implementare una nuova funzione. Devi scegliere un altro vocabolario per i gestori.

Riguarda i processi : le tecnologie migliori non rendono migliori programmatori e programmi. Se hai buoni processi in esecuzione, anche le tecnologie obsolete portano a buoni risultati. Pensa allo sforzo e il tempo è sprecato. Forse non è la tecnologia, ma qualcosa nei processi sta andando terribilmente male. Nella maggior parte dei casi è una mancanza di comunicazione.

Trova una nuova azienda : hai già fatto molto. Puoi ancora provare a migliorare le cose, ma dipende anche da te decidere quanto a lungo vuoi provarlo e quanta energia vuoi investire. Ricorda: anche se non puoi ottenere molti miglioramenti, imparerai molto dai tuoi sforzi. A un certo punto devi andare avanti.

Hai mai smesso di considerare che potresti aver torto?

Quindi leggi alcuni disegni e modelli di libri a scuola e sei diseredato da quelle che sembrano pratiche comparativamente antiquate in cui lavori. Non c'è dubbio che probabilmente sono idee migliori e i nuovi progetti dovrebbero iniziare con questi in mente, ma sembra che tu sia su un livello completamente diverso.

Sviluppare gli sviluppatori è come cercare di mandare i gatti, hanno intrinsecamente una mente propria e un modo preferito di fare le cose, sia che sia giusto o meno. Ho abbastanza tempo per applicare le best practice e gestire un team di 2 sviluppatori, ma lavori per un'azienda che ha 8000.

Questo è un numero incredibilmente enorme. Anche un semplice cambiamento di processo che afferma che tutti gli sviluppatori devono programmare le riunioni e che l'orario fuori sede sul calendario pubblico diventa una politica enormemente complessa e difficile da implementare su tutta la linea. Richiederebbe anche una spinta significativa da parte della direzione per assicurarsi che la politica sia accettata e adottata su tutta la linea.

Potresti non pensarci, ma qualcosa di semplice come passare dal monolitico a più file di intestazione, o spostare il controllo della versione da SourceSafe a Git richiede un enorme sforzo e investimento da parte di tutti i soggetti coinvolti. Richiederebbe:

• Supporto alla gestione significativo

• Accettazione generale dell'azienda

• Investimento degli orari di riunione per tutti gli sviluppatori per informarli delle nuove iniziative (le riunioni costano ore uomo, costo ore uomo costano)

• La formazione deve essere pianificata e stabilita per essere sicuro che anche gli sviluppatori più stupidi sappiano cosa stanno facendo

• Anche ipotizzando un'ora di allenamento, su 8000 sviluppatori x € 50 / ora = € 400000 costo della formazione. Questo è più denaro di quanto il mio unico team di sviluppo software abbia un budget in un anno intero per salari, software e hardware. Questo è un investimento eccezionale che stai proponendo.

Ma stai dicendo: "Pensa a tutto il tempo che potrebbe essere salvato attraverso aumenti di produttività". Giustamente, ma un investimento significativo è un rischio significativo, quindi è meglio essere sicuro che tu abbia ragione su questo prima di firmarlo. Se nessuno dei senior ti sostiene, allora non posso giustificare la spesa. In fin dei conti potremmo essere inefficienti, ma siamo coerenti e con 8000 sviluppatori in tutta la società, la coerenza è la più importante.

Per fare ciò è necessario disconnetterti da più persone di livello senior e devi trovare un modo accurato e oggettivo per misurare il tempo di sviluppo perso in inefficienza. Quel tempo equivale a dollari e solo dollari e politica ti aiuteranno a vincere questa battaglia.

Per me quello che hai descritto non mi sembra un "lead by example", sembra che tu abbia fatto una proposta e sia stato rifiutato. Per dare l'esempio, devi mostrare alle persone che la tua strada è migliore. Dei problemi che hai elencato, ne vedo tre che puoi iniziare a utilizzare tu stesso le tue modifiche.

Plain old makefiles which only support full rebuild.

Crea i tuoi makefile localmente e mostra quanto più efficiente sei in grado di lavorare con loro.

monolithic headers files and projects with very few different files (but each has around 3000 lines of code, which sometimes takes care of very different tasks)

O rompi quelli esistenti quando li tocchi (senza interrompere la costruzione) o introduce file di intestazione più piccoli quando scrivi nuovo codice. Man mano che le persone iniziano a lavorare con loro, capiranno che non hanno bisogno della duplicazione.

no use of the "new" languages facilities (well std::string is not that new but nobody except me uses it)

Continua a introdurre nuove strutture linguistiche ogni volta che tocchi il vecchio codice o introduci un nuovo codice. Assicurati di semplificare le cose. Non scoraggiarti da questo. Molti di noi sono pigri. Se vediamo che una nuova lingua facilita le cose, la adotteremo.

Dopo alcuni mesi, se altri sviluppatori iniziano ad adottare i tuoi miglioramenti, puoi rivolgerti nuovamente al tuo capo su modifiche più radicali come l'aggiornamento del tuo sistema di controllo del codice sorgente. Devi assicurarti che gli altri sviluppatori vedano il vantaggio, o che non passeranno mai. Un modo per avvicinarsi potrebbe suggerire di provare Git su un piccolo progetto su cui sono attivi solo pochi sviluppatori. In questo modo puoi promuoverlo come una valutazione, non come una transizione completa a un sistema sconosciuto.

Infine, se dopo diversi mesi di tentativi nessuno sembra interessato a migliorare il modo in cui le cose vengono fatte nella tua azienda, devi davvero considerare se è adatto a te.

Oltre a Lionel Barret (che per lo più sono d'accordo), considera anche la possibile motivazione alla resistenza.

• Valuta il costo del processo effettivo
• Valuta il costo del processo come sarà il tuo

Ma anche:

• Valuta il costo del cambiamento in termini di
  • Soldi da spendere per configurare il nuovo ambiente per chiunque
  • Tempo da dedicare ad addestrare tutti ad abituarsi alla nuova modalità (potrebbe essere facile per te, ma non così facile per le persone che non sono consapevoli di ciò che stai facendo)
  • Tempo trascorso necessario per gestire il cambiamento in modo non distruttivo.

Ho un sospetto: quanti sono nella tua azienda le persone come te in termini di età e cultura (I uomini "scuola" e "tipo di scuola")? Quante persone come te dovrebbero essere assunte nei prossimi 2/3 anni e quante ne andranno in pensione o cambieranno il loro ruolo nell'organizzazione?

Il mio sospetto è che tu sia in una posizione che non ha abbastanza forza per cambiare la compagnia. In quella situazione, la compagnia ti cambierà o ti "espulterà" (nel senso che diverrà il tuo desiderio di andare via), se non sei in grado di aspettare più tempo.

Ma forse l'azienda sta valutando che i costi aggiuntivi che ti ho detto possono essere salvati permettendo che il processo di cambiamento avvenga spontaneamente aspettando la naturale sostituzione delle persone. Sei solo all'inizio di un processo che non puoi vedere perché non ha ancora (ancora) dietro di te.

A questo punto posso solo aggiungere un riferimento all'articolo Joel Ottenere le cose fatte quando sei solo un grugnito . Le sezioni includono:

Strategy 1 Just Do It

Strategy 2 Harness the Power of Viral Marketing

Strategy 3 Create a Pocket of Excellence

Strategy 4 Neutralize The Bozos

Strategy 5 Get Away From Interruptions

Strategy 6 Become Invaluable

Riassumo l'articolo come "Il cambiamento deve iniziare con te."

Tristemente le persone rimangono bloccate in una routine e sviluppano la mentalità che "funziona, tutti lo usano bene, perché cambiarlo" E si infuria.

L'hai fatto nel modo giusto non solo lamentandoti, ma sviluppando una soluzione praticabile in sostituzione, ora hai solo bisogno di un buy-in.

Mostra il tuo manager di linea diretta (o lead tecnico). Se non sono interessati, hai qualcuno responsabile del controllo dei cambiamenti o dell'innovazione?

Potenzialmente, le tue idee e il tuo lavoro potrebbero essere ignorati e la situazione rimarrà invariata.

Devi indicare il tuo caso in modo che il tuo capo sia dalla tua parte. A proposito, questo tipo di cambiamento è proposto da un direttore tecnico o project manager, quindi sarà necessario impegnarsi per il progetto. (Come rotta alternativa, puoi proporre un audit tecnico, un outsider probabilmente dirà le tue stesse cose ma avrà più peso.)

Finora, non vede la necessità di cambiare, sembra che i cosmetici cambino per lui: costoso senza evidenti benefici se non quello di soddisfare la fantasia di un dev. Solo due cose contano per lui: il flusso di denaro e una squadra stabile. La tecnologia è una scatola nera, se funziona, basta.

I primi soldi, devi dimostrare che il setup attuale gli costa denaro. Quale sarebbe il costo / ora di un dev e quante ore di compilazione più veloce lo avrebbero salvato? Fai i conti. Inoltre, compilare articoli o testimonianze sui rischi dell'attuale pipeline di codice e mostrargli numeri spaventosi: "a causa di SourceSafe / Bad Coding Practices, la nostra azienda ha perso $ XXXK".

Secondo il team, il tuo capo può essere bloccato con vecchi codificatori scontrosi che non vogliono cambiare i loro modi. Se viene stabilito il primo punto, è anche necessario proporre una soluzione a questo problema. Quanti siete ? Potrebbe essere interessante sottolineare che sarà difficile sostituire qualcuno perché l'attuale pipeline di codifica è bizantina. Devi proporre un piano per aggiornare la squadra. Impara le best practice del settore e verifica che seguano le nuove regole.

Infine, è necessario proporre un piano per modificare il codice base, diviso in piccoli progetti, con tappe fondamentali e allocazione delle risorse. In effetti, ti stai vendendo come project manager e le modifiche sono obbligatorie per avere una pipeline di codice solido.

Lavorate in un'organizzazione che crede che fare le cose bene, efficienza e innovazione conducano al successo e alla redditività; o che la ricerca delle entrate e la concentrazione sul mantenimento delle vendite sono gli inquilini del successo?

Le aziende che si comportano come te descrivono sono trincerate tecnologicamente. In un mercato competitivo non sarebbero in grado di competere con una società che si concentra su individui e innovazione.

Se sei la persona che dici di essere, allora lavora da qualche parte che onora e premia il tuo spirito. Alla fine, dopo anni di stabilimenti, inizierai a scendere a compromessi per la stessa filosofia che i tuoi superiori comprendono. Vai a lavorare da qualche altra parte (probabilmente un'organizzazione più piccola) che apprezza il duro lavoro, l'ispirazione, la creatività e il progresso.

Se non corri rischi e lo fai presto, alla fine ti accontenterai e non sarai in grado di continuare a nutrire la tua curiosità e creatività perché è filosoficamente opposto nel tuo attuale gruppo di pari.

L'eccellenza è un'attitudine e una visione del mondo.

Sappi che questa esperienza ti ha dato l'intuizione di sapere cosa evitare, tieni il tuo occhio acuto per il compiacimento e il protezionismo in modo da poterlo rilevare presto.

Nella tua prossima intervista fai domande come "Che tipo di innovazioni provengono dai tuoi dipendenti", "Quali sono alcuni cambiamenti derivanti dalla creatività individuale?", "Quali singoli talenti posso portare a questo team?", "Cosa guida successo delle organizzazioni? "," In che modo la tua organizzazione abbraccia continuamente l'innovazione tecnologica? "... Le risposte a domande come questa sono estremamente significative. Molte organizzazioni non hanno una visione, o quelle che hanno creato la visione sono sparite e l'organizzazione è gestita da contabili. Se stai intervistando il direttore della tecnologia, chiedigli se vede l'organizzazione come una società tecnologica.

Se non ti piace l'ambiente in cui lavori, stai facendo un cattivo servizio a te stesso. Devi essere circondato da persone che hanno interessi e obiettivi simili a quelli che fai professionalmente. So che a volte è più facile dirlo e farlo, ma la sensazione di guardare indietro di diversi anni e sentirti come se avessi perso tempo è peggio della paura di correre un rischio.

In alternativa, se desideri sviluppare in un sistema o in un ambiente che utilizza tecnologie e / o metodologie specifiche, ti suggerisco di trovare un progetto al di fuori del lavoro a cui puoi contribuire. Perlomeno la varietà di lavorare su entrambi i sistemi soddisferà la necessità di qualcosa di diverso mentre trovi il tuo posto.

Mi sembra che tu sia pesce fuori dall'acqua. Vai a trovare il tuo corpo dell'oceano e nuota!