Projetos
Prazos que se cumprem: planear com quem executa
Esforço não é duração, e uma lista de tarefas com datas não é um plano enquanto ninguém verificar quem as faz. Como estimar com quem executa e onde escrever a margem.
5 min de leitura
Um prazo é uma promessa sobre o trabalho de outra pessoa. Quando é dado sem essa pessoa por perto, é uma previsão feita com informação que quem a faz não tem — e o desconforto disso aparece semanas depois, quando a data chega e o trabalho não.
Não é falta de rigor de quem vende nem má vontade de quem executa. É uma conta feita com os números errados: o esforço de um lado, a capacidade do outro, e as duas coisas trocadas uma pela outra sem ninguém dar por isso.
Esforço e duração são contas diferentes
Oito horas de trabalho não são um dia. São oito horas distribuídas por dias que já têm outra coisa dentro. Quem estima responde à pergunta «quanto tempo leva?» com o esforço, porque é a única parte que sabe medir; quem ouve a resposta registou duração.
Imagine um técnico que diz «dois dias» a pensar em dezasseis horas de trabalho concentrado. Está em três projetos, tem duas reuniões por semana e é a pessoa a quem os outros perguntam coisas. As dezasseis horas espalham-se por duas semanas e meia. Nenhum dos dois mentiu, e a data vai falhar.
A correção é de vocabulário e faz-se numa pergunta: quantas horas de trabalho tem isto, e a partir de que dia é que essas horas cabem na agenda de quem as faz? São duas respostas, e são as duas que o plano precisa. Uma estimativa que só tem a primeira está a esconder a segunda em vez de a calcular.
A capacidade da equipa é a parte que ninguém escreve
Uma lista de tarefas com datas não é um plano enquanto ninguém verificar quem as faz. Passa a ser uma lista de desejos organizada por semanas — e lida projeto a projeto, cada uma delas parece perfeitamente razoável.
O problema aparece quando se olha de lado: o mesmo técnico está em três planos na mesma semana, e cada plano está certo sozinho. Ninguém errou, porque ninguém conseguiu ver os três ao mesmo tempo. Uma empresa com duas pessoas especializadas e seis projetos a decorrer não tem um problema de estimativa, tem um problema de carga, e a carga não se resolve com estimativas melhores.
Ver a disponibilidade de quem executa ao lado das tarefas — que é o motivo por que o módulo de Projetos trata equipas e planos no mesmo sítio — resolve metade das derrapagens antes de existirem. E obriga a uma conversa que se evita: nem toda a capacidade é intercambiável. Duas pessoas livres não substituem a pessoa certa ocupada, e um plano que faz essa troca no papel está a inventar um recurso.
Os prazos que dependem do cliente, e que ninguém escreveu
Uma parte do plano não é executada por nós. Precisa de uma aprovação, de um acesso, de conteúdos, de uma decisão que só uma pessoa pode tomar. Essas peças costumam entrar no plano como se fossem instantâneas: a tarefa seguinte começa no dia seguinte, porque assumimos que a resposta chega no mesmo dia.
Escrever as dependências do lado do cliente, com data e com nome, muda duas coisas. Muda a data final, que passa a ser honesta. E muda a conversa do fim do projeto, porque quando um pedido escorrega vê-se logo o que é que escorregou atrás dele, em vez de se discutir em agosto quem esperava por quem em junho. É a mesma informação que serve para o que se mostra ao cliente durante a execução: o que está à espera dele tem de ter nome e data desde o primeiro dia.
Margem escondida em cada estimativa, ou escrita uma vez
Quem foi apanhado uma vez acrescenta gordura a cada estimativa e não diz que o fez. Quem recebe as estimativas, sabendo disso, corta uma percentagem. A conta é feita duas vezes ao contrário e o resultado não tem relação com o trabalho: tem relação com o histórico de desconfiança entre as duas pessoas.
O caminho alternativo é desconfortável e é o único que sobrevive a uma negociação. Estimativas honestas, sem almofada, e uma margem explícita ao nível do projeto, com um dono. Escrita assim, a margem pode ser discutida: quanto é, para que serve, em que condições se usa. Escondida dentro de vinte estimativas, não pode ser discutida nem defendida, e desaparece toda na primeira reunião em que o cliente pedir uma semana.
O paralelo com a previsão de vendas é exato, e é útil dizê-lo em voz alta numa empresa que já tem esse problema resolvido: um número sozinho nunca diz em que se baseia, e um número que todos corrigem de cabeça não é uma previsão.
Uma estimativa é uma conversa, não um número
As duas perguntas que melhoram mais depressa a qualidade de um prazo não pedem números. Pedem condições: o que é que teria de correr bem para isto ser dois dias? E o que é que faria disto duas semanas?
As respostas dão um intervalo em vez de um ponto, o que já é melhor. Mas o que interessa mesmo é o que vem no meio: a lista das coisas que podem correr mal. Essa lista é a razão por que a pessoa hesitou antes de dizer o número, e normalmente nunca chega a quem promete o prazo ao cliente.
Comece por um projeto a decorrer. Junte quem o executa, percorram as tarefas das próximas quatro semanas e digam as datas em voz alta, uma a uma, com a agenda real de cada pessoa aberta. Não é um exercício de planeamento: é um exercício de descobrir quantas das datas atuais ninguém tinha confirmado com quem as vai cumprir. Depois, traga esse plano ao diagnóstico — percorremos o caso e separamos o que se resolve com visibilidade de carga do que exige uma decisão sobre prioridades que só a empresa pode tomar. Se o plano já estiver a escorregar, o sítio onde se vê primeiro é o assunto seguinte.