Come posso cambiare la cultura aziendale sciatta? [chiuso]

L'unico modo per cambiare è far vedere agli altri gli aspetti negativi di una cultura sciatta e, forse ancora più importante, avere un management buy-in per risolverlo. In realtà però, ciò non accade e non sarai in grado di cambiarlo. Potrebbe non essere la risposta che ti aspettavi di sentire, ma dopo cinque anni circa di tentativi e fallimenti in diversi lavori per cambiare la cultura sciatta, posso dire con una certa autorità che di solito non vale la pena di fare lo sforzo.

Il primo passo sarebbe scoprire se qualcun altro conosce o si preoccupa della cultura sciatta; se sei la persona solo che vede problemi, i tuoi sforzi sono vani.

Potrebbe essere necessario avere un sit-down con il collega e il capo e spiegare che quello che avevi era un prototipo e non era pronto per essere usato dai clienti. Se volevano che fosse pronto per essere usato dai clienti, potresti apportare quei cambiamenti con un tempo sufficiente, ma per favore non prendere le cose "veloci e sporche" e trasmetterle ai clienti. Solo perché qualcosa funziona, non è bello essere la lezione da imparare. Mentre hai dato un disclaimer c'è qualcosa da dire per dargli un po 'di rispetto altrimenti questo è ciò che può accadere.

Non puoi sistemare stupido. Se il tuo capo sta facendo cose come le descrivi, è improbabile che tu possa cambiarle. Soprattutto se non è il proprietario - ricorda, ha una pressione proveniente dall'altra direzione, e quella direzione firma il suo assegno. Lo stesso con gli altri tuoi colleghi di lavoro. Il miglior primo corso di azione che puoi intraprendere è prendere l'abitudine di proteggerti. Usa le tecniche come quella finestra di messaggio che descrivi. Mantieni tutte le email. Prendi il più possibile in forma scritta. In questo modo non prendi il peso quando la stupidità colpisce. Quindi, man mano che tieni promosso, istituisci le modifiche che desideri con quelle sotto la tua supervisione.

L'altro giorno, un collega mi ha raccontato una storia di un semplice strumento di test per consentire a un ingegnere in un laboratorio di emettere un singolo comando su un widget e cambiare una variabile che va con il comando. Questo è stato scritto 9 anni fa, e per quanto ne sapeva, è ancora in uso oggi. Uno strumento che è stato scritto in un paio d'ore con test minimi per dimostrare, in laboratorio, che qualcosa funziona, è stata la base per un intero strumento di test di laboratorio di ingegneria. Una volta che scrivi il codice, esiste. Se fa qualcosa di utile ed è visto da altre persone, la gente lo vorrà. Se è buono in quello che fa, le persone chiederanno che faccia X. La prossima cosa che sai, il tuo strumento semplice è un componente significativo.

Penso che la prima responsabilità dello sviluppatore del software sia assicurarsi che chiunque guardi il codice o utilizzi lo strumento capisca che si tratta di un prototipo o meno di un sistema di produzione e dì perché è così. Sembra che tu l'abbia fatto, tuttavia i tuoi colleghi hanno trascurato di portare avanti questa responsabilità. Per risolvere questo problema, consiglierei di parlare con loro, ribadendo che questo non era un codice di produzione e che è stato scritto solo per facilitare il vostro lavoro. Se lo trovano utile, forse offri di lavorare sullo strumento o di supportare altre persone che lavorano sullo strumento per migliorarlo e renderlo più adatto alla produzione.

Per quanto riguarda il processo organizzativo o il cambiamento culturale, aspettati che ci vorrà un po 'di tempo. Inizia impostando un esempio. Se non hai letto The Pragmatic Programmer , fallo. Prendi nota di suggerimenti come Care About Your Craft, Sii un catalizzatore per il cambiamento (mostra alle persone i modi migliori), Non vivere con le finestre rotte, Risolvi il problema e non la colpa. Sembra che tu riconosca alcuni problemi affrontati da questi suggerimenti, quindi inizia a lavorare e a dare un esempio ai tuoi colleghi.

Finché i responsabili delle decisioni non tollerano più le conseguenze del codice errato e sono disposti a pagare / cambiare i loro modi per risolvere il problema.

