Cosa si può fare quando "dare l'esempio" non funziona? [chiuso]

Lavoro per una grande azienda (8000+ dipendenti) da quasi 2 anni e sono stato assunto subito dopo aver finito il mio corso di studio.

Tutti qui hanno a che fare quotidianamente con il codice legacy che è spesso mal progettato e pieno di hack. All'inizio, ho mantenuto un profilo basso, cercando di non criticare troppo le cose. Ma la situazione, così com'è, è diventata molto difficile da convivere e sembra che nessuno sia disposto a migliorare / sostituire gli strumenti che usiamo.

Per essere più espliciti abbiamo:

• Uno strumento di controllo del codice sorgente obsoleto (Visual SourceSafe)
• Vecchi makefile semplici che supportano solo la ricostruzione completa
• .def file che devono essere gestiti manualmente e separatamente per tutte le architetture esistenti
• file e progetti di intestazioni monolitici con pochissimi file diversi (ma ognuno ha circa 3000 righe di codice, che a volte si occupa di compiti molto diversi)
• nessun uso delle "nuove" strutture linguistiche (beh std::stringnon è così nuovo ma nessuno tranne me lo usa)

Ho deciso, qualche mese fa, di fare qualcosa al riguardo, progettando un nuovo ambiente di compilazione. Potrei ottenere build incrementali per lavorare in modo affidabile, tempi di compilazione più rapidi, progetti meglio strutturati, .defgenerazione automatica di file. Ho persino creato un bridge da / a Git a / da Visual SourceSafe.

Ho mostrato i miei risultati a diversi colleghi e al nostro capo, ma era come se a nessuno importasse. Erano tutti come "Beh ... le persone sono abituate a farlo in questo modo adesso. Perché dovremmo cambiare le cose?"

Le modifiche che ho suggerito sono state progettate in modo da consentire una transizione graduale dal vecchio sistema a quello nuovo. Ogni miglioramento potrebbe essere applicato separatamente e in sicurezza.

Ho anche cercato di coinvolgere alcuni dei miei colleghi nelle modifiche. Ma finora, nessun successo.

Hai già affrontato una situazione simile? Cosa si può fare quando "dare l'esempio" non funziona?

Punta alla testa : "Dare l'esempio" dovrebbe avere in mente un miglioramento, ma dovrebbe essere mirato alle persone che non sono tecnologiche. Forse hai investito troppo tempo nel miglioramento della tecnologia, ma non abbastanza tempo in quello che succede nella loro testa. Pensa ai fattori trainanti per cui c'è un'opposizione per cose nuove. In molti casi temono solo dei rischi. Identificare quei rischi e trovare controargumenti 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 simpatizzeranno mai con le tue idee. Lasciali da parte.

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

Vocabolario del management : i manager non sono interessati a progetti migliori. La loro lingua è denaro e tempo. Chiarisci quante ore uomo sono sprecate per i bug. Chiarire che i clienti insoddisfatti che incontrano bug non sono redditizi. Dimostrare quanto più velocemente è possibile implementare una nuova funzionalità. Devi scegliere un altro vocabolario per i manager.

Si tratta di processi : tecnologie migliori non rendono programmatori e programmi migliori. Se hai buoni processi in esecuzione, anche le tecnologie obsolete portano a buoni risultati. Pensa a dove fatica e tempo sono sprecati. Forse non è la tecnologia, ma qualcosa nei processi sta andando terribilmente storto. 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 spetta anche a te decidere per quanto tempo vuoi provarlo e quanta energia vuoi investire. Ricorda: anche se non puoi ottenere molti miglioramenti, imparerai molto dai tuoi sforzi. Ad un certo punto devi andare avanti.

Ti sei mai fermato a considerare che potresti avere torto?

Quindi leggi alcuni libri di disegni e modelli a scuola e non hai diritto a quelle che sembrano pratiche relativamente antiquate in cui lavori. Senza dubbio sono probabilmente idee migliori e nuovi progetti dovrebbero iniziare con questi in mente, ma sembra che tu sia a un livello completamente diverso.

