Cada um do seu jeito
A Capyvara tem dois produtos e um time pequeno e misto: desenvolvedores, design, pessoas de negócio e estudantes em início de carreira. Cada um trabalhava do seu jeito, e o que definia se algo estava "pronto" era a opinião de quem fez.
Num time assim, o risco não é falta de talento. É cada entrega depender de quem lembrou de testar, de quem revisou e de quem sabia como publicar.
Um padrão que vale para todo PR
O primeiro passo foi escrever o que até então estava na cabeça das pessoas. Criei o baseline de engenharia da plataforma e um template de PR obrigatório. Todo PR passou a dizer o que mudou e por quê, a passar por um checklist de permissões e de falhas esperadas, a registrar os testes feitos com e sem permissão e a trazer o impacto e as evidências.
Especificação antes de código
Em seguida, adotei o desenvolvimento guiado por especificação. Cada funcionalidade começa como uma spec com critérios de aceite, que depois vira um plano e uma lista de tarefas. Para que o quadro de trabalho não se descolasse da spec, automatizei a publicação dessas tarefas como cards no Trello, com responsável, labels e uma reexecução que não duplica cards já abertos. O quadro passou a refletir a spec, e não o contrário.
Um caminho só até produção
Organizei o fluxo de desenvolvimento, homologação e produção por PRs, para que nada chegasse ao cliente sem passar pelo ambiente de teste. Também fiz o pipeline comentar no próprio PR o trecho do log e a lista de falhas quando algo quebra. Assim, qualquer pessoa do time, inclusive quem está começando, entende o que deu errado sem precisar pedir ajuda.
Antes de um lançamento, escrevi um parecer de prontidão com o estado real do produto: o que estava pronto, o que não estava e um plano dia a dia até a decisão de lançar ou não.
Prioridade com critério
Também padronizei como registrar débitos técnicos e pedidos de produto: prioridade, impacto, para quem dói, esforço e o que fazer. Com isso, a conversa sobre o que fazer primeiro virou uma comparação entre cards, e não uma disputa de quem fala mais alto. Conduzi reuniões com usuários e clientes e transformei o retorno deles em histórias com critérios de aceite, separando o que era ajuste de interface do que era decisão de produto.
Conhecimento fora da cabeça
Para que o time não dependesse de mim, documentei o onboarding de QA, o processo de publicação, um mapa de conhecimento do produto e os registros de decisão. Do lado do cliente, escrevi o documento de critérios de sucesso com um cliente do setor público e os indicadores de sucesso do produto.
O que mudou
O time passou a ter uma definição comum de pronto, escrita no template de PR. As entregas passaram por um único caminho até produção, com homologação no meio e uma decisão de lançamento baseada em evidência. E o planejamento ficou rastreável, da spec ao card e do card ao PR.
O que eu levo disso
Boas práticas só pegam quando custam menos do que não segui-las. Um checklist no template de PR, um pipeline que explica a própria falha e cards gerados a partir da spec funcionaram melhor do que qualquer conversa sobre disciplina.
Liderar um time pequeno é, em boa parte, decidir o que não fazer agora, e deixar essa decisão escrita, com critério, para todo mundo ver.