Gerentes de projeto em todo o mundo lutam com este problema. Quanto detalhe é suficiente no meu plano de projeto?
A maioria dos gerentes de projeto erro ao lado de tarefas de alto nível. É mais fácil de fazer no começo, todos podem concordar sobre ele, e é fácil de obter estimativas.
É também, infelizmente, o que leva a problemas. Digamos, por exemplo, que você tem uma implementação de um cliente que chama para o desenvolvimento de cinco partes de funcionalidade. Você coloca em uma tarefa de desenvolvimento e tarefas de testes adequadas para cada peça e, em seguida, colocar em uma tarefa de implantação no final. Que deve ser suficiente para a parte de desenvolvimento, certa? Você tem suas estimativas de tarefas de desenvolvimento de quatro em quatro horas cada, e um pedaço maior-que vai levar uma semana. Multa. Você seguir em frente.
Avanço rápido de um mês. A tarefa de uma semana levou três semanas. Testes tem sido uma dor. Ele voltou para correções cinco vezes agora. Seu prazo é completamente tiro, e ninguém pode dar-lhe uma data bem definida sobre quando você vai ser feito.
O que deu errado? A estimativa original era ruim?
Eu diria que a estimativa original método foi ruim.
Desenvolvimento de software moderno não é como se fosse nos dias de outrora. Não há nenhum programa monolítico (na maior parte) mais que leva semanas e semanas para escrever a coisa única, sem degraus entre. Na realidade, essa tarefa de uma semana descrita acima provavelmente consiste de uma série de sub-tarefas, como:
- criar tabelas de banco de dados
- criar objeto X
- construir o método 1
- construir o método 2
- etc
Obviamente, não quer gerenciar micro. Você também não quer exagerar gerenciamento de lista de tarefas. Eu diria, no entanto, que qualquer determinada tarefa deve abranger não mais do que um dia em seu plano. Se isso acontecer, então você precisará decompô-lo em sub-tarefas. Por que fazer isso?
1. Quando quebrar a tarefa em subtarefas, frequentemente seu membro da equipe para executar a tarefa vai se tornar mais preciso em suas estimativas
2. Você pode mais efetivamente isolar tarefas de dificuldade para explicá-los e informar-se sobre eles. Quantas vezes você já teve essa discussão: você: "Bob está funcionando ao longo do desenvolvimento. Ele é uma semana de atrasada sobre o produto X." Exec: "que parte é que ele preso em?" Você: "Item X." Exec: "o que isso significa? Podemos obter-lhe ajuda? Quanto mais ele tem que ir?" Você: "Uhh..."
3. Você pode realmente obter a membros de sua equipe ajuda. Ficar com o exemplo do desenvolvedor: É o desenvolvedor ultrapassagem sobre o trabalho de banco de dados? Obter um DBA para ajudá-los. Eles estão presos em um método em um dos seus objetos? Talvez outro desenvolvedor pode completar outro objetos envolvidos na funcionalidade para você voltar à pista.
4. Você pode planejar em torno de operações diárias muito mais fácil. Se alguém tem um ops de duas horas de reunião na manhã de quinta-feira e uma chamada de conferência naquela noite, você pode confiantemente dizer que eles provavelmente não vai completar sua tarefa de dia inteiro naquele dia. Empurre o cronograma de um dia. Muito simples. Um rápido olhar sobre calendários dos membros de sua equipe diz que você e eles, tudo precisam saber.
4. Imagine quão feliz Membros de sua equipe será quando eles descobrir que eles tem um objetivo de um item por dia. Vêm para trabalhar, fazer isso até o final do dia. Sem planejamento, sem malabarismo, sem balanceamento. Você completa a sua tarefa e passar para o próximo. Simples.
5. Criar pontos de parada. Se o membro da equipe X tem que ser puxado para fora o projeto para uma coisa operacional durante dois dias, você pode simplesmente inserir que no meio de uma tarefa importante, soltando-a entre as subtarefas. Simples e elegante.
Recebendo a quantidade certa de detalhe permite acompanhar a quantidade certa e estimar a quantidade certa. Se uma tarefa consiste em cinco dias de tempo sub-tarefas, então quando três deles são concluídas, você está em algum lugar entre 60 e 80% completo. Uma vez que os membros da equipe aprendem que eles de repente não estão enfrentando o "qual é a porcentagem tem feito?" pergunta quase como muitas vezes, eles vai preferir seu método também.
Alguns membros da equipe não vão gostar deste método, porque eles têm de pensar com os detalhes. Eles sentirão que é enredo. Não é. Sendo solicitado a indicar no final do dia se você terminar o que você começou a fazer naquele dia, não é um grande negócio. Eu recomendo que você senta com eles e explica os benefícios do presente - eles têm um item de um relatório, simples sim ou não, no final de cada dia. Reuniões de status do projeto tornar-se simples ou inexistente. Eles podem obter ajuda quando necessário. Vendê-lo, no entanto, você deve, mas abraçar esse método. Seu projeto planos podem receber mais, mas acredite em mim, que vai ter mais precisas também.
