Il mio collega è un bravo ragazzo, ma la sua prestazione è sub-par. Lo dico al mio capo? [chiuso]

Cerco di avere una regola che tenga sempre informato il mio capo sulle cose che influenzano il progetto. Positivamente e negativamente ... e in casi come questo cerco di dare la colpa a cose come il codice in contrasto con la persona che lo ha scritto. Sembra molto meno che stai picchiando un collega e più come se stessimo cercando di migliorare la qualità del prodotto.

Da un punto di vista gestionale ci sono 3 modi comuni per trattare con i dipendenti in questa situazione:

1. Prendi sotto controllo le loro debolezze
2. Gioca ai loro punti di forza
3. Sbarazzati di loro (non è una tua scelta)

Mantieni sotto controllo le loro debolezze cercando aiuto esterno.

Hey Boss, I'm a bit worried about the state of the code... it's pretty fragile and breaking a lot. It'll take some work to get it into a state where I feel that it can be trusted. Is there a possibility that I could borrow one of the architects for a day or two to see if we can come up with a good design?

Non stai chiedendo ad un'altra persona di aderire al progetto, stai chiedendo più di "input esperti" per un breve periodo di tempo. Produci qualunque documento di cui hanno bisogno, diagrammi UML e frammenti di codice, se questo è ciò che l'architetto vuole. Vedranno in quale stato si trova il codice e quindi il tuo capo avrà qualcun altro che fa eco alle tue opinioni.

Dalla riunione, si spera che si ottenga un design migliore che sia tu che l'altro dev potete seguire senza che lui ne faccia un sacco. Questo è ciò che design e specifiche per un sacco di casi: ridurre il danno che gli sviluppatori non autorizzati possono fare.

Gioca ai loro punti di forza

Hey Boss, I'm working with the code for project x, and it's gorgeous. The code, on the other hand, could use a fair bit of work. I think the project would be better off if [ux guy] was able to focus more on the UX, while I do some refactoring in order to get it into a more stable state. Once the UX is solid, project b could probably use his Midas touch.

Qui, probabilmente il tuo capo lo vedrà bene; che gli stai dicendo che l'altro dev non è molto buono ... ma almeno non lo stai facendo da stronzo. E se è onestamente molto bravo nel lavoro di UX, allora potrebbe trovare una posizione stabile che salta su ciascun progetto e che li rende grandi da un punto di vista dell'usabilità. Immagino che gli piacerebbe anche in questo modo.

Interrompe ripetutamente correggendo i suoi errori. Lui non imparerà; So che non lo farei.

La programmazione è in gran parte un compito logico, ma coinvolge anche il ricordo della memoria. Quando scrivi spesso codice comune, richiama come hai implementato la soluzione l'ultima volta , invece di capirlo di nuovo. Se non ha mai implementato il codice corretto, posso capire perché continua a ripetere gli stessi errori.

Dimostragli cosa ha fatto di sbagliato e forse aggiustalo per la prima volta. Per ogni ulteriore occorrenza dello stesso incidente, fagli applicare la correzione che gli hai mostrato.

Sarei molto attento per alcuni motivi:

1. Come sei sicuro che non lavorerai con lui dopo la versione iniziale? La tua dirigenza potrebbe pensare: "Che squadra, guarda come hanno fatto questa meraviglia insieme!" e voglio tenerti insieme.

2. Se vai dal tuo capo, in che modo vuoi entrare cercando di spiegare la tua posizione? Quanta documentazione hai dei tuoi collaboratori scarsa prestazione?

Quelli sarebbero i trucchi che noterei da ciò che hai chiesto. Suggerirei di chiedergli del codice e vedere se ha delle giustificazioni sul perché è così com'è. Forse sta girando in tondo mentre lo sta codificando, il che causa alcuni problemi. Il cerchio è il punto in cui si codifica qualcosa, quindi attraverso una serie di modifiche finiscono quasi nello stesso punto in cui si è iniziato quando alla fine si annulla l'elenco di modifiche di qualcuno. Sono stato in quelle situazioni in cui sta cambiando e annullando i cambiamenti dopo il cambiamento che si stanca molto velocemente.

Quali sono le conseguenze se non rifai tutto il suo lavoro e lasci semplicemente fallire il progetto? Le conseguenze a voi intendo.

Sicuramente qualcuno del suo livello di esperienza e posizione non è arrivato lì per caso, quindi il suo lavoro non è così grave come lo si percepisce o la sua intera carriera è composta da persone come te che lo portano con sé.

Se lavori su più di 50 ore alla settimana su un progetto, la loro è una cosa seriamente sbagliata e ti disservi non chiamandolo all'attenzione del PM o lasciandolo. Sono un strong sostenitore del fatto di lavorare SMARTER non HARDER.

