Como faço para lidar com um colega lento e não dedicado da equipe? [fechadas]

Eu tenho trabalhado em um novo projeto. O projeto funciona da seguinte maneira: O usuário final pode acessar um aplicativo da web usando um link e ele pode adicionar vários sistemas em sua rede e gerenciar os detalhes específicos do sistema. Minha parte envolve o front end e o servidor da web, que é feito em python. Meu python realmente se comunica com outro projeto que é inteiramente feito em c & c ++. O projeto c / c ++ é o aplicativo principal que executa todas as funcionalidades. Meu python envia a solicitação do usuário para ele e exibe a resposta dele para o usuário.

Estou muito familiarizado com o meu trabalho e vou terminar em breve. Desde que não há muito trabalho nele. E eu sou uma pessoa que gosta de trabalhar. Passo a maior parte do tempo no escritório e só vou para casa quando estou com sono.

O aplicativo c / c ++ é gerenciado por outro colega com mais de 5 anos de experiência e pode fazer as coisas muito mais rapidamente do que eu, mas ele nunca faz isso. Pode ser que ele não goste de fazê-lo. Seu aplicativo trava frequentemente quando meu python se comunica com ele ou retorna valores incorretos. Está cheio de insetos. Como meu aplicativo depende disso, estou tendo dificuldades para construí-lo. Em vez de consertar os bugs, ele me pede para desacelerar meu trabalho. Ele me pede para dizer ao gerente que meu trabalho precisa de muito tempo. Ele está me pedindo para enganar o gerente e até me forçando a trabalhar lentamente como ele.

Durante a reunião do projeto, quando o gerente pergunta sobre os bugs, ele diz que corrigiu tudo e funciona bem. Como ele é meu colega, não pude contar nada ao gerente. Obviamente, preciso ter um bom relacionamento com meus colegas mais do que com meu gerente, pois na maioria das vezes estaremos com nossos colegas, não com o gerente.

Não sou capaz de dizer nada ao gerente sobre isso, pois se o gerente perguntar o porquê, ele poderá pensar que eu reclamei com ele ao gerente. E ele continua mentindo na reunião. E, como ele corrige o bug lentamente, ele ainda diminui o meu trabalho. Agora pensei em trabalhar na parte front-end do meu aplicativo e finalizá-lo para que, nesse meio tempo, ele possa tornar seu projeto estável. Agora, ele está me pedindo para dizer ao gerente que minha parte do front-end exige muito trabalho e que posso precisar de mais e mais tempo, simplesmente para que ele possa arrastar o projeto para baixo. E o triste é que nosso gerente atual foi para os EUA, então temos um gerente temporário e esse cara não conhece muito o projeto, então o c, c ++ apenas o engana.

Alguém pode me sugerir como eu lido com isso? Eu queria terminar o projeto em breve. Como posso fazê-lo trabalhar, mantendo um bom relacionamento com ele?

Respostas aos comentários:

Se ele está realmente enganando deliberadamente a empresa, você deve denunciá-lo à gerência.

Eu sou novo nesta empresa e o outro cara está lá há muitos anos. E eu apenas comecei a conhecer meus colegas. Se eu for diretamente reclamar com ele, acho que não posso fazer um bom relacionamento com meus outros colegas. Até ele tem o poder de enganá-los. Não estou dizendo que ele é um cara mau, ele pode fazer o trabalho, mas ele não está fazendo.

Sua empresa não possui nenhum tipo de sistema de rastreamento de bugs?

Aqui, o sistema de rastreamento de bugs não existe. A empresa tenta finalizar o projeto o mais rápido possível e o entrega ao controle de qualidade. E, em seguida, corrige os erros relatados pelo controle de qualidade.

É por isso que as empresas devem oferecer aos funcionários ações / opções ou algum tipo de propriedade. Dessa forma, você pode literalmente dizer ao sujeito: "Você está me custando crescimento monetário ... não quer ganhar dinheiro também?".

A empresa tem as opções de ações que me deram em 2500 ações, principalmente ele também teria um pouco mais.

A antiguidade merece algum benefício de uma dúvida. Você realmente precisa falar com ele primeiro e tentar entender o problema. Ele pode estar fora de sua profundidade, você pode ajudá-lo, pode haver facilmente variáveis ​​que você não conhece. Pode ser difícil agora, mas você pode facilmente tornar a situação muito pior ao pular a arma.

