Servicios contra Proyectos

0

Dentro de la gestión de TI hay dos grandes ramas: la gestión de servicios y la gestión de proyectos. Normalmente estas dos ramas están tan diferenciadas que en muchas ocasiones parecen como dos carreras diferentes. Los estudios o certificaciones de una no tienen nada que ver con los de la otra. Pero una visión en detalle revela que realmente son dos caras de la misma moneda y que tienen mucho que aprender la una de la otra.

En este artículo expongo mi punto de vista expongo el problema de la división y por qué un buen gestor de TI debe dominar tanto los servicios como los proyectos.

La diferenciación actual

Quitando grandes fabricantes, el trabajo que se puede hacer actualmente como gestor de TI en una organización, puede estar en el lado del desarrollo o en la parte de sistemas. O dicho de otra manera, gestionando proyecto o gestionando servicios. Normalmente, aunque ambos suelan colocarse en el mismo espacio, crean rápidamente la división entre ellos. No es raro ver un responsable de sistemas( o de operaciones, o de explotación, o de servicios, o de…) y a un responsable de desarrollo (o de proyectos, o de programación, o de la PMO, o de…). Cada uno vive en su mundo y se relaciona con el otro para las puestas en producción.

El gestor de proyectos puro conoce poco sobre la gestión de sistemas. Toca ligeramente algunos procesos, pero raramente en profundidad. Es difícil encontrar un gestor de proyectos que conozca la diferencia entre una incidencia y un problema. De la misma manera un gestor de servicios conoce poco sobre la gestión de proyectos. Tiene algunas nociones, principalmente por la experiencia en cambios, pero flaquea si le preguntas sobre gestión de riesgos, reservas de contingencia o planificación. De hecho no es muy raro ver a un responsable de sistemas flaqueando como un novato al planificar un gran cambio.

Que gana el gestor de proyectos sabiendo de gestión de servicios

Lo primero que gana es conocer su lugar en el servicio que está creando. Cuando se desarrolla se es parte de la fase de transición de servicio, se está creando un servicio. Muchos desarrolladores ven el proyecto con un inicio y un fin, no ven que después hay que mantener el producto que se ha generado, y cuando son estos desarrolladores los que lo deben mantener no se dan cuenta de que están dando un servicio de soporte (y no una garantía al desarrollo como se oye decir a muchos de ellos).

A los desarrolladores les importa la tecnología a utilizar y la funcionalidad a conseguir. ¿Hacen una gestión de la capacidad, disponibilidad o seguridad de la aplicación que desarrollan? Normalmente no. Y si les preguntas si lo han tenido en cuenta, no es raro obtener un “¡Eso es problema de sistemas!”

Creo que esto es un error. Si te dedicas a desarrollo, creo que unos fundamentos de ITIL no están de más. Conocer conceptos como SLAs y como desarrollarlos es básico para tu soporte tras la entrega. Lo mismo sobre la gestión de incidencias y problemas. Hay que entender que cuando te mandan un error lo primero es entregar un workaround y no ir a arreglar el defecto y que el cliente se aguante con el problema mientras tanto. Lo mismo con los procesos de gestión de cambios.

Resumiendo, no digo que tengan que ser expertos, pero creo que un gestor de proyectos de desarrollo no está completo si no tiene formación en servicios.

Que gana el gestor de servicios sabiendo de gestión de proyectos

Un servicio no sale de la nada. Hay que ponerlo en marcha, y esto implica pasar por gestión de cambios. Entender la gestión de cambios como algo diferente a un proyecto es un grave error. Hay que planificarlo, seguirlo, evaluar riesgos, costes, timming, etc.

Cuando dirección le pide al gestor de servicios que haga una planificación es normal ver como hace un Project que después se muere de risa. Nunca, y repito lo de nunca, he visto a un gestor de servicios establecer una línea de base y redefinir la planificación a mitad de proyecto, mostrando las desviaciones, llevando ese seguimiento hasta el final. Es normal ver como el Project va cambiando retrasando fechas una y otra vez.

Y tampoco he visto tras un cambio hacer el ejercicio de documentar las lecciones aprendidas, incluso cuando sabes que tras unos meses tendrás un proyecto similar.

Igual que al gestor de proyectos le recomiendo un curso en ITIL, a los gestores de servicios les recomiendo uno de Prince2 o intentar obtener un CAPM.

Resumen final

Creo que el combo gestor de proyectos y de servicios es el de mayor valor para el mundo de la gestión de TI. Y precisamente por eso yo he tomado este camino.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información.
Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector.
Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo.
Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios