Come posso cambiare la cultura aziendale sciatta? [chiuso]

A volte, quando ho un problema che deve essere risolto, scopro che il modo più semplice per risolverlo è scrivere un piccolo programma come strumento personale. Non lo rendo super utilizzabile o super robusto, poiché sono l'unico che lo userà e non ho il tempo di perfezionarlo e testarlo a fondo.

Quindi un collega vede il programma e lo richiede, perché si è imbattuto nello stesso problema e lo strumento potrebbe aiutare. Gli do il disclaimer "Non è carino ma farà il lavoro" e glielo faccio fare.

La prossima cosa che so, il mio superiore mi sta chiamando, dicendomi che sta cercando di far funzionare il software sul computer di un client ma sta mostrando un messaggio di errore X. WTF ?? Quel software non è pronto per il rilascio, né mi è stato detto che doveva essere pronto per il rilascio. Ma per qualche ragione, il mio superiore ha pensato che fosse abbastanza buono e lo ha rilasciato senza dirlo allo sviluppatore originale.

Ora, questo particolare problema è facile da risolvere con a MessageBox.Show("DO NOT GIVE TO CLIENTS!");. Tuttavia, il problema è indicativo di un problema molto più profondo: la nostra cultura aziendale è sciatta. Il software sciatto è OK e i processi sciatti sono OK. Non preoccuparti per il futuro: fai abbastanza sforzo per farlo funzionare a malapena ora, metti i binari in un file .zip e spediscilo. Abbastanza buono per il lavoro del governo.

Questa è una piccola azienda con 10 dipendenti a tempo pieno, sta crescendo ed è in circolazione da un po 'di tempo. Non fraintendetemi; Adoro lavorare qui e adoro la compagnia. Non dirmi di correre; Voglio far parte del miglioramento dell'azienda. Come inizi a portare un buon cambiamento a questo tipo di cultura?

L'unico modo per cambiare è far vedere a tutti gli aspetti negativi di una cultura sciatta e, forse ancora più importante, avere un buy-in da parte della direzione per risolverlo. In realtà, tuttavia, ciò non accade e non sarai in grado di cambiarlo. Potrebbe non essere la risposta che ti aspettavi di sentire, ma dopo circa cinque anni 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.

Il primo passo sarebbe scoprire se qualcun altro conosce o si preoccupa della cultura sciatta; se sei l' unica persona a riscontrare problemi, i tuoi sforzi sono vani.

Potrebbe essere necessario avere un incontro con il collega e il capo e spiegarti che quello che avevi era un prototipo e non era pronto per essere utilizzato dai clienti. Se volevano che fosse pronto per l'uso da parte dei clienti, è possibile apportare tali modifiche con il tempo sufficiente, ma per favore non prendere le cose "veloci e sporche" e passarle 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 risolvere lo stupido. Se il tuo capo sta facendo cose come la descrivi, è improbabile che tu possa cambiarlo. Soprattutto se non è il proprietario - ricorda, ha una pressione proveniente dall'altra direzione e quella direzione firma il suo assegno salariale. Lo stesso con gli altri colleghi. Il miglior primo modo di agire che puoi intraprendere è prendere l'abitudine di proteggerti. Usa tecniche come quella finestra di messaggio che descrivi. Conserva tutte le email. Ottieni quanto più puoi in forma scritta. In questo modo non si prende il peso quando colpisce la stupidità. Quindi, quando vieni promosso, istituisci le modifiche che desideri con quelle sotto la tua supervisione.

L'altro giorno, un collega mi ha raccontato la storia di un semplice strumento di test per consentire a un ingegnere in un laboratorio di inviare un singolo comando a un widget e modificare una variabile associata al comando. Questo è stato scritto 9 anni fa ormai, e l'ultimo lo 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 scritto il codice, esiste. Se fa qualcosa di utile ed è visto da altre persone, la gente lo vorrà. Se è bravo in quello che fa, le persone lo chiederanno per fare X. La prossima cosa che sai, il tuo semplice strumento è un componente significativo.

