Búsqueda


Mostrando entradas con la etiqueta Metodologías. Mostrar todas las entradas
Mostrando entradas con la etiqueta Metodologías. Mostrar todas las entradas

4 de diciembre de 2023

Respect for downstream

un dibujo de un rio que fluye, en algún punto hay una parada porque un equipo está planificando cuánta agua debe bajar. El equipo que planifica ES diverso, tanto en razas como en generos, visten de manera informal y alegre. El rio está en un entorno natural y virgen. Pájaros volando y una puesta de sol es ok.

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:

  1. ¿Qué factores influyen en la predictibilidad de tu(s) equipo(s)?

  2. ¿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?

  3. ¿Cuál es el valor del refinamiento en todo esto?

  4. Estimar o no estimar... esa es la cuestión.

  5. ¿Tiene sentido generar ocupación al 100%? ☠️

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

10 de julio de 2015

… y no hay mucho más que decir…



  1. Crear constancia en la mejora de productos y servicios, con el objetivo de ser competitivo y mantenerse en el negocio, además proporcionar puestos de trabajo.
  2. Adoptar una nueva filosofía de cooperación en la cual todos se benefician, y ponerla en práctica enseñándola a los empleados, clientes y proveedores.
  3. Desistir de la dependencia en la inspección en masa para lograr calidad. En lugar de esto, mejorar el proceso e incluir calidad en el producto desde el comienzo.
  4. Terminar con la práctica de comprar a los más bajos precios. En lugar de esto, minimizar el costo total en el largo plazo. Buscar tener un solo proveedor para cada ítem, basándose en una relación de largo plazo de lealtad y confianza.
  5. Mejorar constantemente y por siempre los sistemas de producción, servicio y planeamiento de cualquier actividad. Esto va a mejorar la calidad y la productividad, bajando los costos constantemente.
  6. Establecer entrenamiento dentro del trabajo (capacitación).
  7. Establecer líderes, reconociendo sus diferentes habilidades, capacidades y aspiraciones. El objetivo de la supervisión debería ser ayudar a la gente, máquinas y dispositivos a realizar su trabajo.
  8. Eliminar el miedo y construir confianza, de esta manera todos podrán trabajar más eficientemente.
  9. Borrar las barreras entre los departamentos. Abolir la competición y construir un sistema de cooperación basado en el mutuo beneficio que abarque toda la organización.
  10. Eliminar eslóganes, exhortaciones y metas pidiendo cero defectos o nuevos niveles de productividad. Estas exhortaciones solo crean relaciones de rivalidad, la principal causa de la baja calidad y la baja productividad reside en el sistema y este va más allá del poder de la fuerza de trabajo.
  11. Eliminar cuotas numéricas y la gestión por objetivos.
  12. Remover barreras para apreciar la mano de obra y los elementos que privan a la gente de la alegría en su trabajo. Esto incluye eliminar las evaluaciones anuales o el sistema de méritos que da rangos a la gente y crean competición y conflictos.
  13. Instituir un programa vigoroso de educación y auto mejora.
  14. Poner a todos en la compañía a trabajar para llevar a cabo la transformación. La transformación es trabajo de todos.

William Edwards Deming, 1986

8 de julio de 2015

Jugando a Lean Lens con el itSMF

Una de las últimas adquisiciones de G2 en materia de juegos didácticos ha sido Lean Lens, un juego creative commons desarrollado por Andrea Darabos y Bazil Arden en 2014 y que presentaron en las jornadas CAS2014 que se desarrollaron en Barcelona el año pasado.

El juego es una representación en forma de obra de teatro en la que hasta 9 grupos de personas interpretan diferentes escenas de la vida cotidiana de las TIC, desde las conversaciones con Negocio para discutir nuevas funcionalidades en la web hasta la resolución de correctivos afectando a diferentes partes de la aplicación. En cada una de las escenas intervienen diversos roles (el Stakeholder, el developer, el tester, el project manager, el tecnico de soporte, etc.) e incorporamos un rol especial en cada grupo que hace las labores de observador. El observador tiene como misión analizar cómo se desarrolla la escena e identificar los diferentes tipos de waste que se generan durante la actividad, de forma que posteriormente se discute con el equipo y se llega a un consenso sobre los derroches identificados.

