Qué definir antes de pedir cotizaciones de software

Una empresa pide tres cotizaciones para el mismo sistema y recibe 400 mil, 900 mil y 2.4 millones de pesos. La reacción normal es pensar que alguien está inflando el precio. Casi nunca es eso.

Lo que pasa es que los tres entendieron proyectos distintos, porque lo que recibieron admitía tres lecturas. La dispersión en las cotizaciones no mide a los proveedores: mide qué tan definido estaba el proyecto.

Esta guía explica qué escribir antes de pedir cotizaciones para que sean comparables — y qué conviene no escribir.

Requerimiento no es lo mismo que solución

El error más común es pedir la solución en vez del problema:

"Necesitamos una app móvil con login por huella y un dashboard con gráficas."

Eso ya decidió la plataforma, la autenticación y la interfaz, antes de saber si son la mejor respuesta. Lo mismo dicho como requerimiento:

"Nuestros 40 técnicos en campo reportan trabajo terminado por WhatsApp. Necesitamos que quede registrado con evidencia y que facturación lo vea el mismo día, sin recapturar."

La segunda versión permite que el proveedor proponga —quizá una PWA sale la mitad y funciona igual, algo que desarrollamos en PWA vs app nativa— y, sobre todo, permite comparar propuestas: todas atacan el mismo problema.

Regla práctica: describe el qué y el por qué; deja el cómo al proveedor. Si ya decidiste el cómo, dilo aparte como restricción, no mezclado con la necesidad.

Lo que sí tiene que estar en el documento

No hace falta un documento de cincuenta páginas. Hacen falta seis apartados, y caben en cinco o seis cuartillas.

1. El problema y qué cambia si se resuelve

Dos párrafos: cómo se hace hoy, qué duele, qué pasa si no se hace nada. Esto orienta todas las decisiones técnicas que vienen después, y es lo que más se omite.

2. Quién lo va a usar y para qué

Cuántos usuarios, de qué tipo, en qué contexto. No es lo mismo veinte personas de oficina que doscientos operadores en planta con guantes y sin señal. Un buen atajo es listar los recorridos principales: "el supervisor abre el turno, asigna, revisa avance, cierra".

3. Alcance mínimo, separado de lo deseable

Dos listas explícitas: lo que debe estar para que el sistema sirva y lo que puede esperar. Sin esa separación, cada proveedor traza la raya donde le conviene y por eso las cotizaciones se van a tres veces.

Un buen filtro para la primera lista: si esto no está, ¿el sistema se puede usar? Si la respuesta es sí, va en la segunda.

4. Con qué se tiene que conectar

Aquí se esconde casi toda la diferencia de precio. Por cada sistema con el que deba hablar: cuál es, si tiene API, quién lo administra y qué datos van en cada dirección. Un sistema aislado y el mismo sistema integrado a un ERP sin API se parecen en pantallas y se separan en meses de trabajo.

5. Los requisitos que no se ven

Los que nadie escribe y todos asumen distinto:

• Volumen: cuántos registros al día, cuántos usuarios simultáneos, cuánto histórico.
• Disponibilidad: ¿aguanta estar caído una hora un martes, o no?
• Dispositivos y conectividad: ¿tiene que funcionar sin señal?
• Cumplimiento: datos personales, CFDI, requisitos del sector.
• Idiomas y zonas horarias, si aplica.

6. Restricciones reales

Fecha límite y por qué existe, rango de presupuesto, tecnología que ya usan y no van a cambiar, quién estará disponible del lado del cliente.

Sobre compartir el presupuesto

Mucha gente lo oculta creyendo que así obtiene mejor precio. Lo que obtiene son propuestas que no puede comparar.

El desarrollo a la medida no tiene un precio de lista: tiene un alcance que se ajusta al presupuesto. Un rango —"entre 800 mil y 1.2 millones"— permite que cada proveedor proponga qué cabe ahí. Sin rango, uno cotiza el Ferrari, otro el compacto, y la comparación no significa nada.

Si el rango honesto es "no sé", entonces la primera conversación no es una cotización: es un discovery.

Cómo hacer las propuestas comparables

Tres cosas ayudan más que cualquier formato:

Pide el mismo desglose a todos. Por fases o por módulos, con horas o semanas estimadas. Un número global no se puede comparar ni negociar.

Pide explícitamente los supuestos. "¿Qué estás asumiendo que no está en el documento?" Las respuestas revelan dónde cada proveedor puso la raya, y suelen explicar por completo la diferencia de precio.

Pregunta qué pasa cuando cambie el alcance. Va a cambiar. Cómo se maneja ese cambio —y a qué costo— importa más que el número inicial.

Con eso ya evaluaste el proyecto. Evaluar al proveedor es otra tarea, y la cubrimos en qué buscar en un proveedor de software.

Lo que no conviene hacer

• Especificar pantallas. Los mockups en el documento inicial anclan la solución y esconden el problema. Guárdalos para el diseño.
• Pedir "todo" para tener margen. Infla las cotizaciones y diluye lo importante. Lo que sí funciona es marcar prioridades.
• Copiar un requerimiento de otra empresa. Se nota, y arrastra decisiones que no son tuyas.
• Mandarlo sin haberlo hablado internamente. Si operaciones y sistemas no coinciden en qué se necesita, el proveedor no lo va a resolver por ustedes.

Cómo lo hacemos en Newsoft

En la práctica, buena parte de las empresas que nos escriben no llegan con este documento — llegan con un problema. Por eso el discovery es gratuito y de dos semanas: sale con el alcance mínimo definido, las integraciones identificadas y una estimación por fases.

Ese entregable es del cliente, sin compromiso. Si con él prefiere pedir otras cotizaciones, tiene todo lo que necesita para que sean comparables. Nos parece mejor negocio que arrancar un proyecto mal definido: casi siempre termina en un sistema que nadie usa.

Si quieres ordenar tu proyecto antes de pedir números, platícanos el caso.

Conclusión

Cuando tres cotizaciones del mismo proyecto salen con 3x de diferencia, el problema casi nunca son los proveedores: es que el documento admitía tres proyectos distintos.

Antes de pedir números, escribe seis apartados —problema, usuarios, alcance mínimo vs. deseable, integraciones, requisitos no funcionales y restricciones— y comparte un rango de presupuesto. Son unas cuantas cuartillas y unos días de trabajo interno, y son la diferencia entre comparar propuestas y adivinar.