Quando falamos de desenvolvimento de produtos digitais, tenho sempre uma pergunta que ronda minha cabeça:
“Estamos construindo algo que resolve um problema real ou apenas implementando política pública em forma de software?”
Calma, não estou aqui criticando políticas públicas. Muito pelo contrário. Mas quem já trabalhou com desenvolvimento de produtos para governo sabe como é difícil equilibrar o que o público precisa com o que a legislação exige. E pior, em ambientes onde a cultura ágil ainda é vista como um “luxo do mercado privado”.
Essa semana, revisitando minhas anotações do Agile Trends, pensei justamente nisso. Falando agora sobre cultura de equipe e gestão ágil, percebi como as apresentações que assisti deixaram claro um ponto: construir produtos com centralidade no cliente exige autonomia dos times e uma cultura de colaboração muito forte.
Parece óbvio, mas na prática não é. Quando você está desenvolvendo um produto para o público em geral – seja um app para pagar boleto ou um sistema complexo de gestão de saúde pública – há sempre o risco de cair no ciclo vicioso de implementar requisitos e esquecer o usuário. Já quando desenvolvemos políticas públicas, o problema se inverte: pensamos tanto em garantir direitos e cobrir legislações que o produto em si perde competitividade, usabilidade ou até sentido no uso real.
Nesse cenário, fica a pergunta que me acompanhou durante o evento:
💭 Como equilibrar desenvolvimento focado no público com a criação de produtos e políticas públicas que, de fato, melhorem a vida das pessoas?
Para começar a responder, nada melhor do que falar sobre o que vi nessas apresentações sobre fatiamento de features, design thinking, autonomia de equipes e práticas reais para criar culturas ágeis mais maduras. Porque no fim, seja para governo, seja para o mercado privado, nenhuma entrega faz sentido sem pessoas no centro do processo.
Independência ou Morte: O 1/6 mais sacrificante do conceito INVEST
Primeiro gostaria de relembrar o que é INVEST. O INVEST em Agile é um acrônimo que representa um conjunto de critérios para avaliar a qualidade de uma história de usuário, ajudando as equipes a garantir que as histórias sejam claras, concisas e fáceis de implementar. As letras da sigla INVEST correspondem a: Independente (Independent), Negociável (Negotiable), Valiosa (Valuable), Estimável (Estimable), Pequena (Small) e Testável (Testable).
Origem
Em 2003 o acrônimo INVEST foi citado em um artigo de Bill Wake como uma checklist para avaliar rapidamente as histórias de usuários, que também reaproveitou o acrônimo SMART (Specific, Measurable, Achievable, Relevant, Time-boxed) para tarefas resultantes da decomposição técnica das histórias de usuários.
Em 2004 o acrônimo INVEST está entre as técnicas recomendadas no livro “User Stories applied” de Mike Cohn.
Na prática, o Fernando Santiago mostrou, o “I” de Independent é provavelmente o mais sacrificante desses seis princípios. Porque criar histórias realmente independentes exige entender como o usuário interage com o sistema para atingir seu objetivo e, a partir disso, pensar:
Quais verbos estão nesse fluxo de valor?
Quais tarefas habilitadoras existem, mesmo que não entreguem valor direto ao usuário?
No contexto de desenvolvimento de produtos digitais para governo, esse princípio parece até cruel. Afinal, políticas públicas são famosas por dependerem de processos que se encadeiam como um dominó infinito. A licitação depende do parecer jurídico, que depende do parecer técnico, que depende de uma portaria que ainda está em consulta pública… e por aí vai.
Mas quando olhamos sob a ótica de produtos digitais, especialmente sistemas que atendem diretamente a população, pensar em histórias independentes pode ser libertador.
Por exemplo:
Um sistema de agendamento de consultas médicas não precisa esperar a integração com o prontuário eletrônico para disponibilizar a agenda básica ao cidadão.
Um módulo de emissão de documentos pode ser dividido em histórias que entreguem etapas do processo (captura de dados, geração de PDF, integração com base federal) sem que tudo precise ser lançado junto.
Quando não criamos histórias independentes, caímos naquele inferno do tudo ou nada: o produto só gera valor quando estiver 100% pronto, o que na prática significa… quase nunca pronto.
Ná prática
Na apresentação, o Fernando trouxe um passo a passo para ajudar a identificar a independência das histórias.
1. Identifique os verbos (as ações)
Comece levantando os verbos do fluxo de valor primário (o caminho principal que o usuário faz para alcançar seu objetivo) e os verbos do fluxo de valor secundário (ações complementares, mas não essenciais para o objetivo final).
🔎 Exemplo prático (pensando em governo) Fluxo primário: “Agendar consulta” → verbos: selecionar especialidade, escolher unidade, escolher data e horário, confirmar. Fluxo secundário: visualizar histórico, cancelar agendamento, avaliar consulta.
2. Identifique as tarefas habilitadoras
Essas são as atividades que não entregam valor direto ao usuário final, mas são necessárias para viabilizar a implementação técnica da história. Podem incluir:
Ajuste de infraestrutura
Criação de tabelas ou endpoints
Configuração de permissão e segurança
🔧 Exemplo prático Antes de disponibilizar o agendamento de consulta, talvez seja necessário criar a API de busca por especialidade. Isso não entrega valor direto ao usuário, mas viabiliza a feature.
3. Classifique as histórias em primárias, secundárias e habilitadoras
Fernando mostrou um modelo visual (tipo um story mapping) onde se distribuem as histórias:
Primárias: entregam valor direto ao usuário
Secundárias: complementam o fluxo, mas não bloqueiam a entrega principal
Habilitadoras: pré-requisitos técnicos
4. Revise dependências
Mesmo depois de fatiar, revise se há dependências entre as etapas de validação. Se sim, reavalie o corte.
5. Observe o comportamento do time
Fernando destacou que não adianta só fatiar histórias no papel se a equipe não entender o fluxo de valor ou insistir em vícios de “trabalhar tudo junto”. É preciso:
Remover vícios e interferências
Compartilhar conhecimento
Criar experiências práticas para reforçar a autonomia
6. Incentive a colaboração real
Porque, no fim, histórias independentes só existem se o time colaborar para enxergar o todo, e não apenas seus pedacinhos de código.
No contexto de produtos digitais, essa abordagem pode ser a chave para quebrar a cultura do “aguarde o sistema ficar pronto” e começar a entregar valor de forma contínua – algo que, convenhamos, é mais urgente do que nunca.
Business Inception: Construção de Produtos Complexos do Jeito Certo
Outra apresentação que me fez refletir sobre nossos desafios no desenvolvimento de produtos foi a da Gabriela Maioral e Najara Goularti, da Odontoprev.
Elas começaram com uma provocação simples: “O óbvio precisa ser perguntado.”
Quantas vezes nos projetos públicos caímos na armadilha de presumir o que o usuário quer, porque “está na lei”, “está no edital” ou “é assim que sempre foi feito”? E então entregamos produtos gigantes, caros, com funcionalidades complexas, que ninguém usa.
Na palestra, Gabriela e Najara mostraram como aplicaram o Business Inception para construir produtos complexos de forma ágil e centrada no cliente. Entre os principais aprendizados:
1. Traga o cliente para o centro – de verdade
Pode parecer frase de efeito, mas elas mostraram que isso vai além de aplicar entrevistas de usuário. É sobre:
Ouvir diretamente o cliente, sem intermediários que “traduzem” a dor de acordo com a visão de negócios.
Mapear personas detalhadamente, entendendo nome, idade, profissão, objetivos e contexto real de uso.
2. Mapeie ganhos, tarefas e dores
Na abordagem delas, antes de pensar em solução, o time mapeou:
Ganhos: o que faz o cliente feliz
Tarefas: o que ele precisa fazer no sistema
Dores: o que dificulta ou frustra sua experiência
Essa clareza permite priorizar funcionalidades com base no impacto real, não no que está mais politicamente visível.
3. Crie a proposta de valor sob duas óticas
Elas dividiram a proposta de valor em:
Visão do cliente: o que ele percebe como valor
Visão do negócio (Odontoprev): o que a empresa pode oferecer como criadores de ganhos, analgésicos e soluções
No caso de produtos digitais para governo, essa visão do negócio inclui políticas públicas, legislação, marcos normativos… mas ainda assim, a visão do cliente não pode desaparecer no processo.
4. Use a matriz CSD (Certezas, Suposições, Dúvidas)
Antes de sair priorizando backlog, elas construíram essa matriz para mapear o que sabiam, o que supunham e o que precisavam validar, isso ajuda principalmente a reduzir desperdício.
5. Backlog priorizado não é luxo, é sobrevivência
No fim, o Business Inception guiou o time para construir um backlog priorizado com base nas dores e objetivos do cliente, garantindo que os esforços fossem direcionados para resolver problemas reais com o menor desperdício possível.
Para fechar, a palestra do Filippe Valentim trouxe um tema que, na minha opinião, conecta tudo o que já falei até aqui: cultura de equipe.
Muita gente ainda vê Management 3.0 como aquele momento “fofinho” do time, cheio de dinâmicas de motivação. E olha, não deixa de ser. Mas como o próprio Filippe disse:
“Não é sobre abraçar árvore, é sobre criar equipes de alta performance de verdade.”
E o que são equipes de alta performance, afinal?
Segundo ele, são aquelas que atingem ou superam metas com frequência, com características como:
Comunicação aberta e transparente
Autonomia e auto-organização
Cultura de aprendizado
Comprometimento e motivação
Foco em resultados
Adaptação e flexibilidade
Então, como aplicar Management 3.0 na prática nesse cenário?
Ferramenta simples para definir níveis de autonomia em cada decisão. Ideal para times que não sabem até onde podem decidir sem “pedir bênção” para cinco gerências antes.
Feedback estruturado, objetivo, que foca em comportamento e impacto, não em julgamentos pessoais. Perfeito para times que evitam conversas difíceis ou só dão feedback uma vez por ano na avaliação de desempenho.
Para entender o que motiva cada pessoa do time e quais mudanças impactam seus valores pessoais. Porque, no fim, um time motivado é aquele que sente que trabalha em algo que faz sentido para si mesmo. Além disso, confiamos em quem conhecemos.
Pelo que entendi, Management 3.0 não é sobre dinâmicas fofinhas. É sobre criar times autônomos e motivados, capazes de entregar resultados reais – seja para um produto de mercado, seja para o próximo sistema de política pública digital que vai impactar milhões de pessoas.
Essas três palestras me lembraram que não existe produto bem-sucedido sem cultura de equipe forte. E que, em produtos digitais para governo, isso se torna ainda mais crítico: porque não estamos falando apenas de melhorar indicadores de conversão, mas de melhorar a vida das pessoas.
No fim do dia, entrega contínua, centralidade no cliente e cultura de equipe são apenas diferentes formas de dizer a mesma coisa: pessoas em primeiro lugar.
Ah, e isso é só uma parte do que vi no Agile Trends. Ainda pretendo escrever mais um ou dois posts sobre as outras palestras que assisti por lá, explorando temas como Inteligência artificial, transformação organizacional em escala e inovação real. Porque, no fim, cada uma dessas conversas me trouxe reflexões que valem compartilhar com todo mundo que também acredita que tecnologia e gestão ágil só fazem sentido quando servem às pessoas.
Coordenador do time de desenvolvimento na BNP Soluções em TI. Ex-treinador de overwatch. Viciado em resolução de problemas. Sommelier de café não-oficial e pai do Heitor
Seja o primeiro a comentar