Otra vez esperando en una sala de espera (¡acertado nombre para la sala!) y me vienen a la cabeza algunas experiencias que he tenido en las últimas semanas sobre el sprint plan.
Para que dirías que sirve este evento de Scrum?
No me considero un ultra especialista de Scrum, por aquello del síndrome del impostor tan común en el sector de la agilidad (otro día hablamos de esto), pero le veo algunos beneficios importantes.
Sirve:
Para tener una conversación abierta entre equipo y PO sobre “qué hacemos a continuación”.
Para equilibrar adecuadamente la capacidad de desarrollo con el tamaño del trabajo que vamos a acometer. (dígase tamaño en todas las acepciones que podamos pensar en el sector del software)
Para establecer las expectativas del PO al respecto de lo que el equipo espera entregar a lo largo de la próxima iteración.
Para aislar al equipo de desarrollo de toda la complejidad del backlog completo y del ruido que se genera cuando hablamos de cosas que no sabemos seguro de si queremos o no hacer. Para enfocar.
El punto de equilibrar la capacidad con el WIP que inyectamos al sistema es fundamental, porque de ahí se deriva en gran parte la viabilidad de cumplir con los objetivos y que el equipo esté alineado con las expectativas establecidas al principio del sprint.
Algo así como decir que
En el sprint plan calibramos el tamaño del trabajo, priorizamos con la PO y seleccionamos juntos lo que vamos a abordar, la PO está de acuerdo con esa selección y espera recibir eso durante la iteración; el equipo se enfoca y todos trabajan en pro de conseguir ese objetivo común.
Si esos objetivos se cumplen de manera consistente, la PO sentirá que el equipo es predecible, lo que lleva a fortalecer los vínculos de confianza. Eso hace que la PO pueda, por su parte, adquirir compromisos con otras partes de la organización e ir preparando todo lo que desencadena una entrega de nuevas funcionalidades a Negocio: modificación de procesos de negocio, gestión del cambio, comunicación, comunicación a cliente final, variación de contratos o, incluso en alguno de los casos que estoy conociendo de primera mano, reestructuración de los espacios físicos para adoptar las nuevas maneras de trabajar.
Es decir: aguas abajo hay muchos grupos de trabajo que dependen del cumplimiento de las expectativas generadas en un Sprint Plan.
-- Hay incertidumbre en el desarrollo. -- Ya lo sé. -- Estamos en un mundo complejo, la organización y el software forman un sistema adaptativo-complejo que lo hace de todo menos predecible. -- También lo sé. Y por eso no pido adherencia al 100%, pido trabajo continuo en pro de la mejora.
Cuanto más puedas reducir la desviación que hay entre lo que te propones hacer en un sprint y lo que consigues, la organización funcionará mejor aguas arriba (en la relación entre los POs y el resto de personas interesadas en aquello que se desarrolla) y aguas abajo (la relación que todas esas personas tienen con el incremento).
Como le decía Batty a Deckard minutos antes de morir, “he visto cosas que vosotros no os creeríais”. He visto muchos equipos que se toman la planificación del sprint como un “trocear el trabajo en bloques de 15 días”, pero también los he visto que planean y comunican aguas abajo para que todo el flujo vaya suave.
Hay gente ahí fuera que lo hace de película: esos son los imprescindibles, esos son aquellos de los que debemos aprender.
PS: Te dejo un par de preguntas para que le des a la reflexión:
¿Qué factores influyen en la predictibilidad de tu(s) equipo(s)?
¿Cómo influye la cantidad de información disponible al respecto de un determinado PBI sobre la capacidad que tenemos de cumplir la meta del sprint?
En algún momento pausado de estas vacaciones le daba vueltas a la situación del sector de la gestión de servicios IT en la última década.
Como siempre, todo nacía de alguna curiosidad, de esas preguntas que, de repente, me saltan a la cabeza y que me obligan a dedicarle unos ciclos de CPU. Sólo que no siempre son “unos pocos ciclos”; en este caso ha sido un poco más.
La pregunta que me hacía giraba en torno a cuál será la aproximación a la Gestión de Servicios IT que hace hoy por hoy una persona de, digamos, 30 años. Con esa edad ha terminado unos estudios, tiene unos años de experiencia y ha comenzado a comprender cómo funciona el sector TIC. Pero también se encuentra con que la formación que pueda recibir para gestionar servicios es, por ejemplo, un Fundamentos de ITIL® 4 o la información que reciba de las herramientas con las que trabaja.
¿Qué visión tiene de la gestión de servicios?
Si miro atrás y pienso en cómo entré yo en este mundo, veo que estudié ITIL® V2, después ITIL® V3, ISO/IEC-20.000, COBIT e ITIL® 4 entre otros. Además, participé en congresos, era activo en multitud de foros, discusiones online y presenciales, conversaciones con gente de mi zona e internacionales. El sector ITSM era bullicioso como un mercado en Palermo, con gente deseando venderte sus servicios, pero también con mucha gente deseando compartir conocimientos, experiencias, ideas.
Pero hoy la cosa es muy, muy diferente. Ninguno de los foros que yo conozca (ni siquiera los que he promovido yo mismo) están activos. Se han convertido en monólogos en los que copywriters escupen mensajes publicitarios disfrazados de “contenidos” y tratan de llamar tu atención sobre su herramienta, sus servicios o su formación.
Llegué a pensar que la profesión podría haberse acabado, que ya nadie quiere un IT Service Manager, quizás porque ya no se hace gestión de servicios. Pero no: obviamente los servicios se siguen prestando, la necesidad de gestionarlos de una manera formal, sistemática y ordenada sigue existiendo y las ofertas de trabajo siguen existiendo. ¡Si hasta veo ofertas pidiendo un especialista CMDB!
Nadie habla ya de la CMDB, pero seguimos necesitando especialistas. ¡qué cosas!
¿Cómo hemos llegado a esta situación?
Yo creo que tantos años de tener un mercado fuertemente dominado por un único framework (ITIL®) ha hecho que la caída de ITIL® arrastre a todo el sector ITSM consigo.
Durante décadas hubo mentes activas que trataron de generar marcos de trabajo, maneras de hacer, diferentes a ITIL® con la intención de añadir diversidad, de generar un negocio alternativo, y de aumentar la velocidad con la que las novedades se incorporaban a los marcos de trabajo. La rápida expansión que están teniendo agile y devops tenía que provocar cambios en la manera de entender y gestionar los servicios e ITIL® estaba siendo demasiado lenta en asimilar todos estos cambios.
La lista de modelos es interminable, pero para citar algunos de los más relevantes podemos pensar en IT4IT, USM, VERISM y muchos más; pero ninguno de ellos ha tenido la penetración y fuerza en el mercado que ha tenido ITIL®. De hecho, si miras las ofertas de trabajo para ITSM en España verás que todas, absolutamente todas, piden ITIL® de una u otra manera.
Así pues, María, nuestra candidata de 30 años que entra en el mundo de la Gestión de Servicios tiene que poner en su CV las siglas doradas, sí o sí; y para eso se inscribe en un curso de Fundamentos ITIL® V4 en el que le van a explicar tal ensalada de conceptos, que va a salir con la cabeza más liada si cabe, porque la cantidad de ideas que añade ese curso es tremenda.
¿Y Entonces? ¿Qué hacemos con María?
No tiene demasiadas alternativas. El mercado de la formación se ha ido concentrando, y ahora PeopleCert es dueño de la certificación y de ITIL®. Por otra parte, EXIN ha caído y por lo tanto sus esquemas de certificación basados en ISO 20.000 también. En formación clásica ITSM queda algo en manos de APMG, la Global Trust Association tiene aqui una gran oportunidad y quién sabe si Pink Elephant conseguirá sacar adelante su esquema de formación y certificación después de que PeopleCert les diera la patada.
Si buscamos los eventos ITSM de 2023 en España, veremos que no hay gran cosa: un montón de empresas que venden herramientas haciendo sus eventos ITSM para demostrar que son los mejores ( y recuerda, María: a fool with a tool is still a fool) y no mucho más. Por otra parte, la gran fuente de conocimiento y de networking que fue itSMF España está en un proceso de cambio que tiene paralizado el motor de eventos y por lo tanto apenas si hay un evento anual en Madrid.
Pero volvamos con el título de esta entrada:
Where have all the SM gone?
Dado el contexto un poco decadente que he mostrado en la primera parte del post, ¿Qué ha pasado con los IT Service Managers, a dónde se han ido?
Los de la vieja escuela han tomado diferentes caminos: los hay que siguen al pie del cañón, gestionando los servicios más importantes del país: sigue siendo un rol necesario, demandado y en proceso inflacionario porque hay pocos; así que muchos están desempeñando un gran trabajo, habitualmente en empresas prestadoras de servicios o de outsourcing. María tiene una gran oportunidad aquí, trabajando codo con codo con cualquiera de estos veteranos, aprendiendo “desde las trincheras” y con suerte aportando todo su conocimiento y nuevas maneras de ver las cosas al sector.
Otros (muchos) se han mudado a un sector mucho más lucrativo: la ciberseguridad. En ese terreno el trabajo nunca falta y cada vez es más necesaria una correcta gestión de los servicios de ciberseguridad. Era un nicho claro. Además, mientras que una buena gestión de servicios en tiempos de crisis se podía ver como un lujo (o un “se le supone” al outsourcer), la ciberseguridad siempre es un must, indiscutible.
Otros, como es mi caso, iniciamos una deriva por el terreno Lean que nos llevó al mundo agile y ahora combinamos conocimientos y experiencias entre la construcción y la entrega. Es bonito, pero un terreno pantanoso por la falta de marcos claros de trabajo; eso hace que sea una profesión muy exigente en pensamiento y reflexión.
Finalmente, otros cuantos (y que serán cada vez más), se han retirado: ITIL® nació a finales de los 80 y los que eran como nuestra María en el año 1988 hoy peinan canas con 65 y están celebrándolo (o no: ahora se dedican a pensar y a escribir y a trabajar pausadamente en lo que les gusta).
Así que María, mi consejo: la gestión de servicios clásica que inventamos en 1990 tiene algunas cosas muy potentes y muy válidas. No debes tirarla toda a la basura. Pero no estaba pensada para la sociedad actual. Hay que trocearla, desmenuzarla como un bocata de esos de pulled-pork, tomar algunas ideas importantes y completarla con todas las cosas nuevas que has aprendido en otros sectores: Lean, Agile, DevOps, Open Management, teal organizations… la lista es interminable.
Yo veo un futuro de ITSM en el que hay diferentes categorías de servicio: aquellos en los que tiene sentido el enfoque ágil, orientados a flujo y a entrega de valor, con fuerte participación del cliente/usuario en su evolución y características de prestación y aquellos en los que no se le ve sentido a esta aproximación y entonces se gestionen de una manera más clásica orientada a economías de escala. Pero en ambos casos, veo un futuro más humanista, en el que las personas tienen un protagonismo especial, en el que hay una manera de organizarnos y de colaborar mucho más orientada a la comunicación, a la mejora y al respecto. Mucho más “Open IT” en definitiva.
Lo maravilloso es que se abre frente a ti un mundo nuevo que no está construido. Tendrás que construirlo tú: crea la comunidad, habla con tus compañeros, se creativa, imagina nuevas maneras de hacer. Tendrás que luchar duro, como en todas las generaciones, por romper los moldes y hacer que los viejos dinosaurios aprendamos a entender el mundo a través de tus ojos. Ten paciencia, habla el idioma de tus superiores, y muéstrales cómo el taylorismo pasó a la historia.
Pero siempre recuerda a Bernard de Chartres:
“si podemos ver más lejos es gracias a que somos enanos a hombros de gigantes”.
¡Buena suerte, María!
Y si necesitas cualquier cosa, aquí estoy. Siempre me ha gustado compartir lo poco que se.
Han pasado siete años desde que escribí “La X Muda”.
Siete años guardado en un cajón de Internet al que sólo llega algún que otro despistado.
Y resulta que durante estas vacaciones, va Rob England y añade en ese fantástico curso que está impartiendo sobre Open IT Management un apartado sobre la octava Muda.
Este curso que están ejecutando Rob y Cherry es muy innovador: en lugar de impartir un curso en forma de masterclass han preferido convertirlo en un correo semanal en el que se toca un tema. Este correo se publica después como un post en linkedin y de ahí cuelga la conversación entre los alumnos alrededor del tema planteado.
Claro, no me pude resistir a añadir en la conversación un enlace al texto de La X Muda, acto que provocó alguna que otra visita a un blog que cría telarañas porque ya nadie sigue a blogueros.
Y una de estas visitas ha abierto una puerta que llevaba siete años cerrada.
¿Será posible? Cuando escribí la X Muda estaba convencido de que alguien me iba a hacer la pregunta.
La dejé adrede plantada en el texto, y pensé que más de una persona se vería provocada por el artículo y acabarían enviando un correo o poniendo un comentario haciéndome "la pregunta"
Pero nadie la hizo. Yo tenía la respuesta preparada, pero nadie hizo "la pregunta".
Increíble.
Son cosas que pasan: a veces piensas que un texto va a desencadenar una determinada secuencia de pensamientos, pero eso no pasa y ya está; la vida sigue.
Y, sin embargo, después de siete años con "la pregunta" junto a "la respuesta" criando polvo en un rincón de mi cabeza, hoy me suena el Whatsapp y alguien (muy especial, tengo que decirlo) me plantea la pregunta
¡No me lo podía creer!
Y así le dije: ¿te puedes creer que llevo siete años esperando a que alguien haga esa pregunta? Quizás es tan tonta o tan obvia, que la gente no lo ha exteriorizado; quizás nadie se ha dado cuenta de que había que hacerla. Sea como sea, la respuesta lleva siete años esperando a salir.
¿Quieres saber cuál es la pregunta (o su respuesta)?
Bueno, pues la tal pregunta es muy simple:
¿Y cuál es la novena muda?
Claro, si llegamos hasta la octava muda (si quieres saber cuáles son y esas cosas, tendrás que ir al artículo original para verlo) y de repente yo salto hasta la décima, la novena quedaba libre. ¿Cuál es?
Va, si la pregunta ha esperado siete años, te puedo dejar un rato pendiente de saber cuál es la novena, ¿no?
A finales de 2022, G2 y la Global Trust Association firmaron un acuerdo de colaboración que habilita a G2 a impartir el portfolio de cursos de la GTA. Este portfolio es muy amplio, así que el planteamiento es ir incorporando poco a poco los cursos que se adecuen mejor a las necesidades de nuestros clientes.
El primer curso que lanzaremos será a finales del mes de Febrero de 2023: el curso de preparación para la certificación Certified Business Agility Professional. Este es un curso en el que se visitan cada una de las dimensiones y dominios del modelo operativo del Business Agility Institute.
Nos hemos dado bastante tiempo para preparar el curso; queremos que sea una experiencia que esté a la altura, así que estamos repasando minuciosamente los contenidos y los materiales.
En G2 somos mucho de estructurarnos las ideas y hemos querido hacer un pequeño trabajo de investigación: ¿Qué definiciones hay de Business Agility? ¿Qué conceptos tienen en común estas definiciones y cómo conecta esto con el curso que vamos a impartir?
El factor común
En el material de clase vienen varias definiciones. Lógicamente la del Business Agility Institute, pero también aparecen las de la Agile Alliance, el Business Agility Manifesto o el Agile Business Consortium.
Incluso cuando ampliamos el abanico y analizamos definiciones de agilidad empresarial proporcionadas por otros marcos de referencia o en bibliografía general, vemos que todas se refieren prácticamente a lo mismo: construir organizaciones capaces de adaptarse rápidamente a los cambios, manteniendo al cliente y sus necesidades en el centro de atención.
Exploremos un poco más los conceptos comunes a todas estas definiciones:
Foco en el Cliente. Todas las definiciones hablan de la capacidad de responder y de adaptarse a los cambios exteriores, en el sector, en el mercado o en el entorno en el que se sitúa la organización. También incluyen ideas al respecto del cambio en las necesidades o intereses de los clientes, y cuando profundizamos un poco más, vemos que en general las tendencias Outside-In, de las que ya hablábamos con USMBOK hace más de 10 años, se consolidan. El cliente le da sentido a la existencia de la empresa ágil y está en el centro de todo.
Innovación, como la capacidad de crear soluciones de negocio de manera rápida y eficiente. Soluciones que satisfacen esas necesidades cambiantes (y el cambio se produce a alta velocidad) en el mercado y los clientes.
Flexibilidad, como la capacidad de responder fácilmente a las demandas y necesidades de los clientes, a pequeñas variaciones en las necesidades, modificando y adaptando productos y servicios para cada uno de los consumidores. También vemos la flexibilidad en los procesos, en la manera de organizarnos y en la manera de ejecutar nuestro trabajo.
Aprendizaje y Mejora continua, como la capacidad de experimentar, aprender e incorporar los aprendizajes en los productos y los procesos productivos. La aproximación empírica al cambio, basada en el método científico, en el planteamiento de hipótesis y la realización de experimentos que nos ayuden a validar estas hipótesis y a cartografiar un terreno (el sector de negocio, el mercado) que cambia constantemente.
Colaboración, ser capaces de trabajar juntos de manera efectiva para alcanzar esos objetivos comunes, no sólo entre individuos, sino también a nivel de equipo, y de unidades organizativas mayores (que no siempre se corresponderán con la idea clásica de “departamento”).
Toma de decisiones rápidas y efectivas, basadas en información actualizada y que le permitan tener esa capacidad de responder y de cambiar de dirección con rapidez en caso necesario. Estructuras organizativas poco jerárquicas donde las decisiones se toman, de forma consciente y empoderada, cerca del lugar donde ocurre la acción.
La conexión con el modelo del BAI
El modelo operativo del BAI se compone de 12 dominios interconectados estructurados en cuatro dimensiones: Relaciones, Liderazgo, Individuos y Operaciones.
Podemos conectar los conceptos comunes a las diferentes definiciones y los dominios del modelo de Agilidad Empresarial del BAI:
En Conclusion
La Agilidad Empresarial no es un modelo, ni un framework ni una metodología. Se trata de un concepto que agrupa una serie de capacidades o características que deben tener las organizaciones para conseguir adaptarse rápidamente a un entorno incierto. De hecho, la definición del BAI dice, literalmente:
La Agilidad Empresarial es un conjunto de capacidades organizativas, comportamientos y formas de trabajar que le brindan a su empresa la libertad y flexibilidad para lograr su propósito.
El modelo del Business Agility Institute es un marco de referencia global, que aborda de manera estructurada todos los conceptos comunes que encontramos en las diferentes definiciones de Agilidad Empresarial.
Por otra parte, el curso de preparación a la certificación de la Global Trust Association revisa todos los dominios de este modelo, aportando los conceptos, una visión de las herramientas y artefactos que se pueden utilizar en cada área y sirve como Piedra de Rosetta para un área de conocimiento que es, sin duda, relevante y muy extensa.
Hace un rato Alex Ballarin 🇺🇦 me ha mencionado en un comentario a un post sobre Minería de Procesos y mi respuesta terminaba con una frase de estas “apisonadora”:
Y después me quedé pensando: "Esto se merece una explicación."
En G2 (gedos.es) llevamos más de 10 años ejecutando proyectos de minería de procesos. Estos proyectos nos han dado una gran experiencia en las diferentes fases por las que pasa, no ya el proyecto de minería, sino la iniciativa completa de minería de procesos dentro de una compañía. Nos han enseñado no sólo a analizar procesos sino a entender los retos de negocio que aparecen detrás de cada una de estas iniciativas.
Todo empieza con la curiosidad: alguien ve una presentación, o atiende a una demo, o lee un artículo y piensa “esto seguro que en mi empresa daría unos resultados increíbles”. Cuando ves tu primera demo de minería de procesos la cosa es tan mágica, tan impresionante, que rápidamente se te ocurren casos de uso en tu compañía.
Después viene el intentar llevarlo a casa: conseguir la financiación para un proyecto piloto de una tecnología mágica y novedosa de la que poca gente ha oído hablar era difícil hasta hace unos años. Ahora todo el mundo habla de las bondades de la minería de procesos y por lo tanto es una tecnología bastante más extendida y eso ayuda. Aún así, el punto débil de un piloto de este tipo es conseguir los datos y eso no es siempre del fácil. Aquí podría abrir un artículo completo al respecto de los problemas organizativos que aparecen en una gran compañía cuando alguien pide los datos de un proceso de negocio; sobre todo si no es el propietario del proceso quien lo hace, pero como decía Michael Ende, "eso es otra historia y debe ser contada en otra ocasión".
Se hace un piloto y se ven los resultados, y todos quedan con la boca abierta diciendo “🤩oooh, esto es fantástico”.
¿Seguro?
Pues no. Aquí empieza el calvario cultural y psicológico de la persona que está impulsando la iniciativa: una de las primeras cosas que aporta la minería de procesos es transparencia al proceso. De repente, como en una radiografía, se ven las interioridades del proceso: es fácil comenzar con el (mal) juego del finger pointing, apuntando a departamentos, productos o incluso personas individuales donde aparecen los problemas del proceso.
De repente, como en una radiografía, se ven las interioridades del proceso.
Aquí es donde se notan los años de experiencia: visión sistémica, atacar al sistema y no a la persona, descubrir qué es lo que produce (el conjunto de causas) los atascos y cuellos de botella, expresar los hallazgos en términos de negocio y no en términos de operativa, técnicos o de proceso. En definitiva, usar la minería de procesos como una herramienta más para la mejora continua del proceso.
Si consigues superar esta etapa, la siguiente no va a ser más fácil: ¿Has visto el final del párrafo anterior? Pone “mejora continua del proceso”. Es decir, la siguiente fase, que tiene que ver con institucionalizar la minería de procesos en la compañía, depende totalmente de la cultura de transparencia y mejora que haya en tu compañía.
Hacen falta valores de esos que están muy enraizados en las compañías Lean y Agile: transparencia, coraje, empoderamiento, deseo de “ser los mejores en mejorar”.
Y recordemos que el cliente objetivo de las grandes compañías de minería de procesos no son precisamente pymes y startups, sino grandes empresas con grandes y costosos procesos de negocio en los que el business case sea magnífico. Empresas en las que es más difícil encontrar la tranquilidad de ejecutar una herramienta que saque los trapos sucios de los procesos de negocio, que señale las ineficiencias y que nos ayude a pensar en qué y cómo debemos mejorar los procesos.
Pero, en definitiva, empresas en las que la apuesta por la mejora puede tener un impacto económico millonario.
Pero en el mundo de las grandes empresas asumir errores, mostrar ineficiencias, declarar transparentemente que las cosas tal y como las hacemos hoy son muy mejorables es muy difícil. También es muy difícil conseguir la complicidad y el compromiso de aquellos que tienen que impulsar el cambio.
Ojo, hay empresas enormes en las que la cultura facilita estas cosas, pero creo que podemos afirmar sin temor a equivocarnos que son las menos.
Por eso el reto es más psicológico y cultural. Tiene mucho que ver con la humildad en el liderazgo, con estar dispuesto a ver la viga en el ojo propio y a tener el valor de cambiar las cosas.
Y tiene que ver con cómo se lleva adelante la iniciativa de Minería de Procesos: si se hace desde fuera del proceso el fracaso está garantizado. Si se hace desde dentro, todo irá mejor, pero el reto será conseguir el compromiso y el tiempo.
Frecuentemente cuando se ponen en marcha nuevos servicios, incidimos sobre cientos de usuarios que deben adquirir rápidamente nuevos conocimientos y adaptarse a nuevas maneras de trabajar. Es en este momento cuando necesitamos poner foco en una Gestión del Cambio precisa y especializada que nos ayude a conseguir poner a todas estas personas en marcha rápidamente.
El problema
Cuando hacemos este tipo de despliegues, se produce un rápido aumento de las necesidades de soporte: gran cantidad de usuarios necesitan apoyo en un corto espacio de tiempo. Los equipos de soporte se ven fuertemente afectados por esta situación, que además deben combinar con dar apoyo a las necesidades cotidianas del negocio.
La gestión del cambio debe proporcionar una base de conocimientos, materiales de formación y procedimientos que sean comprensibles, que se mantengan actualizados y que sobre todo puedan ser consultados de manera fácil por los usuarios afectados.
La solución
El empleo de soluciones especializadas y temporales, que puedan montarse, usarse y desmontarse fácilmente y en modalidad de pago por uso. Soluciones que no interfieran con los entornos corporativos y que proporcionen la flexibilidad y el acceso global que requieren los usuarios.
La Propuesta de G2
El próximo Jueves 7 de Mayo de 2020 haremos un webinar explicando cómo montamos una de estas plataformas express para habilitar una Unidad de Intervención Inmediata.
El Service Desk como Unidad de Intervención Inmediata
Llevo en el sector de las TIC unos 33 años y desarrollando proyectos unos 28. Aún así, mis participaciones en proyectos de software más intensas se han dado durante los últimos 10 años, temporada en la que desde G2 hemos hecho una suave deriva dentro de la gestión de servicios a la gestión completa del ciclo de vida del servicio, cosa que me ha permitido participar en los equipos de desarrollo aportando visiones de Lean, de Agile y de DevOps.
Durante estos años, una de las lecciones más importantes que he aprendido es que no hay DONE sin Materialización del Valor. Es decir, que por mucho que los equipos de desarrollo piensen que han finalizado un paquete de funcionalidades, hasta que no están en manos de usuario y siendo utilizadas, no son más que promesas incumplidas de un valor futuro.
Ya más maduro, sobre el año 2013 reflexionaba sobre la problemática que nos presentaba el hecho de acelerar el flujo utilizando técnicas de automatización y el cuello de botella se trasladaba a otro sitio: el usuario, la última frontera.
Así que llegamos a la conclusión de que una de las fases que más pueden influir en la materialización del valor generado por un proyecto es la de la Gestión del Cambio: poner en manos de los usuarios la nueva aplicación y conseguir desplegar lo antes posible y sobre el número de usuarios adecuados, el conocimiento, la práctica y los nuevos circuitos que harán que la promesa de valor se convierta en realidad.
¿De qué serviría un nuevo sistema para canalizar las oportunidades de venta que llegan por los diferentes canales si los comerciales no lo saben usar o lo usan mal?
¿De qué serviría el precioso sistema de seguimiento de indicadores si los que deben tomar decisiones en base a esos indicadores no lo saben usar o aquellos que alimentan los datos lo hacen mal o a deshora?
¿Cómo diablos vamos a conseguir poner a todas esas personas en teletrabajo si cuando les damos las herramientas técnicas no saben usarlas?
Así, pues, se nos hace fundamental ayudar a los equipos en esta etapa de Gestión del Cambio, y tradicionalmente las empresas ponen foco en una serie de acciones:
generación de materiales de formación
formación a usuarios clave
formación a formadores
formación al equipo de soporte
documentación de las preguntas más frecuentes
Pero... ¿A qué se parece la realidad cuando te enfrentas a desplegar una solución para cientos o miles de usuarios?
Pues lo primero que te pasa es que la aproximación de formar a usuarios claves o formación de formadores es quizás un poco lejana al usuario final.
Tardas demasiado en llegar a ellos y con personas que en realidad son “proxies” del conocimiento: muy buena tiene que ser la formación a formadores (teórica y práctica) para que ellos puedan transmitir de manera fluida todo lo que se supone que debe saber el usuario final. Y muy buenos tienen que ser los materiales de formación, no podemos aspirar a que ellos generen sus propios materiales.
Lo segundo es que habrá situaciones que hayan quedado fuera de la formación y que durante las sesiones de formación a usuario final aparezcan en forma de preguntas que el recién estrenado profesor no sea capaz de resolver. ¿Tenemos un canal para poner en contacto al profesor con el equipo de desarrollo para que le resuelvan la duda de un día para otro? ¿Tenemos una manera de documentar este conocimiento modificando rápidamente el material de formación o de consulta?
En tercer lugar, los recién formados alumnos comienzan a trabajar con el nuevo sistema y lógicamente tienen dudas, encuentran cosas que no saben hacer o peor aún, encuentran errores. Esto, que en condiciones normales significaría una pequeña porción del trabajo habitual del Centro de Soporte, se puede convertir rápidamente en una avalancha de llamadas para las que, por si fuera poco, el técnico de soporte debe invertir mucho más tiempo en resolver porque a) no tiene la práctica y la formación habitual (es un producto nuevo) y b) necesita dar formación al usuario, dando una respuesta que al tiempo de resolver su problema, sea pedagógica para facilitar la incorporación del usuario en la nueva solución.
Para terminar de rizar el rizo, nos vamos a encontrar con que si el Centro de Soporte está colapsado atendiendo este tipo de interacciones, ¿cómo vamos a atender los contactos habituales, los que se refieren a otro tipo de servicios que incluso podrían ser más prioritarios? ¿Cómo atenderemos el Business as Usual?
En definitiva, vemos que para una situación más o menos excepcional como es el roll-out de un proyecto que tiene afectación a un elevado número de usuarios en un breve espacio de tiempo, debemos buscar soluciones adecuadas y excepcionales, huyendo de la solución tradicional de “lo pasaremos a través de soporte ” y construyendo una solución adecuada a esta situación de trato especial al usuario. (de hecho, a esta fase de los proyectos se le llama precisamente la fase de HyperCare)
Posiblemente pensarás que este tipo de roll-outs son poco habituales, que las cosas las hacemos de manera iterativa e incremental y que eso de un gran proyecto en modo cascada está pasado de moda. Te doy toda la razón del mundo, pero también es cierto que la gran mayoría de proyectos que significan sustituir una plataforma por otra, aquellos que tienen una puesta en marcha en formato big-bang, aquellos que ponen un producto mínimo viable en manos de un gran número de usuarios y todos aquellos que se ponen en marcha por motivos de extremada urgencia (por ejemplo, motivados por la activación de planes de continuidad) son candidatos a recibir este tipo de tratamiento.
¿Y cuál es la respuesta?
Bueno, en G2 llevamos tiempo ya dándole vueltas a esto y ayudando a nuestros clientes a crear esto que llamamos Unidades de Intervención Inmediata.
Para ello, nos inspiramos en el concepto de Arquitectura Efímera: son instalaciones que se diseñan y se piensan teniendo en cuenta que serán poco duraderas. Están orientadas a transmitir sensaciones, mensajes o emociones a través de las formas durante un breve espacio de tiempo (semanas o quizás meses), como puede ser una instalación artística en un aeropuerto, el stand alucinante que viste en la última feria a la que asististe o un hospital de campaña montado de manera urgente para atender una situación como la que estamos viviendo.
Estas arquitecturas efímeras están pensadas para transmitir un mensaje concreto durante un tiempo concreto, de la misma manera que en IT necesitamos transmitir un mensaje concreto (la tranquilidad de dar el paso a usar una nueva herramienta) durante un tiempo concreto (el que necesite el negocio hasta haber estabilizado el uso del nuevo sistema).
Así, nuestra propuesta es la generación de una plataforma de soporte completamente nueva, especialmente orientada a apoyar a los usuarios en la transición a esta nueva manera de trabajar que supone el despliegue del nuevo servicio y que se concibe desde el inicio como una plataforma efímera: se monta rápido, se usa rápido, se destruye rápido y sólo se paga por el tiempo que se usa.
El próximo Jueves 7 de Mayo de 2020 haremos un webinar explicando cómo montamos una de estas plataformas express para habilitar una Unidad de Intervención Inmediata. En esta charla veremos cuáles son las ventajas que le aporta al cliente, tanto al equipo de soporte, como al equipo de administración de herramientas y a los usuarios finales.
Si te ha picado el gusanillo de la curiosidad, inscríbete en nuestra página del G2 Atlassian Team y trae preparadas todas las preguntas que quieras plantearle al equipo que con gusto las resolveremos.