Eu até faço isso, primeiro o aplicativo não estava lidando com várias solicitações ao mesmo tempo, ele estava usando uma fila para lidar com as solicitações que enviei a ele. Eu até sugeri a ele algumas das minhas idéias sobre isso. Ele disse que já tinha essas idéias e as executará. Suas explicações foram: "Tudo exige um certo tempo para fazer e este é um projeto que pode levar dois anos para ser concluído e é-nos solicitado que o concluamos em dois meses". Eu costumava ter dificuldade em codificar durante as primeiras semanas por causa desse bug. Mas agora ele consertou. Mas ele está usando uma fila única para solicitações de um usuário e agora está desacelerando o aplicativo, pois ele processa uma solicitação de cada vez.

O que o controle de qualidade está fazendo isso o tempo todo? Por que eles não estão relatando / confirmando o status do (s) projeto (s)?

O gerente é a pessoa que decide quando dar o controle de qualidade. Até agora, ainda não foi entregue ao controle de qualidade. Ele disse que deveríamos dar até o final deste mês.

Você está em uma situação ruim, eu não gostaria de estar no seu lugar. É improvável que você possa resolvê-lo sem entrar em conflito com seu colega.

Isto é o que eu faria:

• Não se torne seu parceiro no crime. Recuse-se a mentir sobre o status do seu projeto ou dele.

• Implemente (no seu tempo livre, se necessário) o relatório de erros para o seu aplicativo, para que todos os erros sejam enviados por email aos seus colegas de trabalho e ao seu gerente. Se o bug for causado pelo aplicativo, torne-o visível no email (coloque [XYZ APP BUG] no assunto do email ou algo assim).

• Manter um banco de dados de bugs (além de enviar bugs por email). Você pode dizer que seu objetivo principal é rastrear seus erros, quando na verdade você estará rastreando principalmente os erros dele . Entre outras coisas, ele deve rastrear quanto tempo leva para corrigir um bug específico.

• Tenha toda a comunicação entre processos com o aplicativo dele coberta com testes (estilo "quando lhe enviei isso, você deve me devolver esse"). Você pode configurar uma tarefa cron que execute esses testes todos os dias e, se eles falharem, o email será enviado a todos.

Basicamente, tente não perder tempo discutindo com ele sobre bugs e concentre-se no seu trabalho. Se o aplicativo dele estiver quebrado e, portanto, você não puder trabalhar no aplicativo, o gerente não fará nada com ele - bem, isso é um problema de gerenciamento e você estará coberto com banco de dados de erros, e-mails e relatórios de teste.

No entanto, cuidado e não o subestime. Preguiçoso de longa data como ele pode ter um truque ou dois na manga. Ele pode virar a equipe inteira contra você ou algo assim, mas isso depende da sua situação específica e está meio fora do escopo desta questão.

Vou apresentar uma visão um pouco controversa: você diz que está trabalhando quantas horas puder ficar acordado. Então, talvez ele não esteja sendo particularmente injusto em dizer "você está me deixando mal e eu estou trabalhando quantas horas eu quiser". Talvez ele tenha estado lá e feito isso e talvez ele tenha se esgotado. Prometo que sim, se continuar assim.

Saia para tomar uma bebida com ele uma noite e veja se não consegue construir um relacionamento pessoal melhor para basear seu profissional. Talvez por ele concordar em colocar um pouco mais e por você concordar em colocar um pouco menos, vocês dois possam trabalhar juntos muito melhor.

Se eu fosse você, também teria muito cuidado com toda essa atitude "meu trabalho, seu trabalho". Entre vocês, você tem um produto para divulgar e isso não pode ser bom para esse produto, o que, por sua vez, não é bom para a empresa ou para o cliente, e eles pagam para que ambos trabalhem .

No entanto, ainda concordo com os outros pontos de vista de que você precisa revisitar a importância de seu relacionamento com seu gerente e precisa ter cuidado ao confiar em seu colega. Só estou dizendo que talvez, apenas talvez, você precise considerar suas próprias ações e as dele.

Manter registros. Documente todos os erros que você receber ao se comunicar com o lado dele, quando você pediu para ele corrigir e quando (se alguma vez) ele fez. Essa é a única maneira que conheço de lidar com esta situação. Portanto, quando seu gerente perguntar a você por que as coisas não estão progredindo, você poderá mostrar claramente sem ser visto como um chorão ou um colega ruim.

