¿Qué es un SLA en desarrollo de software y por qué no alcanza para un proyecto?

Un SLA (service level agreement, o acuerdo de nivel de servicio) es un contrato que fija cómo se mide el servicio que entrega un proveedor: tiempo de respuesta, tiempo de resolución, disponibilidad (uptime) y qué pasa si esos números no se cumplen. Nació para soporte técnico e infraestructura —un helpdesk, un hosting—, no para un proyecto de software con fecha de entrega. Por eso, cuando una empresa contrata un squad externo para construir algo nuevo, un SLA tradicional mide lo que no importa (cuán rápido contestan un ticket) y se queda mudo sobre lo que sí importa (si lo que se está construyendo es lo que se pidió).

¿Qué mide un SLA en un contrato de desarrollo de software?

Un SLA típico define cuatro tipos de métrica: uptime, tiempo de respuesta, tiempo de resolución y disponibilidad de soporte. El documento también suele incluir qué pasa si el proveedor incumple —créditos de servicio, renegociación, salida del contrato— y quién es responsable de cada capa del sistema.

• Uptime — el porcentaje de tiempo que el servicio permanece disponible, medido casi siempre por mes (por ejemplo, 99,9%).
• Tiempo de respuesta — cuánto tarda el proveedor en reconocer un problema reportado.
• Tiempo de resolución — cuánto tarda en solucionarlo de verdad, algo distinto de solo reconocerlo.
• Disponibilidad de soporte — si la cobertura es 24/7, solo horario comercial, o escalonada según la severidad del problema.

¿Por qué un SLA pensado para soporte no alcanza para construir un proyecto?

El problema no es que el SLA esté mal diseñado — es que mide el proceso, no el resultado. Un equipo de soporte puede cerrar el 95% de los tickets dentro del plazo acordado y aun así dejar al cliente con la sensación de que nadie resolvió nada de fondo. Trasladado a un proyecto de desarrollo, ese mismo problema se agrava: medir la productividad de un equipo de ingeniería por tiempo de respuesta o disponibilidad no dice si el código que están escribiendo resuelve el problema real, ni si el proyecto va a estar terminado cuando dijeron que iba a estar terminado.

Gartner ordena esto en tres niveles de madurez de contrato: input-based (se paga por horas o por gente asignada), output-based (se paga por entregables concretos, como una feature o un ticket cerrado) y outcome-based (se paga por el resultado de negocio, como el uptime o el impacto medido). La mayoría de las empresas todavía está en el primer nivel o migrando al segundo; muy pocas llegan al tercero. Un SLA de soporte tradicional vive en el primer nivel. Un proyecto de software bien gestionado necesita vivir, como mínimo, en el segundo.

¿Qué pasa cuando el SLA queda vago?

La causa más común de fricción en un contrato con SLA no es que el proveedor incumpla a propósito: es que la métrica nunca quedó del todo clara. “Tiempo de respuesta” puede significar cosas distintas para cada parte si no se define el momento exacto en que empieza a contar el reloj, y “resuelto” puede significar “se aplicó un parche temporal” para el proveedor y “el problema no va a volver” para el cliente. Cuanto más ambigua la definición, más margen hay para que cada lado la lea a su favor cuando algo sale mal — y ese desacuerdo, no el incumplimiento en sí, es lo que más tiempo consume resolver.

¿Qué reemplaza al SLA en un proyecto pagado por milestone?

En un proyecto de software —a diferencia de un servicio continuo de soporte— lo que hay que verificar no es cuán rápido contesta el equipo, sino si entregó lo que se comprometió a entregar, cuando dijo que lo iba a entregar. Por eso Zenit no le pide a las empresas que redacten un SLA genérico para cada squad: reemplaza esa lógica por criterios de aceptación firmados antes de arrancar cada milestone, así el estándar de “terminado” queda definido de antemano y no se negocia recién cuando algo no cierra.

SafePay libera el pago de cada milestone contra esa evidencia —no contra una fecha en el calendario ni una promesa verbal—, así que el squad no cobra por trabajo que no se puede verificar y la empresa no paga por trabajo que no está hecho.

Y esa historia de cumplimiento no se pierde entre proyectos: ZenitRank la acumula milestone a milestone, con un on-time rate que se actualiza solo, así que la próxima empresa que evalúe a ese squad ve un historial real —no una promesa nueva cada vez.

Un SLA sigue siendo la herramienta correcta cuando lo que se contrata es un servicio continuo — soporte, infraestructura, mantenimiento. Para un proyecto con fecha de entrega y alcance definido, la pregunta que hay que responder no es cuán rápido responde el proveedor, sino si lo que va a entregar es exactamente lo que la empresa necesita — y esa pregunta la responde Kaizen antes de que el proyecto arranque, no un documento de métricas de soporte.