É normal que o programador trabalhe em vários projetos simultaneamente [fechado]

Em um trabalho atual, tenho dois projetos para trabalhar. O primeiro é um sistema muito grande e o segundo é menor, mas também grande (o primeiro projeto está sendo desenvolvido por 12 anos, o segundo por 4 anos).

No começo, eu trabalhava apenas no primeiro projeto e estava tentando me acostumar. Então fui transferido para o segundo projeto e tentei lá, então meu conhecimento sobre o primeiro projeto ficou obscuro. Agora eu tenho que trabalhar nos dois projetos ao mesmo tempo.

É muito difícil para mim, porque, apesar de usarem java, eles usam estruturas diferentes e a quantidade de código e lógica de negócios a entender é muito grande, então eu realmente não consigo segurar esses dois projetos na minha cabeça.

É normal e eu devo me acostumar com isso, embora meus conhecimentos tenham se tornado muito achatados, o que não acontecerá se eu trabalhar apenas em um único projeto? Ou devo levantar uma preocupação ou talvez mudar de empregador?

Discordo completamente quando as pessoas dizem "sim, multitarefa é normal"

Isso não é normal! De maneira alguma, é muito pouco natural para um desenvolvedor realizar várias tarefas em vários projetos (explicarei mais adiante). Por outro lado, a multitarefa é muito comum entre os desenvolvedores. Definitivamente, é algo que você deve se acostumar. Portanto, a verdadeira resposta para sua pergunta é: como fazer várias tarefas?

Antes de tudo, você não deve simplesmente aceitar seu destino, porque "você é um excelente funcionário" e isso significa que você precisa executar mais tarefas do que pode lidar. Nem um pouco, você não. Às vezes, as pessoas recebem várias tarefas porque não há mais ninguém. Às vezes, os gerentes não conseguem lidar com seu trabalho, então delegam, aplicando multitarefas em sua equipe porque não conseguem lidar adequadamente com o cronograma do projeto. Portanto, você deve definitivamente tentar determinar se você está sendo solicitado a realizar várias tarefas porque isso faz parte do seu trabalho ou porque outras pessoas estão sendo incompetentes. De qualquer maneira, você pode julgar por si mesmo se isso é aceitável ou não. Se você não se sentir confortável [com o seu trabalho], há outros lugares onde você pode encontrar trabalho. [Você, o desenvolvedor, é a mercadoria. Os empregadores sabem disso e rezam para que você nunca perceba.]

Agora, sobre multitarefa, discordo 100% quando as pessoas dizem "sim, basta alternar entre si e garantir que você esteja fazendo a mesma quantia em cada projeto". Desculpe, mas esse é um péssimo conselho.

Primeiro, você deve entender como seu cérebro funciona quando estiver desenvolvendo um software (eu sei que há outras tarefas envolvidas, mas vamos nos concentrar nessa). Você primeiro precisa se "conectar", o que significa que você precisa se concentrar muito e colocar sua mente em uma posição em que tenha tudo mapeado em sua cabeça. Todos os nomes de variáveis ​​e métodos, o fluxo de trabalho do seu código, o modelo de objeto, os threads indo lado a lado, tudo. Normalmente, leva-me 15, talvez 20 minutos, para entrar "na zona".

Quando você chega a esse estado, está realmente voando e escrevendo código como se estivesse andando de bicicleta. No momento em que você é interrompido, você pode perder tudo. Se a interrupção for longa o suficiente (5, 10 talvez 30 minutos), você perderá esse estado de espírito e terá que começar tudo de novo.

Portanto, a multitarefa é terrível porque obriga a deixar "a zona" e seguir para outra coisa. Se você está constantemente mudando, isso significa que você não está sendo produtivo, pois toda vez que você muda para uma nova tarefa / projeto, precisa perder 15 a 20 minutos para entrar na zona novamente (sem mencionar que isso derrete seu cérebro lentamente).

É como um multiencadeamento: em algum momento, o custo de alternar o contexto do encadeamento a cada dois ciclos é muito alto, de modo que a CPU acaba gastando mais tempo alternando os contextos do que executando as tarefas reais.

Eu recomendo a leitura de um artigo de Joel Spolsky sobre este assunto:

http://www.joelonsoftware.com/articles/fog0000000022.html

Portanto, meu conselho é: tente aprender a (não) multitarefa, porque é realmente comum. Mas também tenha certeza de que está confortável em fazê-lo. Algumas pessoas podem demorar mais tempo para se concentrar e sofrerão mais que outras quando realizarem tarefas múltiplas; e tudo bem também. Não é porque é comum que seja considerado normal.

Joel colocou bem quando disse:

De fato, a verdadeira lição disso tudo é que você nunca deve deixar as pessoas trabalharem em mais de uma coisa ao mesmo tempo. Verifique se eles sabem o que é. Bons gerentes vêem sua responsabilidade como remover obstáculos, para que as pessoas possam se concentrar em uma coisa e realmente fazer isso.

Sim, é de se esperar. E bem-vindo.