Eu gostaria de apontar outra possibilidade que não foi levantada. Você diz que ele quer que você diminua o seu trabalho. Você quer dizer literalmente que ele está dizendo "trabalhe menos horas" ou que ele está dizendo "escreva alguns testes, teste mais isso, escreva alguma documentação" e outras coisas que você acha que o atrasarão? Vi pessoas novas escrevendo código durante 16 horas por dia e depois reclamando de bugs no código que estão chamando quando, na verdade, passam parâmetros inválidos, não estão verificando valores de retorno e assim por diante. Não posso descartar que seu colega de trabalho esteja pensando nessas coisas.

Na próxima vez em que você estiver em uma reunião e ele disser que todo o código está bom, diga "oh, bom, a coisa que eu contei há uma hora atrás, onde ela explode quando ligo para XYZ com uma data que não é um dia útil, está consertado agora? " Uma das três coisas acontecerá:

• Ele mentirá e dirá que não há esse problema; você dirá "existe! Nós discutimos! Enviei um e-mail a você!" e tudo vai chamar a atenção de um gerente
• Ele lhe dirá que, de fato, isso não é um bug no código dele, é um bug no seu código, porque você só deve passar dias úteis e logo descobrirá o que ele está pensando, mas não está dizendo.
• Ele dirá "não, aquele com quem você acabou de me falar vou lidar hoje, mas todo o resto é bom". Se ele disser isso, agradeça-o por enquanto.

Você pode aprender que seus longos dias de codificação rápida não estão produzindo um bom código, e alguém (talvez seu gerente) pode traduzir para o outro desenvolvedor explicar a você qual é o problema. Ou então, você pode aprender que está trabalhando com uma cobra mentirosa que fará com que você pareça mal para proteger sua posição confortável. Trazer as coisas à tona não pode realmente piorar as coisas. Ou, você pode obter movimentos suficientes dele para aguentar, sem se envolver na política.

O que você tem é um problema político. Primeiro, a opinião do seu gerente é muito, muito mais importante do que você pensa. Esse cara está culpando você pelos atrasos e você está deixando. Você é quem será demitido se alguém for jogado sob o ônibus. Tanto quanto o gerente sabe, é você quem é incapaz de fazer o trabalho em tempo hábil.

Proteja-se da maneira que puder, através de rastreamento de bugs, e-mails, etc., mas NÃO aceite fingir que este é o seu atraso, não o dele. Nunca dê ao chefe um relatório de status falso, ele voltará para morder você. Diga ao chefe a verdade sobre os problemas que você tem (e mostre a prova) com o código dele não funcionando.

Essa pessoa que está pedindo para você relaxar para não parecer ruim é uma cobra (bem, isso é um insulto à comunidade de cobras (referência sutil do Firefly), desculpe a todas as cobras reais por aí). Ele fará qualquer coisa para jogá-lo debaixo do ônibus em vez dele. Não confie nele.

Em primeiro lugar:

Como ele é meu colega, não pude contar nada ao gerente.

Você absolutamente pode e deve garantir que seu gerente saiba a verdade, mesmo que seu colega de trabalho esteja mentindo para ele. Se você não quiser dizer nada em uma reunião com os três na sala, isso é totalmente compreensível. Mas você deve pelo menos afastar seu gerente (o real, não apenas o temporário) e informá-lo de que seu trabalho está quase pronto e aguarda correções de bugs do outro desenvolvedor antes que todo o aplicativo esteja pronto para o horário nobre . Não acuse seu colega de mentir, mas não fique sentado e deixe seu chefe operar com informações incompletas.

Relate seus status honestamente. Se seu trabalho estiver sendo retido por bugs no final de outro desenvolvedor, documente que você encontrou bugs no C / C ++ e os informou (por favor, diga-me que você está usando algum tipo de documentação que deixa um rastro de papel).

Enquanto isso, vá em frente e encerre seu trabalho e informe seu chefe quando terminar. Se o seu gerente quiser saber por que o restante do projeto ainda não está funcionando, você pode encaminhá-lo para o outro desenvolvedor e talvez mencionar que provavelmente é muito complicado / grande / requer muitos testes / outro desenvolvedor é muito ocupado / etc. Se você conhece C / C ++, pode oferecer ajuda na lógica principal do aplicativo para que as coisas também aconteçam. Sim, você estará fazendo o trabalho do outro, mas deixa claro que você é o funcionário que trabalha duro e é produtivo, e o outro não, sem mencionar que o torna ainda mais valioso para o seu chefe. Pode até pressionar o outro desenvolvedor para acelerar as coisas e fazê-las mais rapidamente.

