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
Criterios de aceptación
Los criterios de aceptación definen cuándo un requerimiento se considera completo. Sin ellos, “hecho” es subjetivo.Formato Given/When/Then
El formato más efectivo para criterios de aceptación toma prestado del desarrollo orientado a comportamiento:Ejemplos
Requerimiento: Autenticación de usuariosConsejos 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: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
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.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.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.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
Niveles de severidad
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
Conversión a horas
La conversión depende de la velocidad del equipo, pero baselines comunes: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
1
Solicitud de cambio enviada
El cliente describe el cambio — qué quiere agregar, modificar o eliminar.
2
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.
3
Aprobación o rechazo
El proveedor presenta la evaluación. El cliente aprueba, negocia o retira la solicitud.
4
Enmienda al SOW
Si se aprueba, ambas partes firman una enmienda al SOW documentando el nuevo alcance, cronograma revisado y costo adicional.
5
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:Qué incluir en la cláusula de cambios
Matriz de riesgos
Una matriz de riesgos te ayuda a identificar, evaluar y planificar para cosas que podrían salir mal.Estructura
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
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:Comparación de modelos de precios
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