Il mio collega è un bravo ragazzo, ma la sua performance è scadente. Lo dico al mio capo? [chiuso]

Circa tre mesi fa sono stato inserito in un progetto che fino a quel momento era in fase di sviluppo da un singolo sviluppatore appena assunto perché era in ritardo. Per essere onesti, il progetto è un'interfaccia per un dispositivo medico che ha molte sottigliezze ed è relativamente complesso, quindi posizionare una persona sul progetto che non ha avuto esperienza in azienda è stata probabilmente una cattiva decisione dal punto di vista manageriale.

Ad ogni modo, una volta che ho iniziato a lavorarci mi sono reso conto che ... beh, non ha funzionato affatto. L'interfaccia utente sembrava carina, ma in realtà non ha fatto molto, e ciò che ha fatto è stato fare in modo errato. Ancora una volta, per essere onesti, gran parte di questo era dovuto al fatto che questo sviluppatore non era adeguatamente preparato a scrivere un'interfaccia sul nostro dispositivo. Tuttavia, ho anche capito rapidamente che il codice che era in atto era fragile ed estremamente difficile da mantenere.

Ora non pretendo di essere il miglior programmatore al mondo. Lavoro con un sacco di persone molto intelligenti che sono sviluppatori migliori di me. Tuttavia mi sforzo molto di scrivere un codice il più semplice possibile e robusto. Metto alla prova i miei check-in. Se vedo che il mio codice sta diventando disordinato e difficile da lavorare all'inizio, lo cambio. Ho avuto alcuni colloqui con il mio collega nel tentativo di aiutarlo a scrivere codice migliore. Questo è un po 'complicato perché a) ha più di 20 anni di esperienza nel settore e io ne ho solo 5 eb) è stato assunto come un cosiddetto "esperto di UX" e altri lo vedono come un individuo esperto.

Detto questo, proprio non lo vedo. È un ragazzo molto simpatico ed è ragionevole, ma ogni volta controlla un codice fragile, funziona solo nel caso più ottimista e 9 volte su 10 finisco per correggere bug nel suo lavoro. Il suo codice sembra solo amatoriale e ovviamente non ha il livello di esperienza che ha affermato di avere quando è stato assunto. È arrivato al punto in cui le ore extra che trascorro a modificare il suo codice e a correggere i suoi bug mi hanno messo a dura prova. Per come la vedo io ho due opzioni:

1. Non fare nulla, rompi il sedere per assicurarmi che questo prodotto si spenga in tempo e sia robusto e aspetto che fallisca in futuro (non lavorerò con lui su questo progetto dopo il rilascio iniziale).
2. Racconta al mio capo della sua esibizione. Il mio capo è un uomo ragionevole, ma mi sento solo imbarazzato ad adottare questo approccio. Non mi piace "colpire" (per mancanza di un termine migliore) i miei colleghi e non so come lo prenderà.

Quindi, questo è tutto. Ho provato a risolvere questo problema con il mio collega spiegando perché la sua implementazione non funzionerà o in che modo il suo codice potrebbe essere reso più gestibile, ma continua a fare gli stessi errori. Sono molto interessato a sapere come gli altri hanno gestito situazioni simili, in particolare le persone nel management attualmente. Grazie in anticipo per qualsiasi consiglio che puoi offrirmi.

Almeno prenderei in considerazione la possibilità che se fosse stato assunto come un ragazzo della UX, potrebbe anche essere che nessuno si aspetti davvero un ottimo codice da lui - potrebbero aspettarsi che il suo codice dovrebbe essere fondamentalmente solo un prototipo che delinea la UX, e spetta ad altri programmatori scrivere codice di produzione basato su quello.

Ora, non sto certamente dicendo che sia così, ma non mi sembrerebbe terribilmente sorprendente. Almeno nella mia esperienza, non è affatto raro per le persone UX produrre principalmente cose come prototipi e storyboard. Semmai, se il ragazzo è stato davvero assunto specificamente come specialista di UX, sono sconvolto dalla nozione del suo codice di check-in. Sono abbastanza sicuro di non averlo mai visto.