Há uma série de problemas no trabalho. Esteja ciente que:

1. Você está fazendo suposições sobre as motivações de outras pessoas
2. Você está colorindo fatos com opiniões.
3. Pessoas de fora (mais ninguém) não estão cientes da história e não estão cientes de suas frustrações com seu colega.
4. Você pode parecer infantil se parecer que está jogando um jogo de "pegadinha". Seu colega provavelmente pode jogar melhor - afinal, ele ainda tem um emprego, não é?

Portanto, ao apresentar o status do seu projeto:

1. Não mencione a outra pessoa.
2. Ao relatar erros ou problemas com o código - não o desenvolvedor. Diga "A chamada para o método FooBar () está retornando 1 quando deveria retornar um 2". Então, qualquer problema não é um ataque pessoal, você está apenas falando sobre código - não sobre pessoas.
3. atenha-se aos fatos pelos quais você tem provas.
4. Se o seu colega ficar na defensiva ou hostil, faça perguntas. "Eu não entendo por que você acha que eu deveria fazer _ "
5. Seja alheio a insultos sociais ou insinuações. Finja que você não recebe o ataque pessoal.
6. Durma muito na noite anterior a qualquer reunião de status, para ser mentalmente ágil.
7. Documento, documento, documento.
8. Não tenha vergonha de pedir a esse cara que o ajude com algum problema interessante, ele pode levar para você se achar que você o respeita. Trata-se de construir relacionamento. (observe que isso não está sugando - isso é outra coisa)
9. Esteja preparado para sair, se for necessário, para não ficar carente ou emocionalmente preso. Isso ajudará a manter a cabeça nas reuniões.

"Sou uma pessoa que gosta de trabalhar. Passo a maior parte do tempo no escritório e só vou para casa quando sinto sono."

Isso não é saudável e não se pode esperar dos colegas, a menos que você seja compensado a ponto de poder tirar anos de folga pelo inevitável esgotamento. (Algo como> 10% de propriedade da empresa ou acima de US $ 200 mil por ano). Manter o conhecimento para chegar ao ponto em que ele pode se desenvolver muito rapidamente leva tempo. Parte do seu tempo deve ser dedicada ao desenvolvimento de conhecimentos.

"O projeto c / c ++ é o aplicativo principal que executa todas as funcionalidades. Meu python envia a solicitação do usuário e exibe a resposta dele para o usuário. ... Pode ser que ele não goste."

Python é uma linguagem mais ágil que C / C ++. Seu aplicativo parece conter todas as funcionalidades; seu aplicativo apenas a interface do usuário. Mais provável do que não, estes não são iguais em dificuldade. Ele pode não estar produzindo código rapidamente; mas a codificação de qualidade é muito melhor que a codificação por quantidade. Muito bem, você pode ter expectativas irreais sobre a rapidez com que ele pode codificar nas horas em que deseja / espera trabalhar (normalmente ~ 40 horas por semana; e lembre-se, se ele estiver lá há anos, ele provavelmente acumulou outras tarefas, como gerenciar outras pessoas ou ajudar a manter a idade. projetos que ocupam uma parte significativa da semana de trabalho).

Não minta para ele; mas também não o critique. Fale sobre como o sistema dele é ótimo; concedido precisa de mais trabalho até terminar. Dê ao seu gerente uma atualização de status precisa sem nomear nomes / atribuir culpa. Escreva uma versão simulada de seu sistema que esteja em conformidade com o mesmo padrão em que seu sistema deve estar. Verifique se o seu sistema funciona perfeitamente com o seu sistema de simulação com um conjunto de testes automatizado. Em seguida, seu sistema poderá ser finalizado (por exemplo, sincroniza perfeitamente com o mock-up), mesmo se o sistema ativo ainda estiver com erros.

Em seguida, você pode escrever um conjunto de testes automático para o sistema chamado externamente, em conformidade com os padrões acordados. Por exemplo, teste que Foo (1,2,3) devolve uma resposta de "Bar 4 5 6". Isso pode ajudá-lo a identificar bugs e acelerar o desenvolvimento (e não precisa mexer com seu código). Uma vez concluídas essas etapas, você poderá passar para outro projeto / tarefa (como ajudá-lo nas partes do C / C ++).

