Gestión de Problemas: tus clientes se merecen una explicación (razonable)

Leo en The Opposite of Luck una entrada sobre un informe de análisis forense realizado para determinar la causa raíz de un incidente producido en el Complejo Tecnológico Fisher Plaza de Seattle y que dejó KO las webs de varios clientes alojadas allí.

El informe completo (en inglés) puede leerse aquí.

Como los chicos de The Opposite of Luck, aplaudo la transparencia con la que Fisher Plaza ha manejado este incidente, sobretodo como deferencia a sus clientes, que realmente merecen una explicación; al fin y al cabo, Fisher Plaza provee servicios de housing y hosting, ese es su negocio: el cliente tiene derecho a saber por qué ese servicio ha fallado de forma tan catastrófica.

De igual forma, tus usuarios tambien se merecen una explicación cuando un servicio IT de los que prestas se cae; no tienes que redactar un informe de 12 páginas para cada problema que analices, pero lo que es inaceptable es encogerse de hombros y decirle: “estas cosas pasan…”. 

Cambios urgentes: WTF???

Perdonad si soy ordinario, pero es que han pasado muchas cosas idiotas en mi oficina últimamente: por fin hemos inaugurado nuestra herramienta de Service desk, después de 9 meses de diseño y rediseño (el tiempo medio de implantación en otros clientes de 1 a 2 meses). Aunque inicialmente la ventaja de esta aplicación es que es ITIL compliant por lo que ayudaría a la adopción de procesos ITIL, el jefe del departamento ha decidido, ehrm, redefinir algunos conceptos de ITIL, especialmente algunos relacionados con la gestión de cambios y de SLAs.

Para empezar, ha creado un nuevo tipo de cambio: el Cambio Urgente. No tiene nada que ver con las emergencias, sino con la urgencia. ¿Qué es un cambio urgente? Un cambio que debe ejecutarse lo antes posible. Pero no a causa de una emergencia. Por ejemplo: un project manager quiere desplegar una nueva versión de su aplicación “Tal”, y lo quiere ahora. Esta nueva versión no resuelve un problema grave de la versión previa ni añade una funcionalidad o un requisito que el negocio necesita por imperativos legales o de cualquier otro tipo ni por cualquier otra razón que se te pueda ocurrir para elevar un cambio de emergencia porque, y este es el problema, no es una emergencia. Generalmente, se tratará de una fecha de entrega demasiado cercana y un project manager poco inclinado a asumir la responsabilidad del retraso de la entrega (para qué asumir la culpa cuando tienes a los de Sistemas y su gestión de cambios que “no desplegarán hasta la semana que viene porque nuestra petición ya no entra en el CAB”).

Donde yo veo una ardua resistencia a seguir el dictado que un marco de buenas prácticas da, mi jefe y sus colegas creen que han tenido una idea genial porque con los cambios urgentes pueden demostrar que están orientados al cliente. Y una mierda. Es pura cabezonería.

Y además, ¿qué narices? ¿¡¿De todos los libros de ITIL desde v1 hasta v3, dónde leches han leído ellos ese invento de los “Cambios Urgentes”?!?

Cómo sobreponerse a la aplastante inercia de la realidad en 4 pasos: paso 2

El paso 1 trataba sobre crear el contexto para el cambio, prepararse para que el cambio ocurra definiendo qué debe cambiar y por qué. El paso 2 trata de determinar a quién le importa realmente (o debería importarle) el cambio y por qué. En muchas conversaciones con compañeros en varias empresas en las que he trabajado, existe un “ellos” difuso y étereo involucrado (a veces incluso un “ellos” explicito y concreto): los procesos no pueden cambiarse porque “ellos” no nos dejarán, o porque alguien que ocupa un puesto determinado de mando no permitirá que el cambio se ejecute. En el paso 2 hace falta establecer un enlace entre el comportamiento (“qué”), la razón por la que debe cambiar (“por qué”) y quién necesita entender que el cambio es necesario. Así de simple… aunque si realmente fuera tan simple, no habría ninguna inercia a la que sobreponerse, ¿no?
Seguir leyendo…