Existem algumas maneiras de analisar isso:

1. Espera-se que você faça várias tarefas e é quase impossível se concentrar. Isso resulta em processos de engenharia sub-ideais, confusão ocasional à medida que você alterna, sensação de exploração, frustração, estresse etc. Isso tudo é negativo, é claro; Contudo,

2. Você está confiando em vários projetos, o que reflete bem nos resultados que você produz e na confiança que seu empregador tem em suas habilidades. É uma oportunidade de mostrar a eles que a confiança é garantida.

Meu conselho é desenvolver um julgamento sóbrio de quais tarefas requerem sua atenção imediata e quais podem esperar. Às vezes, a resposta é que nenhum deles pode esperar e você precisa adotar uma abordagem criativa para fornecer resultados (um pouco para o projeto A, depois um pouco para o projeto B, depois enxágue e repita). Cultive as habilidades para prosperar nesse tipo de situação.

Normalmente (embora nem sempre), isso será recompensado com mais responsabilidade, mais projetos para conciliar e mais expectativas. Em algum momento, você poderá, e espera-se, delegar parte desse trabalho. É uma medida de sucesso.

Portanto, mesmo que suas habilidades crescentes de malabarismo sejam exploradas apenas pela sua empresa atual, essas são boas habilidades para ter e o servirão bem em sua carreira.

Pelo que vale, geralmente estou trabalhando em um projeto importante, menor, manutenção e suporte de projetos antigos e gerenciando pelo menos um outro. É frustrante, confuso, cansativo e estou muito agradecido.

Sim! Isso é completamente "normal" / usual quando você trabalha em uma empresa de serviços xD

Além disso, se você colaborar com projetos de código aberto, essa é a regra

Talvez não seja e estado ideal, mas é o pão de todos os dias.

É comum. Mas não é bom, pelas razões que você descreveu. A mudança de contexto consome produtividade, portanto, se você puder, tente trabalhar em um projeto por um longo período de tempo, por exemplo, um dia.

Eu trabalho ativamente em 2 a 3 projetos diferentes todos os dias. E mantenha mais algumas dezenas. Algumas semanas, fica um pouco esmagadora. Alguns dos projetos são enormes, outros são tão pequenos que foram codificados em poucos dias e raramente precisam de alterações. Isso varia, mas me mantém exposto a diferentes maneiras de pensar e resolver problemas, diferentes tecnologias e áreas de negócios. Eu gosto disso.

Então, para responder sua pergunta, sim, é muito comum.

Confira o artigo chamado Multitarefa leva você para lá mais tarde . Este gráfico conta a história:

Em outras palavras, a empresa está perdendo tempo fazendo com que seus programadores trabalhem em mais de um projeto por vez. Com apenas três projetos, o desperdício é de 40%! O resto do tempo é dividido em três projetos.

O motivo da multitarefa é frequentemente declarado como "fazer mais coisas". Mas esse é um raciocínio defeituoso. A multitarefa resulta apenas no atraso de todos os lançamentos. Esta imagem mostra o efeito da dupla tarefa versus concluir um projeto por vez:

(A imagem ignora completamente a sobrecarga. Na realidade, o tempo perdido tornaria os dois projetos 20% mais tarde.)

Depende da empresa. Na IMO, é desejável trabalhar principalmente em apenas um projeto, mas isso geralmente não é possível, especialmente em pequenas empresas.

Obviamente, correções de bugs etc. sempre podem acontecer com qualquer projeto.

Sim, na minha experiência, isso é normal (mesmo que alguns dos 'projetos' sejam bastante semelhantes, por exemplo, um projeto de manutenção e recursos no mesmo produto). Para evitar conflitos e expectativas irreais, concorde com os gerentes de projeto e seu gerente para alocar certas frações do seu tempo para cada projeto (por exemplo, três dias no projeto X, dois no projeto Y por semana). Normalmente, você pode distribuir essas alocações como desejar, por exemplo, seg-qua em X, qui-sex em Y.

Ocasionalmente, haverá momentos em que um projeto "lança uma exceção" e precisa ser trabalhado agora . Há duas coisas a fazer aqui:

1. assegure-se de que seja genuinamente uma exceção, não apenas um gerente de projeto insistente: recue no último caso.
2. troque suas alocações de tempo para continuar trabalhando a mesma fração em cada projeto.

Se você estiver achando difícil voltar à velocidade com a estrutura de um projeto ou a lógica de negócios quando voltar a usá-lo, aproveite a oportunidade para escrever o máximo de documentação possível enquanto estiver trabalhando nele. Detalhar como um sistema complexo funciona, em suas próprias palavras, facilitará muito o retorno ao projeto posteriormente. Além disso, esta documentação pode ser útil para seus colegas de trabalho, se eles precisarem ajudar.

Se o projeto já possui uma boa cobertura de documentação técnica, ainda pode ser benéfico anotar seus pensamentos enquanto trabalha em áreas complicadas. Dessa forma, você poderá retomar seu processo de pensamento na próxima vez em que voltar.

