Come posso gestire un collega lento e non dedicato nella squadra? [chiuso]

Ho lavorato su un nuovo progetto. Il progetto funziona in questo modo: l'utente finale può accedere a una webapp usando un collegamento e può aggiungere più sistemi sulla sua rete e gestire i dettagli di quel particolare sistema. La mia parte coinvolge il front-end e il server web, che è fatto in Python. Il mio pitone in realtà comunica con un altro progetto che è interamente realizzato in c & c ++. Il progetto c / c ++ è l'app principale che offre tutte le funzionalità. My Python invia la richiesta dell'utente e visualizza la risposta da esso all'utente.

Conosco molto bene il mio lavoro e lo finirò presto. Dal momento che non c'è molto lavoro in esso. E io sono una persona che ama lavorare. Trascorro la maggior parte del tempo in ufficio e vado a casa solo quando ho sonno.

L'app c / c ++ è gestita da un altro collega che ha più di 5 anni di esperienza e può fare le cose molto più velocemente di me, ma non lo fa mai. Forse non gli piace farlo. La sua app si blocca spesso quando il mio pitone comunica con essa o restituisce valori errati. È pieno di bug. Dal momento che la mia app dipende da essa, non riesco a costruirla. Invece di correggere i bug, mi chiede di rallentare il mio lavoro. Mi chiede di dire al manager che il mio lavoro ha bisogno di molto tempo. Mi sta chiedendo di ingannare il manager e persino di costringermi a lavorare lentamente come lui.

Durante la riunione del progetto, quando il manager gli chiede degli errori, dice che ha risolto tutto e funziona bene. Dato che è un mio collega, non ho potuto dire nulla al direttore. Ho ovviamente bisogno di avere un buon rapporto con i miei colleghi più che con il mio manager, dato che il più delle volte saremo con i nostri colleghi, non con il direttore.

Non sono in grado di dire nulla al manager in merito, dal momento che se il manager gli chiede perché, allora potrebbe pensare che mi sia lamentato con lui. E continua a mentire all'incontro. E poiché corregge lentamente il bug, rallenta anche il mio lavoro. Ora ho pensato di lavorare sulla parte front-end della mia app e finirla in modo che nel frattempo potesse rendere stabile il suo progetto. Ora mi sta chiedendo di dire al manager che la mia parte di front-end richiede molto lavoro e che potrei aver bisogno di sempre più tempo, semplicemente per poter trascinare il progetto verso il basso. E la cosa triste è che il nostro attuale manager è andato negli Stati Uniti, quindi abbiamo un manager temporaneo e questo ragazzo non conosce molto il progetto, quindi il c, c ++ lo prende in giro.

Qualcuno può suggerirmi come affrontare questo? Volevo finire presto il progetto. Come posso farlo funzionare anche mantenendo un buon rapporto con lui?

Risposte ai commenti:

Se sta davvero deliberatamente fuorviando la società, dovresti denunciarlo alla direzione.

Sono nuovo di questa compagnia e l'altro ragazzo è stato lì per molti anni. E ho appena iniziato a conoscere i miei colleghi. Se vado direttamente a lamentarmi di lui, non penso di poter fare buoni rapporti con gli altri miei colleghi. Anche lui ha il potere di fuorviarli. Non sto dicendo che è un cattivo ragazzo, può fare il lavoro, ma non lo sta facendo.

La tua azienda non ha alcun tipo di sistema di tracciamento dei bug?

Qui il vero sistema di tracciamento dei bug non c'è. La società cerca di completare il progetto il prima possibile e lo consegna al QA. E quindi corregge i bug segnalati dal QA.

Questo è il motivo per cui le aziende dovrebbero offrire ai dipendenti azioni / opzioni o una sorta di proprietà. In questo modo puoi letteralmente dire al ragazzo "Mi stai costando una crescita monetaria ... non vuoi fare soldi anche tu?".

La società ha le opzioni su azioni che mi hanno dato una quota di 2500, per lo più anche lui ne avrebbe avuto di più.

L'anzianità merita alcuni vantaggi di un dubbio. Devi prima parlare con lui e cercare di capire il problema. Potrebbe essere fuori dalla sua profondità, potresti essere in grado di aiutarlo, potrebbero esserci facilmente variabili di cui non sei a conoscenza. Ora può essere difficile, ma potresti facilmente peggiorare la situazione saltando la pistola.

