Diário de Decisões para Startups
Startups tomam centenas de decisões por semana. Desaparecem em threads do Slack e reuniões esquecidas. Como criar um diário de decisões que funciona.
By Ellis Keane · 2026-03-16
Em 1986, o vaivém espacial Challenger desintegrou-se 73 segundos após o lançamento. A investigação subsequente concluiu que engenheiros da Morton Thiokol tinham levantado preocupações sobre as vedações O-ring na noite anterior, argumentando que o frio tornava o lançamento inseguro. A gestão ignorou-os. A decisão foi tomada numa teleconferência e, embora existissem gráficos e testemunhos, o raciocínio crítico por detrás da decisão de avançar estava fragmentado entre os participantes e nunca foi transmitido de forma fiável pela cadeia de comando.
Não estou a comparar as decisões de produto do seu startup a uma catástrofe espacial (bem, não a maioria delas). Mas o padrão de falha subjacente é o mesmo que vejo acontecer em startups todas as semanas, apenas com menos em jogo: uma decisão é tomada, o raciocínio por detrás dela vive na cabeça de alguém ou numa thread do Slack que está prestes a sair do ecrã, e três meses depois ninguém consegue reconstruir porque escolhemos a abordagem A em vez de B. Não porque a decisão estivesse errada – às vezes foi excelente – mas porque o contexto que a tornava certa evaporou.
"Uma decisão é tomada, o raciocínio por detrás dela vive na cabeça de alguém ou numa thread do Slack que está prestes a sair do ecrã, e três meses depois ninguém consegue reconstruir porque escolhemos a abordagem A em vez de B." – Ellis Keane
Um diário de decisões para startups não é um exercício burocrático. É a diferença entre "tentámos isso e não funcionou" (útil) e "acho que falámos sobre isso uma vez?" (inútil).
A Anatomia de uma Decisão Perdida
Deixem-me traçar uma decisão específica ao longo do seu ciclo de vida, porque a versão abstracta deste problema é menos convincente do que a concreta.
É uma terça-feira em Fevereiro. O vosso head of engineering e o PM estão numa thread do Slack a debater se devem construir um sistema de notificações personalizado ou usar um serviço de terceiros. A thread tem 47 mensagens (eu sei, mas é assim que funciona) e, pela mensagem 38, já chegaram à opção de terceiros porque a construção própria levaria três sprints e o prazo de lançamento é daqui a dois.
O PM cria um issue no Linear: "Integrar o [Serviço X] para notificações." Um engenheiro pega nele e começa a construir. A thread do Slack ainda está lá, tecnicamente, mas ninguém a adiciona aos favoritos nem a liga a partir do issue do Linear.
Avancemos para Maio. O serviço de terceiros tem um problema de fiabilidade. Alguém pergunta: "Porque é que não construímos nós mesmos?" O PM lembra-se da conversa mas não dos detalhes. O head of engineering está de licença parental. A thread do Slack está algures no canal #engineering de Fevereiro, mas ninguém se lembra da data exacta, e a pesquisa no Slack devolve 200 resultados para "notification" (porque, claro, todas as equipas discutem notificações constantemente).
A equipa passa 45 minutos numa reunião a reconstruir o raciocínio original. Chegam à mesma conclusão – a restrição de prazo ainda se aplicava – mas os 45 minutos foram-se, e a dúvida fica. Multipliquem isto pelas dezenas de decisões que uma startup toma todos os meses e têm uma fatia de tempo significativa gasta a reanalisar escolhas que já foram tomadas com cuidado.
Porque é que os Startups São Particularmente Maus Nisso
As grandes empresas (com todos os seus defeitos, que são muitos) tendem a ter memória institucional codificada em processos: registos de decisões de arquitectura, RFCs, documentos de design que passam por ciclos formais de revisão. As decisões podem estar enterradas no Confluence, mas pelo menos estão escritas algures onde se consegue encontrá-las.
Os startups não têm essa infraestrutura, e construí-la parece exactamente o tipo de sobrecarga que se deve evitar quando se é pequeno e rápido. Há um argumento razoável de que "vamos lembrar-nos" funciona com 4 pessoas, e funciona – até a quinta pessoa entrar e não ter contexto algum sobre porque as coisas são como são.
O outro factor que torna o acompanhamento de decisões em startups particularmente difícil é a fragmentação de ferramentas. As decisões acontecem em todo o lado: threads do Slack, chamadas no Zoom, comentários no Notion, discussões no Linear, revisões de PR no GitHub e (cada vez mais) em mensagens directas que nunca chegam a um canal partilhado. Cada ferramenta captura um fragmento da decisão, mas nenhuma captura o todo, e os links entre elas são mantidos pela memória humana – que é (com todo o carinho) a base de dados menos fiável a que qualquer um de nós tem acesso.
O que um Diário de Decisões Realmente Precisa
Há a tentação de sobre-engenheirar isto. Já vi equipas construírem bases de dados elaboradas no Notion com 15 propriedades por entrada – tipo de decisão, nível de impacto, estado de revisão, stakeholders, OKRs relacionados – e depois nunca as usarem porque a sobrecarga de preencher todos esses campos para cada decisão é superior ao valor percebido.
Um diário de decisões para startups precisa de ser suficientemente leve para que as pessoas o utilizem de facto. Eis o que importa:
A própria decisão. Uma frase. "Vamos usar o Serviço X para notificações em vez de construir algo próprio." Não um parágrafo – uma frase.
Quem a tomou e quando. Nome e data. Parece óbvio mas é a parte que mais importa quando alguém questiona a decisão seis meses depois. Não é para atribuir culpa (bem, na maioria das vezes não) – é para saber a quem perguntar sobre o raciocínio original.
Que alternativas foram consideradas. Dois ou três pontos. "Considerou-se construção própria (estimativa de 3 sprints, prazo demasiado apertado)" e "Considerou-se o Serviço Y (preço não escala acima de 10 mil utilizadores)." Esta é a parte que evita reanalisar – se as alternativas e os seus compromissos estiverem documentados, a equipa não precisa de os redescobrir.
Onde a discussão aconteceu. Um link para a thread do Slack, o issue do Linear, o comentário no Notion – onde quer que tenha ocorrido o debate real. Este é o campo mais subestimado. Sem ele, a entrada no diário é uma afirmação sem evidências. Com ele, qualquer pessoa que queira o contexto completo pode ir ler a conversa original.
O que mudaria a decisão. Isto é opcional mas incrivelmente útil para startups onde o contexto muda rapidamente. "Reavaliávamos isto se o prazo de lançamento se deslocasse mais de 4 semanas" ou "Isto pressupõe que ficamos abaixo de 10 mil notificações mensais." Transforma um registo estático num registo vivo.
O melhor diário de decisões para startups é aquele que a vossa equipa realmente preenche. Cinco campos, uma frase cada. Se demorar mais de 90 segundos a registar uma decisão, o sistema morre dentro de um mês.
Onde Colocá-lo
Já vi equipas a experimentar três abordagens – todas têm as suas desvantagens.
Uma base de dados no Notion. É a mais comum e funciona razoavelmente bem. Criem uma base de dados com os cinco campos acima, adicionem um template para que o preenchimento seja rápido e liguem cada entrada à página de projecto relevante. A desvantagem: o Notion é onde vivem as especificações, não onde as decisões acontecem, pelo que estão a depender de alguém ir ao Notion depois de a decisão ser tomada noutro sítio. Esse passo "depois" é onde acontece o abandono.
Directamente no Slack. Algumas equipas usam um canal dedicado #decisions e publicam uma mensagem formatada para cada decisão. Tem menos atrito (a decisão foi provavelmente tomada no Slack de qualquer forma), mas a pesquisa no Slack dificulta encontrar decisões por projecto ou intervalo de datas, e a falta de campos estruturados faz com que a consistência se degrade com o tempo.
Directamente no Linear. Se a decisão está relacionada com um fluxo de trabalho específico, registá-la como comentário no issue do Linear relevante mantém a decisão próxima do trabalho que afecta. A desvantagem é que as decisões que abrangem vários issues ou projectos não têm um local natural.
Nenhuma delas é óptima, a ser honesto. O problema fundamental é que as decisões acontecem em várias ferramentas, mas os diários vivem numa só, pelo que há sempre um passo manual para colmatar a lacuna. Esse passo manual é o único ponto de falha de todos os diários de decisões que já vi.
O que Estamos a Construir no Sugarbug
A abordagem que seguimos no Sugarbug é detectar decisões à medida que acontecem nas ferramentas, em vez de exigir que alguém as registe manualmente.
Quando uma thread do Slack chega a uma conclusão ("OK, vamos com o Serviço X"), quando uma discussão num issue do Linear se resolve, quando uma revisão de PR no GitHub termina com uma aprovação – estes são todos sinais de que uma decisão foi tomada. O Sugarbug recebe estes sinais, classifica-os e liga-os às tarefas e pessoas relevantes no grafo de conhecimento. O "diário de decisões" não é uma base de dados separada que alguém tem de manter – é uma vista sobre as decisões já incorporadas nas vossas ferramentas existentes.
Ainda estamos a afinar a precisão da classificação (perceber a diferença entre "uma decisão" e "apenas uma conversa" é mais difícil do que parece), mas a aposta direcional é que capturar decisões na fonte, onde realmente acontecem, é mais fiável do que pedir às pessoas que as dupliquem num sistema separado.
Se isso vos interessar, o sugarbug.ai tem mais detalhes. Mas o sistema manual acima servirá bem a maioria dos startups até que a equipa seja suficientemente grande para que a taxa de abandono do registo manual se torne um problema real – normalmente em torno das 8–12 pessoas, pela nossa experiência.
Pare de perder decisões no scroll do Slack. O Sugarbug captura-as automaticamente a partir das ferramentas onde realmente acontecem.
Q: O que deve incluir um diário de decisões de uma startup? A: No mínimo: a própria decisão (uma frase), quem a tomou, quando, quais alternativas foram consideradas e onde a discussão aconteceu. O último campo é o mais importante – sem um link para a conversa original, o registo torna-se uma afirmação sem evidências, e quando alguém a questiona seis meses depois estão de volta a reconstruir a partir da memória.
Q: O Sugarbug cria automaticamente um diário de decisões a partir das ferramentas existentes? A: É a direcção em que caminhamos. O Sugarbug recebe sinais do Slack, Linear, GitHub, Notion e outras ferramentas, classificando-os num grafo de conhecimento. Quando detecta uma decisão – um PR aprovado, uma discussão do Linear resolvida, uma thread do Slack que termina com um próximo passo claro – liga essa decisão à tarefa e às pessoas relevantes automaticamente. Ainda estamos a refinar a classificação (distinguir "decisão" de "conversa" é genuinamente complicado), mas a ingestão de sinais e a ligação estão a funcionar.
Q: Com que frequência uma startup deve actualizar o seu diário de decisões? A: O ideal é que as decisões sejam registadas à medida que são tomadas, não agrupadas semanalmente. À sexta-feira, o raciocínio por detrás da decisão de terça-feira já é pouco nítido, e a hipótese de alguém preencher o campo "alternativas consideradas" com precisão cai rapidamente. Se for registo manual, tornai-o um hábito de 90 segundos imediatamente após a decisão. Se usar uma ferramenta como o Sugarbug, o objectivo é a captura em tempo real a partir das ferramentas onde as decisões realmente acontecem.
Q: O Sugarbug consegue acompanhar decisões no Slack, Linear e GitHub? A: O Sugarbug liga-se aos três (e ao Notion e Figma) e mantém um grafo de conhecimento das relações entre conversas, tarefas e alterações de código. Quando uma decisão surge numa thread do Slack, leva a um issue do Linear e gera um PR no GitHub, o Sugarbug liga toda a cadeia para que possa rastrear a decisão desde a origem até à implementação sem que ninguém precise de criar esses links manualmente.
Q: Qual é a diferença entre um diário de decisões e um registo de decisões de arquitectura (ADR)? A: Os ADRs são tipicamente documentos formais para escolhas técnicas significativas – "vamos usar PostgreSQL em vez de MongoDB" – com secções estruturadas para contexto, decisão e consequências. Um diário de decisões para startups é mais amplo e mais leve: captura as decisões operacionais diárias (que fornecedor, qual prazo, que funcionalidade cortar) que os ADRs considerariam demasiado pequenas para documentar. Ambos têm valor; o diário de decisões cobre os 95% de decisões que não justificam um ADR formal mas que ainda precisam de ser rastreáveis.