Bem, não deveria ser normal, mas tenho muitos projetos em meus ombros no meu atual empregador. Demora um pouco para me acostumar, eu admito. A dica mais importante que eu poderia dar é sempre priorizar seu trabalho. Force o seu chefe a dizer qual é a tarefa prioritária e trabalhe apenas nisso. Não exerça pressão de quem está reclamando de seus outros projetos. Você não precisa necessariamente atualizar seu currículo ainda, mas verifique se a carga não vai além de algo que possa razoavelmente lidar.

Eu acho que é normal. A maneira como meu trabalho funciona agora (estou em uma empresa com cerca de 40 desenvolvedores, tamanho total da empresa de aproximadamente 700). E eu normalmente tenho um projeto de "longo prazo" com muitos tickets / defeitos pequenos que aparecem, então geralmente acaba sendo 50% de tickets pequenos e 50% trabalham no projeto de longo prazo. O que pode ser difícil é que a interrupção constante possa desacelerar e atrapalhar o projeto a longo prazo.

Eu acho que é normal trabalhar em vários projetos. A chave é aceitar que você estará enfrentando alguma ambiguidade em termos da imagem geral do sistema inicialmente.

Se você se esforçar para obter uma visão mais ampla, obterá clareza e poderá identificar as peças móveis / fixas no sistema e como suas alterações afetam o sistema.

Durante um período de tempo, você aprenderá a encontrar padrões comuns nos vários sistemas em que trabalha. Eles podem ser aplicados a outros projetos, o que reduzirá a quantidade de informações granulares que você precisa manter em mente por vez.

Em qualquer projeto não trivial, há mais de uma pessoa atribuída a ele. Isso significa que você precisa colaborar com outras pessoas e esperar que elas façam seu trabalho, assim como elas precisam esperar por você.

Em vez de deixar as pessoas ociosas, é comum ter vários projetos ativos, para que sempre haja uma tarefa aberta a ser executada, se necessário.

Você ainda deve trabalhar em partes consideráveis ​​em cada projeto para poder entrar na zona e ser produtivo.

Eu concordo com aqueles que dizem que é normal / comum.

Olhe como positivo, você se tornará mais útil, visto como flexível, um cara que pode fazer as coisas! Talvez seja mais valioso à medida que você conhece dois sistemas de dentro para fora.

IMHO, não é apenas habitual, mas também é desejável.

O pior trabalho de desenvolvimento que já tive foi trabalhar na mesma pequena seção da mesma parte do mesmo aplicativo por meses a fio. Tédio. E quando você está entediado, tira o olho da bola ...

Entendo como você está se sentindo, é difícil fazer com que os novos empregadores entendam o desenvolvimento processado envolvido, especialmente se o empregador não estiver focado no desenvolvimento.

A questão é que eles veem três trabalhos sendo trabalhados juntos, mais de um fabricante de dinheiro do que um de cada vez, e as estatísticas mostram uma redução de 40% no desempenho. Isso é perda de 40% no lucro ..

Anteriormente, trabalhei em uma organização que me permitiu focar em um grande projeto de cada vez, com pequenos trabalhos no meio, tickets e suporte, etc. Trabalhámos em um acordo em que 8: 00-10: 00 AM era Ticket e suporte para os sistemas atuais que são enviados por e-mail / telefone / suporte técnico, depois das 10: 00h às 16: 30h ou o seu tempo de término foi um sólido desenvolvimento. Isso funcionou muito bem porque, como tínhamos um serviço de atendimento para atender as ligações e e-mails, pude fazer os ingressos pela manhã e desenvolver o resto do dia. O problema é se você tiver uma má administração. Um gerente faz tudo isso acontecer e, sem o apoio deles ou a compreensão dos desafios que você enfrenta diariamente, eles ignoram o fato.

Fico agradecido, especialmente em meu último trabalho, pelo apoio e compreensão do meu gerente, isso facilitou minha vida, menos estresse e ainda temos todo o trabalho realizado.

Outra questão é: o dinheiro amoroso de Boss, eles veem projetos em dinheiro. Quando eles têm 5 projetos por £ 20.000, tudo ao mesmo tempo (e você é um desenvolvedor solo), isso significa £ 100.000 nos livros. Parece ótimo no papel, mas pode prejudicar a reputação da empresa quando estes não forem cumpridos, os prazos são cumpridos e os sistemas são defeituosos devido à falta de concentração.

Eu simpatizo com você completamente, estou em sua posição agora.

Depende de como você descreve o projeto. Geralmente, o desenvolvedor trabalha com algum problema e, se houver mais de um produto na empresa, você trabalha com vários.

Projetos de software, como parceiros amorosos, podem ser muitos, e bons para muitos, mas são bons apenas se um de cada vez.

Além do que @Martin Wickman disse, tente não mudar muito as tarefas. Por exemplo, trabalhe AM no projeto A, PM no projeto B. Também diga não à adição de recursos; isso é mais doloroso quando você não está trabalhando no projeto em tempo integral.