Lo faccio persino, prima che la sua app non gestisse più richieste alla volta, stava usando una coda per gestire le richieste che gli avevo inviato. Gli ho anche suggerito alcune delle mie idee al riguardo. Ha detto che aveva già queste idee e le eseguirà. Le sue spiegazioni erano: "Tutto richiede un certo tempo per fare e questo è un progetto che potrebbe richiedere due anni per essere completato e ci viene chiesto di completarlo in due mesi". Ho avuto difficoltà a programmare durante le prime settimane a causa di questo errore. Ma ora l'ha risolto. Ma sta usando una singola coda per le richieste di un utente e ora sta rallentando l'app, poiché elabora una richiesta alla volta.

Cosa sta facendo il QA per tutto questo tempo? Perché non stanno segnalando / confermando lo stato dei progetti?

Il manager è la persona che decide quando dare al QA. A partire da ora non ha ancora dato al QA. Ha detto che dovremmo darlo entro la fine del mese.

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

Questo è quello che vorrei fare:

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

• Implementa (nel tempo libero, se necessario) la segnalazione di bug alla tua applicazione, in modo che tutti i bug vengano inviati via e-mail ai tuoi colleghi e al tuo manager. Se il bug è causato dalla sua applicazione, rendilo visibile nell'e-mail (inserisci [XYZ APP BUG] nell'oggetto dell'email o qualcosa del genere).

• Mantenere un database di bug (oltre a inviare bug via e-mail). Puoi dire che il suo scopo principale è monitorare i tuoi bug, mentre in realtà seguirai principalmente i suoi bug. Tra le altre cose, dovrebbe tenere traccia del tempo necessario per correggere un bug specifico.

• Avere tutte le comunicazioni tra processi con la sua app coperte di test ("quando ti ho inviato questo, dovresti restituirmi quello" stile). È possibile impostare un'attività cron che esegue questi test ogni giorno e se falliscono, l'email viene inviata a tutti.

Fondamentalmente, cerca di non perdere tempo a discutere con lui dei bug e concentrati invece sul tuo lavoro. Se la sua app è rotta e quindi non puoi lavorare sulla tua app e il gestore non fa nulla con essa, beh, questo è un problema di gestione e sei coperto di database di bug, e-mail e rapporti di prova.

Tuttavia, fai attenzione e non sottovalutarlo. Un fannullone di lunga data come lui potrebbe avere uno o due scherzi nella manica. Può trasformare l'intera squadra contro di te o qualcosa del genere, ma ciò dipende dalla tua situazione specifica ed è un po 'fuori dalla portata di questa domanda.

Ho una visione leggermente controversa: dici che stai lavorando quante ore puoi rimanere sveglio. Quindi forse non è particolarmente ingiusto nel dire "mi stai facendo apparire male 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 a bere qualcosa con lui una sera e vedi se non riesci a costruire una migliore relazione personale su cui basare il tuo professionista. Forse accettando di aggiungere un po 'di più e accettando di aggiungere un po' di meno, entrambi potrete lavorare insieme molto meglio.

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

Tuttavia, sono ancora d'accordo con gli altri punti di vista sul fatto che è necessario rivisitare l'importanza della relazione con il proprio manager e bisogna fare attenzione a fidarsi del proprio collega. Sto solo dicendo che forse, solo forse, devi guardare le tue azioni e le sue.

Tienine traccia. Documenta ogni errore che ricevi quando comunichi con lui, quando gli hai chiesto di risolvere e quando (se mai) lo ha fatto. Questo è l'unico modo che conosco per affrontare questa situazione. Quindi, quando il tuo manager viene da te chiedendoti perché le cose non stanno progredendo, puoi chiaramente mostrarlo senza essere visto come un piagnucolone o un cattivo collega.

Vorrei sottolineare un'altra possibilità che non è stata sollevata. Dici che vuole che tu rallenti il ​​tuo lavoro. Intendi letteralmente dire "lavora meno ore" o che sta dicendo "scrivi alcuni test, prova di più, scrivi un po 'di 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 dei bug nel codice che chiamano 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 a queste cose.

