Quais as vantagens de divisão do tempo do colaborador entre dois projetos? [fechadas]

https://stackoverflow.com/questions/770470

12-09-2019
|

Pergunta

Eu tenho dois projetos, com prioridades idênticas e horas de trabalho demanda e um único desenvolvedor. Duas abordagens possíveis:

Entregar um projeto pela primeira vez.
Split tempo do desenvolvedor e entregar tanto mais tarde.

Eu não consigo ver qualquer razão por que as pessoas escolhem a segunda abordagem. Mas eles fazem. Você pode me explicar por quê?

Solução

Parece-me que esta decisão muitas vezes se resume a política do escritório . Um grupo empresarial não quer sentir menos importante do que outro, especialmente com as prioridades idênticas estabelecidos no topo. Independentemente de quantas maneiras diferentes você explicar por que fazer as duas coisas ao mesmo tempo é uma má idéia, parece que a política ficar no caminho.

Para obter o melhor produto para os usuários, você precisa para evitar desenvolvedor surra. Quando os desenvolvedores estão se debatendo, o risco de defeitos e comprimento dos prazos de entrega começam a aumentar exponencialmente.

Além disso, se você pode colocar seu chapéu de negócios, você pode tentar explicar-lhes que agora, ninguém está recebendo qualquer valor a partir do que os produtos concluídos vai entregar. Faz mais sentido para a empresa para obter o melhor produto ROI fora da porta primeiro a começar a recuperar o investimento o mais rápido possível, enquanto o outro projeto terá início assim que o primeiro for concluído.

Outras dicas

Às vezes você precisa apenas se afastar do código ter sido escrita por 11 horas a fim de permanecer maximamente produtivo. Depois de ter sido olhando para as minúcias de um sistema que você têm vindo a implementar por um longo tempo pode tornar-se difícil ver a floresta para as árvores, e que é quando você começa a cometer erros que são difíceis de un-make.

Eu acho que é melhor ter 2-3 projetos atuais; um um principal e 1-2 outros projectos que não estão em uma linha de tempo tão estrita.

Se os dois projetos têm a mesma prioridade para a empresa, uma razão óbvia é para gerentes de projeto para dar maior gestão a ilusão de que ambos os projectos são tomadas de cuidados.

Considere que os dois projetos podem pertencer a diferentes clientes (ou ser solicitado por pessoas diferentes de gestão superior).

Nenhum cliente quer ser dito para esperar enquanto projeto de um cliente diferente é dada prioridade.

"Vamos deixar o outro para mais tarde" é, muitas vezes, não é uma resposta aceitável, mesmo que isso leva a atrasos para ambos os projetos.

Eu acredito que isto está relacionado com a noção de em um programa de software " Percebida Receptividade ". Mesmo se algo leva mais tempo para fazer, parece mais rápido quando ele parece estar fazendo alguma coisa, em vez de braços cruzados à espera de algumas outras coisas para ser concluído.

Depende das dependências envolvidas. Se tiver outra dependência do projeto que pode ser cumprida quando o projeto não é 100% completa, então ele pode fazer sentido para dividir o tempo do colaborador. Por exemplo, se sua tarefa é grande, pode fazer sentido para ter o principal desenvolvedor fazer um projeto, em seguida, passar para uma segunda tarefa enquanto um MembroEquipa comentários o projeto o desenvolvedor principal veio com.

Além disso, deserializing desenvolvedores a partir de uma única tarefa pode ajudar a aliviar o tédio. Sim, há uma perda potencialmente significativa na mudança de contexto, mas se ele ajuda a manter o dev afiada, vale a pena.

Se você vai pelo que está no grande e santo livro 'peopleware', você deve manter seu programador em um projeto de cada vez.

A principal razão para isto é que a atenção dividida irá reduzir a produtividade.

