Esta guía cubre los conceptos clave detrás de Statements of Work profesionales para proyectos de software. Ya sea que estés escribiendo tu primer SOW o refinando tu proceso, estas prácticas te ayudan a entregar propuestas claras y defendibles que protegen tanto a ti como a tu cliente.
Qué hace un buen SOW
Un SOW sólido elimina la ambigüedad. Cada sección debe responder una pregunta que podría convertirse en una disputa después. El objetivo es que ambas partes lean el mismo documento y tengan las mismas expectativas.
10 secciones clave
- Resumen del proyecto — qué es el proyecto, quiénes son los stakeholders y el problema de negocio que se resuelve
- Alcance del trabajo — requerimientos detallados con criterios de aceptación para cada entregable
- Fuera de alcance — exclusiones explícitas para prevenir scope creep
- Cronograma e hitos — fases, fechas, dependencias y qué dispara la siguiente fase
- Precios y cronograma de pagos — costo total, estructura de tarifas, triggers de pago y términos de pago tardío
- Equipo y roles — quién trabaja en qué, niveles de seniority y disponibilidad
- Criterios de aceptación — cómo se evalúa y aprueba cada entregable
- Gestión de cambios — cómo se solicitan, evalúan y presupuestan los cambios de alcance
- PI y propiedad del código — quién es dueño de los entregables después de que termina el proyecto
- Compromisos de servicio y SLAs — tiempos de respuesta, uptime, ventanas de corrección de errores y términos de soporte
Errores comunes
| Error | Consecuencia |
|---|
| Requerimientos vagos (“construir la app”) | El cliente espera más de lo que dimensionaste |
| Sin sección de fuera de alcance | Cada solicitud de funcionalidad se convierte en tu responsabilidad |
| Criterios de aceptación faltantes | ”Hecho” se vuelve una cuestión de opinión |
| Sin proceso de gestión de cambios | El scope creep no se presupuesta ni se rastrea |
| Precios sin base de tarifa | El cliente no puede verificar cómo se calcularon los costos |
| Propiedad intelectual poco clara | Disputas sobre propiedad del código después de la entrega |
| Sin cláusula de terminación | Ninguna de las partes tiene una salida limpia |
Antes de enviar cualquier SOW, léelo desde la perspectiva del cliente. Si alguna sección puede interpretarse de dos formas, reescríbela.
Criterios de aceptación
Los criterios de aceptación definen cuándo un requerimiento se considera completo. Sin ellos, “hecho” es subjetivo.
El formato más efectivo para criterios de aceptación toma prestado del desarrollo orientado a comportamiento:
Given [una precondición o contexto]
When [ocurre una acción]
Then [el resultado esperado]
Ejemplos
Requerimiento: Autenticación de usuarios
Given a registered user with valid credentials
When they submit the login form
Then they are redirected to the dashboard and a session token is set
Given a user with invalid credentials
When they submit the login form
Then an error message is displayed and no session is created
Given a logged-in user
When they click "Log out"
Then their session is invalidated and they are redirected to the login page
Given a customer with items in their cart
When they complete the Stripe checkout flow
Then a payment intent is created, the order status changes to "paid",
and a confirmation email is sent within 60 seconds
Given a failed payment (declined card)
When the Stripe webhook fires with status "failed"
Then the order remains in "pending" status and the customer sees a retry option
Consejos para escribir criterios de aceptación
- Escríbelos antes de que comience el desarrollo, no después
- Cubre el camino exitoso y al menos un escenario de fallo
- Incluye resultados medibles (tiempos de respuesta, códigos de estado, envío de emails)
- Evita detalles de implementación — describe qué, no cómo
- Cada criterio debe ser independientemente verificable
Fuera de alcance
La sección de fuera de alcance es tu protección legal más importante. Define lo que el proyecto no incluye.
Por qué importa
Sin una sección explícita de fuera de alcance, los clientes pueden razonablemente esperar funcionalidades que “parecían obvias.” Esto lleva a trabajo no pagado, relaciones tensas y erosión de márgenes.
Cómo escribir exclusiones
Sé específico. En lugar de “funcionalidades adicionales”, lista las cosas exactas que no están incluidas:
| Demasiado vago | Específico y defendible |
|---|
| ”Funcionalidades adicionales" | "Apps móviles nativas (iOS/Android) no están incluidas; este proyecto cubre solo web" |
| "Otras integraciones" | "Integración con Salesforce, HubSpot o cualquier CRM además del especificado en el alcance" |
| "Mejoras futuras" | "Soporte multi-idioma, framework de A/B testing y dashboards de analítica avanzada” |
Supuestos comunes a documentar
Incluye una sección de supuestos — cosas que deben ser ciertas para que el proyecto tenga éxito según lo dimensionado:
- El cliente proporciona credenciales de API para servicios de terceros antes de [fecha]
- El contenido (textos, imágenes, traducciones) es proporcionado por el cliente
- El esquema de base de datos existente no cambia durante el desarrollo
- El entorno de staging es proporcionado por el cliente o provisionado dentro de la primera semana
- El turnaround de revisión y aprobación de código es dentro de 2 días hábiles
Si un supuesto resulta ser falso, se activa el proceso de gestión de cambios.
PI y propiedad del código
Una de las áreas más contenciosas en proyectos de software. Defínela claramente antes de que comience el trabajo.
Tres modelos comunes
Work for hire
El cliente es dueño de todo el código, diseños y entregables una vez realizado el pago. El proveedor no retiene derechos.
All deliverables produced under this agreement are "work for hire."
Upon full payment, the Client owns all intellectual property rights,
including source code, documentation, and designs.
The Provider retains the right to use general knowledge, techniques,
and non-proprietary tools developed during the engagement for future projects.
Modelo de licencia
El proveedor retiene la propiedad y otorga al cliente una licencia perpetua, no exclusiva, para usar, modificar y desplegar el código.
The Provider retains ownership of all deliverables. Upon full payment,
the Client receives a perpetual, irrevocable, non-exclusive license
to use, modify, and deploy the deliverables for their business purposes.
The Client may not resell or sublicense the deliverables without written consent.
Modelo híbrido
La lógica de negocio específica del cliente se transfiere al cliente. Las bibliotecas, frameworks y herramientas reutilizables permanecen con el proveedor.
Custom application code specific to the Client's business is transferred
to the Client upon full payment (work for hire).
Pre-existing libraries, frameworks, components, and tools used by the
Provider remain the Provider's property. The Client receives a perpetual
license to use these components as part of the delivered application.
Definiciones de SLA
Los Acuerdos de Nivel de Servicio definen los compromisos operativos después de la entrega o durante un compromiso en curso.
Métricas clave de SLA
| Métrica | Definición | Ejemplo |
|---|
| Uptime | Porcentaje de tiempo que el sistema está disponible | 99.9% (8.76 horas de downtime/año) |
| Tiempo de respuesta | Tiempo hasta la primera respuesta humana para una solicitud de soporte | 4 horas hábiles para crítico, 24 horas para normal |
| Tiempo de resolución | Tiempo para corregir o proporcionar un workaround | 8 horas para P1, 48 horas para P2, 5 días hábiles para P3 |
| Frecuencia de deploy | Con qué frecuencia se envían actualizaciones | Releases semanales, hotfixes dentro de 24 horas |
| RTO (Recovery Time Objective) | Máximo downtime aceptable después de una falla | 4 horas |
| RPO (Recovery Point Objective) | Máxima pérdida de datos aceptable (tiempo) | 1 hora (backups cada hora) |
Niveles de severidad
| Nivel | Criterios | Ejemplo |
|---|
| P1 — Crítico | Sistema caído, ingresos impactados, sin workaround | El procesamiento de pagos falla para todos los usuarios |
| P2 — Alto | Funcionalidad principal rota, existe workaround | La búsqueda devuelve resultados incorrectos pero los usuarios pueden navegar manualmente |
| P3 — Medio | Funcionalidad menor rota, bajo impacto en usuarios | El botón de exportar no funciona en un navegador |
| P4 — Bajo | Problema cosmético, solicitud de mejora | La alineación está desplazada en una página de configuración |
Estimación con story points
Los story points miden complejidad relativa, no tiempo absoluto. Ayudan a los equipos a estimar esfuerzo de forma consistente entre diferentes tipos de requerimientos.
Escala común
| Puntos | Complejidad | Alcance típico |
|---|
| 1 | Trivial | Cambio de configuración, actualización de texto, bug simple |
| 3 | Pequeño | CRUD estándar, componente UI básico, integración simple |
| 5 | Mediano | Funcionalidad con lógica de negocio, API con validación, flujo multi-paso |
| 8 | Grande | Integración compleja, migración de datos, funcionalidad en tiempo real, sistema multi-rol |
Conversión a horas
La conversión depende de la velocidad del equipo, pero baselines comunes:
| Puntos | Junior | Mid | Senior |
|---|
| 1 | 2-4h | 1-2h | 1h |
| 3 | 8-12h | 4-8h | 3-5h |
| 5 | 16-24h | 10-16h | 6-10h |
| 8 | 32-48h | 20-32h | 12-20h |
Estas son estimaciones, no garantías. Incluye siempre un buffer (15-25%) para incógnitas, revisión de código, testing y despliegue.
Consejos de estimación
- Estima con el equipo, no solo — perspectivas diversas detectan puntos ciegos
- Compara nuevos requerimientos con los recientemente completados (“¿esto es más grande o más pequeño que X?”)
- Si no puedes decidir entre dos valores, elige el mayor
- Cualquier cosa por encima de 8 puntos debería dividirse en requerimientos más pequeños
- Re-estima después del discovery si el brief era vago
Gestión de cambios
La gestión de cambios define cómo se manejan las modificaciones al alcance acordado durante el proyecto.
Proceso estándar
Solicitud de cambio enviada
El cliente describe el cambio — qué quiere agregar, modificar o eliminar.
Evaluación de impacto
El proveedor evalúa el cambio contra el alcance actual: esfuerzo (story points/horas), impacto en cronograma y delta de costo.
Aprobación o rechazo
El proveedor presenta la evaluación. El cliente aprueba, negocia o retira la solicitud.
Enmienda al SOW
Si se aprueba, ambas partes firman una enmienda al SOW documentando el nuevo alcance, cronograma revisado y costo adicional.
El trabajo continúa
El cambio se integra al plan del proyecto y se rastrea junto con los requerimientos originales.
Cómo presupuestar solicitudes de cambio
Enfoques comunes:
| Método | Cuándo usarlo |
|---|
| Misma tarifa por hora | Por defecto para contratos T&M y retainer |
| Precio fijo por cambio | Cuando los cambios están bien definidos y aislados |
| Recargo porcentual | Para cambios urgentes (ej., +25% para cambios solicitados a mitad de sprint) |
Qué incluir en la cláusula de cambios
Changes to the agreed scope require a written Change Request.
The Provider will assess impact within 2 business days and provide
a cost and timeline estimate. Work on the change begins only after
written approval from the Client. Changes not approved in writing
are considered out of scope.
Emergency changes (P1 production issues) may be implemented immediately
and documented retroactively within 24 hours.
Matriz de riesgos
Una matriz de riesgos te ayuda a identificar, evaluar y planificar para cosas que podrían salir mal.
Estructura
| Riesgo | Probabilidad | Impacto | Mitigación |
|---|
| API de terceros cambia o se depreca | Media | Alto | Fijar versiones de API, abstraer integraciones detrás de adaptadores, monitorear changelogs |
| Miembro clave del equipo no disponible | Baja | Alto | Documentar conocimiento, cross-training, asegurar que no haya puntos únicos de falla |
| Scope creep por requerimientos vagos | Alta | Alto | Criterios de aceptación detallados, proceso de gestión de cambios, sección de fuera de alcance |
| Errores en migración de datos | Media | Alto | Ejecutar migración en staging primero, validar conteos de filas, mantener scripts de rollback |
| Retrasos del cliente en aprobaciones | Alta | Medio | Definir SLA de aprobación en el SOW, cláusula de auto-procedimiento después de N días |
| Problemas de performance a escala | Media | Medio | Pruebas de carga antes del lanzamiento, definir criterios de aceptación de performance |
| Vulnerabilidad de seguridad en dependencias | Media | Alto | Escaneo automático de dependencias, política de actualización, proceso de divulgación responsable |
Cómo usar una matriz de riesgos
- Revisa los riesgos al inicio de cada fase
- Asigna un responsable para cada riesgo de alto impacto
- Incluye el costo de mitigación en tu estimación (buffer)
- Actualiza la matriz cuando se descubran nuevos riesgos o cambien los existentes
Especificidades de migración a la nube
Los proyectos de migración a la nube tienen requerimientos de SOW únicos más allá del desarrollo de software estándar.
Secciones adicionales a incluir
- Evaluación del estado actual — infraestructura existente, dependencias y volúmenes de datos
- Estrategia de migración — lift-and-shift, re-platform, re-architect o híbrida
- Plan de rollback — cómo revertir si la migración falla, incluyendo estimaciones de tiempo y costo
- Plan de migración de datos — mapeo de esquemas, reglas de transformación, criterios de validación
- Ventana de downtime — ventanas de mantenimiento acordadas y plan de comunicación
- Requerimientos de compliance — residencia de datos, encriptación en reposo/tránsito, logging de auditoría
- Baselines de performance — métricas actuales para comparar contra la post-migración
- Capacitación y entrega — sesiones de transferencia de conocimiento, runbooks, documentación operativa
Riesgos comunes de migración a la nube
| Riesgo | Mitigación |
|---|
| Incompatibilidades de datos inesperadas | Revisión de mapeo de esquemas y migración de prueba con un subconjunto primero |
| Dependencias de la aplicación en APIs legacy | Auditoría de dependencias antes de la migración, capa de adaptación si es necesario |
| Costos de cloud mayores a lo esperado | Estimación de costos con instancias reservadas, revisión de right-sizing a los 30/60/90 días |
| Downtime extendido durante el cutover | Despliegue blue-green, failover basado en DNS, ensayos previos |
| Brechas de compliance en el nuevo entorno | Checklist de compliance pre-migración, rastro de auditoría desde el día uno |
Tarjetas de tarifas y modelos de precios
Estructura de tarjeta de tarifas
Una tarjeta de tarifas lista tarifas por hora o día según rol y seniority:
| Rol | Junior | Mid | Senior | Lead |
|---|
| Desarrollador Frontend | $45 | $65 | $90 | $120 |
| Desarrollador Backend | $50 | $70 | $95 | $125 |
| Ingeniero DevOps | $55 | $75 | $100 | $130 |
| Ingeniero QA | $40 | $55 | $75 | $100 |
| Diseñador UX | $45 | $65 | $85 | $110 |
| Project Manager | $50 | $70 | $90 | $120 |
Comparación de modelos de precios
| Modelo | El cliente paga | Riesgo del proveedor | Ideal para |
|---|
| Precio fijo | Total acordado por adelantado | Alto (el proveedor absorbe sobrecostos) | Alcance bien definido, proyectos cortos |
| T&M (Time & Materials) | Horas reales × tarifa | Bajo (el cliente absorbe la variabilidad) | Alcance evolutivo, compromisos a largo plazo |
| Retainer | Tarifa mensual fija | Medio (horas comprometidas, alcance flexible) | Soporte continuo, mantenimiento |
| Por hitos | Por entregable | Medio (vinculado a la completación) | Proyectos por fases, financiamiento externo |
| Bolsa de horas | Bloque prepagado de horas | Bajo (úsalas o piérdelas) | Contratos de soporte, trabajo ad-hoc |
| Staff augmentation | Por persona por mes | Bajo (el cliente gestiona el alcance) | Escalamiento de equipo, necesidades de recurso a largo plazo |
Consejos de precios
- Siempre incluye un buffer (15-25%) para incógnitas en proyectos de precio fijo
- Para T&M, establece un tope mensual para que el cliente tenga previsibilidad de costos
- En retainers, define qué pasa con las horas no utilizadas (rollover, expiran o crédito)
- Para pagos por hitos, vincula los triggers a criterios de aceptación, no a fechas
- Incluye una tarifa de movilización para proyectos que requieren configuración inicial significativa (infra, entornos, CI/CD)
- Especifica moneda y método de pago explícitamente — transferencias bancarias, Stripe y cripto tienen tiempos de procesamiento y comisiones diferentes
