IA no project charter: o rascunho em minutos e o que revisar sempre

Um termo de abertura de projeto que levava duas semanas para ficar pronto agora sai em quarenta segundos. Isso é verdade, é novo e é menos útil do que parece, porque o que levava duas semanas nunca foi a redação.

Usar IA no project charter funciona bem em uma metade do documento e falha de forma previsível na outra. Ela estrutura um problema descrito de qualquer jeito, sugere unidades de medida, propõe fronteiras e padroniza a escrita. E inventa meta, inventa ganho, embute a solução no enunciado do problema e escreve cargo onde deveria haver nome.

A diferença entre as duas metades tem uma regra por trás. Onde o trabalho é transformar texto em texto, o modelo é bom. Onde o trabalho é trazer informação que não estava na entrada, ele preenche com o que soa plausível, e plausível é justamente o que passa despercebido na revisão.

Este artigo percorre o documento campo a campo: o que pedir, o que proibir no prompt, que número nunca aceitar, que campo deixar em branco de propósito, e por que criticar um charter pronto rende mais do que gerar um do zero.

No meio, um exemplo inteiro: uma descrição solta escrita por um coordenador de manutenção, o charter que o modelo devolveu a partir dela e a revisão campo a campo marcando o que estava errado. O caso foi montado para este artigo, no formato do Kit Lean Seis Sigma da Voitto. Os números são ilustrativos e internamente consistentes, e não descrevem uma empresa real.

Escrever o charter é a parte fácil

O termo de abertura de projeto cabe em uma página. Tem título, enunciado do problema, meta, escopo, fora de escopo, prazo, patrocinador, dono do processo, equipe, indicador e ganho esperado. Nenhum desses campos é difícil de redigir.

A dificuldade está em outro lugar. Cada campo é uma decisão, e a maior parte delas não é do time do projeto. Definir a meta é decidir o que a empresa vai perseguir nos próximos meses. Definir o escopo é decidir o que fica de fora. Definir o ganho é assumir um número que a controladoria vai cobrar depois.

Vale a mesma lógica de um relatório A3: o documento é curto de propósito, e a brevidade força a decisão. Um charter de quatro páginas normalmente é um charter em que ninguém decidiu nada e todo mundo escreveu.

Guarde esse ponto, porque ele explica quase tudo o que vem a seguir. A IA cobre a parte fácil com folga e não encosta na parte difícil. O risco é confundir uma coisa com a outra.

Os campos do termo de abertura e quem responde por cada um

Das onze linhas, a IA resolve uma sozinha e ajuda em cinco. Nas cinco restantes ela não tem a informação, e o que sai é preenchimento com cara de resposta. Essa é a fronteira inteira do assunto, e o resto do artigo detalha os dois lados dela.

O que a IA faz bem no termo de abertura

Começar pelo que funciona evita a caricatura. Usar IA no project charter resolve problemas reais, e quem já escreveu charter em equipe reconhece todos eles.

• Transformar descrição solta em problema estruturado. A pessoa descreve a dor em três frases desorganizadas e o modelo devolve sujeito, local, frequência e efeito separados.
• Sugerir como transformar o problema em número. Ela propõe unidades de medida plausíveis: percentual de atendimento, horas de parada, peças por mil, dias de ciclo.
• Propor escopo e fronteiras. A primeira lista sai larga, mas explicita processos que o time não tinha considerado, inclusive os que vão virar fora de escopo.
• Redigir de forma padronizada. Dez charters escritos por dez pessoas viram dez formatos. Com o modelo, viram um só, e isso facilita a leitura em comitê.
• Gerar a primeira versão em minutos. O que era uma folha em branco vira um rascunho completo antes da reunião começar.

O último item é o que mais muda o comportamento de uma equipe, e o mecanismo é o mesmo que aparece na aplicação de IA na fase Definir: criticar um texto existente é muito mais fácil do que produzir um do zero.

Por que um rascunho ruim vale mais que uma folha em branco

Com um rascunho na tela, a reunião começa em outro ponto. A primeira fala costuma ser "isso aqui está errado", e essa é uma fala produtiva. Discordar de uma frase concreta gasta menos energia do que formular a primeira frase.

O ganho de tempo é real, mas não é o principal. O principal é que o rascunho torna visível o desacordo que estava escondido. Quando o modelo escreve uma meta de 80% e o patrocinador diz que 20% já seria excelente, uma divergência que ia aparecer no quarto mês apareceu no primeiro dia.

O erro que ela comete quase sempre: a solução dentro do problema

Peça um charter a qualquer modelo e observe o campo problema. Em oito de cada dez vezes ele vai ter uma destas formas: "a ausência de X causa", "a falta de um sistema de Y gera", "a inexistência de um padrão para Z resulta em".

