artigo
discovery, gap analysis e o framework s.t.a.r.t.: entender antes de propor
por que a fase de descoberta evita a reunião do 'não era isso que eu pedi' — e como estruturar uma apresentação técnica que convence sozinha.
Você já esteve numa reunião assim: o time técnico mostra a tela, orgulhoso, e o stakeholder de negócio franze a testa e diz "mas não era bem isso que eu pedi". Ninguém mentiu. Ninguém foi incompetente. O que aconteceu foi mais sutil — alguém entendeu "aprovação mais rápida" como "menos etapas" quando o problema real era "menos gente que não sabe que precisa aprovar". Duas soluções tecnicamente corretas, para dois problemas diferentes.
O ServiceNow facilita esse erro porque o caminho de menor resistência é tentador: a plataforma tem tanta coisa pronta que dá vontade de abrir o Studio e começar a configurar no primeiro dia. O problema é que "configurar rápido" e "configurar a coisa certa" não são a mesma métrica, e só a segunda importa depois que o projeto termina.
#o mapa antes da viagem: as-is e to-be
Ninguém sai de casa numa viagem sem saber, pelo menos aproximadamente, onde está. A análise AS-IS é esse ponto de partida: o retrato honesto (com os defeitos) do processo como ele existe hoje, não como o manual de procedimentos diz que ele deveria existir. O TO-BE é o destino. O projeto inteiro é a distância entre os dois.
Na prática, isso significa investigar cinco frentes antes de desenhar qualquer solução:
| Dimensão | O que perguntar | Onde procurar |
|---|---|---|
| Processos | Quem faz o quê, com que frequência, e onde o processo trava? | Entrevistas com quem executa (não só com quem gerencia), observação direta |
| Dados | Onde os dados moram, com que qualidade, quem é o dono? | Auditoria de dados, entrevistas com analistas |
| Integrações | Quais sistemas conversam, como, com que latência, onde falha hoje? | Diagramas existentes, logs de erro, time de operações |
| Volumes | Quantos registros por dia, qual o pico, qual a projeção para 2-3 anos? | Monitoramento, analytics de uso |
| Compliance | LGPD, retenção de dados, auditoria — o que é obrigatório? | Documentação legal, políticas de TI |
O detalhe que costuma passar despercebido: entrevistar só quem gerencia o processo, não quem executa. Gerente descreve o processo do jeito que ele foi desenhado. Quem está na trincheira sabe qual planilha paralela existe porque o campo obrigatório do formulário nunca reflete a exceção que acontece toda sexta-feira. É nessa planilha paralela que mora metade dos requisitos reais do projeto.
#gap analysis: nem todo buraco pede o mesmo esforço
Com o AS-IS e o TO-BE na mão, o gap analysis é o exercício de listar as diferenças e classificá-las por dois eixos: complexidade técnica e impacto de negócio. A tentação é tratar todo gap como igualmente urgente — mas um gap de alta complexidade e baixo impacto pode esperar a próxima release, enquanto um gap barato de resolver e com impacto alto deveria estar no topo do backlog, não na página três do documento de escopo.
Alguns tipos de gap aparecem com uma regularidade quase previsível:
| Tipo de gap | Exemplo | Complexidade | Caminho na plataforma |
|---|---|---|---|
| Funcional, existe OOB | Aprovação em múltiplos níveis já existe no módulo, só não está ativa | Baixa — só configuração | Ativar o processo nativo, sem customizar |
| Funcional, não existe OOB | Fluxo de aprovação específico de um processo de negócio próprio | Alta — desenvolvimento | Scoped App — mas confira o App Store antes de sair escrevendo do zero |
| Qualidade de dados | Uma fatia relevante da base de usuários não bate com o LDAP | Média — remediação | Import Set com Transform Map de reconciliação, mais um processo de governança contínua |
| Migração histórica | Anos de tickets num sistema legado que precisam entrar na base nova | Alta — ETL | Import Sets em lotes, com validação de cada lote antes do próximo |
| Integração nova | Sincronizar dados mestres com um ERP | Média-alta | MID Server + Import Set (entrada) + REST Message (saída) |
Repare que a coluna "complexidade" nem sempre acompanha o tamanho aparente do pedido. "Só ativar uma aprovação que já existe" é baixa complexidade mesmo que o stakeholder ache que está pedindo algo grande. E "só criar um campo a mais" pode ser alta complexidade se esse campo alimenta uma integração com três sistemas downstream. Gap analysis serve exatamente para separar a percepção do esforço real.
#comunicação arquitetural: o framework s.t.a.r.t.
Depois de entender o problema e priorizar os gaps, sobra a parte que muita gente tecnicamente competente subestima: convencer quem decide de que a solução proposta é a certa. Um arquiteto que não consegue argumentar a própria decisão depende de confiança cega — um recurso escasso em qualquer projeto corporativo, e que se esgota rápido no primeiro desalinhamento.
O S.T.A.R.T. não é um framework oficial da ServiceNow nem uma nomenclatura padronizada de mercado — é bom deixar isso claro antes de citar como se fosse. É um mnemônico (inspirado na lógica do clássico método STAR de entrevistas, com Target e Trade-offs somados ao final) útil para estruturar qualquer apresentação técnica em cinco blocos:
| Elemento | Conteúdo | Exemplo |
|---|---|---|
| S — Situation | O problema atual, com números | "aprovação de Change leva em média 5,2 dias; 34% dos Changes violaram o SLA de 3 dias no último trimestre" |
| T — Target | O estado desejado, com métrica verificável | "reduzir para menos de 2 dias; meta de 90% dentro do SLA" |
| A — Action | Os passos concretos da solução | "Flow Designer com aprovação paralela do CAB e aprovação automática de Changes de impacto baixo após 24h sem resposta" |
| R — Rationale | Por que essa solução venceu as alternativas | "Flow Designer em vez de scripts custom pelo Execution Detail nativo; aprovação paralela corta ~60% do tempo total frente a sequencial" |
| T — Trade-offs | O que está sendo sacrificado, com honestidade | "aprovação automática após 24h é um risco percebido; mitigação: só impacto baixo, log completo, revisão em 3 meses" |
A parte que mais separa uma apresentação convincente de uma genérica é o T de Trade-offs. É tentador pular direto do Action para o "e está tudo resolvido" — mas todo stakeholder experiente sabe que solução sem trade-off é solução mal analisada, e vai perguntar mesmo que você não fale. Chegar primeiro com a resposta muda completamente o tom da conversa: de defesa para parceria.
#e agora?
- Da próxima vez que receber um pedido de feature, resista ao impulso de abrir o Studio no mesmo dia — gaste uma hora estruturando as cinco dimensões do AS-IS antes de propor qualquer TO-BE. É o investimento com melhor retorno deste artigo inteiro.
- Pegue a última decisão arquitetural que você tomou sem documentar o porquê e reescreva ela em formato S.T.A.R.T., mesmo que só para você. Vai ficar claro rápido se a decisão tinha um S com números de verdade ou se foi tomada no instinto.
- Se o gap identificado for "criar uma tabela nova porque a nativa não serve", pare antes de commitar — o próximo artigo desta trilha cobre exatamente esse e outros anti-padrões clássicos. Enquanto isso, releia arquitetura de integração: o veículo certo para o mesmo raciocínio de "qual ferramenta serve para qual gap" aplicado a integrações.