Todo mundo quer saber quanto tempo o projeto levará. Neste artigo, explicaremos como fornecer ao gerente uma previsão precisa e incerta ao mesmo tempo, usando tempos de ciclo e contando histórias, bem como conselhos sobre quando evitar estimativas por completo.

Celeste sentiu a pressão. Seu gerente Barry queria fazer uma previsão trimestral de sua equipe. A tarefa foi complicada pelo fato de o grupo de Celeste trabalhar em mais de um produto: Barry queria obter uma previsão para três de uma vez. Cada um deles fazia parte de um projeto diferente.

Os programadores do grupo Celeste não tinham informações suficientes para fazer pelo menos algumas previsões, especialmente para todo o trimestre.

Celeste decidiu confessar a Barry e ver o que eles vieram. Ela marcou uma consulta no dia seguinte e coletou dados.

A menina chegou ao escritório de Barry exatamente às 10 da manhã. Quando ela bateu na porta, Barry ainda estava falando ao telefone. Ele fez um gesto para ela entrar e levantou um dedo para deixar claro: ele estará pronto em um minuto.

Ela se sentou em uma cadeira de visitante em frente à mesa dele.

Barry desligou e virou: "Bem, vamos discutir o cronograma dos projetos, certo?"

Celeste assentiu e disse: “Sim. Parece ser o que pode ser feito em tal situação. ”

Barry franziu a testa. "Parece?" Eu preciso de compromissos específicos. Não "parece"! "

Celeste sentou-se confortavelmente: "Barry, você está sendo pressionado a lançar esses três produtos?"

"Como você descobriu?" - Barry balançou a cabeça. - Se você ouvir os caras de vendas e marketing, um desastre acontecerá se não os liberarmos agora. Não sei o que responder, exceto que tudo será. "

"Mas no mês passado, você discutiu um portfólio de projetos", lembrou Celeste. "Eu pensei que o produto A era a principal prioridade."

"É", ele disse. "E os produtos B e C também são prioridade máxima."

Celeste revirou os olhos: "Mas você sabe que só pode haver uma prioridade principal, certo?"

"Eu sei disso e você sabe", disse ele. "Mas meus colegas não sabem." Preciso de uma previsão do que você pode fazer - bem, obrigações - e então você pode respirar um pouco em silêncio. ”

“Em que produto devemos trabalhar?”, Perguntou Celeste.

"Produto A, é claro", disse ele. "Ele é o mais pago de volta."

"Bem, é isso que faremos", disse Celeste. "Estamos tensos e lançaremos A em um mês." Sua tarefa é fazer com que essas pessoas legais participem de nossas apresentações toda semana. Eles devem ver o que fazemos em uma semana. Se eles não comparecerem à demonstração, eu me recuso a fornecer qualquer informação. "

Barry recostou-se: - Espere. Eu entendi sobre a demo. E os outros dois meses? E por que você não lhes dá nenhuma informação?

Celeste disse: “Se trabalhávamos em apenas um produto, eu poderia calcular a classificação com base em nosso ciclo de desenvolvimento. Para o produto A, lançamos três a quatro histórias [código para tarefas personalizadas] por semana. Mas não conhecemos o ciclo de desenvolvimento real dos produtos B e C. "

Barry assentiu: "Por que não?"

"Os produtos B e C são planejados em dois e três meses", disse Celeste. - É muito longe para o marketing. O problema é que, quanto mais longe o trabalho, menos "tempo" o departamento de marketing trabalha com o proprietário do produto para esclarecer as histórias. Não temos idéia de quais funções precisarão ser implementadas em dois e três meses. Teríamos que fazer suposições cientificamente baseadas no zero (suposição científica, SWAG). Isso é normal, eu gosto de fazer isso com meus colegas, mas precisamos de mais detalhes. O que não é ".

"Então, por que você não conta nada se eles não comparecem à manifestação?" Perguntou Barry.

"Se não é importante para eles observar nosso progresso e fornecer feedback, eles não se importam muito com o tempo", disse Celeste. "Eles querem que nos comprometamos sem entregar nossas obrigações em troca." Por que devo gastar tempo avaliando se eles não querem contribuir? "

Barry concordou em "vender" a "caixa de tempo" mensal para os gerentes que o pressionavam a estabelecer prazos. Celeste garantirá que a equipe se concentre apenas no produto A. E ela agendou reuniões semanais para demonstrações, para que a equipe mostre seu trabalho e receba feedback.

