Búsqueda


3 de febrero de 2016

Umbrales de Tolerancia - Aprendiendo a delegar

Un par de semanas después de hacer el taller que contaba en el post anterior pasé por otro cliente en el que estoy trabajando temas relacionados con la Gestión de Servicios. Empezamos a hablar y no se muy bien cómo, pero salió (de nuevo) el tema de la delegación y el reparto de responsabilidades, así que me saqué las cartas de la mochila y le enseñé a mi interlocutor lo divertido que es jugar a la baraja.

Siempre que sacas algo que se parezca a jugar en un entorno serio a la gente le cambia la cara… y es muy satisfactorio! Cómo me gusta sacar al niño que hay escondido en los mayores!

La primera impresión fue del tipo “humm que interesante! cómo mola!”, pero en cuestión de minutos la siguiente reacción fue “aquí eso no funcionaría ni de coña. Los jefes cambian de opinión constantemente y aunque te hubieran delegado una faena, seguro que cuando la vean te van a encontrar faltas y la vas a tener que hacer de nuevo”.

Que cosa más común, no?

Tenía una amiga que incluso lo había institucionalizado: metía errores adrede en los informes para que sus jefes los encontraran y los corrigieran, dejandola en paz con el resto del documento.

Ella añadía errores voluntariamente en su trabajo para saciar la sed de micro management de sus superiores y no tener que cambiar continuamente el trabajo realizado. Un honeypot para jefes!

La lección es rápida en este sentido: delegar es un trabajo bidireccional. Como manager tengo que hacer el ejercicio de “entregar” la responsabilidad del trabajo y la toma de decisiones, pero tambien tengo que hacer el trabajo de “recibir” los resultados. Como ejecutor de las tareas, tengo que hacer el trabajo de “aceptar” el trabajo y la toma de decisiones y el de “entregar” unos resultados adecuados.

Con el taller del Poker de Delegación hemos definido el terreno de juego al respecto de las decisiones y con la matriz RACI lo hemos hecho con respecto a las tareas… Desde el punto de vista del manager hemos organizado el DAR. ¿Y qué pasa con el RECIBIR?

Y aquí es donde entra en juego este nuevo concepto: los umbrales de tolerancia.


Todos tenemos unos determinados umbrales de tolerancia con respecto a la vida. Los hay que son más estrictos y los hay que son más laxos… los hay super minuciosos (los que viven en el 5º sigma de la vida) y los hay más relajados (los que viven en el 0,5 sigma de la vida).

Y tradicionalmente serán los del 5º sigma los que entran a saco en el micro management.

Si delegas un trabajo, tienes que estar dispuesto a que lo que recibas no sea exactamente lo que tu esperas. Habrá variaciones porque no es posible que hayas especificado exactamente tus deseos; habrá variaciones porque la forma de hacerlo del otro será diferente de la tuya; habrá variaciones porque la forma de entender el trabajo, la vida, la calidad o las herramientas del otro será diferente de la tuya.

Delegar significa estar dispuesto a recibir el trabajo diferente a como te lo esperabas.

Así que si delegas, prepárate a recibir cosas que no son exactamente lo que querias. Debes tener un margen de tolerancia adecuado. Si es demasiado abierto, no podrás asegurar que el trabajo se haga “a tu estilo” o “según las normas” o “de manera adecuada”. Pero si es demasiado cerrado, estarás machacando a tus compañeros permanentemente, repitiendo el trabajo y a la larga habrás minado totalmente la iniciativa y las ganas de autonomia de lagente.

Y cuando juegues al poker, el equipo pedira siempre un 1 - Tell, que básicamente significa “yo soy un mandado, a mi, lo que diga el jefe; las decisiones, que las tome él que para eso le pagan… que si no, siempre dice que lo hago mal y paso"

¿Has tenido un jefe del quinto sigma? ¿Cómo lo has vivido?

¡¡Pues no lo seas tu!!

PS:: Mis agradecimientos a Rui Soares por darme el empujón a comenzar a publicar mis primeros dibujos… quien sabe si no conseguiré algún día llegarle a la altura del tobillo! Obrigado pela inspiração!

Foto original de Krzysztof Puszczyński

1 de febrero de 2016

Acordando niveles de delegación

