recuperação de desastre de software quando um engenheiro está subitamente indisponível

8

Recentemente, na minha empresa, tínhamos um projeto em que o prazo era muito curto e tudo corria conforme o planejado até que eu não estivesse disponível devido a problemas pessoais extremos.

Eventualmente, perdemos o prazo em 4 a 5 dias.

Quais são os planos de recuperação habituais para essas condições? minha empresa deve tentar terceirizar um desenvolvedor para concluir meu trabalho? mesmo isso poderia levar alguns dias para encontrar um?

project-management software deadlines

— xerife
fonte

3

Se sua parte do trabalho puder ser terceirizada sem treinamento ou transferência de informações, talvez você não esteja agregando muito valor. Porém, tipicamente, em um projeto bem gerenciado, é preciso permitir algum tempo de contingência (com base na duração do projeto, mas nunca menos de uma semana) para gerenciar riscos como esse.

— James McLeod

Por que não havia ninguém para terminar o trabalho?

— Euphoric

7

"Recentemente, em minha empresa, tínhamos um projeto em que o prazo era muito curto" - em outras palavras, (a) o gerente de projeto criou um prazo que não permitia que algo desse errado; e (b) o gerente de projeto era incapaz de prever quaisquer riscos (como um desenvolvedor ficar indisponível por um período de tempo, não exatamente uma circunstância exótica) e, portanto, não pôde planejar por eles. Parece que você precisa de um novo gerente de projeto, a menos que este possa aprender com seus erros.

— Kyralessa

4

@Kyralessa: Ou (c) o gerente de projeto foi forçado a retirar todos os buffers do planejamento porque alguém fez promessas irreais ao cliente. "Construir isso não pode ser tão difícil, então vamos prometer uma data de entrega antes de pedirmos aos desenvolvedores suas estimativas".

— Bart van Ingen Schenau

3

@BartvanIngenSchenau, em uma situação como essa, seu trabalho como gerente de projetos é recuar.

— Kyralessa

10

Depende da duração previsível da indisponibilidade, da duração restante do projeto, da maneira como as tarefas são distribuídas e das conseqüências da falta de prazos.

Os desenvolvedores de software não são intercambiáveis à vontade. Os desenvolvedores desenvolvem conhecimento sobre o sistema à medida que o sistema cresce, e a adição de um novo recurso requer o enfrentamento do conhecimento contextual ausente dos novos recursos.

Várias boas práticas reduzem os riscos associados à indisponibilidade repentina:

as revisões por pares garantem que o conhecimento sobre o desenvolvimento seja compartilhado entre vários desenvolvedores. Em caso de indisponibilidade, o restante da equipe pode se reorganizar para assumir o controle ou, na pior das hipóteses, trazer um novo codificador e organizar a transferência de conhecimento.
equipes colocadas integradas que trabalham juntas para tomar decisões de design podem reduzir a indisponibilidade da mesma maneira. O conhecimento compartilhado sobre o design geral facilita a redistribuição do trabalho e informações aos recém-chegados.
documentação formal poderia eventualmente ajudar. No entanto, na prática, isso funcionará bem apenas se a documentação produzida por um desenvolvedor for usada por outro desenvolvedor (ou modelos usados nas ferramentas de geração de código). A documentação que é lida apenas por si mesmo com frequência parece ser muito mais ambígua. Se um novo desenvolvedor tiver que assumir esse trabalho, a documentação própria pode levantar tantas perguntas quanto respostas.

Trazer novos desenvolvedores quando há prazos apertados é muito desafiador, porque informar os novatos leva tempo à equipe, em um período em que não há tempo livre. Se você estiver doente por uma semana, não faz sentido. Deve-se prever se o custo de informar os novatos é compensado pelos benefícios do novo recurso, normalmente se houver altos custos de atraso, ou se não for possível adiar, ou se a indisponibilidade for por um longo período de tempo.

— Christophe
fonte

1

Isso é bem próximo. O mais importante é garantir que alguém possa cobri-lo a qualquer momento.

— candied_orange

