¿Cómo es el SLA al trabajar con Managed Teams?

La realidad digital y tecnológica de hoy en día ha llevado a las empresas a transformarse, sí o sí. Quedarse en el pasado significa perder clientes, ventas y productividad. Es por eso que muchas organizaciones han buscado apoyo en partners tecnológicos para potenciar sus proyectos e inyectarles rapidez y calidad. Y una de las modalidades más efectivas ha sido Managed Teams, que un equipo especializado se incorpore a tu proyecto y lo desarrolle con el mayor foco y experticia.

Pero claro, como cualquier relación entre una compañía y un proveedor de servicios tecnológicos, debe existir un contrato del tipo Service Level Agreement o SLA, para fijar todas las condiciones de esta colaboración laboral entre la empresa y el Managed Team.

¿Cómo funciona el SLA o Service Level Agreement?

Comencemos con la definición de lo que es un SLA: se trata de un contrato o documento que define el servicio que el cliente necesita del proveedor de tecnología. También fija cómo se medirá la calidad del servicio o del producto creado, también las posibles soluciones y las penalizaciones si algo no sale como estaba previsto.

Es indispensable que se cree un SLA entre el proveedor y la compañía, porque en este documento quedarán plasmados todos los servicios que serán contratados, las responsabilidades el proveedor y las expectativas del cliente. Con el SLA, ambas parte están claras de qué es lo que necesita el proyecto en el cual se trabajará.

Al no tener un SLA, por ejemplo, pueden haber confusiones o malas interpretaciones sobre lo que se tiene que hacer o lo que se necesita en el proyecto, lo que puede llevar a una pérdida de tiempo y de dinero. 

¿Cuáles son los componentes de un SLA?

Las cláusulas o elementos de un SLA deben estar referidas a dos aspectos: servicios y gestión, explican en un artículo de la revista CIO.

Elementos de servicios

Acá el proveedor del servicio va a plasmar detalladamente todos los servicios que va a prestar durante la relación laboral, también quedará explícito aquello que se excluye del servicio. Se tiene que explicar también las responsabilidades de parte y parte, los horarios para cada servicio, los procedimientos que se van a aplicar en el trabajo y las compensaciones por el servicio prestado.

Elementos de gestión 

“Los elementos de gestión deben incluir definiciones de estándares y métodos de medición, procesos, contenidos y frecuencia de informes, un proceso de resolución de disputas, una cláusula de indemnización que proteja al cliente de litigios de terceros resultantes de incumplimientos del nivel de servicio, y un mecanismo para actualizar el acuerdo según sea necesario”, explicó CIO.

Cómo manejar los cambios en un SLA con Managed Teams

Pero claro, a lo largo del desarrollo de software pueden haber cambios en los flujos de trabajo, por lo que el SLA debe ser actualizado para que se ajuste a la realidad del proyecto. Esta actualización se puede hacer perfectamente y sin complicaciones, solo que debes seguir algunas recomendaciones.

Hay una falsa creencia sobre el SLA: muchas personas interpretan este documento como un servicio de soporte, de resolución de problemas, pero realmente el SLA está enfocado en determinar el tipo de servicio que será prestado, cuáles son las prioridades del proyecto y los tiempos en los que se tienen que ejecutar las tareas. Y la idea es que el proveedor sepa cuáles son esas prioridades y cómo manejarlas para que el proyecto cumpla las expectativas del cliente.

El SLA de Managed Teams está orientado a qué tan rápido una compañía puede sumar recursos a un contrato para que la continuidad del proyecto no se vea afectada.

El Project Manager o Scrum Máster es el responsable de manejar todo lo relacionado a las necesidades del proyecto. Si se llega a necesitar más recursos en el proyecto, o eliminar alguno, es responsabilidad de esta figura para garantizar que el desarrollo marche de la mejor manera.

Los cambios en un SLA típico pueden durar de una a tres semanas. En primer lugar, el proveedor envía al cliente varios perfiles en un lapso de 3 o 4 días, el cliente evalúa los perfiles, aprueba los que sean necesarios y así estos perfiles pueden comenzar a trabajar en dos semanas.

Ante estos momentos de cambios, lo primero que tiene que hacer el PM es planear por adelantado. Es decir, si se acaba de iniciar un sprint y el PM sabe que para el siguiente sprint tendrá un flujo de trabajo grande, de una vez tiene que ir organizando la solicitud de nuevos recursos para el equipo. De modo que al inicio o a la mitad del siguiente sprint estén los recursos nuevos que se necesitan.

Hay un aspecto que se debe tomar en cuenta y es que el SLA es distinto si se trata de recursos permanentes en el proyecto o si son transitorios.

Un perfil transitorio es alguien que tiene un rol interino, que trabajará un tema puntual en el proyecto, por ejemplo un DevOps, un diseñador gráfico o un especialista en seguridad. Es una persona que estará en el proyecto un par de semanas o un par de meses y después saldrá, cuando la necesidad haya sido cubierta. Con este tipo de perfil se puede planear con anticipación y organizarse, el SLA será un poco más abierto ya que en teoría no debería incidir en el core del proyecto.

Los SLA con más complejidades son los de los recursos permanentes del proyecto o que están asociados al core, ya que están cubriendo una necesidad fuerte.

En cualquiera de los casos, el PM del proyecto es quien debe estar atento a las necesidades que vayan surgiendo en el desarrollo, para que pueda solicitar los recursos necesarios a tiempo y hacer los cambios en el SLA de forma oportuna.

Te recomendamos en video