Queste sono decisioni difficili per aziende piccole e in crescita. Non sanno dove mettere tutto il loro impegno. Esiste il rischio di rendere il codice troppo solido quando le regole aziendali e talvolta interi settori di attività appaiono, cambiano e scompaiono durante la notte.

Cerca di scrivere un buon codice. Assicurati di informare tutti delle conseguenze in modo che possano prendere decisioni informate. Se il codice errato viene messo in produzione, tienilo d'occhio se puoi e continua a suggerire di migliorarlo, soprattutto se quella parte dell'attività diventa critica.

Rendere le persone in attesa di ciò che vedi come codice minimamente praticabile sembra essere al di sopra delle loro attuali aspettative.

Vorrei sottolineare che parte del problema qui è che hai scritto uno strumento veloce e sporco in primo luogo. Certo, c'erano buone ragioni. Certo, ha fatto il lavoro. Ma , ho trovato che qualsiasi che risolve un problema, cadrà nella trappola di una soluzione "abbastanza buona", se inizi a distribuirlo.

Se il tuo collega lo desidera, o gli dici educatamente che non è completamente funzionante e che stai tenendo le chiavi. Puoi eseguirlo per lui di volta in volta. Oppure aggiungi la funzionalità extra, preferibilmente dall'inizio del progetto.

Tutti i miei strumenti veloci e sporchi a questo punto provengono da un file scheletro molto testato. Mi consente di andare avanti rapidamente, mi fornisce un punto di partenza funzionante e mi consente di dimenticare di aggiungere tutti quegli spigoli necessari. Non devo preoccuparmi della libreria getopts e delle sue stranezze. Non ho bisogno di ricordare dettagli sulla gestione della memoria quando uso python. Costruisci il programma in modo che esegua un'attività semplice e solo una . Ciò rende facile testare se stanno cercando di piegarlo fuori forma.

Infine, approfitta dell'architettura della macchina a stati finiti. Se sai di andare in tutti i possibili stati, è molto più facile fare in modo che, indipendentemente da cosa, l'utente non possa mai saltare le tracce. Ho un programma che ho scritto per seguire questo paradigma. Accetta file di input arbitrari, che legge byte per byte. Anche se il client gli ha detto di leggere un eseguibile binario, non avrebbe avuto problemi. Dal momento che non trova nessuna delle cose che sta cercando, il suo buffer interno si riempirebbe. Ciò lo farebbe pulire, chiudere e riportare all'utente che hanno bisogno che io lo guardi.

Bene, la risposta non ha molto a che fare con la programmazione, tranne che il software è un bene che è difficile giudicare facilmente la qualità di.

Potresti non essere in grado di cambiare la cultura, perché le persone potrebbero non avere motivi reali non di essere trascurati, perché le persone interessate dalla qualità del software non hanno molto a che fare con il processo . Ad esempio, ai tuoi clienti potrebbe essere richiesto di acquistare e utilizzare software per svolgere il proprio lavoro, ma hanno poca scommessa personale sull'efficacia del software, perché non saranno personalmente biasimati per i suoi problemi o premiati per le sue virtù (in gran parte perché nessuno sa davvero se il software in competizione sarebbe meglio). Quindi potresti dover soddisfare le loro richieste di funzionalità senza prendere troppo a lungo, ma non devi preoccuparti troppo del fatto che sia bacato. Quindi puoi essere abbastanza sciatto senza conseguenze (per chiunque prenda decisioni che ti riguardano).

Non so se una cosa del genere è il caso, ma se è così potresti avere difficoltà a cambiare la cultura, dal momento che le persone che stai cercando di cambiare non saranno in realtà meglio se lo facessero.

Se staranno meglio, potresti avere un momento più semplice, dal momento che puoi potenzialmente convincerli perché lo faranno. Sfortunatamente, se non ci fosse un qualche tipo di situazione politica che rende sciatto O.K. probabilmente non sarebbero essere sciatti in primo luogo, quindi è probabile che sia duro. Potresti sempre provare l'argomento "un giorno potresti avere un lavoro che richiede di fare le cose per bene" (forse più diplomaticamente formulato ...)