O que só você pode fazer no projeto, e o que não deveriam estar te pedindo

A lista existe. Ela mora no contrato, e não foi escrita para você.

A pergunta costuma chegar tarde e em voz baixa. Você já entendeu a proposta, já viu o preço, e falta uma coisa que ninguém escreveu: o que vai depender de você depois que isso começar. Quanto do seu tempo, quantas conversas, e o que acontece se você não souber responder o que te perguntarem.

Perguntar isso antes de fechar é a coisa certa a fazer, e quem entrega deveria ter dito primeiro.

Procurei onde essa resposta está publicada. Ela existe, e mora em dois lugares. O primeiro é a cláusula de contrato. Uma minuta que eu li obriga o cliente a fornecer condições técnicas, informações e documentação, declara que o cumprimento dos prazos depende diretamente disso, e diz o que acontece se faltar: fica autorizada a majoração dos prazos, sem ônus nem penalidade. É uma frase honesta, e é lida uma vez, na assinatura, por quem já decidiu. A consequência que ela publica protege quem entrega.

O segundo lugar é conteúdo sobre como conduzir o cliente, escrito para outras agências. Resultado após resultado ensinando o fornecedor a definir responsáveis, combinar prazos de aprovação e abrir canal de comunicação. É bom material, e o destinatário é sempre o mesmo. Nunca é você.

Achei uma única página que publica a lista voltada a quem contrata, e ela para exatamente onde este texto começa: enumera o que o cliente deve fazer e não diz o que continua sendo do fornecedor.

O que segue tem os dois lados. Não é contrato, não estima o seu tempo em horas e não vai te cobrar nada. É a divisão que eu uso, com o critério que a produz, para você conferir se o que estão te pedindo cabe do seu lado da linha.

Duas perguntas separam o que é seu do que é meu.

O papel do cliente não é a lista de tarefas que sobra depois que o fornecedor separa a parte dele. Se fosse, ela mudaria conforme a disposição de cada fornecedor, e é mais ou menos isso que acontece hoje.

Existe um critério melhor, e ele não é meu. Está na documentação de adoção de uma das plataformas com que eu trabalho, e separa funções de um jeito que vale para qualquer projeto. Uma delas responde por definir o que o dado significa, para que ele é usado e quem pode acessá-lo. Outra responde por construir, manter, publicar e proteger. Uma terceira decide os usos apropriados e os inadequados. Repare que a primeira e a terceira não descrevem trabalho técnico. Descrevem conhecimento do negócio e autoridade sobre ele.

Daí saem as duas perguntas.

Isso só existe dentro da sua empresa? Tem informação que não está em documento nenhum, não se descobre por pesquisa e não se deduz olhando o sistema. Ela mora na cabeça de quem opera. Se a resposta certa só existe aí dentro, é sua.

Isso só você pode autorizar? Tem decisão que precisa de alguém com nome e autoridade para responder por ela. Liberar um acesso, escolher o que entra e o que fica de fora, dizer que aquele número representa o negócio. Se ninguém pode assinar no seu lugar, é sua.

Tudo o que não passa em nenhuma das duas é meu. Inclusive a parte que costuma ser empurrada: descobrir o que perguntar, traduzir o que você respondeu para uma estrutura que funcione, propor o que você não sabia que era possível, testar antes de te mostrar, e escrever o que foi decidido para que continue explicável depois.

O teste vale nos dois sentidos, e é essa simetria que impede a lista de virar cobrança. Se uma tarefa pode ser transferida para quem entrega sem perda de qualidade, ela não é sua. Pedir mesmo assim não é colaboração, é transferência indevida.

As cinco participações abaixo são os lugares em que as duas perguntas dão sim. Em cada uma: o que é seu, o que continua sendo meu, e o sinal de que a linha foi cruzada.

O contexto que a sua operação tem e nenhum documento registra.

