Come convincere gli altri ad effettuare il cambiamento? [chiuso]

How do I persuade even 1 person that there is a better way?

Parli con loro. Li mostri.

Ma non importa affatto. Due persone, anche dieci persone non cambieranno la cultura di una grande organizzazione.

L'org ama le cose così come sono adesso. Hanno incentivato le persone a fare le cose come sono adesso. Le persone sono state premiate e promosse per aver costruito quello che c'è adesso, quindi considerale buono. E l'org ha avuto molto successo nel fare le cose nel modo in cui sono state fatte le cose, quindi vederle come buone.

L'uomo basso sul totem non cambierà mai quell'org di qualsiasi dimensione significativa.

È uno slogan lungo e difficile per tracciare i vantaggi dell'adozione delle migliori pratiche che temo. Il miglior consiglio che posso dare è quello di cercare di trovare un problema di peso medio - un bug che è costato un bel po 'di tempo e problemi da risolvere, ad esempio, magari con più di un tentativo di riparazione - e tracciare il tempo e il denaro necessari sono stati salvati se il prodotto fosse correttamente strutturato o almeno strutturato in modo diverso. Prova a dirlo in termini di "questo sta funzionando per te, ma immagina quanto tempo avresti più tempo e quanto meno lo stress ci sarebbe se potessimo trovare un modo migliore".

Ci sono molti modelli e pratiche di blog, articoli e white paper da fonti attendibili che puoi usare per supportare la tua discussione, ma soprattutto consiglierei di adottare l'approccio "non sarebbe bello se ..." piuttosto che l'approccio "voi ragazzi dovete essere pazzi per ...". Volete che vogliano migliorare, non sentirsi criticati per le pratiche che, per quanto li riguardano, sono perfettamente ragionevoli e hanno servito bene.

Recentemente ho dovuto eseguire un intervento chirurgico importante su un prodotto maturo perché le cose erano strutturate male, e sono riuscito a vincere perché nel modificare il progetto ho ottenuto miglioramenti significativi delle prestazioni e notevolmente migliorato la stabilità del prodotto. Potrebbe valere la pena trovare un'area del tuo prodotto che puoi iniziare a modellare in questo modo, ma assicurati che le persone sappiano cosa stai facendo e perché. In fin dei conti è una decisione aziendale e, se riesci a renderlo un po 'più semplice, che offre importanti miglioramenti nel processo e nella produzione, il tuo compito sarà tanto più semplice.

Buona fortuna a te!

How do you explain that this large organization practices zero industry standards and follows no software patterns? Yet everyone seems completely happy and convinced that nothing is wrong.

Come questo: Wow! Questa grande organizzazione non fa nulla di ciò che mi è stato detto è buono! E fanno anche cose che mi hanno detto sono cattive! Ma questa organizzazione di grande successo non sembra dispiacere. Cosa sto trascurando? Posso imparare qualcosa da loro? Quali problemi stanno cercando di risolvere assumendomi?

This is the least maintainable, least testable code I have seen in my 20 years of software development.

Prevedo che qualsiasi cosa al di fuori della tua zona di comfort si sentirà poco maneggevole e cattivo per te. Ma se non riesci a rompere le cose e spiegare perché sono cattivi per la compagnia, perché sono in contrasto con i suoi obiettivi, la tua preoccupazione non è necessariamente razionale; sei solo a disagio. E la compagnia può tollerare il tuo disagio.

How do I persuade even 1 person that there is a better way?

Identifica i problemi che la società ha effettivamente.

Queste cose non sono problemi inerenti:

• Non aderente agli standard
• Non si utilizzano i pattern software
• Il codice non è stato testato unitamente
• "ALL logica / html / style / js è nelle procedure del database"

Inherently, sono solo "cose". Raggiungono lo stato di "problemi" solo se portano a "problemi reali" più importanti. Problemi a cui la società potrebbe interessare un suono del genere:

• "Chrome sta per soffocare sul nostro markup non standard durante il prossimo aggiornamento e la nostra proprietà web principale sarà totalmente inutilizzabile."
• "Ci vorrà circa un mese per propagare la modifica dell'intestazione su tutto il sito."
• "Abbiamo giocato a whack-a-mole con gli stessi tre bug ricorrenti per circa 2 mesi ..."