Como outros já mencionaram, comportar-se profissionalmente é a coisa mais importante para sua carreira de longo prazo. E honestamente, desde que você se comporte profissionalmente, você estará em ótima forma, não importa como as pessoas ao seu redor se comportem.

Nessa situação, há algumas considerações que você precisa levar em consideração.

Primeiro, você precisa entender que você é responsável por seu programa trabalhar com as especificações desejadas, dentro do prazo estabelecido. Se o seu programa interoperar com o de outra pessoa, você também será responsável por garantir que esse outro programa também funcione no mesmo prazo. Em outras palavras: se a outra pessoa perder o prazo, você também o terá perdido, mesmo que sua parte do projeto esteja dentro do prazo. Em termos de gerenciamento, isso é chamado de propriedade das entradas .

Você observou corretamente que, quando o seu colega declara em uma reunião que os bugs do programa foram corrigidos, você não pode declara-lo imediatamente incorreto para o gerente (seu gerente veria isso como "jogar seu colega de trabalho sob o ônibus"; uma péssima mudança de carreira). Outros, por outro lado, apontaram que não é profissional não declarar o verdadeiro estado do projeto ao gerente. Ambos os lados estão completamente corretos.

Então, se é ruim contradizer seu colega na frente do gerente, e também é ruim não contradizê-lo, o que você faz?

A resposta é realmente bastante simples: você precisa conversar com seu colega antes da reunião com o gerente e informar que, na próxima reunião, você precisará informar ao gerente sobre os problemas que está enfrentando. o programa deles, e isso está afetando sua capacidade de entregar seu lado do projeto a tempo e se há algo que você possa fazer para ajudá-los a resolver os problemas que você está enfrentando. Você precisa ter essa conversa pelo menos dois dias inteiros antes da reunião, onde informará o gerente e, de preferência, com uma semana de antecedência.

Na maioria dos casos, apenas dizer ao seu colega que você terá que listar o programa deles como um risco em uma reunião específica os motivará a resolver os problemas que você está tendo, e você nunca precisará conversar com o gerente . Em outros, onde os problemas são mais direcionados ao cronograma, o colega geralmente concorda com você e os dois podem ir juntos ao gerente.

Eu nunca tive um colega que não resolveu as coisas rapidamente ou concordou com as minhas preocupações, quando expresso dessa maneira. Mas se isso acontecesse, ao avisar seu colega com antecedência, você ainda estaria em uma posição melhor ao conversar com o gerente. Como você conversou com seu colega e tentou encontrar uma solução por conta própria, e avisou-o com antecedência de que seria necessário levantar o problema nesta reunião, seu colega não ficará surpreso quando o fizerem e o gerente venceu. pense que você está simplesmente tentando mudar a culpa.

Lembre-se de que, quando você expressa suas preocupações, seja para o colega ou para o gerente, essas preocupações são sobre o programa do seu colega que está retornando dados incorretos (ou o que quer que esteja fazendo); são coisas mensuráveis ​​que podem ser verificadas e corrigidas. Suas preocupações não são sobre seu colega ser lento ou não dedicado; essas não são coisas mensuráveis, que podem ou não ser verdadeiras e que dificilmente serão corrigidas, trazendo-as para uma reunião na frente do chefe.

Qual sistema de rastreamento de bugs você está usando? Eu esperava que pelo menos destacasse onde os bugs não estão sendo corrigidos no devido tempo. Onde seu código está aguardando a entrada da outra camada, os atrasos devem ser destacados na documentação de rastreamento do projeto. Isso também não está acontecendo?

Parece-me que há gerenciamento de projetos inadequado aqui. Você precisa: a) rastrear os bugs que estão afetando você; b) acompanhar as discussões por escrito.

Seu colega não deve pedir para você aumentar o tempo de desenvolvimento para cobrir a falta de vontade dele. Em algum momento, isso deve ser tratado com seu gerente. No momento, você está encobrindo seu colega e isso quase certamente sairá pela culatra.

Não há nada de errado em defender um colega, mas alguém espera que você minta diariamente para o seu chefe. Eu não podia respeitá-lo como pessoa e não gostaria de ter essa pessoa como um conhecido casual. Ele quer ser um inimigo, trazê-lo.

Como você pode argumentar atrasos na camada de aplicativos por causa do front end? É por isso que você faz isso para que eles possam ser separados. O que vem a seguir, ele tem ainda mais atrasos porque alguém quer criar um front end para mobil?