Cuando se han escenificado todas las escenas, los observadores rellenan el “Mural del Waste”, que hace patente la presencia de los 8 tipos de derroche en cada una de las etapas de la cadena de valor de las TIC, al tiempo que se plantean las diferentes soluciones y formas de mejorar el escenario propuesto.

El juego facilita la comprensión de los diferentes tipos de derroche, la colaboración en equipo y sobre todo demuestra cómo un Mural del Waste puede convertirse en una herrmaienta importantísima (y visual) a la hora de potenciar las actividades de mejora continua dentro de las organizaciones.

Algunos de los comentarios que surgieron en esta edición de Lean Lens con el itSMF España en el Curso de Verano fueron

Lo que estamos representando aquí es tan familiar que le podríamos poner nombre y apellidos a cada post-it que estamos pegando en el Mural del Waste


Pero… ¿Vamos a mejorar ya, o nos quedamos mirando esto como si nada?


Nos ha parecido tan evidente y tan típico lo que estabamos representando que nos da la sensación de que nos vamos a repetir mucho al poner los derroches en el Mural del Waste


Una mañana intensa en la que hemos aprendido mucho; los alumnos se han llevado nuevas técnicas para hacer aflorar las ineficiencias en su organización y para apalancar los planes de mejora continua y yo… pues yo me he llevado un paquete de mejoras a plantearle a Andrea sobre el juego y un paquete de experiencia adicional para mi mochila.

8 de junio de 2013

El punto débil de DevOps

Hace algún tiempo leí el libro The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, una novela muy inspiradora al respecto del uso de las técnicas Lean en el mundo de las operaciones IT y su fuerte relación con el mundo del desarrollo y DevOps. Como novela es entretenida, explica y ejemplifica los conceptos fundamentales y es un cuento de hadas, donde todo va de acuerdo a lo que el guionista ha pensado y desemboca en un fantástico final feliz. Desde luego, no creo que sea necesario recordarles a los lectores que lo que pasa en esos mundos imaginarios no siempre se parece a la realidad y al contrario que en el mundo de Fantasía, a este otro lado a veces las cosas no son tan maravillosas. (Nadie piensa que los lobos hablan después de leer Caperucita, verdad??)

En un momento del libro, el protagonista está reflexionando al respecto de cómo acelerar el ritmo de pasos a producción en el equipo de desarrollo (se han puesto el objetivo de conseguir diez –si, 10- despliegues al día) justamente para seguir los consejos que daba el equipo de Flickr en su conferencia de 2009. Parte de esa reflexión le lleva a decir la frase

 

Until code is in production, no value is actually beign generated, because it is merely WIP stuck in the system

o sea… hasta que el código no está en producción no se está generando realmente valor porque es únicamente WIP atascado en el sistema

Claro, el paralelismo con el libro de Service Operations de ITIL® y el sentido de que no es hasta este momento cuando realmente se entrega valor al usuario del servicio es directo… pero mi reflexión posterior me llevó un poco más adelante: recordé aquel post que había escrito al respecto de que en realidad el valor de un servicio no es como dice ITIL® el equivalente a Utilidad x Garantía, sino que debemos incorporarle un factor más: el uso.

Así, pues, y siguiendo con la reflexión, tanto da que seamos capaces de hacer 1, 10 ó 100 despliegues al día, que si el usuario no es consciente de lo que pasamos a producción y no es capaz de usar las nuevas funcionalidades que estamos incorporando, en realidad IT habrá generado su parte de valor pero si damos un paso atrás e intentamos encontrar dónde está el valor aportado/generado por el negocio no lo encontraremos: así, mi propuesta de modificación a la frase es

Until code is properly USED to GENERATE the EXPECTED VALUE, it still will be WIP stuck at any other point of the system

o sea.. hasta que el codigo no sea USADO de forma adecuada para GENERAR el VALOR ESPERADO, seguirá siendo WIP atascado en cualquier otra parte del sistema.

