Toda empresa de software já usa Scrum, Kanban, ITIL e algum tipo de discovery. O problema quase nunca é o método: é que cada time usa um pedaço diferente, ninguém sabe onde um termina e o outro começa, e o trabalho cai nas fronteiras. Este é o desenho que eu uso para resolver isso.
O Fonte-framework é um modelo operacional único para engenharia de software. Ele organiza dez metodologias de mercado, de Design Thinking e Lean Inception a Scrum, XP, Kanban, DevOps, SAFe, Lean IT, ITIL e ITSM, em um sistema coerente: rigoroso o bastante para governar a qualidade da entrega, leve o bastante para não virar burocracia. Nenhum dos dez foi inventado por mim. O que é meu é o desenho que faz os dez conviverem sem se atropelar.
O trabalho se organiza em três pilares permanentes. Descobrir reduz a incerteza antes de construir. Entregar produz com previsibilidade o que já foi validado. Operar sustenta o serviço em produção. Entre eles há três portas, que são os pontos onde alguém decide e registra a decisão. Acima, uma camada de governança define a direção e o que merece investimento. Abaixo, a esteira técnica e a cultura sustentam o resto.
A diferença em relação a um processo tradicional não está em um mecanismo só. Está em entregar em pedaços, em vez de guardar tudo para uma virada de chave no fim. Está em validar a hipótese antes de gastar engenharia com ela, porque o erro mais caro de um projeto é descobrir na entrega que ninguém queria aquilo. Está em controlar a cadência do time, de forma que o ritmo seja combinado e não descoberto no meio do caminho. E está em fechar o ciclo: o que a operação aprende volta para a descoberta, de 30 a 90 dias depois da entrega, que é o que separa uma organização que comemora entrega de uma que sabe se entregou valor.
Desenhei o modelo inteiro, a partir do que vivi: anos de acerto e de erro em projeto real, somados ao estudo dos métodos que já existiam. Respondo por ele na operação, e a parte difícil não é o desenho, é alocar o time certo para que ele funcione, com cada papel tendo valor real para entregar. Não é uma pessoa por papel: em time pequeno, o mesmo profissional acumula papéis, e é isso que permite o modelo servir tanto a uma squad quanto a uma estrutura inteira. Está em uso na engenharia da Sesatech.
Visão geral
Os três pilares
Correm em paralelo o tempo todo. Enquanto um item está sendo construído, outro já está sendo investigado, e um terceiro já está em produção pedindo melhoria.
Pilar 01 · Descobrir
Transforma um problema difuso em solução validada, com valor, escopo e viabilidade definidos. Começa por uma triagem que decide o que merece investigação, e termina num pacote curto de diretrizes, não numa especificação.
Pilar 02 · Entregar
Constrói o que já foi validado, do desenvolvimento à homologação. Scrum dá o ritmo, XP dá a técnica, Kanban dá o fluxo. Quem escreve o código não aprova a própria revisão, e quem constrói não dá o aceite do teste de usuário.
Pilar 03 · Operar
Mantém o serviço no ar e é o único pilar que não termina por item. Separa três promessas diferentes que entram pela mesma porta: incidente restaura, requisição atende, problema elimina a causa para não voltar.
As três portas
Cada porta existe para impedir um desperdício que a operação já viu acontecer. Fora delas, o fluxo é contínuo e tem poucas cerimônias.
Porta 1
Só entra em desenvolvimento a história que está pronta, com critério de aceite testável e aprovação registrada de quem pediu e de quem vai construir. Roda uma sprint à frente, de forma contínua. Impede o retrabalho por desalinhamento, que é o mais caro de todos porque só aparece no fim.
Antes de construir
Porta 2
Controla a ida à produção: aceite do usuário na homologação, gestão de mudança e janela combinada. Não é uma reunião de aprovação, é a diferença entre publicar com decisão tomada e publicar na esperança de que dê certo.
Antes de publicar
Porta 3
A única porta que olha para trás. De 30 a 90 dias depois da entrega, confere adoção, benefício e satisfação, e devolve o resultado à descoberta. Junto com ela corre um segundo retorno, contínuo: o atrito que a operação vê todo dia e vira melhoria. São dois relógios diferentes, de propósito.
Depois de entregar
As camadas
Acima
Onde a estratégia vira portfólio e a engenharia presta contas em valor, custo e risco. Uma iniciativa percorre um funil explícito, da análise à medição do valor depois de entregue, e não some do radar no dia em que foi aprovada.
Transversal
O time de plataforma, cujo cliente são os próprios times de produto. Entrega esteira, ambientes em autosserviço e observabilidade, e mantém o padrão de processo, qualidade e métrica. Habilita os times, não executa por eles.
Abaixo
Cultura e princípios, que é a parte que nenhuma ferramenta resolve: erro é aprendizado e não culpa, qualidade se decide na origem, decisão se toma olhando o trabalho real, e ritmo sustentável entrega mais que esforço heroico.
Princípios
Time que descobre e constrói no mesmo ciclo acaba construindo o que ainda não entendeu. A descoberta trabalha adiantada, e o refinamento abastece a entrega cerca de uma sprint à frente.
Reunião só onde existe decisão conjunta. O resto do trabalho corre fora de sala. É o que permite um modelo com esse nível de detalhe não custar o dia inteiro de quem participa dele.
Cada porta pede uma linha: quem aprovou, o quê e quando. É o registro mais barato que existe, e é o que elimina a discussão sobre quem tinha combinado o quê três meses depois.
Nunca cobra pessoa. Indicador usado como cobrança individual para de ser verdadeiro na semana seguinte, e aí a organização perde o instrumento e o time junto.
Perguntas
Entrega em pedaços, em vez de guardar tudo para uma virada de chave no fim, o que faz o valor chegar antes e o erro aparecer cedo, quando ainda é barato. Valida a hipótese antes de gastar engenharia com ela. Controla a cadência do time, de forma que o ritmo seja combinado e não descoberto no meio do caminho. E fecha o ciclo, levando o que a operação aprendeu de volta para a descoberta, em vez de encerrar o projeto no dia do deploy.
Não. Ele arruma os dois no mesmo desenho, junto com os outros oito métodos. Scrum dá a cadência da entrega, SAFe entra na gestão de portfólio da camada de governança, ITIL na operação. A contribuição do modelo não é um método novo: é o critério de onde cada um entra e o que acontece nas fronteiras entre eles.
Descobrir reduz a incerteza, transformando um problema difuso em solução validada. Entregar produz com previsibilidade o que já foi validado. Operar sustenta o serviço em produção e devolve o aprendizado ao início do ciclo. Os três correm em paralelo o tempo todo, não em sequência: enquanto um item está sendo construído, outro já está sendo investigado.
Porque controle que não decide nada vira burocracia. Cada porta existe para impedir um desperdício específico e já observado: entrar em desenvolvimento sem clareza, subir para produção sem aceite, e entregar sem nunca conferir se o benefício apareceu. Fora delas, o fluxo é contínuo e tem poucas cerimônias.
Vira, se o registro passar a valer mais que a decisão. A regra que evita isso é que cada porta exige uma aprovação nominal e curta, não um documento: quem aprova, o que aprovou e quando. E a métrica serve para diagnosticar o processo, nunca para cobrar pessoa, porque métrica usada como cobrança deixa de ser verdadeira na semana seguinte.
Um modelo operacional não se justifica pelo desenho, se justifica pelo desperdício que ele tira do caminho. Este existe porque um time que não sabe onde termina a responsabilidade dele gasta mais energia negociando fronteira do que entregando.
Na sua operação, quem decide que uma história está pronta para desenvolver, e onde essa decisão fica registrada?