Lo que podemos saber en una llamada de treinta minutos

La primera conversación dura treinta minutos y no cuesta nada. No es un descuento: es que media hora suele bastar para saber si aquí hay un proyecto, y a ninguno de los dos nos conviene averiguarlo despacio.

Qué preguntamos

No requisitos. Proceso. Quién hace hoy el trabajo, qué hace cuando algo sale mal y con qué frecuencia pasa. Los requisitos son lo que alguien ya ha decidido que quiere; el proceso es donde vive de verdad el problema, y con frecuencia no coinciden.

Qué solemos poder establecer

Si el problema es de software siquiera. Una parte sorprendente de lo que llega como petición de desarrollo es un proceso que nadie ha cambiado porque cambiarlo es incómodo. El software lo vuelve permanente y caro.

Si se puede cerrar el alcance. Parte del trabajo se puede presupuestar a precio cerrado con honestidad; otra parte no, y fingir lo contrario produce una petición de cambio en el segundo mes. Decimos cuál es cuál al principio en lugar de descubrirlo después.

Aproximadamente cuánto vale. No un presupuesto. Si el coste del problema es plausiblemente mayor que el de resolverlo, porque si no lo es, todo lo que venga después es esfuerzo perdido.

Por qué a veces decimos que esperes

Porque los datos no están listos, o el proceso va a cambiar de todas formas, o lo que necesitas existe ya hecho por una fracción de lo que costaría construirlo. Decirlo pronto te sale más barato a ti y a nosotros nos conviene más que un proyecto que decepcione.

Qué pasa después

Si hay algo que merezca la pena, recibes por escrito qué haríamos, en qué orden y qué partes cerraríamos a precio fijo y cuáles no. Si no lo hay, también lo recibes por escrito, con lo que haríamos en su lugar.

En cualquier caso hablas con un ingeniero capaz de construirlo, no con alguien que se lo traslada después a uno.