- Em ambientes de negócios iniciais, com mudanças frequentes, é sensato resolver os problemas rapidamente com a solução mais fácil e, quando os limites aparecerem, reavaliar os requisitos antes de substituir ou reforçar a solução
- O Google Sheets é um meio eficaz de resolver problemas em ambientes que mudam rapidamente e, em vez de desenvolver ferramentas complexas, favorece a usabilidade real e a redução de desperdício
- O autor relembra que, na prática, apressou a criação de sistemas dedicados em vez de usar ferramentas genéricas e acabou desperdiçando tempo ao ignorar a incerteza de escopo
- O método central é a estratégia de começar pequeno e iterar: começar com a solução mais simples e pequena → entender o escopo no trabalho real → melhorar gradualmente se necessário
- Porém, nem todo problema pode ser resolvido com planilhas; o ideal é usá-las temporariamente até que o escopo fique claro, e é importante fazer uma seleção criteriosa de acordo com o contexto da organização
A escolha mais fácil para resolver problemas
- Para qualquer problema, é importante escolher primeiro a solução mais fácil de aplicar
- Quando esse método deixa de se adequar ao negócio, é necessário melhorar a solução existente ou buscar uma alternativa de acordo com os novos requisitos
- No ambiente que o autor vivenciou, na maioria dos casos a melhor abordagem era criar uma nova Google Sheet
O ambiente de startup em rápida mudança e a utilidade das ferramentas
- Depois de entrar na empresa há cerca de 9 meses, o entusiasmo por criar novas ferramentas e serviços para uma empresa pequena e em estágio inicial desapareceu
- Em um ambiente em que a direção do negócio mudava a cada 2 meses, muitos projetos eram iniciados e depois abandonados
- Em muitos casos, mesmo quando o problema podia ser resolvido facilmente com uma Google Sheet, tempo e esforço eram investidos em projetos desnecessariamente complexos
Exemplos de desperdício de tempo
-
Painel administrativo de gestão de cargas
- Foram necessários 2 meses para projetar e construir um painel administrativo para gerenciar e rastrear cargas recebidas para o negócio
- O objetivo era classificar pacotes e dados de clientes e ajudar a gerenciá-los melhor
- Esse painel administrativo foi usado duas vezes e nunca mais
- Ele poderia ter sido facilmente substituído por uma Google Sheet, e é isso que está sendo usado atualmente para essa tarefa
-
MVP de cálculo automático de tarifas alfandegárias
- Foram necessárias 3 semanas para criar um MVP de um sistema de orçamento que calculava automaticamente tarifas alfandegárias e impostos ao encomendar determinados produtos
- Como os impostos e as tarifas alfandegárias do Zimbábue são muito complexos, saber o valor exato a pagar poderia oferecer uma jornada melhor ao cliente e acelerar o processo, sem precisar esperar todas as respostas de atendimento de uma empresa terceirizada de desembaraço aduaneiro
- No fim, foi usada a tabela de classificação de impostos e tarifas alfandegárias de um concorrente, copiada para uma Google Sheet
-
Processo de escolha de CRM
- Foram gastos 2 meses com pesquisa, reuniões (de mais de 1 hora) e buscas para encontrar um bom CRM para o negócio
- Houve análise e comparação detalhada de recursos e preços de vários CRMs
- No fim, decidiu-se usar a versão gratuita do Oddo, mas ela não foi muito utilizada dentro do negócio
- Surpreendentemente, há algumas semanas foi descoberto que o Google Sheets já tinha um template de CRM embutido
Princípios da abordagem com Google Sheets
- Criar uma Google Sheet não é a melhor solução para todos os problemas, mas na situação do autor isso costuma acontecer com frequência
- Muitas vezes ele se encontra em situações em que nunca é possível conhecer o escopo completo do problema antes de começar o trabalho real
- Isso não significa que não se deva planejar projetos
- A equipe deve discutir o fluxo de trabalho e as informações necessárias, mas não é possível conhecer o escopo completo do problema antes de iniciar o trabalho real
- Quando o escopo completo do problema fica claro, passa a ser possível criar ou melhorar a solução disponível
- No melhor cenário, essa abordagem evita o trabalho extra de adicionar recursos desnecessários; no pior, ajuda a não gastar tempo em projetos fadados ao fracasso
- Até agora, a melhor forma de entender o escopo completo do problema foi implementar a solução básica mais simples e pequena e, se necessário, iterar depois
Limitações e cuidados
- Essa abordagem também tem desvantagens; por exemplo, em algumas organizações, milhares de linhas de planilhas são usadas para registrar todas as transações e informações
- O Google Sheets só é útil antes que o escopo completo do problema seja entendido
- É preciso experiência e bom julgamento para saber que tipo de problema pode ser resolvido com uma Google Sheet
- É importante priorizar o desenvolvimento de ferramentas que realmente possam ser usadas, sem desperdiçar tempo
- Ainda assim, não é um conselho que sirva para todos, então cada um precisa avaliar com cuidado de acordo com sua própria situação
Conclusão
- Começar com o menor esforço e a solução mais simples, expandindo ou sofisticando apenas quando necessário, é uma estratégia muito adequada para startups ou ambientes com muitas mudanças
- Experimentos pessoais de desenvolvimento podem ser feitos livremente, mas nos negócios é importante construir apenas o que é realmente necessário e não gastar tempo nem energia com trabalho desnecessário
3 comentários
Eu também concordo no geral, mas hoje prefiro usar o Notion Database como baseline inicial em vez do Google Sheets. É parecido, mas no fim das contas só 1 pessoa configura o template. Se as outras pessoas gerenciarem os dados em cima dessa base, dá para evitar uma situação bagunçada. Não chega ao nível do App Script, mas também dá para implementar automações com mais facilidade. A dificuldade da configuração inicial é levemente maior, mas não é nada demais, e acho que em termos de flexibilidade são parecidos. Além disso, recentemente até passou a ter controle de permissões por linha, então Good.
Acho que o Notion é bom porque a curva de aprendizado é baixa.
Opinião no Hacker News
Isso é algo que sempre passa despercebido. Planilhas reúnem em um só lugar um banco de dados, uma UI rápida e fácil de customizar, além de um ambiente de processamento de dados iterativo e fácil de depurar. É uma ferramenta que praticamente todo trabalhador do mundo já entende e usa, e também oferece ao criador liberdade para implementar do jeito que quiser. A portabilidade também é excelente. Tenho convicção de que é uma ferramenta especialmente criativa e poderosa para quem não sabe programar. Claro que essa liberdade também traz desvantagens, mas, independentemente da discussão sobre estar tudo online ou sobre qual fornecedor é melhor, meu apreço profundo por planilhas não diminui nem um pouco. Acho que são a melhor ferramenta de autoria que já criamos. Um modelo parecido com o das planilhas seria o HyperCard. Era uma bancada flexível na qual dava para conectar vários apps, dados, UX e afins. Espero que o HyperCard seja lembrado para sempre
Exato, a barreira de entrada das planilhas é realmente muito baixa. Eu até registro o crescimento das lavouras no Google Sheets pelo celular, no meio da fazenda. Mesmo com sinal fraco, deixo salvo no modo offline e sincronizo quando volto para casa. Mesmo que o registro fique meio bagunçado, ainda é muito melhor do que não ter registro nenhum. A agricultura precisa de muitos dados, mas surpreendentemente é um ambiente com pouca informação. O ciclo de aprendizado é longo, em escala anual, e cada ano é diferente
Para quem sabe programar, o Appscript transforma a planilha quase em um superpoder. Para quem não conhece, não é obrigatório escrever só JS no web IDE embutido no Google Sheets (embora isso também seja bem utilizável). Com
clasp, dá para desenvolver em Typescript no IDE local e, no processo de build, compilar para JS e implantar direto na planilha. Depois que você monta o toolchain, a experiência de desenvolvimento (DX) fica bem decenteConcordo fortemente. O valor de uma bancada integrada de banco de dados + UX + lógica é o núcleo dos apps que continuamos recriando repetidamente. É por isso que o Visual Basic ainda continua em uso. Claro que, depois que a direção fica bem definida, não é o melhor caminho, mas para iterar rápido e descobrir os requisitos reais não tem nada melhor
Acho que seria ótimo se houvesse um jeito melhor de usar planilhas como backend de banco de dados. Grande parte do que a maioria das pessoas faz em planilhas seria melhor resolvida em um banco de dados. Mas bancos de dados exigem mais treinamento, e, sem esse treinamento, o resultado pode acabar sendo pior do que com planilhas
Sempre me perguntei por que não existe um caminho de transição realista para migrar gradualmente de planilhas para um banco de dados completo com UI customizada. A planilha está exatamente um passo antes disso, e parece que bastariam alguns recursos essenciais (dados estruturados, SQL nativo, elementos de UI customizados, integração com IDE etc.) para isso ser viável
Isso me lembra o post "Ask HN: Is the world run by badly updated Excel sheets?". É preciso experiência para sentir na pele os limites das planilhas. Não há controle de versão, não há testes. São ótimas para trabalhos curtos e que não mudam, mas viram problema quando precisam evoluir continuamente. Veja https://news.ycombinator.com/item?id=33611431. Havia um comentário naquele fio dizendo o seguinte: no fim, dentro da empresa, todo mundo acaba se adaptando ao jeito do dono do Excel. Se não gostar, é só criar outro Excel e copiar e colar, então cada um vai tocando por conta própria. Um gerente de projeto que conheço passava o dia conciliando versões de planilhas com vários autores
Quando comecei como programador nos EUA, nos anos 2000, eu achava que meu trabalho era transformar em webapps as planilhas em drives de rede do Windows que sempre precisavam de alguém cuidando delas com muito carinho. Mesmo assim, muitas empresas ainda funcionam bem com base em planilhas. No fim, chega uma hora em que o problema de escala explode, e aí é preciso migrar para um app, mas é melhor fazer algo do que ficar travado tentando alcançar a perfeição
Foi dito que "não há controle de versão", mas, na verdade, o Excel até tem recurso de controle de versão. Com "Rastrear Alterações", você pode aprovar ou rejeitar alterações feitas por outras pessoas. Só que quase ninguém que trabalha com automação de planilhas no estilo Rube Goldberg usa isso. Mas, se precisar, existe
Já vi muito problema surgir quando a informação fica espalhada por várias planilhas. Muitas vezes, os envolvidos não sabem em qual planilha está cada informação, nem qual é a fonte de verdade. Então é comum alguém atualizar só o arquivo A sem saber, enquanto outra pessoa mexe só no B, e isso gera conflito o tempo todo. O problema não era tanto do programa nem dos dados em si, mas da forma como os arquivos eram gerenciados dentro do projeto. Vira um labirinto de gestão, com pastas compartilhadas complexas e arquivos largados em algum canto da rede
Concordo com o conselho de "sempre use a forma mais simples de resolver o problema e, quando ela deixar de atender ao negócio, melhore-a ou busque uma solução alternativa conforme os novos requisitos". É preciso focar em resolver o problema atual; tentar antecipar problemas futuros, ou problemas que talvez você gostaria de ter, raramente dá certo. A solução atual pode se tornar inadequada no futuro, mas é difícil prever exatamente como isso vai acontecer
É difícil prever em que direção uma solução vai se tornar inadequada no futuro, mas ainda assim dá para escolher uma solução atual de um jeito que não bloqueie nem atrapalhe soluções futuras. É bom manter as opções abertas e evitar ficar preso a um fornecedor de forma irreversível
Um caso clássico e previsível de inadequação futura é depender completamente de um fornecedor específico e acabar sendo expulso do serviço ou obrigado a aceitar preços cada vez maiores. Esse é um problema bastante previsível
Se você resolver o problema de uma forma que cubra melhor o domínio do problema como um todo, sem necessariamente fazer mais trabalho, consegue absorver requisitos que mudam com pequenas adaptações, o que aumenta a robustez da solução. E assim você naturalmente também cobre problemas futuros
Trabalho em uma grande empresa famosa dos EUA. Nosso departamento depende muito de duas planilhas. Elas sobreviveram a três fusões e aquisições envolvendo minha fábrica. Quando entrei, há 7 anos, já eram um formato antigo. Dois anos atrás, um novo gerente tentou migrar isso para um sistema corporativo e falhou, e em breve esse sistema também deve ser substituído por outro novo. Mas acho que ainda estaremos usando as planilhas em 2027
Sou ex-funcionário do Google. Durante 5 anos, fiz todo o meu trabalho só com Sheets (internamente chamado de Trix): gestão de projetos, CRM, planejamento trimestral, relatórios, entrevistas, finanças e tudo mais. Não era simplesmente por ser um produto do Google (eu também usava bastante produtos concorrentes). A conveniência esmagadora vinha do fato de que planilhas podiam ser montadas rápido o suficiente para atingir o objetivo, permitindo focar na essência do trabalho
Sobre a opinião de alguém que disse estar "há 9 meses na empresa", achei que, certa ou errada, é preciso ter bastante coragem para dar uma opinião tão categórica com menos de um ano de experiência. O ponto que o OP deixou passar é a verdade de que "não existe nada mais permanente do que uma gambiarra temporária". Você até pode escolher uma solução rápida e improvisada no curto prazo, mas isso só é aceitável quando controla totalmente o ciclo de vida dessa solução. Se você a entregou às pressas porque alguém pediu, e depois querem continuar adicionando novos usos em cima dela… aí eu defenderia com força uma ferramenta com custo inicial um pouco maior
Quase ri da parte do "uma vez a cada poucos meses...". O autor acertou ao dizer que o princípio geral é fazer o trabalho com ferramentas simples. Se você puder usar a ferramenta existente e ela atender razoavelmente à necessidade, melhor ainda. Na prática, porém, os requisitos de negócio mudam de novo a cada poucos meses, então pode até acontecer de você escapar do fenômeno da "gambiarra temporária virar solução permanente". Mas, para a maioria, depois de alguns anos ainda sobra a faxina para fazer, e o cenário de "reescrevemos quando precisar" quase nunca funciona. E o autor ainda não viveu, por conta própria, o que acontece depois de 1 ano, ou mais
Essa parte do "a cada poucos meses..." me chamou bastante atenção também. Fiquei me perguntando se isso veio de alguém que já passou por isso umas 4 vezes
Para quem se cansou de planilhas grandes, o MS Access era uma solução bem útil. Ele trazia mais estrutura e manutenção do que uma planilha, sem perder a acessibilidade nem aumentar demais a dificuldade de desenvolvimento. Dava para criar ótimas UIs sem muito conhecimento de programação. Passados 20 anos, também não sei muito bem qual seria hoje o substituto do Access
Concordo totalmente com o OP. Só acrescentaria uma coisa: quando surge uma necessidade complexa demais para o Google Sheets, o Google Colab (ou um Jupyter notebook) vira a opção imediatamente acima. Antes de construir um app de verdade, eu sempre me pergunto: 1. Isso dá para fazer só com uma planilha? 2. Se não, dá para fazer com um Jupyter notebook? Aliás, a integração entre Sheets e Colab também é excelente
Na minha opinião, jupyter notebook já é um passo muito mais complexo do que simplesmente escrever um script em python. Também dá para comentar um script em python, e esse modelo de "subir um servidor web local e executar bloco por bloco para ver comentários" não me agrada muito
Tenho curiosidade sobre como fazer upgrade de algo que já estava em um google sheet para um colab notebook. Dá para ler os dados brutos da planilha com o pacote python
gspread, mas parece difícil levar os gráficos e os elementos interativos existentes diretamente para um jupyter notebook. No fim, acho que teria que reconstruir tudoO Google Apps Script também é uma boa alternativa. Mesmo com scripts simples, como para importar dados, já dá para fazer bastante coisa
Um dos maiores problemas da automação de negócios é o vazio que existe entre o chamado IT "shadow", plataformas low-code e projetos totalmente "oficiais". Falta um caminho de migração adequado entre "montar algo rapidinho com google form" e "subir um app React com CI/CD, testes e CDN". As alternativas disponíveis parecem ser apenas jardins murados incompatíveis entre si
Faço toda a minha gestão financeira no Google Sheets. Também criei minha própria UI de Expense Tracker e já acumulei mais de 5.000 lançamentos ao longo de vários anos. Mais recentemente, fiz no vibe coding uma ferramenta de web UI usando Google Service Account, e transformei isso em um PWA para usar também no celular. Para usos simples (especialmente aplicações para uma pessoa), Google Sheets já basta tranquilamente no lugar de um DB