Una decisión de 10 minutos que casi cuesta un proyecto
Hace tiempo, un cliente me pidió ayuda para desbloquear el desarrollo de una aplicación móvil. El problema radicaba en la persistencia de datos: la app debía permitir recopilar inspecciones en zonas sin cobertura, lo que obligaba a almacenarlas temporalmente en el dispositivo. Inicialmente, se optó por una base de datos relacional, una decisión que técnicamente parecía acertada.
El problema: Los datos eran estructuralmente más parecidos a documentos que a tablas rígidas. Esto, sumado a los constantes cambios en los requerimientos, convirtió la arquitectura en una pesadilla. Cada vez que se añadía un campo o se modificaba un formulario, el equipo debía realizar migraciones de base de datos complejas y transformaciones manuales que consumían mucho tiempo y generaban errores constantes.
La solución que propuse: almacenar los datos en ficheros JSON, más que suficiente para almacenar la información temporalmente hasta el momento de transmitirla.
El código es un pasivo, el producto es el activo
Un desarrollador móvil con mentalidad de CTO no solo escribe código que funciona; escribe código que construye una empresa. La diferencia radica en pasar del «¿cómo lo implemento?» al «¿por qué lo hacemos y a qué coste?«.
Así es como piensa un perfil estratégico:
- El código como deuda: Entiende que cada línea de código escrita es algo que habrá que mantener y pagar en el futuro. Quien sabe cuándo no programar es tan valioso como quien sabe hacerlo.
- Tecnología «aburrida» pero sólida: Aunque le apasione la innovación, prefiere tecnologías maduras. ¿Por qué? Porque es más fácil encontrar talento, tienen menos errores inesperados y garantizan que la app siga viva en dos años.
- Visión de «App Store»: A diferencia de una web, una app móvil no se actualiza instantáneamente. Un error en producción puede tardar días en corregirse por los tiempos de revisión de Apple o Google y las actualizaciones en los dispositivos de los usuarios. El pensamiento de CTO implica una gestión de riesgos mucho más rigurosa antes de cada lanzamiento y valorar el uso de técnicas (p. ej. feature flags) que permitan modificar el comportamiento de la app sin tener que publicar una nueva versión.
- Equilibrio entre velocidad y deuda: Sabe que en un MVP (Producto Mínimo Viable) se pueden tomar atajos para validar el mercado, pero identifica exactamente cuándo hay que «limpiar la casa» para que la app no se derrumbe bajo su propio peso meses después.
Errores comunes que matan startups y PYMES
- Ignorar la incertidumbre técnica crítica: Si el valor depende de una innovación técnica o de unas prestaciones exigentes, no construyas toda la app de golpe. Haz una prueba de concepto de tres días. Si la tecnología no responde, no habrás perdido tres meses.
- Esperar demasiado para validar el modelo de negocio: Especialmente critico si nuestra app propone una funcionalidad muy innovadora que quizás el mercado no acabe valorando nunca.
- Sobre-ingeniería: Las arquitecturas de software y los patrones de diseño son herramientas poderosas que conviene usar juiciosamente. Tan pernicioso es ignorarlas como aplicarlas ciegamente.
Cómo detectar (o entrenar) esta mentalidad
Desarrollar esta visión no sucede de la noche a la mañana; es una transición de enfoque. Si quieres saber si tu equipo tiene este «chip» o quieres ayudarles a desarrollarlo, busca estas señales:
| Enfoque tradicional | Enfoque «thinking like a CTO» |
|---|---|
| «Necesitamos refactorizar este módulo.» | «Si invertimos 2 días en limpiar este módulo, las próximas funciones saldrán un 30% más rápido.» |
| «Usemos la última librería que salió ayer.» | «¿Esta librería tiene comunidad? ¿Habrá soporte en 2 años? ¿Es segura?» |
| «He terminado la tarea según el ticket.» | «He visto que esta función no ayuda al objetivo de retención de usuarios de este mes, ¿seguro que la queremos así?» |
Enamorarse del problema, no de la solución. Si el problema de un usuario se resuelve con una pantalla sencilla en lugar de una animación 3D compleja, y eso ahorra 40 horas de presupuesto, el «Developer-CTO» siempre elegirá el ahorro para reinvertirlo en lo que realmente genera ingresos.
¿Sientes que tu equipo técnico y tus objetivos de negocio hablan idiomas distintos?