Precio fijo vs. tiempo y materiales: ¿cómo se cobra un proyecto de software?

Precio fijo es un contrato de desarrollo de software donde el alcance, el plazo y el costo total se acuerdan antes de arrancar, y el riesgo de que algo cueste más de lo previsto lo asume el squad o la consultora que ejecuta. Tiempo y materiales (T&M) es un contrato donde se paga por las horas reales trabajadas, y ese mismo riesgo de sobrecosto lo asume la empresa que contrata. Ninguno de los dos es superior en abstracto: precio fijo funciona cuando el alcance ya está bien cerrado, y T&M cuando se espera que cambie sobre la marcha. El problema real es que la mayoría de los proyectos de software no encaja del todo en ninguno de los dos extremos.

¿Qué es un contrato a precio fijo en desarrollo de software?

En un contrato a precio fijo, el squad o la consultora cotiza un monto cerrado por un alcance definido de antemano: tantas funcionalidades, tantas pantallas, tantos meses. La empresa sabe exactamente cuánto va a pagar antes de que se escriba la primera línea de código, y ese es su atractivo principal —presupuesto predecible, sin sorpresas—. La contracara es que ese mismo cierre absorbe el riesgo de estimación: si algo toma más tiempo del calculado, quien ejecuta el trabajo pierde margen, no la empresa.

Este modelo funciona bien cuando el alcance está genuinamente cerrado antes de arrancar —un rediseño acotado, una migración con especificación clara, un MVP con funcionalidades ya definidas—. Se rompe apenas aparece un pedido de cambio a mitad de camino, porque cualquier ajuste al alcance original implica renegociar el contrato entero, no solo sumar una tarea suelta.

¿Qué es un contrato de tiempo y materiales (T&M) en desarrollo de software?

En un contrato de tiempo y materiales, la empresa paga por las horas reales que el equipo dedica al proyecto, más los recursos que use en el camino. No hay un monto total fijado de antemano: el costo final depende de cuánto trabajo termine llevando el proyecto. A cambio de esa incertidumbre, la empresa gana la flexibilidad de ajustar prioridades, sumar funcionalidades o cambiar de dirección sin tener que renegociar un contrato cerrado cada vez que algo cambia.

El riesgo se invierte respecto al precio fijo: acá lo asume la empresa, no el squad. Si el alcance crece sin que nadie lo controle, el costo crece con él —y a diferencia del precio fijo, no hay un techo que fuerce una conversación explícita antes de que eso pase—. T&M funciona bien cuando el proyecto es evolutivo por naturaleza (un producto que itera según feedback real) y mal cuando la empresa no tiene la disciplina de monitorear el avance semana a semana.

¿Por qué la mayoría de los proyectos de software no encaja en ninguno de los dos modelos puros?

Los dos modelos parten del mismo supuesto: que el alcance se puede fijar con precisión al principio (precio fijo) o que la empresa puede monitorear cada cambio en tiempo real (T&M). Los datos de la industria dicen que ninguno de los dos supuestos se cumple con la frecuencia que haría falta. Según el Pulse of the Profession 2018 del Project Management Institute (PMI) —una encuesta a 5.402 organizaciones—, el 52% de los proyectos completados en los 12 meses previos había tenido scope creep, alcance que crece sin pasar por un proceso formal de aprobación, frente al 43% que la misma encuesta medía cinco años antes. Las tres causas más citadas de que un proyecto no cumpla su objetivo fueron un cambio en las prioridades del negocio (39%), un cambio en los objetivos del proyecto (37%) y una recolección incorrecta de requisitos al inicio (35%).

El costo de no resolver esto bien no es menor: los grandes proyectos de TI sobrecostean en promedio un 45%, según el estudio conjunto de McKinsey & Company y la Universidad de Oxford sobre 5.400 proyectos. Con un alcance que se mueve en más de la mitad de los proyectos reales, un contrato a precio fijo termina en una negociación de cambio de contrato tras otra, y uno de tiempo y materiales termina en una factura que crece sin que nadie haya decidido explícitamente que debía crecer.

¿Importa el modelo de cobro si el proyecto de todos modos no cumple los objetivos?

Menos de lo que parece. El Standish Group, que mantiene la base de datos más grande sobre resultados de proyectos de TI, encontró en su CHAOS Report 2020 que solo el 31% de los proyectos se completa dentro de alcance, tiempo y presupuesto; el 50% queda "desafiado" —con sobrecostos o recortes de alcance—, y el 19% se cancela directamente. Esa distribución no depende de si el contrato original era precio fijo o T&M: depende de si el alcance quedó bien definido desde el arranque, y de si los cambios, cuando aparecen, se gestionan como una decisión explícita o se cuelan sin que nadie los mida.

¿Existe un modelo intermedio entre precio fijo y tiempo y materiales?

En la práctica, cada vez más squads y agencias de desarrollo cobran por milestone: en vez de fijar el costo de todo el proyecto de una vez, o dejarlo abierto por hora, se define un alcance y un costo acotado para el próximo tramo de trabajo —dos, cuatro semanas—, se ejecuta, se entrega, y recién ahí se acuerda el siguiente. Cada milestone funciona como un mini contrato a precio fijo con un alcance chico y verificable, en vez de comprometer de entrada el proyecto completo.

La diferencia con un precio fijo tradicional es que el compromiso cerrado dura solo lo que dura ese tramo: si el alcance necesita ajustarse, se ajusta en el próximo milestone, con su propio costo, en vez de forzar una renegociación de todo el contrato o dejar que el cambio se cuele sin control.

Cómo lo resuelve Zenit: pago por milestone, no precio fijo puro ni T&M abierto

En Zenit, cada milestone arranca con un criterio de aceptación firmado por la empresa y el squad antes de que se escriba la primera línea de código: qué incluye ese hito, qué queda afuera, y qué evidencia demuestra que está terminado. Ese acuerdo cumple la función que el precio fijo tradicional no logra sin romperse ante el primer cambio, y la que el T&M abierto nunca tuvo: si algo nuevo aparece a mitad de un milestone, no se suma por goteo —se convierte en una decisión explícita sobre si entra en el milestone actual, con su costo y plazo ajustados, o en el siguiente—.

Esa definición temprana del alcance —la misma que, según los datos de PMI citados arriba, es lo que más reduce el riesgo de que un proyecto se salga de control— es también el trabajo que hace Kaizen antes de armar el match: en vez de partir de un formulario, escucha las reuniones del equipo y arma un brief con alcance, milestones y decisiones ya documentadas antes de que el squad arranque a trabajar.

La pregunta que de verdad importa no es "precio fijo o tiempo y materiales". Es qué pasa el día que el alcance necesita cambiar —porque en la mayoría de los proyectos reales, según los datos citados arriba, ese día llega—: si esa conversación queda documentada y acotada milestone a milestone, o si se convierte en una renegociación de contrato completo o en una factura que crece sin que nadie la vea venir.