Intenté contactar con Gene Kim, el autor del libro, a ver qué opinaba del tema, pero es un hombre ocupado y no he conseguido llamar su atención… pero sí que hubo otra persona que dio su punto de vista: Byron Miller opinó al respecto diciendo que en el fondo todo lo relacionado con formación, cambios culturales y modificación de procesos debe ser también considerado WIP.

Vamos a ver si soy capaz de explicar hasta qué punto es importante esto: dentro de las metodologías ágiles (Scrum, XP, etc.) hay un aspecto que es fundamental y es lo que llaman la definición de “HECHO”. Sin esta definición no funciona nada… y es algo que está aquí para arreglar gran parte de los problemas que tenemos en las TIC.

Es necesario que todo el equipo que participa en la cadena de valor del servicio llegue a un consenso al respecto de qué significa decir que una petición del cliente esté HECHA. Históricamente, cada uno de los diferentes silos que participan en la entrega de esta petición ha interpretado como HECHO el momento en que lo da por terminado (según su visión especializada de las cosas) y lo pasa al siguiente elemento en la cadena. Así, el analista da por hecho el análisis cuando lo pasa a desarrollo, el desarrollador da por hecho el código cuando lo pasa a QA Testing y toda la división de desarrollo da por hecho el programa cuando lo entrega a producción.

Pero la cosa no debe de ser así. Todo el equipo, completo, debe tener una definición común de hecho. ¿Cuándo está hecho el evolutivo? ¿Cuando entrego a Ops? ¿Cuando lo despliego? ¿o cuando he conseguido que los usuarios lo usen adecuadamente?

Desde el punto de vista del negocio, claramente el evolutivo está hecho cuando entrega el valor prometido y eso sólo se hace mediante el USO, por lo tanto HECHO incluye también la formación, el cambio cultural, la modificación de los procesos de negocio, etc etc etc.

Así que, desde luego, todo ese aspecto soft de la entrega de servicios forma parte del WIP.

Ahora vamos a darle otra vuelta de tuerca a todo esto. Si pensamos en la teoría de las limitaciones, la propuesta de Goldratt dice en parte que dado un sistema, siempre existirá un cuello de botella. Es más, resulta que cualquier mejora que pretendamos aplicar al sistema debe de ser directamente sobre el cuello de botella, ya que si actuamos antes el resultado será un atasco monumental a la entrada del cuello de botella; y si actuamos después nos encontraremos con que no servirá de gran cosa puesto que será la limitación actual del sistema la que no esté entregando suficiente “ritmo” a las piezas que se encuentran detrás de ella. Así, cualquier mejora introducida en el sistema si no es en el cuello de botella, o bien no tiene efecto o bien contribuye a empeorar el rendimiento global del sistema.

Ufff… esto es complicado, pero va cogiendo sentido!

¿Qué pasa cuando agilizamos el desarrollo y no agilizamos los pasos a producción? Pues que se produce un atasco monumental en los PaP, y eso provoca… que la gestión de cambios es “el malo”, el que no deja pasar las cosas a producción, el que es un freno para la organización. Y qué pasa cuando agilizamos también el paso a producción? Que nadie se explica cómo puede ser que no se usen las nuevas funcionalidades de las aplicaciones y que cuando se usan el equipo de soporte y apoyo funcional no da abasto (hemos movido el atasco a otro sitio).

Si juntamos una definición de HECHO con visión completa, en la que el evolutivo está hecho cuando se está usando y está generando valor a la organización, con la “prisa” por adoptar metodologías DevOps que nos permitan hacer diez despliegues al día, nos encontraremos con que ahora el cuello de botella es el usuario, que no es capaz de absorber tanto cambio de forma continuada o la organización no permite que el usuario dedique el tiempo necesario a formación para ser capaz de absorber los diez despliegues al día. facebookApp

En mi opinión, el ejemplo más claro de esta situación es el mundo de las Apps, en las que se despliegan (no 10 veces al día, pero hay algunos que despliegan al menos una vez al mes) nuevas funcionalidades que son documentadas en un pequeño “Read-Me” o similar que nadie se lee. El resultado? Pilas de nuevas funcionalidades que nadie usa… waste por todas partes porque no se está entregando valor con ese código desplegado, pero un equipo de desarrollo orgulloso de haber conseguido los hitos previstos.