Mandare gli sviluppatori è come cercare di radunare i gatti, che hanno intrinsecamente una propria mente e un modo preferito di fare le cose, sia giusto che no. Ho difficoltà a far rispettare le best practice e gestire un team di 2 sviluppatori, ma lavori per un'azienda con 8000.

Questo è un numero incredibilmente enorme. Anche un semplice cambiamento di processo che afferma che tutti gli sviluppatori devono pianificare le riunioni e il tempo fuori sede nel calendario pubblico diventa una politica estremamente complessa e difficile da implementare su tutta la linea. Ciò richiederebbe anche una spinta significativa da parte della direzione per assicurarsi che la politica sia accettata e adottata su tutta la linea.

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

• Significativo supporto gestionale

• Ampia accettazione dell'azienda

• Investimento delle ore di incontro per tutti gli sviluppatori per informarli delle nuove iniziative (Le riunioni costano ore uomo, ore uomo costo denaro)

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

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

Ma stai dicendo: "Pensa a tutto il tempo che potrebbe essere salvato aumentando la produttività". Giustamente, ma un investimento significativo è un rischio significativo, quindi è meglio essere sicuri che tu abbia ragione su questo prima di firmare. Se nessuno dei ragazzi senior ti sta sostenendo, non posso giustificare la spesa. Alla fine potremmo essere inefficienti, ma siamo coerenti e con 8000 sviluppatori in tutta l'azienda, la coerenza è la più importante.

Per fare ciò è necessario disconnettersi da più persone di livello senior ed è necessario trovare in modo accurato e oggettivo un modo per misurare il tempo perso dello sviluppatore verso l'inefficienza. Quel tempo equivale a dollari e solo dollari e politica ti aiuteranno a vincere questa battaglia.

Quello che hai descritto non sembra "dare l'esempio" per me, sembra che tu abbia fatto una proposta e tu sia stato respinto. Per dare l'esempio devi mostrare alle persone che la tua strada è migliore. Tra i problemi che hai elencato ne vedo tre che puoi iniziare a utilizzare tu stesso le tue modifiche.

Vecchi makefile semplici che supportano solo la ricostruzione completa.

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

file e progetti di intestazioni monolitici con pochissimi file diversi (ma ognuno ha circa 3000 righe di codice, che a volte si occupa di compiti molto diversi)

Rompi quelli esistenti quando li tocchi (senza interrompere la generazione) o introduci file di intestazione più piccoli quando scrivi un nuovo codice. Quando le persone iniziano a lavorare con loro, si renderanno conto di non aver bisogno della duplicazione.

nessun uso delle "nuove" strutture linguistiche (bene std :: string non è così nuovo ma nessuno tranne me lo usa)

Continua a introdurre nuove funzionalità 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 funzionalità linguistica semplifica le cose, la adotteremo.

Dopo alcuni mesi, se altri sviluppatori iniziano ad adottare i tuoi miglioramenti, puoi nuovamente rivolgerti al tuo capo su cambiamenti più radicali come l'aggiornamento del sistema di controllo del codice sorgente. Devi assicurarti che gli altri sviluppatori vedano il vantaggio, o non lo passeranno mai. Un modo per avvicinarsi potrebbe essere quello di suggerire di provare Git su un piccolo progetto su cui solo pochi sviluppatori sono attivi. In questo modo è possibile promuoverlo come una valutazione, non una transizione su vasta scala 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 concordo maggiormente), considera anche la possibile motivazione alla resistenza.

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

Ma anche:

• Valutare il costo della modifica in termini di
  • Soldi da spendere per configurare il nuovo ambiente per chiunque
  • Tempo da dedicare alla formazione di tutti per 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 la modifica in modo non distruttivo.

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

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

Ma è possibile che la società stia valutando che i costi aggiuntivi che ti ho detto possono essere risparmiati permettendo che il processo di cambiamento avvenga spontaneamente aspettando che avvenga la sostituzione naturale delle persone. Sei solo all'inizio di un processo che non puoi vedere perché non ha nulla (ancora) dietro di te.

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

Strategia 1 Fallo e basta

Strategia 2 Sfrutta il potere del marketing virale

