A criação de user stories estava a ocupar demasiado tempo aos nossos Business Analysts. Mesmo depois de compreenderem a necessidade de negócio e reunirem o contexto certo, continuava a existir uma quantidade significativa de trabalho manual para transformar essa informação em user stories e critérios de aceitação.
Mas o tempo não era o único desafio. O nível de detalhe dependia muitas vezes da experiência de quem as escrevia, criando inconsistências, ambiguidades e, mais tarde, novas questões e retrabalho para as equipas de desenvolvimento e Quality Assurance (QA).
Foi este o problema que nos levou a criar o StoryWeaver.
Começámos com uma pergunta simples: poderia a Inteligência Artificial Generativa ajudar nos a transformar um contexto de negócio que já compreendíamos em user stories mais claras e consistentes, sem retirar o julgamento humano do processo?
Essa pergunta deu origem à nossa primeira Proof of Concept.
O problema era maior do que o tempo gasto a escrever user stories
Há uma parte de Business Analysis que não acredito que a tecnologia deva substituir: compreender o problema.
Um Business Analyst continua a precisar de falar com os stakeholders, perceber como as pessoas trabalham, identificar dificuldades, questionar pressupostos e clarificar aquilo que o negócio realmente pretende alcançar. Esse contexto não pode simplesmente ser delegado a um modelo.
Mas, depois desse trabalho estar feito, continuávamos a gastar demasiado tempo a converter manualmente essa informação numa estrutura consistente que as equipas de desenvolvimento e QA pudessem utilizar.
Esta distinção tornou se importante quando começámos a explorar a geração de user stories com IA. Não queríamos pedir à IA que decidisse aquilo de que o negócio precisava. Queríamos que nos ajudasse a expressar aquilo que já tínhamos compreendido de uma forma mais clara, estruturada e consistente.
O desafio está em manter este nível de qualidade de forma consistente entre diferentes equipas, algo que exige tempo, disciplina e experiência. E quando a qualidade do requisito inicial varia, o impacto tende a sentir se nas fases seguintes do processo de delivery.
Começar com uma Proof of Concept (PoC)
A primeira versão do StoryWeaver foi propositadamente pequena. Criámos uma Proof of Concept para responder a uma questão muito prática: conseguiria a Inteligência Artificial Generativa utilizar o contexto já recolhido por um Business Analyst para criar uma primeira versão útil de uma user story?
O output seguia uma estrutura definida, incluindo título, precondições, descrição e critérios de aceitação. Para os critérios de aceitação, adotámos uma estrutura Given, When, Then, facilmente compreensível por Business Analysts, developers e equipas de QA.
O objetivo nunca foi gerar um resultado e enviá lo diretamente para desenvolvimento. O StoryWeaver cria o ponto de partida. O Business Analyst revê o resultado, questiona o que foi gerado, acrescenta o contexto em falta e valida se representa corretamente a necessidade de negócio.
O que mudou foi o esforço necessário para chegar a essa primeira versão estruturada. Em vez de começar sempre numa página em branco, as equipas passaram a partir de uma base organizada, podendo dedicar mais tempo a melhorar a qualidade do requisito do que a estruturá lo.
De uma PoC útil a uma solução reutilizável
Uma PoC torna se interessante quando funciona uma vez. Torna se verdadeiramente valiosa quando continua a gerar valor para além do cenário específico para o qual foi inicialmente criada. Esse foi o passo seguinte do StoryWeaver.
À medida que começámos a utilizá lo internamente, percebemos que o valor não estava apenas na produtividade, mas também na consistência. As próprias medições da Xpand IT mostraram uma redução de cerca de 40% no tempo que os Business Analysts dedicavam à criação de user stories. No entanto, o impacto qualitativo era igualmente importante.
Uma estrutura comum fazia com que a qualidade de uma user story dependesse menos da forma individual de escrever de cada Business Analyst. Ao mesmo tempo, as equipas de desenvolvimento recebiam requisitos mais previsíveis e as equipas de QA tinham critérios de aceitação mais claros para trabalhar. Todos podiam partir de uma compreensão mais consistente daquilo que precisava de ser construído.
Isto torna se ainda mais relevante à medida que a IA acelera outras partes do ciclo de desenvolvimento de software. Gerar código mais depressa não resolve um requisito ambíguo. Pelo contrário, quanto mais rápida se torna a execução, mais importante se torna a clareza no início do processo.
A UNICRE foi o teste num contexto real
Rapidamente percebemos que o problema que tínhamos identificado internamente não era exclusivo da Xpand IT. A UNICRE enfrentava muitos dos mesmos desafios: o esforço manual associado à criação de user stories, níveis de detalhe inconsistentes, ambiguidades entre negócio e tecnologia e o retrabalho que daí resultava.
Como a Xpand IT e a UNICRE já trabalhavam em conjunto há vários anos e conhecíamos bem a sua realidade de delivery, conseguimos passar da experimentação interna para a aplicação do StoryWeaver num contexto real de cliente.
Este foi um passo importante na evolução da solução. O StoryWeaver teve de se adaptar a processos, equipas e prioridades diferentes, permitindo nos perceber onde a abordagem inicial funcionava e onde era necessária maior flexibilidade. O envolvimento dos stakeholders relevantes ao longo do processo ajudou também a garantir que a solução permanecia alinhada com a forma como as equipas realmente trabalhavam.
A experiência reforçou um princípio importante por detrás do StoryWeaver: a IA deve reduzir a execução repetitiva sem retirar o julgamento humano do processo. Ao diminuir parte do esforço manual associado à criação de requisitos, as equipas podem dedicar mais tempo ao que exige conhecimento e experiência humanos: questionar pressupostos, analisar dependências, antecipar riscos e validar aquilo que efetivamente avança para desenvolvimento.
O que torna a geração de user stories com IA útil na prática?
É também aqui que considero existir uma distinção importante entre utilizar uma ferramenta generalista de IA e integrar IA num processo de delivery.
Para organizações que estejam a avaliar este tipo de solução, há quatro aspetos que considero fundamentais:
- Um output estruturado e não apenas texto gerado. O resultado deve seguir um formato que Business Analysts, developers e equipas de QA consigam realmente utilizar;
- Validação humana desde a origem. A IA deve acelerar o trabalho, não retirar responsabilidade ou pensamento crítico ao processo;
- Integração com a forma de trabalhar existente. O verdadeiro valor surge quando o output consegue acompanhar o ciclo de delivery, em vez de se transformar noutro documento isolado;
- Um ciclo de feedback baseado na utilização real. As práticas de gestão de requisitos variam entre organizações, pelo que a solução tem de evoluir através dos diferentes contextos em que é aplicada.
Foram estes princípios que permitiram ao StoryWeaver ir além da experiência inicial. A tecnologia é importante, mas é o processo que existe à sua volta que determina se essa tecnologia cria realmente valor.
O StoryWeaver é uma ferramenta visual que apoia os Business Analysts ao longo do ciclo de criação de user stories, desde a compreensão da necessidade e introdução de contexto até à geração, revisão humana, desenvolvimento e refinamento. O objetivo é simples: reduzir o esforço manual, aumentar a consistência e minimizar o retrabalho, mantendo as pessoas responsáveis pelas decisões que realmente importam.
A principal aprendizagem do StoryWeaver
A principal aprendizagem do StoryWeaver não é que a IA consegue escrever user stories. Consegue. A verdadeira oportunidade está em identificar as partes de um processo onde as pessoas estão a gastar tempo em execução repetitiva, em vez de dedicarem esse tempo ao pensamento que realmente cria valor.
Para os BAs, isso significa dedicar menos tempo a traduzir a mesma informação para uma estrutura predefinida e mais tempo a questionar requisitos, analisar dependências, identificar riscos e garantir que aquilo que chega ao desenvolvimento corresponde efetivamente ao que o negócio precisa.
Para developers e equipas de QA, significa começar com melhor contexto. Para a organização, significa reduzir a distância entre uma ideia e uma compreensão partilhada daquilo que precisa de ser construído.
O StoryWeaver nasceu porque quisemos resolver um problema que nós próprios sentíamos. Transformar essa dificuldade interna em algo útil para os nossos clientes não foi um exercício de inovação separado. Foi a consequência de aplicar tecnologia a um problema que já conhecíamos bem.
E essa é talvez a aprendizagem mais importante: os casos de utilização de IA com maior potencial muitas vezes não começam pela tecnologia. Começam por um problema que vale a pena resolver.