É a primeira participação e a mais difícil de substituir. Todo processo tem uma versão escrita e uma versão real, e a distância entre as duas é onde moram as exceções: o cliente que sempre paga fora do prazo e mesmo assim continua sendo atendido, a categoria que na planilha se chama de um jeito e no sistema de outro, a regra que nasceu de um problema específico que ninguém mais lembra qual foi.

Nada disso está documentado. Não porque a sua empresa seja desorganizada, e sim porque exceção é o que sobra depois que a regra foi escrita.

O que é seu: contar como funciona hoje, com as exceções, e dizer por que a regra é assim quando você souber. Se não souber, dizer isso também vale, e vale mais do que inventar uma justificativa.

O que continua sendo meu: perguntar direito. Refazer a pergunta de outro jeito quando a primeira não trouxe nada. Percorrer um caso real com você em vez de pedir um documento que você teria que escrever. E não confundir a sua falta de tempo com falta de informação, que são coisas diferentes e pedem respostas diferentes.

O sinal de que a linha foi cruzada: quando te pedem a solução em vez do problema. Você conta que o pedido do cliente chega por mais de um canal e alguém responde perguntando qual integração você prefere usar. Descrever a operação é seu; decidir o que fazer com ela é meu, e trocar isso de lugar transfere para você um risco que você não tem como avaliar.

Em automação essa participação fica mais visível que em qualquer outro tipo de projeto, porque o fluxo só se sustenta se as exceções estiverem descritas antes de ele ser desenhado. O que precisa estar mapeado antes de um fluxo entrar no ar, incluindo o que fazer quando um passo falha.

Acesso não é tarefa de quem tem tempo. É ato de quem tem autoridade.

A segunda participação parece a mais simples e é a que mais atrasa projeto. Liberar acesso a uma conta, a um sistema ou a uma base não é tarefa administrativa. É um ato que só quem tem autoridade pode praticar, e as plataformas são explícitas sobre isso: para adicionar ou remover uma pessoa numa conta de análise, é preciso estar no papel de administrador daquela conta. Não existe atalho, e não existe versão de mim que faça isso no seu lugar.

O que é seu: saber quem, dentro da empresa, pode conceder cada acesso, e acionar essa pessoa. Se a resposta for que ninguém sabe, isso não é falha sua: é o primeiro achado do projeto, e ele aparece antes de qualquer construção.

O que continua sendo meu: dizer exatamente de que acesso eu preciso, para quê e por quanto tempo. Pedir pelo canal seguro em vez de por mensagem. Avisar cedo, e não na véspera. E seguir trabalhando no que não depende daquele acesso enquanto ele não chega, que é a parte que raramente aparece escrita em lugar nenhum.

O sinal de que a linha foi cruzada: pedido de acesso amplo, sem recorte e sem justificativa. Me dá acesso de administrador em tudo é conveniência de quem entrega, não requisito de projeto. Quando o recorte não é explicado, quem assume o risco é você.

Vale ser específico sobre o que trava, porque essa é a parte que costuma virar cobrança. Um acesso que demora não para o projeto inteiro: ele para exatamente a etapa que depende daquela fonte. O mapeamento continua, o desenho continua, as regras continuam sendo discutidas. O que muda é a ordem, e reorganizar a ordem é trabalho meu. A demora vira problema quando ninguém disse cedo o que estava parado, e dizer isso cedo também é meu.

Num painel, a quantidade de fontes define o tamanho dessa conversa, e cada fonte costuma ter um dono diferente dentro da empresa. Que tipo de acesso um painel exige, e como isso é combinado antes de o trabalho começar.

Decisão: recomendar é meu trabalho, escolher continua sendo seu.

A terceira participação é a que mais se tenta transferir, e a única que não vai.

Todo projeto tem escolhas que não são técnicas por natureza, mesmo quando chegam vestidas de técnica. O que entra na primeira versão e o que fica para depois. Qual problema resolver primeiro. O que o sistema pode fazer sozinho e o que precisa passar por uma pessoa. Nenhuma delas tem resposta certa fora do seu contexto, porque a resposta depende do que custa mais caro para você errar.