Você ficaria tentado a fazer as coisas de maneira diferente?

Estimativa de termos - trabalho não trivial

Estimar prazos também é um trabalho. Muitas equipes colocam essa rotina em seu horário de trabalho regular. No entanto, uma estimativa trimestral precisa muitas vezes requer mais de uma hora ou duas de trabalho.

Há pelo menos dois problemas na avaliação do desempenho trimestral. Com muita frequência, os requisitos não são totalmente definidos e, como na equipe da Celeste, a avaliação desanexa a equipe do trabalho urgente no projeto.

O problema é que planejar o desenvolvimento de software não é como planejar uma viagem. Se sua cidade tiver mais de um semáforo, você estará familiarizado com as flutuações de tráfego. Eu moro em um subúrbio de Boston, de onde uma viagem ao aeroporto pode levar 20 e 90 minutos. Na maioria das vezes de 30 a 45 minutos. Essa é uma variação significativa para uma viagem de 13 km.

E não há inovação nessa viagem. Fui ao aeroporto várias vezes e conheço várias maneiras de chegar lá. Tenho aplicativos móveis que me ajudam a encontrar a rota mais rápida, mesmo ao longo do caminho. Embora algumas opções sejam um pouco mais previsíveis, nenhuma delas pode garantir que essa viagem em particular termine em 20 minutos.

A viagem ao aeroporto ocorre em uma rota pré-determinada e com obstáculos bem compreendidos. Mas o desenvolvimento de produtos é uma questão diferente. Isso é inovação. Em outras palavras, não fizemos nada assim antes. Caso contrário, não precisaríamos escrever um novo aplicativo ou atualizar um sistema desatualizado - usaríamos o antigo.

Para uma avaliação razoável, temos várias opções. Na verdade três:

• Você pode estimar a ordem de magnitude. Eu acho que isso é útil para todo o projeto. “Esperamos cinco a nove meses de trabalho. Saberemos melhor quando respondermos a essas perguntas e terminarmos esta parte do complexo trabalho. ” O SWAG é adequado para essas avaliações.
• Você pode reunir informações suficientes sobre os requisitos e fornecer uma estimativa razoável. A equipe pode precisar trabalhar com histórias de usuários para fazer uma previsão com uma dispersão relativamente pequena no tempo.
• Existe uma opção para avaliar o trabalho por um curto período, por exemplo, por uma semana ou duas. Pode acontecer que a previsão final não esteja totalmente correta. Mas geralmente está perto o suficiente do resultado para não decepcionar as pessoas que pediram para fazê-lo.

Que previsão você precisa para um gerente?

Percebi que os gerentes geralmente precisam de uma estimativa da ordem de magnitude. Nesse caso, a equipe pode fazer uma previsão e relatá-la da seguinte maneira:

“Acreditamos que este projeto levará cinco meses com 50% de confiança na precisão dessa previsão. Estamos 80% confiantes na avaliação de oito meses. Dez meses são 90% de confiança. ”

Isso ajuda os gerentes a entender que existe uma gama de confiança. Se eles querem 100% de certeza, isso pode levar mais de 14 meses.

Você pode usar o método espiral: “Focamos no primeiro trimestre do próximo ano. Não sabemos quando exatamente no primeiro trimestre, mas achamos que podemos lidar com isso. " À medida que o projeto avança, você especifica: "Estamos atualizando a estimativa para um período entre meados de janeiro e meados de março". Depois de aprender ainda mais, diga: "Em algum lugar de fevereiro, se uma nevasca não acontecer". Então, em janeiro, você pode dizer: "A terceira semana de fevereiro".

Eu também recomendaria um intervalo de três datas: “A data otimista é janeiro. O mais realista é o final de fevereiro. O mais pessimista é o final de abril.

De qualquer forma, nunca faça uma avaliação inequívoca. Ele tenta St. Murphy (da Lei de Murphy) para assumir seu projeto e fazer coisas desagradáveis.

Em alguns casos e em alguns comandos, o cliente pode exigir informações adicionais. Aqui você pode discutir com ele as funções específicas que estão sendo implementadas para entender as incertezas.

Use tempo de ciclo em vez de avaliação