No gerenciamento de projetos, existe um conceito para esses casos. A planificação deve levar em conta esse tipo de situação. Agora é tarde demais para a empresa minimizar o impacto. Seja honesto com as partes interessadas e faça com que elas saibam que o prazo deve ser alterado. O cumprimento dos prazos não é quase nada comparado ao cumprimento das expectativas. Tentando evitar essa falta de planejamento, em detrimento da "qualidade", a solução pode ser mais cara do que você pensa ... Após o lançamento, há apenas uma "primeira impressão".

— LAIV

@ Laiv Obrigado pelo seu feedback. Não posso julgar se, neste caso, o prazo pode ser adiado ou não. No passado, eu gerenciei vários projetos críticos de introdução do ano 2000 e do EURO para os quais o adiamento não era uma opção. Mas concordo com você no princípio: é melhor discutir questões de prazo com o cliente quando o risco é alto, em vez de tentar encontrar secretamente uma alternativa impossível e falhar. A planificação da contingência é obviamente uma obrigação; mas, infelizmente, não é suficiente lidar com situações tão extremas (as reservas tendem a se esgotar no final do projeto).

— Christophe

Sim, é verdade. Não tenho visto muitos projetos em andamento, apesar do orçamento para contingências.

— LAIV

5

Os planos usuais para isso são incorporar contingência no prazo. As coisas acontecem, você geralmente nunca atinge os prazos. Você estar indisponível foi apenas mais um soluço nos planos cuidadosamente elaborados que nunca saem conforme o planejado!

— gbjbaanb
fonte

Você está completamente correto: todo plano precisa de algumas reservas de contingência para lidar com riscos. O problema com demasiada contingência, no entanto, é o efeito de profecia auto-realizável: no final, a contingência é consumida de qualquer maneira. E nas últimas semanas do plano, as pessoas ainda podem adoecer, embora não haja margem. Portanto, a contingência sozinha não é suficiente.

— Christophe

1

Na verdade, a contingência é uma estratégia de mitigação de risco, mas existem outras maneiras de lidar com o risco, incluindo removê-lo (garantir que outras pessoas possam assumir o controle sem afetar o cronograma), aceitá-lo (o padrão se você não gerenciar seus riscos) ou transfira-o (nesse caso, informe o cliente / cliente que eles não estão pagando o suficiente para garantir a entrega no prazo e precisam estar prontos para lidar com qualquer atraso).

— James McLeod

5

Isso é chamado de "fator de barramento". Basicamente, o risco representa o projeto se um desenvolvedor for atingido por um barramento. Ter um desenvolvedor indisponível por uma semana é um pequeno problema, comparado à perda permanente de um desenvolvedor. Pode ser um acidente ou uma doença súbita, mas, de maneira menos dramática, pode ser apenas um desenvolvedor central que muda de emprego em pouco tempo ou é demitido. Ou um desenvolvedor principal sendo transferido para outra tarefa de alta prioridade em diferentes departamentos.

Em resumo, você precisa planejar a redução do fator de barramento ou precisa estar preparado para atenuá-lo, por exemplo, tendo buffers nos prazos ou apenas ser flexível o suficiente para poder cumprir o prazo. O que você normalmente não pode fazer é terceirizar uma tarefa complexa em pouco tempo ou contratar um novo desenvolvedor - quase sempre levava mais tempo para introduzir um novo desenvolvedor em um sistema existente do que esperar uma semana para o desenvolvedor principal retornar. Se uma equipe pequena perde um membro, é claro que será mais lenta, mas se também for necessário introduzir um novo membro, será ainda mais lenta .

Você pode diminuir o fator de barramento, tendo uma equipe compartilhando conhecimento continuamente e revisões por pares (ou mesmo programação em pares). Mas é claro que isso é algo que precisa acontecer antes do ônibus chegar.

— JacquesB
fonte

2

Qualquer funcionário pode ficar indisponível por uma semana, um mês ou para sempre, sem aviso prévio, a qualquer momento. Acidente, doença, tendo tido o suficiente deste trabalho, muitas outras razões. Cabe à gerência garantir que essa ocasião seja irritante, talvez cara, mas não um desastre.

