Um ciclo de seis semanas de trabalho, seguido de duas de pausa para ajustes, cabe oito vezes num ano. Murilo Alencar, board member e Tech, People & Game Strategist, comenta que é esse o ritmo de parte das empresas de software que trocaram cronogramas longos por ciclos fixos. O detalhe mais útil desse modelo não é a duração do ciclo, mas o que acontece quando ele termina.
Se o projeto não fica pronto em seis semanas, ele não ganha prorrogação automática. Volta para a prancheta. A regra parece dura, e é, mas inverte uma lógica comum na gestão de tecnologia: em vez de mover a data, corta-se escopo. A seguir, abordaremos como aplicar essa inversão em quatro etapas.
Defina quanto tempo o problema merece
Uma equipe recebe o pedido de criar um sistema de notificações. A pergunta habitual é quanto tempo isso leva, e a resposta costuma crescer à medida que surgem detalhes. A gestão por ciclos fixos faz a pergunta ao contrário: quanto tempo esse problema vale para o negócio?
Essa resposta, para Murilo Moura Alencar, se chama apetite. Uma estimativa parte de um desenho e calcula o prazo; o apetite parte do prazo, duas ou seis semanas, e pergunta o que vale a pena construir dentro dele. Definido antes de o trabalho começar, ele serve de árbitro quando surgir a tentação de acrescentar “só mais uma coisa”.
Desenhe a solução em traço grosso antes de entregar
Com o apetite definido, alguém mais experiente esboça a solução no nível certo de detalhe: o bastante para mostrar os elementos principais e o fluxo entre eles, sem chegar a telas finais. O esboço aponta também os buracos conhecidos, aquelas partes que podem engolir semanas se ninguém as delimitar.
O objetivo é entregar à equipe um trabalho aproximado, resolvido nos pontos críticos e com limites claros. Detalhar demais tira da equipe a chance de decidir. Detalhar de menos deixa riscos escondidos para a quinta semana. Nas equipes que adotam o modelo, essa preparação costuma ocorrer em paralelo ao ciclo em andamento, conduzida por quem não está programando naquele momento.
Termine uma parte de ponta a ponta primeiro
Uma equipe que passa quatro semanas construindo telas, banco de dados e regras de negócio em separado chega à reta final com muita tarefa concluída e nada que funcione. A gestão por ciclos recomenda o caminho oposto: integrar design e programação cedo e entregar uma fatia pequena, porém completa, que alguém consiga clicar e testar.
A ordem também importa. As partes mais desconhecidas vêm primeiro, porque são elas que escondem a complexidade capaz de estourar o prazo. Deixar o incerto para o fim é a forma mais comum de descobrir tarde demais que o apetite não bastava.
Corte escopo quando o prazo apertar
Aqui entra a regra conhecida como disjuntor. Se o projeto não fica pronto no ciclo, por padrão ele não recebe extensão. Em vez de reinvestir num caminho que não funcionou, a liderança trata o atraso como sinal de que algo foi mal avaliado no desenho ou no tamanho da aposta.
Para a equipe, o efeito é prático. Saber que não haverá prorrogação obriga a decidir, ao longo das semanas, o que é essencial e o que pode ficar para depois. É o tipo de escolha que Murilo Alencar considera responsabilidade de quem executa, e não só de quem planeja.
O prazo como ferramenta de decisão
Em muitas empresas, o prazo funciona como instrumento de cobrança e existe para apontar quem atrasou. No modelo de apetite, ele vira instrumento de escolha, porque obriga liderança e equipe a dizer em voz alta quanto cada problema vale. Cortar escopo com critério, nesse sentido, é menos uma técnica de projeto e mais uma forma de respeitar o tempo de quem constrói.
Essa mudança, na visão de Murilo Moura Alencar, toca tanto a tecnologia quanto as pessoas. Assim, conclui-se que equipes que conhecem o limite do investimento tendem a trabalhar com mais autonomia e menos desgaste, já que a solução passa a caber no tempo disponível, e não o contrário.