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

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.

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?

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.

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!

Consumada la venta de ITIL

Es curioso cómo son las cosas… hay días en que parece que los astros se alineen para dar esas coincidencias extrañas que pasan sólo muy de vez en cuando. Esta mañana he estado repasando un poco la línea temporal sobre historia de ITSM que tengo para mis clases y me di cuenta que una de las últimas entradas era la publicación del concurso para formar una joint-venture que impulsara las best-practices del gobierno británico (ITIL, MoV, Prince, etc..). Como no había tenido novedades al respecto y el tema había levantado bastante debate entre los profesionales del sector, me puse a buscar a ver si había algo de información al respecto del resultado, pero no encontré nada.

Luego, después de comer miré el correo y zas! ahí estaba la notificación de que se había publicado la nota de prensa con el resultado de esta aventura: la formación de una Joint-Venture con una empresa que yo no conocía de nada: Capita PLC

Esta Joint-Venture tiene aspectos muy curiosos. Empezamos leyendo la composición: 51% Capita, 49% Cabinet Office (o gobierno británico o su majestad la reina… los actuales dueños, vamos). Cuando salió la noticia del concurso hubo mucha discusion al respecto de si una JV sería vender ITIL® o no… para mi ahora está claro: si te asocias con alguien y ese alguien tiene más del 50% del asunto, lo has vendido. A partir de ahora, en las decisiones importantes, quien manda es Capita, no la Cabinet Office.

Otro aspecto interesante son los matices de la nota de prensa del gobierno británico:

Capita plc will own a 51% share of the new company. It will bring commercial expertise and enable investment needed to develop the products and break into new international markets. The government will retain 49% to ensure taxpayers benefit as the business grows.

Ojo, que no dice que se quedan el 49% para asegurar el buen crecimiento de los estándares ni la calidad de los mismos ni nada por el estilo… se quedan el 49% para asegurarse el beneficio. Y punto. A lo largo de toda la noticia se habla constantemente de los beneficios económicos y de las grandes perspectivas de comercialización que tienen los productos. Si alguna vez hubo alguna posibilidad de que ITIL® pasara a formar parte de la cultura general en forma de material libre, ya nos podemos olvidar… y eso significa también que la cultura de compartir y enriquecer los contenidos de las Best Practices de una manera similar a las comunidades open source desaparecerá rápidamente.

Y todo esto para qué? ¿A qué se dedicará la nueva empresa?

The new company will accredit exam institutes and training organisations to run exams and courses. It will act as an exam institute itself for the Project and Programme Management portfolio, including PRINCE2® products. Professionals using the qualifications will benefit too.

Asi que quedará como ente acreditador para los institutos examinadores y empresas de formación… ¿Qué pasará con APMG? En su página web apenas si hay una pequeña mención al tema… como si lo dijeran con la boca chica. Ellos hicieron ya un movimiento con ISACA que les puede salvar el trasero al menos en lo que a ITIL se refiere: están en el negocio de las certificaciones de COBIT 5, y eso puede ser muy grande si lo saben mover bien.

Y EXIN también ha movido ficha, anunciando en su pagina web la noticia e incluyendo un comentario esperanzador al respecto de que CAPITA respetará el ecosistema actual. De todas formas, tanto APMG como EXIN tienen sus salvavidas particulares en caso de que a estos británicos se les vaya la pinza.

¡Qué curioso es este mundillo!

Te puede interesar mirar atrás:

El futuro de ITIL (Noviembre de 2006)

La vuelta al cole (Septiembre de 2006)

3 deseos de Navidad para el sector

Estamos a finales de año, y proliferan los posts sobre las predicciones para el año 2013. Dado el ratio de acierto, este año he preferido pensar en deseos para el 2013 y me gustaría compartirlos con ustedes… quien sabe! Igual se me cumplen (este año me he portado muy bien, Santa!) y es el inicio de una época mejor que la que estamos viviendo. Así que sin más prolegómenos, allá van los tres deseos:

1.- Extensión de Lean en la Administración Pública: Todos los que hablan sobre la crisis dicen que debemos recortar gastos y aligerar las AAPP. Yo no se mucho de economía, pero sí que se de reducir gastos: se llama eficiencia. Y la mejor manera de conseguir eficiencia (sin perder en eficacia, que es lo que nos está pasando en estos momentos) es conseguir que las ideas y principios del pensamiento Lean se extiendan, se comprendan y se vayan aplicando lentamente. Un entorno con transparencia, con sentido común, con visión de conjunto y sin derroche nos permitiría tener una administración pública que le costaste por lo menos un 60% menos al contribuyente sin perder calidad de servicio. ¿No queremos mantener el estado del bienestar? ¡Pues lo que tenemos que hacer es no derrochar ni un céntimo del ciudadano! Olvidemos la tecnocracia, dejemos de gastar millones de euros en aplicaciones y sistemas que automatizan el derroche y hagamos un esfuerzo por volver a los orígenes, comprender (aprender a ver) los procesos, identificar lo que sobre, limpiar, depurar, y después hablamos de automatizar. Hace casi un año el Estado de Washington emitió una orden para que las agencias estatales adoptaran estrategias Lean… ¡¡ Cómo me gustaría ver algo así aquí!!

