Come faccio a gestire un collega lento e imprevedibile nella squadra? [chiuso]

Sei in una brutta situazione, non vorrei essere nei tuoi panni. È improbabile che tu possa risolvere il problema senza entrare in conflitto con il tuo collega.

Questo è quello che farei:

• Non diventare il suo partner in un crimine. Rifiuta di mentire sullo stato del tuo progetto o del suo progetto.

• Implementa (nel tuo tempo libero se necessario) bug segnalando alla tua applicazione, quindi tutti i bug vengono inviati via email ai tuoi collaboratori e al tuo manager. Se il bug è causato dalla sua applicazione, rendilo visibile nell'e-mail (metti [XYZ APP BUG] nell'oggetto email o qualcosa del genere).

• Gestisci un database di bug (oltre a inviare bug via email). Puoi dire che il suo scopo principale è quello di rintracciare i bug tuoi , quando in realtà troverai il monitoraggio dei suoi bug. Tra le altre cose, dovrebbe tenere traccia del tempo necessario per correggere bug specifici.

• Tutte le comunicazioni tra processi con la sua app sono coperte dai test ("quando ti ho inviato questo, dovresti restituirmi quello" stile "). Puoi impostare un'attività cron che esegue questi test ogni giorno e, in caso di esito negativo, l'email viene inviata a tutti.

In sostanza, cerca di non sprecare tempo a discutere con lui di bug e concentrarti invece sul tuo lavoro. Se la sua app è rotta e quindi non puoi lavorare sulla tua app e il manager non fa nulla con esso - beh, questo è un problema di gestione e sei coperto da database di bug, e-mail e rapporti di test.

Tuttavia, attenzione e non sottovalutarlo. Slacker da lungo tempo come lui potrebbero avere un asso nella manica. Può trasformare tutta la squadra contro di te o qualcosa del genere, ma questo dipende dalla tua situazione specifica ed è piuttosto fuori portata da questa domanda.

Troverò un punto di vista leggermente controverso: tu dici che stai lavorando tutte le ore in cui puoi stare sveglio. Quindi forse non è particolarmente ingiusto dire "mi stai facendo sembrare cattivo e in realtà sto lavorando tutte le ore che sono disposto a fare". Forse è stato lì e l'ha fatto e forse è bruciato. Ti prometto che lo farai se continui così.

Esci per un drink con lui una notte e vedi se non puoi costruire un rapporto personale migliore su cui basare il tuo professionista. Forse accettando di mettere un po 'di più e acconsentendo a mettere un po' meno, puoi lavorare insieme molto meglio.

Se fossi in te, sarei anche molto attento a tutto questo atteggiamento "il mio lavoro, il tuo lavoro". Tra voi due, avete un prodotto per uscire da lì e questo non può essere buono per quel prodotto, che a sua volta non va bene né per l'azienda né per il cliente e pagano entrambi per lavorare .

Tuttavia, sono ancora d'accordo con le altre opinioni sulla necessità di rivedere l'importanza della relazione con il tuo manager e devi stare attento a fidarti del tuo collega. Sto solo dicendo che forse, solo forse, hai bisogno di guardare le tue azioni e quelle di lui.

Mantieni i record. Documenta ogni errore che ricevi quando comunichi con lui, quando gli chiedi di aggiustarlo e quando (se mai) lo fa. Questo è l'unico modo che conosco per affrontare questa situazione. Quindi quando il tuo manager ti chiede perché le cose non stanno procedendo puoi chiaramente mostrare senza essere visto come un piagnucolone o un cattivo collega.

Vorrei segnalare un'altra possibilità che non è stata sollevata. Dici che vuole che tu rallenti il tuo lavoro. Intendi dire letteralmente "lavora meno ore" o che sta dicendo "scrivi alcuni test, prova di più, scrivi della documentazione" e altre cose che pensi ti rallenteranno? Ho visto nuove persone correre in giro a scrivere codice per 16 ore al giorno e poi lamentarsi di bug nel codice che stanno chiamando quando in realtà stanno passando parametri non validi, non stanno controllando i valori di ritorno e così via. Non posso escludere che il tuo collega stia pensando queste cose.

La prossima volta che sei in una riunione e lui dice che tutto il suo codice va bene, dì "oh, bene, la cosa che ti ho detto circa un'ora fa, dove esplode quando chiamo XYZ con una data che non è un giorno lavorativo, è fissato ora? " Una delle tre cose succederà:

• mentirà, e dirà che non c'è un problema del genere, dirai "c'è così! Ne abbiamo discusso! ti ho mandato!" e l'intera cosa verrà all'attenzione di un manager
• Ti dirà che, in realtà, non è un bug nel suo codice, è un bug nel tuo codice, perché dovresti passare solo giorni lavorativi, e presto scoprirai cosa sta pensando, ma non dicendo
• Dirà "no, quello di cui mi hai appena parlato mi occuperò di oggi, ma tutto il resto è buono." Se lo dice, grazie per ora.

Potresti scoprire che i tuoi lunghi giorni di codifica veloce non stanno producendo un buon codice, e qualcuno (forse il tuo manager) potrebbe tradurre l'altro sviluppatore per spiegarti qual è il problema. Oppure, potresti imparare che stai lavorando con un serpente bugiardo che ti farà sembrare cattivo per proteggere la sua posizione comoda. Portare le cose allo scoperto non può davvero peggiorare le cose. Oppure potresti ottenere abbastanza movimento da lui che puoi sopportarlo, senza essere coinvolto nella politica.

Quello che hai è un problema politico. Per prima cosa l'opinione del tuo manager è molto, molto più importante di quanto sembri pensare. Questo tizio ti incolpa per i ritardi e tu lo stai lasciando. Tu sei quello che verrà licenziato se qualcuno viene gettato sotto l'autobus. Per quanto ne sa il manager, tu sei quello che è incapace di fare il lavoro in modo tempestivo.

Proteggiti in ogni modo possibile, tramite bug tracking, email, ecc., ma NON andare avanti fingendo che questo sia il tuo ritardo, non il suo. Non dare mai al capo un falso rapporto di stato, tornerà a morderti. Dì al capo la verità sui problemi che hai (e mostra la prova) con il suo codice che non funziona.

Questa persona che ti sta chiedendo di perdere tempo in modo che non sembri male è un serpente (beh, questo è un insulto alla comunità dei serpenti (sottile riferimento alla Firefly), mi dispiace per tutti i serpenti attuali là fuori). Farà qualsiasi cosa per gettarti sotto l'autobus al posto suo. Non fidarti di lui.

Prima di tutto:

Since he is my colleague, I couldn't tell anything to the manager.

Assolutamente puoi e dovresti assicurarti che il tuo manager sappia la verità, anche se il tuo collega gli sta mentendo in faccia. Se non vuoi dire nulla in un incontro con tutti e 3 nella stanza, è del tutto comprensibile. Ma dovresti almeno mettere da parte il tuo manager (quello vero, non solo il temp) e fargli sapere che il tuo lavoro è quasi finito e attende correzioni di bug dagli altri sviluppatori prima che l'intera applicazione sia pronta per il prime time . Non accusare il tuo collega di mentire, ma non stare lì e lasciare che il tuo capo funzioni con informazioni incomplete.

Segnala i tuoi stati onestamente. Se il tuo lavoro è bloccato da bug di un altro sviluppatore, documenta che hai trovato bug nel C / C ++ e li hai segnalati (per favore dimmi che stai usando una qualche forma di documentazione che lascia una scia di carta).

Nel frattempo, vai avanti e concludi il tuo lavoro e fai sapere al tuo capo quando hai finito. Se il tuo manager vuole sapere perché il resto del progetto non è ancora attivo e funzionante, puoi riferirlo a un altro sviluppatore, e forse dire che è probabilmente molto complicato / di grandi dimensioni / richiede un sacco di test / altro sviluppatore è molto occupato / etc. Se conosci C / C ++, puoi offrire aiuto sulla logica dell'applicazione principale per far sì che anche le cose si muovano con quello. Sì, farai il lavoro dell'altro ragazzo, ma è chiaro che sei un dipendente che lavora duramente ed è produttivo, e l'altro non lo è, per non parlare del fatto che ti rende ancora più prezioso per il tuo capo. Potrebbe anche mettere un po 'di pressione sull'altro sviluppatore per fare un passo in avanti e farli fare più velocemente.

Ci sono una serie di problemi al lavoro. Tieni presente che:

1. Stai facendo delle supposizioni sulle motivazioni di altre persone
2. Stai colorando fatti con opinioni.
3. Gli estranei (chiunque altro) non sono a conoscenza della storia e non sono consapevoli delle tue frustrazioni con il tuo collega.
4. Potresti sembrare puerile se sembra che tu stia giocando a un gioco "gotcha". Probabilmente il tuo collega può suonarlo meglio - dopotutto ha ancora un lavoro vero?

Pertanto, quando si presenta lo stato del progetto:

1. Non parlare dell'altra persona.
2. Quando si segnalano errori o problemi con il codice, non lo sviluppatore. Dì "La chiamata al metodo FooBar () restituisce 1 quando dovrebbe restituire un 2". Quindi qualsiasi problema non è un attacco personale, stai solo parlando di codice, non di persone.
3. attenersi ai fatti per i quali hai una prova.
4. Se il tuo collega si fa difensivo o ostile, fai domande. "Non capisco perché pensi che dovrei fare _ "
5. Essere ignaro di offese sociali o insinuazioni. Fai finta di non avere l'attacco personale.
6. Dormi molto la notte prima di qualsiasi riunione di stato, quindi sei mentalmente agile.
7. Documento, documento, documento.
8. Non essere timido nel chiedere a questo tizio di aiutarti con qualche problema interessante, potrebbe portarti da te se sente che lo rispetti. Si tratta di costruire un rapporto. (nota che è non che fa schifo - questo è qualcos'altro)
9. Siate pronti a partire, se necessario, in modo da non essere bisognosi o intrappolati emotivamente. Questo ti aiuterà a tenere la testa in riunione.

"I am a person who loves to work. I spends most of the time in office and only go home when I feel sleepy."

Questo non è salutare e non ci si può aspettare dai colleghi, a meno che non si sia risarciti al punto di poter prendere anni per l'inevitabile esaurimento. (Qualcosa come > 10% di proprietà in azienda o oltre $ 200k all'anno). Mantenere le competenze per arrivare al punto in cui si può sviluppare molto rapidamente richiede tempo. Un po 'del tuo tempo dovrebbe essere dedicato allo sviluppo di competenze.

"The c/c++ project is the main app which does all the functionality. My python sends the user request to it and displays the response from it to the user. ... May be he doesn't like to do it."

Python è un linguaggio più agile di C / C ++. La sua app sembra contenere tutte le funzionalità; la tua app è solo l'interfaccia utente. Più probabile che no, questi non sono uguali in difficoltà. Potrebbe non produrre codice velocemente; ma la codifica della qualità è molto meglio della codifica della quantità. È molto probabile che tu abbia aspettative irrealistiche per quanto velocemente possa codificare nelle ore in cui è disposto / previsto a funzionare (in genere circa 40 ore settimanali e ricorda se è lì da anni, probabilmente ha accumulato altri compiti come gestire gli altri o aiutare a mantenere vecchi progetti che occupano una parte significativa della settimana lavorativa).

Non mentire per lui; ma di nuovo non lo criticare neanche. Parla di come il suo sistema è grande; concesso che ha bisogno di più lavoro fino al suo completamento. Offri al tuo manager un accurato aggiornamento di stato senza nominare i nomi / assegnare la colpa. Scrivi una versione mocked-up del suo sistema che sia conforme allo stesso standard a cui il suo sistema dovrebbe conformarsi. Assicurati che il tuo sistema funzioni perfettamente con il tuo sistema di simulazione con una suite di test automatizzata. Quindi il tuo sistema può essere completato (ad es. Si sincronizza perfettamente con il modello), anche se il sistema live è ancora buggato.

Quindi puoi scrivere una suite di test automatica per il suo sistema chiamato esternamente conforme agli standard concordati. Ad esempio, test di Foo (1,2,3) restituisce una risposta di "Bar 4 5 6". Questo potrebbe aiutarlo a identificare bug e velocizzare il suo sviluppo (e non ha bisogno di fare casino con il suo codice). Una volta terminate queste operazioni, sarai in grado di passare a un altro progetto / attività (ad esempio aiutandolo con le parti C / C ++).

Come altri hanno già detto, il comportamento professionale è la cosa più importante per la tua carriera a lungo termine. E onestamente, finché ti comporti professionalmente, sarai in ottima forma, indipendentemente da come si comportano le persone intorno a te.

In questa situazione, ci sono un paio di considerazioni da tenere in considerazione.

Per prima cosa, devi capire che sei responsabile per il tuo programma che lavora alle specifiche desiderate, entro la scadenza indicata. Se il tuo programma interagisce con il programma di qualcun altro, sei anche responsabile di assicurarti che anche quell'altro programma funzioni alla stessa scadenza. Per dirla in modo diverso: se l'altra persona salta la sua scadenza, anche tu hai perso la tua scadenza, anche se la tua parte del progetto era in orario. In termini di gestione, questo è chiamato proprietario degli input .

Hai correttamente notato che quando il tuo collega dichiara in una riunione che i bug del suo programma sono corretti, non puoi immediatamente dichiararlo come errato al manager (il tuo manager lo vedrebbe come "buttare il tuo collega sotto il autobus ", una brutta mossa di carriera). Altri, d'altra parte, hanno sottolineato che è non non professionale dichiarare il vero stato del progetto al manager. Entrambi i lati sono completamente corretti.

Quindi, se è male contraddire il tuo collega di fronte al manager, ed è anche un male per non contraddirlo, allora cosa fai?

La risposta è in realtà piuttosto semplice: devi parlare con il tuo collega molto prima dell'incontro con il manager e far sapere loro che alla riunione imminente dovrai dire al manager i problemi che hai avendo avuto con il loro programma, e che sta influenzando la tua capacità di consegnare la tua parte del progetto in tempo, e se c'è qualcosa che puoi fare per aiutarli a risolvere i problemi che hai avuto. Devi avere questa conversazione almeno due giorni interi prima della riunione, dove dirai al direttore, e preferibilmente una settimana intera in anticipo.

Nella maggior parte dei casi, solo dicendo al tuo collega che devi elencare il loro programma come un rischio in una determinata riunione, li convincerai a risolvere i problemi che stai affrontando e non dovrai mai parlare con il manager a tutti. In altri, dove i problemi sono più dettati dalla pianificazione, il collega sarà spesso d'accordo con te, e voi due potete andare insieme al manager.

Non ho mai avuto un collega che non abbia sistemato le cose per me rapidamente o che non sia d'accordo con le mie preoccupazioni, se espresso in questo modo. Ma se succedesse, avvisando il collega in anticipo, saresti ancora in una posizione migliore quando parlerai con il manager. Dal momento che hai parlato con il tuo collega e hai cercato di elaborare una soluzione da solo, e li hai avvertiti con largo anticipo che avresti bisogno di sollevare il problema in questo incontro, il tuo collega non si sorprenderà quando lo farà, e il manager ha vinto Pensa che stai semplicemente cercando di spostare la colpa.

Per favore ricorda che quando esprimi le tue preoccupazioni, sia al collega che al manager, che le tue preoccupazioni riguardano il programma del tuo collega che sta restituendo dati cattivi (o qualsiasi altra cosa stia facendo); queste sono cose misurabili che possono essere verificate e corrette. I tuoi dubbi sono non sul fatto che il tuo collega sia lento o imprevedibile; queste non sono cose misurabili, che possono o non possono essere vere, e che è improbabile che vengano corrette portandole in un incontro davanti al capo.

Quale sistema di tracciamento dei bug stai usando? Mi sarei aspettato che almeno per evidenziare dove i bug non vengono risolti a tempo debito. Laddove il tuo codice è in attesa su input dell'altro livello, i ritardi devono essere evidenziati nella documentazione di monitoraggio del progetto. Neanche questo sta succedendo?

Mi sembra che non ci sia una gestione dei progetti inadeguata qui. Devi a) tracciare i bug che ti riguardano e b) seguire le discussioni per iscritto.

