Cómo estimar un proyecto cuando el cliente todavía no sabe exactamente qué quiere

No finjas precisión mientras el proyecto siga siendo incierto

Un cliente dice que necesita un dashboard, quiere automatizar un proceso o necesita una web moderna pero no sabe exactamente qué debe contener. La presión por dar precio aparece inmediatamente. Nadie quiere parecer difícil o poco experimentado, así que se hacen unas preguntas, se imagina una versión razonable y se produce una cifra precisa. La cifra parece profesional; la información de debajo no. Un total limpio puede esconder una enorme incertidumbre cuando los requisitos siguen siendo supuestos.

Precisión y exactitud no son lo mismo. Una cotización de 7.480 $ puede ser menos responsable que un rango de 6.000–10.000 $ si faltan requisitos centrales. El número exacto da la impresión de que la incertidumbre se resolvió cuando solo se ocultó. Después, cuando aparecen las necesidades reales, cada detalle nuevo parece scope creep aunque nadie pudiera haber definido bien el alcance original. Ambas partes pueden sentirse engañadas sin que nadie intentara engañar.

Tu trabajo en esta fase no es predecir el futuro. Es reducir la incertidumbre hasta un nivel en el que tenga sentido un compromiso comercial. A veces bastan quince minutos de aclaraciones. Otras veces hacen falta discovery pagado, auditoría, entrevistas o un prototipo. Lo importante es incorporar la incertidumbre al proceso en lugar de fingir que no cuesta nada. Una estimación responsable empieza admitiendo lo que aún no sabes.

Separa lo conocido, lo asumido y lo desconocido

Crea tres listas. Lo conocido son hechos que ambas partes pueden confirmar ahora: sistema existente, fecha obligatoria, número de usuarios, plataformas soportadas o requisitos legales. Los supuestos son cosas que temporalmente tratas como ciertas para poder estimar: el cliente entregará copy final, una persona aprobará diseño, la API actual expone los datos necesarios. Lo desconocido son preguntas que pueden cambiar materialmente esfuerzo pero aún no tienen respuesta.

Separarlas evita que un supuesto se convierta silenciosamente en promesa. Si estimas una migración suponiendo datos limpios, escríbelo junto al precio. Si aparecen miles de duplicados, se entiende por qué cambió el trabajo. Sin el supuesto escrito, tú recuerdas una condición y el cliente recuerda un precio. Una frase compartida convierte memoria en referencia común.

Prioriza desconocidos por impacto. No hace falta investigar cada detalle. Empieza por preguntas capaces de cambiar arquitectura, volumen de tareas, especialistas, coste de terceros, criterios de aceptación o calendario. Una etiqueta de botón no tiene el mismo impacto que desconocer si el sistema legacy ofrece API. Lo de alto impacto debe resolverse antes de cerrar el modelo comercial.

• Conocido: hechos verificables por ambas partes ahora
• Asumido: condición temporal que permite construir la estimación
• Desconocido: pregunta capaz de cambiar coste o calendario de forma material
• Alto impacto: cambia arquitectura, volumen, dependencia o criterios de aceptación
• Bajo impacto: detalle que puede decidirse después sin cambiar el modelo comercial

Usa discovery pagado cuando resolver lo desconocido requiere trabajo real

Discovery no es una llamada de ventas gratis con mejor nombre. Si hay que inspeccionar datos, revisar un sistema existente, entrevistar stakeholders, probar una API, mapear un proceso o definir requisitos, ese trabajo crea valor. Reduce riesgo para el cliente y te da información para estimar la entrega responsablemente. Hacerlo antes no lo convierte en gratuito.

Una fase de discovery puede ser fixed-price cuando su output está claro: mapa de requisitos, evaluación técnica, scope priorizado, wireframes y nueva estimación. También puede ser horaria con cap cuando la propia investigación es incierta. Define qué recibe el cliente al final en lugar de vender investigación ilimitada. Un buen discovery termina en mejores decisiones, no simplemente en más documentos.

Es especialmente útil cuando el escenario pesimista es muchísimo más caro que el optimista. Si una integración puede ser dos días o seis semanas según lo que se descubra, cotizar la media no reparte el riesgo. Invierte una cantidad menor en averiguar en qué escenario estás y luego cotiza implementación desde evidencia. El cliente gana control y tú no apuestas margen sobre información que nadie posee.

Estima con rangos en lugar de forzar un número mágico

Mientras exista incertidumbre, un rango honesto es mejor que falsa precisión. Un rango útil no es entre cinco y cincuenta mil. Está ligado a escenarios: el extremo bajo a supuestos favorables concretos y el alto a riesgos conocidos o decisiones más complejas. Explica qué mueve el proyecto. Un rango sin razones es vago; un rango conectado a decisiones es una herramienta.

Para tareas inciertas usa tres puntos: optimista, probable y pesimista. La fórmula (optimista + 4 × probable + pesimista) ÷ 6 puede dar un número de planificación manteniendo el rango. Lo más importante es escribir el caso pesimista antes de comprometerte. Si el peor caso razonable es comercialmente inaceptable, cambia el modelo antes de firmar.

Si el cliente necesita techo de presupuesto, usa aprobaciones por etapas. Puedes limitar discovery a una cantidad y empezar implementación solo después de aprobar otra estimación. También puedes usar time and materials con cap semanal o máximo. El modelo comercial debe contener incertidumbre, no negarla. El control presupuestario puede venir de límites y checkpoints en lugar de inventar scope final.

