Começa pelo trabalho que alguém precisa de concluir
Descreve uma situação concreta antes de enumerar funcionalidades. Identifica quem chega à aplicação, o que traz consigo e o resultado de que precisa para seguir o trabalho. Esse percurso dá um propósito aos ecrãs e às ações. Sem ele, uma lista extensa pode continuar a deixar a necessidade principal por resolver.
Imagina uma oficina que recebe pedidos de reparação por vários canais e quer organizá-los. A ideia inicial pode ser ter uma aplicação com clientes, equipamentos e estados. Ainda falta saber quem regista o pedido, que informação recebe e como percebe se existe material suficiente para encaminhar o trabalho a um técnico.
Uma descrição mais útil acompanha um pedido desde a entrada: a receção identifica o equipamento, regista o sintoma e associa uma forma de contacto. O responsável técnico analisa o pedido e decide o passo seguinte. A equipa precisa de reconhecer o estado atual sem reconstruir a história em várias conversas.
Este percurso ajuda a encontrar o primeiro resultado que vale a pena construir. Talvez seja suficiente registar e consultar pedidos de forma consistente antes de acrescentar notificações ou relatórios. Essa escolha pode mudar depois, mas permite discutir uma necessidade completa em vez de começar por uma coleção de botões.
É a mesma lógica de usar IA no negócio para além do chatbot: partir do trabalho que precisa de acontecer. A ferramenta passa a ter um lugar definido no processo, e a especificação consegue explicar como a aplicação contribui para o resultado sem lhe atribuir todas as responsabilidades da equipa.
Para preparar o próximo passo, consulta Criar produtos digitais com IA.
Usa as perguntas para fechar escolhas importantes
As perguntas devem reduzir a incerteza que afeta o comportamento, começando pelas decisões com mais consequências. Quem pode fazer cada ação, que informação é obrigatória e quando um pedido muda de estado são bons pontos de partida. Questões sobre aparência podem esperar quando ainda não está definido o funcionamento central.
Ao desenvolver uma plataforma de apoio com pedidos de ajuda, precisei de responder a muitas perguntas para esclarecer o que queria que acontecesse. A ideia de ter um sistema de tickets parecia simples. O detalhe apareceu quando foi necessário explicar o comportamento da plataforma, os acessos e a relação entre as suas partes.
Na oficina hipotética, pergunta primeiro quem pode marcar um pedido como concluído. Se qualquer pessoa puder fazê-lo, o processo será diferente de um sistema em que essa decisão pertence ao técnico responsável. A resposta muda as ações disponíveis, a informação mostrada e os casos que precisam de ser verificados.
Pede à IA que explique por que precisa de cada decisão importante e apresente opções compreensíveis. Se uma pergunta mistura várias escolhas, divide-a. É mais fácil avaliar a consequência de permitir reabrir um pedido concluído do que responder a um parágrafo que mistura estados, notificações, permissões e desenho do painel.
Nem todas as perguntas têm de ficar respondidas antes da primeira construção. Algumas podem ser adiadas se não afetarem o percurso escolhido. Regista esse adiamento e o seu alcance, para que uma ausência de decisão não seja interpretada mais tarde como autorização para inventar uma regra ou construir uma funcionalidade.
Distingue dados, regras e decisões em aberto
A especificação deve separar a informação que existe das regras que a aplicação vai aplicar sobre ela. Deve também assinalar o que ainda não foi decidido. Essa distinção evita que exemplos se transformem em requisitos obrigatórios ou que uma hipótese sugerida pela IA passe a ser tratada como escolha aceite.
Um pedido de reparação pode ter identificação do equipamento, descrição do sintoma e contacto do cliente. Esses são dados. Impedir o encaminhamento quando falta informação essencial é uma regra, que precisa de indicar exatamente o que é essencial. A forma de avisar a receção pode continuar como decisão em aberto.
Também importa saber de onde vem cada informação e quem a pode corrigir. Se o cliente descreve o sintoma e o técnico regista o diagnóstico, os dois campos têm funções diferentes. Substituir um pelo outro pode apagar contexto que ajuda a compreender o pedido e a explicar a resposta posterior.
Ao dar contexto à IA com critério, inclui exemplos representativos e explica o papel de cada documento. Uma folha antiga pode mostrar como os pedidos eram organizados, sem determinar que todas as suas colunas devam existir na nova aplicação. A relevância do material depende da decisão que ajuda a tomar.
Escreve resultados que possas observar
Uma especificação útil descreve o resultado esperado em situações concretas, incluindo pelo menos as exceções que alteram a decisão principal. Troca palavras vagas por comportamentos observáveis. Em vez de pedir uma aplicação intuitiva, explica o que a pessoa deve conseguir encontrar, fazer e confirmar quando percorre a tarefa definida.
Na oficina, um caso pode começar com um pedido completo que ainda não tem técnico atribuído. Quando o responsável o atribui, o nome deve ficar associado ao pedido e visível para quem acompanha o trabalho. Esse resultado permite verificar uma função sem depender de uma opinião genérica sobre a qualidade do painel.
Outro caso pode ter informação insuficiente sobre o equipamento. A aplicação deve mostrar o que falta e manter o pedido no estado previsto, em vez de o apresentar como pronto para análise. A exceção obriga a esclarecer a relação entre os dados disponíveis e a ação permitida naquele momento.
Pede que a IA confronte os exemplos com as regras e procure contradições antes de implementar. Se um caso aceite exige uma ação que outra regra proíbe, há uma escolha por resolver. Encontrar essa incoerência no documento permite discuti-la antes de existirem ecrãs e dados dependentes de interpretações diferentes.
Entrega uma primeira versão delimitada da especificação
A primeira especificação deve conter o percurso escolhido, as regras aceites, os exemplos de validação e os limites do que será construído. Inclui as questões adiadas e as ações que exigem uma decisão tua. Pede uma leitura de confirmação para perceber se a IA entendeu o mesmo resultado antes de avançar.
Essa confirmação pode ser uma explicação curta do percurso, acompanhada das decisões que têm maior impacto. Se a IA repetir apenas a lista de funcionalidades, ainda não sabes se compreendeu a relação entre elas. No exemplo da oficina, interessa que consiga explicar quando um pedido está pronto para ser encaminhado.
O passo seguinte é planear a construção da aplicação a partir dessa base. A especificação descreve o comportamento pretendido; o plano organiza o trabalho para o obter e verificar. Manter essa distinção ajuda a rever a implementação sem deixar que uma escolha técnica altere silenciosamente uma regra do negócio.
Durante a construção vão surgir perguntas novas, e algumas respostas podem melhorar a ideia inicial. Atualiza a especificação quando aceitares uma mudança relevante, indicando o que substituiu a decisão anterior. Assim, o documento continua a orientar o trabalho em curso e permite perceber por que razão a aplicação tem o comportamento que foi escolhido.