Isso não é enunciado de problema. É enunciado de solução escrito ao contrário. Dizer que a ausência de um sistema causa a falta de peça é afirmar, antes de qualquer análise, que a causa é a ausência do sistema e que a solução é implantá-lo.

O custo disso é alto e chega tarde. Um projeto que começa com a causa decidida não investiga: ele executa. Se a causa verdadeira for outra, e costuma ser, o time descobre no terceiro mês, com o orçamento comprometido e o patrocinador já anunciando o sistema novo na reunião de diretoria.

É o mesmo motivo pelo qual o método DMAIC separa Definir de Analisar por um portão formal. A fase Definir existe para descrever o sintoma com precisão, e a proibição de nomear a causa ali não é preciosismo metodológico. É proteção contra exatamente esse erro.

Por que ela erra: o texto de origem já chega contaminado

O modelo não inventa essa construção: ele a herda de duas fontes. A primeira é o texto que você entrega. Quase ninguém descreve uma dor sem já propor o remédio. A frase típica que chega a um modelo é "precisamos implantar um sistema de estoque porque falta peça". A solução está na oração principal e o problema na subordinada, e o modelo reproduz essa hierarquia com fidelidade.

A segunda é o corpus em que ele foi treinado. A internet está cheia de charters de exemplo, e a maioria deles tem a solução no título. O padrão estatístico que o modelo aprendeu é esse, não o padrão que um bom livro de método recomenda.

A consequência prática é direta: pedir "escreva o problema" não resolve, porque o modelo acredita estar descrevendo um problema. É preciso proibir a construção específica, com palavras, e não confiar na instrução genérica de ser rigoroso.

Como pedir que ela separe problema de solução

A instrução que funciona é explícita e negativa. Em vez de descrever a qualidade desejada, proíba a construção indesejada e nomeie a estrutura obrigatória.

1. Proíba as fórmulas: "não use as expressões ausência de, falta de, inexistência de, nem a falta de nenhum sistema, ferramenta, padrão ou treinamento como causa".
2. Exija a estrutura do sintoma: o que acontece, com que frequência, onde, desde quando, e qual o efeito visível para o cliente ou para o processo seguinte.
3. Peça a separação explícita: um bloco com o problema e outro, marcado como hipótese, com as soluções que apareceram no texto de origem.
4. Mande devolver as soluções capturadas: "liste separadamente toda solução que estava implícita no texto que recebi e que você retirou do enunciado".

O quarto item é o mais útil e o menos usado. Ele transforma o modelo em detector: a lista que volta mostra quantas decisões já estavam tomadas antes de o projeto começar, e essa lista costuma surpreender quem escreveu o texto original.

Quem quiser fechar o cerco pode pedir também o SIPOC do processo antes do charter. Delimitar fornecedor, entrada, processo, saída e cliente obriga a nomear onde o problema acontece, e enunciado com fronteira definida é mais difícil de contaminar com solução.

A meta que ela inventa sem linha de base

O segundo erro estrutural aparece no campo meta. Peça uma meta e o modelo entrega uma, sempre, mesmo sem ter recebido um único número. Reduzir em 50%, aumentar em 30%, atingir 95%. Os valores são redondos, plausíveis e completamente arbitrários.

Meta sem linha de base não é meta, é desejo. Reduzir 50% de um indicador que hoje está em 8% é uma coisa. Reduzir 50% de um indicador em 0,4% é outra, provavelmente impossível de medir com o volume de dados que a empresa tem.

A regra de ouro é simples: o campo meta fica vazio até a linha de base existir. Se o charter precisa circular antes disso, escreva "a definir após a medição da linha de base, prevista para tal data". Campo vazio é honesto, campo chutado é dívida.

A sequência correta inverte a ordem habitual. Primeiro mede-se o valor atual, depois se estabelece o alcançável, e só então a meta é escrita. É o mesmo encadeamento do ciclo PDCA, em que o planejar depende de um estado inicial conhecido.

Nenhum número que a IA produziu sozinha entra no charter

Essa regra vale para além da meta, e é a única deste artigo que não admite exceção. Todo número do termo de abertura precisa ter origem rastreável: um relatório, uma consulta ao sistema, uma contagem feita por alguém, uma estimativa assinada por quem entende do processo.

Um teste barato revela o problema em segundos: pergunte ao modelo de onde veio cada número. A resposta vai ser uma explicação metodológica bem escrita sobre como aquele valor poderia ser estimado, e não a fonte de onde ele saiu. Isso basta para reprovar o campo. Quem quiser ver a cadeia completa funcionando pode olhar um exemplo de DMAIC fechado, em que cada número tem período e fonte declarados.

O escopo largo demais é o comportamento padrão