Lavora a smart 50 e se il progetto non funziona, NON È IL TUO GUASTO. Se fallisce a causa della sua incompetenza e ti incolpano, allora probabilmente non è l'ambiente in cui vorresti lavorare comunque.

Così tanti miei amici lavorano BENE oltre i 40 / week tipici di un progetto mal gestito perché hanno paura di fallire quando non si rendono conto di quanto il fallimento o il successo influenzi direttamente tutta la tua carriera.

Oltre l'80% dei progetti fallisce, non c'è vergogna in questo.

Si chiama una revisione tra pari. Il tuo manager si aspetta qualcosa da te e deve sapere dove viene speso il tempo del suo prezioso sviluppatore. Sono sorpreso che non lo sappia già, ma di nuovo ho visto di peggio.

Non parlargli nei termini dell'altro ragazzo, parlagli in termini di lavoro quotidiano che fai. Se ciò significa dissing il suo codice, così sia. Andare armato con i collegamenti di controllo ecc. Per dare qualche tipo di prova del tuo lavoro quotidiano. Il tuo manager potrebbe volere esattamente questo da te - porta i 20 anni di UX e ottieni il codice robusto. Invece di fare wireframe, scrive solo il codice di livello prototipo. Parla con il tuo manager.

E spero che tu non sia stato assunto come sua baby sitter. Buona fortuna.

Il progetto verrà avviato prima se non dovessi riscrivere / rifare il suo lavoro? Aiuterà a rientrare nel budget? Non devi picchiare, sollevare in privato le tue preoccupazioni. Qui è dove la maggior parte delle persone commette un errore, si lamentano senza offrire soluzioni.

Ci sono raccomandazioni specifiche che puoi offrire al tuo capo per migliorare il risultato. Migliore documentazione? Test utente robusti? Il tuo obiettivo è quello di rendere l'azienda, il progetto, il tuo collega e te stesso di successo. Far finta che non ci siano problemi assicura il fallimento per tre dei quattro --- e tu non sei il fortunato.

Devi andare dal tuo capo al più presto e dirgli chiaramente cosa hai detto qui.

Prima di tutto, questo è un dispositivo medico. Qualcuno potrebbe essere ferito o morire se c'è un insetto? Codice secondo cui la vita o la salute delle persone dipendono dal bisogno di essere il più robusto possibile dal punto di vista umano, non un bug errato scritto da un ottimista per lo scenario migliore.

Okay, mettendo il mio cappello ex manager su ... non hai idea se il tuo capo lo sappia, o quale sarà la sua risposta se è una novità per lui. Ma se non lo sa, ha bisogno di farlo, e non dovresti farlo in secondo piano nascondendo questa informazione. Se sta bene con la codifica del tuo collega in questo modo, ti farà sapere.

Mi sono imbattuto in una situazione come questa molti anni fa. Un "guru del networking" e io stavamo lavorando a una proof-of-concept come contractor. In effetti, non riusciva quasi a fare nulla, e soprattutto a perdere tempo. Un giorno, il nostro capo ci ha detto che avevamo una demo in arrivo. Ben presto, il "guru del networking" ha iniziato a ricevere molte telefonate di silenzio, e alla fine mi ha detto che se ne sarebbe andato prima della demo per fare un altro concerto. Non appena ho potuto ottenere il nostro capo da solo, gli ho parlato di questo. Ha scaricato il "guru della rete" e ha portato in qualcuno che ho consigliato, che ha tirato fuori più codice in tre giorni che il "guru" ha fatto in tre mesi. La demo è stata un successo strepitoso, ma se fossi rimasto zitto, il progetto sarebbe completamente fallito.

Sì, dillo al tuo capo. Poi vedrai se non sei quello fuori posto lì. È compito del manager sapere come sta funzionando il team e se il capo non l'ha ancora notato forse non gli interessa quanto te per la corretta codifica - come molti, molti posti in cui sono stato.

E tra tutti quei diversi posti di lavoro, se ho avuto una mano piena (significato 5) di tutti gli amici che è già un gran numero. Avevano tutti bravi ragazzi e ragazze, ma non perderai un'amicizia per aver fatto il tuo lavoro - se li perdi è una buona cosa. Nel tuo caso, valuterebbe il lavoro più di te.

Certo, non è un tentativo di farlo licenziare. Sta solo mostrando la tua preoccupazione per il benessere del progetto, ed è per questo che tutti voi siete (o dovreste) essere lì.

Hai provato a parlargli, dopotutto, e se non fai niente, rischi davvero di finire lì.