Ao calcular o termo do projeto, tradicionalmente avaliamos a duração das etapas intermediárias, depois as resumimos e adicionamos um buffer para todos os tipos de acidentes. Então a liderança nos corta esse período pela metade. Como parte desta nota, o autor estará interessado em nossos cálculos, porque mesmo um gerente de projeto com vasta experiência muitas vezes entende que o período calculado é muito curto e muito, às vezes às vezes, em desacordo com sua avaliação pessoal especializada. Sim, ele corrigirá as estimativas dos termos do projeto e as etapas intermediárias para sua avaliação de especialistas e, com verdadeiro domínio de algum processamento, cumprirá o prazo com uma precisão de 15%, mas o sedimento permanecerá.
Esta nota explica o motivo da discrepância entre estimativas de especialistas e estimativas calculadas teoricamente. Também é considerado por que a avaliação de especialistas "superestimada" geralmente é subestimada se não for feita com base em estatísticas sobre a implementação de projetos semelhantes. No final, é revelado como calcular corretamente o termo do projeto e explicar a situação às partes interessadas antes do início ou durante o projeto.
A raiz do erro
Quando avaliamos o período de implementação de uma obra, determinamos o número mais provável. Pode ser uma avaliação de especialista em um ponto ou em três pontos, como no PERT. Em um projeto complexo, isso pode ser modelagem paramétrica. Em todos os casos, cometemos o mesmo erro. O fato é que, em todos os métodos clássicos de estimativa, assume-se que temos uma distribuição normal do valor estimado - de acordo com Gauss. Os teóricos gostam muito dessa distribuição.
A distribuição normal significa que um projeto com uma duração estimada corretamente de 6 meses tem a mesma probabilidade de concluir em 9 meses ou 3 meses. A distâncias iguais do centro de distribuição, a probabilidade de conclusão do projeto é igual - esse é um recurso da curva de Gauss. Por outro lado, na prática, poucos viram um projeto de TI concluído duas vezes mais rápido (após 3 meses), mas projetos que são atrasados uma vez e meia em termos (9 meses) que vemos regularmente. Além disso, com uma distribuição normal, metade dos nossos projetos terminaria antes do tempo estimado e depois metade. Mas isso também não é observado na prática. Isso sugere que a distribuição normal para estimativa de prazos não é aplicável. Ou seja, não temos uma distribuição normal, mas alguma outra, com probabilidade de conclusão diferente antes e depois da data mais provável.
Considere a distribuição lognormal como um exemplo dessa distribuição. Ele nos mostrará os recursos dessa classe de distribuições. Para a distribuição lognormal, as expectativas mediana e matemática estão significativamente além do pico:
No gráfico apresentado, o pico mostra a maior probabilidade da data de conclusão do projeto.Esta figura geralmente inclui essa figura mais uma certa margem. A mediana indica um ponto de separação no qual metade dos projetos será concluída antes deste prazo e na segunda metade depois. Expectativa matemática indica o valor médio da duração do projeto. Para um fragmento de trabalho, a distribuição terá os mesmos recursos: uma grande diferença entre o período de tempo mais esperado para a implementação do fragmento de trabalho (os planos são tradicionalmente baseados nele) e o valor médio do termo.
Para prever a duração do projeto, determinamos a cadeia mais longa no tempo e adicionamos a duração de seus fragmentos. Se somarmos os valores distribuídos de acordo com Gauss, então, em média, o termo final correto deve ser obtido. De fato, metade dos fragmentos do trabalho será concluída antes do prazo, metade depois e essas heterogeneidades se anularão. Quanto mais fragmentos, maior a precisão das compensações. Além disso, podemos calcular o erro e alterar levemente o prazo final por um sigma ou dois, dependendo das consequências do prazo final.
Mas não temos uma distribuição gaussiana. Em nosso país, prolongar o tempo de execução de cada obra é muito mais provável do que reduzi-lo na mesma quantidade. Como resultado, se adicionarmos os prazos para a conclusão mais provável de cada obra, as heterogeneidades em termos de conclusão não serão compensadas, mas amplificadas. Além disso, eles se intensificam no sentido de prolongar o prazo médio real do projeto em comparação com a estimativa. O que observamos na vida real: se o primeiro termo estiver vencido, todos os outros termos estarão vencidos, enquanto o atraso apenas aumentará. Somente aplicando esforços adicionais o atraso do projeto pode ser interrompido.
Uma característica desse método de cálculo é um fato bem conhecido: quanto menor a fragmentação do trabalho para avaliar a duração do projeto, menos precisa é a estimativa. Embora em teoria deva ser exatamente o oposto. A razão para isso é que nossa avaliação de especialistas para todo o trabalho e suas partes constituintes é extraída da experiência. A experiência avalia cada elemento independentemente, e não com base na aritmética, segundo a qual a duração do trabalho deve ser a soma das durações de suas partes constituintes. A aritmética não funciona aqui, pois a soma dos prazos mais prováveis para a conclusão de peças não fornece o prazo mais provável para a conclusão de todo o trabalho - apenas as expectativas matemáticas podem ser somadas corretamente.
Se tentarmos mudar levemente o termo estimado para o projeto inteiro ou suas partes por um sigma ou dois, considerando a distribuição normal, isso não ajuda muito, pois a cauda da distribuição é muito mais espessa que a curva gaussiana. Como resultado, devido a esse aumento na estimativa do prazo, não é possível nem chegar à mediana, sem mencionar o valor médio da duração do projeto na forma de expectativa matemática.
O que fazer
Por um lado, as expectativas matemáticas devem ser adicionadas. Por outro lado, não somos matemáticos. Somos da vida real e entendemos o problema de calcular os parâmetros dos gráficos, mesmo quando há tempo para isso e algumas estatísticas acumuladas. Mas existem outras maneiras. No final, o problema de avaliar o tempo de mais de uma dúzia de anos e a prática aprendeu a trabalhar com ele.
Método Brooks : consideramos o período de implementação do programa "frontal" (o usuário é o próprio programador) e multiplicamos por 3 para o produto de software (o usuário é um círculo ilimitado de pessoas) ou o complexo de software (nas realidades atuais - um conjunto de microsserviços) e 9 para o produto de software do sistema ( nas realidades atuais, um conjunto de componentes de infraestrutura relacionados). A origem desses coeficientes é teoricamente justificada no primeiro capítulo do livro de Mythical Man-Month, de Brooks, e essa descrição de 1975 é bem alterada para as realidades atuais.
Método Scrum : introduzimos uma unidade intermediária abstrata da complexidade da implementação do funcional, olhamos para as estatísticas da implementação do funcional medido nas unidades dadas do funcional, pedimos à equipe que avalie a complexidade das tarefas do projeto, traduza as unidades na iteração Scrum (sprints) de comprimento conhecido e obtenha uma estimativa dos termos para essa equipe de desenvolvimento. Como trabalhamos com estatísticas realmente coletadas e a equipe é responsável por suas estimativas da complexidade, a vinculação da duração à unidade de trabalho é uma expectativa matemática e, portanto, metade dos sprints terminará um pouco mais cedo, meio pouco depois. Na prática, na metade das iterações do Scrum, a equipe precisará participar das tarefas e, na metade, adicionar as não planejadas, para que o comprimento do sprint permaneça constante.
A tarefa de transferir a Avaliação Scrum de uma equipe para outra é uma arte. Eles não podem ser transferidos simplesmente introduzindo um fator de conversão para as unidades de trabalho de uma equipe nas unidades de trabalho da outra equipe. O fato é que uma equipe possui um bom front-end em sua composição, mas não possui um bom especialista em base, e a outra equipe possui um bom especialista em base, mas as tarefas de linha de frente para ele são de maior complexidade. As diferenças na especialização dos desenvolvedores levarão ao fato de que, com relação às tarefas de back-end, uma equipe terá um excesso de complexidade em relação às tarefas no banco de dados e a outra na frente. Além disso, a própria equipe determina o nível necessário da qualidade interna do produto e diferentes equipes o determinam de uma maneira ligeiramente diferente das equipes vizinhas, o que também dificulta o recálculo das unidades de trabalho. Ou seja, é possível converter as unidades intermediárias de uma equipe nas unidades intermediárias de outra equipe, comparando estimativas de tarefas semelhantes, mas essas tarefas devem ser tiradas de diferentes tipos de atividades, levando em consideração os pontos fortes e fracos das equipes e levando em consideração as peculiaridades da criação do Scrum.
Método dos elementos funcionais : introduzimos uma unidade intermediária de trabalho, compilamos uma lista de elementos funcionais (telas em um navegador, microsserviços, elementos de infraestrutura personalizados, etc.), estimamos a laboriosidade do trabalho em cada elemento funcional em unidades intermediárias. Depois disso, com base em nossa experiência de trabalho com uma equipe de desenvolvimento específica, avaliamos o fator de conversão da unidade intermediária ao longo do tempo. Pessoalmente, ainda avalio independentemente os fatores de conversão para diferentes tipos de atividades: análise, design, gravação de instruções de tarefas, código de escrita, layout, teste, integração etc. Depois disso, a ordem das operações, o tempo de atraso característico entre a conclusão da operação anterior e o início de uma nova devem ser levados em consideração e a duração do projeto deve ser determinada pelo método do caminho crítico.
Até o momento, trabalhamos com os fatores internos do projeto. Mas também temos externos: contratados externos, departamentos relacionados, fornecedores e cliente. Os problemas com eles são exatamente os mesmos: eles respondem duas vezes ou mais rapidamente ou menos frequentemente do que uma vez e meia mais que o valor mais provável. Ou seja, também não há distribuição de tempo normal. Isso também deve ser estabelecido e levado em consideração com base em estatísticas sobre o trabalho com clientes, contratados e unidades relacionadas e, se possível, ser protegido com a ajuda de sanções.
Justificativa de tempo
E assim, estimamos a duração projetada do projeto. Como justificar o prazo recebido? Com base nos cálculos feitos. Por exemplo, o autor de uma observação para projetos que não sejam Scrum geralmente cria uma grande tabela visual de várias linhas no Planilhas Google com um cálculo detalhado pelo método de elementos funcionais. O cálculo é baseado na prática, todos os coeficientes e parâmetros são visuais, e a prática para as partes interessadas geralmente é um argumento forte e bom, mesmo que seja um período desconfortável para certos indivíduos. Especialmente a prática é visual e obtida dentro da estrutura da empresa atual.
As partes interessadas, como a gerência, concordarão com uma avaliação de cronograma bem-feita e bem informada? Nem sempre, mesmo que as partes interessadas compreendam e compreendam plenamente que a avaliação está correta. Às vezes, a avaliação é inaceitável por razões externas, mas isso já é uma dor para as partes interessadas, resultando em uma decisão difícil por parte da gerência sobre o momento. No entanto, vendo os cálculos baseados na experiência, a gerência e outras partes interessadas têm a oportunidade de influenciar previsivelmente o prazo final do projeto, alocando recursos e poderes adicionais. Às vezes, a gerência que entende a situação do momento continuará a cortar prazos sem alocar recursos e autoridade adicionais. Como viver com isso é o tópico de uma nota separada.