Nunca escreve
sem confirmar.

A adoção do Jira ficou mais estruturada em design, e trouxe um problema novo.

Manter os cards atualizados dia a dia, no momento exato de cada mudança, virou fricção constante. Cada squad cadastrava issue do jeito que dava, sem padrão de campo obrigatório, principalmente o Design Type, a classificação que sustenta qualquer métrica extraída depois sobre o que o time de design está de fato fazendo.

Cards parados e sem atualização, principalmente sem issue type preenchido.

Sem essa classificação, pesquisa, mapeamento, ideação, teste de usabilidade e métricas viravam tudo indistinto num board sem categoria. Não tinha como responder, com dado confiável, uma pergunta simples: no que o time de design está gastando o esforço.

Criar uma automação que criasse e atualizasse cards a partir de linguagem natural, com padrão consistente.

O objetivo não era só parar de esquecer de atualizar. Era tirar do designer a obrigação de decorar regra de Jira (campo certo, tipo certo, vínculo certo) só pra manter o próprio board em dia.

Construí pro meu próprio uso primeiro. Virou base pra outros dois designers construírem o deles.

Montei o Controller resolvendo o meu problema: meus dois projetos (PIXSPI e PIX2), minhas particularidades de campo, meu jeito de descrever tarefa. Não nasceu como ferramenta pensada pro time desde o início. Foi só depois de rodar de verdade, com atrito real testado no meu próprio uso, que a Jessica e a Vanessa pegaram o padrão como ponto de partida e montaram os próprios prompts e controllers em cima dele.

Isso não parou no "construí e usei". Quando a adoção começou a aparecer no board de governança do time inteiro (que cobre squad muito além do meu, de Financeiro a KYC a Aquisição), segui acompanhando os números e puxando o assunto com as lideranças quando via gap. Um exemplo real: identifiquei 23 itens concluídos sem Design Type e levei isso pro canal de lideranças, pedindo apoio pra cobrar os liderados a ajustar. A automação resolve o esforço de criar e atualizar, mas não substitui a disciplina de classificar certo.

Dois prompts, dois momentos de uso: criação sob demanda e check-in diário automático.

O Controller opera dois projetos na mesma instância (PIXSPI e PIX2), e cada um tem particularidade própria de campo. PIX2 usa um Epic Link clássico que o PIXSPI não tem, e possui um campo adicional de "Squads de Produto" e um componente "Design" que não existem no outro projeto. Antes de qualquer ação, o Controller busca a issue pra confirmar a qual projeto ela pertence. Nunca assume.

Existem dois tipos de issue no fluxo: Design, pra macro-etapas do processo (pesquisa, mapeamento, ideação, teste), e sub-design, subtask pra quebrar um card Design em tarefas menores. Os dois têm um campo de Design Type, mas com opções diferentes: o de Design cobre a etapa do processo (Pesquisa, Mapeamento, Ideação, Teste de Usabilidade, Métricas), o de sub-design cobre entregável mais visual (Protótipo, Componente, Content, Tagueamento). Regra combinada: se a tarefa não se encaixa claramente numa opção, o Controller pergunta antes de escolher. Nunca decide sozinho.

Todo card Design segue uma estrutura fixa de descrição (descrição do que será feito, objetivo, lista de tarefas) pra manter tom e nível de detalhe consistente entre os designers que usam o padrão, não só entre os meus próprios cards.

• O vínculo com o épico pode ser de duas formas: relacionado (Relates, o padrão mais comum) ou como filho direto do épico. O Controller sempre confirma qual o usuário quer, em vez de assumir o default
• Pra descobrir o responsável, o Controller busca o accountId pelo nome. E aprendeu, no uso real, que buscar nome completo às vezes falha e buscar só o primeiro nome funciona melhor. Quando não encontra, lista as opções parecidas e pergunta, em vez de arriscar atribuir card pra pessoa errada
• O check-in diário é o segundo prompt, programado pra rodar às 17h em dias úteis. Ele pergunta o que aconteceu no dia, eu respondo em linguagem natural, e ele devolve os cards e o texto de atualização pra eu validar antes de qualquer escrita no Jira. Nada é criado ou editado sem confirmação explícita minha na conversa

Um Controller que cria, atualiza e nunca escreve sem confirmação.

O resultado prático são duas rotinas: criação de card a partir de descrição solta de tarefa (com pergunta ativa quando falta Design Type ou responsável), e atualização contínua via check-in diário, sempre com prévia antes de qualquer mudança real no Jira.

Um card de referência ficou registrado como modelo de tom e estrutura pros próximos: descrição objetiva, objetivo separado da descrição, lista de tarefas clara, vínculo ao épico documentado. Esse padrão é o que se replicou quando Jessica e Vanessa construíram os próprios controllers.

Adoção real, mas não uniforme. E isso está sendo tratado com governança ativa, não escondido.

O board de governança do time de design (que cobre squad muito além da minha: Financeiro-ERP, Vendas Físicas, Seguros, Grandes Contas, Fiscal, KYC, Open Finance, Produtos-ERP, Aquisição, Identidade e Fraude, Nota Fiscal de Serviço, Novas Frentes de Negócios, Mensageria, Transacional do Cartão, Cobranças, BackOffice) mostra 17 designers mapeados: 11 com Design Type aplicado corretamente, 4 sem aplicar, e 2 com aplicação incompleta, inclusive a minha própria linha, marcada como heavy user (13 tickets) e "Incompleto". Ser quem construiu a ferramenta não me deixou imune ao mesmo problema de disciplina de dado que ela existe pra resolver.

O que esse projeto ensina sobre automatizar processo sem terceirizar a disciplina.

• Automação resolve esforço, não substitui disciplina. Criar e atualizar card ficou mais fácil, mas classificar certo continua exigindo atenção de quem preenche, e a taxa de "Incompleto" (inclusive a minha) prova isso
• Ferramenta que nasce resolvendo o próprio problema espalha mais rápido que ferramenta pensada pro time desde o início. Jessica e Vanessa não adotaram um processo oficial. Pegaram uma solução que já tinha provado valor em uso real
• Confirmar antes de escrever é o que sustenta confiança numa automação que mexe em dado de várias pessoas. O Controller nunca cria ou edita sem intenção clara indicada na conversa. Isso não é só regra técnica, é o motivo de dar pra confiar nele com o board do time inteiro
• Ser heavy user não é sinônimo de dado perfeito, e admitir isso publicamente pesa mais a favor do que contra. Levar meu próprio "Incompleto" pra dentro da governança, em vez de esconder, é coerente com pedir que os outros ajustem o deles
• Ferramenta pessoal que vira prática de time precisa de alguém puxando a manutenção depois que o brilho inicial passa. A mensagem pro canal de lideranças sobre os 23 itens é a parte do trabalho que continua depois do Controller já estar pronto e funcionando