Il tuo collega non dovrebbe chiederti di gonfiare il tuo tempo di sviluppo per coprire la sua mancanza di volontà. Ad un certo punto, questo è qualcosa che dovrà essere affrontato con il tuo manager. Allo stato attuale, stai coprendo il tuo collega e questo quasi certamente si ritorcerà contro.

Non c'è niente di sbagliato nel mettersi in fila per un collega, ma qualcuno deve aspettarsi che tu menti al tuo capo ogni giorno. Non potevo rispettarlo come persona e non avrei alcun desiderio di avere questa persona come conoscenza occasionale. Vuole essere un nemico, portarlo su.

Come puoi argomentare i ritardi sul livello dell'applicazione a causa del front-end? Ecco perché lo fai in modo che possano essere separati. Qual è il prossimo, ha ancora più ritardi perché qualcuno vuole costruire un front-end mobile?

Completa il tuo lavoro. Documenta eventuali problemi riscontrati con un errore nella sua app. E poi GO HOME! non mi interessa se hai sonno o no. Trova degli amici che vale la pena avere.

Ho appena letto "The Clean Coder" di R.C. Martin (zio Bob). Il punto principale del libro è che i programmatori in generale non ottengono molto rispetto perché non si comportano in modo professionale . Ciò significa principalmente che non comunicano efficacemente con la direzione lo stato del progetto.