A medida que han ido pasando los años y he ido madurando como profesional, más le he ido encontrando sentido a todo el discurso de Paul Wilkinson quien, desde que yo conozco esto de la Gestión de Servicios, ha sido monotemático: lo importante son las personas [y desde 2004 que sigo oyendo el eco de sus palabras "las personas, las personas, …”]

Asi que me centré en las personas, en su trabajo, en su forma de entender lo que debían hacer y en su forma de aprender; y eso me llevó a pensar en asuntos como la motivación, la implicación y la asunción de responsabilidades, al tiempo que me llevaba a investigar mejores maneras de enseñar a las personas lo que deben saber para hacer su trabajo.

Yo lo que necesito es que ellos tomen las decisiones sin que yo tenga que entrar al micromanagement, dijo el CIO.

Recientemente, haciendo un trabajo con un cliente, llegamos al momento en el que se debían repartir las responsabilidades sobre un determinado conjunto de actividades, así que sacamos nuestra matriz RACI y comenzamos a repartir letras a diestro y siniestro, en una reunión con los implicados para que tuvieran voz y voto sobre este reparto. De repente llegamos a un momento en que el CIO dijo algo así como “pero yo lo que necesito es que ellos tomen las decisiones sin que yo tenga que entrar al micromanagement” y vimos claramente que nos faltaba algo.No es lo mismo una tarea que una decisión.

Menos mal que uno es un hombre de recursos y que en G2 siempre estamos aprendiendo cosas nuevas “para cuando hagan falta”, así que tiré de agenda y concreté una siguiente fecha para hacer un taller de “Póker de Delegación”, práctica que aprendí en las clases de Management 3.0 de las manos de Gabri Prat, Angel Medinilla y Angel Diaz-Maroto.

La idea que subyace detrás de este taller es identificar el conjunto de decisiones que se deben tomar en un determinado ámbito de actuación (dentro de un proceso, dentro de una metodología, durante la ejecución de un proyecto, etc) y llegar con la dirección a un acuerdo al respecto del modelo de delegación que vamos a utilizar para cada una de ellas. A modo de ejemplo, podríamos acordar que la decisión sobre si realizar o no gastos no presupuestados y con un importe superior a 2.000 € será tomada por la dirección consultando opinión a la persona que solicita el gasto, pero la decisión sobre qué miembro del equipo debe realizar las guardias se deja al equipo sin necesidad de aportar más explicaciones. Desde la orden impuesta y sin derecho a réplica hasta la delegación absoluta de una decision hay todo un continuo de posibles modelos, que el juego de Póker de Delegación establece en siete niveles.

Llegar a este tipo de acuerdos es de gran utilidad para un equipo de trabajo: nos ayuda a poner claras las reglas del juego, a saber cuándo tengo que pedir permiso y cuándo no, a visualizar claramente cuál es el terreno de juego y a reducir el tiempo necesario y el desgaste asociado a las reuniones. Un gran invento!!

Fue un taller fantástico, discutimos los puntos de decisión y el grado de delegación que quería el equipo y el que quería el responsable y nos encontramos en casos en los que el responsable queria dar más “correa” de la que el equipo quería asumir, y casos en los que el propio equipo pedía más y mientras ellos jugaban a tomar decisiones yo los observaba y sonreía porque estaba viendo a un equipo hacerse mayor.

Ahora ellos tienen un terreno de juego delimitado, que les indica para las 10 ó 12 decisiones más habituales que deben tomar en el desempeño de sus tareas cuál es el modelo de delegación que han acordado. Y si quieren cambiar ese modelo, como ahora está objetivado, sólo tienen que volver a jugar una partida a las cartas.

20 de noviembre de 2015

La muerte del proyecto o el Nirvana del Flow

Voy en el AVE volviendo de impartir un (otro) curso de Lean-IT; eso significa que llevo al menos tres días en los que mi cabeza sólo tiene un foco: el flujo, el waste, el valor, la Voz del Cliente y todo ese tipo de conceptos. Cuando consigo ese nivel de concentración pasan cosas interesantes, las ideas van sedimentando y de tanto explicar conceptos, otros más grandes se van consolidando encima de ellos.

Cierro los ojos y veo el flujo, como Neo. Me imagino una situación ideal, el Nirvana del flow y tiene pinta de un equipo multidisciplinar y no demasiado grande, bien avenido, motivados y con muchas ganas de cumplir su misión: entregar un software a su comunidad de usuarios que funciona, que hace lo que necesitan los usuarios incluso sorprendiéndoles con algún que otro truco sacado del sombrero de chistera del product owner o del UX Designer. Un software que va a la velocidad que quieren los usuarios, que está disponible, que no falla y que además cumple con las normativas y mantiene la seguridad en regla.

Pero ese equipo, además, resulta que se mantiene en contacto permanentemente con los usuarios, con los clientes (no obligatoriamente son la misma persona!) y de esa manera va incorporando nuevas funcionalidades y características al sistema de información y a la manera en que la empresa tiene de ponerlo al alcance de los usuarios (nuevos modos de contratación, nuevos modelos de facturación, nuevas formas de estar en contacto con los usuarios o incluso nuevas maneras de ayudar a los usuarios a sacarle el máximo provecho a tan preciado software).

¿Y sabes cómo empezó todo? Con una pequeña idea que probaron en un laboratorio de esos semestrales que la empresa facilita: “la semana que viene hay hackaton”, dijeron… se juntaron uno de marketing con un desarrollador, un experto en usabilidad y uno que trabaja en soporte, pero que le encanta jugar los fines de semana montando contenedores Docker, dejaron salir todo lo que tenian dentro y plof! Apareció una primera idea que parecía que podía tener éxito.

Cuando terminó el hackaton le mostraron a sus compañeros el resultado (basto, poco pulido, pero con una pequeña muestra de funcionalidad) y hubo quien apreció la viabilidad, así que la empresa decidió apostar y les pidió que en dos meses tuvieran montado un MVP (un Producto Minimo Viable) que pudieran presentar para ver si lo lanzaban.

A medida que pasaba el tiempo la lista de ideas iba creciendo: algunos usuarios piloto daban su opinión y encontraban nuevas maneras de usar la aplicación, muchos de los desarrolladores soñaban con nuevas funcionalidades y habia quien pensaba que añadiendo integraciones hacia otras partes de la organización podrían sacarle mucho más partido.

El equipo no era novato y ya había vivido esas sensaciones antes. Hicieron un gran esfuerzo para mantener a raya el WIP. Había que morder el pastel a pequeños trozos, masticarlos bien y hacer la digestión. Poco a poco aquello que era apenas una maqueta pasó a ser un MVP y el MVP fue creciendo hasta convertirse en un producto a secas y al cabo de los años hasta le quitaron el logo de “Beta” que tenía en la home page.

Durante todo este tiempo, el equipo permaneció relativamente estable. Algunos entraban y otros salían, pero el indice de rotación se mantuvo relativamente bajo. Sí que es cierto que cuando el producto comenzó a tener éxito, las nuevas ideas entraban mucho más rápido de lo que les daba tiempo a fabricarlas, así que trabajaron duramente para automatizar todo lo que podían para que los ciclos de desarrollo-integración-pruebas-aceptación-despliegue fueran lo más cortos posible, eliminando siempre que podían los frenos al flujo y habilitando bucles de feedback para que todo el equipo supiera en cada momento qué estaba pasando.

También es cierto que a medida que el volumen de usuarios iba creciendo el tamaño de las actividades de soporte y apoyo era cada vez mayor. Compredieron que no era sostenible así que decidieron poner en marcha todos los mecanismos que les facilitaran reducir este tipo de demanda: tolerancia cero a la deuda técnica, controles de calidad cada vez más exhaustivos, un interfaz de usuario brillante y fácil de usar, formación a los usuarios y una magnífica base de conocimientos que permitiera a los usuarios resolver sus dudas. Para terminar de poner la guinda a este pastel se inventaron el rol de “usuario ayuda a usuario” y habilitaron un foro de soporte en el que unos usuarios ayudaban a otros, todo inspirado por un potente motor de gamificación que permitía ganar puntos que podrías canjear en algunos establecimientos colaboradores (si ayudas en el foro puedes conseguir un pase VIP para el estreno de Star Wars!!).

Han pasado algunos años, y el producto sigue en constante evolución: siempre hay ideas nuevas, siempre hay necesidades nuevas y siempre hay formas nuevas de interactuar con el cliente, de forma que el equipo no se ha disuelto, siguen siendo aquellos que empezaron junto con otros que se han sumado a la aventura.

Lo que más me sorprende de todo esto es el cambio tan profundo de mentalidad: nunca ha habido un proyecto… nunca ha habido una planificación a un año vista ni tan sólo un roadmap (porque el roadmap lo hacen los clientes en as reuniones quincenales que tienen con el product owner. El roadmap nunca es a 5 años vista, sino que es a dos meses vista).

Esta manera de pensar ha sido “la muerte del proyecto” tal y como lo conocemos. Ahora ya no hay proyectos en esta empresa; lo que hay son experimentos que dan lugar a un ciclo de vida de producto (o de servicio, según lo quieras mirar). El proyecto tiene fecha de fin: acaba cuando se termina de construir, pero en este modelo no terminamos nunca de construir.

Hay algunos en el equipo que empiezan a dar señales de aburrimiento. Tienen ganas de nuevas aventuras, pero no piensan en cambiar de empresa. ¡Ni locos!

El mes que viene hay hackaton. ¿Te animas?

———
REFERENCIAS:

Para los conceptos de MVP y experiementación para incorporar la innovación, Lean Startup de Eric Ries
Para los ciclos cortos de desarrollo y contacto con el cliente, Agile
Para la automatización de los ciclos de desarrollo-pruebas-despliegue, Integración Continua de Jezz Humble
Para la cohesion de equipos multidisciplinares (de verdad), DevOps y Agile. Gene Kim y Jezz Humble
Para la motivación de los equipos y mantenerlos a tu lado, Management 3.0 de Jurgen Appelo
Para aprender más de todo esto sin tener que leerte la Biblioteca de Alejandria, G2 Gobierno y Gestión de TI

20 de octubre de 2015

Mi ruta en el Vision15

Ya está aquí el Vision15, la cita anual de todos los profesionales del mundo de la Gestión de Servicios; y con el congreso, la dura tarea de tener que seleccionar de entre la abundancia de ponencias aquellas que más me interesan para tener la agenda lista y no perderme nada.



Este año la cosa ha estado difícil y he tenido que tomar decisiones, dejando fuera de la agenda algunas ponencias que realmente me interesan, pero nadie dijo que la vida fuese fácil!!.
También he decidido dejarme algunos huecos libres: habitualmente me pasa en este tipo de congresos que tengo ganas de cruzar impresiones con gente o que alguien me pide un rato para intercambiar ideas y resulta que no puedo porque la agenda está a tope.

¿Que tienes ganas de que hablemos de algo concreto?
Pues me he dejado cuatro slots el primer dia y dos el segundo para comentar.

¿Que quieres una demo de Process Mining? 
Pues tenemos tiempo más que de sobras para mirarlo con calma.

¿Que quieres que nos tomemos una cerveza mientras hablamos de un plan de formación en DevOps? 
Tenemos sofás y tiempo. Yo pago la cerveza ;-)