De esa forma, todo vuelve a girar alrededor del “activo más importante de las empresas”: las personas. Las personas son la pieza sobre la que no tenemos capacidad de automatización y por lo tanto será el elemento que siempre será nuestro cuello de botella y sobre el que debemos trabajar en primera instancia, porque de lo contrario lo único que estaremos haciendo será cambiar el atasco de sitio (práctica muy habitual en las organizaciones estructuradas por silos, donde no hay una visión de conjunto: “yo ya he hecho mi parte… el resto no es cosa mía” y donde, además, se ponen objetivos por cumplimientos parciales)

En fin, todo esto ha sido una reflexión provocada por un párrafo en una novela… así que es probable que esté profundamente equivocado. ¿Tienes experiencias al respecto? ¿Trabajas en una empresa DevOps y nos quieres contar cómo transmites todo el cambio a la comunidad de usuarios?

¡Usa los comentarios, por favor!

Postdata: Ops! Por cierto… si somos capaces de hacer diez despliegues al día de correctivos, adelante!!! La comunidad de usuarios y los equipos de soporte lo están deseando! Es decir, todo este discurso es válido cuando el cuello de botella es el usuario por su ritmo de adoptar/asimilar/aprender las nuevas funcionalidades que estamos desplegando. Pero si hablamos de demanda fallo, el discurso es completamente distinto!

24 de abril de 2012

Lean Management: la clave para un outsourcing de primera clase

El 2011 ha sido el año de Lean-IT: han aparecido publicaciones y foros, se ha realizado el I European Lean IT Summit, han surgido de la nada nuevos esquemas de certificación y se han impartido clases y dado conferencias por todo el país.

Esto probablemente ha sido motivado porque se acabaron definitivamente las vacas gordas y ahora nos enfrentamos a una larga temporada de vacas flacas; los directivos buscan maderos a los que agarrarse y poder seguir entregando los niveles de servicio demandados pero, eso sí, dentro de unos niveles de calidad aceptables y, sobre todo, dentro de los márgenes económicos en los que se pueden mover en esta nueva situación.

El Pensamiento Lean se mueve siempre basado en una serie de principios, que podemos resumir en el siguiente gráfico:

Principios_Lean

Por otra parte, un proveedor de servicios IT en modalidad de outsourcing o prestación de servicios continuados se encuentra en estos momentos con la necesidad acuciante de cumplir con las necesidades del cliente (representado principalmente en el modelo tradicional de entrega de servicios por “cumplir las exigencias del contrato” o “satisfacer los SLA”), posiblemente reducir los importes de estos contratos (hacer más con menos) y por otra parte satisfacer sus propias necesidades de rentabilidad (mantener los márgenes de beneficio).

Así, nos encontramos en una situación en la que por una parte la demanda tira del beneficio hacia abajo y mantiene, si no aumenta, la tensión sobre las exigencias de nivel de servicio; por otra parte, el proveedor se ve en la obligación de mantener el beneficio obtenido por la prestación, por lo que alguno de los puntos del triángulo de los servicios se verá afectado.

Pero esto no debe ser necesariamente así. La primera lectura es que si disponemos de menos financiación, habrá que dar menor rendimiento o peores niveles de servicio, y es aquí donde Lean-IT nos puede ayudar especialmente. Veamos cómo siguiendo los diferentes principios que hemos presentado anteriormente:

IDENTIFICAR EL VALOR: Lean asume que los atributos de un producto o servicio que establecen el valor aportado para el consumidor son variables y que por lo tanto debemos realizar una alineación permanente con estos atributos. Eso repercute directamente en la necesidad permanente de contacto con el cliente/consumidor para identificar en cada momento qué es lo importante, ajustando la producción a esas necesidades. Desde el punto de vista de un proveedor de servicios, esto significa que necesitamos contratos lo suficientemente flexibles como para soportar fácilmente variaciones en las necesidades, eTriangulo_Leann los ámbitos, en los niveles de servicio entregados y, lógicamente, en los niveles de facturación y por lo tanto se debe trabajar en equipo para formalizar estos contratos ágiles con mecanismos de facturación variable. Por otra parte, un proveedor de servicios con espíritu Lean no sólo se centrará en el cumplimiento del contrato; pondrá su interés en el propósito de su cliente… ¿Recuerdas la definición de servicio según ITIL? “Un medio de generar valor al cliente facilitando los resultados que desea obtener…” esto es lo que significa ese interés en el propósito: entender y facilitar los resultados que el cliente desea obtener.

