Un desarrollador solo puede darte un precio fijo si el trabajo está escrito con la claridad suficiente para cotizarse. Cuando no lo está, recibes un rango, y ese rango lo resuelve después quien tenga menos voz en la conversación, casi siempre tú.
Esta guía recorre lo que conviene escribir antes de hablar con nadie. Toma una tarde y sirve igual si nos contratas a nosotros o a otra persona.
#Empieza por el problema y quién lo tiene
Escribe dos o tres frases: quién tiene el problema, qué intenta lograr y qué falla hoy. Nombra roles reales, no “la empresa”. Por ejemplo: “Los despachadores vuelven a escribir cada trabajo desde el correo en una hoja de cálculo, y los conductores llaman para preguntar qué cambió”.
Evita describir una solución aquí. “Necesitamos una app” es una solución. “Los conductores no pueden ver su día sin llamar a la oficina” es un problema, y deja espacio para una respuesta mejor que la que tenías en mente.
#Mapea el proceso actual
Escribe el proceso tal como funciona en realidad, no como dice el manual. En cada paso, anota cuatro cosas:
- Qué ocurre (un verbo y un objeto)
- Quién lo hace
- Cuánto tarda, más o menos
- Dónde falla: traspasos que se pierden, datos que se vuelven a escribir, esperas, errores que alguien tiene que corregir después
La columna de “dónde falla” es la parte más valiosa de la página. Le dice al desarrollador dónde está el trabajo. Si quieres un formato ya listo, usa la hoja de mapeo de procesos.
#Lista los sistemas y los datos involucrados
Anota cada herramienta que toca el proceso: hojas de cálculo, correo, software de contabilidad, un CRM, un sitio web, un sistema telefónico. De cada una, anota qué datos viven ahí y si el sistema nuevo necesita leerlos, escribir en ella o reemplazarla.
Anota también cuántos datos hay. Unos cientos de filas y diez años de registros son migraciones muy distintas. Si parte de los datos está desordenada (duplicados, campos de texto libre, nombres inconsistentes), dilo desde ahora.
#Separa lo indispensable de lo que viene después
Haz dos listas. Lo indispensable es aquello sin lo cual el desarrollo no tiene sentido. Todo lo demás va en “después”.
Una buena prueba: si la primera versión saliera sin esta función, ¿la gente podría hacer su trabajo? Si la respuesta es sí, es de “después”. Sé estricto, porque cada elemento indispensable se cotiza y cada elemento de “después” se puede cotizar por separado cuando la primera versión ya esté funcionando.
#Di qué queda fuera del alcance
Escribe una lista corta de lo que el desarrollo no hará. Lo que queda fuera del alcance evita la disputa más común: una parte asumió que estaba incluido y la otra no. Ejemplos típicos son “sin acceso público para clientes”, “sin migración de registros anteriores a 2020” o “sin cambios al sistema de contabilidad”.
Si no estás seguro de si algo va en esta lista, ponlo ahí y deja que el desarrollador te pregunte.
#Indica tus restricciones
Las restricciones influyen en el precio tanto como las funciones. Anota:
- Fecha límite: una fecha real y el motivo (una temporada, un contrato, alguien que empieza a trabajar)
- Rango de presupuesto: una cifra o una banda, aunque sea aproximada. Permite que el desarrollador proponga lo que cabe en lugar de adivinar
- Idiomas: qué idiomas necesitan los usuarios y las pantallas: inglés, español o ambos
- Cumplimiento y privacidad: cualquier regla sobre datos de clientes, pagos, expedientes de salud o dónde se pueden almacenar los datos
- Personas: quién lo usará, cuántas son y en qué dispositivos
#Decide cómo sabrás que funcionó
Elige dos o tres medidas antes de que empiece el desarrollo, mientras nadie está encariñado con el resultado. Deben ser cosas que puedas observar: la cantidad de datos que se vuelven a escribir a mano por día, cuánto tarda en enviarse una cotización, cuántas llamadas quedan sin contestar.
Escribe ahora el número de partida, aunque sea una estimación. Sin una base de comparación, “funcionó” se convierte en una opinión.
#Ponlo en una sola página
Todo lo anterior cabe en una sola hoja. Si quieres una plantilla, el brief de proyecto en una página tiene una sección para cada punto de aquí. Envíalo antes de la primera llamada y espera mejores preguntas y una cifra más firme a cambio.
Si algo de tu página sigue siendo vago, no pasa nada. Márcalo como una pregunta abierta. Un buen taller de descubrimiento existe justamente para cerrar esos huecos, y una lista escrita de preguntas abiertas es mucho más barata de resolver que una sorpresa a la mitad del desarrollo.
