Gli sviluppatori pensano di non dover seguire il processo di sviluppo standard [duplicato]

-1

Come gestisci uno sviluppatore senior che non pensa che il modo standard di sviluppo dell'azienda per applicarsi a loro sia applicabile?

Ad esempio:

  1. Chiede ad altri sviluppatori di lavorare via email, piuttosto che assegnare bug a loro.
  2. Conserverà copie della documentazione e del codice nella propria area locale, piuttosto che tenerli nell'area comune sotto il controllo del codice sorgente. (e sovrascrivi le altre modifiche con la loro)

NOTA: questo è stato contrassegnato per le persone con controllo di qualità prima.

    
posta NWS 05.09.2013 - 17:08
fonte

3 risposte

7

Documento le loro attività, fornisco loro più avvertimenti scritti, lavoro con le risorse umane per creare e attuare un piano di miglioramento, poi le licenzio.

modifica

Dato che non sei il manager, il meglio che puoi fare è documentare ciò che vedi (attenersi ai fatti) e inoltrare al tuo manager una volta ogni tanto. Se qualcuno dei tuoi pari ti lamenta di questa persona, incoraggiali a documentare anche & avanti al capo.

Avere una pila di eventi documentati da più peer è molto utile per il gestore quando è il momento di agire.

    
risposta data 05.09.2013 - 17:11
fonte
8

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.

    
risposta data 05.09.2013 - 17:37
fonte
5

Per incoraggiare l'uso di un sistema di tracciamento dei bug invece delle e-mail, puoi utilizzare la stessa tecnica che ho usato con i miei clienti. Crea una e-mail automatica che spiega come inviare un bug o richiedere una funzionalità su un sistema di tracciamento dei bug. Invia questa e-mail automatica ogni volta che ricevi una richiesta di bug / funzionalità per posta.

Pochi giorni dopo, la persona sarebbe così seccata che o ti affronterà (stai attento alle persone arrabbiate) o inizi a utilizzare il sistema di tracciamento dei bug.

Allo stesso modo, ignora i documenti che non sono memorizzati nel repository ufficiale. Se la persona ti chiede perché non hai seguito un documento specifico, chiedi quale e chiedi di non leggerlo mai, poiché non è nel repository.

    
risposta data 05.09.2013 - 17:38
fonte