Origem: Extreme Programming, tempo limitado
O termo "spike" vem da Extreme Programming (XP), onde descreve uma investigação técnica curta e separada do trabalho de entrega — uma escalada rápida sobre uma pergunta específica, não um incremento de produto.
A diferença em relação a uma tarefa normal está no objetivo. Uma tarefa de sprint produz código que vai para produção. Um spike produz conhecimento: a resposta para uma pergunta que, sem ela, deixaria a próxima decisão técnica apoiada em opinião em vez de evidência. O código escrito durante um spike é descartável por definição. Ele existe para responder à pergunta, não para durar.
A segunda característica que define um spike é o time-box. Ele não termina quando "está pronto"; termina quando o tempo acaba, com ou sem resposta definitiva. Isso é proposital: a alternativa — investigar até se sentir seguro — tende a se expandir para preencher qualquer prazo disponível, e decisões de biblioteca ou arquitetura raramente têm um ponto natural de "informação suficiente". O time-box força uma saída: ao fim do prazo, ou há o suficiente para decidir, ou há o suficiente para saber que a próxima etapa é um spike menor e mais específico.
Quando vale fazer um spike
Nem toda decisão técnica precisa de um spike. Vale abrir um quando três condições aparecem juntas.
Primeiro, existe uma escolha real entre opções concretas — trocar uma lib de state management, adotar um ORM novo, decidir entre duas abordagens de autenticação — e não uma preferência já assentada no time. Se a resposta é óbvia para quem vai implementar, o spike é teatro.
Segundo, a incerteza é sobre comportamento, não sobre sintaxe. Ler a documentação de uma API resolve dúvida de sintaxe. Um spike existe para o que a documentação não responde: como a lib se comporta sob as condições reais do projeto, como ela interage com o resto do stack, que trade-off só aparece depois que alguém tenta integrar de verdade — uma dívida de incerteza que só some quando a decisão é testada, não apenas discutida.
Terceiro, o custo de errar é alto o suficiente para justificar o tempo do spike. Trocar uma dependência pequena e isolada raramente compensa um spike formal; trocar a camada de dados ou o framework de UI, sim. Reverter depois é caro, e o spike é comparativamente barato.
Quando essas três condições batem, o padrão mais comum é o spike como PoC antes de compromisso: um protótipo mínimo, escrito para ser descartado, que exercita o ponto de maior incerteza — não o caminho feliz completo, só a parte que ninguém consegue responder sem código rodando.
O que um bom spike produz
Um spike malfeito produz uma sensação: "acho que a opção A é melhor". Um spike bom produz um artefato que qualquer pessoa do time, inclusive quem não participou, consegue ler e usar para decidir. Três elementos costumam estar presentes.
Opções comparadas nos mesmos critérios. Não adianta ter testado a fundo a opção A e só lido a documentação da opção B: a comparação vale pelo que foi verificado sob as mesmas condições: setup, curva de aprendizado, tamanho do pacote, maturidade do ecossistema, ou o que for relevante para aquela decisão específica.
Uma recomendação, não uma lista neutra. O spike existe para decidir, então ele precisa terminar com uma posição — "recomendo a opção A, porque X" — mesmo que a resposta honesta seja "nenhuma das duas resolve, o problema está em outro lugar". Uma lista de prós e contras sem conclusão só empurra a decisão de volta para quem devia recebê-la pronta.
Um plano de PoC ou de próximos passos. Se o spike não esgotou a pergunta no tempo disponível — o caso mais comum —, ele precisa deixar explícito o que falta verificar e como, para que a próxima etapa comece de onde o spike parou, não do zero.
Vale registrar também o que um spike não é. Não é uma pesquisa de mercado sobre qual ferramenta é "a mais popular": popularidade não é o critério, adequação ao projeto é. E não é uma avaliação aberta sem prazo: um spike sem time-box vira só mais um item de backlog que nunca fecha, porque sempre existe mais uma dúvida a esclarecer antes da decisão.
Onde o SpikeMe entra
O SpikeMe existe para a parte de organizar essa saída. Você aponta o package.json do projeto, descreve o tema da decisão, e a ferramenta gera um documento de spike estruturado — opções comparadas, recomendação e plano de PoC — a partir do contexto real do seu stack, não de um template genérico. O trabalho de investigar continua sendo seu: o SpikeMe organiza o resultado para que ele vire uma decisão registrada, revisável e compartilhável, em vez de uma conclusão perdida em uma thread de chat. Para gerar um spike a partir do seu projeto, veja spikeme.io.