El primer día a las 12:20 es mi ponencia sobre el uso de la Minería de Procesos en ITSM; luego por la tarde, a las 17:10 es la ponencia de Telefónica explicando su caso de éxito en el uso de la Minería de Procesos y el viernes a las 10:20 es la ponencia sobre integración de herramientas ITSM multifabricante, un caso muy interesante de integración en escenarios de outsourcing multiproveedor en el que G2 ha tenido una participación importante.

En fin, sin más preámbulos, esta es mi selección.

Jueves 12:
9:45 - 10:20 PP.1 El IT como bróker de Servicios
10:20 - 11:00 PP.2 Hacking Físico
11:00 - 11:40 CAFE
11:40 - 12:20 <<LIBRE>>

12:20 - 13:00 Posibilidades de uso en la minería de procesos 
13:00 - 13:40 Cómo conseguir un SLA adaptado
13:40 - 14:20 Ingeniería del Éxito
14:20 - 15:30 COCTEL

15:30 - 16:10 <<LIBRE>>
16:10 - 16:50 ¿Cómo es una organización Ágil?
16:50 - 17:10 <<LIBRE>>
17:10 - 18:00 Ojo de Halcón
18:00 - 18:40 Influencia del Factor Humano
18:40 - 18:50 Resumen jornada (SALÓN ATOCHA)
18:50 - 20:00 <<LIBRE>>


