En tecnología es fácil asociar sofisticación con calidad. Una solución con muchas piezas, nombres modernos y arquitectura compleja parece más profesional.
Pero muchos proyectos no necesitan más complejidad. Necesitan resolver un problema concreto, mantenerse sin drama y permitir cambios razonables. Ahí las soluciones sencillas suelen ganar.
Sencillo no significa ...
La aportación técnica suele medirse cuando aparece algo visible: una web, una aplicación, una integración o una automatización. Pero parte del valor más importante llega antes.
Un buen técnico ayuda a no construir mal. Pregunta, ordena, detecta riesgos, traduce incertidumbre y evita que una decisión tomada con prisa se convierta en una limitación cara.
Hace preguntas ...
Automatizar seduce porque promete recuperar tiempo. Una tarea repetitiva desaparece, un informe se genera solo o un sistema conecta datos sin intervención humana.
El problema aparece cuando automatizamos algo que todavía no entendemos. Entonces no eliminamos trabajo: escondemos decisiones, fijamos errores y hacemos más rápido un proceso que quizá necesitaba ...
Añadir código produce una sensación agradable de avance. Hay una funcionalidad nueva, una pantalla más, una automatización o una integración que antes no existía.
Pero cada línea que entra en un sistema deja una pequeña obligación futura. Habrá que entenderla, probarla, actualizarla, corregirla y decidir qué hacer cuando el contexto cambie.
El código no termina ...
Durante años se ha usado la expresión “picar código” como si programar fuera una tarea mecánica: alguien piensa, alguien diseña y el programador convierte instrucciones en líneas de software.
Esa visión se queda corta. Programar también es entender un problema, detectar ambigüedades, decidir compromisos, anticipar mantenimiento y construir algo que otras personas ...
Mirar atrás tiene trampa. Desde el presente todo parece evidente y uno corre el riesgo de juzgar con demasiada dureza decisiones tomadas con menos información. Aun así, revisar primeros proyectos sirve para detectar aprendizajes que se repiten.
No cambiaría haber probado, fallado o insistido. Sí habría intentado aprender antes algunas cosas: hablar más con clientes, ...
En un proyecto nuevo hay muchos falsos positivos. Reuniones, mensajes, visitas, ideas, tareas cerradas y gente que dice que le gusta lo que haces. Todo eso puede ayudar, pero no siempre indica que vas por buen camino.
Conviene distinguir movimiento de progreso. El progreso deja señales más exigentes: alguien usa, alguien paga, alguien vuelve, alguien recomienda o el equipo ...
Empezar tiene una energía especial. Se elige un nombre, se compra un dominio, se cuentan planes y todo parece abierto. Esa fase es necesaria, pero no es la más difícil.
Lo difícil llega después, cuando el proyecto ya tiene fricción. Clientes que no entienden la propuesta, ventas que tardan más, funciones que nadie usa, costes que pesan y datos que contradicen la ...
Una idea puede ser brillante y seguir siendo solo una idea. Puede tener nombre, logo, dominio comprado y una presentación bonita. Nada de eso la convierte todavía en empresa.
Empieza a parecer una empresa cuando aparecen señales menos románticas: alguien paga, alguien repite, hay una forma de entregar valor, los costes tienen sentido y el proyecto puede seguir funcionando ...
Antes de montar una empresa, diseñar una marca, buscar financiación o encargar una web, conviene hacer algo bastante menos vistoso: hablar con posibles clientes. No para pedir permiso ni para hacer una encuesta decorativa, sino para entender si el problema que imaginamos existe de verdad.
La mayoría de proyectos no fallan porque falte una idea. Fallan porque se construyen ...
