O último ticket que abrimos no nosso Jira para um projeto interno é de fevereiro. Ninguém decidiu numa reunião deixar de o usar. Aconteceu sozinho: sempre que alguém escrevia um ticket, acabava por escrever o mesmo no prompt do agente, e o ticket nunca mais era lido por ninguém. Passadas umas semanas, as pessoas deixaram de escrever a primeira versão.
Hoje o trabalho de cada projeto é gerido num ficheiro de texto, tasks.md, que vive dentro do próprio projeto e que os agentes vão preenchendo enquanto trabalham. Funciona-nos melhor do que o Jira em quase tudo. Numa coisa funciona pior, e é a que mais nos dói: saber o que cada um está a fazer.
Este texto tem opinião. Acho que o Jira, e quase qualquer tracker de tickets, foi pensado para distribuir horas de programador, que durante vinte anos foram o mais caro de um projeto. Com agentes, escrever o código custa minutos ou horas. O caro agora é saber o que você quer e verificar que o que voltou está bem, e um quadro de tickets não ajuda em nenhuma das duas coisas.
Também é um texto a meio caminho. Estamos há oito meses com este sistema, já o mudámos quatro vezes e vamos mudá-lo mais. Conto o que nos correu bem, o que nos correu mal e o que ainda não sabemos resolver.
Um aviso antes de começar: somos uma agência, e parte do que vendemos são horas de desenvolvimento. Se estimar em horas deixar de fazer sentido, isso afeta-nos a nós antes de mais ninguém.
Para que servia o Jira
Tire-lhe as integrações, as cores e os campos personalizados, e ao Jira sobram quatro funções:
- Uma fila: o que há para fazer e por que ordem.
- Uma distribuição: quem faz cada coisa.
- Uma estimativa: quanto vai custar, em horas ou em pontos, para saber o que cabe num sprint.
- Um estado: em que ponto está cada coisa, para que quem não está a programar o saiba sem perguntar.
As quatro giram em torno do mesmo recurso escasso: o tempo de uma pessoa que sabe programar. O sprint existe porque esse tempo se esgota a cada duas semanas. Os pontos existem porque é preciso distribuí-lo antes de o gastar. As colunas “Em curso” e “Em revisão” existem porque uma tarefa podia passar dias em cada uma.
Durante anos trabalhámos assim, e funcionava. Tínhamos refinamentos às segundas, planning a cada duas semanas, uma retro que às vezes se saltava e um quadro por projeto. O quadro era a forma de o cliente, o gestor de projeto e a equipa verem o mesmo.
O que mudou com os agentes
A primeira coisa que notámos foi que as estimativas deixaram de bater certo, e não por serem más. Uma tarefa de três pontos, que antes era um dia e meio de trabalho, fazia-se numa tarde. Uma de cinco, num dia. As de oito continuavam a custar o mesmo ou mais, porque aí o difícil nunca foi teclar: era perceber o que havia para fazer.
Durante uns dois meses tentámos recalibrar os pontos. Não funcionou. O tempo de uma tarefa já não dependia do tamanho, dependia de quão bem estava explicada. Uma tarefa grande mas clara saía numa manhã. Uma pequena mas ambígua podia comer dois dias de ida e volta, porque o agente fazia com muita segurança algo que não era o que queríamos, era preciso explicar outra vez, e voltava a fazer outra coisa.
Aí percebemos que tínhamos mudado o gargalo de sítio. Antes o trabalho encravava em “quem tem tempo para fazer isto”. Agora encrava em dois sítios:
- Antes de começar: escrever bem o que você quer. Não num ticket de duas linhas, mas com o contexto, as restrições, o que não se deve tocar e como vai saber que está bem.
- Ao terminar: rever o que o agente fez. Ler a alteração, testá-la, perceber se partiu alguma coisa que não se vê.
O Jira não tem coluna para nenhuma das duas. Tem “Por fazer”, “Em curso” e “Feito”, e a maior parte do esforço já não está em “Em curso”.
A outra coisa que mudou foi o tempo que uma tarefa passava em cada estado. Se uma tarefa está “Em curso” durante quarenta minutos, movê-la no quadro custa quase o mesmo que fazê-la. As pessoas deixaram de a mover. O quadro começou a mentir. E um quadro que mente é pior do que não ter quadro, porque alguém olha para ele e acredita.
O tasks.md
A alternativa saiu de um projeto pequeno, quase por acidente. Um programador da equipa começou a deixar ao agente uma lista de pendentes num ficheiro de texto na raiz do projeto, para não ter de lhe explicar o contexto todas as manhãs. Ao fim de uma semana o agente já atualizava essa lista sozinho: marcava o que terminava, acrescentava o que encontrava pelo caminho e anotava porque deixava algo a meio.
Copiámo-lo para os restantes projetos. Hoje todos têm um, e é parecido com isto:
# Tarefas
## Em curso
- [ ] Exportação de encomendas para CSV com filtro por loja (Laura, desde 14-out)
- Falta: testar com mais de 10.000 linhas
- [ ] Mudança do gateway de pagamento para a nova API (Dani, desde 15-out)
## Pendente
- [ ] A pesquisa ignora acentos ("gestao" não encontra "gestão")
- [ ] Rever textos legais da página de checkout (à espera de resposta do cliente)
## Feito
- [x] Login com link mágico por e-mail (Laura, 13-out)
- Retirou-se o login com palavra-passe no telemóvel a pedido do cliente
- [x] Corrigido o cálculo do IVA em devoluções parciais (Dani, 11-out)As regras são poucas:
- O agente lê-o ao começar qualquer sessão. Assim sabe o que está em aberto, quem está com cada coisa e o que se decidiu antes, sem que ninguém lho conte.
- O agente atualiza-o ao terminar. Move o que fez para “Feito”, com uma linha sobre o que mudou e, se for preciso, porquê. Se encontrou algo partido que não lhe cabia arranjar, acrescenta-o a “Pendente”.
- As pessoas leem-no e corrigem-no. Se uma prioridade muda, move-se a linha à mão. Ninguém tem de “mover cartões” para que o estado esteja atualizado, porque o estado é escrito por quem faz o trabalho.
- Tudo o que não cabe numa linha vai para outro sítio. As decisões de design e as regras do projeto vivem num ficheiro à parte que o agente também lê. O
tasks.mdé só a lista.
Comparado com o Jira, ganha em três coisas. Vive com o código, por isso guarda-se, versiona-se e recupera-se junto com ele. O agente lê-o sem integrações, sem permissões e sem conectores, porque é texto. E uma pessoa lê-o inteiro em trinta segundos, o que é mais do que se pode dizer de um quadro com cento e vinte cartões.
Perde noutras, e conto-as mais abaixo.
O que correu bem
A alteração que saiu da reunião
Na primavera tínhamos uma reunião de acompanhamento com um cliente do setor da distribuição. A meio da reunião, o diretor de operações disse que o relatório de encomendas que lhes tínhamos entregado servia, mas que o que precisavam mesmo era de o ver por loja e de o poder descarregar para o passar a cada encarregado.
Com o nosso processo anterior, isso teria sido um ticket, um refinamento na segunda-feira seguinte, uma estimativa e, com sorte, entrar no sprint da semana a seguir. Duas semanas, sendo otimistas.
A programadora que estava na reunião anotou-o no tasks.md enquanto falavam, com as palavras do cliente. À saída abriu uma sessão com o agente. Às cinco da tarde mandámos-lhe um link para o ambiente de testes com o filtro por loja e o download. A resposta do diretor foi um áudio de WhatsApp que ainda pomos a tocar de vez em quando.
O agente fez a sua parte, mas o que poupou as duas semanas foi que entre o pedido e o código não havia mais nada: nem ticket, nem fila, nem planning. A única coisa necessária era perceber bem o que o cliente pedia, e isso já tínhamos porque estávamos na reunião.
O MVP que saiu antes do prazo
Para uma startup tínhamos planeado um primeiro produto em seis semanas: registo de utilizadores, um painel com três vistas, pagamentos e notificações. Saiu em duas e meia.
O que mais pesou foi que, sem sprints, o cliente via avanços todos os dias e corrigia todos os dias. Quando na segunda semana percebeu que uma das três vistas do painel não ia ser usada por ninguém, tirámo-la nessa mesma tarde. Num sprint de duas semanas essa alteração teria chegado tarde, com a vista já construída e testada.
A fundadora disse-nos depois que éramos o primeiro fornecedor com quem não sentia que estava à espera.
O cliente que deixou de pedir o relatório semanal
A vários clientes mandávamos um relatório semanal de estado. Escrevia-o o gestor de projeto às sextas, a partir do quadro do Jira, e levava bem mais de uma hora.
Um cliente perguntou-nos se podia ver diretamente “essa lista que vocês usam”. Demos-lhe acesso de leitura ao tasks.md. Duas semanas depois pediu-nos para deixarmos de lhe mandar o relatório: preferia olhar para a lista quando lhe apetecia, e ali estava tudo o que precisava de saber. Nas palavras dele, percebia melhor pelo ficheiro do que pelo relatório, porque cada linha tinha sido escrita por quem tinha feito o trabalho.
Nem todos os clientes o querem assim, e está tudo bem. Mas nenhum nos pediu para voltar ao quadro.
A integração num dia
Quando alguém entra num projeto a meio do caminho, o normal é passar dois ou três dias a ler tickets, a perguntar e a perceber o que está a meio. Este verão entrou um programador novo num projeto que estava em curso há quatro meses. Pediu ao agente que lesse o tasks.md e o ficheiro de regras e lhe explicasse o estado do projeto. Nessa mesma manhã fechou a primeira tarefa.
Menos reuniões
Deixámos de fazer planning e refinamento. Continuamos a falar, mas de outra forma: dez minutos de manhã para dizer em que vai mexer cada um, e conversas curtas quando é preciso decidir alguma coisa. Ao fim de um mês, as pessoas da equipa contavam que tinham as tardes inteiras para trabalhar sem interrupções, e isso notava-se no que saía.
O que correu mal
Duas pessoas, a mesma tarefa
Numa terça-feira, dois programadores corrigiram o mesmo erro ao mesmo tempo. O cliente tinha-o reportado por dois canais diferentes, um viu-o no e-mail e outro no chat do projeto, e cada um passou-o ao seu agente. Nenhum dos dois olhou para o tasks.md antes de começar, e os agentes também não, porque a tarefa ainda não estava anotada. Demos por isso na revisão: duas correções diferentes para a mesma coisa, ambas razoáveis e incompatíveis entre si.
Perdemos uma tarde. Não é muito, mas é exatamente o tipo de coisa que um quadro com responsável atribuído evita, e nós tínhamos tirado isso.
”Em curso” durante nove dias
Noutro projeto, uma tarefa esteve marcada como “Em curso” durante nove dias. A pessoa que estava com ela tinha passado para outro projeto urgente e não a moveu. Os agentes, sempre que liam o ficheiro, assumiam que alguém estava a tratar dela e não lhe tocavam. Descobrimo-lo quando o cliente perguntou por essa funcionalidade.
Um ficheiro que se preenche sozinho preenche-se com o que o agente sabe. O que acontece fora da sessão (alguém muda de projeto, um cliente muda de ideias ao telefone) não chega ao ficheiro se uma pessoa não o escrever.
O agente que deu por terminado algo a meio
O tasks.md é atualizado pelo agente, e o agente às vezes é otimista. Já tivemos tarefas marcadas como feitas que estavam a meio: a exportação funcionava, mas não com os dados reais do cliente; o formulário era enviado, mas o e-mail de confirmação não saía. O ficheiro dizia “Feito” com a mesma segurança nos dois casos.
Desde então, uma tarefa não está feita porque o agente o diz. Está feita quando uma pessoa a reviu, e o agente não pode marcar essa caixa.
”O que estão a fazer agora?”
Esta é a que mais nos custou. Um cliente ligou numa quinta-feira e perguntou, com toda a razão, em que estávamos a trabalhar nessa semana. O gestor de projeto não sabia ao certo. Havia duas pessoas no projeto, cada uma com duas ou três sessões de agente abertas, e o tasks.md refletia o que se tinha terminado, mas não o que estava a acontecer naquele momento. Teve de perguntar no chat da equipa e ligar ao cliente vinte minutos depois.
Com o Jira essa pergunta respondia-se olhando para uma coluna. Essa coluna mentia muitas vezes, mas respondia-se.
A armadilha da velocidade
O cliente da alteração na reunião habituou-se a que as coisas chegassem no mesmo dia. Três meses depois pediu uma integração com o seu sistema de faturação, que dependia de um fornecedor externo e de permissões que demoraram uma semana a chegar. Para ele, uma semana era lentíssimo. Antes, a mesma integração teria sido um sprint inteiro e ter-lhe-ia parecido normal.
Ir depressa muda o que o cliente espera, e quando algo não pode ir depressa, é preciso explicá-lo antes de ele perguntar. Aprendemo-lo tarde.
O problema que não resolvemos: trabalhar em paralelo
Se há uma coisa que o Jira fazia bem e nós ainda não, é coordenar várias pessoas a trabalhar ao mesmo tempo no mesmo projeto.
Com agentes, cada programador pode ter várias tarefas a avançar em simultâneo. Isso multiplica o que sai, mas também multiplica as hipóteses de duas tarefas pisarem o mesmo bocado de código, ou de duas pessoas resolverem o mesmo problema cada uma por si. E o tasks.md fica aquém, porque reflete o que se decidiu ou terminou, não o que se está a fazer neste momento.
O que fazemos hoje é pouco sofisticado: os programadores falam entre si. Antes de começar algo que mexe numa parte sensível do projeto, avisa-se no chat da equipa com um “vou mexer nos pagamentos esta manhã”. A reunião de dez minutos de cada manhã serve sobretudo para isso. E a regra é que uma tarefa se anota no ficheiro, com nome, antes de ser dada a um agente, não depois.
Funciona porque somos poucos por projeto e conhecemo-nos. Não sei se funcionaria com quinze pessoas.
Experimentámos outras coisas que não funcionaram:
- Um ficheiro de tarefas por pessoa. Cada um sabia o seu e ninguém via o conjunto. Durou duas semanas.
- Pôr o agente a avisar no que está. Pedimos-lhe que, ao começar, escrevesse no ficheiro em que ia mexer. Fazia-o, mas quando duas sessões começavam quase ao mesmo tempo, nenhuma via o que a outra tinha escrito.
- Voltar a um quadro só para o que está em curso. Durou menos do que o ficheiro por pessoa. Ninguém o atualizava, pelo mesmo motivo de antes.
Estamos a olhar para ferramentas que tentam resolver precisamente isto. O Orca, da Stably AI, é uma aplicação de desktop open source que lança vários agentes em paralelo, cada um isolado, e permite ver num único ecrã o que cada um está a fazer e comparar os resultados. Resolve a parte de ver o que faz cada agente de uma pessoa. A parte de ver o que faz cada pessoa da equipa continua em aberto.
O que a Atlassian e a Linear estão a fazer
Os fabricantes de trackers viram o mesmo e responderam metendo os agentes lá dentro.
A Atlassian abriu o Agents in Jira em beta em fevereiro de 2026 e anunciou-o como disponível para todos em maio, no Team ‘26. Você atribui um ticket a um agente a partir do mesmo menu que usa para uma pessoa, e o agente lê o ticket e regista nele o seu progresso.
A Linear tomou uma decisão que me parece melhor: uma issue só se atribui a pessoas e delega-se em agentes. O agente trabalha, mas o responsável continua a ser um humano. É uma distinção pequena no ecrã e grande na prática, porque deixa claro quem responde quando o agente se engana, que é precisamente o que nos aconteceu com as tarefas que o agente dava por terminadas.
As duas respostas têm o mesmo problema de fundo: assumem que um ticket é uma boa especificação para um agente, e quase nenhum o é. “Corrigir o login no Safari” chega para uma pessoa que sabe a quem perguntar. Um agente com esse ticket vai fazer alguma coisa, e vai fazê-la com muita segurança. Como atribuir tickets a agentes é cómodo, fica mais fácil mandar trabalho mal explicado a algo que não pergunta.
Onde o Jira continua a ter razão
Se chegou até aqui a pensar “isto funciona-vos porque são poucos”, tem parte de razão. Há sítios onde eu não tiraria o Jira:
- Várias equipas que dependem umas das outras. Um
tasks.mdcoordena um projeto. Quando a equipa de pagamentos depende de que a de plataforma mude alguma coisa, e cada uma trabalha no seu, é preciso um sítio comum onde essa dependência se veja. - Pessoas que não estão no projeto. Direção, suporte, vendas ou compliance precisam de saber o que se passa sem abrir um ficheiro dentro do código. Um quadro é uma interface para eles, e isso não muda porque o código seja escrito por um agente.
- Auditorias. Se você é auditado em ISO 27001 ou SOC 2, o auditor vai querer ver que cada alteração tem um pedido, uma aprovação e um responsável. Se o seu processo de controlo de alterações já está montado sobre o Jira, refazê-lo não compensa.
- A equipa de um cliente. Quando nos integramos na equipa de produto de um cliente, trabalhamos com as ferramentas dele. Com a Orquest usávamos o Jira deles e entrávamos nas suas dailies. Aí não há nada a discutir: o tracker é deles.
O que têm em comum é que quase tudo é comunicação com pessoas que não estão dentro do código. A parte do Jira que continua a fazer sentido é a que fala com humanos. A que perdeu o sentido, para nós, é a que planeava o trabalho dos programadores.
O que faríamos se começássemos hoje
Isto continua a mudar, mas se uma equipa nos perguntasse amanhã como começar, dir-lhe-íamos isto:
- Deixe de estimar o trabalho que um agente faz. Se a equipa continua a pôr pontos em tarefas de quarenta minutos, está a medir o ritual, não o trabalho.
- Ponha a lista de tarefas dentro do projeto, num ficheiro que o agente leia ao começar e atualize ao terminar. É a forma mais barata de o agente ter memória entre sessões.
- Anote a tarefa antes de a dar a um agente, com nome. É a única regra que nos evitou de facto trabalho duplicado.
- Uma tarefa só está feita quando uma pessoa a revê. O agente pode propor que está terminada; não pode decidi-lo.
- Fale com o resto da equipa antes de mexer em algo delicado. Uma mensagem de uma linha no chat evita uma tarde perdida. Ainda não encontrámos nada melhor.
- Feche o que está há semanas sem se mexer. Uma tarefa em que ninguém tocou em seis semanas é uma decisão que ninguém quis tomar. Se era importante, alguém a voltará a abrir.
- Guarde o Jira, ou o que usar, para falar com quem não está no código. Clientes que o prefiram, direção, auditoria.
Daqui a seis meses é provável que este texto já esteja desatualizado. Se resolvermos o trabalho em paralelo, contamo-lo aqui. E se alguém já o resolveu, gostávamos muito de saber como: escreva-nos para info@soamee.com.