Las cinco preguntas que hago antes de escribir una línea de código.

Cuando alguien me escribe para hacer un sistema, lo último que pregunto es qué quiere que haga el sistema.

No porque no importe. Porque la respuesta a esa pregunta cambia tres veces durante el proyecto, y hay otras cinco que no cambian y que definen si va a salir bien.

Las dejo acá por dos razones. Una, para que sepas cómo trabajo antes de arriesgar plata conmigo. Dos, porque si las contestás para vos mismo vas a estar mejor parado con cualquier proveedor, trabajemos juntos o no.

1. ¿Cómo lo hacés hoy?

Antes de qué querés que pase, necesito saber qué pasa ahora. Quién recibe, quién revisa, dónde se anota, qué se hace cuando algo sale distinto.

Si la respuesta es clara, el proyecto arranca con la mitad del riesgo afuera. Si la respuesta es "depende" o "eso lo maneja Marcela", ahí está el primer trabajo, y no es de programación.

2. ¿Qué pasa si no hacemos nada?

Suena a pregunta de vendedor al revés, y es la más útil de todas.

Si la respuesta es "seguimos como estamos, incómodos pero funcionando", tenés tiempo y conviene hacer las cosas bien. Si la respuesta es "en tres meses no podemos facturar", estamos hablando de otra cosa y hay que resolver eso primero, aunque sea feo.

Muchas veces esta pregunta destapa que el problema urgente no es el que me estaban contando.

3. ¿Quién decide?

Necesito un nombre. Una persona que pueda decir "se hace así" sin consultar.

No tiene que ser el dueño ni saber de tecnología. Tiene que existir y tener que estar disponible. Los proyectos que se estiran casi nunca se estiran por la parte difícil: se estiran esperando definiciones.

4. ¿Qué es lo único que tiene que funcionar sí o sí?

Todo pedido tiene una lista de veinte cosas. Casi siempre hay una sola que, si falla, hace que el resto no sirva.

Saber cuál es cambia el orden en que se construye. Se empieza por ahí, se prueba con gente real temprano, y el resto se acomoda alrededor. Si nadie eligió esa única cosa, se construye todo con la misma prioridad, que es la forma más cara de trabajar.

5. ¿Qué queda explícitamente afuera?

Esta es la que más incomoda y la que más protege a las dos partes.

Escribir qué no incluye el proyecto evita la conversación de "yo pensé que esto venía", que es donde se rompe la confianza. Y no cierra ninguna puerta: lo que queda afuera hoy se puede hacer después, cotizado aparte y con la cabeza fría.

Un presupuesto que solo dice lo que incluye está incompleto.

Si no podés contestarlas

Es más común de lo que parece, y no es una mala señal: es una señal de en qué etapa estás.

Si te faltan varias respuestas, todavía no es momento de contratar a nadie para construir. Es momento de sentarse a ordenar, que no cuesta dinero y baja el precio de todo lo que venga después.

Te lo voy a decir si veo eso. Prefiero perder un proyecto que empezar uno que va a salir mal, porque el que sale mal me cuesta a mí también: tiempo, reputación y una relación que se rompe.

Si querés que hagamos estas cinco preguntas juntos, la primera charla es sin costo y sin compromiso. A veces termina en un proyecto, y a veces en un plan para dentro de seis meses.