Como podemos planejar projetos de maneira realista, considerando problemas de suporte?

Estamos com um problema no trabalho: estamos tentando agendar o trabalho para que possamos avaliar escalas de tempo e obter datas de prazo.

O problema é que é difícil planejar um projeto sem saber tudo o que vai acontecer.

Por exemplo, no momento planejamos todos os nossos projetos até o início de dezembro, mas nesse período teremos várias reuniões internas e externas, teleconferências e trabalho extra. É bom dizer que um projeto levará três semanas, mas se houver uma semana de interrupção nesse período, a data de conclusão será adiada uma semana.

O problema é 3 vezes:

1. Quando agendamos projetos, as escalas de tempo são tomadas literalmente. Se estimarmos três semanas, o prazo é estabelecido para três semanas, o cliente é informado e não há espaço para extensão.

2. Trabalho intermediário e isso significa que perdemos tempo produtivo trabalhando no projeto.

3. Às vezes, os clientes não têm o tempo necessário para realizar o trabalho, então, às vezes, vêm até nós e dizem que precisam de um projeto feito até o final do mês, mesmo quando pensamos que o trabalho levará dois meses - para não mencionar que já temos trabalho a fazer.

Temos um gráfico de Gantt que estamos tentando preencher com todos os projetos que temos e preenchemos os quadros de horários, mas eles não são comparados ao gráfico de Gantt. Isso dificulta dizer "Bem, agendamos três semanas para este projeto, mas perdemos uma semana aqui, portanto o prazo precisa voltar uma semana".

Também não é profissional manter a falta de prazos que comunicamos ao cliente.

Como as outras pessoas lidam com esse tipo de situação? Como você gerencia o planejamento de projetos? Quanto tempo "extra" você agendar em um projeto para contabilizar o trabalho que não é do projeto que ocorre durante um projeto? Como você lida com problemas de suporte, bugs e outras coisas? Coisas que você não pode explicar durante o planejamento?

ATUALIZAR

Muitas boas respostas, obrigado.

O problema é que é difícil planejar um projeto sem saber tudo o que vai acontecer.

Esse é o objetivo do gerenciamento de riscos. Como você não pode saber tudo, planeje com base no que sabe e identifique quais coisas podem ter mais impacto no seu plano e qual a probabilidade de que isso aconteça. Avalie também o impacto potencial do cronograma, dizendo que, se X acontecer, ele fará com que o cronograma caia em um número estimado (palavra-chave - estimado) em Y dias ou semanas.

Está tudo muito bem dizendo que um projeto levará 3 semanas,

Nunca dê uma estimativa tão específica. Indique um intervalo ou quantifique a probabilidade de atingir essa estimativa. Por exemplo, diga "este projeto levará de 2 a 5 semanas" ou "há 85% de chance de o projeto ser concluído em 3 semanas e 95% de chance de ser realizado em 4 semanas".

Também não é profissional para o cliente continuar dizendo que perdemos um prazo.

Verdade. No entanto, você está misturando os conceitos de "estimativa", "cronograma" e "prazo". Sua estimativa é uma aproximação de quanto tempo levará para concluir uma determinada tarefa ou projeto e a probabilidade de alcançá-lo. O prazo final é uma data imposta pelo cliente na qual o projeto deve ser realizado para agregar valor. O cronograma é como você usa seus recursos disponíveis para cumprir seu prazo.

Há momentos em que simplesmente não é possível concluir o trabalho atribuído dentro de um prazo e todas as estimativas e agendamentos no mundo não farão diferença.

Então, minha pergunta ... como outras pessoas fazem isso? Como você gerencia o planejamento de projetos? Quanto tempo "extra" você agendar em um projeto para explicar tudo o que acontece nesse meio tempo?

Recomendo a leitura de dois livros, ambos de Steve McConnell: Estimativa de software: Desmistificando a arte negra e Desenvolvimento rápido: domesticando agendas de software selvagens . Estimativa de software é elaborar suas estimativas, apresentá-las aos clientes e alguns aspectos da negociação e lidar com expectativas irreais. O Rapid Development é o gerenciamento geral de projetos, que lida com os ciclos de vida, cronograma, alocação de recursos e como melhor programar e orçar projetos para atender às suas estimativas e prazos.

Eu sugeriria cavar os detalhes do processo de desenvolvimento do Scrum . Abrange essas atividades de desvio pela focus factormétrica. Basicamente, você deve trabalhar de 2 a 3 sprints / iterações e depois medir o fator de foco de sua equipe (e para cada membro também seria útil). Depois disso, você poderá fornecer estimativas mais precisas que abrangem a atividade diária.

Dê uma olhada neste artigo - "O fator de foco"

Se algum de vocês conhece o desenvolvimento Agile, provavelmente já ouviu falar do fator de foco (ou fator de produtividade). É usado para planejar para ajudar a determinar quantas "horas reais" você precisa trabalhar em alguma coisa. É a diferença entre "horas reais" e "horas ideais".