O que é seu: escolher, depois de ouvir as opções e as consequências. E dizer o que fica de fora, que é a metade da decisão que costuma ficar sem dono.

O que continua sendo meu: apresentar as opções em linguagem que você confere, com a consequência de cada uma declarada. Recomendar uma, com o motivo. E aceitar a sua escolha quando ela for diferente da minha recomendação, sem transformar isso em atrito nem em cláusula.

O sinal de que a linha foi cruzada: ele tem duas versões, e as duas são reconhecíveis. A primeira é te pedirem para escolher a ferramenta. Qual banco, qual plataforma de automação, qual modelo de linguagem: isso é decisão técnica com consequência técnica, e passar para você é passar um risco que você não tem como medir. A segunda é o inverso, e é mais silenciosa: te entregarem alternativas sem recomendação nenhuma. Apresentar opções sem dizer qual eu faria e por quê não é neutralidade. É devolver a decisão sem a informação que a torna possível.

Existe um caso em que essa participação não tem dono, e ele precisa ser nomeado sem rodeio. Quando ninguém dentro da empresa pode dizer o que fica de fora, o projeto não atrasa por falta de tempo nem de acesso. Ele atrasa porque a escolha vai sendo adiada, e cada semana produz uma versão diferente do escopo. Isso não é motivo para sermão, e também não é motivo para eu decidir sozinho. É motivo para parar e definir quem responde, antes de construir.

Num agente de IA a decisão vira limite, e o limite é explícito: o que ele pode responder, o que ele pode executar e em que ponto ele para e chama uma pessoa. Quais limites são combinados com você, e quem aprova cada um deles.

Validar é confirmar que representa o negócio, não que ficou bonito.

A quarta participação é a mais mal-entendida das cinco, e desfazer o mal-entendido é o ponto principal deste texto.

Validar é dizer se aquilo corresponde à realidade que você conhece. O total de vendas do mês bate com o que você fecha. A regra que define cliente ativo é a regra que a sua empresa usa. O texto da página descreve o que você realmente faz. É isso, e é só isso.

O que é seu: conferir contra o que você já sabe, e apontar quando não bate. Não é preciso saber por que não bate. Apontar sem saber a causa é uma contribuição completa, porque a causa é o meu trabalho.

O que continua sendo meu: te mostrar de um jeito que você confere sem aprender nada novo. Se para validar um número você precisa entender a ferramenta, eu montei errado, não você. E investigar a divergência que você apontou, inclusive quando ela vier sem explicação junto.

O sinal de que a linha foi cruzada: te cobrarem conhecimento técnico como condição para aprovar. Entender a ferramenta nunca foi papel do cliente, em nenhum tipo de projeto. Conduzir o que ficou pronto, sim, e as duas coisas são confundidas o tempo todo. Quando alguém sugere que você precisa aprender a ferramenta para poder aprovar, o que está sendo transferido é a obrigação de traduzir, e traduzir é de quem construiu.

Existe um limite honesto aqui, e ele me obriga tanto quanto a você: você não deveria aprovar o que não consegue compreender. Se o que te apresentaram não dá para conferir, a resposta certa não é confiar. É pedir que seja apresentado de outro jeito.

Na medição digital isso tem nome próprio: o que conta como resultado é decisão do seu negócio antes de ser configuração, e nenhuma ferramenta descobre isso sozinha. Como as ações que representam resultado são definidas com você antes de virarem evento. Numa página de campanha a validação é mais curta e igualmente sua: a oferta precisa estar descrita como você a apresentaria se estivesse na frente da pessoa. O ponto do processo em que a página passa pelas suas mãos.

Adoção: quem não usa por dentro não percebe quando algo sai do lugar.

A quinta participação é a única que não termina junto com o projeto, e é onde autonomia se separa de abandono.

Uma estrutura entregue continua funcionando sozinha por um tempo. Depois o negócio muda: entra um produto novo, a equipe cresce, o fornecedor de um sistema altera alguma coisa. Nada disso costuma quebrar o que foi construído de uma vez. O que acontece é mais discreto, e é que o resultado deixa de corresponder à realidade sem que ninguém repare.

Quem repara é quem usa. Não quem entende de tecnologia, quem usa. A pessoa que abre o painel toda segunda percebe que aquele número parou de fazer sentido antes de qualquer aviso automático.

O que é seu: ter alguém, com nome, que usa e responde por aquilo. Não é preciso que essa pessoa saiba construir, e não é preciso que seja a mesma que decidiu. É preciso que ela exista.

O que continua sendo meu: ensinar essa pessoa a conduzir o que ficou, no nível de quem opera e não de quem constrói. Deixar registrado por que cada coisa foi feita daquele jeito, para que continue explicável depois que eu sair de cena. E seguir disponível sem ser necessário, que é uma diferença que dá para conferir.

O sinal de que a linha foi cruzada: transformar autonomia em abandono. Entregar, mostrar numa conversa só e desaparecer não é te dar independência. É interromper o trabalho antes do fim. O sinal oposto vale igual: se depois de meses você ainda precisa de mim para tudo, eu também não terminei.

Num site institucional isso é visível porque a página envelhece em público. O serviço que mudou continua descrito do jeito antigo até alguém de dentro perceber. O que muda num site depois que ele entra no ar, e o que fica sob os seus cuidados.

Esta participação é o que torna verificável a promessa de autonomia que todo fornecedor faz, e a recíproca também vale: uma entrega que não deixou ninguém capaz de conduzi-la não cumpriu a promessa, por melhor construída que esteja. Como distinguir uma promessa de autonomia cumprida de uma apenas declarada.

Se a conversa começa pela sua lista de obrigações, o problema é anterior.

Falta o que esta divisão não resolve, e falta dizer de onde eu falo.

Começo pela parte incômoda. Eu escrevi a régua que define o que eu posso te cobrar e do que eu posso me eximir, e publiquei ela no meu próprio site. Isso não se resolve com um aviso de isenção, então prefiro apontar onde a régua pesa do meu lado. Ela me obriga a perguntar direito em vez de pedir documento pronto. Ela me obriga a recomendar, e recomendar é assumir responsabilidade por uma opinião. Ela me obriga a seguir trabalhando no que não depende de você enquanto espero, o que remove o argumento mais confortável que existe numa discussão de prazo. E ela me proíbe de usar conhecimento técnico como requisito para você aprovar alguma coisa, que é o jeito mais fácil de fazer alguém concordar sem entender. São obrigações que passam a ser exigíveis a partir de agora, e é assim que eu prefiro.

O que a divisão não faz. Ela não evita desacordo, porque discordar sobre o que é de quem é normal e se resolve conversando, não com uma lista. Ela não estima o seu tempo, e eu não vou estimar: isso depende do tipo de projeto, do estado do que já existe e de quantas pessoas precisam ser ouvidas. O que ela substitui é a pergunta quanto do meu tempo isso consome por uma pergunta que tem resposta, e a resposta cabe nas cinco participações acima: o que trava se eu não estiver na sala.

E existe o caso em que nenhuma das cinco tem dono. Ninguém consegue contar o processo com as exceções, ninguém pode liberar acesso, ninguém decide o que fica de fora, ninguém confere se o número representa o negócio, e não há quem vá usar depois. Quando isso acontece, o achado não é que você não está preparado. É que o projeto não começa por aí, e começar mesmo assim produz uma entrega que precisará ser refeita quando as pessoas aparecerem. Costuma se resolver numa conversa interna, e resolver antes sai mais barato que resolver depois.

Uma última coisa, e é o teste que eu apliquei em cada frase acima. Nenhuma delas deveria funcionar, recortada e sozinha, como defesa minha numa discussão de prazo. Se alguma funcionar, ela está escrita errada, e eu quero saber.