IDENTIFICAR, REPRESENTAR Y OPTIMIZAR EL FLUJO DE VALOR: Como dicen Mike Rother y John Shook en su libro “Learning to See”, siempre que hay un producto para un cliente, hay un flujo de valor. El reto consiste en verlo. Este principio Lean hace aflorar uno de los principales problemas organizativos que existen: la jerarquía es a nivel funcional, a nivel de unidades organizativas mientras que el flujo de valor hacia el cliente/consumidor es transversal y cross-funcional. Cuando se aprende a representar y ver el flujo de valor se puede detectar una multitud de actividades que se realizan que no aportan nada a esos parámetros o atributos de valor que hemos identificado en el punto anterior: es lo que el Pensamiento Lean denomina waste (desperdicio, ineficiencia, derroche) y que nos permitirá optimizar el flujo, dejándolo libre de todas estas actividades que sólo incorporan más tiempo de proceso, más volumen de actividad y más ineficiencia global. Aquí es donde entra en juego la posibilidad de hacer más con menos, hacer más de lo que aporta valor, más de lo que al cliente le sirve para lograr su propósito, con menos consumo de recursos, con menos ineficiencia y con menos actividades que no aportan valor. En el fondo, aquí de lo que estamos hablando es de poder lograr los objetivos marcados utilizando menos recursos con lo que podremos ajustar el presupuesto tal y como nos lo exigen los tiempos que corren, al tiempo que podemos mantener los niveles de servicio esperados.

FACILITAR EL “PULL”: Durante las sesiones de formación en Lean Thinking es habitual realizar simulaciones o juegos de mesa en los que se demuestran algunos de los conceptos explicados durante las clases. Uno de estos juegos consiste primero en simular un sistema basado en PUSH (empujar la producción hacia el mercado, producir en base a previsiones y acertar a que el producto se consuma en el momento esperado) y posteriormente otro sistema basado en PULL (en el que es la demanda y el consumo el disparador de la producción, principio básico para la producción Just in Time). Los resultados son espectaculares en estos juegos, donde llegamos a ver incrementos en el resultado final (no sólo en la productividad, sino en los resultados económicos finales: se produce ajustadamente a lo que se puede vender y por lo tanto no hay sobrecostes de almacenamiento, sobre-stock, materiales, etc..)

Pero nosotros, en IT, no nos movemos en una cadena de montaje. Lo nuestro no es una producción en serie con poca variabilidad en el producto entregado y por lo tanto las herramientas Lean no se pueden aplicar directamente sin modificaciones; nos movemos en el mundo de los servicios, intangibles, variables y con una característica fundamental que los hace únicos: la coproducción. El usuario sincroniza el acto del consumo con el acto de la producción que se realiza desde el área de IT (no en el 100% de los casos, pero sirve como generalización). Es por eso que en esta situación el PULL o acto de “estirar de la cadena de producción” se convierte en un factor crítico. Debemos facilitar el consumo y debemos conseguir alisar en lo posible la demanda.

En el caso de nuestro hipotético proveedor de lo que podremos llamar “LeanSourcing”, el hecho de estar permanentemente cerca del cliente, co-planificando la demanda y pensando con él en maneras de conseguir que haya el mínimo posible de picos, hace que el proveedor pueda organizar mucho mejor los recursos necesarios, entregar los recursos adecuados, planificar sus propias necesidades de contratación y de formación, racionalizar, en definitiva, sus costes.