La prossima volta che sei in riunione e dice che tutto il suo codice va bene, dì "oh, bene, la cosa di cui ti ho parlato un'ora fa, dove esplode quando chiamo XYZ con una data che non è un giorno lavorativo, è riparato ora? " Accadrà una di tre cose:

• Mentirà e dirà che non esiste un problema del genere, dirai "è così! Ne abbiamo discusso! Ti ho mandato un'email!" e il tutto arriverà 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 scoprirai presto cosa sta pensando, ma non dicendo
• Dirà "no, quello di cui mi hai appena parlato di cui mi occuperò oggi, ma tutto il resto è buono". Se lo dice, basta ringraziarlo per ora.

Potresti scoprire che i tuoi lunghi giorni di programmazione veloce non producono un buon codice e che qualcuno (forse il tuo manager) potrebbe tradurre per 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 all'aperto non può davvero peggiorare la situazione. Oppure, potresti semplicemente ottenere abbastanza movimento da lui da poterlo sopportare, senza essere coinvolto nella politica.

Quello che hai è un problema politico. Innanzitutto l'opinione del tuo manager è molto, molto più importante di quanto sembri pensare. Questo ragazzo ti sta incolpando per i ritardi e te lo stai lasciando fare. Sei tu quello che verrà licenziato se qualcuno viene gettato sotto l'autobus. Per quanto ne sa il manager, sei colui che non è in grado di svolgere il lavoro in modo tempestivo.

Proteggiti in ogni modo possibile, tramite il tracciamento dei bug, le e-mail, ecc., Ma NON far finta che questo sia il tuo ritardo, non il suo. Non dare mai al capo un falso rapporto sullo stato, tornerà a morderti. Di '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 rilassarti in modo che non sembri male è un serpente (beh, questo è un insulto alla comunità dei serpenti (sottile riferimento a Firefly), mi dispiace per tutti i serpenti reali là fuori). Farà di tutto per buttarti sotto l'autobus invece di lui. Non fidarti di lui.

Innanzitutto:

Dato che è un mio collega, non ho potuto dire nulla al direttore.

Puoi assolutamente e dovresti assicurarti che il tuo manager conosca la verità, anche se il tuo collega gli sta mentendo in faccia. Se non vuoi dire nulla in una riunione con tutti e tre nella stanza, è assolutamente comprensibile. Ma dovresti almeno mettere da parte il tuo manager (quello vero, non solo la temp) e far loro sapere che il tuo lavoro è quasi finito e sta aspettando correzioni di bug dalla fine dell'altro sviluppatore prima che l'intera applicazione sia pronta per la prima serata . Non accusare il tuo collega di mentire, ma non sederti lì e lascia che il tuo capo operi con informazioni incomplete.

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

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 rimandarlo all'altro sviluppatore e forse menzionare che probabilmente è molto complicato / di grandi dimensioni / richiede molti test / altro sviluppatore è molto occupato / etc. Se conosci C / C ++, puoi offrire aiuto sulla logica principale dell'applicazione per far muovere anche le cose. Sì, farai il lavoro dell'altro ragazzo, ma chiarisce che sei l'impiegato che lavora duro ed è produttivo, e l'altro non lo è, per non parlare del fatto che ti rende ancora più prezioso per il tuo capo. Potrebbe persino esercitare una certa pressione sull'altro sviluppatore affinché intensifichi le cose e le realizzi più rapidamente.

Ci sono una serie di problemi al lavoro. Fai attenzione a:

1. Stai facendo ipotesi sulle motivazioni delle altre persone
2. Stai colorando i fatti con le 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 infantile se sembra che stai giocando a un gioco "gotcha". Il tuo collega probabilmente può giocare meglio - dopo tutto ha ancora un lavoro, no?

Pertanto, quando si presenta lo stato del progetto:

