Como trabalhamos
Quatro passos, nesta ordem, sempre.
A ordem é o método. Nada é construído antes de ser definido, nada entra em produção antes de ser medido e nada é transferido sem as pessoas capazes de manter tudo funcionando.
01
Definir
Definir a tarefa, o responsável e a medida de sucesso antes de escolher qualquer modelo.
02
Instrumentar
Construir primeiro a bancada de avaliação, para distinguir melhora de sorte.
03
Integrar
Colocar no fluxo de trabalho existente, com fallbacks, logs e controle de acesso.
04
Transferir
Entregar o runbook, os testes e uma equipe capaz de operar sem a gente.
Como trabalhamos
01. Definir
Definimos a tarefa, o responsável e a medida de sucesso antes de escolher qualquer modelo. Sentamos com quem opera o processo, mapeamos onde falha, decidimos quais dados o sistema pode acessar e registramos o que seria um bom resultado. Se não cabe um agente ali, dizemos isso nesta etapa.
Entregas
- A definição da tarefa
- o responsável identificado
- a medida de sucesso e sua meta
- o escopo de acesso aos dados
- a decisão de construir ou não
02. Instrumentar
Construímos primeiro a bancada de avaliação, para distinguir melhora de sorte. Casos reais viram um conjunto de testes, as métricas correspondem à tarefa, as linhas de base são registradas e toda mudança passa a ser avaliada do mesmo jeito.
Entregas
- O conjunto de avaliação com casos reais
- as métricas e linhas de base
- o código de pontuação
- o primeiro relatório
- o tamanho de amostra necessário para detectar uma diferença
03. Integrar
Colocamos o sistema no fluxo existente, com fallbacks, logs e controle de acesso. Ele entra onde o trabalho já acontece, no ERP, CRM, sistema de chamados ou repositório de documentos, com encaminhamento dos casos que não deve resolver sozinho e registro de tudo o que faz.
Entregas
- O sistema em produção nas ferramentas existentes
- controle de acesso e permissões
- logs e monitoramento
- fallbacks e caminhos de encaminhamento
- a trilha de auditoria
04. Transferir
Entregamos o runbook, os testes e uma equipe capaz de operar sem a gente. Formamos as pessoas que vão responder pelo sistema e documentamos como operá-lo e como alterá-lo.
Entregas
- O runbook
- a suíte de testes e o histórico de avaliação
- formação da equipe de operação
- a documentação
Exemplo de projeto
Como podem ser seis semanas.
Cronograma ilustrativo. Projetos reais são dimensionados na definição e variam conforme o processo, os dados e a equipe.
Semana 1
Definir: workshop com os responsáveis pelo processo, escopo de acesso aos dados e medida de sucesso acordada.
Semana 2
Instrumentar: conjunto de avaliação com casos reais, linhas de base registradas e primeiro relatório.
Semana 3
Integrar: primeira versão em ambiente de homologação, conectada aos sistemas de registro.
Semana 4
Integrar: cada mudança passa pela avaliação, fallbacks e logs são testados e o controle de acesso é revisado.
Semana 5
Integrar: entrada em produção com escopo limitado, medida diariamente.
Semana 6
Transferir: runbook, testes e formação entregues; a equipe opera o sistema.
Cada mudança passa pela avaliação.
Nenhuma mudança de prompt, modelo ou código chega à produção sem uma execução da bancada contra a linha de base. Se não superar a linha de base além do acaso, com a amostra acordada, a mudança não entra. A regra continua após a transferência, e o runbook explica como executá-la.
Como funciona a transferência.
A transferência é a última etapa e é planejada desde a primeira. A equipe aprende no sistema em funcionamento, o runbook cobre a rotina e as falhas, e os testes, o histórico de avaliação e a documentação ficam no seu repositório. O sistema funciona sem a gente.