Clutch Developer
ES
Book a call

Precio fijo vs tiempo y materiales: cuál contrato te protege realmente

Uno de estos transfiere riesgo a tu proveedor. El otro te lo transfiere a ti. Ninguno es generoso.

Adquisiciones lo trata como una preferencia comercial. No lo es. Es una decisión sobre quién absorbe el costo de equivocarse, y elegir el equivocado es cómo los proyectos de software se vuelven adversariales.

Lo que cada modelo realmente dice

Precio fijo dice: nos ponemos de acuerdo sobre qué se construye, y yo llevo el riesgo de estimarlo mal. El proveedor precifica ese riesgo. Estás pagando una prima por certeza — típicamente 20-40% sobre la estimación honesta.

Tiempo y materiales dice: nos ponemos de acuerdo sobre una dirección, y tú llevas el riesgo de que tarde más. Pagas solo por trabajo hecho. También pagas por cada hora gastada yendo por el camino equivocado.

Ninguno es generoso. Ambos son racionales. El fallo es elegir el que no coincide con cuán bien entiendes el trabajo.

Cuándo precio fijo es correcto

  • El alcance es genuinamente conocible — un rediseño de un conjunto de pantallas definidas, una migración con una fuente y destino conocidos, una integración específica.
  • Tienes un plazo externo duro (un hito de financiación, una feria, una fecha regulatoria) y necesitas que el plazo sea el problema de otro.
  • No puedes tolerar varianza de presupuesto, y aceptarás que el alcance se reduzca para proteger el número.
  • La relación es nueva y quieres un primer proyecto limitado antes de comprometerte a más.

La cláusula que lo decide todo: qué pasa cuando el alcance cambia. Si la respuesta es "lo discutiremos," tienes un contrato de tiempo y materiales con pasos de más y peor humor.

Cuándo tiempo y materiales es correcto

  • Aún estás descubriendo qué debería ser el producto. Fijar un precio en lo desconocido solo fija el alcance, y será el alcance equivocado.
  • Tienes a alguien técnico de tu lado que pueda juzgar si las horas son reales.
  • El trabajo es continuo — un roadmap en lugar de un proyecto.
  • Las prioridades cambiarán, y prefieres redirigir que renegociar.

Los modos de fallo

Precio fijo falla al hacer cada conversación una negociación. El margen del proveedor ahora depende de hacer menos, así que una buena idea en la tercera semana se convierte en una solicitud de cambio. La calidad silenciosamente se convierte en la válvula de escape, porque es la única cosa que nadie incluyó en los detalles. Obtienes exactamente lo que se escribió, que rara vez es lo que necesitabas.

Tiempo y materiales falla al eliminar el plazo. Sin un final fijo, no hay presión sobre el alcance, y "ya que estamos" se convierte en la frase más cara del proyecto. Seis meses después tienes código excelente y ningún producto — por qué las agencias tardan seis meses.

El modelo que realmente recomendaría

Una ventana de precio fijo y duración fija con contenido negociable. Dos semanas, un precio, acordado de antemano. Lo que entra en esas dos semanas se decide conjuntamente y puede cambiar hasta el momento en que comienza el trabajo.

Esto invierte el equilibrio usual. El proveedor lleva el riesgo de entrega (la fecha y el precio son fijos), y tú mantienes la flexibilidad (qué se construye puede cambiar). Nadie tiene incentivo para discutir sobre el alcance, porque el alcance no es lo que se está protegiendo — la ventana es.

Solo funciona si la ventana es corta. Un contrato de doce meses fijo con alcance flexible no es esto; es un retainer con una buena historia.

Qué realmente pasa cuando el alcance cambia

Lo hará. La pregunta es qué hace el contrato que hagan las personas al respecto.

Bajo precio fijo, una solicitud de cambio es una negociación con un margen asociado. El proveedor tiene que precificarla, tú tienes que aprobarla, y ambos estáis ahora ligeramente en lados opuestos. La mejor estrategia para el proveedor es interpretar el alcance original estrechamente; la mejor estrategia para ti es interpretarlo ampliamente. Ninguno de los dos se comporta mal y la relación aún se degrada.

Bajo tiempo y materiales, un cambio es solo el trabajo de la próxima semana. Sin fricción — que es el problema. Nada obliga a nadie a preguntar si el cambio vale su costo, porque el costo nunca aparece como una decisión. Aparece tres meses después como un burn rate.

Bajo una ventana fija, un cambio cuesta algo visible e inmediato: desplaza algo más en las mismas dos semanas. Esa es la versión más saludable, porque la compensación es explícita y la hace la persona que debería hacerla — tú.

El híbrido que la mayoría realmente quiere

En la práctica la forma que funciona para la mayoría del trabajo de producto es:

  1. Una discovery pequeña y pagada, precio fijo. Unos pocos días a una semana. Termina en un alcance que ambos creen, no en una presentación. Si el proveedor no quiere hacerlo, está planeando hacer el descubrimiento en tu presupuesto.
  2. Ventanas de entrega de precio fijo y duración fija. Dos o tres semanas cada una, precificadas de antemano, contenido acordado al inicio de cada una. Lanza algo real al final de cada una.
  3. Tiempo y materiales para la cola. Soporte, cambios pequeños, el largo período tranquilo después del lanzamiento. Nadie debería fijar un precio en trabajo que aún no ha sido imaginado.

El paso de descubrimiento es lo que hace los precios fijos honestos. Sin él, un proveedor fijando un precio está adivinando, y la adivinanza incluye un margen para su propia incertidumbre que estás pagando.

Tarifa versus costo total

Un proveedor de 400 €/día que necesita dos semanas de ramp-up cuesta más que uno de 900 €/día que empieza a producir el martes. Ésta es la falsa economía más común en procuración de software, y sobrevive porque la tarifa diaria es el número en la hoja de cálculo y el ramp-up no.

Cuando compares proveedores, pregunta a cada uno: ¿cuándo veo la primera cosa que funciona? Esa sola fecha codifica ramp-up, peso del proceso, realidad del personal y confianza. Es más indicador del costo total que la tarifa.

Cláusulas que valen más que la tarifa

Sea cual sea el modelo que elijas, estas deciden si funciona:

  • Asignación de IP al pago, no a la finalización. Si el proyecto se detiene temprano, deberías poseer lo que pagaste.
  • Acceso al código fuente desde el día uno. No una entrega al final. Si no puedes ver el repositorio, no puedes verificar nada.
  • Una persona nombrada. Los contratos son con empresas; el trabajo lo hacen las personas. Nómbralas, y di qué pasa si cambian.
  • Una salida que no sea punitiva. Un proveedor confiado en su trabajo no necesita una cláusula de bloqueo.
  • Definición de listo. Escrita, de antemano, en términos que un no-ingeniero pueda verificar.

Si haces bien esos cinco, el modelo de precios importa mucho menos de lo que nadie en la sala cree actualmente.