Cuatro pasos. El segundo puede ser parar.
Es el mismo recorrido en todos los encargos, cambie el sector o la tecnología. Lo que cambia es por dónde se entra y hasta dónde se llega.
Qué pasa, y en qué orden.
-
Entender el contexto
Cómo funciona de verdad el negocio o el proyecto, qué se quiere conseguir, quién va a usarlo y con qué condicionantes. El problema inicial y lo que realmente hace falta no siempre coinciden: alguien pide una web y lo que necesita es que le lleguen encargos.
-
Definir qué merece construirse
Qué solución encaja, cuánta complejidad necesita de verdad, hasta dónde llega el alcance y qué queda fuera. Aquí el trabajo puede terminar, y a veces debe.
-
Construir con control
Construir o reconstruir sin complicar porque sí, en trozos pequeños y sin poner en riesgo innecesariamente lo que ya funciona. Con el alcance, el plazo y el precio escritos antes de empezar.
-
Comprobar que resuelve el problema
Que hace lo que tenía que hacer, que la persona que lo va a usar puede usarlo y que su mantenimiento es razonable. Si no se puede comprobar, no está terminado.
No se toca lo que funciona sin poder volver atrás.
El miedo a que alguien te rompa lo que ya tienes montado es razonable. Muchas veces el trabajo entra en algo que ya está en marcha y del que alguien depende, así que se organiza para que un error no se convierta en un problema.
- Cambios pequeños, uno cada vez, en vez de una sustitución completa.
- Pruebas reversibles: antes de tocar nada se prepara cómo deshacerlo.
- Validación con datos reales, no con ejemplos que siempre salen bien.
- Revisión antes de escalar: primero en pequeño, y solo después al resto.
Nada se sustituye hasta que lo nuevo se ha comprobado funcionando al lado de lo viejo.
Entender el problema y decidir qué merece construirse.
Aporto criterio de producto y capacidad para convertir una necesidad poco definida en algo concreto y construible. Entiendo el contexto, decido el alcance, construyo y compruebo sin perder de vista quién va a usarlo después.
La parte que más valor tiene no es escribir código: es decidir qué hay que construir, con qué alcance, y cuándo no hace falta construir nada. El contexto, las decisiones, la comprobación y la responsabilidad son míos.
Hasta dónde llego.
Construyo y reconstruyo, y analizo el contexto que hace falta para construir bien. Ese es el terreno:
- Digo qué he mirado y qué no, para que conozcas el alcance exacto de lo que recibes.
- No doy soporte ni mantengo software de terceros que no he construido.
- No hago consultoría de procesos, de compras ni de gestión empresarial.
- En materias reguladas o de alta especialización —fiscal, jurídica, seguridad avanzada— derivo a quien corresponde.