Un ejemplo interesantísimo de este caso se produce cuando vemos a empresas que tienen externalizado su AM&O (Application Management & Operations ) y que colaboran con su proveedor para planificar la demanda de nuevos desarrollos y evolutivos en ventanas a 3 meses vista. Cuando esta planificación se hace de forma apropiada, el cliente consigue a las personas más adecuadas para cada uno de los trabajos y el proveedor, con un conocimiento previo de la demanda que tendrá del cliente, puede planificar mejor sus equipos e incluso planificar las necesidades de contratación o de formación que tendrá.

BUSQUEDA DE LA PERFECCION: Este principio asume que la perfección es un estado utópico, inalcanzable; no por ello debemos tirar la toalla, sino que debemos iniciar actividades de adaptación continua a las necesidades de ese “blanco móvil” que es el valor desde el punto de vista del consumidor. Bajo este paraguas aparecen las herramientas de mejora continua, tanto del sistema de producción como del producto/servicio producido.

Aquí aparece el trabajo en equipo, el aprovechar la inventiva, imaginación y conocimiento de todo el equipo, hacer participar a los diferentes integrantes del flujo de valor en las propuestas de mejora y un concepto importantísimo en toda iniciativa de gestión Lean: Walk the Gemba, pasear, visitar, conocer cómo se realiza el trabajo de verdad (Gemba es una palabra japonesa que tiene el significado de “lugar donde se encuentra la verdad” y “lugar donde se produce la acción”). Hablando con expresiones más castizas, comprenderemos mejor cuáles son las necesidades de mejora del sistema productivo si somos capaces de ponernos en la piel de cada uno de los que intervienen en el flujo de valor; y podremos comprender las necesidades de mejora del producto/servicio que entregamos si nos ponemos en la piel del consumidor/usuario que utiliza nuestros productos/servicios.

Otro ejemplo especialmente interesante del grado de comprensión que se adquiere cuando se vive el Gemba es el caso de una empresa en la que, después de varias sesiones destinadas a plantear las mejoras necesarias en la gestión de facturas de proveedores, el analista se pasó una mañana validando facturas y conformando albaranes. Mientras lo iba haciendo, iba exclamando “¡Pero este trabajo lo he hecho ya dos veces!”, “¡Aquí me faltaría un campo para registrar esta información!” o “¡Necesito una consulta que agilice este paso!”

consumo_leanUn LeanSourcer no desarrollará su trabajo de manera deslocalizada sin exigirle a su cliente que los equipos de trabajo puedan visitar, ver y vivir de vez en cuando el Gemba del usuario, sentir sus problemáticas y poder así plantear mejoras a los servicios entregados.

En conclusión, cumplir con la exigencia que hacen los clientes hoy en día de hacer más con menos sin perder la calidad es un reto que se puede conseguir traduciendo la consigna en “hacer lo necesario, bien a la primera, y con el menor consumo de recursos posible”, que es justamente el leitmotiv de la gestión Lean, aunque para ello es preciso que ambos componentes de la ecuación, cliente y proveedor, trabajen en equipo para conseguirlo. Se construye de esta forma un sistema productivo en el que todos ganan y, en esta relación win-win se consolidan relaciones de larga duración en las que el cliente y el proveedor se convierten en partners.

NOTA: Este artículo se publicó por primera vez en la revista Service Talk de Abril 2012 (Año VII – Edición I), publicada por el itSMF de España.

8 de septiembre de 2011

Una grata sorpresa

Hace poco tuve una avería de hardware con mi portátil y, como está en garantía, llamé al servicio técnico donde diagnosticaron y enviaron a un técnico para que sustituyera unas piezas. La misma tarde que vino el técnico me llamó por teléfono la chica que me había atendido en el ServiceDesk para confirmar si el técnico había llevado a cabo la intervención y para saber si podía dar el caso por cerrado. Al decirle que sí, me indicó que me llegaría una encuesta de satisfacción por correo y que si no me importaría rellenarla.

Al día siguiente me llegó la encuesta de satisfacción donde me preguntaban una serie de asuntos relativos al soporte, al técnico, etc… pero la última pregunta fue una muy grata sorpresa: destilaba pensamiento Lean por todas partes.