Infelizmente, porque muitas gerências operacionais são bom homem de negócios em vez de bons gestores , eles podem pensar que multitarefa ou trabalhando em dois projetos de alguma forma significa que mais coisas estão sendo feitas ( o que é impossível, uma pessoa pode só existe fisicamente em um fluxo do continuum espaço-tempo de uma só vez).

espero que ajude:)

Eu acho que a razão número 1 do ponto de vista de gestão é para o progresso percebido. Se você trabalha em mais de um projeto ao mesmo tempo, as partes interessadas são capazes de ver progredir imediatamente. Se você segurar um projeto fora, em seguida, as partes interessadas de que o projeto pode não gostar que nada está sendo trabalhado.

trabalhando em mais de 1 projeto também minimiza os riscos tanto. Por exemplo, se você trabalha em um projeto em primeiro lugar e que o projeto leva mais tempo do que o esperado você pode executar em problemas com o segundo projeto. Stakeholder também provavelmente vai querer o seu projeto feito agora. Segurando um fora devido a um outro projeto pode fazê-los reconsiderar ir em frente com o projeto.

Dependendo do que os projetos são que você pode ser capaz de trabalhar alavancagem feito um para o outro. Se eles são semelhantes, em seguida, fazer os dois ao mesmo tempo pode ser benéfica. Se você fazê-las em seqüência única os projetos subseqüentes podem se beneficiar dos anteriores.

Na maioria das vezes os projectos não são um fluxo constante de trabalho. Às vezes, os desenvolvedores estão ocupados e às vezes não. Se você só trabalha em 1 projeto em um tempo um desenvolvedor e outros membros da equipe provavelmente seria não fazer nada enquanto os mais tarefas 'administrativas' estão ocorrendo. Gerir o tempo por mais de um projeto permite que as equipes obter mais feito em um prazo mais curto.

Como um desenvolvedor eu prefiro trabalhar em vários projetos, desde que os prazos são razoáveis. Contanto que eu não estou sendo solicitado a fazer as duas coisas ao mesmo tempo sem qualquer alteração no cronograma Eu estou bem. Muitas vezes, se eu estou preso em um projeto que eu possa trabalhar no outro. Depende dos projectos embora.

Eu pessoalmente prefiro o primeiro, mas a gestão pode querer ver o progresso em ambos os projetos. Você também pode reconhecer estimativas imprecisas mais cedo se você está fazendo algum trabalho de ambos, o que permite informar o cliente antes.

Assim, a partir de uma perspectiva de desenvolvimento 1 é a melhor opção, mas de um ponto de vista 2 serviço ao cliente é provavelmente melhor.

É o gerenciamento de suas expectativas dos clientes; se você pode dizer tanto os clientes que você está trabalhando em seu projeto, mas vai demorar um pouco mais devido a outros projectos, em seguida, dizer que está colocando o seu projeto fora até que terminar este outro projeto o cliente vai pular do barco e encontrar alguém que possa começar a trabalhar em seu projeto agora.

É um efeito plaecbo ??- dividindo um desenvolvedor entre dois projetos da maneira que você descreveu dá às pessoas / "negócio" a impressão de que o trabalho está sendo concluído em ambos os projectos (à taxa mesma / custo / hora), enquanto na realidade, é provavelmente muito mais ineficiente, uma vez que a troca de contexto e de outras considerações tem um custo (em tempo e esforço).

Por um lado, ele pode fazer a bola rolar em coisas como esclarecimentos de requisitos e tarefas semelhantes (de modo que o desenvolvedor pode mudar para o projeto alternativo quando eles estão bloqueados) e também pode levar a entrada de início de outras unidades de negócios / partes interessadas etc.

Em última análise, porém, se você tem um recurso, então você tem um gargalo natural.

A melhor coisa que você pode fazer para que o desenvolvedor solitário é interceptar as pessoas (de distrair a pessoa), e tentar levar um pouco da burdon torno de requisitos, perseguindo esclarecimentos e manipulação de feedback do usuário etc.

