- En entornos de negocio iniciales que cambian con frecuencia, es inteligente resolver los problemas rápido con la solución más sencilla y, cuando se vean sus límites, reevaluar los requisitos para sustituirla o reforzarla
- Google Sheets es una herramienta eficaz para resolver problemas en entornos que cambian rápido; frente a desarrollar herramientas complejas, favorece más la usabilidad real y la reducción del desperdicio
- El autor recuerda que, en su trabajo, se apresuró a crear sistemas dedicados en lugar de usar herramientas generales, pasando por alto la incertidumbre del alcance y desperdiciando tiempo
- El método clave es la estrategia de empezar pequeño e iterar: comenzar con la solución más pequeña y sencilla → entender el alcance a través del trabajo real → mejorar gradualmente si hace falta
- Aun así, no todos los problemas pueden resolverse con hojas de cálculo; es mejor usarlas de forma temporal hasta que el alcance quede claro, y es importante hacer una selección inteligente según el contexto de la organización
La opción más sencilla para resolver problemas
- Para cualquier problema, es importante elegir primero la solución más fácil de aplicar
- Cuando ese método deja de ajustarse al negocio, hace falta mejorar la solución existente o buscar una alternativa según los nuevos requisitos
- En el entorno que experimentó el autor, en la mayoría de los casos crear una nueva Google Sheet era la mejor opción
El entorno startup de cambios rápidos y la utilidad de las herramientas
- Hace unos 9 meses entró a trabajar, y la expectativa de crear nuevas herramientas y servicios para una empresa pequeña y en etapa inicial desapareció
- En un entorno donde la dirección del negocio cambiaba cada 2 meses, muchos proyectos se empezaban y luego se abandonaban
- En muchos casos, aunque se podía resolver fácilmente con Google Sheet, se invirtió tiempo y esfuerzo en proyectos innecesariamente complejos
Casos de pérdida de tiempo
-
Panel de administración para gestión de carga
- Se tardaron 2 meses en diseñar y construir un panel de administración para gestionar y rastrear la carga entrante del negocio
- El objetivo era clasificar paquetes y datos de clientes y ayudar a administrarlos mejor
- Este panel de administración se usó dos veces y nunca más
- Se podía reemplazar fácilmente con Google Sheet y actualmente se usa para esta tarea
-
MVP para cálculo automático de aranceles
- Se tardaron 3 semanas en crear un MVP de un sistema de cotización que calculaba automáticamente aranceles e impuestos al pedir ciertos productos
- Como los impuestos y aranceles en Zimbabue son muy complejos, si los clientes conocen el monto exacto a pagar se puede ofrecer una mejor experiencia y acelerar el proceso sin tener que esperar todas las respuestas a consultas de clientes de una empresa externa que gestiona aduanas
- Al final, se revisó la tabla de clasificación de impuestos y aranceles de un competidor y se copió a Google Sheet para usarla
-
Proceso de selección de CRM
- Se tardaron 2 meses en investigación, reuniones (de más de 1 hora) y búsquedas para encontrar un buen CRM para usar en el negocio
- Se compararon y analizaron las funciones y precios de varios CRM
- Al final se decidió usar la versión gratuita de Oddo, pero no se utilizó mucho dentro del negocio
- Sorprendentemente, hace unas semanas se descubrió que Google Sheets tiene integrada una plantilla de CRM
Principios del enfoque con Google Sheets
- Crear una Google Sheet no es la mejor solución para todos los problemas, pero en la situación del autor a menudo sí lo es
- Con frecuencia se enfrentaba a situaciones en las que nunca se puede conocer el alcance completo del problema hasta empezar el trabajo real
- Esto no significa que no se deban planear los proyectos
- El equipo debe discutir el flujo de trabajo y la información necesaria, pero hasta que no se empieza el trabajo real no se conoce el alcance completo del problema
- Una vez identificado el alcance completo del problema, se puede empezar a construir o mejorar la solución disponible
- En el mejor de los casos, este enfoque ayuda a evitar la carga de trabajo extra de añadir funciones innecesarias; en el peor, evita gastar tiempo en proyectos que van a fracasar
- Hasta ahora, lo mejor ha sido abordar la solución básica más pequeña y sencilla para entender el alcance completo del problema y luego iterar si es necesario
Limitaciones y aspectos a tener en cuenta
- Este enfoque también tiene desventajas; por ejemplo, en algunas organizaciones se registran todas las transacciones e informaciones en hojas de cálculo de miles de filas
- Google Sheets solo es útil antes de entender el alcance completo del problema
- Se necesita experiencia y criterio para decidir qué problemas pueden resolverse con Google Sheet
- Debe darse prioridad a desarrollar herramientas que realmente se puedan usar, sin desperdiciar tiempo
- Pero, como no es un consejo aplicable a todo el mundo, cada quien debe evaluar con cuidado según su propia situación
Conclusión
- Empezar con el menor esfuerzo y la solución más simple, y expandir o sofisticar solo cuando sea necesario, es una estrategia muy adecuada para startups o entornos con muchos cambios
- Se puede experimentar libremente en el desarrollo personal, pero en los negocios es importante construir solo lo realmente necesario y no gastar tiempo ni energía en trabajo innecesario
3 comentarios
Yo también estoy básicamente de acuerdo, pero ahora prefiero usar Notion Database como línea base inicial en lugar de Google Sheets. Se parecen, pero al final la configuración de la plantilla la hace una sola persona. Si los demás gestionan los datos sobre esa base, se pueden evitar situaciones desordenadas. No llega al nivel de
app script, pero también permite implementar automatizaciones con más facilidad. La dificultad de la configuración inicial es un po~quito más alta, pero no es mucha, y en cuanto a flexibilidad y demás, me parece que son bastante parecidos. Además, recientemente ya permite gestión de permisos a nivel de fila, así que good.Creo que Notion es bueno porque su curva de aprendizaje es baja.
Opinión de Hacker News
Este es un punto que siempre se pasa por alto. Las hojas de cálculo reúnen en un solo lugar una base de datos, una UI rápida y fácil de personalizar, y un entorno de procesamiento de datos iterativo y fácil de depurar. Es una herramienta que todos los trabajadores de oficina del mundo ya entienden y usan, y además ofrece la libertad para que quien la crea implemente lo que quiera como quiera. También es muy portátil. Estoy convencido de que es una herramienta especialmente creativa y poderosa para quienes no saben programar. Claro, esa libertad también tiene desventajas, pero más allá del debate sobre si debe ser en línea o qué proveedor es mejor, mi cariño profundo por las hojas de cálculo no disminuye ni un poco. Creo que es la mejor herramienta de autoría que hemos creado. Un modelo parecido al de las hojas de cálculo sería HyperCard. Era un banco de trabajo flexible con el que se podían entrelazar distintas apps, datos, UX y más. Ojalá HyperCard sea recordado para siempre
Exacto, las hojas de cálculo tienen una barrera de entrada bajísima. Yo incluso registro el crecimiento de los cultivos en Google Sheets desde el teléfono, en medio del campo. Aunque la señal sea débil, lo dejo guardado en modo offline y se sincroniza cuando vuelvo a casa. Aunque los registros queden desordenados, sigue siendo muchísimo mejor que no tener nada. La agricultura necesita muchos datos, pero sorprendentemente es un entorno donde faltan. El ciclo de aprendizaje es largo, de un año, y cada año es distinto
Para quienes saben programar, Appscript convierte las hojas de cálculo casi en un superpoder. Para quien no lo sepa: no necesariamente tienes que escribir solo JS en el web IDE integrado en Google Sheets (aunque la verdad es que eso también sirve bastante bien). Si usas
clasp, puedes desarrollar en Typescript desde un IDE local, compilar a JS durante el proceso de build y desplegarlo directo a la hoja de cálculo. Si ya tienes armado el toolchain, la experiencia de desarrollo (DX) es bastante buenaEstoy totalmente de acuerdo. El valor de un banco de trabajo integrado con base de datos + UX + lógica es el núcleo de las apps que parece que seguimos reinventando una y otra vez. Por eso Visual Basic todavía se sigue usando. Claro, una vez que la dirección ya está claramente definida, no es la mejor opción, pero para iterar rápido y descubrir los requisitos reales no hay nada mejor
Siempre he pensado que estaría bien tener una mejor manera de usar hojas de cálculo como backend de base de datos. Gran parte de lo que la mayoría de la gente hace con hojas de cálculo probablemente se resolvería mejor con una base de datos. Pero las bases de datos requieren más formación, y si esa formación no existe, el resultado incluso puede ser peor que con una hoja de cálculo
Siempre me he preguntado por qué no existe una ruta de transición realista para pasar gradualmente de una hoja de cálculo a una base de datos completa con UI personalizada. La hoja de cálculo está justo en la etapa anterior a eso, y parecería perfectamente posible si tuviera unas cuantas funciones esenciales (datos estructurados, SQL nativo, elementos de UI personalizados, integración con IDE, etc.)
Esto me recuerda al post "Ask HN: Is the world run by badly updated Excel sheets?". Hace falta experiencia para vivir en carne propia los límites de las hojas de cálculo. No hay control de versiones, no hay pruebas. Son buenas para trabajos cortos y de vida útil estable, pero si tienen que evolucionar de forma continua, se vuelven problemáticas. Véase https://news.ycombinator.com/item?id=33611431. Había un comentario en ese hilo que decía algo así: al final, dentro de la empresa todos se adaptan a la manera de trabajar del dueño del Excel. Si no les gusta, pueden hacer su propio Excel nuevo y copiar/pegar, así que cada quien termina gestionando lo suyo. Conozco a un project manager cuyo día a día era coordinar versiones de hojas de cálculo hechas por múltiples autores
Cuando empecé como programador en Estados Unidos en los 2000, pensaba que mi trabajo era convertir en webapps esas hojas de cálculo en drives de red de Windows que siempre necesitaban que alguien las cuidara con cariño. Aun así, muchas empresas siguen funcionando bastante bien sobre hojas de cálculo. Al final llega el momento en que explota el problema de escalabilidad, y ahí sí toca moverlo a una app, pero entre querer hacerlo perfecto y no hacer nada, es más importante sacarlo adelante
Dices que "no hay control de versiones", pero en realidad Excel sí tiene funciones de control de versiones. Si usas "Track Changes", puedes aprobar o rechazar cambios hechos por otras personas. Solo que quienes trabajan con automatizaciones de hojas de cálculo tipo Rube Goldberg casi nunca usan esa función. Pero si hace falta, se puede usar
He visto muchos problemas cuando la información queda dispersa entre varias hojas de cálculo. A menudo los involucrados no saben qué información está en cuál hoja ni cuál es la fuente de verdad. Entonces alguien actualiza solo el archivo A sin que los demás se enteren, mientras otra persona toca solo el B, y así surgen choques todo el tiempo. Más que un problema del programa o de los datos, el problema era cómo se gestionaban los archivos dentro del proyecto. Se vuelve un laberinto de administración: carpetas compartidas complejas, archivos abandonados en algún punto de la red, etc.
Estoy de acuerdo con el consejo de "usa siempre la forma más sencilla de resolver el problema, y cuando deje de servir para el negocio, mejórala o busca una solución alternativa según los nuevos requisitos". Hay que enfocarse en resolver el problema actual; intentar anticipar problemas futuros, o incluso problemas que uno desearía tener, rara vez sale bien. La solución actual puede volverse inadecuada en el futuro, pero es difícil predecir exactamente cómo se volverá inadecuada
Puede ser difícil predecir en qué dirección una solución dejará de servir en el futuro, pero aun así puedes elegir una solución actual de forma que no bloquee ni estorbe la solución futura. Conviene mantener abiertas las opciones y evitar quedar atrapado en una dependencia de proveedor de la que no puedas salir
Un caso típico y predecible de inadecuación futura es depender por completo de un proveedor específico, hasta el punto de que puedan expulsarte del servicio o forzarte a aceptar precios cada vez más altos. Ese sí es un problema bastante predecible
Si resuelves el problema de una manera que abarque de forma más amplia el dominio del problema sin hacer más trabajo, puedes absorber requisitos cambiantes con pequeños ajustes, lo que hace que la solución sea más robusta. Así, de paso, terminas cubriendo también problemas futuros
Trabajo en una gran empresa muy conocida de Estados Unidos. Nuestro departamento depende muchísimo de dos hojas de cálculo. Han sobrevivido a tres adquisiciones/fusiones relacionadas con mi planta. Cuando entré hace 7 años, ya eran formatos viejos. Hace 2 años, un gerente nuevo intentó migrarlo a un sistema corporativo, pero fracasó, y pronto ese sistema también será reemplazado por otro nuevo. Pero igual creo que en 2027 seguiremos usando las hojas de cálculo
Soy ex empleado de Google. Durante 5 años manejé todo mi trabajo solo con Sheets (internamente se le llamaba Trix): gestión de proyectos, CRM, planeación trimestral, reportes, entrevistas, finanzas, todo. No era simplemente porque fuera un producto de Google (también usábamos bastante productos de la competencia). La comodidad abrumadora estaba en que las hojas de cálculo se podían construir lo suficientemente rápido como para servir al objetivo, y eso te dejaba concentrarte en la esencia del trabajo
Sobre la opinión de alguien que dijo "llevo 9 meses en el trabajo", pienso que, tenga razón o no, hace falta bastante descaro para dar una opinión tan tajante con menos de un año de experiencia. Lo que el OP pasó por alto es la verdad de que "no hay nada más permanente que una solución temporal". Está bien elegir una solución rápida e improvisada en el corto plazo, pero solo si controlas por completo el ciclo de vida de esa solución. Si alguien te pidió algo, lo entregaste de prisa, y luego empiezan a montarle nuevos usos encima de forma continua… ahí sí me pongo a defender con fuerza una herramienta con un costo inicial un poco mayor
Casi me hizo reír la parte de "una vez cada pocos meses..." de ese problema. El autor acertó en que la gran regla es resolver las cosas con herramientas simples. Si puedes usar la herramienta existente tal como está y satisface razonablemente la necesidad, mejor aún. En la práctica, como los requisitos de negocio cambian cada pocos meses, a veces uno puede evitar el fenómeno de que "lo temporal se vuelve permanente". Pero para la mayoría, años después sigues pagando el costo acumulado, y el escenario de "lo reescribimos cuando haga falta" casi nunca funciona. Además, el autor todavía no ha vivido realmente lo que pasa al cabo de un año o más
A mí también me llamó especialmente la atención esa parte de "cada pocos meses...". Me pregunto si lo habrá vivido unas 4 veces antes de decirlo
Para quienes se cansaron de las hojas de cálculo gigantes, MS Access era una solución bastante útil. Añadía estructura y mantenibilidad a la hoja de cálculo sin perder accesibilidad ni facilidad de desarrollo. Se podía crear una gran UI sin mucho conocimiento de programación. Veinte años después, yo tampoco tengo muy claro cuál sería hoy el reemplazo de Access
Estoy totalmente de acuerdo con el OP. Agregaría una cosa: cuando los requisitos se vuelven demasiado complejos para manejarlos en Google Sheets, Google Colab (o un Jupyter notebook) es el siguiente escalón. Antes de construir una app de verdad, siempre me pregunto: 1. ¿Esto se puede resolver solo con una hoja de cálculo? 2. Si no, ¿se puede con un Jupyter notebook? Además, la integración entre Sheets y Colab es excelente
En mi opinión, un jupyter notebook es una capa de complejidad mucho mayor que simplemente escribir un script de python. También puedes poner comentarios en un script de python, y no me convence eso de "levantar un servidor web local y ejecutar por bloques de código para poder ver los comentarios"
Me da curiosidad cómo se hace para subir algo que ya estaba en una google sheet a un colab notebook. Con el paquete de python
gspreadpuedes leer los datos raw de la hoja, pero parece difícil llevarte también los gráficos existentes o los elementos interactivos tal cual a jupyter notebook. Al final, seguramente habría que reconstruirloGoogle Apps Script también es una buena alternativa. Incluso con scripts simples, como para traer datos, se pueden hacer bastantes cosas
Uno de los mayores problemas de la automatización empresarial es la brecha que existe entre la llamada IT "en la sombra" (
shadowIT), las plataformas low-code y los proyectos plenamente "formales". Falta una ruta de migración razonable entre "armarlo rápido con google form" y "montar una app en react con CI/CD, pruebas y CDN". Solo hay alternativas tipo jardín amurallado, incompatibles entre síYo manejo todas mis finanzas con Google Sheets. Incluso me hice mi propia UI de Expense Tracker y he ido acumulando más de 5,000 registros de gastos durante varios años. Últimamente también hice, con vibe coding, una herramienta web UI usando Google Service Account, y la convertí en PWA para usarla desde el teléfono. Para usos simples (sobre todo aplicaciones para una sola persona), Google Sheets basta perfectamente en lugar de una DB