La aportación de valor al cliente se resumen en el Pensamiento Lean en una serie de principios que, expresados por la voz del cliente, suenan como

  • Resuelve mi problema completamente
  • No malgastes mi tiempo
  • Dame exactamente lo que quiero
  • Agrega valor allá donde yo quiero
  • Resuelve mi problema cuando yo quiero

Las preguntas de la encuesta iban enfocadas a saber si se había resuelto mi problema correctamente, en plazos, en el momento que yo había indicado… preguntas habituales para saber si estoy o no satisfecho con el soporte dado. Pero la última pregunta estaba orientada a saber si yo había percibido que habían malgastado MI tiempo… el tiempo del consumidor, algo cada vez más precioso y que pocas compañías se preocupan de cuidar.

encuesta_lean

5 de abril de 2011

Conceptos LEAN : YOKOTEN

dragonball2La palabra japonesa Yocoten significa “despliegue horizontal”. Está directamente relacionada en el mundo LEAN con el acto de aprender de nuestros éxitos (en contra del tradicional “aprender de nuestros errores”, que también tiene su sentido). El significado que hay detrás de este término es el comprender cuáles son las prácticas que hemos llevado a cabo en el diseño, fabricación o entrega de un producto (bien o servicio) y ser capaces de “replicar” ese éxito.

Este aprendizaje continuo sobre cuáles son las prácticas que nos han funcionado bien no sólo es aplicable internamente en una organización, sino que también las podemos extrapolar al exterior, a otras organizaciones (sean o no de nuestro sector) y eso es lo bonito del tema… el conocimiento transversal, el aprender de los demás y el llevar adelante nuevas iniciativas de cambio y mejora inspiradas en éxitos de otros (contribuyendo de esta manera al crecimiento de la sociedad en su conjunto).

Así, cuando leemos los libros en los que se describe el Sistema de Producción de la Toyota, vemos algunas prácticas que a ellos les han resultado provechosas y las trasladamos a nuestra organización, estamos haciendo Yokoten; cuando entendemos cuáles han sido los factores de éxito de la implantación de un servicio en una rama de la compañía y la trasladamos, comunicamos, enseñamos y aplicamos finalmente en las otras ramas, estamos haciendo Yokoten; cuando una administración pública aprende de otra administración pública o es capaz de replicar ejemplos de éxito en sus diversas sedes, departamentos, consejerías, Ayuntamientos… estamos haciendo Yokoten.

Esto enlaza de perlas con el mundo de la Gestión de Servicios TI, ya que para empezar tenemos toneladas de “marcos de referencia” y de “prácticas recomendadas”; cuando entendemos quénos aporta ITIL® y aplicamos algunas de sus enseñanzas en nuestra organización, estamos practicando Yokoten.

Ahora bien, para eso (sobre todo internamente) es necesario no sólo aprender de nuestros errores, sino aprender de nuestros éxitos y para ello necesitamos comprender qué componentes o factores de un servicio que damos son los que contribuyen de forma importante a que éste sea un buen servicio:¿POR QUÉ NUESTRO SERVICIO ES BUENO?

Ahora, como dicen los “Lean Thinkers”, ves y mira (Go see), porque seguramente la clave de por qué tu servicio es bueno no la encontrarás en tu despacho: la verás en el lugar donde se trabaja, donde se produce el servicio, donde se consume el servicio y sobre todo en las manos de aquellos que usan tu servicio para un propósito superior. Sal fuera, observa, pregunta, muestra respeto y aprende.

29 de agosto de 2008

British Airways con viento de cola

Hoy he leído un artículo del CIO Update que hablaba sobre un caso de estudio de aplicación de Lean IT en British Airways. Me ha llamado la atención por varios motivos; el primero, porque en el evento de Abril del itSMF-NL tuve la ocasión de conocer a Ian Clayton que dio varias conferencias sobre modelos basados en Lean Manufacturing aplicados a ITIL, en lo que él llamaba Lean ITIL.

Otro de los aspectos interesantes de este post es la propuesta y la interpretación que aparece entre líneas del concepto tradicional de "las 3 P". Las 3P del mundo itilero son People, Process, Products (en mis tiempos se decía People, Process, Technology, pero entonces no se podía dar "la regla de las 3P" a los alumnos de Foundations, así que algún profesor espabilado cambió el concepto a las 3P y desde entonces ha proliferado).