O terceiro erro é mais silencioso. Peça o escopo e o modelo lista todas as áreas que tocam o assunto: almoxarifado, compras, manutenção, PCP, suprimentos, TI e qualidade. Cada uma delas tem alguma relação com o problema, então nenhuma parece errada.

O corretivo é escolher uma fatia com dado, dono e volume relevante. Um diagrama de Pareto sobre as ocorrências costuma resolver isso em uma tarde: se três famílias de item respondem por 70% das faltas, o escopo é essas três famílias, e o resto vai para o campo fora de escopo com essa justificativa escrita.

Quando a dúvida é entre frentes de tamanho parecido, uma matriz esforço e impacto resolve mais rápido que uma reunião. O que não funciona é pedir ao modelo que priorize: sem dado de frequência e sem custo real de implantação, a priorização dele é ordenação de palpite.

O campo fora de escopo merece atenção especial porque é o que a IA escreve pior. Ela produz negativas genéricas do tipo "não inclui mudanças estruturais". O fora de escopo útil é específico e nomeia o que alguém esperava: "não inclui o almoxarifado da unidade 2" ou "não inclui troca do ERP".

Os campos que ela não tem como preencher

Há uma classe de campo em que o problema não é qualidade de resposta. É que a resposta não está no texto de entrada nem em conhecimento geral, e nenhum prompt melhora isso.

• Patrocinador. Não é um cargo, é uma pessoa com verba, agenda e disposição para destravar conflito entre áreas. O modelo escreve "Diretor de Operações" e isso não é informação.
• Dono do processo. Quem fica com a rotina depois que o projeto acaba. É o campo que mais determina se o ganho sobrevive ao encerramento, e o único jeito de preenchê-lo é perguntar e ouvir sim.
• Disponibilidade do dado. Se o indicador existe no sistema, com que granularidade, desde quando, e se alguém tem acesso. O modelo sugere indicadores elegantes que a empresa não consegue medir.
• Critério de ganho. Como a economia será contabilizada, com que taxa, em que conta, validada por quem. Isso se combina com a controladoria antes, nunca depois.

O critério de ganho é o que mais gera briga tardia. Um projeto de Lean Seis Sigma que reduz hora extra pode ter o ganho reconhecido como economia direta ou como capacidade liberada, e a diferença entre as duas leituras chega a ser de uma ordem de grandeza. Acordar isso no charter custa uma conversa de trinta minutos, e não acordar custa a credibilidade do projeto no fechamento.

O exemplo: a descrição solta que chegou ao modelo

O que vem a seguir é um caso completo: o texto de entrada, o charter gerado e a revisão. O texto abaixo é o tipo de descrição que realmente chega, escrita por um coordenador de manutenção em um campo livre.

"A gente precisa implantar um sistema de gestão de estoque no almoxarifado, porque está sempre faltando peça quando a manutenção vai executar a ordem. O pessoal reclama muito. Mês passado perdemos uma parada por falta de rolamento e ficou máquina esperando. Queria um projeto para resolver isso até o fim do ano."

Repare no que já está decidido nesse parágrafo. A solução está na primeira oração, a causa está implícita na palavra sistema, o prazo está na última frase, e o único dado concreto é uma ocorrência isolada citada de memória. Não há linha de base, não há período, não há volume.

O charter que o modelo devolveu

Entregue essa descrição a um modelo pedindo um termo de abertura completo e o resultado sai em segundos, bem formatado e com todos os campos preenchidos. Abaixo, o que voltou, reproduzido sem correção.

Lido rápido, ele passa: está completo, coerente e sem erro de português. E é um charter ruim em dez dos onze campos.

A revisão, campo a campo, marcando o que estava errado

A revisão abaixo foi feita na ordem dos campos, sem pular nenhum, com a pergunta fixa: isso é fato, decisão tomada por alguém, ou texto que o modelo produziu para preencher espaço?

Vale olhar duas linhas de perto. A linha de base não foi corrigida: ela não existia. O modelo escreveu uma meta de redução sem nunca ter dito qual era o valor atual, e o documento parecia completo mesmo assim. Um charter pode estar inteiro na aparência e não ter o número mais importante.

A revisão campo a campo como rotina, não como exceção

O exemplo acima não é um caso extremo escolhido a dedo. É o comportamento padrão, e por isso a revisão precisa ser um procedimento fixo, com a mesma pergunta aplicada a todos os campos, na ordem.