O problema das interrupções é que, para determinados indivíduos ou equipes, elas tendem a ocorrer dentro de um intervalo relativamente pequeno de probabilidades. Por exemplo, você tem o mesmo número de reuniões todas as semanas, ou o mesmo número de horas gastas em correções urgentes todos os meses, ou o mesmo tempo gasto respondendo perguntas para as pessoas que visitam sua mesa, especialmente quando a média é maior. um longo período de tempo.

Muitas técnicas modernas de agendamento levam isso em consideração. O Scrum o fator em velocidade. O planejamento baseado em evidências também usa uma velocidade com um intervalo de confiança para qualquer estimativa. Pomodoro leva em consideração as interrupções ao decidir quantos "pomodoros" você pode concluir em qualquer semana. Tudo isso depende do rastreamento das medições históricas de suas interrupções e da sua contabilização em suas estimativas. Eu recomendo que você dê uma olhada em todos eles e crie uma técnica que funcione para sua equipe.

Bons conselhos por toda parte.

Outra coisa que pode ser útil para lidar com problemas de suporte é dedicar pessoal para o suporte em uma base fixa "round-robin".

Por exemplo, se você tiver cinco desenvolvedores, atribua um a cada dia da semana. Quando esse dia chegar, o desenvolvedor designado trabalhará apenas para esse dia com suporte. No dia seguinte, outro desenvolvedor assume o suporte. Dessa forma, todo mundo tem a chance de permanecer no seu "fluxo", todo mundo experimenta a comida para cães.

Como você REALMENTE escolhe dividir o trabalho de suporte regular não importa realmente (o rodízio diário dos dias da semana é apenas um exemplo). O que importa é limitar o tempo de suporte a intervalos regulares fixos. Isso torna o tempo de desenvolvimento mais previsível com o trade-off de que você não pode ter "todo mundo descarta tudo" para lidar com problemas de suporte.

Essa é uma habilidade que realmente vem com a experiência, e muitas vezes as pessoas são perguntadas antes que possam julgar com precisão uma coisa dessas. Sempre trabalhei em um grupo bastante unido com um estilo informal, mas desenvolvemos algumas regras práticas que pareciam se manter bem.

Primeiro, nenhuma tarefa leva menos de uma semana. Sempre faça uma estimativa em semanas, mesmo que uma tarefa pareça demorar alguns dias para ser realizada. Haverá algum motivo para que isso não seja feito antes do final da semana.

Segundo, faça o possível para estimar o tempo que a tarefa levará, incluindo interrupções, problemas de suporte ao cliente, passando por testes etc. Agora, duplique esse número. Essa é a sua estimativa (em semanas).

Terceiro, verifique se o seu gerente ainda não está adicionando algum preenchimento às suas estimativas. Nossa equipe teve um gerente reclamando de nossas estimativas. Acontece que ele já o multiplicaria por 2,1 (sua estimativa de preenchimento empiricamente derivada) e já tínhamos dobrado antes de contar a ele.

Não é uma ferramenta sofisticada e pode não ser um método perfeito, mas funciona surpreendentemente bem.

As pessoas que fazem a necessidade de estimativa de entender que nenhuma equipe é sempre 100% em um projeto. Você tem licença médica, férias, dever de júri, licença de luto, reuniões de RH necessárias (é hora de benefícios!), Reuniões de equipe que não são relacionadas ao projeto, atraso inevitável, intervalos no banheiro, trabalho de suporte em itens já em produção, tratamento de e-mails, , configurando o novo computador após a morte do antigo, respondendo a perguntas sobre trabalhos futuros e fazendo estimativas para esse trabalho, orientando juniores etc. que precisam ser levados em consideração. É irresponsável que um estimador assuma mais de 6 em 8 horas disponível por dia. Isso é uma garantia de que o prazo não pode ser cumprido. Se você está garantindo que o prazo não pode ser cumprido, está garantindo um cliente insatisfeito.

Você está absolutamente correto - é difícil planejar um projeto sem saber tudo o que vai acontecer. Mas é muito importante acompanhar as coisas que são uma norma, bem como as tarefas que você prevê. Aqui é onde o gerenciamento de agendamento desempenha um papel. Eu tenho usado o gerenciamento de projetos da Microsoft (versão padrão) para o qual também inclui recursos que fazem parte de um software de agendamento de gerenciamento de projetos.

Você pode visitar http://www.microsoft.com/project/en/us/schedule-management.aspx para obter mais informações.

Parece que há muito esforço oculto de suas equipes de projeto através do qual você está perdendo o foco e a velocidade. Pode ser benéfico separar realmente a tarefa de lidar com

..os problemas de suporte e bugs e outras coisas?

para um grupo específico de pessoas, para que os outros membros da equipe possam se concentrar nas novas tarefas de desenvolvimento. Com isso, sua produção geral pode cair um pouco, mas a qualidade melhorará porque há menos distração. Isso, em troca, reduzirá o número de bugs, portanto, um trabalho a hoc que entra nos seus projetos.

Quanto à parte do planejamento, concordo plenamente com a resposta de Thomas Owens.