Colpire la cultura come uno sviluppatore appena assunto [chiuso]

Ok, il primo passo per me è scoprire perché / chi altro capisce che questo è un problema importante. Ad esempio, se qualche manager a metà della "catena di comando" nasconde il fatto che il lavoro di sviluppo non viene eseguito "su standard affidabile", potresti trovarti nei guai se lo esponi (ovviamente non in una BUONA azienda dove i gestori ascoltano al personale, ma alcune aziende non sono buone).

Il secondo passo è trovare gli argomenti per il tuo progetto. Puoi dimostrare che il codice del progetto attuale è affetto da una cattiva disciplina? Ad esempio, quanti bug sono causati dalla mancanza di revisione del codice.

(Naturalmente anche la revisione del codice non è perfetta, di recente ho introdotto un bug spostando una variabile da un ciclo [perché ne avevo bisogno nel contesto anche dopo il ciclo], che ha portato al valore non impostato in una condizione insolita - > errore rilevato nei test notturni. Il codice è stato esaminato da due o tre ingegneri esperti che non hanno individuato questo ...)

In terzo luogo, puoi dimostrare che il lavoro sarà effettivamente più efficiente "dopo questi cambiamenti"?

Se riesci a mostrare queste cose, la maggior parte dei gestori accetterà di introdurre cambiamenti, perché migliora la produttività. Ma se vai semplicemente in un manager e dici "Il lavoro non è molto bello qui ...", potresti non arrivare così lontano ...:)

Nella mia esperienza professionale (26 anni combinati in tre luoghi di lavoro molto diversi, senza contare la scuola di specializzazione), ci sono momenti in cui una squadra fa meglio con documentazione, revisione, test e simili, e altre volte quando fa peggio . Può essere influenzato da scadenze esterne o da una serie di altri fattori. Il "brutto tempo" può durare molto più di 6 mesi e le persone sono meno disposte del solito ad alimentare le idee del nuovo noleggio sulle migliori pratiche quando si sentono in dovere di rinunciare a qualcosa di proprio.

O può essere che sia sempre stato così in quel gruppo finché qualcuno se ne ricorda. In tal caso, ci vorrà un po 'di tempo per cambiare le vecchie abitudini; al contrario, se l'intero castello di carte non sta già crollando a questo punto, probabilmente può essere sostenuto per un tempo sufficiente per implementare i cambiamenti gradualmente.

Quanto è grande il reparto in cui lavori?

Recentemente ho implementato una serie di standard per lavorare con il controllo del codice sorgente in cui lavoro poiché usavamo cose come (a) messaggi criptici che solo l'autore e (forse) il recensore del codice capivano, (b) i commit monolitici che dovrebbero essere diviso in commit separati (ad es. 'change comment', 'fixed bug', 'rinominato metodo', ecc.).

Il modo in cui l'ho fatto era di:

• Portalo con i miei dirigenti nella mia recensione annuale (il tuo punto 3).
• Invio di un'e-mail agli sviluppatori del mio dipartimento dicendo che stavo scrivendo uno standard e chiedendo di vedere se avevano suggerimenti / pensieri (il tuo punto 1).
• Dopo aver completato la bozza finale, invialo per chiedere agli sviluppatori di chiedere un feedback.
• Organizzare un incontro in cui le persone discutono apertamente di eventuali cambiamenti ritenuti utili (ho acquistato una piccola scatola di cioccolatini all'incontro per addolcire l'accordo).

Anche se non è stato un successo completo, il modo in cui il dipartimento usa il controllo del codice sorgente è sicuramente migliorato di conseguenza (credo).

Se fossi in te (e in base a quante persone devi influenzare), parlerei con il maggior numero possibile di persone, informerò gli altri che lo stai facendo (potresti guadagnare punti brownie con la gestione per mostrare l'iniziativa) e ricerca accuratamente qualsiasi modifica tu voglia fare: in questo modo puoi far vedere agli altri perché dovrebbero seguire i tuoi suggerimenti.

modifica : vorrei sottolineare che ci sono circa 15 sviluppatori nel reparto in cui lavoro.