Método de trabajo
Primero entiendo el sistema. Después decido qué merece ser construido.
No comienzo por una pantalla ni por una tecnología concreta. Empiezo por comprender qué ocurre, quién participa, dónde aparece la dificultad y qué tendría que cambiar para que el trabajo funcionara mejor.
Mi método reúne pensamiento empresarial, diseño de sistemas y programación. Cada fase prepara la siguiente, pero todas permanecen conectadas.
COMPRENDER
Escuchar antes de proponer.
Necesito conocer la situación real, no solo la versión resumida del problema. Pregunto qué se intenta conseguir, cómo se trabaja ahora y dónde se rompe el proceso.
Una buena solución empieza cuando el problema deja de ser una frase genérica y se convierte en algo que puede observarse y explicarse con claridad.
ORDENAR
Dibujar el sistema completo.
Organizo las personas, la información, las decisiones y los recorridos que intervienen. Este mapa permite distinguir lo esencial de lo accesorio y descubrir dependencias que una pantalla aislada no mostraría.
DECIDIR
Elegir qué construir y qué no.
No todo necesita una función nueva. A veces la mejor decisión es simplificar, conectar piezas existentes o eliminar un paso.
Aquí defino una dirección coherente: qué debe resolver el sistema, qué experiencia necesita ofrecer y qué estructura puede sostenerlo.
DISEÑAR Y PROGRAMAR
Convertir las decisiones en una experiencia real.
Diseño para que el sistema pueda comprenderse y programo para que pueda funcionar. Mantener ambas tareas conectadas evita que la interfaz prometa algo que el código no puede cumplir o que una buena solución técnica resulte difícil de utilizar.
REVISAR
Volver a mirar cuando el sistema ya existe.
Construir permite comprobar las decisiones. Reviso el funcionamiento, observo lo que necesita más claridad y ajusto aquello que solo podía descubrirse al llevar la idea a la realidad.
PRINCIPIOS
Tres criterios que atraviesan todo el proceso.
Claridad antes que espectáculo
La forma debe ayudar a comprender el sistema y no competir con él.
Coherencia antes que parches aislados
Cada decisión debe tener sentido dentro del conjunto.
Cercanía al código
Me mantengo cerca de la implementación porque ahí se comprueba la calidad real de una idea.
EMPEZAR
No hace falta llegar con un documento perfecto.
Es suficiente con poder explicar qué ocurre ahora, qué quieres cambiar y por qué es importante. A partir de ahí podemos ordenar el problema y descubrir si tiene sentido construir algo nuevo.