Viernes 13:
09:00 - 09:40 PP.3 Recuerdos del futuro presente
09:40 - 10:20 Aplicación de tecnologías analíticas
10:20 - 11:00 Integración herramientas ITSM multifabricante
11:00 - 11:30 CAFE
11:30 - 12:10 Hacia la excelencia con Lean(Out)sourcing
12:10 - 12:50 Cuarto y mitad de gobierno, por favor.
12:50 - 13:30 ITSM2020 nuevo modelo para la gestión de negocios
13:30 - 13:50 <<LIBRE>>
13:50 - 15:00 PP.4 PANEL DE EXPERTOS/MESA DEBATE
15:00 - 15:30 AC.4 Entrega de galadornes y cierre del Congreso
15:30 - 16:30 <<LIBRE>>


¿Cuál es tu selección? ¿Me pierdo algo que no debería?

16 de octubre de 2015

La minería de procesos en acción

Hacía mucho tiempo que tenía ganas de hacer esto. Un pequeño vídeo que demostrara las capacidades de la minería de procesos de tal forma que te pudieras hacer una idea más clara de lo que se puede llegar a conseguir con este tipo de herramientas.

La semana pasada organizamos en G2 el evento Business Process Transformation, donde explicamos varias técnicas que nos permiten facilitar la mejora continua y la transformación de los procesos de negocio, y entre ellas hablamos de la minería de procesos. Un “problemilla” técnico deslució mucho una demo en la que tenía puestas muchas ilusiones así que he aprovechado un rato que tenía disponible para preparar este video. No soy un profesional de la edición, así que ha quedado como ha quedado… pero estoy seguro de que te activará las neuronas y te dejará imaginando cómo podrías aplicar este tipo de ideas en tus procesos.