Mentire è sicuramente una forma di comunicazione molto pessima. Il tuo collega è estremamente poco professionale e anche tu. Entrambi non stanno facendo nulla di buono per migliorare la percezione dei programmatori.

Ti consiglierei di andare subito alla direzione. Tuttavia, in passato mi sono messo nei guai per essere stato troppo "onesto" (in una situazione non correlata), quindi non sono sicuro che dovresti seguire il mio consiglio. Inoltre, come molti hanno sottolineato, forse la tua percezione della situazione non è accurata come pensi.

È difficile e irragionevole stimare lo sforzo relativo e la complessità di un altro progetto se non si ha familiarità con la base di codice. Dici che il suo codice è soggetto a errori, ma potrebbe essere in ottima forma con tutti i problemi rimanenti a un livello molto alto di astrazione ... Il problema è, questo è il codice solo che il tuo fronte fine ha bisogno!

O forse è un brutto dipendente e sta facendo un giro in compagnia. Non posso dire, e potresti anche non avere tutte le informazioni che devi sapere con sicurezza.

Suggerirei una tattica a metà strada. La prossima volta che vi incontrate, portate alcuni dettagli di un grosso bug nel suo codice che sta interessando voi. Quando dice che tutto va bene, dire educatamente che è un problema in sospeso che blocca i tuoi progressi.