Faça seu trabalho. Documente os problemas que você está tendo com uma falha no aplicativo dele. E então vá para casa! Eu não me importo se você está com sono ou não. Encontre alguns amigos que valem a pena ter.

Acabei de ler "The Clean Coder", de RC Martin (tio Bob). O ponto principal do livro é que os programadores em geral não recebem muito respeito porque não estão se comportando profissionalmente . Isso significa principalmente que eles não se comunicam efetivamente com a gerência sobre o status do projeto.

Mentir é certamente uma forma muito muito ruim de comunicação. Seu colega está sendo extremamente profissional e você também. Vocês dois não estão fazendo nada de bom para melhorar a percepção dos programadores.

Eu aconselho você a ir imediatamente para a gerência. No entanto, eu tive problemas no passado por ter sido muito "honesto" (em alguma situação não relacionada), então não tenho certeza se você deve seguir meu conselho. Além disso, como muitos apontaram, talvez sua percepção da situação não seja tão precisa quanto você pensa.

É difícil e irracional estimar o esforço e a complexidade relativos de outro projeto, se você não estiver familiarizado com a base de código. Você diz que o código dele é propenso a erros, mas pode estar em ótima forma com todos os problemas restantes em um nível muito alto de abstração ... O problema é que esse é o único código que seu front end precisa!

Ou talvez ele seja um mau funcionário e esteja levando a empresa para passear. Não posso dizer, e você também pode não ter todas as informações que precisa saber com confiança.

Eu sugeriria uma tática intermediária. Da próxima vez que você se encontrar, traga alguns detalhes de um grande erro no código dele que está afetando você. Quando ele disser que está tudo bem, diga educadamente que há uma questão pendente que está bloqueando seu progresso.

Politicamente, dizendo assim, vamos afirmar que ele não está totalmente correto, enquanto ainda lhe dá uma chance de se fazer de bobo e não ser colocado na defensiva.

Seu gerente deve perguntar na próxima reunião se está consertado. Caso contrário, a pressão recai sobre ele para corrigir um erro. Se estiver correto, diga obrigado, está funcionando muito bem agora e você encontrou um novo bloqueador. Se você quer ser especialmente gentil, diga que a encontrou pouco antes da reunião.

Você não está mentindo, por si só, nem está tomando partido. Você está jogando política chamando a atenção para os problemas e deixando seu colega ficar de fora, se as coisas realmente não estiverem indo tão bem.

É tentador apenas conversar com seu gerente, mas não esqueça com qual deles você mais deve trabalhar.

A resposta de Pat foi ótima. Eu concordo 100%. Não vá espreitar uma reunião com o chefe. Leve-o com o seu colega entre quatro olhos ou com todos os três. Mas a sugestão de Pat de se concentrar nos problemas de código e não nas pessoas é o caminho certo a seguir.

Btw, 40h / semana é suficiente cara. Você precisa manter sua motivação alta!

Peça mais alguma coisa para ajudá-lo nos testes de integração. A pessoa deve ser capaz de dizer onde o problema ocorre. Como tentador apontou, eu me pergunto por que não existe um excel para rastrear os problemas! como não há rastreamento, é como toda vez que o outro cara foge dizendo que está tudo bem a partir de agora! não funciona dessa maneira!

É o seu módulo, se você precisar fazê-lo, precisará levantar a bandeira vermelha sobre o que está causando o atraso do seu lado. A experiência no MERE Years não tem nada a ver, é apenas o conhecimento e é nisso que o seu gerente deve insistir. Como já foi dito, sinto que há um gerenciamento deficiente do projeto acontecendo aqui.

1. Mostrar iniciativa solicitando tarefas adicionais e perguntando como você pode agregar valor à organização é a melhor maneira de ganhar confiança.

Seu gerente pode não ser técnico o suficiente para descobrir quem está atrasando o projeto, mas provavelmente é inteligente o suficiente para reconhecer que um desenvolvedor que está buscando ativamente novas tarefas está passando rapidamente pelas tarefas atuais. Isso levará a uma conversa em que você poderá deixar claro que está aguardando correções de erros de outras pessoas em suas tarefas atuais. Enquadre a discussão em termos de como você pode agregar valor adicional à organização usando eficientemente seu tempo livre, e não como seu colega está sendo muito lento com as correções de erros.