Sólo una pista a tener en cuenta: cuando hablamos de “proceso” hablamos de “cosas que cambian en el tiempo”… así que podemos aplicar estas técnicas para analizar la evolución en el tiempo de cualquier concepto. Por ejemplo, mi compañero Jorge hizo una extracción de datos de LinkedIN para representar el mapa de cuáles son los caminos más exitosos para que una persona se convierta en CIO. Mi amigo Mariano quiere utilizarlo pasa estudiar el comportamiento de los alumnos en los MOOC de la Generalitat y yo lo he utilizado para estudiar el proceso de conformación de facturas o el factor de rotación de personal de un outsourcer del que no se mucho más que el rastro que dejan sus operadores en mis herramientas de gestión.

Abre tu mente, imagina cómo podrías utilizarlo y ponte en contacto con nosotros en http://www.gedos.es si quieres un piloto o una prueba con tus propios datos. ¡Aprender es gratis!

23 de julio de 2015

DevOps Foundations

Hace sólo un par de días se ha publicado el State of DevOps Report 2015, un estudio que cada año llevan a cabo los equipos de The IT Revolution y Puppet Labs. Este año se repiten algunas de las conclusiones a las que se había llegado en años anteriores, pero con unas cifras aún más espectaculares todavía: los dos primeros Key Findings son para dejar con la boca abierta a cualquiera:

  • High-performing IT organizations experience 60 times fewer failures and recover from failure 168 times faster than their lower-performing peers. They also deploy 30 times more frequently with 200 times shorter lead times. Failures are unavoidable, but how quickly you detect and recover from failure can mean the difference between leading the market and struggling to catch up with the competition.

  • Lean management and continuous delivery practices create the conditions for delivering value faster, sustainably. Manufacturing was revolutionized by the application of lean principles in the 1980s. Today, it’s IT’s turn to go lean. When you apply lean management and continuous delivery practices to software delivery, you get the same results — higher quality, shorter cycle times with quicker feedback loops, and lower costs. And the benefits don’t stop there: These practices also contribute to creating a culture of learning and continuous improvement, lower levels of burnout, and higher organizational performance overall.