Se você tiver uma equipe de dez, poderá perder 10% da sua equipe. A empresa deve ser capaz de lidar com isso se o restante da equipe estiver motivado (pagar horas extras é altamente motivador). Se você é uma equipe de um, o trabalho não será realizado. Se você tiver outros funcionários que possam intervir, o atraso poderá ser minimizado. Seria difícil contratar alguém de fora, embora você provavelmente encontre um contratado que possa começar com alguns dias de antecedência por algumas semanas a uma taxa horária muito alta.

A melhor coisa a fazer é ter contratos, etc., para que um atraso no acabamento de um produto não seja um desastre financeiro. E ter uma data de término planejada e realizável muito antes do prazo. Ter funcionários que possam colaborar entre si ajuda (mas pode ser problemático de se conseguir).

E se você tem um prazo que deve ser alcançado, então talvez o escopo do trabalho é mais flexível. Em outras palavras, descarte os recursos para cumprir seu prazo.

— gnasher729
fonte

1

Uma maneira importante de reduzir o "fator de barramento" mencionado pelo @JacquesB acima é a programação de pares como uma técnica principal. (Minha própria prática é usar o termo "fator de loteria", pois é menos mórbido, mas o efeito é o mesmo.)

Muitos desenvolvedores odeiam a programação em pares; muitos gerentes também odeiam isso, por razões totalmente diferentes (alguns desenvolvedores odeiam ser forçados a se comunicar com outros seres humanos por longos períodos; alguns gerentes geralmente se sentem incorretamente como se estivessem pagando o dobro do dinheiro por uma única saída).

Porém, a programação em pares praticamente elimina o risco de um único ponto humano de falha, garantindo que qualquer tarefa de desenvolvimento seja executada e compreendida por pelo menos dois desenvolvedores.

— Jim Kiley
fonte

0

Existem várias maneiras de eu ver esse tipo de coisa tratada:

Compartilhe o trabalho

A coisa mais óbvia a fazer é compartilhar o trabalho entre os recursos existentes (supondo que isso seja possível). Como garantir que os desenvolvedores atinjam o terreno é quase uma resposta em si, mas, no final das contas, tudo se resume a registrar corretamente os requisitos, projetos e progresso. Coisas como programação em pares também podem ajudar bastante aqui.

Adiar o prazo ou tentar recuperar o tempo

Verifique com o cliente se o prazo pode ser estendido. Como alternativa, pode ser possível ganhar tempo adicional de desenvolvimento trabalhando à noite, fins de semana e feriados.

Abandone outras tarefas

Existem outras tarefas não críticas que podem ser temporariamente eliminadas para liberar espaço?

Adiante

Há algum trabalho planejado após o desenvolvimento que possa ser antecipado, como documentação, scripts de teste e configuração?

Admita que poderia ser tarde

Fale com o cliente mais cedo. Pode ser possível entregar em parte - ou, no mínimo, você pode ter uma orientação decente sobre as prioridades relativas de outras coisas.

Recurso adicional

Uma possibilidade - mas isso por si só traz riscos. Vai levar tempo para que eles sejam atualizados e, como são temporários, eles podem sair deixando você ainda pior.

Verifique o caminho crítico

Se outras partes estiverem envolvidas - verifique se elas ainda estão no alvo. Há pouco sentido em mover o céu e a terra para que algo termine, por exemplo, se a equipe de teste estiver com um mês de atraso em testar as coisas.

Aceitando as realidades do risco

Existe uma frase comum na profissão jurídica que afirma que problemas difíceis criam soluções ruins. Pode ser tentador fazer com que todos entendam tudo para cobrir todas as eventualidades. Isso, no entanto, é uma tarefa tola.

Os desenvolvedores devem gastar tempo de qualidade em seus próprios desenvolvimentos. Consumir uma quantidade cada vez maior de tempo tornando-se realidade com outros desenvolvimentos é uma atividade altamente questionável. Um meio termo razoável pode ser ter um especialista no assunto e um deputado.

— Robbie Dee
fonte