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

Ho scoperto che la causa principale del lavoro sciatto, al di fuori del programmatore, semplicemente non è la cura, è una 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'eccitazione generale sulla programmazione sono:

• Sessioni tecnologiche settimanali di borsa marrone (invitali a cercare un argomento e presenti)
• Ogni giorno o settimanalmente sessioni di tutoraggio tra i membri junior e senior.
• Revisioni del codice (con enfasi sull'apprendimento, senza evidenziare errori).

L'apprendimento è contagioso. Quando promuovi un ambiente che incoraggia l'apprendimento, non solo produci sviluppatori migliori, ma mostra agli altri membri del 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 di Sr. PHP e il tuo compito è quello di sistemare le cose, ti suggerisco che è ora di flettere un po 'di muscoli.

Se fossi al tuo posto, farei un buon sondaggio del codice e vedrò gli errori che si ripetono più e più volte. Blocca il tempo di riunione ogni settimana per andare oltre queste cose con il team. Non puntare le dita o nomi di nomi, solo mostrare come eseguire correttamente tale compito.

Quindi, visto che hai già visto le correzioni delle esigenze, crea una lista. Se è veloce e facile da fare, fallo. Se ti renderà la vita più facile averlo fatto ... fallo. Fai una lista di tutte le cose che devi fare e fai i biglietti per loro e vedi quando le persone hanno dei cicli per farlo. Se qualcuno sta correggendo un bug in un'area problematica, spiegalo come risolverlo correttamente.

Se richiede un grande cambiamento, siediti con il team e i detentori di interessi e discuti le opzioni.

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

Prospettiva del problema della gestione 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 questo causerà un lungo ritardo. Devi convincerli che non con i benefici aggiunti. Se non pensano di avere un disastro, 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. Le vendite, il marketing e i manager ti faranno credere che ogni scadenza fallita significhi che la società mancherà a quell'unico colpo al mega-million investor in venture capital. La realtà è che non vogliono rompere la brutta notizia all'1% dei tuoi clienti che non avevano davvero bisogno della funzionalità. Sono estremo e di solito cade da qualche parte nel mezzo, quindi gli sviluppatori devono imparare che cos'è un'emergenza reale. Quindi è più facile convincerli a prendersi il tempo per farlo correttamente invece di aver bisogno di tempo per farlo. Devi capire i rischi.

Come un grande romanzo, il codice non è scritto bene la prima volta, ma purtroppo 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 molto semplice da mantenere. Il prossimo passo è determinare come manterrai i tuoi standard.

Hai un compito importante davanti a te. Forse alcuni grandi programmatori hanno sviluppato le loro abilità e le loro 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'angelo investitore promette che tutti diventeranno ricchi.

Siediti e scrivi il prototipo (o qualche modulo se l'intero progetto è troppo grande) che utilizza un design davvero valido come meglio credi. Quindi presentalo / discutine 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 per primo e chiedi al tuo team di usarlo più tardi. Fai attenzione al marketing a basso costo su strumenti scadenti.