Ovviamente, licenziarli o segnalarli alla direzione è un'opzione; se fosse o meno la mia prima scelta come opzione dipenderebbe dal fatto che siano o meno anche dei buoni sviluppatori.
Sembra errato inviare una persona molto intelligente che impacchetta solo perché non segue il processo. Soprattutto se non comprendi pienamente perché non seguono il processo. Suggerirei che invece di etichettare semplicemente questa persona come un rinnegato e in cerca di modi per affrontare la persona , ti occupi di ciascuno dei comportamenti problematici uno per uno e cerca i modi per gestire questi specifici comportamenti .
Ad esempio:
-
Non affidare le cose al controllo del codice sorgente è esasperante (come guida, di tanto in tanto ho dovuto scherzare educatamente su questo argomento) ma a volte è difficile trovare alternative, specialmente se stai usando VCS centralizzato vecchia scuola dove solo tu avere una possibilità di risolvere conflitti di fusione e commit.
Quando si ha a che fare con TFS o anche con SVN, prima che i plugin git-tfs o git-svn fossero stabili, dovrei fare spesso dei backup della mia copia di lavoro nel caso in cui avessi incasinato un'unione. Nelle aziende in cui i conflitti di fusione sono difficili da risolvere o le build danneggiate non vengono gestite correttamente, i commit ritardati o nessun commit possono essere un comportamento difensivo che rimanda a problemi organizzativi di livello superiore che devono essere risolti.
Non dire nulla di ciò si applica a te o al tuo compagno di squadra o alla tua organizzazione, il punto è non lo sappiamo , e presumo che tu non lo sappia, altrimenti probabilmente avresti incluso quella informazione nella tua domanda. (Giusto?)
-
Per il problema n. 1 (utilizzando l'e-mail per l'assegnazione del lavoro), la soluzione è assolutamente ovvia: ignorali. Penso che la stragrande maggioranza degli sviluppatori abbia dovuto affrontare questo problema a un certo punto, anche se l'incarnazione più comune del problema è che gli utenti business fanno richieste via email, al contrario di altri sviluppatori / manager.
È fondamentalmente la stessa situazione, però. Ignori le richieste di posta elettronica e, se premuto, spieghi gentilmente che la tua email arriva troppo velocemente e troppo spesso per essere in grado di tenere traccia di eventuali problemi o richieste sepolti lì, e che ne hai bisogno nel database dei bug per traccia il tuo tempo. Menzionalo al Project Manager, assumendo che tu ne abbia uno; sicuramente ti prenderà la tua parte.
Mi sono ritrovato anch'io alla fine degli affari di questo quando ho a che fare con gli amministratori di sistema; a volte c'è una linea sfocata tra la semplice richiesta di una messaggistica istantanea e la richiesta di un'indagine su qualche problema, e mi verrà detto di inviare un biglietto tramite e-mail all'indirizzo di tracciamento. È un inconveniente minore, ma non è un grosso problema, capisco quanto il loro tempo sia altamente compresso e sotto controllo intenso, e non possono permettersi di fare cose casuali per persone a caso senza una priorità assegnata.
Nella maggior parte dei casi, se esiste un buon motivo per l'esistenza di un processo, dovrebbe essere semplice per te registrare un reclamo formale o semplicemente seguire da solo il processo corretto e lasciare che gli altri si occupino con le conseguenze di non seguirlo .
Ma, come ho detto prima, assicurati che ciò di cui ti lamenti sia il processo specifico che non viene seguito , non pronunciarlo come un reclamo generale sulla persona altrimenti quasi certamente ne uscirai come un cattivo ragazzo.