La promesa de ser capaz de llevar valor al negocio en forma de funcionalidades TIC 30 veces más frecuentemente, 200 veces más rápido y de una forma 60 veces más estable no puede dejar indiferente a nadie; tampoco a nosotros. Así mismo, la importancia de la utilización de los princiios Lean-IT es algo que llevamos predicando desde hace años, así que esto tenía que pasar… estaba en nuestro roadmap.

Durante el último mes el equipo G2 ha estado trabajando a toda máquina para sacar adelante la primera edición de nuestra nueva incorporación en el catálogo de formación: el curso DevOps Foundations, una experiencia de 20 horas en la que combinamos unas 5 horas de teoría y le sacamos brillo a nuestros skills más techies con unas 15 deliciosas horas de práctica.

Este curso ha sido perfilado después de las conversaciones con varios clientes, en las que hemos discutido cuáles debían ser los puntos a tratar en los diferentes tipos de sesión formativa, con diferentes audiencias y diferentes necesidades. De esta manera, el paquete formativo ha quedado compuesto por tres elementos fundamentales:

  • Una Keynote de una hora orientada especialmente al cuadro directivo, en la que explicamos los conceptos fundamentales y nos centramos en dar a conocer los beneficios para el negocio y para el equipo de IT del uso de estas prácticas.
  • Una Master Class de cuatro horas dirigida al equipo de mandos intermedios, gestores de servicio, jefes de proyecto y líderes de equipo. En esta sesión explicamos los conceptos teóricos fundamentales y lanzamos los punteros hacia los diferentes cuerpos de conocimiento que nos permitirán comprender la esencia de las prácticas DevOps. 
  • Un curso DevOps Foundations de cinco horas de teoría y 15 de práctica dirigido especialmente al equipo técnico (tanto de Desarrollo como de Sistemas u Operaciones ). En este curso las horas de teoría explican los patrones y antipatrones presentes en las prácticas DevOps, el por qué las cosas se hacen así y las líneas teóricas que dirigen estas prácticas. La parte práctica permite al alumno comenzar con un desarrollo simple (el foco no es el desarrollo ni las prácticas de desarrollo) e ir implementando en cada sesión los automatismos para cada paso, de forma que el último día habremos completado un ciclo completo de desarrollo en el que hemos automatizado:
    • El control de versiones
    • El Build
    • Las pruebas unitarias
    • La conexión con el repositorio de binarios
    • La gestión de la configuración
    • Las pruebas de integración
    • Las pruebas de carga
    • El despliegue al entorno de producción
    • La monitorización de los sistemas
    • La monitorización de la aplicación
    • La representación en el dashboard y la correlación con los despliegues

Hemos impartido la primera sesión y los resultados han sido muy buenos: los alumnos pudieron tener una visión global de las posibilidades que brinda el uso de DevOps, ganaron los conocimientos en fundamentos para comenzar a hacer sus primeras automatizaciones del pipeline de despliegue de aplicaciones y aprendieron las ventajas que nos aporta el adoptar una perspectiva de trabajo en la que los equipos de Desarrollo, Testing y Operaciones se alinean en un flujo común.

Obviamente, también hemos jugado....


Queda abierta la puerta para el desarrollo de un curso de nivel Advanced en el que se expandan los conceptos de testing y QA, se incorpore todo el conjunto de herramientas de ticketing y la trazabilidad de acciones y podamos ver tambien el aprovisionamiento y aseguramiento de la calidad de elementos de infraestructura infraestructuras.

Tambien vemos necesaria la creación de un nivel FusionSM, en el que se exploren las adaptaciones necesarias en los modelos de gestión y gobierno actuales para el despliegue “sin sangre” de estas metodologías al tiempo que se discuta el impacto de la externalización y tipologías de contrato. ¿Cómo conecta esto con la ISO 20.000 o con mi modelo actual basado en ITIL(r)? ¿Qué impactos tiene sobre la Gestión de la Seguridad y el cumplimiento legal? ¿Qué ocurre cuando el desarrollo está externalizado?. Siguiendo los principios de la Gestión Lean de Servicios, lo haremos si hay demanda...

¿Te imaginas hacer un push a tu sistema de control de versiones y que tus modificaciones pasen a producción de forma automatizada, con los controles comprobados, cumpliendo los requerimientos de tu Gestión de Cambios y en poco tiempo? ¿Se lo imagina tu negocio?