Strategia 3 Crea una tasca di eccellenza

Strategia 4 Neutralizza i Bozos

Strategia 5 Allontanati dalle interruzioni

Strategia 6 Diventa prezioso

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

Purtroppo le persone restano bloccate in una carreggiata e sviluppano la mentalità che "funziona, tutti lo usano bene, perché cambiarlo" E diventa esasperante.

Hai fatto la cosa giusta 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 incaricato del controllo delle modifiche o dell'innovazione?

Potenzialmente, le tue idee e il tuo lavoro potrebbero essere ignorati e la situazione rimarrà così com'è.

Devi dichiarare 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 da un project manager, quindi dovrai impegnarti nel progetto. (Come percorso alternativo, puoi proporre un audit tecnico, è probabile che un estraneo dica 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 per soddisfare la fantasia di un dev. Per lui contano solo due cose: il flusso di denaro e una squadra stabile. La tecnologia è una scatola nera, se funziona, è abbastanza.

Per prima cosa, devi dimostrare che la configurazione attuale gli sta costando dei soldi. Qual è il costo / ora di uno sviluppatore e quante ore più veloci i tempi di compilazione gli farebbero risparmiare? Fai i conti. Inoltre, compilare articoli o testimonianze sui rischi dell'attuale pipeline di codici e mostrargli numeri spaventosi: "a causa di SourceSafe / Bad Coding Practices, la nostra azienda ha perso $ XXXK".

Secondo il team, il tuo capo potrebbe essere bloccato con vecchi programmatori scontrosi che non vogliono cambiare strada. Se viene stabilito il primo punto, è inoltre 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 il team. Impara le migliori pratiche del settore e verifica che stiano seguendo le nuove regole.

Infine, è necessario proporre un piano per modificare la base di codice, suddivisa in piccoli progetti, con pietre miliari e allocazione delle risorse. In effetti, ti stai vendendo come project manager e le modifiche sono obbligatorie per avere una pipeline di codice solida.

Lavori in un'organizzazione che crede di fare bene le cose, l'efficienza e l'innovazione portano al successo e alla redditività; o che il perseguimento delle entrate e la concentrazione sul mantenimento delle vendite sono gli inquilini del successo?

Le aziende che si comportano come stai descrivendo sono tecnologicamente radicate. In un mercato competitivo non sarebbero in grado di competere con un'azienda focalizzata 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 insediamento, inizierai a scendere a compromessi per la stessa filosofia che i tuoi superiori abbracciano. Vai a lavorare altrove (probabilmente un'organizzazione più piccola) che valorizza il duro lavoro, l'ispirazione, la creatività e il progresso.

Se non corri un rischio e lo farai presto, alla fine ti accontenterai e non sarai in grado di continuare a nutrire la tua curiosità e creatività perché è filosoficamente opposta al tuo attuale gruppo di pari.

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

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

Nella tua prossima intervista poni domande come "Che tipo di innovazioni provengono dai tuoi dipendenti", "Quali sono alcuni cambiamenti che derivano dalla creatività individuale?", "Quali talenti individuali posso portare a questo team?", "Cosa guida il successo delle tue 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 visione o quelle che hanno creato la visione sono sparite e l'organizzazione è gestita da ragionieri. Se stai intervistando il direttore della tecnologia, chiedigli se vede l'organizzazione come una società tecnologica.

Se non ti piace l'ambiente in cui stai lavorando, stai facendo un disservizio 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 a dirsi che a farsi, ma la sensazione di guardare indietro di diversi anni e sentirsi come se avessi perso tempo è peggiore della paura di rischiare.

In alternativa, se vuoi sviluppare un sistema o un ambiente che utilizza tecnologie e / o metodologie specifiche, ti suggerisco di trovare un progetto al di fuori del lavoro a cui puoi contribuire. Per lo meno la varietà di lavorare su entrambi i sistemi soddisferà la necessità di qualcosa di diverso mentre trovi dove appartieni.

Mi sembra che tu sia un pesce fuor d'acqua. Vai a trovare il tuo corpo oceanico e nuota!