Não gosto de previsões sobre o prazo de implementação de projetos de software ou outros projetos de TI, especialmente o Agile. Em vez disso, prefiro que a equipe divulgue histórias muito pequenas ou avalie o trabalho por tempo de ciclo.

Se você não estiver familiarizado com a terminologia:

• Histórias de usuários descrevem como um cliente ou usuário usa um produto para uma finalidade funcional ("Quero reservar um local" ou "Preciso publicar dados de cidades inteligentes para atender aos requisitos de transparência"). As histórias são diferentes das de um desenvolvedor que analisa um produto em termos de bancos de dados e APIs.
• O tempo do ciclo refere-se ao tempo total que uma equipe leva para liberar o trabalho em uma história. Isso inclui tempo de desenvolvimento ativo e tempo de inatividade quando o trabalho espera algo.

A idéia é entender o tempo médio necessário para produzir algo útil (história).

No caso de Celeste, ela sabia que uma equipe poderia produzir de três a quatro histórias por semana para o produto A. Para muitas equipes, a contagem de histórias funciona como outros métodos de avaliação.

Se a equipe nunca trabalhou em um produto semelhante, o tempo de ciclo anterior não será aplicável a este novo produto. A equipe pode não saber como refinar e dividir as histórias para produzir várias por semana. Além disso, ela pode não estar ciente do status do código e da disponibilidade de um número suficiente de testes. Se sua equipe trabalha em histórias há mais de três dias, não se preocupe em prever. Conte as histórias e não tente fazer mais do que o habitual.

Quando uma equipe começa a lidar com histórias em um ou dois dias, você também não precisa fazer uma avaliação. Geralmente, um cálculo simples é mais fácil e preciso.

Por que não usar velocidade?

Você notou que eu recomendo o tempo do ciclo e a contagem de histórias, em vez de acelerar a estimativa do tempo do projeto. Porque a velocidade é um substituto.

Por exemplo, eu ando todos os dias para manter a forma. Eu sigo a mesma rota todos os dias, rastreando minha velocidade relativa. Em um belo dia de sol, ando cerca de 5,6 km por hora. Em um dia chuvoso ou quente e úmido, a velocidade cai para 4 km / h. Na neve ou no gelo, não consigo sair de casa, neste caso minha velocidade é 0.

Eu estou indo na mesma rota. (Sim, é chato, mas é o meu problema). Embora eu percorra a mesma distância, a jornada leva tempos diferentes, dependendo das condições. Aqui as condições são semelhantes à base de código e aos testes de sua equipe.

Se as histórias forem pequenas o suficiente, a velocidade corresponderá ao tempo do ciclo. Mas, com muita frequência, os gerentes tentam avaliar projetos com histórias muito grandes. A contagem será mais simples: “Podemos terminar uma ou duas histórias em um ciclo. Qual ou duas histórias você quer escolher?

Recusar-se a avaliar não é uma farsa

Quando Barry discutiu questões com colegas, um deles disse: "Recusar-se a avaliar os prazos é uma farsa!"

Barry respondeu: “Não é verdade. Você quer que lançemos um produto, certo? ”

A resposta foi “Claro. B e C. "

"O problema é que eles precisam ser feitos por sua vez", respondeu Barry. - Se você realmente precisa do produto A, qual é o sentido de fazer uma previsão para o resto? Podemos começar a trabalhar e mostrar nosso progresso. Quando tivermos feito o suficiente, repetiremos o procedimento para B e C. Além disso, você terá tempo para esclarecer os requisitos de B e C para nos preparar as histórias. ”

A equipe de Celeste concluiu a maior parte do Projeto A em um mês. O lançamento do produto B levou mais tempo - mais perto de dois meses. E como a empresa recebeu renda suficiente com a liberação dos produtos A e B, reduziu a pressão sobre a liberação do produto C.

Saiba qual nota seu gerente precisa. Apresente-a como ele precisar. E se você tiver pouco tempo, comece a trabalhar.

Avaliação de projetos de TI: lições

• Não inclua números ou datas específicas. Em vez disso, forneça uma estimativa de ordem de magnitude com confiança em uma liberação oportuna. Ou sugira estimativas de curto prazo com base em fatores sob seu controle.
• Divida os objetivos do projeto em histórias de usuários que definem a funcionalidade do software. Em seguida, faça suas estimativas com base no número de histórias de usuários que você pode processar.
• Certifique-se de entender os requisitos antes de fazer qualquer compromisso.