• Vincula el extremo bajo a supuestos favorables explícitos
• Vincula el extremo alto a riesgos o decisiones más complejas
• Usa tres puntos para tareas inciertas
• Usa caps o checkpoints cuando el cliente necesite control presupuestario
• No conviertas un rango muy amplio en un punto medio fijo solo para que la propuesta quede bonita

Escribe supuestos y exclusiones directamente en la estimación

Una estimación con scope poco claro vale lo que valen los supuestos que la sostienen. Pon los importantes junto al precio: quién aporta contenido, cuántos stakeholders aprueban, qué formato de datos esperas, qué sistemas ya son accesibles, cuántas revisiones se incluyen y qué costes de terceros quedan fuera. Son inputs del cálculo, no decoración legal.

Las exclusiones son igual de importantes. No son lenguaje hostil ni negativa a ayudar; definen el límite de la decisión actual. Si copywriting, traducción, limpieza de migración, revisión legal, analytics avanzadas o integraciones personalizadas no están incluidos, dilo. Una exclusión clara puede convertirse después en una opción en lugar de un conflicto.

Usa lenguaje normal. El propósito no es crear un documento capaz de vencer a un abogado, sino que dos personas lean la misma frase e imaginen aproximadamente el mismo proyecto. Si un supuesto sorprendería al cliente, háblalo antes de aceptar la cotización. La mejor estimación no tiene más disclaimers; tiene menos interpretaciones ocultas.

Ofrece fases y opciones en lugar de una cotización de todo o nada

Los proyectos inciertos son más fáciles de comprar cuando se dividen en decisiones. En vez de pedir aprobación para un presupuesto grande y nebuloso, ofrece una primera fase que crea claridad y una segunda que entrega la solución definida. También puedes ofrecer versión mínima y ampliada mientras el cliente decide cuánta complejidad necesita. Las decisiones pequeñas son más fáciles de cotizar y de detener.

Las opciones deben representar scope real, no price anchoring artificial. Por ejemplo, importación manual ahora frente a integración automática después de validar la API; cinco páginas principales frente a migración completa. El cliente elige un trade-off comercial y tú no finges que ambas versiones requieren el mismo trabajo. A veces no sabe lo que quiere porque las funcionalidades todavía no han tenido que competir por el mismo presupuesto.

Las fases crean puntos naturales de parada. Si discovery demuestra que una función no tiene sentido económico, el cliente puede terminar después de recibir hallazgos útiles. Eso hace que discovery sea un activo de decisión y no solo un coste antes del trabajo real. Una buena primera fase conserva valor aunque la segunda nunca ocurra.

• Discovery primero, cotización de implementación después
• Scope mínimo viable frente a ampliado
• Core conocido a precio fijo, integración incierta por horas
• Aprobación de milestone antes de comprometer el siguiente presupuesto
• Módulos opcionales después de validar el resultado principal

Define de antemano cómo la nueva información cambia precio y calendario

Un proyecto incierto debería volverse más claro. El proceso debe explicar qué ocurre cuando aparecen datos nuevos. Si un requisito cabe dentro del entregable y supuestos aprobados, puede ser una refinación. Si añade output, dependencia, integración, audiencia o criterio de aceptación, necesita change request o nueva estimación. La regla debe basarse en consecuencias, no en lo pequeño que suene el mensaje.

No esperes a la factura para clasificar cambios. Cuando un descubrimiento altere el esfuerzo, pausa la parte afectada y documenta impacto: qué cambió, coste adicional o reducido, efecto en calendario y nuevos supuestos. Si cambia el compromiso comercial, consigue aprobación escrita antes de seguir. Dos minutos de aclaración antes de implementar cuestan menos que una disputa después de entregar.

Esto protege también la relación. Los clientes suelen odiar más las facturas sorpresa que escuchar que una petición nueva cuesta dinero. Un proceso calmado les da control: aprobar, quitar otra cosa, posponer o mantener el scope original. Es una decisión de negocio, no una confrontación. El proyecto puede aprender sin convertir cada nuevo dato en culpa de alguien.

Ejemplo: estimar un dashboard antes de tener requisitos

Un cliente pide un dashboard operativo. Sabe que quiere ventas, inventario y personal juntos, pero todavía no define métricas, calidad de datos ni permisos. Una cotización fija te obligaría a inventar respuestas. Propón discovery: workshop, revisión de tres fuentes, mapa de permisos, wireframes y scope priorizado. Esos outputs sí son suficientemente concretos para cotizar.

Al terminar descubres que ventas e inventario tienen APIs estables pero los datos de personal están en hojas inconsistentes. Ahora puedes dividir implementación: core dashboard fixed-price con dos APIs conocidas y una fase limitada de limpieza e importación para personal. El cliente obtiene un rango más estrecho y decide si la automatización merece el coste. Un gran riesgo se convierte en dos compromisos controlables.

Este proceso no te hace menos decisivo. Simplemente coloca las decisiones en el orden correcto. Primero se paga el trabajo necesario para saber; después el trabajo necesario para construir. Ese orden suele separar un proyecto sano de una promesa fixed-price basada en historias distintas en la cabeza de cada parte. Cuando el scope es incierto, el primer precio profesional puede ser el precio de la claridad.

• Aclara el resultado de negocio antes de hablar de funcionalidades
• Identifica desconocidos de alto impacto antes de fijar implementación
• Vende discovery cuando resolverlos exige trabajo real
• Usa rangos y caps mientras exista incertidumbre
• Convierte supuestos en condiciones escritas
• Reestima cuando nueva información cambie materialmente el proyecto