Se la tua azienda riconosce i problemi e riconosce che sono prioritarie, puoi iniziare a parlare di soluzioni fattibili e quanto di un investimento temporale le soluzioni valgono. Ma preparati! Potrebbero sentirti e dire, "Quello che stai chiamando i problemi non sono davvero problemi per noi" o "Ciò per cui stiamo lavorando per ora" e "Le soluzioni proposte non sono un guadagno netto per noi".

Tieni presente che sei stato assunto per svolgere un determinato lavoro in un'azienda che ha già successo in in qualche modo. Potresti avere alcune grandi preoccupazioni e principi stellari, ma potresti anche essere manca il "quadro generale" dell'azienda. Non avrai alcun supporto dalla compagnia se non ci sono connessioni tra i tuoi principi come loro.

Per prima cosa dovresti considerare se "la tua strada" effettivamente è migliore. Se tutti sono felici e non percepiscono alcun problema, allora devono fare esattamente qualcosa . Se stanno raggiungendo i loro obiettivi senza seguire lo "standard del settore", forse hanno inconsapevolmente sviluppato un processo che è effettivamente migliore dello standard del settore?

È veramente difficile vendere un cambiamento di processo a qualcuno che non percepisce un problema con il loro approccio attuale. Devi essere in grado di dimostrare che le modifiche che suggerisci in realtà è un miglioramento. Devi assolutamente escogitare argomenti migliori di quelli che affermano che il codice non è "standard industriale" o "non usa schemi", poiché nessuno dei due ha un valore in sé.

In primo luogo, trova alcune prove per i reali problemi dell'organizzazione. Sopra hai scritto

practices zero industry standards

Non vedo un problema qui.

and follows no software patterns

Ancora nessun problema.

This is the least maintainable, least testable code I have seen in my 20 years of software development.

Questo è solo un giudizio generale, motivato, nessun problema concreto.

ALL logic/html/style/js is in the database procedures

Sono abbastanza sicuro che un team di validi ingegneri del software potrebbe creare un sistema ben strutturato utilizzando PL / SQL e Oracle come piattaforma, quindi non è stato ancora dato alcun problema in quella frase.

Quindi, nella tua domanda, non ci sono molte prove che ci sia bisogno di qualsiasi tipo di cambiamento. Ma in un commento hai scritto

constant bugs, unable to fix problems quickly, unable to bring new folks on board, having the core guys overwhelmed yet the rest of us sit around and do nothing

Bene, ecco le questioni interessanti che hai "dimenticato" di menzionare nella tua domanda. Ma hai ancora bisogno di saperne di più sulle cause profonde di queste cose, quindi potresti essere in grado di migliorare le cose.

• bug costanti? Sembra che la garanzia della qualità e i test debbano essere migliorati. Forse l'introduzione di alcuni test automatici può aiutare (non dirmi che questo non è possibile perché tutto è nel DB - ho scritto il codice di test in PL / SQL quasi 20 anni fa).

• Impossibile risolvere rapidamente i problemi? Può avere diversi motivi, trovare le cause principali. Forse mancano strumenti di debug e logging, forse la documentazione è brutta, forse le persone hanno bisogno di più formazione, forse il codice è malamente leggibile. Trova la causa, quindi puoi lavorarci sopra.

• Impossibile portare nuove persone a bordo? Trova la causa. È perché il sistema è così mal documentato? È necessaria più formazione? Oppure perché nessun nuovo arrivato conosce PL / SQL? Forse ci sono possibilità di sviluppare alcune nuove parti con un set di strumenti diverso.

(E spesso un argomento: queste persone hanno già sentito parlare dell'uso del controllo del codice sorgente?)

E così via. Certo, ci saranno anche problemi politici da risolvere, il che non è nulla che possiamo aiutarti (la migliore raccomandazione qui: trovare persone che ti sostengono). Ma non provare a cambiare l'intera organizzazione in una sola volta. Trova un problema in cui hai una certa influenza, imposta un obiettivo realistico per un leggero miglioramento, prova a implementarlo e rendilo pubblico dopo che ha funzionato. Risciacqua e ripeti. Se sei fortunato, altri seguiranno il tuo esempio dopo un po 'di tempo.