Penso che la prima responsabilità spetti allo sviluppatore del software 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 spiega perché sia ​​così. Sembra che tu l'abbia fatto, tuttavia i tuoi colleghi hanno trascurato di portare avanti quella responsabilità. Per risolvere questo problema, consiglierei di parlare con loro, ribadendo che questo non era un codice di produzione ed era stato scritto solo per facilitare il tuo lavoro. Se lo trovano utile, forse offrono 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, aspettatevi che ci vorrà del tempo. Inizia dando un esempio. Se non hai letto The Pragmatic Programmer , fallo. Prendi nota di suggerimenti come Cura del tuo mestiere, Sii un catalizzatore per il cambiamento (mostra modi migliori alle persone), Non vivere con le finestre rotte, Risolvi il problema, non la colpa. Sembra che tu riconosca alcuni problemi affrontati da questi suggerimenti, quindi inizia a lavorare e vivere un esempio per i tuoi colleghi.

Fino a quando i responsabili delle decisioni non tollerano più le conseguenze del codice errato e sono disposti a pagare / cambiare il loro modo di risolvere il problema.

Queste sono decisioni difficili per le aziende piccole e in crescita. Non sanno dove mettere tutti i loro sforzi. Esiste un rischio che rende il codice troppo solido quando le regole aziendali e talvolta intere linee di business 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 cattivo codice viene messo in produzione, tienilo d'occhio se puoi e continua a suggerire di migliorarlo soprattutto se quella parte del business diventa critica.

Far aspettare le persone per quello che vedi come codice minimamente praticabile sembra essere al di là delle loro aspettative attuali.

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

Se il tuo compagno lo vuole, o educatamente digli che non è completamente funzionale, e tieni le chiavi. Puoi eseguirlo di volta in volta. In alternativa, aggiungi le funzionalità extra, preferibilmente dall'inizio del progetto.

Tutti i miei strumenti veloci e sporchi a questo punto provengono da un file scheletro pesantemente testato. Mi permette di andare rapidamente, mi fornisce un punto di partenza funzionante e mi fa dimenticare di aggiungere tutti quei bordi smussati necessari. Non devo preoccuparmi della libreria getopts e delle sue stranezze. Non ho bisogno di ricordare i dettagli sulla gestione della memoria quando uso Python. Costruisci il programma in modo che esegua una semplice attività e una sola . Questo rende facile testare se stanno cercando di piegarlo fuori forma.

Infine, approfitta dell'architettura delle macchine a stati finiti. Se sai di andare in tutti i possibili stati, è molto più facile assicurarsi che, indipendentemente da ciò, l'utente non potrà 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 avesse 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ò provocherebbe la pulizia, la chiusura e la segnalazione con garbo dell'utente che hanno bisogno che io lo guardi.

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

Potresti non essere in grado di cambiare la cultura, perché le persone potrebbero non avere un vero motivo per non essere sciatte, 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 fare il loro lavoro, ma hanno poca partecipazione personale nell'efficacia di quel software, perché non saranno personalmente accusati dei suoi problemi o ricompensati per le sue virtù (in gran parte perché nessuno sa davvero se il software della concorrenza sarebbe meglio). Quindi potresti dover solo soddisfare le loro richieste di funzionalità senza impiegare troppo tempo, ma non devi preoccuparti molto se si tratta di un bug. Quindi puoi essere abbastanza sciatto senza conseguenze (per chiunque prenda decisioni che ti riguardano).

Non so se qualcosa del genere sia il caso, ma se è così potresti avere difficoltà a cambiare la cultura poiché le persone che stai cercando di cambiare non andranno davvero meglio se lo fanno.

Se staranno meglio, potresti avere un momento più facile, dal momento che puoi potenzialmente convincerli perché lo faranno. Sfortunatamente, se non ci fosse una sorta di situazione politica che rende OK la sciatta, probabilmente non sarebbero sciatti in primo luogo, quindi è probabile che sia dura. Potresti sempre provare l'argomento "un giorno potresti avere un lavoro che richiede di fare le cose nel modo giusto" (forse con parole più diplomatiche ...)