Esta gente de BA ahora utiliza una ampliación de ese concepto: las 3PI, donde entran Proposition, Process, People and Single IT Solution:

  • Proposition: Para cada una de las iniciativas o propuestas que se lleven a cabo dentro de IT, se analizará cada propuesta frente a las demás, estudiando el valor que aporta cada una.
  • Process: Se entenderá el proceso de negocio extremo a extremo y no la pobre interpretación del mismo que puede hacer IT sobre los puntos en los que IT participa.
  • People: Se tendrá en cuenta la usabilidad (tanto para el personal propio como para el usuario/cliente final -- no olvidemos que es British Airways)
  • ... y finalmente la Tecnología

Es muy interesante, porque entre otras cosas y tal y como dice el artículo, si lo pensamos bien, esto significa que las TIC son únicamente el 25% de cualquier iniciativa. No tiene por que ser matemático, pero como imagen es perfecta y me gusta: Valor, Proceso, Personas y entonces después miramos cómo metemos la Tecnología en todo esto.

¿Se acuerdan de aquel Whitepaper de HP mítico llamado A fool with a tool is still a fool ?

15 de mayo de 2008

Acto de presentación del 191 de Novática

Ayer, día 14 de Mayo del 2008, se hizo un pequeño acto en el Ateneo Barcelonés para la presentación del número 191 de Novática,  dedicado al Gobierno de las TIC.

Fue un acto muy agradable, con cuatro presentaciones y unas 50 personas en una sala de la dimensión adecuada para que no diera sensación de agobio ni de vacío.

Las presentaciones fueron, por orden de aparición:

  • Didac López: Presentación de la revista y del trabajo realizado
  • Antonio Valle: El estado del arte en el Gobierno de las TIC
  • Aleix Palau: El estado del Gobierno de las TIC en España
  • Tomás Roy: El punto de vista de un usuario en una gran entidad (Generalitat de Catalunya)

No me cansaré de decirlo: el 191 de Novática hará historia. Historia por la calidad de los contenidos, por la difusión que se ha hecho y se hará de la revista y por una aproximación menos (mucho menos!) techie a la profesión desde ATI y desde Novática.

Hoy me llegaba un mail de un amigo... sus palabras literales:

Yo fui para que me dieran la revista, ahora tengo en mi poder una mítica Novática 191 :)

La versión en inglés de este número de Novática se puede descargar ya aquí, y la versión en castellano se podrá descargar en breve aquí.

5 de abril de 2008

Metodologías Ágiles y Gestión de Organizaciones

No soy, para nada, un experto en el mundo de las metodologías ágiles; ni si quiere puedo decir que sea un entendido, ni tan sólo apenas un conocedor, pero me llama mucho la atención el crecimiento que está teniendo este concepto.

Para mi todo empezó con el primer post de Sistemas Decisionales, donde ya comenzaban a aparecer estos conceptos, y después de eso se han ido sucediendo alguna que otra lectura, conversaciones con gente como Jorge Fernández, y (y esto es lo que más me ha llamado la atención) una pregunta hecha por cada vez más clientes y alumnos cuando hablamos de metodologías "rollo ITIL, y tal": ¿Y esto cómo cuadra con las Metodologías Ágiles?

Así que quizás comienza a llegar la hora en que estudiemos, experimentemos y probemos, para poder dar una respuesta a la gran pregunta en algún momento.

Para ayudarnos a todos aquellos que queramos entrar en este mundo, y a los que ya estén ayudarlos a seguir cada vez mejor, acaba de nacer la comunidad Scrum Manager, en palabras textuales, 

Comunidad profesional para la gestión flexible de proyectos y organizaciones TIC

O, como dicen en Navegapolis al respecto del lanzamiento,

Para estar al día en gestión de proyectos ágil, evitando costosos o exclusivos "seminarios de formación": una comunidad en la que los profesionales son miembros, no por el pago de una cuota, sino por la participación y por compartir su experiencia.