Búsqueda


29 de abril de 2016

¿Transformación Digital? No sin DevOps!!

Se me repite la ocasión en que vuelvo a casa despues de un curso de DevOps Foundations. Probablemente disponer de tres horas de tranquilidad después de tanta actividad hace que me aparezcan algunas ideas y me den ganas de escribir.

Una de las slides que presento en la versión para managers de este curso está sacada del documento State of DevOps Report 2015, publicado por Puppet Enterprise y que representa un informe sobre el estado de la cuestión que han venido publicando desde 2013 y que se ha ganado el respeto de la comunidad.

La primera vez que vi esta gráfica se me pusieron los pelos de punta y creo que es de una importancia tan grande que es necesario dedicarle un post, una noticia en el periódico y hasta un libro si fuera necesario con tal de hacer entender a todos los directivos del pais lo que significa.

Vamos a ir por partes: en el eje vertical tenemos tenemos la frecuencia de despliegues en la organización., pero atención, representada en una escala logarítmica donde 1 significa un despliegue al día… pero es que 2 significan 10 despliegues al día y 3 significan 100 despliegues al día; no nos dejemos engañar por la inocencia de esa gráfica.

En el eje horizontal tenemos, en escala también logarítmica, el tamaño de los equipos de desarrollo. Asi que me he permitido el lujo de calcular “a ojo” los valores de la curva, meterlos en un excel y hacer una gráfica parecida pero con escala lineal, para no suavizar el impacto del puñetazo que nos dan estos datos


¿Y qué significa esto? Pues básicamente que

a) Los “low performers” (aquellos que con sus prácticas actuales no llegan a más de 100 desarrolladores y que aún así están haciendo como mucho tres o cuatros despliegues a la semana.

b) El rendimiento de los “low performers” cae rápidamente cuando crecen en número de desarrolladores. Esto es típico de las aproximaciones tradicionales: al añadir más personal, crece la desorganización y el waste y por lo tanto la eficiencia cae en picado. En la siguiente gráfica he quitado a los high performers para poder percibir esta situación:


c) Con respecto a los “Mid Performers”, podemos ver que soportan relativamente bien la incorporación de cada vez más personal y lentamente aumentan el número de despliegues al día. Fijémosnos en que esto significa, desde el punto de vista del negocio, que podemos llegar a doblar el número de desarrolladores (e incurrir en costes mucho más elevados, ya que el aumento de costes no es lineal al numero de personas) y aún así no llegan al despliegue diario (en el fondo, quizás aqui el aspecto importante de verdad es que puedes doblar los recursos, pero no doblarás la velocidad de despliegues, sino que se mantendrá relativamente constante)