Politicamente, dicendolo così diciamo che non è del tutto corretto, pur continuando a dargli un'apertura per giocare in modo stupido e non essere messo sulla difensiva.

Il tuo manager dovrebbe chiedere alla prossima riunione se è stato corretto. In caso contrario, la pressione cade su di lui per risolvere un bug. Se è risolvibile, ad esempio grazie, funziona alla grande ora e hai trovato un nuovo blocco. Se vuoi essere particolarmente gentile, di 'che ti sei imbattuto poco prima dell'incontro.

Non stai mentendo, di per sé, né stai prendendo posizione. Stai facendo politica richiamando l'attenzione sui problemi e lasciando che il tuo collega risparmi faccia se le cose non stanno davvero andando bene.

È allettante parlare solo con il tuo manager, ma non dimenticare quale di questi è il caso in cui devi lavorare di più.

La risposta di Pat è stata grandiosa. Sono d'accordo al 100%. Non entrare di nascosto in un incontro con il capo. O prendilo con il tuo collega tra 4 occhi o fallo con tutti e 3. Ma il suggerimento di Pat di concentrarsi sui problemi del codice e non sulle persone è la strada giusta da percorrere.

Btw, 40h / week è abbastanza bravo. Devi mantenere alta la tua motivazione!

Chiedi qualcun altro per aiutarti sia nei test di integrazione. La persona deve essere in grado di dire dove si verifica il problema. Come ha sottolineato Temptar, mi chiedo perché non ci sia nemmeno un excel per tenere traccia dei problemi! dal momento che non c'è traccia, è come ogni volta che l'altro ragazzo sta scappando dicendo che adesso va tutto bene! non funziona in questo modo!

È il tuo modulo se hai bisogno di farlo è necessario alzare la bandiera rossa su cosa causa il ritardo dal tuo lato. L'esperienza in MERE Years non ha nulla a che fare, è solo la conoscenza e questo è ciò su cui il tuo manager dovrebbe insistere. Come detto anche io sento che c'è una cattiva gestione del progetto che sta accadendo qui.

1. Mostrare l'iniziativa richiedendo attività aggiuntive e chiedendo come è possibile aggiungere valore all'organizzazione è il modo migliore per guadagnare fiducia.

Il tuo manager potrebbe non essere abbastanza tecnico da capire chi sta rallentando il progetto, ma probabilmente sono abbastanza intelligenti da riconoscere che uno sviluppatore che sta cercando attivamente nuovi incarichi sta attraversando il loro attuale compito. Ciò porterà a una conversazione in cui è possibile chiarire che si stanno aspettando correzioni di bug da parte degli altri sul proprio compito attuale. Inquadra la discussione in termini di come puoi aggiungere ulteriore valore all'organizzazione utilizzando in modo efficiente il tuo tempo libero, non come il tuo collega è troppo lento con le sue correzioni di bug.