Come convincere i miei colleghi che fare le cose bene gli farà risparmiare tempo

Di recente ho iniziato in una nuova società, con una manciata di programmatori. È un'azienda di medie dimensioni, con circa 70 dipendenti, ma l'IT ha solo 9-10 e oltre a me ci sono 3 "programmatori". Tuttavia, questi ragazzi hanno un'esperienza molto limitata e stanno facendo un sacco di cose davvero terribili. Ad esempio, uno dei nostri progetti è un sito Web PHP. La maggior parte del codice è memorizzata in un controller PHP di 20.000 righe, con ~ 6000 righe di JavaScript integrate nel PHP.

Continuo a dare piccoli suggerimenti qua e là ma nessuno ha ascoltato, tutti dicono che sono troppo impegnati per implementare i miei suggerimenti. Il fatto è che non dovrebbero essere così occupati e non lo sarebbero se le cose fossero fatte bene. Passano la maggior parte del loro tempo a riparare cose che continuano a rompersi. Se ogni progetto fosse realizzato correttamente, avrei potuto fare tutto da solo.

Quale approccio devo adottare per convincere questi ragazzi o il manager che le cose devono cambiare e che cambiare le cose farà risparmiare un sacco di tempo? Devo saltare il tentativo di convincere i miei colleghi e andare direttamente dal direttore, con una proposta commerciale su come la società risparmierà un sacco di soldi se inizieranno a fare le cose giuste?

Ho scoperto che la causa principale del lavoro sciatto, al di fuori del programmatore semplicemente non premuroso, è la mancanza di conoscenza. Sfortunatamente in molti ambienti, la mancanza di conoscenza viene guardata in basso piuttosto che discussa apertamente.

Alcune tecniche che ho usato con successo per favorire la discussione, la crescita e l'entusiasmo generale per la programmazione sono:

• Sessioni tecnologiche settimanali di borse marroni (chiedi loro di cercare un argomento e un presente).
• Sessioni di tutoraggio giornaliere o settimanali tra membri junior e senior.
• Revisioni del codice (con particolare attenzione all'apprendimento, non alla segnalazione di errori).

L'apprendimento è contagioso. Quando promuovi un ambiente che incoraggia l'apprendimento non solo produci sviluppatori migliori, ma mostri agli altri nel tuo team che fanno parte di qualcosa di più grande di un modo per ottenere uno stipendio.

Dopo aver visto che sei stato assunto come sviluppatore Sr. PHP e il tuo compito è quello di sistemare le cose, ti suggerisco che è tempo di flettere un po 'di muscoli.

Se fossi al tuo posto, farei un buon sondaggio sul codice e vedrei errori che si verificano continuamente. Blocca l'orario delle riunioni ogni settimana per esaminare queste cose con il team. Non puntare le dita o i nomi dei nomi, mostra solo come eseguire correttamente l'attività.

Successivamente, poiché hai già visto che è necessario correggere, crea un elenco. Se è veloce e facile da fare, fallo. Se ti semplificherà la vita ... fallo. Fai un elenco di tutte le cose che devono essere fatte e crea biglietti per loro e vedi quando le persone hanno dei cicli per farle. Se qualcuno sta risolvendo un bug in un'area problematica, spiegagli come risolverlo correttamente.

Se richiede un grande cambiamento, siediti con la squadra e gli stakeholder e discuti delle opzioni.

Avere una politica a porte aperte in cui aiuterai le persone. Sii qualcuno che educa e non intimidisce. No, "devi farlo in questo modo" e altro ancora "sarebbe meglio se fosse fatto in questo modo". Spiega i vantaggi di farlo nel modo che suggerisci e gli svantaggi del modo in cui è stato fatto. Le persone saranno più disposte a farlo nel modo giusto se sentiranno di aver imparato qualcosa invece di sentirsi dire che la loro strada è sbagliata e di farlo in un altro modo b / c che dici così.

Prospettiva della direzione del problema Se hanno accettato il tempo di sviluppo in relazione alla quantità di difetti, perché dovrebbero rischiare? Quando i benefici a lungo termine contraddicono gli obiettivi a breve termine, di solito perdono. Stai chiedendo loro di fare un passo indietro. Potrebbero pensare che ciò causerà un lungo ritardo. Devi convincerli che non insieme ai vantaggi aggiunti. Se non pensano di avere un pasticcio, chiedi loro di spiegare perché ci vuole così tanto tempo per introdurre rapidamente nuovi bug con ogni "correzione".

La qualità del codice dipende da molte circostanze e situazioni. Vendite, marketing e dirigenti ti faranno credere che ogni scadenza non riuscita significa che la società mancherà a un colpo contro il mega-milione di investitori in capitale di rischio. La realtà è che non vogliono dare la brutta notizia all'1% dei tuoi clienti che comunque non hanno davvero bisogno della funzione. Sono estremo e di solito cade da qualche parte nel mezzo, quindi gli sviluppatori devono imparare cos'è un'emergenza reale. Quindi è più facile convincerli a prendere il tempo per farlo bene invece di aver bisogno di tempo per farlo. Devi capire i rischi.

Come un grande romanzo, il codice non viene scritto bene la prima volta, ma sfortunatamente viene ancora pubblicato troppo spesso. Inizia con qualcosa di fondamentale come stabilire uno standard di codifica. Ognuno ne ha uno, ma molti come nella tua situazione, non sono stati formalizzati né sono molto severi. "Fai quello che vuoi." è uno standard che è molto facile da mantenere. Il prossimo passo è determinare come mantenere i tuoi standard.

Hai un compito importante davanti a te. Forse alcuni grandi programmatori hanno sviluppato le loro abilità e abitudini nella misura in cui non devono mai scendere a compromessi sulla qualità del loro codice o andare in debito tecnico, ma aspettano e vedono cosa succede quando quell'investitore angelo promette che tutti diventeranno ricchi.

Siediti e scrivi il prototipo (o qualche modulo se l'intero progetto è troppo grande) che utilizza un design davvero buono come ritieni opportuno. Quindi presentare / discuterne con il team. Potrebbe essere più facile convincere con l'esempio.

In questo processo, potresti anche scoprire che alcuni strumenti, librerie, approcci o simili non sono così buoni. Valuta sempre prima e chiedi al tuo team di usarlo in seguito. Fai attenzione al marketing a basso costo con strumenti scadenti.