1. Non menzionare l'altra persona.
2. Quando si segnalano errori o problemi con il codice, non con lo sviluppatore. Dì "La chiamata al metodo FooBar () sta restituendo 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 cui si ha la prova.
4. Se il tuo collega diventa difensivo o ostile, fai delle domande. "Non capisco perché pensi che dovrei fare _ "
5. Sii ignaro di insulti o insinuazioni sociali. 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 ragazzo di aiutarti con qualche problema interessante, potrebbe prenderti se sente che lo rispetti. Si tratta di costruire un rapporto. (nota che non sta succhiando - questo è qualcos'altro)
9. Preparati a partire, se necessario, in questo modo non sei bisognoso o intrappolato emotivamente. Questo ti aiuterà a mantenere la testa nelle riunioni.

"Sono una persona che ama lavorare. Trascorro la maggior parte del tempo in ufficio e vado a casa solo quando ho sonno."

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

"Il progetto c / c ++ è l'app principale che offre tutte le funzionalità. Il mio python invia la richiesta dell'utente e mostra la risposta da esso all'utente. ... Può essere che non gli piaccia farlo."

Python è un linguaggio più agile di C / C ++. La sua app sembra contenere tutte le funzionalità; la tua app solo l'interfaccia utente. Più probabilmente che no, questi non sono uguali in difficoltà. Potrebbe non produrre codice rapidamente; ma la codifica di qualità è molto meglio della codifica di quantità. Potresti avere aspettative non realistiche sulla velocità con cui può programmare nelle ore in cui è disposto / previsto a lavorare (in genere ~ 40 ore settimanali; e ricorda che se è stato lì per anni, probabilmente ha accumulato altri compiti come gestire gli altri o aiutare a mantenere gli anziani progetti che occupano una parte significativa della settimana lavorativa).

Non mentire per lui; ma di nuovo non criticare neanche lui. Parla di come il suo sistema sia eccezionale; garantito che ha bisogno di più lavoro fino alla fine. Dai al tuo manager un accurato aggiornamento dello stato senza nominare i nomi / assegnare la colpa. Scrivi una versione simulata del suo sistema conforme allo stesso standard a cui il suo sistema dovrebbe conformarsi. Assicurati che il tuo sistema funzioni perfettamente con il tuo sistema simulato con una suite di test automatizzata. Quindi il tuo sistema può essere finito (ad esempio, si sincronizza perfettamente con il modello), anche se il sistema live è ancora difettoso.

Quindi è possibile scrivere una suite di test automatici 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 i bug e la velocità lungo il suo sviluppo (e non ha bisogno di pasticciare con il suo codice). Una volta fatte queste cose, sarai in grado di passare a un altro progetto / attività (come aiutarlo con le parti C / C ++).

Come altri hanno già detto, comportarsi in modo professionale è la cosa più importante per la tua carriera a lungo termine. E onestamente, fintanto che ti comporterai professionalmente, sarai in ottima forma, non importa come si comportano quelli che ti circondano.

In questa situazione, ci sono un paio di considerazioni che è necessario prendere in considerazione.

Innanzitutto, devi capire che sei responsabile del funzionamento del programma secondo le 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 entro la stessa scadenza. Per dirlo in modo diverso: se l'altra persona non rispetta la scadenza, anche tu hai perso la scadenza, anche se la tua parte del progetto era puntuale. In termini di gestione, questo si chiama proprietario degli input .

Hai giustamente notato che quando un tuo collega dichiara in una riunione che i bug del suo programma sono stati corretti, che non puoi dichiararlo immediatamente errato al manager (il tuo manager lo vedrebbe come "gettare il tuo collega sotto l'autobus"; una pessima mossa professionale). Altri, d'altra parte, hanno sottolineato che non è professionale non dichiarare il vero stato del progetto al manager. Entrambe le parti sono completamente corrette.

Quindi, se è male contraddire il tuo collega di fronte al manager, ed è anche male 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 loro sapere che al prossimo incontro dovrai dire al manager dei problemi con cui hai avuto il loro programma e che ciò sta influenzando la tua capacità di consegnare il tuo lato del progetto in tempo, e se c'è qualcosa che puoi fare per aiutarli ad affrontare i problemi che hai avuto. Devi avere questa conversazione almeno due giorni interi prima della riunione in cui dirai al manager e preferibilmente con un'intera settimana di anticipo.

Nella maggior parte dei casi, il semplice fatto di dire al collega che dovrete elencare il loro programma come un rischio in una riunione specifica li motiverà ad affrontare i problemi che avete e non dovrete mai parlare con il manager . In altri, dove i problemi sono più determinati dalla pianificazione, il collega spesso concorderà con te e voi due potrete andare insieme al manager.

Non ho mai avuto un collega che non mi ha risolto le cose in fretta o altrimenti concordato con le mie preoccupazioni, quando espresso in questo modo. Ma se accadesse, avvisando anticipatamente il tuo collega, saresti comunque in una posizione migliore quando parli con il manager. Dal momento che hai parlato con il tuo collega e hai provato a trovare una soluzione da solo, e li hai avvertiti con largo anticipo che avresti dovuto sollevare il problema in questa riunione, il tuo collega non sarà sorpreso quando lo fanno e il manager ha vinto non pensi che stai semplicemente cercando di spostare la colpa.

Ricorda che quando esprimi le tue preoccupazioni, al collega o al manager, le tue preoccupazioni riguardano il programma del tuo collega che sta restituendo dati errati (o qualsiasi altra cosa stia facendo); queste sono cose misurabili che possono essere verificate e riparate. Le tue preoccupazioni non riguardano il fatto che il tuo collega sia lento o indeciso; queste non sono cose misurabili, che possono essere o non essere vere e che è improbabile che vengano risolte sollevandole in una riunione 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 codice è in attesa di input dall'altro livello, i ritardi devono essere evidenziati nella documentazione di tracciabilità del progetto. Neanche questo sta succedendo?

Mi sembra che ci sia una gestione del progetto inadeguata qui. Devi a) tenere traccia dei bug che ti riguardano e b) seguire le discussioni per iscritto.

