Qué es la declaración de trabajo (statement of work) y cómo no firmar una mala
La guía del founder no técnico para el documento que define qué estás pagando de verdad para que un proveedor construya, y quién carga con la cuenta cuando la realidad se aleja del plan.
Una founder que conocemos firmó una declaración de trabajo para un portal de clientes. Doce páginas, un logo en la esquina, un calendario de pagos que parecía justo. Le echó un vistazo, firmó y transfirió el anticipo. Cuatro meses después el portal funcionaba, más o menos, y las facturas habían crecido un 60 por ciento. Cada cargo extra venía de una línea que ella leyó como promesa y el proveedor escribió como ejemplo. “Gestión de usuarios” resultó ser un admin, no la jerarquía de roles que había imaginado. “Reportes” era un único export, no el dashboard de su cabeza. Nada de esto fue fraude. Estaba todo ahí, en el documento que no sabía leer.
Una declaración de trabajo, o statement of work (SOW), es el documento que define exactamente qué va a construir un proveedor para ti, cómo sabrás que está terminado, cuánto cuesta y quién es responsable de qué. Es la parte de un contrato de software donde vive el trabajo de verdad. Si está bien hecho, es la mejor protección que tiene un founder no técnico contra el scope creep, las facturas sorpresa y una entrega que técnicamente salió pero no hace lo que estabas comprando. Si está mal, renunciaste a tu ventaja antes de la primera línea de código.
La mayoría de los founders trata el SOW como papeleo que despachar de camino a empezar. Es al revés. Es la negociación. Para cuando estás discutiendo una factura, el SOW ya decidió quién gana.
Qué es, en realidad, una declaración de trabajo
Quita los templates de en medio y una declaración de trabajo responde a cuatro preguntas. ¿Qué exactamente estás construyendo? ¿Cómo van a acordar ambas partes que está terminado? ¿Qué pasa cuando el plan cambia? ¿Y quién se queda con qué al final? Un documento que responde esas cuatro con claridad es un buen SOW, tenga seis páginas o treinta. Un documento vago en cualquiera de ellas es un pasivo, por profesional que parezca.
El Project Management Institute lleva décadas escribiendo sobre por qué fracasan los proyectos de servicio, y el patrón es aburrido: las dos partes tenían imágenes distintas de “terminado” y nunca las pusieron por escrito. El SOW existe para forzar esa conversación antes de que el dinero se mueva. No está ahí para tener contentos a los abogados. Está ahí para que, en el tercer mes, cuando digas que la búsqueda está rota y el proveedor diga que la búsqueda nunca estuvo en el alcance, exista un documento que lo resuelva en lugar de la relación.
Por eso el SOW importa más para ti que para el proveedor. El proveedor escribe estos documentos todo el tiempo. Sabe dónde están los puntos débiles. Tú estás leyendo el primero o el segundo bajo presión de tiempo, traduciendo intención de negocio en entregables técnicos en un idioma que no dominas del todo. La asimetría es el problema entero. Cerrarla es el objetivo de este texto.
Qué va dentro de una declaración de trabajo
Un SOW de software que te protege tiene más o menos siete partes. No necesitas redactarlas. Necesitas saber para qué sirve cada una, para notar cuándo falta o está hueca.
Objetivos y contexto. Unas frases sobre para qué sirve el proyecto y cómo se ve el éxito en términos de negocio. Suena a relleno y no lo es. Cuando una disputa llega al “bueno, técnicamente el spec decía”, la sección de objetivos es lo que una persona razonable lee para decidir qué quisiste decir de verdad. Un SOW sin propósito declarado es uno que el proveedor puede interpretar enteramente a su favor.
Alcance del trabajo. El corazón: las funcionalidades, pantallas y comportamientos concretos que se van a construir. Aquí es donde la vaguedad cuesta dinero. “Gestión de usuarios” no es alcance. “Los admins pueden crear, editar, desactivar y asignar uno de tres roles a usuarios; los usuarios reciben una invitación por email y definen su propia contraseña” es alcance. Cada sustantivo del resumen debería abrirse en verbos contra los que un desarrollador pudiera construir. Si no se abre, es un espacio reservado para una pelea.
Entregables. Las cosas concretas que recibes: la aplicación corriendo, el código fuente, la documentación, los archivos de diseño, el deploy en tus cuentas. Nómbralos como objetos, no como actividades. “Desarrollo de una app móvil” es una actividad. “Una app iOS y Android publicada en tus cuentas de App Store y Play Store, más el código fuente en un repositorio que es tuyo” es un entregable. La diferencia es si tienes algo en la mano al final.
Cronograma e hitos. Fases con fechas, y de preferencia pago atado a hitos aceptados, no al calendario. Un hito que pagas se entregue o no no es un hito. Es una fecha de vencimiento sobre tu dinero.
Criterios de aceptación. Cómo acuerdan ambas partes que un entregable está terminado. Es la cláusula que los founders se saltan y luego desearían no haberlo hecho. Sin ella, “terminado” significa “el proveedor dice que está terminado”. Con ella, “terminado” significa que el flujo de checkout procesa un pago de prueba real, envía el recibo y actualiza el estado del pedido, y tienes una ventana definida para probarlo. Si tu SOW calla aquí, eso es lo primero que hay que corregir antes de firmar.
Precio y condiciones de pago. El número, qué cubre y, sobre todo, qué no cubre. Un precio cerrado con un alcance nebuloso es una trampa para ti. Tiempo y materiales sin tope es una trampa en la dirección opuesta. Qué modelo estás usando cambia todo en cómo debe leerse el resto del SOW, lo que vale entender antes de elegir; el trade-off entre precio cerrado y tiempo y materiales vive en la cláusula de precio.
Gestión de cambios. El proceso para lidiar con cualquier cosa fuera del alcance original. Volveremos a esta, porque es la cláusula que en silencio decide la mayoría de tus facturas futuras.
Quién prepara la declaración de trabajo
En casi todo proyecto de software, el proveedor escribe el SOW. Es normal. Tiene los templates, conoce el detalle técnico y es quien se compromete a entregar. El error no es dejar que lo redacte. El error es tratar su versión como documento terminado en lugar de posición de apertura.
Un SOW escrito por el proveedor está escrito para ser entregable por el proveedor, no para ser seguro para ti. No es villanía; es incentivo. Su versión tenderá a mantener el alcance suelto para no quedar encajonado, los criterios de aceptación blandos para que “terminado” sea decisión suya, y el proceso de cambio favorable para que los añadidos sean fáciles de facturar. Un buen proveedor no peleará cuando aprietes eso. Un proveedor que pelea para no hacer objetivo el “terminado” te está diciendo algo, y deberías escucharlo antes de firmar, no después.
Así que la respuesta honesta a “quién prepara el SOW” es: ellos redactan, tú eres dueño. No se espera que escribas alcance técnico desde cero. Se espera que leas la versión del proveedor como la negociación que es, preguntes qué significa en la práctica cada línea vaga e insistas en que las respuestas entren en el documento. El founder que pregunta “¿qué incluye exactamente ‘reportes’, y podemos listarlo?” ya evitó la factura sorpresa más común que hay. Es el mismo músculo que usarías en el propio contrato de desarrollo de software, aplicado a la parte que de verdad describe el trabajo.
Declaración de trabajo vs contrato, y vs alcance del proyecto
Tres términos se enredan aquí, y la confusión cuesta dinero real a los founders.
El contrato (a menudo un Master Services Agreement, o MSA) es el marco legal: responsabilidad, confidencialidad, propiedad intelectual, garantías, cómo se resuelven las disputas, cómo cada parte puede salir. Son las reglas de la relación. Rara vez menciona tus funcionalidades específicas.
La declaración de trabajo (SOW) es el proyecto. Vive bajo el contrato y describe qué se construye, cuándo, por cuánto. Un MSA puede tener varios SOWs apilados debajo, uno por proyecto o fase. Cuando alguien dice “firma el SOW”, quiere decir comprometerte con esta pieza específica de trabajo bajo términos que el MSA ya fijó.
El alcance del proyecto es el hermano cercano que confunde: en conversación, “alcance del trabajo” y “declaración de trabajo” se usan casi como sinónimos, y la mayor parte del tiempo no importa hasta que importa. Cuando alguien dice “eso está fuera del alcance”, apunta a la sección de alcance del SOW para justificar un cargo. Que es exactamente por qué esa sección tiene que ser lo bastante específica para resolver la cuestión.
En corto: el contrato gobierna la relación, el SOW gobierna el proyecto, y el alcance es la parte del SOW por la que todos van a discutir.
La cláusula que decide tus facturas futuras
Aquí está la parte de una declaración de trabajo que la mayoría de los founders subestima, y es la que determina lo que vas a pagar de verdad: la gestión de cambios.
Ningún proyecto de software termina como lo describió su SOW. Aprenderás algo de los usuarios, una prioridad cambiará, una funcionalidad resultará más difícil o más fácil de lo que cualquiera supuso. Eso no es fracaso. Es construir. La pregunta que el SOW tiene que responder es qué pasa cuando ocurre, porque “ya lo vemos” se resuelve a favor del proveedor todas las veces.
Una cláusula de cambio sana dice: cualquier cosa fuera del alcance acordado pasa por una solicitud de cambio escrita, que declara el trabajo, el costo y el impacto en el cronograma, y nada se construye hasta que lo apruebas por escrito. Esa sola frase es la diferencia entre un proveedor que te avisa que un cambio cuesta 4.000 dólares antes de hacerlo y uno que lo hace y te avisa después. La mecánica de ese proceso vale conocerla de memoria, porque la usarás una y otra vez; una solicitud de cambio de verdad es lo que mantiene honesto un proyecto una vez que empieza a moverse.
La ausencia de esa cláusula es cómo el scope creep se vuelve crisis de presupuesto. No por una gran traición. Por cincuenta pequeños “claro, se puede agregar” que nadie coteó, hasta que el total está un 60 por ciento arriba y ninguna conversación aislada fue donde se descarriló. El SOW que hace de cada añadido una decisión pequeña, explícita y aprobada de antemano es el SOW que te mantiene solvente.
Cómo leer un SOW antes de firmarlo
No necesitas volverte gerente de proyectos. Necesitas cuatro preguntas, y la disciplina de no firmar hasta que cada una tenga una respuesta de verdad en el documento.
Primera: ¿qué exactamente se entrega? Lee la sección de alcance y, para cada funcionalidad, pregunta si un desarrollador que nunca habló contigo podría construir la cosa correcta solo con las palabras. Si “gestión de usuarios” o “reportes” o “notificaciones” aparece sin abrirse, eso no es alcance, es un espacio reservado. Haz que lo listen.
Segunda: ¿cómo sabemos que está terminado? Encuentra los criterios de aceptación. Si “terminado” se define como el proveedor declarándolo terminado, no tienes criterios de aceptación. Pide condiciones observables, comprobables, y una ventana para probarlas.
Tercera: ¿qué pasa cuando cambia? Encuentra la cláusula de cambio. Si los añadidos pueden construirse y facturarse sin tu firma por escrito, el presupuesto del SOW es ficción. Arregla la cláusula, no el número.
Cuarta: ¿quién se queda con qué al final? Confirma por escrito que eres dueño del código fuente, los repositorios, las cuentas de deploy y los archivos de diseño cuando el trabajo esté pagado. Una entrega que no puedes llevar a otro desarrollador no es un activo tuyo. Es una suscripción al proveedor que la construyó, y a eso no aceptaste.
Cuatro preguntas. Diez minutos si el SOW es honesto, y una conversación incómoda pero barata si no lo es. Cualquiera de los dos desenlaces vale mucho más que el anticipo que estás por transferir. El SOW es donde estás comprando software o alquilando una relación de la que costará salir. Léelo como si el dinero dependiera de ello, porque depende.
Preguntas frecuentes
¿Qué es una declaración de trabajo en términos simples?
Es el documento que detalla exactamente qué va a construir un proveedor para ti, cómo sabrás que está terminado, cuánto cuesta y quién se queda con qué al final. Va bajo el contrato principal y describe el trabajo real, así que si alguna vez hay una disputa sobre lo prometido, el SOW es lo que la resuelve.
¿Quién escribe la declaración de trabajo, el cliente o el proveedor?
Casi siempre el proveedor, porque tiene los templates y el detalle técnico. Pero su versión está escrita para ser segura para el proveedor, no para ti. Trátala como posición de apertura: lee cada línea vaga, pregunta qué significa en la práctica e insiste en que las respuestas entren en el documento antes de firmar.
¿Cuál es la diferencia entre declaración de trabajo y contrato?
El contrato, a menudo un Master Services Agreement, fija las reglas legales de la relación: responsabilidad, propiedad intelectual, confidencialidad, resolución de disputas. La declaración de trabajo va debajo y define alcance, plazo y precio de un proyecto específico. Un contrato puede cubrir varios SOWs.
¿Una declaración de trabajo es legalmente vinculante?
Sí, una vez que ambas partes la firman, normalmente como anexo de un contrato más amplio. Precisamente por eso los detalles importan tanto: un documento vinculante con alcance vago te ata a la interpretación del proveedor, no a la tuya.
¿Cuál es la diferencia entre alcance del proyecto y declaración de trabajo?
En la práctica el mercado los usa casi como sinónimos. Lo que importa es la sección de alcance dentro del SOW, que lista qué se está construyendo. Cuando alguien dice “eso está fuera del alcance”, apunta a esa sección, y por eso tiene que ser lo bastante específica para resolver la cuestión.
¿Qué tan detallada debe ser una declaración de trabajo?
Lo bastante detallada para que un desarrollador que nunca habló contigo pueda construir la cosa correcta solo con las palabras, y para que “terminado” sea una condición observable, no la opinión del proveedor. El tamaño varía; un SOW ajustado de seis páginas le gana a uno inflado de treinta. La precisión en alcance, aceptación y cambio es lo que cuenta.