Se il ragazzo è davvero uno specialista di UX, la cura potrebbe non essere quella di cercare di fargli produrre codice migliore, ma di farlo uscire completamente dalla codifica (almeno tutto tranne i prototipi). Se è onestamente bravo nella progettazione di UX, probabilmente il vero errore è persino chiedergli di scrivere del codice di produzione. Invece, dovrebbe probabilmente (al massimo) lavorare in un sandbox di prototipazione UX in cui il suo risultato è usato per guidare il prossimo round di codice reale che viene prodotto, ma non è mai stato registrato come codice di produzione.

Cerco di avere una regola che tenga sempre informato il mio capo delle cose che influenzano il progetto. Positivamente e negativamente ... e in casi come questo provo a dare la colpa a cose come il codice al contrario della persona che lo ha scritto. Sembra molto meno che tu stia colpendo un collega e più come se stessi cercando di migliorare la qualità del prodotto.

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

1. Tieni sotto controllo le loro debolezze
2. Gioca ai loro punti di forza
3. Sbarazzati di loro (non proprio la tua scelta)

Prendi il controllo delle loro debolezze cercando un aiuto esterno.

Ehi capo, sono un po 'preoccupato per lo stato del codice ... è piuttosto fragile e si rompe molto. Ci vorrà del lavoro per portarlo in uno stato in cui sento che ci si può fidare. Esiste la possibilità che potrei prendere in prestito uno degli architetti per un giorno o due per vedere se riusciamo a trovare un buon design?

Non stai chiedendo a un'altra persona di unirti al progetto, stai chiedendo più "input di esperti" per un breve periodo di tempo. Produci qualsiasi documento di cui abbiano bisogno, diagrammi UML e frammenti di codice se è quello che vuole l'architetto. Vedranno in quale stato si trova il codice e poi il tuo capo avrà qualcun altro che fa eco alle tue opinioni.

Spero che dall'incontro otterrai un design migliore che tu e gli altri sviluppatori potete seguire senza che lui rovini molto. Questo è ciò che progetta e le specifiche in molti casi: ridurre il danno che i cattivi sviluppatori possono fare.

Gioca ai loro punti di forza

Ehi capo, sto lavorando con il codice per il progetto x, ed è stupendo. Il codice, d'altra parte, potrebbe usare un bel po 'di lavoro. Penso che il progetto sarebbe migliore se [ux guy] fosse in grado di concentrarsi maggiormente sulla UX, mentre faccio un po 'di refactoring per portarlo in uno stato più stabile. Una volta che la UX è solida, il progetto b potrebbe probabilmente usare il suo tocco Midas.

Qui, il tuo capo probabilmente vedrà attraverso di esso; che gli stai dicendo che l'altro dev non è molto bravo ... ma almeno non sei uno stronzo a riguardo. E se è davvero bravo nel lavoro di UX, allora potrebbe trovare una posizione stabile saltando su ogni progetto e rendendolo fantastico dal punto di vista dell'usabilità. Immagino che gli sarebbe piaciuto anche così.

Smetti di correggere ripetutamente i suoi errori. Non imparerà; So che non lo farei.

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

Mostragli cosa ha fatto di sbagliato e magari risolverlo la prima volta. Per ogni ulteriore occorrenza dello stesso incidente, chiedigli di implementare la correzione che gli hai mostrato.

Starei davvero attento per alcuni motivi:

1. Come sei sicuro di non lavorare con lui dopo il rilascio iniziale? Il tuo management potrebbe pensare: "Che squadra, guarda come hanno portato insieme questa meraviglia!" e voglio tenerti insieme.

2. Se vai dal tuo capo, quanto tecnico vuoi provare a spiegare la tua posizione? Quanta documentazione avete delle scarse prestazioni dei vostri collaboratori?

Quelli sarebbero i trucchi che noterei da quello che mi hai chiesto. Ti suggerirei di chiedergli del codice e vedere se ha qualche giustificazione per il motivo per cui è così. Forse sta correndo in cerchio mentre lo codifica, il che causa alcuni problemi. Il cerchio è il punto in cui codifichi qualcosa, quindi una serie di modifiche finisce quasi nello stesso identico punto in cui hai iniziato quando l'elenco delle modifiche di qualcuno si annulla alla fine. Sono stato in quelle situazioni in cui sta cambiando e annullando il cambiamento dopo il cambiamento che si stanca abbastanza rapidamente.

Quali sono le conseguenze se non rifai tutto il suo lavoro e lasci che il progetto fallisca? Le conseguenze per te intendo.

