SoW

Un Statement of Work es el documento que convierte un acuerdo verbal en contrato. Lista el entregable en términos concretos («feature X en producción cumpliendo criterios de aceptación A, B, C»), el precio, el plazo y las condiciones de aceptación.

En derecho austríaco y alemán el instrumento equivalente es el Werkvertrag, más fuerte que el SoW en inglés: el proveedor está legalmente obligado a entregar la obra, no solo a aportar esfuerzo, y el cliente puede retener el pago hasta que la obra se acepte. Un contrato de Time & Material bajo el mismo marco es un Dienstvertrag, que solo obliga a esfuerzo. Los engagements a precio fijo de Wavect son contratos Werkvertrag.

Ejemplo de por qué los criterios de aceptación cargan con todo el contrato: un SoW que dice «construir la feature de reporting, debe funcionar bien» es inaplicable, porque «funcionar bien» es una opinión. Un SoW que dice «el endpoint /reports devuelve las cifras mensuales para el rango R en menos de 200ms bajo carga L, coincidiendo con los valores del spec S» es comprobable, y «hecho» deja de ser una negociación. El error de founder más común es firmar un SoW redactado de forma vaga para ahorrar tiempo al inicio, y luego pasar seis meses discutiendo si una feature a medio funcionar cuenta como entregada. Un proveedor que se resiste a escribir criterios de aceptación precisos está protegiendo su derecho a tener esa discusión más tarde.

El SoW es también el documento que evita el scope creep: lo que no esté en él queda fuera por definición y se gestiona con un change request. Ojo a las capas: un MSA (Master Services Agreement) cubre el marco legal (IP, responsabilidad, jurisdicción) una vez, y muchos SoWs viven bajo él a lo largo del tiempo. El trade-off honesto es que un SoW apretado cuesta trabajo real de escribir y se siente lento al principio, que es exactamente el trabajo que una fase de discovery pagada existe para hacer. Relacionado: Fractional CTO Austria explica el modelo Werkvertrag en la práctica.

Cuándo importa esto en un proyecto de software. En el momento en que cambia el dinero de manos. El SoW es donde «qué estás comprando» deja de ser una conversación y se vuelve exigible, así que es el único documento que decide si una disputa posterior se resuelve por el contrato o por quién grita más fuerte.

Qué suelen hacer mal los founders. Firman un SoW vagamente redactado para empezar más rápido, y luego discuten meses si una funcionalidad a medias cuenta como entregada. Los criterios de aceptación cargan con todo el contrato; «debe funcionar bien» es una opinión, no un entregable.

Cómo lo maneja Wavect. Escribimos criterios de aceptación lo bastante precisos para ser testables antes de que nadie firme, y corremos primero una discovery pagada para que el alcance sea real. Nuestra guía para elegir una agencia de software y la guía de precio fijo vs time and materials recorren la decisión del contrato en lenguaje claro.