A única vez que eu já tinha propositadamente puxar um desenvolvedor de fora de seu projeto principal é se eles seria um trunfo para o segundo projeto, eo segundo projeto foi parado por algum motivo. Se permitir que um desenvolvedor para dividir uma parte de seu tempo poderia ajudar a impulsionar um projeto parado, eu faria isso. Isto aconteceu-me com os desenvolvedores "especialistas" - aqueles que têm muito mais experiência / habilidades especializadas / etc

Dito isto, gostaria de tentar manter o desenvolvedor em dois projetos para tão pouco tempo quanto possível, e trazê-los de volta ao seu projeto "main". Eu prefiro permitir que as pessoas se concentrar em uma tarefa de cada vez. Eu sinto que meu trabalho como gerente é prioridades e foco equilíbrio e deslocamento das pessoas -. E desenvolvedores deve apenas desenvolver, tanto quanto possível

Há três vantagens reais de tempo dos desenvolvedores divisão entre os projectos que não podem ser ignorados:

Especialização:. Fazendo ou consultar no trabalho que requer conhecimento especializado semelhante em ambos os projetos
A coerência ea partilha de conhecimento:. Trazendo consistência na forma como dois produtos distintos são construídos e trabalho, difundir o conhecimento do outro lado da empresa
Melhor utilização equipa:. Em uma ocasião rara quando um dos projectos está temporariamente em suspenso à espera de alguma outra entrada

tempo Splitting entre vários projectos é benéfico quando não envolve uma mudança significativa no contexto.

Ter um desenvolvedor trabalhar sozinho em vários projetos de desenvolvimento de software nega o benefício de especialização (não há qualquer no caso), consistência e compartilhamento de conhecimento.

Ele deixa apenas a vantagem de utilização do tempo, no entanto, se contextos diferem significativamente e não há sobreposição considerável entre os projectos a sobrecarga de comutação muito provavelmente excedem qualquer momento salvo.

troca de contexto é um animal muito interessante: ao contrário do seu nome implicando uma mudança discreta o processo é sempre gradual. Existem vários graus de ter informações de contexto na nossa cabeça: contexto 10% (rasa), 90% (de profundidade). Demora menos tempo para rasa-switch ao invés de completamente-switch; no entanto, há uma correlação directa entre a quantidade de contexto carregado (concentração na tarefa) e qualidade de produção.

É possível preencher o seu tempo inteiramente trabalhando em vários projetos distintos que dependem de rasa-switching (para reduzir o tempo de espera), mas a qualidade da saída sofrerá inevitavelmente. Em algum ponto não é só “não-funcionais” aspectos de qualidade (segurança do sistema, usabilidade, desempenho), que irá degradar, mas também funcional (sistema deixando de realizar o seu trabalho, falhas funcionais).

Por dividindo o tempo entre dois projetos, você pode reduzir o risco de atrasar um projeto por causa de outro.

Vamos supor que a estimativa para ambos os projetos é de 3 meses cada. Ao fazê-lo em série, um após o outro, você deve ser capaz de entregar o primeiro projeto depois de 3 meses, o segundo projecto 3 meses mais tarde (ou seja, após 6 meses). Mas, como as coisas vão no desenvolvimento de software, as chances são de que o primeiro projeto encontra alguns problemas por isso leva 12 meses em vez. Ou, pior ainda, vai para o purgatório "em uso, mas nunca terminou". O segundo projeto começa tarde ou mesmo não !

Ao recursos de divisão, você evitar este problema. Se tudo correr bem com o segundo projeto, você é capaz de entregá-lo depois de 6 meses, não importa quão bem o primeiro projeto faz.

As situações da vida real, onde trabalham em vários projetos pode ser uma vantagem é no caso em que a especificação não é clara (cada vez) e o cliente é muitas vezes indisponíveis para esclarecimentos. Nesses casos, você pode simplesmente mudar para outro projeto. Isso fará com que alguns alternância de tarefas e deve ser evitado em um mundo perfeito, mas mais uma vez ...

Esta é basicamente a minha vida profissional em poucas palavras: -)

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow