Do documento ao experimento: toy e produção

O primeiro incremento não precisa ser um chatbot. Para aprender se o brief captura o problema, bastam fixtures de tickets sintéticos, um fluxo manual descrito, exemplos de sugestões opcionais e um checker determinístico. Essa escolha economiza integração antes de saber se a dor existe. Ela também preserva uma alternativa sem IA capaz de ganhar no teste.

No toy offline, examples/check-brief.mjs lê o documento e falha se faltar papel, hipótese refutável, owner, alternativa sem IA, evidências ausentes ou rollback. Um teste negativo deliberado demonstra que o checker não aceita um brief ornamental. A implementação não mede tempo de atendimento. Isso é uma lacuna explícita, não um defeito escondido. Futuros incrementos podem usar TypeScript, Node.js LTS, PostgreSQL e interface web simples como stack didática, com versões fixadas na sessão que construir o app. Escolher essas ferramentas hoje não valida a oportunidade.

Num piloto autorizado, o contrato seria mais exigente. Regras determinísticas do backend controlariam tenant, autorização, SLA, estados e atribuição. IA apenas sugeriria categoria e resumo com base em texto permitido. O agente veria a origem, poderia corrigir ou rejeitar e confirmaria a ação. O backend validaria qualquer comando, independentemente do que a interface ou modelo disser. Não haveria resposta externa automática, cobrança real nem deleção de dados de terceiros. PII seria minimizada; logs, redigidos; retenção e acesso, aprovados antes de ingestão. Um prompt não é controle de isolamento entre tenants.

Cada efeito precisa de dono, permissão, evidência e reversão. Alterar categoria exige permissão do agente, evento auditável sem texto sensível e retorno ao valor anterior quando viável. Abrir um piloto exige consentimento da organização, owner operacional e botão de desligamento. Mesmo uma interface “somente sugestão” tem efeito: pode induzir decisão errada. A pessoa que opera precisa poder perceber incerteza e manter o caminho manual.

Não temos evidência de que uma arquitetura com modelo seja necessária. Primeiro, compare uma taxonomia simples e campos melhores com o fluxo atual. Se a maior parte do atraso vier de falta de agente disponível, nenhuma classificação automática resolve o gargalo. Se o problema estiver na definição de filas, melhorar a regra pode superar o modelo com menor custo e risco. Essa possibilidade deve permanecer aberta até observarmos o trabalho.

Autonomia negociada, em dois contextos

Uma equipe de tickets recebe demandas fechadas. Uma equipe de produto tende a receber um problema e negociar solução. A distinção ajuda, mas organizações reais misturam os dois modos. É possível começar discovery em uma equipe de tickets sem fingir que recebeu mandato para mudar política, falar com clientes ou gastar orçamento.

Na equipe de tickets, proponha uma conversa curta com quem prioriza e quem opera suporte: “Posso gastar uma janela definida para mapear fluxo e comparar uma alternativa sem IA antes de estimar o chatbot? Preciso de acesso supervisionado a agentes, sem dados sensíveis, e retorno na sexta. Trago brief e incertezas; a decisão de prioridade continua com você.” O acordo deve registrar tempo de investigação, pessoas autorizadas, dados permitidos, limite de gasto, decisão que você pode tomar sozinho e quem aprova piloto. Se não houver acesso a usuários, trabalhe com fluxo documentado e marque a evidência como ausente. Não substitua entrevista por imaginação.

Na equipe de produto, PM, designer, engenharia e suporte podem formular juntos a hipótese e os guardrails. Engenharia pode decidir implementação reversível e viabilidade; design, como agente identifica e corrige erro; PM, prioridade e coerência com estratégia; suporte, adequação à operação e escalonamento. O owner do piloto responde pelo go/no-go depois de ouvir essas perspectivas. O contrato não deve diluir responsabilidade até ninguém poder interromper o experimento. Em ambos os contextos, combine uma agenda de feedback: revisão do brief antes de construir, observação após cada rodada, decisão escrita de continuar, alterar ou parar.

Um contrato mínimo de autonomia responde: qual problema podemos investigar; quais dados e usuários podemos acessar; quais decisões são nossas; quais exigem aprovação; que efeito está proibido; quem decide conflito; em que data revisitamos. Ele protege tanto a equipe quanto o engenheiro. “Seja mais dono” sem essas respostas geralmente aumenta cobrança sem ampliar capacidade de agir.

Quatro modos de falha que merecem nome

1. Título novo sem autonomia

Sintoma: alguém recebe o título de Product Engineer, mas só descobre demandas após priorização e não pode conversar com suporte. Causa: mudança de nomenclatura sem contrato de acesso, decisão e responsabilidade. Resposta: negociar uma pequena janela de descoberta, um interlocutor operacional e um limite claro de decisão. Registre recusas e alternativas. Se a organização não autorizar, avalie trabalho dentro da fronteira disponível; não assuma resultados fora dela. O custo para o usuário é uma interface construída a partir de suposições que ninguém pode corrigir.

2. IA escolhida antes do problema

Sintoma: time compara modelos e custos de tokens antes de observar por que tickets aguardam. Causa: demo de tecnologia vira definição de problema. Resposta: mapear fluxo e baseline, testar formulário/regras e descrever condição em que IA seria melhor. Talvez a espera seja causada por escala de trabalho ou política de fila. Se for, classificador nenhum a remove. Para o cliente final, automação irrelevante pode tornar a experiência mais opaca.

3. Feature confundida com impacto

Sintoma: “100% dos tickets classificados” vira sucesso, mesmo com mais reatribuições. Causa: output é barato de contar; correção e efeito adverso exigem observação. Resposta: separar contrato técnico, adoção e outcome no painel; definir denominador e guardrails antes do piloto; revisar amostra de erros. A equipe pode concluir que o protótipo funciona tecnicamente e que não melhorou serviço. Essa conclusão evita custo recorrente desnecessário.

4. Decidir sem consultar quem suporta consequências

Sintoma: engenharia muda categorias e fluxo sem envolver agentes, gestor, design, privacidade ou quem atende reclamações. Causa: “ownership” interpretado como licença para absorver a decisão alheia. Resposta: mapear afetados, pedir revisão antes do efeito, nomear owner final e canal de escalonamento. Uma sugestão incorreta afeta agente e cliente; uma retenção longa afeta risco da empresa; uma nova taxa afeta comprador. Ouvir não elimina discordância, mas torna trade-offs visíveis.

Avaliar sem fabricar sucesso

Antes de medir benefício, defina unidade (ticket elegível), denominador (todos os tickets elegíveis recebidos no canal e janela), corte de observação (prazo fixo após chegada para cada ticket), método (eventos de chegada, primeira atribuição, confirmação/correção por amostra), segmentos (tipo e complexidade) e limites (sazonalidade, diferença entre agentes, registros ausentes). Registre quantos continuaram sem atribuição correta no corte; reporte sua proporção sobre todos os elegíveis. A mediana dos tempos concluídos usa somente tickets com evento observado e declara quantos entraram nesse cálculo. Registre custo de revisão do agente e casos em que a sugestão foi ignorada. Sem essas duas leituras, uma mediana menor pode refletir tickets mais fáceis.

Compare três condições quando viável: fluxo atual observado, alternativa sem IA e sugestão com IA mais revisão. Uma comparação sequencial pequena pode ensinar, mas não controla todas as diferenças. Não chame correlação de causalidade. Defina, antes, que evidência faria parar: erros de atribuição relevantes, exposição de dados, queda de confiança dos agentes, custo total incompatível ou ausência de melhora após janela suficiente. A meta didática provisória de 20% em duas semanas no brief não é critério aprovado; limiares operacionais exigem baseline e acordo local.

Para o brief offline, o critério é menor: os arquivos existem, a fixture válida passa, a incompleta falha, e não há campos que apresentem hipótese como evidência. Esse teste demonstra disciplina de decisão, não valor comercial. O passo seguinte é observar algumas interações autorizadas e atualizar o documento, inclusive se o problema inicial estiver errado.

Custo, segurança e reversibilidade fazem parte da hipótese

O custo de uma sugestão inclui integração, processamento, revisão humana, monitoramento, incidentes, treinamento e oportunidade perdida. A alternativa sem IA tem custo de manutenção das regras, mas pode ser mais barata e previsível. Estime com dados locais; não publique retorno financeiro derivado de fixture. A decisão de continuar deve considerar o serviço prestado ao cliente, não apenas preço por chamada.

Tickets podem conter nomes, contratos, senhas ou detalhes de negócio. Mesmo uma prova de conceito deve usar dados sintéticos até existir base autorizada para tratamento. Para piloto real: minimizar texto enviado, restringir tenant e papéis no backend, redigir logs, estabelecer retenção, consentimento e procedimento de exclusão com responsáveis. Não alegamos certificação ou conformidade legal. A revisão de jurídico/privacidade pertence a quem tem essa função. Se um provedor externo for considerado, documente fluxo de dados e contrato antes do envio.

Reversibilidade é funcionalidade: manter o fluxo manual; habilitar a sugestão por grupo; desativá-la sem quebrar estados; preservar evidência mínima para investigar erro; evitar migração que obrigue todos a usar modelo. O custo de voltar deve caber na mesma reunião que aprovou avançar. Uma feature que só pode ser desligada por deploy arriscado reduz autonomia operacional justamente quando mais importa.

Checklist de partida

• Escrevi problema em termos de comportamento e consequência, antes da solução?
• Separei usuário, comprador potencial e afetado, com interesses e riscos distintos?
• Descrevi alternativa atual como observada ou hipótese explícita?
• Comparei alternativa sem IA e explicitei condição para considerar IA?
• Defini outcome, unidade, denominador, janela, método e guardrails?
• Listei evidências ausentes sem tratar fixture como entrevista?
• Registrei owner, limites de autonomia, acesso autorizado e agenda de feedback?
• Cada possível efeito tem permissão, evidência e rollback?
• Testei checker válido e inválido e li o resultado real em verification.md?

Três exercícios para a primeira semana

Básico — reescreva um ticket. Pegue “adicionar chatbot” e produza duas frases: problema observável e hipótese refutável. Inclua usuário, medida e um guardrail. Critério: uma pessoa de suporte consegue dizer que observação refutaria a proposta. Solução comentada: “Atribuições podem demorar porque agentes precisam interpretar texto livre; vamos comparar mediana até atribuição correta e reatribuições com fluxo atual.” Ainda falta baseline; isso é honestidade, não incompletude a esconder.

Intermediário — negocie autonomia. Escreva um pedido de 30 minutos de observação autorizada, uma janela de revisão do brief e uma lista de decisões reservadas ao owner. Critério: quem recebe sabe exatamente que tempo, dados e pessoas seriam envolvidos, e pode aceitar uma parte sem aceitar o piloto. Solução comentada: pedir acesso supervisionado a uma fila sem dados sensíveis para observar etapas, devolver achados até sexta e deixar mudança de SLA, gasto e implantação com responsáveis existentes. Se o acesso for negado, registrar lacuna e trabalhar com documentação.

Avançado — desenhe a comparação. Defina eventos, denominador, três condições e regra de parada para DeskPilot. Critério: tickets sem atribuição não somem; erros têm severidade; diferença de complexidade é relatada; nenhuma porcentagem fictícia aparece. Solução comentada: registrar chegada, atribuição, confirmação e reatribuição; comparar baseline observado, formulário/regras e sugestão revisada em janelas acordadas; segmentar por tipo; parar diante de exposição de dados ou erro grave. Aceitação da sugestão é diagnóstico, não outcome.

Glossário e próximo passo

Outcome é mudança observada para usuário ou negócio, com efeitos adversos considerados. Output é entrega produzida. Baseline é medida do fluxo existente, com método e janela. Guardrail é indicador ou limite que evita otimizar uma medida à custa de dano. Tenant é a fronteira de dados de uma organização numa aplicação compartilhada. Rollback é o procedimento de voltar ao estado seguro, não a esperança de que nada falhe.

O primeiro resultado do Product Engineer aqui não é código impressionante: é uma decisão que pode ser negada com evidência. O DeskPilot saiu do ponto zero com um problema candidato, pessoas distintas, comparação possível e limites escritos. Ainda faltam clientes, entrevistas e baseline. No capítulo 02 previsto desta série, a próxima tarefa será verificar quem sofre a demora, como trabalha hoje e se esse recorte merece um produto. Até lá, o brief deve permanecer v0.

Fontes e limites

• PostHog, What is a product engineer?. Handbook vivo, consultado em 27/09/2026. Descreve prática da empresa; não prova padrão universal ou ganho de produtividade.
• Marty Cagan / SVPG, Product vs Feature Teams, 29/08/2019; consultado em 27/09/2026. Framework autoral; nomenclatura declarada não padronizada.
• DORA, State of AI-assisted Software Development 2025, 2025; consultado em 27/09/2026. Contexto de pesquisa, sem inferência causal sobre carreira ou DeskPilot.