1. Isso é fato, decisão ou preenchimento? Fato tem fonte. Decisão tem quem decidiu. Preenchimento não tem nenhum dos dois e sai do documento.
2. Esse número tem período e origem? Sem período declarado, nenhum valor entra, nem como referência.
3. Esse campo nomeia uma pessoa ou um cargo? Cargo em campo de responsabilidade equivale a campo vazio.
4. Esse texto serviria a outro projeto qualquer? Se serviria, é genérico, e genérico em charter é ruído.
5. Alguém fora do time entende o escopo pela leitura? Se precisa de explicação verbal, a fronteira não está escrita.

As pendências que sobrarem não ficam no charter. Elas viram um plano de ação curto, com dono e data, e o charter só é assinado quando ele estiver fechado. Campo pendente com dono é gestão; campo pendente sem dono vira campo inventado na véspera da apresentação.

Criticar um charter pronto rende mais que gerar do zero

O melhor uso de IA no project charter é o que quase ninguém faz. Em vez de pedir um charter, entregue o charter que a equipe já escreveu e peça uma crítica estruturada.

A assimetria tem uma explicação simples. Ao gerar, o modelo precisa inventar o que não sabe, e inventa bem demais. Ao criticar, ele trabalha sobre um texto existente, e apontar solução embutida, meta sem base, escopo largo e risco genérico é reconhecimento de padrão, que é onde ele é forte.

• "Aponte todo trecho do campo problema que afirma ou sugere uma causa."
• "Liste todo número sem período, fonte ou método de apuração declarados."
• "Diga quais riscos listados serviriam a qualquer projeto e devem ser trocados."
• "Aponte cada responsabilidade atribuída a cargo em vez de pessoa."
• "Escreva as três perguntas que o patrocinador provavelmente fará e que o documento não responde."

A última é a mais valiosa. Ela devolve as lacunas na forma em que elas realmente aparecem, que é como pergunta em reunião, e costuma acertar duas das três. É o mesmo princípio que faz a IA render mais em melhoria contínua quando usada para questionar do que para concluir.

O prompt que funciona

O prompt abaixo incorpora as restrições discutidas. Ele é longo de propósito: instrução curta devolve charter genérico, e o tamanho aqui é o que separa o resultado útil do resultado bonito.

1. Contexto. Cole a descrição solta como está, sem limpar. As contradições e a solução embutida são informação, e limpar antes esconde o que precisa ser detectado.
2. Proibições. "Não escreva causa no campo problema. Não use ausência de, falta de ou inexistência de. Não proponha meta numérica. Não estime ganho financeiro. Não preencha patrocinador nem dono do processo."
3. Estrutura obrigatória. Liste os campos na ordem e mande escrever a expressão A DEFINIR em todo campo que dependa de dado ou de decisão de outra pessoa.
4. Saídas extras. "Liste as soluções implícitas que retirou do enunciado. Liste os dados que precisam ser levantados para preencher cada A DEFINIR, com a fonte provável de cada um."
5. Fatia. "Proponha três recortes de escopo possíveis, do mais estreito ao mais largo, e diga o que cada um deixa de fora."

O quinto item substitui a pergunta que não funciona. Pedir o escopo certo é pedir uma decisão que depende de dado que o modelo não tem. Pedir três recortes com o que cada um exclui é pedir alternativas, e a escolha continua com quem pode escolher.

O protocolo, em sete passos

Fechando o assunto em forma de rotina, do primeiro rascunho ao documento assinado.

1. Escreva a descrição solta sem editar. Inclusive a solução que já está na cabeça de quem descreve, porque ela vai precisar ser identificada e retirada.
2. Gere o rascunho com as proibições ativas. Campo que dependa de dado ou de pessoa volta como A DEFINIR, e a lista de soluções implícitas volta junto.
3. Meça a linha de base antes de discutir meta. Com período declarado e fonte nomeada. Sem isso, o campo meta permanece vazio, mesmo que o documento precise circular.
4. Feche escopo, patrocinador, dono e critério de ganho em conversa. São os quatro campos que não saem de prompt nenhum, e são eles que determinam se o projeto anda.
5. Revise campo a campo com as cinco perguntas. Na ordem, sem pular, marcando o que é fato, o que é decisão e o que é preenchimento.
6. Use o modelo como crítico da versão final. Peça as perguntas que o patrocinador fará e responda as que fizerem sentido antes da reunião.
7. Assine só com todos os A DEFINIR resolvidos. Ou com data e dono explícitos para cada um que continuar aberto.

O resumo do artigo cabe em uma frase. A IA no project charter encurta a redação e não encurta a decisão, e confundir as duas coisas é o que transforma um rascunho de dez segundos em um compromisso de seis meses.

Quem quiser padronizar isso na empresa pode amarrar o charter ao formato que já usa, seja o 5W2H para o plano de execução ou o portão de Definir do método que a equipe segue. O documento muda de nome conforme a escola, e a fronteira entre o que a máquina redige e o que a organização decide continua exatamente no mesmo lugar.