Il tuo collega non dovrebbe chiederti di aumentare i tempi 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, ti stai nascondendo per il tuo collega e questo quasi sicuramente si ritorcerà contro.

Non c'è niente di sbagliato nel cercare un collega, ma deve aspettarsi che qualcuno si aspetti che tu menti al tuo capo quotidianamente. Non potevo rispettarlo come persona e non avrei alcun desiderio di avere questa persona come conoscenza occasionale. Vuole essere un nemico, portalo avanti.

Come si possono sostenere 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. Documentare eventuali problemi che si verificano con un errore sulla sua app. E poi TORNA A CASA! Non mi importa se hai sonno o no. Trova alcuni amici che vale la pena avere.

Ho appena letto "The Clean Coder" di RC 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 il management sullo stato del progetto.

Mentire è sicuramente una pessima forma di comunicazione. Il tuo collega è estremamente poco professionale e anche tu. Entrambi non state 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 gran forma con tutti i problemi rimanenti a un livello molto alto di astrazione ... Il problema è che è l' unico codice di cui il tuo front-end ha bisogno!

O forse è un cattivo impiegato e sta portando la compagnia a fare un giro. Non posso dirlo, e potresti non avere tutte le informazioni che devi sapere con fiducia.

Suggerirei una tattica a metà strada. La prossima volta che ti incontri, porta nel tuo codice alcuni dettagli di un grosso bug che ti sta colpendo. Quando dice che tutto va bene, educatamente dire che c'è un problema in sospeso che blocca i tuoi progressi.

Politicamente, dirlo in questo modo ti fa affermare che non è del tutto corretto, pur continuando a dargli un'apertura per fare lo stupido e non essere messo sulla difensiva.

Il tuo manager dovrebbe chiedere alla prossima riunione se è stato risolto. In caso contrario, la pressione ricade su di lui per correggere un bug. Se è riparato, dì grazie, ora funziona alla grande e hai trovato un nuovo blocco. Se vuoi essere particolarmente gentile, supponi di esserti imbattuto poco prima della riunione.

Non stai mentendo, di per sé, né stai schierandosi. Stai giocando in politica richiamando l'attenzione sui problemi e lasciando che il tuo collega salvi la faccia se le cose non stanno andando molto bene.

È allettante parlare con il tuo manager, ma non dimenticare con quale di essi devi lavorare di più.

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

A proposito, 40 ore alla settimana è abbastanza amico. Devi mantenere alta la tua motivazione!

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

È il tuo modulo se devi farlo, devi alzare la bandiera rossa su cosa sta causando il ritardo sul 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 qui sta succedendo una cattiva gestione del progetto.

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

Il tuo manager potrebbe non essere abbastanza tecnico per capire chi sta rallentando il progetto, ma è probabilmente abbastanza intelligente da riconoscere che uno sviluppatore che sta attivamente cercando nuovi compiti è alle prese con il loro attuale compito. Questo porterà a una conversazione in cui puoi chiarire che stai aspettando correzioni di bug da altri sul tuo attuale incarico. 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 sia troppo lento con le sue correzioni di bug.