Sicuramente qualcuno del suo livello di esperienza e posizione non è arrivato lì per caso, quindi o il suo lavoro non è così male come lo percepisci o la sua intera carriera è composta da persone come te che lo portano dietro.

Se stai lavorando più di 50 ore alla settimana a qualsiasi progetto, allora il loro è qualcosa di gravemente sbagliato e ti scoraggi non richiamandolo all'attenzione del Primo Ministro o lasciandolo. Sono un forte sostenitore del lavoro più intelligente, non più duro.

Lavora in modo intelligente 50 e se il progetto non funziona allora NON È IL TUO GUASTO. Se fallisce a causa della sua incompetenza e ti danno la colpa, allora probabilmente non è l'ambiente per cui vorresti lavorare.

Così tanti miei amici lavorano BENE per la tipica 40 / settimana su un progetto mal gestito perché hanno paura del fallimento quando non si rendono conto di quanto poco il fallimento O il successo influisca direttamente su tutta la tua carriera.

Oltre l'80% dei progetti fallisce, non c'è da vergognarsi.

Si chiama recensione tra pari. Il tuo manager si aspetta da te e deve essere informato su dove viene speso il suo prezioso tempo di sviluppo. Sono sorpreso che non lo sappia già, ma di nuovo ho visto di peggio.

Non parlargli in termini dell'altro ragazzo, parlagli in termini di lavoro quotidiano che fai. Se ciò significa dissotterrare il suo codice, così sia. Vai armato di link per il check-in, ecc. Per dare una sorta di prova del tuo lavoro quotidiano. Il tuo manager potrebbe volere esattamente questo da te tra l'altro - porta in UX i 20 anni e ottieni il codice robusto. Invece di creare wireframe, scrive semplicemente il codice di livello del prototipo. Parla con il tuo manager.

E spero che tu non sia stato assunto come sua baby sitter. In bocca al lupo.

Il progetto verrà avviato prima se non fosse necessario riscrivere / ripetere il suo lavoro? Aiuterà a rientrare nel budget? Non devi colpire, sollevare privatamente 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 che miglioreranno il risultato. Migliore documentazione? Test efficaci per l'utente? Il tuo obiettivo è quello di rendere l'azienda, il progetto, il tuo collega e te stesso di successo. Fingere che non ci siano problemi garantisce 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 bug? Il codice che dipende dalla vita o dalla salute delle persone deve essere il più robusto possibile umanamente, non una robaccia buggy scritta da un ottimista per lo scenario migliore.

Okay, indossando il mio cappello da ex manager ... non hai idea se il tuo capo lo sappia o quale sarà la sua risposta se per lui è una novità. Ma se non lo sa, deve farlo e non dovresti indovinarlo nascondendo queste informazioni. Se sta bene con il tuo collega che codifica in questo modo, ti farà sapere.

Mi sono imbattuto in una situazione come questa molti anni fa. Un "guru della rete" e io stavamo lavorando su una bozza di concetto come appaltatori. In effetti, quasi non riusciva a fare nulla, e per lo più scherzava. Un giorno, il nostro capo ci disse che avevamo una demo in arrivo. Presto il "guru della rete" iniziò a ricevere molte telefonate di silenzio, e alla fine mi disse che sarebbe partito prima della demo per prendere un altro concerto. Non appena riuscivo a trovare il nostro capo da solo, glielo dissi. Ha scaricato il "guru della rete" e ha portato qualcuno che ho raccomandato, che ha tirato fuori più codice in tre giorni rispetto al "guru" in tre mesi. La demo è stata un successo strepitoso, ma se avessi taciuto, il progetto sarebbe fallito completamente.

Sì, dillo al tuo capo. Quindi vedrai se non sei tu quello fuori posto. È compito del manager sapere come sta lavorando la squadra e se il capo non se ne è ancora accorto forse non gliene frega tanto quanto te per la corretta codifica - come in molti, molti posti in cui sono stato.

E tra tutti quei diversi posti di lavoro, se avessi una mano piena (che significa 5) di amici da tutti loro, è già un gran numero. Avevano tutti simpatici ragazzi e ragazze ma non perderai un'amicizia nel fare 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, motivo per cui tutti voi siete (o dovreste) essere presenti.

Dopo tutto, hai provato a parlargli e, se non fai nulla, rischi di rischiare il tuo lavoro lì.