Encontrar decisões antigas no Slack quando a busca falha
Como encontrar decisões antigas no Slack quando a busca falha. Por que decisões somem, por que logs não funcionam e como é um sistema orientado a decisões.
By Ellis Keane · 2026-03-14
Pense rápido: onde seu time decidiu usar webhooks em vez de polling? Não o que foi decidido – onde essa decisão está registrada agora, em um lugar que alguém entrando no próximo mês conseguiria encontrar?
Se vocês são como nós, a resposta honesta fica em algum lugar entre "em algum thread do Slack, provavelmente" e "acho que foi no #eng-backend, talvez há três semanas, e acho que envolveu duas ou três pessoas, mas sinceramente não consigo lembrar quais". O que é uma situação fascinante quando você pensa sobre isso – porque a própria decisão foi importante o suficiente para mudar como o sistema inteiro funciona, mas aparentemente não foi importante o suficiente para que alguém a registrasse em um lugar que não seja um fluxo de consciência organizado por timestamp. E é isso, em resumo, que é o problema ao tentar encontrar decisões antigas no Slack – a informação está toda lá, só não está organizada de um jeito que permita recuperá-la como uma decisão.
Tenho pesquisado como encontrar decisões antigas no Slack há algum tempo, e quanto mais aprofundo, mais acho que o problema central não é disciplina, hábito ou qualquer outra coisa que as pessoas costumam culpar. É arquitetural. A busca do Slack foi criada para encontrar mensagens, e decisões não são mensagens – são significado que por acaso é expresso por mensagens, uma distinção que soa pedante até você passar vinte minutos rolando resultados de busca tentando descobrir qual das dezessete menções a "webhooks" foi aquela em que seu time realmente se comprometeu a usá-los.
Como a busca do Slack realmente funciona (e onde ela falha)
Vamos ser precisos sobre isso, porque "a busca do Slack é ruim" não é o diagnóstico correto – a busca do Slack é bastante boa no que faz. O problema é que o que ela faz e o que você precisa que ela faça ao procurar uma decisão são duas coisas fundamentalmente diferentes.
O Slack indexa mensagens como texto com metadados: timestamp, remetente, canal e (se você tiver um plano pago) o contexto completo do thread. Quando você busca por "webhook", o Slack retorna fielmente cada mensagem contendo essa palavra, ranqueada por alguma combinação de recência e relevância. Você pode restringir as coisas com operadores de busca – in:#eng-backend from:@sarah before:2026-02-15 – mas tudo que você está fazendo é filtrar a mesma lista plana de mensagens por metadados. Isso é recuperação por palavras-chave, e para encontrar uma mensagem específica da qual você se lembra vagamente, funciona bem.
Mas uma decisão não é uma palavra-chave. Uma decisão é uma relação entre uma pergunta, um conjunto de opções, um conjunto de pessoas e um momento em que o grupo convergiu para uma opção. O texto real da decisão pode ser "sim, vamos de webhooks, a abordagem com polling está comendo nosso rate limit" – que é coloquial, contextual e só faz sentido se você já conhece o thread em que apareceu. Ou pode ser "funciona, deixa eu prototipá-lo", que não contém nenhuma palavra-chave relacionada à decisão técnica que representa.
Esse é o descasamento arquitetural: o Slack armazena mensagens cronologicamente e as recupera por palavra-chave. Decisões são semânticas (são sobre significado) e relacionais (se conectam a tarefas, pessoas e resultados). Você está pedindo a um sistema de armazenamento cronológico que faça recuperação semântica, e ele não consegue, porque nunca foi projetado para isso. A lacuna entre "pesquisável" e "encontrável" é enorme – cada mensagem na sua história do Slack é tecnicamente pesquisável, mas isso não significa que a decisão de que você precisa seja encontrável em qualquer sentido prático.
"O Slack criou um dos maiores repositórios de tomada de decisões organizacionais da história, e quase nada disso é recuperável como decisões – cada palavra perfeitamente preservada e quase totalmente impossível de encontrar." attribution: Ellis Keane
O que acontece quando você tenta encontrar decisões antigas no Slack
É assim que o descasamento se parece na prática. Digamos que há três semanas seu time decidiu trocar de polling para webhooks em uma integração com GitHub. Você lembra que a discussão aconteceu no #eng-backend e envolveu alguns engenheiros. Então você busca por "webhook" naquele canal.
O que volta: cada mensagem que já mencionou webhooks no #eng-backend. Relatórios de bugs de seis meses atrás. Alguém fazendo uma pergunta sobre lógica de retry de webhooks em um contexto completamente diferente. Um link que alguém compartilhou de um post de blog sobre boas práticas de webhooks (que, numa bela ironia, provavelmente fica mais alto nos resultados de busca do que a decisão real ao lado). A decisão em si – uma resposta em um thread onde alguém disse que a abordagem de polling estava atingindo rate limits – está enterrada em algum lugar na página três, parecendo exatamente igual a cada outra mensagem ao redor.
E esse é o cenário em que você se lembra mais ou menos das palavras usadas. Metade das vezes, as decisões usam linguagem tão contextual que poderia estar criptografada. "Vamos com a opção B" não contém a palavra "webhook", mesmo que a opção B fosse webhooks. "Funciona, deixa eu prototipá-lo" não contém nem a palavra "opção". O momento real da decisão costuma ser a mensagem mais curta e com menos palavras-chave em todo o thread, porque naquele ponto todos na conversa já têm o contexto e estão apenas confirmando o alinhamento.
Acho isso genuinamente interessante como um problema de arquitetura de informação (bem, interessante e também um pouco irritante quando você é quem está pesquisando). O Slack criou um dos maiores repositórios de tomada de decisões organizacionais da história, e quase nada disso é recuperável como decisões – cada palavra perfeitamente preservada e quase totalmente impossível de encontrar.
Por que logs de decisão são um cemitério com melhor sinalização
O conselho padrão, se você for buscar soluções, é manter um log de decisões. Um banco de dados no Notion, um canal dedicado no Slack (a ironia disso aparentemente escapa às pessoas que o recomendam), uma página de wiki – um único lugar onde as decisões são registradas à medida que acontecem.
Tentamos isso. Durou cerca de seis semanas. As primeiras duas semanas foram ótimas – todos estavam comprometidos, as entradas eram detalhadas, o log era genuinamente útil. Na terceira semana, as entradas começaram a ficar irregulares. Na quinta semana, uma pessoa ainda estava atualizando, escrevendo coisas como "decidiu coisa sobre auth" sem links, sem contexto e sem indicação de quem estava envolvido ou quais eram as alternativas. Na sexta semana paramos silenciosamente de fingir.
O problema não é que nosso time falta disciplina (talvez falte, mas esse não é o problema relevante aqui). O problema é que o log de decisões impõe um ônus exatamente no momento errado. Você acabou de ter uma discussão produtiva, chegou ao alinhamento, alguém está pronto para começar a construir – e agora você precisa pausar, abrir uma ferramenta diferente, escrever um resumo, marcar as pessoas relevantes e criar um link de volta para a conversa original. São de três a cinco minutos por decisão, e para um time tomando de cinco a dez decisões significativas por dia em canais e threads, o overhead se acumula em algo que ninguém quer ser responsável por.
E o sistema só funciona com 100% de adesão. Um log com 70% das decisões é, em certos aspectos, pior do que nenhum log, porque agora você está verificando dois lugares e não confiando em nenhum. Você verifica o log, a decisão não está lá, então você pesquisa no Slack de qualquer jeito – e voltou de onde começou, exceto que também desperdiçou dois minutos verificando o log primeiro.
Decisões não são eventos – são gradientes
Parte do motivo pelo qual o registro manual falha é que ele assume que as decisões são momentos discretos e identificáveis. Na realidade, a maioria das decisões emerge gradualmente por meio da conversa, e o "momento da decisão" é muitas vezes genuinamente ambíguo.
Considere como uma decisão de engenharia típica realmente se desenrola. Alguém levanta uma preocupação em um comentário do Figma: "esse padrão de interação pode não funcionar no mobile." Um engenheiro responde em um thread do Slack, marcando o comentário original: "sim, eu olhei isso – a biblioteca de componentes não oferece suporte." Um designer sugere uma abordagem alternativa no mesmo thread. O engenheiro diz "funciona, deixa eu prototipá-lo." Dois dias depois, um PR implementando a alternativa é aberto, e a issue do Linear é atualizada.
Onde a decisão foi tomada? Foi o comentário do Figma que trouxe o problema à tona? O thread do Slack onde a alternativa foi proposta? O momento em que o engenheiro disse "funciona"? O PR que o implementou? Na prática, a decisão foi distribuída por todos esses quatro momentos, abrangendo duas ferramentas e três dias. Não foi um evento que você poderia registrar – foi um gradiente que se resolveu em um resultado, e a única razão pela qual sabemos que uma decisão foi tomada é que o código mudou.
Essa é (acho eu) a parte que a maioria dos conselhos sobre "rastreamento de decisões" erra. Trata as decisões como coisas que você captura, como anotar um número de telefone. Mas a maioria das decisões reais são coisas que você reconstrói – você olha para o que mudou, rastreia de volta pelas conversas que levaram até lá, e monta o raciocínio após o fato. O que significa que o sistema de que você precisa não é um log. É um grafo.
O que um grafo oferece que um log não consegue
Um grafo conecta sinais entre ferramentas e no tempo. Em vez de alguém escrever manualmente "decidimos usar webhooks por causa dos rate limits", o grafo vincula o thread do Slack onde os rate limits foram discutidos, a issue do Linear que acompanhou o trabalho de integração, o PR que implementou os webhooks e as pessoas que estavam envolvidas na conversa. A decisão não é registrada – ela se torna reconstituível a partir das conexões entre coisas que já estavam acontecendo.
A diferença prática aparece em um cenário específico. Três semanas após a decisão sobre webhooks, um novo engenheiro entra e pergunta: "por que estamos usando webhooks em vez de polling para o GitHub? Polling parece mais simples." Sem um sistema conectado, alguém diz "ah, a gente decidiu isso um tempo atrás", ninguém lembra qual canal, alguém passa quinze minutos pesquisando no Slack, e eles ou encontram ou (mais provavelmente) reconstroem o raciocínio da memória, o que é arriscado porque a memória não é confiável e o raciocínio original foi quase certamente mais detalhado do que qualquer pessoa se lembra três semanas depois.
Com um grafo, o engenheiro olha para a tarefa de integração com o GitHub. Cada sinal que tocou aquela tarefa está vinculado: a discussão original sobre rate limits, o thread onde polling versus webhooks foi avaliado, o PR que implementou a mudança. A trilha completa de decisões, de ponta a ponta, sem que ninguém tenha pesquisado nada e sem que ninguém tenha registrado nada.
A lacuna não é entre "busca boa" e "busca ruim" – é entre recuperação por palavra-chave e recuperação por relacionamento. As decisões são definidas por suas conexões com tarefas, pessoas e resultados, não pelas palavras usadas para expressá-las.
Os custos que não aparecem em nenhum painel
Sou honestamente cético em relação a qualquer pessoa que afirme ter números precisos para custos intangíveis como esses (as estatísticas do gênero "times perdem X horas por semana" sempre parecem ter sido calculadas de trás para frente a partir de uma conclusão desejada), mas aqui está o que observamos no nosso próprio time.
O custo mais óbvio é a rediscussão – quando ninguém consegue encontrar a decisão original, os times simplesmente a reabrem, às vezes porque as pessoas genuinamente não se lembram e às vezes porque um novo membro do time tem perguntas legítimas que ninguém consegue responder com especificidade. Estávamos rediscutindo questões resolvidas regularmente antes de termos uma forma de rastrear as decisões até sua origem, e cada rediscussão carrega seu próprio overhead: o tempo da reunião, o cansaço emocional de argumentar sobre algo que você tem quase certeza que já foi resolvido, a suspeita persistente de que o raciocínio original era mais detalhado do que qualquer pessoa se lembra.
O custo mais sutil é o que acontece durante o onboarding. Cada pergunta "por que foi feito assim?" de um novo membro do time interrompe alguém que estava na decisão original, e a resposta é reconstituída da memória cada vez que alguém pergunta, se afastando ligeiramente do raciocínio original a cada retransmissão – como um jogo de telefone sem fio, exceto que o telefone é software empresarial e a mensagem é "por que a arquitetura funciona dessa forma". E há uma lacuna de credibilidade que se acumula ao longo do tempo: "usamos webhooks" carrega menos peso do que "usamos webhooks porque o polling estava consumindo 40% do nosso rate limit da API do GitHub e estávamos atingindo throttling durante os horários de pico". O raciocínio é o que permite que futuros engenheiros avaliem se uma decisão ainda se sustenta sob circunstâncias alteradas, e esse raciocínio está em algum thread do Slack, perfeitamente preservado e praticamente invisível.
Pare de perder decisões no scroll do Slack. O Sugarbug rastreia automaticamente a trilha completa de decisões – do thread do Slack à issue do Linear até o PR.
Q: Por que é tão difícil encontrar decisões antigas no Slack? A: O Slack armazena mensagens cronologicamente, não por significado. Uma decisão enterrada em um thread parece idêntica a qualquer outra resposta – a busca do Slack pode combinar palavras-chave, mas não consegue distinguir "decidimos usar Redis" de "deveríamos usar Redis?" sem ler o contexto conversacional completo. Com o tempo, fica mais difícil, porque você perde as pistas contextuais (quem estava envolvido, qual canal, qual semana) que tornavam a busca viável em primeiro lugar.
Q: O Sugarbug rastreia automaticamente as decisões tomadas no Slack? A: Sim. O Sugarbug classifica os sinais recebidos do Slack e de outras ferramentas conectadas, identificando padrões semelhantes a decisões – threads que fazem referência a tarefas, envolvem pessoas atribuídas e resultam em mudanças de status ou PRs. Esses sinais são vinculados à tarefa relevante no grafo de conhecimento, para que você possa rastrear a trilha de decisões a partir da tarefa em vez de pesquisar no histórico do Slack.
Q: Qual é a diferença entre um log de decisões e um grafo de conhecimento para decisões? A: Um log de decisões exige que alguém registre manualmente cada decisão assim que acontece – notar, pausar, resumir, marcar, vincular. Um grafo de conhecimento infere decisões a partir de sinais que fluem pelas ferramentas e as vincula a tarefas, pessoas e conversas automaticamente. Um depende da disciplina consistente de cada membro do time; o outro roda em segundo plano a partir da atividade que já está acontecendo.
Q: O Sugarbug pode extrair decisões de ferramentas além do Slack? A: O Sugarbug se conecta ao Slack, GitHub, Figma, Linear, Notion, e-mail e calendários. As decisões frequentemente abrangem várias ferramentas (um comentário no Figma leva a um thread no Slack que leva a um PR), e o grafo de conhecimento vincula sinais em todas as superfícies conectadas. Você vê a trilha completa independentemente de qual ferramenta a conversa começou.
Q: Como isso é diferente de usar apenas a busca nativa do Slack? A: A busca do Slack encontra mensagens que contêm palavras-chave específicas. Um grafo de conhecimento encontra os relacionamentos entre mensagens, tarefas e pessoas. Quando você está procurando uma decisão, raramente está buscando uma palavra – está buscando o momento em que um time escolheu uma abordagem em vez de outra, e esse momento é definido por suas conexões com outros sinais, não pelas palavras usadas para expressá-lo.
---
Se as decisões continuam desaparecendo no histórico do Slack, o problema não é o Slack – é que nenhum sistema está observando os momentos que importam e os conectando ao trabalho que eles moldaram. Essa é a lacuna que estamos construindo o Sugarbug para preencher.