2.- Que se rompa el modelo de la pirámide: Este modelo de la pirámide (a falta de un nombre mejor) es una figura literaria que yo utilizo para visualizar un gran problema existente en las organizaciones: cuanto más arriba en la jerarquía está una persona, más importantes son las decisiones que tiene que tomar. Cuanto más arriba, más dinero en juego, más personas afectadas, a más largo plazo son las decisiones… Pues si es así, por qué razón cuanto más arriba se está menos atención, tiempo y reflexión se dedica a tomar estas decisiones? Un CFO, un CEO, un CIO no es un superhombre con una inteligencia diez veces superior a la media… le tiene que dedicar a las cosas un tiempo razonable, parecido al que le tendrías que dedicar tú o que le tendría que dedicar yo.

Estar “trasteando” con el móvil o con la tablet durante las reuniones en las que se está tratando de proporcionarle la información necesaria para que tome una decisión con criterio, llegar tarde o no llegar a las reuniones (diciéndole a su segundo “ve tu a la reunión y luego me haces un resumen”) o pretender decidir cosas que afectan a cientos de trabajadores en base a lo que me puedas explicar en 5 minutos tomando un café entre reunión y reunión es una terrible falta de respeto hacia los trabajadores y sobre todo hacia la organización que sufrirá las decisiones tomadas a la ligera.

Desearía que a partir del año 2013 los directivos sean conscientes de la importancia que tienen sus decisiones, que dediquen el tiempo necesario para meditar, reflexionar y decidir y que, para que esto sea viable, el “span de responsabilidad” sea el adecuado.

3.- Que tengamos cuidadito con el cloud: Todas las predicciones apuntan a que hay nubarrones grandes en el horizonte del 2013. El hype del cloud computing viene pegando con fuerza, pero son cada vez más los CIOs que, una vez comprado el modelo en cloud, se topan de morros con la realidad: ¡¡Se nos ha olvidado pensar cómo vamos a gestionar esto!!. De repente tu proveedor es un proveedor industrializado, que obtiene su beneficio de la producción en masa y de las economías de escala… ¿que quieres personalizar el qué??? ¿Que te tenga en cuenta en las paradas planificadas? ¿Que te avise antes de los upgrades y los haga cuando a ti te venga bien según tu ciclo de negocio?  ¡¡No me haga usted reir, por favor, señor cliente, que me duele una costilla!!

Asi que por favor, piensa antes de tirarte a la piscina! No todo es mover las cosas de inversión a gasto ni ganar en flexibilidad. Tu les das servicios TIC a tus clientes, a quienes les importa un pepino si la cosa es cloud o no. Y con esto no quiero decir que sea un anti-cloud y que no me guste… lo que quiero decir es que las cosas hay que pensarlas un pelin. Vamos, que si se me cumple el deseo 2, el tres va de regalo!

Feliz Navidad a todos, y si quieres dejar tus deseos en los comentarios, se los paso a Papa Noel todos juntos!

PS:: El diseño de la camiseta es propiedad de GamesAjare.

El TFT12 ya está aquí!

Han pasado varios meses desde que comenzara esta gran aventura que ha supuesto la organización del congreso global TFT12, Tomorrows IT Service Future Today. En el momento de escribir estas letras, quedan menos de siete horas para que comience el espectáculo, cuando den las 08:00am en Sydney, Australia y comience el día 5 de Diciembre al otro lado del mundo. A partir de ese momento, tendremos 24 horas de conferencias sobre ITSM con 24 ponentes de todo el mundo explicándonos qué nos depara el futuro en este sector tan agitado; pero lo novedoso no es sólo que sean 24 ponentes hablando durante 24 horas… este congreso es novedoso en todos y cada uno de los aspectos, desde la selección de conferenciantes por crowdsourcing hasta la difusión en directo y en diferido mediante Google Hangout.

Te dejo aquí algunas pistas que te ayudarán a consumir el conocimiento aportado durante todo este tiempo:

1. Consulta el programa del evento, escoge qué conferencias quieres ver en directo.
2. Haz un RSVP del evento en las redes sociales que utilices, para saber con quiénes te encontrarás y con quién podrás compartir comentarios, impresiones e ideas. Hay eventos creados en Facebook, Gooogle+ y LinkedIN
3. Atiende en vivo y en directo a las conferencias que serán emitidas en streaming por Youtube.
4. Descárgate las presentaciones a medida que se vayan produciendo.
5. A partir del 10 de Diciembre, podrás escuchar y descárgate el audio de las conferencias desde SoundCloud
6. Revisa la lista de ponentes y sus biografías en el tablón de Pinterest.
7. Subscríbete aquí para que te lleguen directamente a tu Evernote o a tu Kindle las presentaciones de forma automática a medida que se vayan produciendo.
8. Añade comentarios tanto sobre lo ponentes como sobre las ponencias en Slideshare y Pinterest.
9. Utiliza el hashtag #TFT12 para cualquier comentario que hagas en las redes sociales.
10. Inscríbete ya! La lista de ponencias para el TFT13 ya está abierta!

Habías visto alguna vez un congreso más 2.0 que este? Estamos haciendo historia y tú puedes ser parte de ella. Espero verte entre los asistentes. Mi conferencia es el día 5 a las 14:00 hora canaria (GMT) y una hora más en la Península (15:00 CET) y versará sobre RBSM – Risk Based Service Management.