d) Finalmente, los “High Performers”. Estos son los preocupantes. Estos se mantienen más o menos cercanos hasta llegar a los 300 desarrolladores. Entonces comienza su escalada brutal: pasan a los cinco despliegues al día y rápidamente con capaces de llegar a los 80 despliegues al día apenas triplicando los recursos (osea, triplico los recursos y multiplico por 15 los resultados (!!!)

Posiblemente en estos momentos estés pensando que eso en el fondo son unos números más o menos trucados, quizás que en tu empresa hay doscientos programadores y que eres capaz de hacer 40 despliegues a la semana (que son unos 5 al día) y que eso está chupado, o simplemente que “¿y para qué quiero yo hacer tantos despliegues al día?”.

Perdón, que me ha faltado la última excusa, bastante frecuente además, la de “si, claro… pero ¿cuántos de esos despliegues son buenos? ¿Qué nivel de fallos tienen estos tios a esa velocidad?”. Te lo respondo en la siguiente tabla, tambien sacada del mismo State of Devops Report 2015

Ok, pues esto nos muestra que se está produciendo una brecha inmensa que está separando a los high performers del resto del mundo a una velocidad pasmosa y eso es un problema.

Ahora piensa en todos aquellos que están hablando sobre Transformación Digital. En el fondo están tratando de aplicar soluciones del mundo digital a los problemas que tienen sus clientes y buscando nuevas vías de contactar con ellos, de mantenerlos ligados a su marca, productos y servicios y rompiendose la cabeza para innovar en sectores que posiblemente sean muy tradicionales: ¿cómo ofrecer novedades en el sector banca, seguros, retail?

Y resulta que todo el concepto de Transformación Digital se basa en tres palabras: experimentar, innovar, aprender y digitalizar. Una empresa que aborde una iniciativa de transformación digital tiene que ser consciente de que esto no es un proyecto con inicio y fin, sino una transformación: ahora eres una cosa y luego serás otra, pero esa otra cosa, ese punto de destino es móvil y cambiante; las empresas transformadas ya no son empresas rígidas sino que son empresas líquidas que se adaptan de forma continua a un entorno, a un mercado y a unos clientes que cambian continua y rápidamente.

¿Y cómo puedes conseguir eso en un entorno digitalizado? Pues con velocidad. Necesitas que en IT tu flujo de aportación de valor sea muy rápido y que tu lead time sea muy corto con un nivel de acierto elevadísimo… y eso es exactamente lo que están consiguiendo los high performers de nuestra gráfica de arriba.

Resulta que los high performers han llegado a una situación en la que su lead time de experimentacion es muy corto, su capacidad de desplegar pruebas en los entornos de produccion es altisima, su riesgo muy bajo y su capacidad de recuperarse ante los errores es increible… los high performers pueden probar nuevos productos, nuevas lineas de negocio y nuevas maneras de comunicarse y satisfacer a sus clientes 200 veces más rápido que una empresa “normal”: o espabilamos o se nos comen!!

Así pues, la próxima vez que te plantees la transformación digital de tu compañía piensa primero en los cimientos sobre los que debes consruir ese cambio:

  • una cultura de colaboración
  • una organización transversal que huye de los silos verticales
  • equipos multidisciplinares
  • flujo de valor
  • aprendizaje
  • automatización

En definitiva, Lean-IT, Agile y DevOps o lo que nosotros llamamos Agile IT Management.

Y esos cimientos debes construirlos rápido: los high performers llevan años haciéndolo así que no te van a dejar respirar.

No tardes y empieza ya!

30 de marzo de 2016

La X Muda

Esta vez me pilló viajando. El dia 23 de Marzo me pilló en uno de esos viajes al otro lado del mundo que hago al menos una vez al año y que me sirven para despejarme del ruido cerebral que produce la civilización y la gran ciudad.

¿Que qué pasa el 23 de Marzo?

Pues este año, concretamente, el 23 de Marzo supuso el décimo aniversario de este blog. 10 años contando historias vividas día a día y que ahora, cuando las miro en perspectiva me muestran en gran medida cómo ha sido mi evolución personal en el mundo del Gobierno y la Gestión de las Tecnologías de la Información…

Aqui tienes la primera entrada de este blog: La CMDB Federada (qué ojo!! jeje)

Pero no me pilló desprevenido! Ya sabía que me iba a pillar de viaje así que antes de salir me compré un bloc y un boli Bic de cuatro colores y armado con semejante despliegue de tecnología me fui al paraiso Zen a pensar en el contenido de este post de celebración de una década de GobiernoTIC.

La X Muda

Una de las obsesiones incorporadas en los sistemas de producción basados en Lean es la detección y eliminación sistemática de las ineficiencias. Esas ineficiencias se clasifican fundamentalmente en tres grandes grupos:

  • Muda: tipos de trabajo o acción que resultan en derroche de tiempo, esfuerzo, recursos, ...
  • Mura: grupo de las ineficiencias producidas por falta de homogeneidad en las entradas, en las tareas, en las personas, ...
  • Muri: grupo de las ineficiencias que se producen por el stress o sobretensión en personas y medios de producción

Taiichi Ohno hizo un gran trabajo clasificando las diferentes tipologías de MUDA en lo que posteriormente hemos ordenado alrededor de las letras del acrónimo TIMWOOD (acrónimo que los profesores utilizamos para facilitar que los alumnos que están comenzando su recorrido no tengan problemas en recordar cuáles son los 7 tipos de muda):

  • Transportation
  • Inventory
  • Motion
  • Waiting
  • Overprocessing
  • Overproduction
  • Defects

Más adelante, en el libro The Toyota Way, Jeff Liker menciona la octava muda como el no aprovechar la creatividad, el talento o la sabiduría de los empleados.

Con el paso de los años he ido acostumbrando el ojo a ver y a detectar los ocho tipos de muda, al tiempo que he ido desarrollando la capacidad de enseñar a clientes, compañeros y alumnos a detectarlas; sin embargo, poco a poco iba apareciendo la necesidad de ampliar esta lista. Si nos fijamos bien, veremos que los ocho tipos de muda tienen que ver con acciones que realizamos, con actividad no provechosa (especialmente las 7 primeras, que están muy relacionadas con los procesos productivos).

Sin embargo, no aparecen en esta clasificación mudas que tengan que ver con el cómo se hacen las tareas, desde el punto de vista humano y no del procesos; desde el punto de vista de los “soft-skills”.

Justamente cuando repasaba la historia del blog y veia que se habían cumplido 10 años de GobiernoTIC mi reflexión era ¡¡Vaya… ahora en la distancia me doy cuenta de que no tenian que haber sido 10 años de Gobierno TIC sino de Gobierno de las Personas que Trabajan en las TIC!! ¡¡Cómo no me dí cuenta en las primeras conferencias de Paul Wilkinson en el 2005!!

En más de una ocasión me he encontrado actividades de tipo VA que se ejecutaban de una forma muy cuestionable y el problema no está en ninguna de las letras del TIMWOOD, sino que la cosa tiene que ver con la forma en que la información, los mensajes o las órdenes fluyen en la organización.

No es un problema de delegación ni de matrices RACI sino que es más profundo: hay organizaciones en las que cuesta mover la rueda simplemente porque a cada impulso que se da, aparecen palos en las ruedas, falta de grasa, tensiones, dudas, protestas… aspectos culturales que nos llevan a declarar la X MUDA: LA FRICCION

Entiendo por fricción toda aquella fuerza contraria al correcto fluir del valor hacia el cliente. Son fuerzas contrarias al flujo definido y no se representa por actividades NVA o NNVA, no son actividades sino fuerzas.

Podemos ver ejemplos de fricción cuando se pide hacer una tarea y se te activa la Tercera Ley de Newton: "Actioni contrariam semper & æqualem esse reactionem” o sea "Con toda acción ocurre siempre una reacción igual y contraria"

O cuando hay que actuar y primero tenemos que dar diez mil explicaciones porque la persona no acaba de estar convencida de que esa sea la linea de acción correcta.

O cuando Newton vuelve a actuar, pero esta vez en forma de su primera Ley: “Todo cuerpo persevera en su estado de reposo o movimiento uniforme y rectilineo a no ser que sea obligado a cambiar su estado por fuerzas impresas sobre él"

Básicamente, encontraremos que hay equipos cohesionados en los que el trabajo se ejecuta de forma suave, coordinada y sin fricciones… mientras que hay otros equipos en los que las fricciones son las que ocasionan el derroche de energía, tiempo y recursos. No tiene que ver con las tareas que se desempeñan sino con la convivencia, feeling, liderazgo y comunicación que hay en el equipo.

Y de la misma manera que desarrollamos patrones y antipatrones para enfrentarnos a los ocho tipos de Muda, hacemos ejercicios para “aprender a ver” las ineficiencias en nuestro flujo e incorporamos todas las observaciones en el tablon de posibles entradas para un Kaizen o un Kaizen Diario, debemos incorporar la friccion dentro de nuestras observaciones, analizar qué es lo que la causa y tratar de buscar soluciones, sólo que generalmente las contramedidas a desplegar tendrán más que ver con la cultura de equipo o la gestión del cambio que con los procesos, procedimientos o métodos de trabajo.

… y así es como yo veo la Décima forma de Muda: la FRICCION, que hace que incluso un proceso perfecto se ejecute de manera ineficiente, que no se ve fácilmente, que siempre tenderemos a encubrir y que no acabo de imaginarme cómo representar en un Value Stream Map…

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?