tag:blogger.com,1999:blog-246203022024-03-08T00:36:40.552+01:00Gobierno de las TIC - Conocimiento AdquiridoUn espacio de reflexión y divulgación sobre ITSM y Gobierno de las TICAntonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.comBlogger304125tag:blogger.com,1999:blog-24620302.post-40967444172416414782023-12-04T17:48:00.002+01:002023-12-04T17:59:16.822+01:00Respect for downstream<p class="article-editor-content__paragraph" data-pm-slice="1 3 []"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjwo1ji2h7TWPBD6PZgNZnOLxepjEjNCgDanOLzvppLsyISrhBrdG0N0FwhS7NqVx_vA2zxN2f2mciEB8Go6KUr2dfHjVKgU0p72GaTgJTUNaYDAYizmy4us_0J5XXn4kwICEB0r33WwluCOuSUz6h_1rRC5HoSPTVy8IBFoO0t7VqbnXoWcmo4Hw/s1016/respect_for_downstream.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="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." border="0" data-original-height="765" data-original-width="1016" height="241" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjwo1ji2h7TWPBD6PZgNZnOLxepjEjNCgDanOLzvppLsyISrhBrdG0N0FwhS7NqVx_vA2zxN2f2mciEB8Go6KUr2dfHjVKgU0p72GaTgJTUNaYDAYizmy4us_0J5XXn4kwICEB0r33WwluCOuSUz6h_1rRC5HoSPTVy8IBFoO0t7VqbnXoWcmo4Hw/w320-h241/respect_for_downstream.jpg" title="Respect for downstream" width="320" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div>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.<p></p><blockquote class="article-editor-content__blockquote"><p class="article-editor-content__paragraph">Para que dirías que sirve este evento de Scrum?</p></blockquote><p class="article-editor-content__paragraph">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. </p><p class="article-editor-content__paragraph">Sirve:</p><ul class="article-editor-content__bullet-list"><li class="article-editor-content__list-item"><p class="article-editor-content__paragraph">Para tener una conversación abierta entre equipo y PO sobre “<em>qué hacemos a continuación</em>”.</p></li><li class="article-editor-content__list-item"><p class="article-editor-content__paragraph">Para equilibrar adecuadamente la capacidad de desarrollo con el tamaño del trabajo que vamos a acometer. (dígase <em>tamaño</em> en todas las acepciones que podamos pensar en el sector del software)</p></li><li class="article-editor-content__list-item"><p class="article-editor-content__paragraph">Para establecer las expectativas del PO al respecto de lo que el equipo espera entregar a lo largo de la próxima iteración.</p></li><li class="article-editor-content__list-item"><p class="article-editor-content__paragraph">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.</p></li></ul><p class="article-editor-content__paragraph">El punto de <strong>equilibrar la capacidad con el WIP que inyectamos al sistema</strong> 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.</p><p class="article-editor-content__paragraph">Algo así como decir que </p><blockquote class="article-editor-content__blockquote"><p class="article-editor-content__paragraph">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.</p></blockquote><p class="article-editor-content__paragraph">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.</p><p class="article-editor-content__paragraph">Es decir: <strong>aguas abajo hay muchos grupos de trabajo que dependen del cumplimiento de las expectativas generadas en un Sprint Plan.</strong></p><blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;"><p style="text-align: left;"><em>-- Hay incertidumbre en el desarrollo.<br /></em><em>-- Ya lo sé. <br /></em><em>-- Estamos en un mundo complejo, la organización y el software forman un sistema adaptativo-complejo que lo hace de todo menos predecible. <br /></em><em>-- También lo sé. Y por eso no pido adherencia al 100%, pido trabajo continuo en pro de la mejora.</em></p></blockquote><p class="article-editor-content__paragraph" style="text-align: left;">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).</p><p class="article-editor-content__paragraph">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. </p><p class="article-editor-content__paragraph"><strong>Hay gente ahí fuera que lo hace de película:</strong> esos son los imprescindibles, esos son aquellos de los que debemos aprender.</p><p class="article-editor-content__paragraph">PS: Te dejo un par de preguntas para que le des a la reflexión:</p><ol class="article-editor-content__ordered-list"><li class="article-editor-content__list-item"><p class="article-editor-content__paragraph">¿Qué factores influyen en la predictibilidad de tu(s) equipo(s)?</p></li><li class="article-editor-content__list-item"><p class="article-editor-content__paragraph">¿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?</p></li><li class="article-editor-content__list-item"><p class="article-editor-content__paragraph">¿Cuál es el valor del refinamiento en todo esto?</p></li><li class="article-editor-content__list-item"><p class="article-editor-content__paragraph">Estimar o no estimar... esa es la cuestión.</p></li><li class="article-editor-content__list-item"><p class="article-editor-content__paragraph">¿Tiene sentido generar ocupación al 100%? ☠️</p></li></ol>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.com0tag:blogger.com,1999:blog-24620302.post-34440960713023245342023-09-02T14:32:00.002+02:002023-09-02T14:48:03.302+02:00Where have all the SM gone?<p> En algún momento pausado de estas vacaciones le daba vueltas a la situación del sector de la gestión de servicios IT en la última década.</p><p>Como siempre, todo nacía de alguna curiosidad, de esas preguntas que, de repente, me saltan a la cabeza y que me obligan a dedicarle unos ciclos de CPU. Sólo que no siempre son “unos pocos ciclos”; en este caso ha sido un poco más.</p><p>La pregunta que me hacía giraba en torno a cuál será la aproximación a la Gestión de Servicios IT que hace hoy por hoy una persona de, digamos, 30 años. Con esa edad ha terminado unos estudios, tiene unos años de experiencia y ha comenzado a comprender cómo funciona el sector TIC. Pero también se encuentra con que la formación que pueda recibir para gestionar servicios es, por ejemplo, un Fundamentos de ITIL® 4 o la información que reciba de las herramientas con las que trabaja.</p><h3 style="text-align: left;">¿Qué visión tiene de la gestión de servicios?</h3><p>Si miro atrás y pienso en cómo entré yo en este mundo, veo que estudié ITIL® V2, después ITIL® V3, ISO/IEC-20.000, COBIT e ITIL® 4 entre otros. Además, participé en congresos, era activo en multitud de foros, discusiones online y presenciales, conversaciones con gente de mi zona e internacionales. El sector ITSM era bullicioso como un mercado en Palermo, con gente deseando venderte sus servicios, pero también con mucha gente deseando compartir conocimientos, experiencias, ideas.</p><p>Pero hoy la cosa es muy, muy diferente. Ninguno de los foros que yo conozca (ni siquiera los que he promovido yo mismo) están activos. Se han convertido en monólogos en los que copywriters escupen mensajes publicitarios disfrazados de “contenidos” y tratan de llamar tu atención sobre su herramienta, sus servicios o su formación.</p><p>Llegué a pensar que la profesión podría haberse acabado, que ya nadie quiere un IT Service Manager, quizás porque ya no se hace gestión de servicios. Pero no: obviamente los servicios se siguen prestando, la necesidad de gestionarlos de una manera formal, sistemática y ordenada sigue existiendo y las ofertas de trabajo siguen existiendo. ¡Si hasta veo ofertas pidiendo un especialista CMDB!</p><p>Nadie habla ya de la CMDB, pero seguimos necesitando especialistas. ¡qué cosas!</p><h3 style="text-align: left;">¿Cómo hemos llegado a esta situación? </h3><p>Yo creo que tantos años de tener un mercado fuertemente dominado por un único framework (ITIL®) ha hecho que la caída de ITIL® arrastre a todo el sector ITSM consigo.</p><p>Durante décadas hubo mentes activas que trataron de generar marcos de trabajo, maneras de hacer, diferentes a ITIL® con la intención de añadir diversidad, de generar un negocio alternativo, y de aumentar la velocidad con la que las novedades se incorporaban a los marcos de trabajo. La rápida expansión que están teniendo agile y devops tenía que provocar cambios en la manera de entender y gestionar los servicios e ITIL® estaba siendo demasiado lenta en asimilar todos estos cambios.</p><p>La lista de modelos es interminable, pero para citar algunos de los más relevantes podemos pensar en IT4IT, USM, VERISM y muchos más; pero ninguno de ellos ha tenido la penetración y fuerza en el mercado que ha tenido ITIL®. De hecho, si miras las ofertas de trabajo para ITSM en España verás que todas, absolutamente todas, piden ITIL® de una u otra manera.</p><p>Así pues, María, nuestra candidata de 30 años que entra en el mundo de la Gestión de Servicios tiene que poner en su CV las siglas doradas, sí o sí; y para eso se inscribe en un curso de Fundamentos ITIL® V4 en el que le van a explicar tal ensalada de conceptos, que va a salir con la cabeza más liada si cabe, porque la cantidad de ideas que añade ese curso es tremenda.</p><h3 style="text-align: left;">¿Y Entonces? ¿Qué hacemos con María?</h3><p>No tiene demasiadas alternativas. El mercado de la formación se ha ido concentrando, y ahora PeopleCert es dueño de la certificación y de ITIL®. Por otra parte, EXIN ha caído y por lo tanto sus esquemas de certificación basados en ISO 20.000 también. En formación clásica ITSM queda algo en manos de APMG, la Global Trust Association tiene aqui una gran oportunidad y quién sabe si Pink Elephant conseguirá sacar adelante su esquema de formación y certificación después de que PeopleCert <a href="https://www.businesswire.com/news/home/20230517005620/en/Goodbye-ITIL®-–-PeopleCert-Ends-Partnership-with-Pink-Elephant" target="_blank">les diera la patada.</a></p><p>Si buscamos los eventos ITSM de 2023 en España, veremos que no hay gran cosa: un montón de empresas que venden herramientas haciendo sus eventos ITSM para demostrar que son los mejores ( y recuerda, María: a fool with a tool is still a fool) y no mucho más. Por otra parte, la gran fuente de conocimiento y de networking que fue itSMF España está en un proceso de cambio que tiene paralizado el motor de eventos y por lo tanto apenas si hay un evento anual en Madrid.</p><p>Pero volvamos con el título de esta entrada:</p><h3 style="text-align: left;">Where have all the SM gone?</h3><p>Dado el contexto un poco decadente que he mostrado en la primera parte del post, ¿Qué ha pasado con los IT Service Managers, a dónde se han ido?</p><p>Los de la vieja escuela han tomado diferentes caminos: los hay que siguen al pie del cañón, gestionando los servicios más importantes del país: sigue siendo un rol necesario, demandado y en proceso inflacionario porque hay pocos; así que muchos están desempeñando un gran trabajo, habitualmente en empresas prestadoras de servicios o de outsourcing. María tiene una gran oportunidad aquí, trabajando codo con codo con cualquiera de estos veteranos, aprendiendo “desde las trincheras” y con suerte aportando todo su conocimiento y nuevas maneras de ver las cosas al sector.</p><p>Otros (muchos) se han mudado a un sector mucho más lucrativo: la ciberseguridad. En ese terreno el trabajo nunca falta y cada vez es más necesaria una correcta gestión de los servicios de ciberseguridad. Era un nicho claro. Además, mientras que una buena gestión de servicios en tiempos de crisis se podía ver como un lujo (o un “se le supone” al outsourcer), la ciberseguridad siempre es un must, indiscutible.</p><p>Otros, como es mi caso, iniciamos una deriva por el terreno Lean que nos llevó al mundo agile y ahora combinamos conocimientos y experiencias entre la construcción y la entrega. Es bonito, pero un terreno pantanoso por la falta de marcos claros de trabajo; eso hace que sea una profesión muy exigente en pensamiento y reflexión.</p><p>Finalmente, otros cuantos (y que serán cada vez más), se han retirado: ITIL® nació a finales de los 80 y los que eran como nuestra María en el año 1988 hoy peinan canas con 65 y están celebrándolo (o no: ahora se dedican a pensar y a escribir y a trabajar pausadamente en lo que les gusta).</p><p>Así que María, <b>mi consejo</b>: la gestión de servicios clásica que inventamos en 1990 tiene algunas cosas muy potentes y muy válidas. No debes tirarla toda a la basura. Pero no estaba pensada para la sociedad actual. Hay que trocearla, desmenuzarla como un bocata de esos de pulled-pork, tomar algunas ideas importantes y completarla con todas las cosas nuevas que has aprendido en otros sectores: Lean, Agile, DevOps, Open Management, teal organizations… la lista es interminable.</p><p>Yo veo un futuro de ITSM en el que hay diferentes categorías de servicio: aquellos en los que tiene sentido el enfoque ágil, orientados a flujo y a entrega de valor, con fuerte participación del cliente/usuario en su evolución y características de prestación y aquellos en los que no se le ve sentido a esta aproximación y entonces se gestionen de una manera más clásica orientada a economías de escala. Pero en ambos casos, veo un futuro más humanista, en el que las personas tienen un protagonismo especial, en el que hay una manera de organizarnos y de colaborar mucho más orientada a la comunicación, a la mejora y al respecto. Mucho más “<a href="https://tealunicorn.com/oitp/" target="_blank">Open IT</a>” en definitiva.</p><div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen="" class="BLOG_video_class" height="320" src="https://www.youtube.com/embed/V6ROcOgxMCg" width="385" youtube-src-id="V6ROcOgxMCg"></iframe></div><p>Lo maravilloso es que se abre frente a ti un mundo nuevo que no está construido. Tendrás que construirlo tú: crea la comunidad, habla con tus compañeros, se creativa, imagina nuevas maneras de hacer. Tendrás que luchar duro, como en todas las generaciones, por romper los moldes y hacer que los viejos dinosaurios aprendamos a entender el mundo a través de tus ojos. Ten paciencia, habla el idioma de tus superiores, y muéstrales cómo el taylorismo pasó a la historia.</p><p>Pero siempre recuerda a Bernard de Chartres: </p><p></p><blockquote><p>“si podemos ver más lejos es gracias a que somos enanos a hombros de gigantes”.</p></blockquote><p>¡Buena suerte, María!</p><p>Y si necesitas cualquier cosa, aquí estoy. Siempre me ha gustado compartir lo poco que se.</p>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.com0tag:blogger.com,1999:blog-24620302.post-31242791176875900562023-09-01T19:03:00.001+02:002023-09-01T19:03:07.722+02:00La pregunta<div>Han pasado siete años desde que escribí <a href="http://www.gobiernotic.es/2016/03/la-x-muda.html" target="_blank">“La X Muda”</a>. </div><div>Siete años guardado en un cajón de Internet al que sólo llega algún que otro despistado.</div><div><br /></div><div>Y resulta que durante estas vacaciones, va <a href="https://www.linkedin.com/in/robenglandattwohills/" target="_blank">Rob England</a> y añade en ese fantástico curso que está impartiendo sobre <a href="https://tealunicorn.com/om/" target="_blank">Open IT Management</a> un apartado sobre la octava Muda.</div><div><br /></div><div>Este curso que están ejecutando Rob y Cherry es muy innovador: en lugar de impartir un curso en forma de masterclass han preferido convertirlo en un correo semanal en el que se toca un tema. Este correo se publica después como un post en linkedin y de ahí cuelga la conversación entre los alumnos alrededor del tema planteado. </div><div><br /></div><div>Claro, no me pude resistir a añadir en la conversación un enlace al texto de <a href="http://www.gobiernotic.es/2016/03/la-x-muda.html" target="_blank">La X Muda</a>, acto que provocó alguna que otra visita a un blog que cría telarañas porque ya nadie sigue a blogueros.</div><div><br /></div><div>Y una de estas visitas ha abierto una puerta que llevaba siete años cerrada. </div><div><br /></div><div>¿Será posible? Cuando escribí la X Muda estaba convencido de que alguien me iba a hacer <i>la pregunta</i>. </div><div><br /></div><div>La dejé adrede plantada en el texto, y pensé que más de una persona se vería provocada por el artículo y acabarían enviando un correo o poniendo un comentario haciéndome "la pregunta"</div><div><br /></div><div>Pero nadie la hizo. Yo tenía la respuesta preparada, pero nadie hizo "la pregunta".</div><div><br /></div><div>Increíble.</div><div><br /></div><div>Son cosas que pasan: a veces piensas que un texto va a desencadenar una determinada secuencia de pensamientos, pero eso no pasa y ya está; la vida sigue.</div><div><br /></div><div>Y, sin embargo, después de siete años con "la pregunta" junto a "la respuesta" criando polvo en un rincón de mi cabeza, hoy me suena el Whatsapp y alguien (muy especial, tengo que decirlo) me plantea <i>la pregunta</i></div><div><br /></div><div>¡No me lo podía creer! </div><div><br /></div><div>Y así le dije: ¿te puedes creer que llevo siete años esperando a que alguien haga esa pregunta? Quizás es tan tonta o tan obvia, que la gente no lo ha exteriorizado; quizás nadie se ha dado cuenta de que había que hacerla. Sea como sea, la respuesta lleva siete años esperando a salir.</div><div><br /></div><div>¿Quieres saber cuál es <i>la pregunta</i> (o su respuesta)? </div><div><br /></div><div>Bueno, pues la tal pregunta es muy simple:</div><div><br /></div><div></div><blockquote><div>¿Y cuál es la novena muda?</div><div></div></blockquote><div><br /></div><div>Claro, si llegamos hasta la octava muda (si quieres saber cuáles son y esas cosas, tendrás que ir <a href="http://www.gobiernotic.es/2016/03/la-x-muda.html">al artículo original para verlo</a>) y de repente yo salto hasta la décima, la novena quedaba libre. ¿Cuál es?</div><div><br /></div><div>Va, si la pregunta ha esperado siete años, te puedo dejar un rato pendiente de saber cuál es la novena, ¿no?</div><div><br /></div><div>¿Cual crees tú que será la novena muda? </div>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.com0tag:blogger.com,1999:blog-24620302.post-51642069274460692312023-02-06T09:52:00.003+01:002023-09-01T18:44:20.657+02:00Adaptase a los cambios: la clave de la agilidad empresarial<p data-renderer-start-pos="1" style="caret-color: rgb(23, 43, 77); color: #172b4d; font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; font-size: 16px; letter-spacing: -0.005em; line-height: 1.714; margin: 0px; padding: 0px; white-space: pre-wrap;">A finales de 2022, G2 y la Global Trust Association firmaron un acuerdo de colaboración que habilita a G2 a impartir el portfolio de cursos de la GTA. Este <a class="css-tgpl01" data-renderer-mark="true" href="https://globaltrustassociation.org/es/certificaciones/" style="color: #0052cc; text-decoration: none;" title="https://globaltrustassociation.org/es/certificaciones/">portfolio es muy amplio</a>, así que el planteamiento es ir incorporando poco a poco los cursos que se adecuen mejor a las necesidades de nuestros clientes.</p><p data-renderer-start-pos="312" style="caret-color: rgb(23, 43, 77); color: #172b4d; font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; font-size: 16px; letter-spacing: -0.005em; line-height: 1.714; margin: 0.75rem 0px 0px; padding: 0px; white-space: pre-wrap;">El primer curso que lanzaremos será a finales del mes de Febrero de 2023: el curso de preparación para la certificación <strong data-renderer-mark="true">Certified Business Agility Professional</strong>. Este es un curso en el que se visitan cada una de las dimensiones y dominios del modelo operativo del <a class="css-tgpl01" data-renderer-mark="true" href="https://businessagility.institute/" style="color: #0052cc; text-decoration: none;" title="https://businessagility.institute">Business Agility Institute</a>.</p><p data-renderer-start-pos="604" style="caret-color: rgb(23, 43, 77); color: #172b4d; font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; font-size: 16px; letter-spacing: -0.005em; line-height: 1.714; margin: 0.75rem 0px 0px; padding: 0px; white-space: pre-wrap;">Nos hemos dado bastante tiempo para preparar el curso; queremos que sea una experiencia que esté a la altura, así que estamos repasando minuciosamente los contenidos y los materiales. </p><p data-renderer-start-pos="790" style="caret-color: rgb(23, 43, 77); color: #172b4d; font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; font-size: 16px; letter-spacing: -0.005em; line-height: 1.714; margin: 0.75rem 0px 0px; padding: 0px; white-space: pre-wrap;">En G2 somos mucho de estructurarnos las ideas y hemos querido hacer un pequeño trabajo de investigación: <strong data-renderer-mark="true">¿Qué definiciones hay de Business Agility? ¿Qué conceptos tienen en común estas definiciones y cómo conecta esto con el curso que vamos a impartir?</strong></p><h2 data-renderer-start-pos="1044" id="El-factor-común" style="caret-color: rgb(23, 43, 77); color: #172b4d; font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; font-size: 1.43em; font-weight: 500; letter-spacing: -0.008em; line-height: 1.2; margin: 1.8em 0px 0px; padding: 0px; scroll-margin-top: 56px; white-space: pre-wrap;">El factor común<span class="heading-anchor-wrapper" role="presentation" style="height: 1.2em; margin-left: 6px; position: absolute;"><button aria-label="Copiar enlace en el título" class="css-779anb" style="background-color: transparent; border: none; color: var(--ds-icon, #42526E); cursor: pointer; display: inline; font-family: inherit; opacity: 0; outline: none; padding-left: 0px; padding-right: 0px; right: 0px; transform: translate(-8px); transition: opacity 0.2s ease 0s, transform 0.2s ease 0s;"><span aria-label="Copiar" class="css-1afrefi" role="img" style="--icon-primary-color: var(--ds-icon-subtle, #6B778C); --icon-secondary-color: var(--ds-surface, #FFFFFF); display: inline-block; flex-shrink: 0; height: 24px; line-height: 1; width: 24px;"><svg height="24" role="presentation" viewbox="0 0 24 24" width="24"><g fill-rule="evenodd" fill="currentColor"><path d="M12.856 5.457l-.937.92a1.002 1.002 0 000 1.437 1.047 1.047 0 001.463 0l.984-.966c.967-.95 2.542-1.135 3.602-.288a2.54 2.54 0 01.203 3.81l-2.903 2.852a2.646 2.646 0 01-3.696 0l-1.11-1.09L9 13.57l1.108 1.089c1.822 1.788 4.802 1.788 6.622 0l2.905-2.852a4.558 4.558 0 00-.357-6.82c-1.893-1.517-4.695-1.226-6.422.47"></path><path d="M11.144 19.543l.937-.92a1.002 1.002 0 000-1.437 1.047 1.047 0 00-1.462 0l-.985.966c-.967.95-2.542 1.135-3.602.288a2.54 2.54 0 01-.203-3.81l2.903-2.852a2.646 2.646 0 013.696 0l1.11 1.09L15 11.43l-1.108-1.089c-1.822-1.788-4.802-1.788-6.622 0l-2.905 2.852a4.558 4.558 0 00.357 6.82c1.893 1.517 4.695 1.226 6.422-.47"></path></g></svg></span></button></span></h2><p data-renderer-start-pos="1061" style="caret-color: rgb(23, 43, 77); color: #172b4d; font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; font-size: 16px; letter-spacing: -0.005em; line-height: 1.714; margin: 0.75rem 0px 0px; padding: 0px; white-space: pre-wrap;">En el material de clase vienen varias definiciones. Lógicamente la del <em data-renderer-mark="true">Business Agility Institute</em>, pero también aparecen las de la <em data-renderer-mark="true">Agile Alliance,</em> el <em data-renderer-mark="true">Business Agility Manifesto </em>o el <em data-renderer-mark="true">Agile Business Consortium.</em> </p><p data-renderer-start-pos="1272" style="caret-color: rgb(23, 43, 77); color: #172b4d; font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; font-size: 16px; letter-spacing: -0.005em; line-height: 1.714; margin: 0.75rem 0px 0px; padding: 0px; white-space: pre-wrap;">Incluso cuando ampliamos el abanico y analizamos definiciones de agilidad empresarial proporcionadas por otros marcos de referencia o en bibliografía general, vemos que todas se refieren prácticamente a lo mismo: <em data-renderer-mark="true"><u data-renderer-mark="true">construir organizaciones capaces de adaptarse rápidamente a los cambios, manteniendo al cliente y sus necesidades en el centro de atención</u></em>. </p><p data-renderer-start-pos="1627" style="caret-color: rgb(23, 43, 77); color: #172b4d; font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; font-size: 16px; letter-spacing: -0.005em; line-height: 1.714; margin: 0.75rem 0px 0px; padding: 0px; white-space: pre-wrap;">Exploremos un poco más los conceptos comunes a todas estas definiciones:</p><p data-renderer-start-pos="790" style="caret-color: rgb(23, 43, 77); color: #172b4d; font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; font-size: 16px; letter-spacing: -0.005em; line-height: 1.714; margin: 0.75rem 0px 0px; padding: 0px; white-space: pre-wrap;"><strong data-renderer-mark="true"></strong></p><ul class="ak-ul" data-indent-level="1" style="box-sizing: border-box; caret-color: rgb(23, 43, 77); color: #172b4d; display: flow-root; font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; font-size: 16px; margin: 10px 0px 0px; padding: 0px 0px 0px 24px; white-space: pre-wrap;"><li><p data-renderer-start-pos="1703" style="font-size: 1em; letter-spacing: -0.005em; line-height: 1.714; margin: 0px; padding: 0px;"><strong data-renderer-mark="true">Foco en el Cliente</strong>. Todas las definiciones hablan de la capacidad de <strong data-renderer-mark="true">responder y de adaptarse</strong> a los cambios exteriores, en el sector, en el mercado o en el entorno en el que se sitúa la organización. También incluyen ideas al respecto del cambio en las necesidades o intereses de los clientes, y cuando profundizamos un poco más, vemos que en general las tendencias <strong data-renderer-mark="true">Outside-In</strong>, de las que ya hablábamos con USMBOK hace más de 10 años, se consolidan. El <strong data-renderer-mark="true">cliente</strong> le da sentido a la existencia de la empresa ágil y está en el centro de todo.</p></li><li style="margin-top: 4px;"><p data-renderer-start-pos="2245" style="font-size: 1em; letter-spacing: -0.005em; line-height: 1.714; margin: 0px; padding: 0px;"><strong data-renderer-mark="true">Innovación</strong>, como la capacidad de crear soluciones de negocio de manera rápida y eficiente. Soluciones que satisfacen esas necesidades cambiantes (y el cambio se produce a alta velocidad) en el mercado y los clientes.</p></li><li style="margin-top: 4px;"><p data-renderer-start-pos="2465" style="font-size: 1em; letter-spacing: -0.005em; line-height: 1.714; margin: 0px; padding: 0px;"><strong data-renderer-mark="true">Flexibilidad</strong>, como la capacidad de responder fácilmente a las demandas y necesidades de los clientes, a pequeñas variaciones en las necesidades, modificando y adaptando productos y servicios para cada uno de los consumidores. También vemos la flexibilidad en los procesos, en la manera de organizarnos y en la manera de ejecutar nuestro trabajo.</p></li><li style="margin-top: 4px;"><p data-renderer-start-pos="2814" style="font-size: 1em; letter-spacing: -0.005em; line-height: 1.714; margin: 0px; padding: 0px;"><strong data-renderer-mark="true">Aprendizaje y Mejora continua</strong>, como la capacidad de experimentar, aprender e incorporar los aprendizajes en los productos y los procesos productivos. La aproximación empírica al cambio, basada en el método científico, en el planteamiento de hipótesis y la realización de experimentos que nos ayuden a validar estas hipótesis y a cartografiar un terreno (el sector de negocio, el mercado) que cambia constantemente.</p></li><li style="margin-top: 4px;"><p data-renderer-start-pos="3232" style="font-size: 1em; letter-spacing: -0.005em; line-height: 1.714; margin: 0px; padding: 0px;"><strong data-renderer-mark="true">Colaboración</strong>, ser capaces de trabajar juntos de manera efectiva para alcanzar esos objetivos comunes, no sólo entre individuos, sino también a nivel de equipo, y de unidades organizativas mayores (que no siempre se corresponderán con la idea clásica de “departamento”).</p></li><li style="margin-top: 4px;"><p data-renderer-start-pos="3505" style="font-size: 1em; letter-spacing: -0.005em; line-height: 1.714; margin: 0px; padding: 0px;"><strong data-renderer-mark="true">Toma de decisiones rápidas y efectivas</strong>, basadas en información actualizada y que le permitan tener esa capacidad de responder y de cambiar de dirección con rapidez en caso necesario. Estructuras organizativas poco jerárquicas donde las decisiones se toman, de forma consciente y empoderada, cerca del lugar donde ocurre la acción.</p><p data-renderer-start-pos="3505" style="font-size: 1em; letter-spacing: -0.005em; line-height: 1.714; margin: 0px; padding: 0px;"><strong data-renderer-mark="true" style="font-size: 1.43em; letter-spacing: -0.008em;">La conexión con el modelo del BAI</strong></p><p data-renderer-start-pos="3505" style="font-size: 1em; letter-spacing: -0.005em; line-height: 1.714; margin: 0px; padding: 0px;"><strong data-renderer-mark="true" style="font-size: 1.43em; letter-spacing: -0.008em;"><span style="background-color: white; font-size: 16px; font-weight: 400; letter-spacing: -0.08px;">El modelo operativo del BAI se compone de 12 dominios interconectados estructurados en cuatro dimensiones: Relaciones, Liderazgo, Individuos y Operaciones.</span></strong></p><p data-renderer-start-pos="3505" style="font-size: 1em; letter-spacing: -0.005em; line-height: 1.714; margin: 0px; padding: 0px;"><strong data-renderer-mark="true" style="font-size: 1.43em; letter-spacing: -0.008em;"><span style="background-color: white; font-size: 16px; font-weight: 400; letter-spacing: -0.08px;"><br /></span></strong></p><p data-renderer-start-pos="3505" style="font-size: 1em; letter-spacing: -0.005em; line-height: 1.714; margin: 0px; padding: 0px;"><strong data-renderer-mark="true" style="font-size: 1.43em; letter-spacing: -0.008em;"></strong></p><div class="separator" style="clear: both; text-align: center;"><strong data-renderer-mark="true" style="font-size: 1.43em; letter-spacing: -0.008em;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgzO-w7tjDoTXpJyjfJpyQowov8StJxnlqHv8jfAHkWbfUMeH3KYLZtyjhXzGO91HM5AOjIT1ImagfuE-jl3_7lIYDDRaJaTwPhSXtwqvNqTgltWhjS1jBtBejyphwLY75w2WeNojambDxdtH8AWvppkqLx1JrPeE8bsxainlij_fPxr7Klbqs/s720/b20ab361-ab9a-4ed9-af74-33607f229bc4.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="720" data-original-width="719" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgzO-w7tjDoTXpJyjfJpyQowov8StJxnlqHv8jfAHkWbfUMeH3KYLZtyjhXzGO91HM5AOjIT1ImagfuE-jl3_7lIYDDRaJaTwPhSXtwqvNqTgltWhjS1jBtBejyphwLY75w2WeNojambDxdtH8AWvppkqLx1JrPeE8bsxainlij_fPxr7Klbqs/s320/b20ab361-ab9a-4ed9-af74-33607f229bc4.png" width="320" /></a></strong></div><p data-renderer-start-pos="3505" style="font-size: 1em; letter-spacing: -0.005em; line-height: 1.714; margin: 0px; padding: 0px;"><strong data-renderer-mark="true" style="font-size: 1.43em; letter-spacing: -0.008em;"><strong data-renderer-mark="true" style="font-size: 1.43em; letter-spacing: -0.008em;"><br /></strong></strong></p><p></p><p data-pm-slice="1 1 []" style="caret-color: rgb(0, 0, 0); color: black; white-space: normal;">Podemos conectar los conceptos comunes a las diferentes definiciones y los dominios del modelo de Agilidad Empresarial del BAI:</p><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgaGrdxRiCprnnUI0l6Rf07gd1Jvsc5McapHQQuDl46Px3cTq1ITQH1LIckU4OpbBbhnTSJjvi2_meep_rc840JNlhysjTw6KHbWTprDHPWBSbSumEcjpUiaI0abQiWhH5Dtk06TtfhhV2NzWtd6DJs0artsDYl9XJmaQqRbIQ3IK59AHCCR5o/s1388/1675670826306.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1388" data-original-width="1310" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgaGrdxRiCprnnUI0l6Rf07gd1Jvsc5McapHQQuDl46Px3cTq1ITQH1LIckU4OpbBbhnTSJjvi2_meep_rc840JNlhysjTw6KHbWTprDHPWBSbSumEcjpUiaI0abQiWhH5Dtk06TtfhhV2NzWtd6DJs0artsDYl9XJmaQqRbIQ3IK59AHCCR5o/w605-h640/1675670826306.png" width="605" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"><br /></div><h2 data-renderer-start-pos="3839" id="La-conexión-con-el-modelo-del-BAI" style="font-size: 1.43em; font-weight: 500; letter-spacing: -0.008em; line-height: 1.2; margin: 1.8em 0px 0px; padding: 0px; scroll-margin-top: 56px;"><span class="heading-anchor-wrapper" role="presentation" style="height: 1.2em; margin-left: 6px; position: absolute;"><button aria-label="Copiar enlace en el título" class="css-779anb" style="background-color: transparent; border: none; color: var(--ds-icon, #42526E); cursor: pointer; display: inline; font-family: inherit; opacity: 0; outline: none; padding-left: 0px; padding-right: 0px; right: 0px; transform: translate(-8px); transition: opacity 0.2s ease 0s, transform 0.2s ease 0s;"><span style="color: #172b4d; font-size: 16px; letter-spacing: -0.005em; text-align: left;">ativo del BAI se compone de 12 dominios interconectados estructurados en cuatro dimensiones: Relaciones, Liderazgo, Individuos y Operaciones</span></button></span></h2><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgihgm4z0b7siZGQ0NI_Fx1CXffHrk3Uw-1m4mt1zGPDvC8svyE_bUOwhNOsfa-1M9TbgqS_fx2QlfNPnXWYlnO4Jcczl3EC66rm1mnOD0EkHxsEIsSsSlcc9zRlEi8C1550sGtH_JbQESr2FCvzoxaoEiMl8Db4v8fpJN7zCUVZWYnLkvYSns/s1452/1675670874495.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1452" data-original-width="1304" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgihgm4z0b7siZGQ0NI_Fx1CXffHrk3Uw-1m4mt1zGPDvC8svyE_bUOwhNOsfa-1M9TbgqS_fx2QlfNPnXWYlnO4Jcczl3EC66rm1mnOD0EkHxsEIsSsSlcc9zRlEi8C1550sGtH_JbQESr2FCvzoxaoEiMl8Db4v8fpJN7zCUVZWYnLkvYSns/w574-h640/1675670874495.png" width="574" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: center;"><h2 data-pm-slice="1 1 []" style="caret-color: rgb(0, 0, 0); color: black; text-align: start; white-space: normal;">En Conclusion</h2><p style="caret-color: rgb(0, 0, 0); color: black; text-align: start; white-space: normal;">La Agilidad Empresarial no es un modelo, ni un framework ni una metodología. Se trata de un concepto que agrupa una serie de capacidades o características que deben tener las organizaciones para conseguir adaptarse rápidamente a un entorno incierto. De hecho, la definición del BAI dice, literalmente:</p><p style="caret-color: rgb(0, 0, 0); color: black; text-align: start; white-space: normal;"></p><blockquote>La Agilidad Empresarial es un conjunto de capacidades organizativas, comportamientos y formas de trabajar que le brindan a su empresa la libertad y flexibilidad para lograr su propósito.</blockquote><p></p><p style="caret-color: rgb(0, 0, 0); color: black; text-align: start; white-space: normal;">El modelo del Business Agility Institute es un marco de referencia global, que aborda de manera estructurada todos los conceptos comunes que encontramos en las diferentes definiciones de Agilidad Empresarial.</p><p style="caret-color: rgb(0, 0, 0); color: black; text-align: start; white-space: normal;">Por otra parte, el curso de preparación a la certificación de la Global Trust Association revisa todos los dominios de este modelo, aportando los conceptos, una visión de las herramientas y artefactos que se pueden utilizar en cada área y sirve como <em>Piedra de Rosetta</em> para un área de conocimiento que es, sin duda, relevante y muy extensa.</p></div><br /></li></ul>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.com0tag:blogger.com,1999:blog-24620302.post-28327172537885217262022-08-15T14:08:00.003+02:002022-08-15T14:13:05.580+02:00Los retos en la Minería de Procesos<div>Hace un rato <a href="https://www.linkedin.com/in/alexballarin/" target="_blank">Alex Ballarin 🇺🇦</a> me ha mencionado en un comentario a un post sobre Minería de Procesos y mi respuesta terminaba con una frase de estas “apisonadora”: </div><div><br /></div><div style="text-align: left;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgsblG2ySvDnriBvY7xLurmqWOBihaZwtkIDKvgkZV2bgThUfU0XP6Opx9f2M-XnpbtC7Z36UUYtGJZHgrzeeUe1IQWfwMSW9MlI4GIX40iPqd45ASE-02HUYdXqy25BVRmlR-pFwenXXpuC-Biwgh5DOcCTQp6YebtJL9Be4zVVfYQagN9db8" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="630" data-original-width="1200" height="168" src="https://blogger.googleusercontent.com/img/a/AVvXsEgsblG2ySvDnriBvY7xLurmqWOBihaZwtkIDKvgkZV2bgThUfU0XP6Opx9f2M-XnpbtC7Z36UUYtGJZHgrzeeUe1IQWfwMSW9MlI4GIX40iPqd45ASE-02HUYdXqy25BVRmlR-pFwenXXpuC-Biwgh5DOcCTQp6YebtJL9Be4zVVfYQagN9db8" width="320" /></a></div><br /><br /></div><div>Y después me quedé pensando: "Esto se merece una explicación."</div><div><br /></div><div>En G2 (<a href="https://www.gedos.es">gedos.es</a>) llevamos más de 10 años ejecutando proyectos de minería de procesos. Estos proyectos nos han dado una gran experiencia en las diferentes fases por las que pasa, no ya el proyecto de minería, sino la iniciativa completa de minería de procesos dentro de una compañía. Nos han enseñado no sólo a analizar procesos sino a entender los retos de negocio que aparecen detrás de cada una de estas iniciativas.</div><div><br /></div><div><b>Todo empieza con la curiosidad:</b> alguien ve una presentación, o atiende a una demo, o lee un artículo y piensa “esto seguro que en mi empresa daría unos resultados increíbles”. Cuando ves tu primera demo de minería de procesos la cosa es tan mágica, tan impresionante, que rápidamente se te ocurren casos de uso en tu compañía.</div><div><br /></div><div><b>Después viene el intentar llevarlo a casa:</b> conseguir la financiación para un proyecto piloto de una tecnología mágica y novedosa de la que poca gente ha oído hablar era difícil hasta hace unos años. Ahora todo el mundo habla de las bondades de la minería de procesos y por lo tanto es una tecnología bastante más extendida y eso ayuda. Aún así, el punto débil de un piloto de este tipo es conseguir los datos y eso no es siempre del fácil. Aquí podría abrir un artículo completo al respecto de los problemas organizativos que aparecen en una gran compañía cuando alguien pide los datos de un proceso de negocio; sobre todo si no es el propietario del proceso quien lo hace, pero como decía Michael Ende, "<i>eso es otra historia y debe ser contada en otra ocasión</i>".</div><div><br /></div><div>Se hace un piloto y se ven los resultados, y todos quedan con la boca abierta diciendo “🤩oooh, esto es fantástico”. </div><div><br /></div><div><b>¿Seguro?</b></div><div><br /></div><div><b>Pues no</b>. Aquí empieza el calvario cultural y psicológico de la persona que está impulsando la iniciativa: una de las primeras cosas que aporta la minería de procesos es <b>transparencia</b> al proceso. De repente, como en una radiografía, se ven las interioridades del proceso: es fácil comenzar con el (mal) juego del finger pointing, apuntando a departamentos, productos o incluso personas individuales donde aparecen los problemas del proceso. </div><div><br /></div><div></div><blockquote><div>De repente, como en una radiografía, se ven las interioridades del proceso.</div><div></div></blockquote><div><br /></div><div><b>Aquí es donde se notan los años de experiencia:</b> visión sistémica, atacar al sistema y no a la persona, descubrir qué es lo que produce (el conjunto de causas) los atascos y cuellos de botella, expresar los hallazgos en términos de negocio y no en términos de operativa, técnicos o de proceso. En definitiva, usar la minería de procesos como una herramienta más para la mejora continua del proceso.</div><div><br /></div><div>Si consigues superar esta etapa, la siguiente no va a ser más fácil: ¿Has visto el final del párrafo anterior? Pone “<i>mejora continua del proceso</i>”. Es decir, la siguiente fase, que tiene que ver con <b>institucionalizar la minería de procesos</b> en la compañía, depende totalmente de la cultura de transparencia y mejora que haya en tu compañía. </div><div><br /></div><div>Hacen falta valores de esos que están muy enraizados en las compañías Lean y Agile: <b>transparencia, coraje, empoderamiento, deseo de “ser los mejores en mejorar”. </b></div><div><br /></div><div>Y recordemos que el cliente objetivo de las grandes compañías de minería de procesos no son precisamente pymes y startups, sino grandes empresas con grandes y costosos procesos de negocio en los que el <i>business case</i> sea magnífico. Empresas en las que es más difícil encontrar la tranquilidad de ejecutar una herramienta que saque los trapos sucios de los procesos de negocio, que señale las ineficiencias y que nos ayude a pensar en qué y cómo debemos mejorar los procesos. </div><div><br /></div><div>Pero, en definitiva, empresas en las que la apuesta por la mejora puede tener un<b> impacto económico millonario.</b></div><div><br /></div><div>Pero en el mundo de las grandes empresas asumir errores, mostrar ineficiencias, declarar transparentemente que las cosas tal y como las hacemos hoy son muy mejorables es muy difícil. También es muy difícil conseguir la complicidad y el compromiso de aquellos que tienen que impulsar el cambio.</div><div><br /></div><div>Ojo, hay empresas enormes en las que la cultura facilita estas cosas, pero creo que podemos afirmar sin temor a equivocarnos que son las menos.</div><div><br /></div><div>Por eso <b>el reto es más psicológico y cultural</b>. Tiene mucho que ver con la humildad en el liderazgo, con estar dispuesto a ver la viga en el ojo propio y a tener el valor de cambiar las cosas. </div><div><br /></div><div>Y tiene que ver con cómo se lleva adelante la iniciativa de Minería de Procesos: si se hace desde fuera del proceso el fracaso está garantizado. Si se hace desde dentro, todo irá mejor, pero el reto será conseguir el compromiso y el tiempo.</div><div><br /></div><div>¿Estas preparado? ¿Estas preparada?</div><div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjSQlSNy6lA519dnNsQ9FQn72RclpK7wHRfwcDeYkdo3i9DMtaCBpYcxtWBWDv1JSo7zseOzgnivM6BySU8nGzT2iDfbA_8u7AUdOE8cM_RjzhqbAfKp1HzMmYrTiurOs7F8wqAuS2gJQSiG6C7yhgoLdhPih0XIFoUv-7Y4VOZDMvDYS4p-QQ" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="1105" data-original-width="1280" height="240" src="https://blogger.googleusercontent.com/img/a/AVvXsEjSQlSNy6lA519dnNsQ9FQn72RclpK7wHRfwcDeYkdo3i9DMtaCBpYcxtWBWDv1JSo7zseOzgnivM6BySU8nGzT2iDfbA_8u7AUdOE8cM_RjzhqbAfKp1HzMmYrTiurOs7F8wqAuS2gJQSiG6C7yhgoLdhPih0XIFoUv-7Y4VOZDMvDYS4p-QQ" width="278" /></a></div><br /><br /></div>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.com0tag:blogger.com,1999:blog-24620302.post-73428656601655320642020-05-03T22:04:00.002+02:002020-05-03T22:10:05.964+02:00Necesito una Unidad de Intervención Inmediata<div>Frecuentemente cuando se ponen en marcha nuevos servicios, incidimos sobre cientos de usuarios que deben adquirir rápidamente nuevos conocimientos y adaptarse a nuevas maneras de trabajar. Es en este momento cuando necesitamos poner foco en una Gestión del Cambio precisa y especializada que nos ayude a conseguir poner a todas estas personas en marcha rápidamente.</div><div><br /></div><h2 style="text-align: left;"><b><font size="4">El problema</font></b></h2><div>Cuando hacemos este tipo de despliegues, se produce un rápido aumento de las necesidades de soporte: gran cantidad de usuarios necesitan apoyo en un corto espacio de tiempo. Los equipos de soporte se ven fuertemente afectados por esta situación, que además deben combinar con dar apoyo a las necesidades cotidianas del negocio.</div><div><br /></div><div>La gestión del cambio debe proporcionar una base de conocimientos, materiales de formación y procedimientos que sean comprensibles, que se mantengan actualizados y que sobre todo puedan ser consultados de manera fácil por los usuarios afectados.</div><div><br /></div><h2 style="text-align: left;"><b><font size="4">La solución</font></b></h2><div>El empleo de soluciones especializadas y temporales, que puedan montarse, usarse y desmontarse fácilmente y en modalidad de pago por uso. Soluciones que no interfieran con los entornos corporativos y que proporcionen la flexibilidad y el acceso global que requieren los usuarios.</div><div><br /></div><h2 style="text-align: left;"><b><font size="4">La Propuesta de G2</font></b></h2><div>El próximo Jueves 7 de Mayo de 2020 haremos un webinar explicando cómo montamos una de estas plataformas express para habilitar una Unidad de Intervención Inmediata. </div><div><br /></div><div>Inscríbete aquí: <a href="https://atlassian.gedos.es/inscripcion-webinar/ " target="_blank">https://atlassian.gedos.es/inscripcion-webinar/ </a></div><div class="separator" style="clear: both; text-align: center;"><a href="https://atlassian.gedos.es/inscripcion-webinar/ " style="margin-left: 1em; margin-right: 1em;" target="_blank"><img border="0" data-original-height="627" data-original-width="1200" height="209" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_Y3fS1zYyIyw-eX72n1YNRvRxdSM00UjnJUgtxyeMgqMsgbjLgXEkLqPmvkpqgi9oXbazyvll3MEfpXV-E8t3uwz923gd6BnZbMi0QT_I5MbTRgn4AFQ91exDOAKZrKfl88exKA/w400-h209/banner-linked-Atlassian-v2-2.jpg" width="400" /></a></div><div><br /></div><div><h2 style="text-align: left;"><font size="4"><b>El Service Desk como Unidad de Intervención Inmediata</b></font></h2><div>Llevo en el sector de las TIC unos 33 años y desarrollando proyectos unos 28. Aún así, mis participaciones en proyectos de software más intensas se han dado durante los últimos 10 años, temporada en la que desde G2 hemos hecho una suave deriva dentro de la gestión de servicios a la gestión completa del ciclo de vida del servicio, cosa que me ha permitido participar en los equipos de desarrollo aportando visiones de Lean, de Agile y de DevOps.</div><div><br /></div><div>Durante estos años, una de las lecciones más importantes que he aprendido es que no hay DONE sin Materialización del Valor. Es decir, que por mucho que los equipos de desarrollo piensen que han finalizado un paquete de funcionalidades, hasta que no están en manos de usuario y siendo utilizadas, no son más que promesas incumplidas de un valor futuro.</div><div><br /></div><div>Ya escribía sobre esto aquí</div><div><br /></div><div><a href="http://www.gobiernotic.es/2009/12/el-ultimo-del-ano-y-va-sobre-valor.html" target="_blank">http://www.gobiernotic.es/2009/12/el-ultimo-del-ano-y-va-sobre-valor.html</a></div><div><br /></div><div>y aquí</div><div><br /></div><div><a href="http://www.gobiernotic.es/2010/05/la-evolucion-cuantica.html" target="_blank">http://www.gobiernotic.es/2010/05/la-evolucion-cuantica.html</a></div><div><br /></div><div>Ya más maduro, sobre el año 2013 reflexionaba sobre la problemática que nos presentaba el hecho de acelerar el flujo utilizando técnicas de automatización y el cuello de botella se trasladaba a otro sitio: <b>el usuario, la última frontera.</b></div><div><br /></div><div><a href="http://www.gobiernotic.es/2013/06/el-punto-debil-de-devops.html" target="_blank">http://www.gobiernotic.es/2013/06/el-punto-debil-de-devops.html</a></div><div><br /></div><div>Así que llegamos a la conclusión de que una de las fases que más pueden influir en la materialización del valor generado por un proyecto es la de la <b>Gestión del Cambio</b>: poner en manos de los usuarios la nueva aplicación y conseguir desplegar lo antes posible y sobre el número de usuarios adecuados, el conocimiento, la práctica y los nuevos circuitos que harán que la promesa de valor se convierta en realidad.</div><div><br /></div><div><i>¿De qué serviría un nuevo sistema para canalizar las oportunidades de venta que llegan por los diferentes canales si los comerciales no lo saben usar o lo usan mal?</i></div><div><br /></div><div><i>¿De qué serviría el precioso sistema de seguimiento de indicadores si los que deben tomar decisiones en base a esos indicadores no lo saben usar o aquellos que alimentan los datos lo hacen mal o a deshora?</i></div><div><br /></div><div><i>¿Cómo diablos vamos a conseguir poner a todas esas personas en teletrabajo si cuando les damos las herramientas técnicas no saben usarlas?</i></div><div><br /></div><div>Así, pues, se nos hace fundamental ayudar a los equipos en esta etapa de Gestión del Cambio, y tradicionalmente las empresas ponen foco en una serie de acciones: </div><div><br /></div><div><ul style="text-align: left;"><li>generación de materiales de formación</li><li>formación a usuarios clave</li><li>formación a formadores</li><li>formación al equipo de soporte</li><li>documentación de las preguntas más frecuentes</li></ul></div><div><br /></div><div>Pero... <b> ¿A qué se parece la realidad cuando te enfrentas a desplegar una solución para cientos o miles de usuarios? </b></div><div><br /></div><div>Pues lo <b>primero</b> que te pasa es que la aproximación de formar a usuarios claves o formación de formadores es quizás un poco lejana al usuario final. </div><div><br /></div><div>Tardas demasiado en llegar a ellos y con personas que en realidad son “<i>proxies</i>” del conocimiento: muy buena tiene que ser la formación a formadores (teórica y práctica) para que ellos puedan transmitir de manera fluida todo lo que se supone que debe saber el usuario final. Y muy buenos tienen que ser los materiales de formación, no podemos aspirar a que ellos generen sus propios materiales.</div><div><br /></div><div>Lo <b>segundo</b> es que habrá situaciones que hayan quedado fuera de la formación y que durante las sesiones de formación a usuario final aparezcan en forma de preguntas que el recién estrenado profesor no sea capaz de resolver. ¿Tenemos un canal para poner en contacto al profesor con el equipo de desarrollo para que le resuelvan la duda de un día para otro? ¿Tenemos una manera de documentar este conocimiento modificando rápidamente el material de formación o de consulta?</div><div><br /></div><div><b>En tercer lugar</b>, los recién formados alumnos comienzan a trabajar con el nuevo sistema y lógicamente tienen dudas, encuentran cosas que no saben hacer o peor aún, encuentran errores. Esto, que en condiciones normales significaría una pequeña porción del trabajo habitual del Centro de Soporte, se puede convertir rápidamente en una avalancha de llamadas para las que, por si fuera poco, el técnico de soporte debe invertir mucho más tiempo en resolver porque a) no tiene la práctica y la formación habitual (es un producto nuevo) y b) necesita dar formación al usuario, dando una respuesta que al tiempo de resolver su problema, sea pedagógica para facilitar la incorporación del usuario en la nueva solución.</div><div><br /></div><div><b>Para terminar</b> de rizar el rizo, nos vamos a encontrar con que si el Centro de Soporte está colapsado atendiendo este tipo de interacciones, ¿cómo vamos a atender los contactos habituales, los que se refieren a otro tipo de servicios que incluso podrían ser más prioritarios? ¿Cómo atenderemos el <i>Business as Usual</i>?</div><div><br /></div><div>En definitiva, vemos que para una situación más o menos excepcional como es el roll-out de un proyecto que tiene afectación a un elevado número de usuarios en un breve espacio de tiempo, debemos buscar soluciones adecuadas y excepcionales, huyendo de la solución tradicional de “<i>lo pasaremos a través de soporte </i>” y construyendo una solución adecuada a esta situación de trato especial al usuario. (de hecho, a esta fase de los proyectos se le llama precisamente la fase de <i>HyperCare</i>)</div><div><br /></div><div>Posiblemente pensarás que este tipo de <i>roll-outs</i> son poco habituales, que las cosas las hacemos de manera iterativa e incremental y que eso de un gran proyecto en modo cascada está pasado de moda. Te doy toda la razón del mundo, pero también es cierto que la gran mayoría de proyectos que significan sustituir una plataforma por otra, aquellos que tienen una puesta en marcha en formato big-bang, aquellos que ponen un producto mínimo viable en manos de un gran número de usuarios y todos aquellos que se ponen en marcha por motivos de extremada urgencia (por ejemplo, motivados por la activación de planes de continuidad) son candidatos a recibir este tipo de tratamiento. </div><div><br /></div><h2 style="text-align: left;"><b><font size="4">¿Y cuál es la respuesta?</font></b></h2><div><br /></div><div>Bueno, en <a href="https://www.gedos.es" target="_blank">G2</a> llevamos tiempo ya dándole vueltas a esto y ayudando a nuestros clientes a crear esto que llamamos <b>Unidades de Intervención Inmediata.</b> </div><div><br /></div><div>Para ello, nos inspiramos en el concepto de <a href="https://es.wikipedia.org/wiki/Arquitectura_ef%C3%ADmera" target="_blank">Arquitectura Efímera</a>: son instalaciones que se diseñan y se piensan teniendo en cuenta que serán poco duraderas. Están orientadas a transmitir sensaciones, mensajes o emociones a través de las formas durante un breve espacio de tiempo (semanas o quizás meses), como puede ser una instalación artística en un aeropuerto, el stand alucinante que viste en la última feria a la que asististe o un hospital de campaña montado de manera urgente para atender una situación como la que estamos viviendo.</div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><img border="0" data-original-height="2160" data-original-width="3840" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3s_ll8FKlwHXkOhyphenhyphenff65dWC15fTYt2HMnspSj2Vdasfl7_IpwMN_J8p8yxGasPTusKd06fTT4qDgjyMhQqtd8wfdDFOf1rKZ8o9AGCnOQ-d2fOSpnUuuGKaJAsrSsUvDfGulDAQ/w320-h180/vistas-cama-atardecer.jpg" width="320" /></div><div><br /></div><div><br /></div><div>Estas arquitecturas efímeras están pensadas para transmitir un mensaje concreto durante un tiempo concreto, de la misma manera que en IT necesitamos transmitir un mensaje concreto (la tranquilidad de dar el paso a usar una nueva herramienta) durante un tiempo concreto (el que necesite el negocio hasta haber estabilizado el uso del nuevo sistema).</div><div><br /></div><div>Así, nuestra propuesta es la generación de una plataforma de soporte completamente nueva, especialmente orientada a apoyar a los usuarios en la transición a esta nueva manera de trabajar que supone el despliegue del nuevo servicio y que se concibe desde el inicio como una plataforma efímera: se monta rápido, se usa rápido, se destruye rápido y sólo se paga por el tiempo que se usa.</div><div><br /></div><div>El próximo <b>Jueves 7 de Mayo de 2020</b> haremos un webinar explicando cómo montamos una de estas plataformas express para habilitar una Unidad de Intervención Inmediata. En esta charla veremos cuáles son las ventajas que le aporta al cliente, tanto al equipo de soporte, como al equipo de administración de herramientas y a los usuarios finales.</div><div><br /></div><div>Si te ha picado el gusanillo de la curiosidad, <a href="https://atlassian.gedos.es/inscripcion-webinar/">inscríbete en nuestra página del G2 Atlassian Team</a> y trae preparadas todas las preguntas que quieras plantearle al equipo que con gusto las resolveremos.</div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://atlassian.gedos.es/inscripcion-webinar/" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="627" data-original-width="1200" height="209" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhq3hIDThW5wflIfvHmV0Mjgf5TTQmAHKsGZuV5lnX87Zv7JZ4FkZIjeh_WN5rlsXdC6xNdSnCYtNqzD_XQiE3nO2Ob2x5ga1lURR_yqQsHKjCFI3GBXb6X9TDmf551m8J4mkAU4g/w400-h209/banner-linked-Atlassian-v2-2.jpg" width="400" /></a></div><div><br /></div><div><br /></div></div>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.com0tag:blogger.com,1999:blog-24620302.post-81280439390195089352020-03-20T13:36:00.004+01:002020-03-20T14:36:21.460+01:00Algunos consejos de higiene mental para el teletrabajo<p>Estamos en una situación realmente excepcional, histórica. Hace menos de diez días paseábamos por las calles, tomábamos cervezas y reíamos con los amigos y ahora, de repente, estamos todos encerrados en nuestras casas.</p><p>Algunos, muy afortunados, podemos hacer teletrabajo.</p><p><strong>El primer día fue atómico.</strong> Yo ya estaba acostumbrado y practicaba. teletrabajo frecuentemente; en G2 varios compañeros trabajaban de forma diaria en esta modalidad y otros tenían al menos uno o dos días por semana… pero esto es diferente: quienes no estaban acostumbrados a esto eran los clientes (!)</p><p>Llamadas, whatsaps, mensajes, correos, videoconferencias…. de todo y en todo momento. Un caos!</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiXZ6sfCnvMmWJdiFEYeaYe4gdrEHaRQfiLiekVLskpbvIr_97eirk-tCFbVJ_HCkAeBq5RBTg87hR2NAh6WKaZnJMAjiZLAezQG_0aNW0jN8Cx-Gq6T5H2eeNbtVow2ZmCt92nrA/s1600/WhatsApp+Image+2020-03-12+at+14.50.33.jpeg"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiXZ6sfCnvMmWJdiFEYeaYe4gdrEHaRQfiLiekVLskpbvIr_97eirk-tCFbVJ_HCkAeBq5RBTg87hR2NAh6WKaZnJMAjiZLAezQG_0aNW0jN8Cx-Gq6T5H2eeNbtVow2ZmCt92nrA/s320/WhatsApp+Image+2020-03-12+at+14.50.33.jpeg" alt="image-16" width="1600" style="max-width: 100%;"></a></div><p dir="ltr"><strong><br>El segundo día fue mejor</strong>. Todo se iba estabilizando lentamente, la gente cogía costumbre y estábamos más sueltos; ahora bien: el caos de herramientas continuaba siendo un problema. De ahí en adelante todo ha ido a mejor en términos de. organización, coordinación y capacidad de apoyo a los clientes.</p><p>Aún así, poco a poco se iban perfilando en mi cabeza algunas prácticas que me gustaría compartir y que son las que estoy aplicando para mantener mi <strong>higiene mental</strong>. Es decir, ademas de mantener la seguridad en casa, el confinamiento y las reglas estrictas de distanciamiento social y limpieza, es necesario mantener la higiene dentro de tu cabeza para no terminar desquiciada. Asi que vamos allá:</p><p><strong>1.- UNIFICACION DE HERRAMIENTAS:</strong></p><p>Ya sabemos que el multitasking es un enemigo importante de nuestra cabeza. La capacidad de concentración, la capacidad de atención y la productividad personal se ven fuertemente afectadas por el multitasking. Pues resulta que intentar mantener la atención en siete medios de comunicación diferentes, y además siete medios que tratan de luchar por captar tu atención, es horroroso!</p><p><a href="https://www.moma.org/interactives/exhibitions/2011/talktome/objects/145523/"></a><a href="https://www.blogger.com/u/1/blogger.g?blogID=24620302"></a>Pacta con tus compañeros / clientes las herramientas de comunicación que vas a usar y trata de unificar todo lo que puedas. No es viable para una cabeza normal estar atenta a Teams, Meet, Whatsapp, Zoom, iMessage, Telegram , correo, slack, etc.</p><p>Nosotros hemos tratado de condensar todo esto en Teams. Algunos clientes usan otros sistemas, pero al menos entre nosotros y con los clientes con los que estamos trabajando más intensamente, hemos reducido los canales.</p><p><strong>2.- SE EXQUISITO CON LAS NOTIFICACIONES:</strong></p><p>Venimos de un mundo en el que la lucha por tu atención era lo más importante en el marketing, así que todo está lleno de "artefactos" pensados especialmente para capturar tu atención. Antes era importante gestionar bien esto; ahora es imprescindible.</p><p>Una de las obras de arte que se exponen en el MOMA es “The hierarchy of Digital Distractions”. Esta obra representa claramente la situación en la que te vas a encontrar: todos intentando captar tu atención, tanto en el mundo digital, como en el mundo físico. Es agotador!</p><div class="separator" style="clear: both; text-align: center;"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-S-2B0JKpGl1XLf8_JcGbMPRuXnuFxvwdAM7iCwlRBsN34AcUW-pAI51NRHk23IulN6VQ96ehm1sarvH7AUDid5H1JFMpMrvFw1RULvslNQ3yFqJl7xpwQ8TOuMmLq6DIa8W69g/s320/TTM_104-large.jpg" alt="image-18" width="1200" style="max-width: 100%;"></div><p><a href="https://www.moma.org/interactives/exhibitions/2011/talktome/objects/145523/">https://www.moma.org/interactives/exhibitions/2011/talktome/objects/145523/</a></p><p dir="ltr"><br>Mi consejo aquí es que silencies grupos, desactives todas las notificaciones que puedas en tu teléfono, que desactives todos los pop-ups posibles en tu PC y que trabajes con el teléfono boca abajo para que no te distraiga.</p><p><strong>3.- CUIDADO CON LA INFOXICACION</strong></p><p>Estamos pasando momentos duros, eso es innegable. Pero estar leyendo las noticias todo el dia, atento al último minuto y a la última cifra, no contribuye en nada a tu bienestar.</p><p>Aquí me permito el lujo de poner una cita de <strong>Dune</strong>, uno de mis libros favoritos y que me he leído ya ni se cuantas veces. Contiene verdaderas perlas de sabiduría como esta:</p><blockquote>“No conoceré el miedo. El miedo mata la mente. El miedo es la pequeña muerte que conduce a la destrucción total. Afrontaré mi miedo. Permitiré que pase sobre mí y a través de mí. Y cuando haya pasado girare mi ojo interior para escrutar su camino. Allá donde haya pasado el miedo ya no habrá nada. Solo estare yo.”</blockquote><p>Asi, mi consejo es leer las noticias como mucho una vez al día y habilitar los mensajes de los servicios de emergencia de tu zona por si acaso y no mucho más. El siguiente hashtag será #NoTeRayes para combatir el #YoMeRayoEnCasa</p><p>**4.- CUIDA TUS HORARIOS:**Se habla mucho de los horarios, de la rutina, etc. Aparte de esto, yo tengo un consejo más que darte: cuida tu horario de pantallas. Nos pasamos un chorro de horas conectados para teletrabajar. No puede ser que al finalizar la jornada sigas enganchado a la tele, a la consola, al móvil… Asi que al menos ponte un límite: nada de pantallas durante un rato en el día y nada de internet tres horas antes de irte a la cama.</p><p>Este último punto es importante: conozco a varias personas que sufren ataques de ansiedad nocturnos provocados por ese último artículo que leyeron en la cama.</p><p><strong>5.- CUIDADO CON TWITTER</strong><br>Twitter es una fuente inagotable de fake news, de charlatanes y de gente compitiendo por ver quien la dice más gorda. Es cierto que tambien hay muy buena gente y muy buena información, pero hay que saber filtrar, y filtrar cansa.</p><p>NO leas twitter por la noche.<br>NO te creas todo lo que leas<br>NO retuitees sin contrastar la informacion<br>NO estes todo el día pegado a twitter</p><p>Piénsalo bien, ¿de qué te sirve ser una persona super informada, al minuto? La situación es chunga, está claro. Cambia día a día, es cierto. Pero no cambia minuto a minuto.</p><p><strong>6.- RELAX</strong><br>Tu mente necesita descansar. Tu mente necesita desconectar. Yo eso lo consigo con sesiones cortas de meditación guiada. No voy a decir que soy un practicante experto de mindfulness, pero es algo que me ha ayudado mucho en los últimos años.</p><p>Si no sabes cómo desconectar o cómo relajarte o cómo meditar, aquí te dejo una lista de reproducción que es la que yo uso.</p><div class="embed-wrapper" data-url="www.youtube.com/watch?v=_yjgcb5MEGw" style="clear: both; text-align: center;"><iframe width="480" height="270" src="https://www.youtube.com/embed/_yjgcb5MEGw" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe></div><div class="embed-wrapper" data-url="www.youtube.com/watch?v=_yjgcb5MEGw" style="clear: both; text-align: center;"><iframe width="480" height="270" src="https://www.youtube.com/embed/_yjgcb5MEGw" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe></div><div class="embed-wrapper" data-url="www.youtube.com/watch?v=_yjgcb5MEGw" style="clear: both; text-align: center;"><iframe width="480" height="270" src="https://www.youtube.com/embed/_yjgcb5MEGw" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe></div><div class="embed-wrapper" data-url="www.youtube.com/watch?v=_yjgcb5MEGw" style="clear: both; text-align: center;"><iframe width="480" height="270" src="https://www.youtube.com/embed/_yjgcb5MEGw" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe></div><div class="embed-wrapper" data-url="www.youtube.com/watch?v=_yjgcb5MEGw" style="clear: both; text-align: center;"><iframe width="480" height="270" src="https://www.youtube.com/embed/_yjgcb5MEGw" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe></div>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.com0tag:blogger.com,1999:blog-24620302.post-70374403040889681712018-12-19T18:20:00.007+01:002018-12-19T18:55:59.595+01:00Las amebas y la estrategia<p>¿Has visto alguna vez una ameba? Al microscopio, en vivo y en directo… en la EGB, quizás? en el Instituto?<br></p><div class="separator" style="clear: both; text-align: center;"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTMhxqT5JTK9mE_DsFC9nwPfG5j4jHfH_59mIuT3QS1ByO1dcLe2wih1Kj0ScmilEUhFQWV0zwVqJer46HUklLPyfEcd1Rr9_L3YRfcZ7-pyqm9zgfjGRxT8yOT4LgY2rfeY-TDA/s9999/nombre-cientifico-ameba-naegleria-fowleri_LPRIMA20160927_0134_34.png" width="667" style="max-width: 100%;"></div><p>Una ameba es un ser vivo unicelular, no tiene cilios ni flagelos, como podrían tenerlos un paramecio o un vibrión colérico. Una ameba se mueve emitiendo pseudópodos, arrastrando lentamente parte de la masa celular en el sentido en que se quiere desplazar y luego moviendo el resto de la célula completa hacia allí.</p><p dir="ltr">Cuando se quiere alimentar, emite dos pseudópodos que rodean la partícula que quiere absorber hasta que éstos se unen y fusionan, dejando a la particula dentro de la ameba.</p><div class="custom-html-block"><iframe width="560" height="315" src="http://www.youtube.com/embed/x1ErCyZCFw8?controls=0" frameborder="0" allow="accelerometer;autoplay;encrypted-media;gyroscope;picture-in-picture" allowfullscreen=""></iframe></div><p><br></p><h3>Pues las empresas son como las amebas.</h3><p>Llevo años explicando esto en mis clases, primero cuando hablaba de mejora continua en ITIL, después cuando hablaba de mejora continua en ISO/IEC 20000, luego cuando hablaba de mejora continua en Lean y últimamente cuando hablo de mejora continua en Agile. Es mi forma de ver la importancia que tiene el impacto que tiene desplegar el pensamiento estratégico hacia toda la organización cuando estamos fomentando una cultura de mejora continua. Y sin embargo, repasando este blog nunca había escrito sobre la ameba.</p><p>Pero hoy he visto un post de <a href="https://www.linkedin.com/feed/update/urn:li:activity:6480937309297475584/" target="_blank">Txell Costa</a> donde hace una metáfora parecida pero con una goma elástica… y por eso me he decidido a escribir sobre la relación que hay entre un ser unicelular, microscópico, sin cilios ni flagelos, que se mueve por medio de pseudópodos … y tu empresa.</p><p>Las empresas son como las amebas. Emiten un pseudópodo y exploran nuevos territorios, como tú cuando tocas el agua de la playa con la punta del pie antes de meterte, tanteando a ver si está demasiado fría. Estos nuevos territorios pueden ser nuevos mercados, nuevos productos, nuevas maneras de hacer, nuevas maneras de organizar… emiten un pseudópodo y tantean y, si les parece que el agua está de su gusto, se tiran (algunas de cabeza y otras de culo… ya sabemos cómo va esto...)</p><p>En un entorno tradicional y jerarquizado, la alta direccion sabe a dónde quiere ir, y cuáles son los planes estratégicos para los próximos 5 años. La visión es clara y dirige el timón con mano férrea hacia ese horizonte que se ha planteado. En estos casos, transmitir la estrategia a los trabajadores no es necesario, es incluso contraproducente, no vaya a ser que alguien se vaya de la lengua, cuente nuestros planes y la competencia acabe adelantándonos.<ironic mode off></p><p>Y qué pasa con la mejora continua? Los pequeños movimientos evolutivos no forman parte de aquellos grandes planes estratégicos, asi que aparece otra manera de avanzar: el <strong>modo ameba,</strong> en el que pequeños grupos de personas dentro de la organización se plantean pequeñas mejoras que hacen más eficiente el sistema o más valioso el producto final. Esas pequeñas mejoras se plantean como pruebas o experimentos (Da igual cuál sea el modelo de mejora continua que uses, más tarde o más temprano aparece el Dr. Deming con su ciclo PDCA y el planteamiento de experimentos… no conozco ningún modelo de mejora continua que no pase por ahí)</p><p dir="ltr">Bien. Ya he puesto en tu cabeza la imagen de la amena extendiendo sus pseudópodos para experimentar un nuevo terreno.</p><p dir="ltr">¿Funcionará bien la nueva manera de gestionar pedidos? Hacemos un piloto, probamos un MVP, hacemos una prueba con un par de clientes, extendemos a “friends & family” y si todo va como debe ir, pues ¡adelante!</p><p>Pero los métodos modernos de mejora continua tratan de conseguir un factor multiplicador involucrando a todo el personal de la organización (a lavez que potencian la cultura, empoderan al personal y un buen atado de otras ventajas). Se trata de paralelizar el modelo evolutivo y conseguir un pipeline continuo de experimentos. Hasta llegar al extremo asombroso de <a href="https://blog.usejournal.com/how-booking-com-a-b-tests-ten-novenonagintillion-versions-of-its-site-25fc3a9e875b" target="_blank">booking.com y sus 2^1000 versiones concurrentes de la web</a>. Esto significa que estamos montando modelos de mejora continua que tratan de conseguir multitud de pequeños equipos distribuidos por la organización haciendo experimentos y provocando pequeños cambios que, en algunos casos, pueden resultar interesantes y provocar una tensión de movimiento “hacia allí"</p><p dir="ltr">Pero ¡atención! No estamos hablando de un ser pluricelular que hace muchos experimentos, sino de una pobre y triste ameba, unicelular y sin cilios ni flagelos.</p><p dir="ltr">¿Qué le pasa a la ameba si de repente emite 50 pseudópodos en direcciones opuestas y se empeña en moverse?</p><p dir="ltr">Lo mismo que le pasa a tu empresa cuando no se ha transmitido la estrategia y se montan grupos de mejora: cada vez que un grupo de mejora encuentra algo interesante (es decir, realiza un experimento exitoso) provoca una tensión hacia aquello que ha descubierto. Una empresa cuyos equipos no conocen la estrategia y tiene pocos experimentos exitosos se moverá como un tronco a la deriva en medio del océano: en el mejor de los casos, se deja llevar por los resultados de estos experimentos.</p><p dir="ltr">Pero una empresa que no ha transmitido la estrategia a sus colaboradores, que fomenta un entorno de mejora continua con gran parte de su personal y que además consigue multitud de éxitos en los experimentos, puede terminar intentando avanzar de forma simultánea en direcciones contrarias. En el mejor de los casos no se mueve y en el peor de los casos se rompe, se parte la pared celular y todo citoplasma queda por ahí desparramado. ¡Qué triste!</p><blockquote>¿Nunca has tenido la sensación de que en tu empresa tienes varios jefes y que estos jefes estiran de ti en direcciones opuestas como si te estuviesen torturando al estilo mongol con 4 caballos?<br></blockquote><p dir="ltr"><br>Una buena transmisión de la estrategia corporativa ayuda a que los experimentos vayan en direcciones similares al menos, reduciendo el riesgo de que la empresa se parta, los trabajadores se quemen o la goma elástica de Txell salte por los aires.</p><p dir="ltr">Finalmente y por aterrizar esto a un terreno más práctico: si te imaginas una empresa que tiene varios equipos de desarrollo usando Scrum y estos equipos hacen retrospectivas y plantean pequeñas mejoras, te recomiendo que:<br></p><ol><li>Los equipos tengan claro hacia dónde vamos</li><li>Hagas <em>Retros de Retros</em> uniendo representantes de los equipos o una comunidad de Scrum Masters para que vean periódicamente si las mejoras propuestas por el equipo A no le están haciendo la vida imposible al equipo B o al departamento C</li></ol>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.comtag:blogger.com,1999:blog-24620302.post-21488101064612327832018-09-29T16:02:00.010+02:002021-06-30T16:00:30.045+02:00Recursos para aprender Minería de Procesos<strong>¿Quieres aprender algo más sobre minería de procesos?</strong><br />
En esta página hago un recopilatorio de todos los enlaces interesantes que te pueden servir para desarrollar tus conocimientos en esta materia.<br />
<br />
<strong>Formación:</strong><br />
<ul>
<li><a href="http://bit.ly/PM-MOOC">Process Mining - Data Science in Action</a> — un curso de coursera genial!</li>
<li><a href="http://formacion.gedos.es/">Fundamentos de Minería de Procesos con Disco</a>— El curso que impartimos en G2 (presencial u online)</li>
</ul>
<strong>Presentaciones</strong><br />
<ul>
<li><a href="https://www.slideshare.net/avallesalas/ponencia-posibilidades-de-uso-de-la-minera-de-procesos-para-la-mejora-en-itsm">Posibilidades de uso de la Minería de Procesos para la mejora en ITSM</a></li>
<li><a href="https://www.slideshare.net/avallesalas/process-mining-and-lean">Process Mining and Lean</a></li>
<li><a href="https://www.slideshare.net/avallesalas/process-mining-31905580">La minería de procesos en la auditoría de sistemas de información</a></li>
<li><a href="https://www.slideshare.net/avallesalas/buceando-en-standardcase-tft13">Buceando en Standard+Case</a></li>
<li><a href="https://www.slideshare.net/avallesalas/la-eficiencia-est-servida-minera-de-procesos-en-accion">La eficiencia está servida: Minería de Procesos en acción</a></li><li><a href="https://www.slideshare.net/avallesalas/la-minera-de-procesos-al-servicio-del-auditor" target="_blank">La minería de procesos al servicio del auditor</a></li>
</ul>
<strong>Artículos y Publicaciones</strong><br />
<ul>
<li><a href="https://www.slideshare.net/avallesalas/caso-de-xito-mineria-de-procesos-en-investigacin-del-cancer">Caso de Éxito: La Minería de Procesos y la investigación del cáncer</a></li>
<li><a href="https://www.slideshare.net/avallesalas/novatica-223-process-mining-english-edition">Novática 223: Monográfico sobre Minería de Procesos</a></li>
<li><a href="http://www.ati.es/novatica/2013/223/Nv223-24-VIII-Premio-Novatica-finalista.pdf">El uso de la minería de procesos en ITSM</a></li>
<li><a href="http://www.gobiernotic.es/2015/05/lo-esencial-es-invisible-los-ojos.html">Lo esencial es invisible a los ojos</a></li>
<li><a href="http://www.gobiernotic.es/2015/10/la-mineria-de-procesos-en-accion.html">La minería de procesos en acción</a></li>
<li><a href="http://bit.ly/PM-TheBook">Libro Process Mining</a></li>
</ul>
<strong>Herramientas</strong><br />
<ul>
<li><a href="https://fluxicon.com/">Disco</a> (Esta es la que <a href="https://www.gedos.es/servicios/" target="_blank">distribuimos en G2</a>, no te la pierdas!)</li>
<li><a href="https://www.minit.io/">Minit</a> (Esta también la <a href="https://www.gedos.es/servicios/" target="_blank">distribuimos en G2</a>, tampoco te la puedes perder)</li>
<li><a href="http://www.processmining.org/prom/start">ProM</a> (Open Source)</li>
<li><a href="https://www.celonis.com/">Celonis</a></li>
<li><a href="https://processgold.com/en/">Process Gold</a> (Ahora comprada por UIPath y <a href="https://www.gedos.es/servicios/" target="_blank">también distribuida por G2</a>)</li>
<li><a href="http://apromore.org/">Appromore</a> (Open Source)</li>
</ul>
<strong>Websites</strong><br />
<ul>
<li><a href="http://www.gedos.es/soluciones-new/">G2, los expertos en Mineria de Procesos</a></li>
<li><a href="http://bit.ly/PM-Manifest">Process Mining Manifesto</a></li>
<li><a href="http://bit.ly/PM-LinkedIN">LinkedIN Grupo Minería de Procesos</a></li>
</ul>
Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.comtag:blogger.com,1999:blog-24620302.post-34593502062784614802018-09-20T18:33:00.001+02:002018-09-20T18:33:44.878+02:00Scrum en organizaciones Lean: más madera para el Product Owner!<p dir="auto">Dentro de mi viaje particular al <a href="http://www.gobiernotic.es/2015/11/la-muerte-del-proyecto-o-el-nirvana-del.html" target="_blank">Nirvana del Flow</a>, esta semana he tenido un momento importante. Facilitando un evento Kaizen para el equipo de almacén de un cliente, intentando corregir unos “problemillas” que había con unos bultos que se traspapelaban por el camino hemos seguido todos los pasos de rigor: plantear el problema, hacer un VSM, identificar oportunidades de mejora, análisis de causas etc etc.</p><p dir="auto">Lo de siempre en el mundo Lean, siempre tan interesante gracias a la participación de todos. Aparte de todo lo que aprendí del mundo de los almacenes y la logística, que es impresionante, pude vivir (otra vez!) la excitación que te genera ver que el equipo Kaizen no se enfoca en las guerras personales y empieza a trabajar de manera creativa en comprender el problema y plantear contramedidas, siempre de manera transversal y cross-departamental. ¡Es alucinante!</p><p dir="auto">Pero por el camino empecé a notar que la cosa se podía complicar. En seguida aparecieron propuestas de pequeños cambios en el proceso, pequeñas modificaciones en la operativa (con el consiguiente problema de Gestión del Cambio con el personal y sus diferentes turnos) y el nacimiento de nuevas necesidades de información, controles y sistemas de información. </p><blockquote>¿Quien dijo que los procesos industriales son más fáciles de gestionar porque están estandarizados? <br></blockquote><p dir="auto">Este proceso que estábamos analizando es fácil de comprender, pero la cantidad de casuísticas que tiene es impresionante y ahí aparecía una de las lecciones importantes del Kaizen… recuerdas? <em>“Kaizen … yo me flagelo y hago un sacrificio por el bien común”.<br><br></em></p><div class="embed-wrapper" data-url="www.youtube.com/embed/txOeJQCMT8s" style="clear: both; text-align: center;"><iframe width="480" height="270" src="https://www.youtube.com/embed/txOeJQCMT8s" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen=""></iframe></div><p dir="auto">Para conseguir un proceso más homogéneo y sin tantas excepciones y casos especiales todos deben hacer pequeñas concesiones para conseguir optimizar el proceso de forma global en lugar de perseguir las optimizaciones locales e independientes para cada uno de los interesados. En este caso, el equipo de almacén se ve afectado por los requisitos, limitaciones o presiones impuestas en el proceso aguas arriba (por ejemplo, presiones en la planificación establecidas dos o tres eslabones antes de llegar a la preparacion de un pallet que debe ser expedido).</p><p dir="auto">Y ahora vamos a pensar un poco más allá; este post no pretendía ser una explicación sobre una sesión de Kaizen. ¿Te imaginas una empresa en la que los diferentes equipos hacen sesiones de Kaizen para ir mejorando poco a poco los procesos de negocio? En el almacén, en compras, en logísticas, en pedidos… en todas partes gente haciendo pequeñas modificaciones y pequeñas mejoras sobre los procesos, haciendo que la empresa lentamente vaya evolucionando a mejores cotas de calidad, eficiencia y valor para el cliente. <strong>¿Mola, no?</strong></p><p dir="auto">¿Y dónde están los informáticos?</p><p dir="auto">¡Esa es la reflexión clave! Si los procesos evolucionan continuamente, informática debe ser capaz de soportar esas modificaciones de forma continua, debe facilitar la adaptación permanente de los sistemas de información a las necesidades y a los cambios provocados por la mejora contínua del negocio. </p><p dir="auto">Es lo que hacemos siempre, no? Desde luego, no me cabe la menor duda de que siempre estamos intentando mantener un ritmo decente de modificaciones/evoluciones a nuestros sistemas de información, pero en un entorno Lean donde la evolución y el cambio son constantes el nivel de exigencia es mucho mayor.</p><p dir="auto">¿Y cómo respondemos en informática a esta situación de elevada demanda de pequeños cambios sobre los mismos sistemas de información? </p><p dir="auto">Con equipos especializados en esos sistemas de información, focalizados en el proceso, orientados a la ejecución de tareas que finalizan con un incremento de producto totalmente funcional.. respondemos a las células de producción con células de producción. Los equipos ágiles son especialmente necesarios en estos entornos donde no dar respuesta incremental a estas demandas significa frenar la mejora de los procesos de negocio.</p><p dir="auto">Por eso es tan y tan importante provocar la transformación ágil en los entornos Lean para hacer que flujo, valor y calidad vayan de la mano en todos los sentidos. Y cuando tengas en marcha equipos ágiles, si usas Scrum por favor, <strong>asegúrate de que al menos el Product Owner asiste a las sesiones Kaizen de su cliente</strong>. </p><p dir="auto">Ni te imaginas el aprendizaje y la cantidad de información y de ideas enriquecedoras que el equipo de desarrollo se va a llevar de esas sesiones: es ver a tus usuarios tratando de resolver sus problemas utilizando tus herramientas. <br></p><p dir="ltr"><br>Postdata: en este evento Kaizen que estoy facilitando está presente la Product Owner y varias personas del equipo de desarrollo… está siendo una experiencia super enriquecedora para todos!</p>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.comtag:blogger.com,1999:blog-24620302.post-35322871648515055642017-12-01T15:20:00.002+01:002017-12-01T15:20:53.486+01:00BCN DevOps Tour<p dir="auto">El itSMF es una asociación veterana; recuerdo cuando en 2005 nos reunimos en Madrid para iniciar las conversaciones para su fundación y cómo en aquel momento el foco principal de todos los que estábamos allí era aprender, compartir y difundir conocimientos relacionados con la Gestión del Servicio.</p><p dir="auto">En el año 2005 la Gestión del Servicio era ITIL. No había mucho más a lo que agarrarse y así fue como el itSMF España se convirtió en algo muy parecido a todos los demás itSMF del mundo: el foro de la gente interesada en ITSM y por consiguiente el foro que difundía ITIL. Las primeras acciones fueron traducir el glosario, los libros de ITIL V2 y la norma ISO 20.000-1 al castellano… todo hervía alrededor de ITIL.</p><p dir="auto">El tiempo fue pasando y gracias a la visión estratégica que siempre ha caracterizado a las diferentes instancias de la Junta Directiva fuimos incorporando otros marcos de referencia y otras prácticas… y así ha sido hasta estos días en que hicimos un curso de verano centrado en DevOps y un congreso especializado en Agilidad: el itSMF se consolida como la asociación de aquellos que estamos preocupados por la Gestión de Servicios a lo largo de todo su ciclo de vida y eso incluye nuevas maneras de crear, mantener y evolucionar los servicios como son los métodos ágiles y las prácticas DevOps.</p><p dir="auto">Pero eso no es todo! Tambien nos interesa la gente, sus prácticas, su manera de organizar el trabajo, su manera de relacionarse y de organizarse… así que incorporamos aspectos de motivacion, de organizacion y de Lean-IT.</p><p dir="auto">Todos estos intereses tan variopintos se reflejan en los congresos que hacemos por toda la geografía; este año hemos tenido (así, que yo recuerde ahora mismo y de memoria) e Madrid, Barcelona, Asturias, Valencia y Sevilla…pero eso nos sabía a poco así que hace poco más de un año en el comité de Catalunya iniciamos un experimento con los <a href="https://www.meetup.com/es-ES/itSMF-CAT/" target="_blank">meetups</a>: pretendiamos vernos más a menudo, algo más frecuentemente que una vez al año. (<a href="https://www.meetup.com/es-ES/itSMF-CAT/" target="_blank">Ya tardas en inscribirte siguiendo el enlace!!</a>)</p><p dir="auto">Pues este mes de <strong>Diciembre de 2017</strong> todo esto converge en una gran iniciativa que ha contado con la participación de miembros del comité de Catalunya, miembros del equipo de itSMF España y empresas “usuarias” que desean compartir experiencias: El próximo <strong>12 de Diciembre </strong>arranca el <strong>BCN DevOps Tour</strong>, una iniciativa en la que pretendemos acercar a la comunidad de expertos en Gestión de Servicios las prácticas <strong>#DevOps</strong> y lo que ello significa en las empresas que están utilizándolas. Para ello hemos buscado a varias empresas finalistas, de diferentes sectores y que estén llevando a cabo actividades relacionadas con DevOps para iniciar una conversación abierta y enriquecedora sobre qué hacen, qué quieren hacer, beneficios, problemas, herramientas, resultados y todo aquello que quieran compartir con nosotros.</p><p dir="auto">La primera sesión será en el Campus Norte del IESE y contaremos con la participación de Jordi Badía, CIO de Venca, quien nos explicará el impacto que ha tenido DevOps en su organización.</p><p dir="auto">Quieres venir?</p><ol><li>Inscribete en <a href="http://meet.meetup.com/wf/click?upn=XTL-2BADyqX-2FD82kkVyMmL1VDlbcq9d2WUi1EG1Qj1k3SxlLoYyoeYf0pkkIhN14HrZTHRoMirWLfXOV5BcQU1nfqaGmN3oerzGTIpQ8JKVEeZwK-2F3-2Fvtrzoy0bttNGsN8M0jEVXfy9SNvvWehgqn5w3Zg44HErNIIZWJFU-2FQ3DCA-3D_CFzYnDkg-2B7xquwLx-2BIhVQDe-2BIpJyzivcYmCtJVaj3idgQSw5qofGgelWliY1c1gOgcM7U-2FT0Ks5JBPSmSseBSSXONcZV5B6aRa-2B7-2FrbJzKo1v58xyr-2F8EM2KlYs3JJzzcSPua4jVV3OpBXktwBrKEIYUako2eF8wKJ5qcCe-2B5-2Bksd7hwZ3YfgESBA6-2BaH1cGJrO8-2B5vPx-2FyO3Klpc5FU9XMx1jVMT7xjhRoZGHJuV6I-3D">este enlace</a></li><li>Haz RSVP en la <a href="http://meet.meetup.com/wf/click?upn=pEEcc35imY7Cq0tG1vyTt-2FJhZqmey-2FT1DzLWv3s-2BMbC951MaCNvFitotjXQ6KeOf8Raj9IbejZphnHpwMtodwg-3D-3D_CFzYnDkg-2B7xquwLx-2BIhVQDe-2BIpJyzivcYmCtJVaj3idgQSw5qofGgelWliY1c1gO9esIJA9ClLTpZnAjyVOHH0eCxYjpmW7KjldiwEVmZrdVSE-2FDMHpqRudUmzY0MLHjNPbs-2BUUDXYGfn4ygKygvsiqef9xh3HuIOzMRTpInH6twsNL4JtoPvNTa-2BU9-2Bt-2Fj3qGNsWnjCnfO9YXUA13o-2BCSWB6hitLoNrH0JLk2FSX2I-3D">web de meetup</a></li><li>Marca el Martes 12 de Diciembre de 18:00 a 20:00 en <strong>tu agenda</strong> como ocupado</li></ol><p dir="auto"><br>No te puedes perder esta iniciativa única en la que aprenderemos directamente de los que están en las trincheras… quieres venirte al Gemba con nosotros?</p><p dir="auto">PS:: Ayudanos a difundirlo, comparte enlaces, comentarios y opiniones con tus amigos en las redes sociales y echanos una mano a llenar el aula!</p>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.comtag:blogger.com,1999:blog-24620302.post-54944892369461982572017-08-02T14:11:00.000+02:002017-08-02T14:12:02.320+02:00No es el problema. Eres tú frente al problema.<p dir="auto">La primera vez que oí hablar sobre el modelo Cynefin fue allá por el año 2012 cuando estaba colaborando con <a href="http://www.itskeptic.org/blog" target="_blank">Rob England</a> en la traducción del libro <a href="http://https://www.amazon.es/Gestión-Esencial-Servicios-Traducción-Management/dp/148231049X" target="_blank">Gestión Esencial de Servicios</a> al castellano. En aquel momento me pareció un framework muy interesante para clasificar los problemas y cómo nos enfrentamos a ellos; luego Rob lo utilizó en su libro <a href="https://www.amazon.es/Plus-Standard-Case-Approach-response/dp/1482061740/ref=sr_1_1?s=foreign-books&ie=UTF8&qid=1501675255&sr=1-1&keywords=plus+standard+case" target="_blank">Plus! Standard+Case</a> y en el <a href="https://es.slideshare.net/avallesalas/buceando-en-standardcase-tft13" target="_blank">congreso TFT13 yo le dí una vuelta más</a> tratando de enlazar los conceptos de S+C, Cynefin y Minería de Procesos.</p><p dir="auto">Pero luego vino el esquema de certificación de la Lean IT Association y la <a href="https://campus.gedos.es/catalog/info/id:125" target="_blank">certificación LITA Kaizen</a>. Cuando me preparaba, volvió a aparecer el modelo de Cynefin y esta vez venía con fuerza, como parte central del proceso de resolución de problemas que plantea la LITA combinando Kaizen con Six Sigma (DMAIC) y Cynefin.</p><div class="separator" style="clear: both; text-align: center;"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-JUt0grdSCDTwltdEvZ81K7thUVHvfPXpBxklJ35obrPGua187ql8IRdSvKM-25gehkiPFRgjYKTx7x0IJk4kLiu7MxY3egbQTOGiTl2qRkNhRyOMzYdbRaJbrxQJARXTvHrbeg/s9999/Cinefyn.png" width="654" style="max-width: 100%;"></div><p><br></p><p dir="auto">Fue mientras daba una clase de Kaizen que me vino la iluminación; uno de esos momentos A-HA! que sólo puede tener el profesor cuando por el simple hecho de poner las cosas en orden en su cabeza para poderlas explicar, éstas encajan de una manera especial y plop! se hace la luz.</p><p dir="auto">El modelo Cynefin ve los problemas como un <strong>cúmulo de causas y efectos;</strong> aquellos en los que la relación <em>causa - efecto</em> es clara, los entiende como “<u>Simples</u>”, mientras que en aquellos en que la relación <em>causa - causa - causa/efecto intermedio - causa - efecto</em> es intrincada, con multiples ramificaciones y multitud de causas contribuyendo a la aparición de los efectos los clasifica como “<u>Complejos</u>” y aquellos en los que las relaciones entre los eventos no son permisibles los clasifica como “<u>Caoticos</u>”.</p><blockquote>Las relaciones causa-efecto con diferentes niveles de complejidad existen; el problema es que tú no eres capaz de percibirlas o de comprenderlas.</blockquote><p dir="auto">Pero, lo caótico no es el problema. Las relaciones causa-efecto con diferentes niveles de complejidad existen; el problema es que tú no eres capaz de percibirlas. Sin embargo si eres capaz de aprender nuevas ideas, si eres capaz de cambiar la perspectiva o el espectro en el que te mueves (en la vista, por ejemplo, cambiar a espectro infrarojo te permite ver las cosas desde otro punto de vista; en matemáticas, pasar de una serie temporal a un histograma te permite comprender otras facetas del problema analizado; en Telecos, Fourier cambió para siempre la forma de entender las ondas), si eres capaz de pensar de una manera diferente es cuando empujas el problema hacia niveles Cynefin de menor complejidad. </p><p dir="auto">Aquí es justo cuando me viene a la cabeza ese momento en que Neo comprende.</p><div class="embed-wrapper" data-url="www.youtube.com/embed/WNnGXXlPzuo" style="clear: both; text-align: center;"><iframe width="480" height="270" src="https://www.youtube.com/embed/WNnGXXlPzuo" frameborder="0" allowfullscreen=""></iframe></div><blockquote>Cómo clasificas el problema dice más de ti que del problema en sí.</blockquote><p dir="ltr">Cómo clasificas el problema dice más de ti que del problema en sí. Y esta es una de las razones por las que utilizamos Kaizen para enfrentarnos a los problemas que nos parecen complejos o complicados: utilizamos un equipo para atacar el problema; un equipo multidisciplinar que, gracias a las diferentes perspectivas, experiencias y formas de vivir y de entender el problema hará que el grupo entero gane un nuevo nivel de conocimiento al respecto del problema y sus relaciones con los factores que contribuyen a su aparición. Ese es uno de los motivos por los que, casi sin darnos cuenta, los equipos multidisciplinares y la diversidad hacen empresas más eficientes: <strong>los problemas parecen menos cuando los enfrentas en buena compañía.</strong></p><p dir="ltr">PS:: Este post viene provocado como reflexión ante una <a href="https://www.linkedin.com/feed/update/urn:li:activity:6298411445986091008" target="_blank">pregunta de Javier Garzás en linkedIn</a>… como siempre, un placer! :-)<br></p>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.comtag:blogger.com,1999:blog-24620302.post-33306900743819054582017-01-31T10:03:00.000+01:002017-01-31T10:03:08.966+01:00Qué hacer con las interrupciones<p dir="auto">LLevaba días con ganas de escribir algunas reflexiones al respecto del problema que suponen las interrupciones para la efectividad de un equipo y finalmente Javier Garzas se me adelantó con <a href="http://www.javiergarzas.com/2017/01/controlando-las-interrupciones.html" target="_blank">este post sobre control de interrupciones</a>.</p><p>Efectivamente, tal y como indica el post de Javier, las interrupciones son uno de los mayores destructores de productividad tanto del individuo como del equipo, fundamentalmente porque somos muy malos gestionando los cambios de contexto y por lo tanto el overhead intelectual que tiene dejar de hacer lo que estamos haciendo para atender un interrupción y volver a ponernos es elevadísimo.</p><p>A ese esfuerzo intelectual tenemos que sumarle el mal humor acumulativo que le va entrando a la persona interrumpida que en las dos o tres primeras interrupciones no tiene problema y atiende con una sonrisa, las siguientes 3 ya no son tan bienvenidas y a partir de la séptima ya empieza a desesperarse y a desear esconderse en una cueva para que le dejen concentrarse en paz.</p><p>Son un problema importante y debemos tratarlo como tal. Seguro que si analizamos un poco podremos ver que tenemos diferentes tipos de interrupciones en función del grado de proximidad al individuo (yo las clasifico en internas, de equipo y externas) y esto nos indica tambien con quien debemos contar para resolverlas.</p><p>Así, resolver las interrupciones internas será tarea de cada uno de los miembros del equipo, adoptando rutinas y formas de trabajar libres de interrupciones (modo Foco en el ordenador que estes utilizando, musica de concentración, evitar el web-browser sobre todas las cosas, técnicas del tipo <a href="http://https//es.wikipedia.org/wiki/T%C3%A9cnica_Pomodoro" target="_blank">Pomodoro</a>).</p><p>Por otra parte, resolver problemas de interrupciones a nivel equipo o a nivel compañía es un trabajo mucho más duro. Normalmente nos encontraremos con que este tipo de interrupciones vienen dadas porque existen dependencias entre las personas o los equipos y es ahí donde debemos trabajar.</p><p>Durante mi vida profesional me ha tocado trabajar con multitud de equipos distintos que sufrian las interrupciones de diferentes maneras. La forma más común de enfrentarse a ellas es el llanto y la flagelación: “En esta empresa no se puede trabajar, es que es imposible hacer nada… no hay manera… me pillo una sala para poder estar concentrado”…</p><p>La siguiente manera de enfrentarse, y esta viene más en entornos con cierto nivel de madurez y sobre todo en entornos ágiles en los que se ha reservado un espacio para la reflexión y la mejora continua del equipo, es el planteamiento de la situación en una retrospectiva: “no conseguimos llegar a nuestros objetivos porque estamos sometidos a gran cantidad de interrupciones. ¿Qué podemos hacer?"</p><p>… y aquí es donde viene el meollo de la cuestión: el equipo se plantea qué hacer con las interrupciones y como es normal lo primero que se plantea es objetivizar un poco la situación y aparecen los tableros para visualizar el problema como el que describe Javier en su artículo. Luego en pequeñas sesiones de trabajo el equipo va explorando las causas de las interrupciones y <strong>tratando de poner freno o límites</strong>.</p><p dir="ltr">A mi me gustaría ir mucho más alla: dado que las interrupciones son un problema importante para el/los equipos (no olvidemos que quien interrumpe probablemente también vea un problema en la necesidad de interrumpir) y que debemos estudiarlas desde un punto de vista sistémico (porque si no, optimizaremos localmente y conseguiremos un bonito desastre a nivel de sistema de producción), debemos tratarlas con un enfoque Kaizen. </p><p>Por ejemplo, en una retrospectiva participan los miembros del equipo; si las interrupciones son del tipo externo, ¿No nos falta el otro lado para poder analizar el problema?</p><div class="separator" style="clear: both; text-align: center;"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCmgFED7duBK28IzzTibwqV7iGdyLyPOWO73fAnaIgPqw4eyoObdt1kQXTrBoDgSKVzX3l25dAxIv2C0Qc92tXKGxdAIbNIM41iyzJBcoHp3HeaI_Jg9rvLviu83S5W9JHcxQDUA/s9999/Cinefyn.png" width="655" style="max-width: 100%;"></div><p dir="ltr"><br>El <a href="https://en.wikipedia.org/wiki/Cynefin_framework" target="_blank">modelo Cynefin</a> clasifica los problemas en Simples, Complicados, Complejos y Caóticos. Los problemas simples son aquellos que se pueden explicar fácilmente desde una perspectiva de Causa-Consecuencia y en mi opinion personal (y seguro que muy discutible) son geniales para ser atacados en las retrospectivas: un equipo en un par de horas trabajando sobre ellos llegará fácilmente a proponer una solución que podrá ser incorporada como mejora continua en su backlog, al tiempo que se entrena en el análisis de problemas, autocrítica y mejora continua.</p><p>Sin embargo, las interrupciones como mal sistémico de una organización no pertenecerán a este tipo de problemas: no tendrán una clara relación causa-efecto, sino que serán provocadas por una sucesión de causas que contribuyen a la aparición del problema o incluso habrá algunas veces en las que las causas y los efectos no podrán ser observados a priori sino que vemos su aparición a posteriori. Es el terreno de los problemas Complicados y Complejos que es justamente donde el Kaizen se mueve bien.</p><p>Así, desde aqui mi propuesta es no pensar que existen las varitas mágicas y ser conscientes de que la probabilidad de que una “best-practice” nos solucione el problema de las interrupciones es realmente baja, tendiendo a cero. El Kaizen es un método sistemático para atacar este tipo de problemas, así que empieza por visualizar el tamaño de tu problema (y decidir si las interrupciones son realmente un problema en tu organización) y después sigue los pasos del método uno por uno.<br></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9ZXCoTXZZP1qb7RQ0hb-E5_0aLxPYPQW9MXlrI0QF6TOAZE3U2pt2pE28SJTCfs5GYEe5FBVLRq3NfF1WzcijnSHw07EiCOHqGbDZ6Bhqh18ItxiNpJpH3i9eMcGEKf1qywG2Kg/s9999/Kaizen-segun-la-Lean-IT-Association_full.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgwsSRNIA5VBmL6n5mR96HJ3SSokzwgeWEF96k19aSSAjQvycbT9E4TJ_pZpYtk-DdawhbrKJP1GavY6Je_dOGyicfa7ywwXlUb2vMgGvHcTXbxo5WG_A_kUl1LIQD3x-7T_wJInw/s9999/Kaizen-segun-la-Lean-IT-Association.png" alt="Kaizen según la Lean-IT Association" title="Kaizen según la Lean-IT Association" data-image-align="middle" data-image-caption="Kaizen según la Lean-IT Association" width="500" style="max-width: 100%;"></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Kaizen según la Lean-IT Association</td></tr></tbody></table><p dir="ltr">Si quieres saber más sobre Kaizen en el mundo Lean-IT, te recomiendo el <a href="http://www.leanitassociation.com/certifications/lean-it-kaizen/" target="_blank">libro oficial de la Lean-IT Association</a> (descarga gratuita) o los <a href="http://formacion.gedos.es/programa-de-formacion/lita-lean-it-kaizen/" target="_blank" title="Formación Lean-IT">programas de formación en Lean-IT de G2</a></p>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.comtag:blogger.com,1999:blog-24620302.post-25973243138226940262016-10-09T18:23:00.001+02:002017-06-15T14:33:35.855+02:004 ideas para aumentar la velocidad<p dir="auto">En Scrum se utiliza el concepto de velocidad para referirnos a la capacidad que tiene el equipo de “quemar puntos”, o sea, a su capacidad de producción. El aumento de la velocidad es uno de los principales indicadores de que el equipo está cohesionado, en continuo aprendizaje y en mejora continua.</p><div></div><p><br>Pero... <strong><em>¿cómo se aumenta la velocidad? <br></em></strong><br>Desde luego, no es por azar. En este artículo veremos cuatro herramientas fundamentales para la mejora de la velocidad en tu equipo Scrum.</p><h3>1.- Identificar QUÉ nos resta capacidad</h3><p>Si sumamos todo el tiempo laboral del que disponen los miembros del equipo, tendremos una capacidad productiva teórica máxima.</p><p>Esto es una simplificación, porque estamos sumando “peras con manzanas” ya que una hora de María no es igual a una hora de Joan y, desde luego, una hora de Joan haciendo análisis no es igual que una hora de Joan haciendo testing. Por esta razón utilizamos puntos en lugar de horas para estimar las tareas, pero esta es otra historia que debe de ser contada en otra ocasión.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEivP61q_i8_n1auKoQyT446wLvE6dpXP-eUV2pSD0HKHjbGuiEG5NTr8Azf4pGl7k1gViWzOosflo30SW2K9Z5I8W50MMlDu5mIz_0YjpwSsmPR2nXGjaM4U50p2k-8B0D6psWBNA/?imgmax=9999"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9YAS2-fanbBZA9HQjM63YPE7iwuwNpMC9JkFKW5ED_f5dtsSUhGrUDTZU_9yp77Unhmx_9yjc6WnW4N5Nfdo43qHXqdHzeFpqS1DlENaxWWGYiEZEfsyOgDY4jyv1QHUZ13gxVg/?imgmax=9999" width="200" height="343"></a></div><p>Centrémonos: tenemos una capacidad máxima teórica que luego se convertirá en una capacidad efectiva real. ¿Cuál es la diferencia? ¿Qué nos está mermando la capacidad productiva?</p><p>Debemos aprender a identificar en qué estamos invirtiendo el tiempo del equipo para ver cómo podemos optimizarlo y ganar en capacidad productiva, o al menos ganar en objetividad y no engañarnos pensando que el equipo produce 8 horas al día. Por ejemplo, nos encontraremos frecuentemente que los miembros del equipo dedican parte de su capacidad en tareas como:<br></p><ul><li>Reuniones<br></li><li>Llamadas telefónicas<br></li><li>Formación<br></li><li>Participación en otros proyectos<br></li><li>Colaboración con otros equipos<br></li><li>I+D<br></li><li>Ausencias / Absentismo<br></li><li>Ejecución de tareas no planificadas<br></li></ul><p>Atención! Hemos dicho “optimizar”, no “eliminar”. Hay que ser conscientes de en qué invertimos nuestro tiempo y en conseguir un equilibrio. Por ejemplo, una de las grandes ventajas de aislar al equipo y tratar de eliminar las interrupciones es reducir el tiempo dedicado a reuniones y llamadas telefónicas; o una de las ventajas de mantener acotado el numero de equipos a los que pertenece una persona es reducir el overhead de coordinación y de cambio de contexto.</p><h3>2.- Identificar EN QUÉ derrochamos capacidad</h3><p>Este punto está más relacionado con la parte “interna” del trabajo como equipo Scrum. De todo el trabajo que hacemos como equipo (es decir, del que estamos considerando dentro del cómputo de la velocidad), ¿qué podemos optimizar? ¿Se nos va el tiempo en actividades que no aportan valor al usuario?</p><p>Hay tres grandes “vampiros” de la eficiencia en el trabajo de un equipo scrum: Muda, Mura y Muri.</p><p><strong>Muda</strong>: Son actividades que no aportan valor y que están clasificadas por algunos autores en 8 grandes bloques:</p><p>1. Trabajo a Medias (el famoso WIP)</p><p>2. Exceso de Funcionalidad (hacer más de lo que el cliente requiere)</p><p>3. Procesos Extra (algo parecido al exceso de burocracia o procesos excesivamente complicados)</p><p>4. Traspasos (cruzar barreras organizativas siempre añade retrasos a nuestro flujo)</p><p>5. Retrasos (todo aquello que suponga tiempos de espera)</p><p>6. Conmutación de Tareas (la multitarea es enemiga de tu cerebro, que es tu principal medio de producción!)</p><p>7. Defectos (los errores y la deuda técnica)</p><p>8. El talento desaprovechado (por eso somos un equipo scrum!)</p><p><strong>Mura</strong>: es la irregularidad en las tareas o en los resultados. Por eso tratamos de estandarizar las entradas al proceso, utilizar plantillas y checklists o incluso homogeneizar el trabajo a nivel inter-equipo scrum y hasta hemos formalizado una Definition of Done</p><p><strong>Muri</strong>: es el trabajo tensionante. El stress sobre personas y máquinas produce errores y genera más muda. Por este motivo buscamos equipos motivados, equilibrados y felices.</p><p>Aprender a ver, clasificar y eliminar muda, mura y muri en el trabajo que hace el equipo Scrum día a día debe convertirse en uno de los puntos clave de las retrospectivas y alimentar el backlog de mejora continua de forma implacable.<br></p><blockquote> Aprender a ver, clasificar y eliminar muda, mura y muri debe convertirse en uno de los puntos clave de las retrospectivas para optimizar el trabajo del equipo Scrum</blockquote><p><br></p><h3>3.- Aprender a NIVELAR la demanda</h3><p>En el sprint plan hacemos entrar trabajo al sprint backlog y se adquiere el compromiso del equipo con respecto a los objetivos a cumplir. Si dejamos entrar demasiado, tendremos más demanda que capacidad y eso genera muri. Si dejamos entrar poco, tendremos más capacidad que demanda y eso genera muda.</p><p>Tenemos que aprender no sólo a dejar entrar la cantidad justa sino que además debemos aprender a dejar entrar la combinación adecuada de tareas en función de las características del equipo (y por esta razón los equipos deben de ser lo más estables posibles).</p><p>Así, debemos trocear las historias de usuario en paquetes pequeños que fluyan suavemente y debemos evitar entrar bloques grandes en el proceso. Un trabajo “grande” se comportará como un tractor en una carretera: todo el resto del trabajo estará atascado detrás, ya trabajes en modo Scrum o en modo Kanban.</p><p>Esta técnica de combinación de la demanda para ocupar nuestra capacidad se llama <strong>Heijunka</strong> y es clave en la planificación industrial de la producción.</p><h3>4.- Aprender a ayudar al FLUJO</h3><p>Recuerdas el manifiesto ágil? Decía algo así como “Preferimos <strong>software funcionando</strong> sobre documentación extensiva”. Nos gusta más el software funcionando, es decir, nos gusta ese momento en que pasamos un “PSPI” (Potentially Shippable Product Increment) a Done.</p><p>Así que cuando acabes una tarea, en lugar de dirigirte al sprint backlog y coger la próxima tarea para iniciarla, para un momento y mira el tablero; recuerda que somos un equipo y nos medimos como equipo, así que no se trata de ser el que más tareas inicia, sino que se trata de que como equipo debemos terminar las tareas que nos hemos comprometido.</p><blockquote>Lo importante es llevar la historia de usuario a <strong><em>done</em></strong>, no las tareas individuales. Esto nos hace trabajar como un equipo y poner foco en la entrega de valor.</blockquote><p>Una vez hecha esta reflexión plantéate:</p><ol><li>¿Hay alguna tarea bloqueada que tú puedas desbloquear?<br></li><li>¿Hay alguna tarea a medias en la que tú puedas ayudar?<br></li><li>¿Hay algún compañero que necesite tu ayuda?<br></li><li>De todas las tareas que hay en el sprint backlog y tú puedes hacer, ¿Cuál es la que más ayuda a una historia a terminar?<br></li></ol><p dir="ltr">La idea, una vez más, es completar el trabajo que hemos comprometido al inicio del sprint. ¿Qué crees que hará más feliz al cliente al final del sprint, mostrar que hemos iniciado todas las historias y no hemos acabado ninguna o mostrar que hemos acabado el 70% de las historias y que no hemos llegado a completar el otro 30%?</p><p>¿Qué otros trucos tienes para aumentar la velocidad? Estos cuatro son sólo eso... cuatro de entre los cientos que podemos imaginar.</p>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.comtag:blogger.com,1999:blog-24620302.post-24050385255051177252016-07-29T12:01:00.001+02:002017-07-24T18:00:52.135+02:00La rana en la olla, agile y los equipos de operaciones<div dir="auto">
Cuando das clases de muchas temáticas diferentes pasa que durante un curso tu mente se enfoca en una materia concreta y al siguiente curso la materia cambia. Si en medio además te dedicas a hacer proyectos, notas cómo esas materias te influencian fuertemente en tu manera de enfocar o de abordar los problemas que se plantean en la ejecución.</div>
<div dir="auto">
Este último mes he tenido proyectos de agilidad, clases de lean y clases de ITIL® así que mi cabeza es un hervidero de ideas. Entre ellas, esta mañana apareció un flash: <em><strong>¿que pasa con los atributos de garantía en un entorno ágil?</strong></em></div>
<div dir="auto">
Hace unas semanas escuchaba a Alex Ballarin en una clase diciendo algo que me hizo sonreír: las historias de usuario pueden usarse también para expresar requerimientos no funcionales, por ejemplo algo así como "Como sistema quiero soportar 1000 usuarios concurrentes para que no se ralentice la cadena de valor"</div>
Con la interpretación “tradicional" de ITIL® vemos el ciclo de vida del servicio como una gigantesca rueda waterfall que lleva un servicio completo desde la Estrategia hasta la Operación y luego lo hace evolucionar en forma de "servicio modificado” con la mejora continua del servicio. Con esta visión es fácil comprender la importancia que tiene en la etapa de diseño que utilicemos las famosas 4P para tener en cuenta los aspectos de garantía del servicio y que incorporemos los requerimientos de garantía en el diseño y posteriormente en la construcción, pruebas y despliegue.<br />
<div dir="auto">
La cosa es grande y viene de lejos, así que nos preparamos para acogerla en nuestro entorno de producción; para ello tendremos en cuenta a los equipos de operaciones o, para ser más itileramente formal, a las funciones de la etapa de Operación del Servicio y por ejemplo prepararemos las infraestructuras para dar soporte al volumen de usuarios que esperamos.</div>
<div dir="auto">
Cuando se avecina un cambio grande, es normal que se cree esa sensación de necesidad de preveer las consecuencias y por lo tanto que se piense en aspectos como la capacidad, la disponibilidad o la seguridad.</div>
<div dir="auto">
Pero… ¿y qué pasa en el momento en que cambiamos el modo de trabajo y pasamos a trabajar el modo “evolutivo” desde el minuto cero?</div>
<div dir="auto">
<strong>Peter Senge </strong>explica en su libro <strong>La Quinta Disciplina</strong> el concepto de adaptación a los cambios lentos y graduales y el peligro que conllevan si no estamos atentos y lo ilustra con una parábola que a mi personalmente me pone los pelos de punta por lo cruel de la idea: <strong>la parábola de la rana hervida</strong>. Muy cruel, pero explicita!</div>
<blockquote>
Si ponemos una rana en una olla de agua hirviente, inmediatamente intenta salir. Pero si ponemos la rana en agua a la temperatura ambiente, y no la asustamos, se queda tranquila. Cuando la temperatura se eleva de 21 a 26 grados centígrados, la rana no hace nada, e incluso parece pasarlo bien. A medida que la temperatura aumenta, la rana está cada vez más aturdida, y finalmente no está en condiciones de salir de la olla. Aunque nada se lo impide, la rana se queda allí y hierve. ¿Por qué? Porque su aparato interno para detectar amenazas a la supervivencia está preparado para cambios repentinos en el medio ambiente, no para cambios lentos y graduales.</blockquote>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiu5F1i5g517F12N4u-Ormx2zEvGLUS9NAhKoy6TEaJR0UwOMHuXZWOLa_d4L2ghbkznYO1VLhhoj7LSmeDlkXwf5lS3C3ENbPUHHA6C9ED8bbg449qD6apu7Pg4zrwJFBBdkl9tw/s1600/La+Rana_II.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="521" data-original-width="850" height="196" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiu5F1i5g517F12N4u-Ormx2zEvGLUS9NAhKoy6TEaJR0UwOMHuXZWOLa_d4L2ghbkznYO1VLhhoj7LSmeDlkXwf5lS3C3ENbPUHHA6C9ED8bbg449qD6apu7Pg4zrwJFBBdkl9tw/s320/La+Rana_II.jpg" width="320" /></a></div>
<br />
De repente ocurre que en algún momento aparece esa necesidad de soportar 1000 usuarios concurrentes, la implementamos y luego se producen 200 modificaciones posteriores a las funcionalidades del servicio en forma de sendas historias de usuario que se implementan en sprints sucesivos…. y de repente esas pequeñas modificaciones que una a una eran poquita cosa hacen que nuestro sistema deje de soportar 1000 usuarios concurrentes.<br />
<div dir="ltr">
Técnicamente esto no debería pasar, porque a cada modificación hacemos pruebas de regresión y pruebas de los requerimientos funcionales y nos aseguramos de que cada pequeño cambio no rompa nada, pero… por favor, que levante la mano el que esté dispuesto a asegurar que hace eso para todos sus servicios en la etapa de construccion.</div>
<div dir="ltr">
<strong>Si salen más de 10, prometo borrar este post.</strong></div>
<div dir="ltr">
En resumen, que propongo que al menos para empezar, la historia de usuario se reescriba para contemplar este peligro y quede en algo asi como</div>
<blockquote>
Como sistema, quiero soportar 1000 usuarios concurrentes y seguir soportándolos despues de los próximos 10 sprints. Depués volvemos a hablar de demanda, capacidad y arquitectura.</blockquote>
<div dir="ltr">
A media que vayamos madurando y consigamos un flujo continuo con todos los requerimientos de información necesarios, una arquitectura flexible y escalable y un sistema de testing automatizado que nos garantice que cumplimos los requisitos no funcionales en modo regresión entonces podremos modificar la historia de usuario para reflejar el objetivo real:</div>
<blockquote>
Como sistema quiero soportar el numero de usuarios concurrentes que necesite el negocio en todo momento de modo flexible, elástico y con una estructura de costes asumible por la organización.</blockquote>
<div dir="ltr">
Pero eso requiere un nivel de madurez enorme en toda la organización: el negocio debe decir de forma continua (o casi) la demanda prevista, la capacidad debe poderse adaptar de forma instantánea, las arquitecturas deben poderse redimensionar al momento y todo esto con un esquema económico razonable… o podemos quitar al negocio de la ecuacion y montar un sistema flexible y automatizado que crezca o decrezca según la demanda real…</div>
<div dir="ltr">
¿Ciencia Ficción?</div>
<div dir="ltr">
¡Preguntale a Etsy o a Netflix!</div>
PS:: <strike>Iba a ilustrar este post con alguna foto… lo primero que me vino a la cabeza fue esta preciosa ranita de San Antonio del blog <a href="http://naturalezaandaluza.blogspot.com.es/2013/08/ranita-de-san-antonio.html" target="_blank">Naturaleza Andaluza,</a> pero finalmente me he negado…. no se ha dañado ninguna rana para escribir este post.</strike> Ojalá Peter Senge piense en otra parabola menos salvaje!<br />
<br />
PS2: Pues resulta que este post inspiró a mi amigo Rui Soares, autor de ITIL Blues y creador de los personajes Mush & Room, quien me dibujó la fantástica ilustración que acompaña este artículo. GRACIAS!Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.com0tag:blogger.com,1999:blog-24620302.post-4665520761052422342016-06-14T16:11:00.002+02:002016-06-14T16:12:07.871+02:00El secreto que el itSMF no quiere que sepas<p>Hace un par de meses me llamaron desde el equipo que organiza el X Curso de Verano del itSMF para preguntarme si me gustaría participar en una de las clases. La temática de este año es Preparando a los profesionales de IT para la transformación digital, algo que es imprescindible para la evolución que tendrán las empresas en los próximos años.</p><p><br></p><p>Llevo colaborando con esta asociación desde su fundación allá por el año 2005, así que no podía negarme; planteé una clase teórico-práctica sobre el impacto que tiene la cultura DevOps en la prestación y operación de servicios y me encajaron en la agenda, que <a href="http://itsmf.es/index.php?option=com_content&view=article&id=2255" target="_blank">puedes consultar en este enlace</a>.</p><p>¿Has visto los contenidos? ¡Como cada año, este curso de verano es interesantísimo! Hablaremos de Modelos de Transformación, de Bimodal-IT, de DevOps, de Gamificación... todo aquello que necesitas echarte a la mochila para facilitar la transformación digital de tu compañía (por ejemplo, leiste el artículo que publiqué hace unos meses titulado "<a href="http://https://www.linkedin.com/pulse/transformación-digital-sin-devops-antonio-valle?trk=mp-author-card" target="_blank">¿Transformación Digital? ¡No sin DevOps!</a>" )</p><p>Cuando el equipo del itSMF España publicó la agenda del curso, me sorprendió agradablemente ver que el <u>precio del curso es de 295€</u>; teniendo en cuenta los contenidos y la duración del curso es un precio más que razonable. Pero cuando se envió el mailing presentando el curso a los miembros del itSMF vi encantado que <strong>el curso es gratuito para los miembros de la asociación!!</strong></p><blockquote>El X Curso de Verano del itSMF España, centrado en las habilidades y conocimientos que debe adquirir el Área de TI para facilitar la Transformación Digital es una actividad gratuita para socios.</blockquote><p>Así que si eres miembro de esta gran asociación, <a href="http://itsmf.es/index.php?option=com_dtregister&Itemid=230&eventId=76&controller=event&task=individualRegister" target="_blank">no tardes en inscribirte al curso, en cualquiera de sus sedes.</a> Pero... ¿y si no eres socio? ¿Tienes que pagar los 295€ que cuesta la inscripción al curso?</p><p>Aquí es donde viene el secreto que quiero contarte... el itSMF España lleva 11 años dando charlas, haciendo congresos, publicando documentos, haciendo whitepapers. En definitiva, esta asociación lleva 11 años compartiendo conocimiento en prácticas relacionadas con la Gestión de Servicios y todo ese conocimiento está almacenado en las interioridades del portal de socios de la organización.</p><p>Esta asociación organiza anualmente al menos tres congresos (el Nacional, el de Catalunya y el Universitario), varios encuentros regionales, varios seminarios en modalidad online, un curso de verano y uno de herramientas. Todas esas charlas y presentaciones se ponen al alcance de los miembros de la asociacion sin que esto suponga un coste extra al importe de la membresía; y hacerte socio de itSMF España cuesta 100€ al año.</p><blockquote>Hacerte socio del itSMF España sólo cuesta 100€ al año y te aporta más beneficios de los que te esperas<br></blockquote><p>Así que si quieres asistir al curso de verano, enterarte de todo lo que vamos explicar y de rebote tener acceso a la mayor biblioteca de prácticas de gestión de servicios en castellano <a href="http://www.itsmf.es/index.php?option=com_comprofiler&task=registers" target="_blank">hazte socio del itSMF España ya mismo</a>, antes de que se den cuenta y cambien las políticas de membresía o suban los precios!</p>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.comtag:blogger.com,1999:blog-24620302.post-15579287720865376672016-05-31T18:16:00.003+02:002016-05-31T18:49:33.232+02:00La primera paga extra<p>Corría el año 1983 y yo entraba en el instituto con la cabeza llena de ideas y sobre todo con una pasión que me había acompañado desde que tengo memoria: la biología. Desde que tengo recuerdos, yo iba a ser biólogo, a ser posible entomólogo o herpetólogo, y mi mayor héroe era <a href="https://es.wikipedia.org/wiki/Gerald_Durrell" target="_blank">Gerald Durrell,</a> que se había criado de una manera muy parecida a mi, en una isla y rodeado de bichos (para muestra, un botón: el libro <a href="http://https://www.amazon.es/Bichos-demás-parientes-Libro-Bolsillo/dp/8420674214" target="_blank">“Bichos y demás parientes”</a>).</p><p>Una vez en el instituto conocí a Víctor, quien se convertiría en uno de aquellos amigos “para toda la vida” y que compartía conmigo un montón de aficiones e intereses, como la música y las matemáticas (pero no la biología). Víctor tenía una calculadora HP de aquellas que se programaban en notación polaca inversa y eso era la bomba! No había nada más entretenido que pensar en cómo hacer que la calculadora aquella nos ayudara con los problemas de trigonometría. A mitad de curso yo ya pensaba que después de hacer biología me gustaría aprender algo de informática.</p><p>Más adelante, Víctor me presentó a un amigo suyo que estudiaba FP y que tenía una calculadora programable que se programaba en Basic, una Casio PB-100</p><div class="separator" style="clear: both; text-align: center;"><img src="http://www.pisi.com.pl/piotr433/pb700.jpg"></div><p><br>No me lo podía creer! Aquello era la bomba! *Necesitaba* una..! Me la prestó un fin de semana y creo que no hice otra cosa durante esos dias que programar y programar… había que ver qué era capaz de hacer esa maravilla.. ¿multiplicar determinantes? ¿hacer integrales definidas? ¿calcular fórmulas químicas?</p><p>Unos años antes, en 1976, había desembarcado en Gran Canaria un equipo de El Corte Inglés con la misión de construir el primer centro de los grandes almacenes en la isla. Escogieron para construirlo justamente el solar que había al lado de mi casa, allí donde los chiquillos del barrio jugábamos a futbol o practicábamos tiro al blanco con piedras y latas vacías. En 1977 inauguraron por todo lo alto el local con bendiciones del párroco de la Iglesia del Pino incluidas! </p><div class="separator" style="clear: both; text-align: center;"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhUX-_c3axBNMT7KsJVfRcizsCMejSzaR0LoVZ5SwyKkeGQbzb3GaxXcxV_pZWtGAGlP5zoD2kf6APjVNMRp1gAR92mZWncWXB5mbw1_BNLw3CEjds5UHk8oyPk479C8GG53mMP2w/"></div><p>Así que para los años de instituto yo ya era un asiduo a pasar el tiempo libre echando un vistazo en los escaparates de El Corte Inglés; hasta que un día los chicos de ECI pusieron a la venta una “cosa rara”: un ordenador personal (??) que se conectaba a la televisión y se podía programar: un <a href="https://es.wikipedia.org/wiki/Sinclair_ZX81" target="_blank">Sinclair ZX-81</a>. Yo inmediatamente me llevé a mi padre a ver aquello y a decirle que me encantaría tener una cosa de esas, pero la respuesta de mi padre fue tajante: “Eso es una porquería. El día que tengan un ordenador de verdad, te compro uno."</p><p>¡¡Un ordenador de verdad!! Y el maravilloso ZX que tenía delante qué era?? Pues a ojos de mi padre, el ZX-81 debía ser poco más que una calculadora programable o incluso menos! Así que hubo que esperar. Pero mientras esperaba yo iba casi cada día a mirar aquel aparato, luego vinieron otros: el Spectrum, el Casio portable, los diferentes fabricantes y modelos de MSX, el Vic-20, el Commodore 64...</p><p>Pasaron al menos dos o tres años en los que yo invertía gran parte de mi tiempo libre en ir a la Planta 4 de El Corte Inglés a toquetear ordenadores; todo lo que aprendía en el instituto lo intentaba aplicar así que “inventé” las <a href="https://es.wikipedia.org/wiki/Curva_de_Lissajous" target="_blank">curvas de lissajous</a> (luego descubrí que ya estaban inventadas), implementé los algoritmos para multiplicar determinantes, descubrí que si pintas una gráfica en la que la X se mueve según un sin(t) y la Y se mueve segun cos(t) obtienes una circunferencia (si y solo si las dos variables están debidamente sincronizadas) y luego cuando en el instituto me explicaron las coordenadas polares me resultó obvio: ¡ya lo había descubierto en El Corte Inglés!</p><p>Llegué a conocer a los dependientes y ganamos tanta confianza que cuando un “adulto” entraba preguntando por un ordenador para comprarle a su hijo, lo redirigían a mí para que le explicara para qué podría usar el ordenador su criatura.</p><p>Y un buen día llegué yo a la cuarta planta y uno de los chicos me dijo “Mira: ha llegado esto; a ver qué puedes hacer con él”… y allí estaba… flamantemente nuevo, un <a href="https://es.wikipedia.org/wiki/Amstrad_CPC_464" target="_blank">Amstrad CPC 464</a> con sus 64Kb de RAM y lo que era más alucinante, su monitor de súper alta resolución que podía darte 320x200 en cuatro colores!!</p><p>No me lo podía creer, aquello era un pedazo de ordenador; seguro que sería lo que mi padre llamaba “un ordenador de verdad”. Así que lo llevé a verlo y … no!, seguía siendo un juguete; así que tocó seguir aprendiendo, programando y casi que trabajando en El Corte Inglés.</p><p>Para acortar un poco la historia, cuando Amstrad presentó el CPC-6128 ya en el año 1985, aquello ya se pareció a “un ordenador de verdad”, así que mi padre hizo un tremendo esfuerzo (que lógicamente ocultó y del cual yo no fui nunca consciente) y me compró el aparato. Ya con él en casa, me conseguí un manual de programación en ensamblador y de llamadas al sistema (fuera lo que fuera aquello) y escribí mi primer juego en ensamblador (una variante de Tron, película que me había dejado encandilado por aquella época)</p><div class="separator" style="clear: both; text-align: center;"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrl2osRRhM9jv6BqNWr8Yt0BMGRMqJOOdHI9aGOKWsHCJXLUDpcVgwJlywEyw9VrjhFJ-Ofq1cX7PqLQERUXYm7IYD9MaXOUEtdDdxKA7sZAQFZypGQ-JzuKxvzjfWjyOUdQSwUQ/"></div><p>El resto ya vino rodado; un día estaba en El Corte Inglés y llegó un señor a preguntar quién podría hacer un programa para llevar el control de los gastos de la flota de ambulancias de la Cruz Roja y el dependiente me señaló a mí. Fueron mis primeras 10.000 pesetas ganadas honradamente programando; luego alguien de Indescomp buscaba a un programador que pudiera hacer las traducciones del software educativo al castellano y comencé a trabajar para ellos: me daban los diskettes del software en inglés y con una herramienta muy parecida a las PC-Tools, yo traducía aquello al castellano con un editor hexadecimal. Ahora mirándolo en la distancia me parece que la cosa no debía ser muy legal, pero yo estaba convencido de que si, porque ellos eran “la casa madre”.</p><p>Ya para esa época había abandonado la idea de estudiar Biología (bueno, en realidad decía que estudiaría Biología después de Informática; que la Informática sería para comer y la Biología para gozar), así que cuando estaba en 3º de BUP me compré una calculadora Casio FX-850P que me acompañó durante todos mis años de facultad y que aún tengo en mi poder en perfecto estado. Entré en la Facultad de Informática de la ULPGC y empecé a jugar en una liga más importante, así que vendí el CPC-6128 y me compré mi primer PC, un Amstrad PC1512 que fué rápidamente substituido por un Inves 80286 (También de El Corte Inglés!).</p><div class="separator" style="clear: both; text-align: center;"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjItpkOgg3M4cQ0WkA1fMwhSDcVdUt3rR6puSlnwHebrJBSEkD-9Adkj5QniWNPsypTCbCBZLsV6yoZkUzxLjIVn8QWnvfiwaofehgIKd07oFoQuEd3QKqB2eOwK8LTDRIlBVdvA/"></div><p>Así que cuando la semana pasada ví en la tele la publicidad de El Corte Inglés titulada “La primera paga extra” me emocioné mucho… parecía como si alguien de ECI hubiera entrado en la agencia de publicidad a pedir un spot emotivo y hubiera contado mi historia; el chaval baja las escaleras feliz por haberse comprado su primer iPad y yo comencé a construir mi futuro gracias a aquel Amstrad y al buen criterio de mi padre que no quiso comprarme un “ordenador de juguete” sino que decidió que había llegado el momento de hacer el gran esfuerzo familiar cuando vio que aquello realmente me interesaba.</p><div class="embed-wrapper" style="clear: both; text-align: center;"><iframe width="560" height="315" src="https://www.youtube.com/embed/68bbIPi1n6M" frameborder="0" allowfullscreen=""></iframe></div><p><strong><br>33 años después, GRACIAS.<br></strong><br><strong>Gracias a mis padres</strong>, por el pedazo de esfuerzo que sé que tuvieron que hacer.<br><strong>Gracias a mi familia</strong>, por el apoyo que siempre me han mostrado.<br><strong>Gracias a mis amigos</strong>, por darme el empujón que me cambió la vida.<br><strong>Y Gracias al equipo de El Corte Inglés</strong> que trabajaba en la Planta 4 del centro de Mesa y Lopez 15 porque podrían haberme echado o haberme dicho “niño, no toques los ordenadores que son muy caros”, pero sin embargo me dejaron hacer durante los 3 ó 4 años que estuve yendo hasta que entré en la Universidad y me facilitaron el acceso a algo que no me podía permitir fácilmente.</p>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.comtag:blogger.com,1999:blog-24620302.post-1633828615740470612016-04-29T13:48:00.004+02:002017-06-15T14:40:57.951+02:00¿Transformación Digital? No sin DevOps!!<p>Se me repite la ocasión en que vuelvo a casa despues de un curso de <a href="http://formacion.gedos.es/programa-de-formacion/devops-foundation/" target="_blank">DevOps Foundations</a>. Probablemente disponer de tres horas de tranquilidad después de tanta actividad hace que me aparezcan algunas ideas y me den ganas de escribir.</p><p>Una de las slides que presento en la versión para <em>managers</em> de este curso está sacada del documento <a href="https://puppet.com/resources/white-paper/2015-state-of-devops-report" target="_blank">State of DevOps Report 2015</a>, 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.</p><div class="separator" style="clear: both; text-align: center;"><a href="file:///Users/avalle/Library/Containers/com.blogo.Blogo/Data/Library/Caches/com.blogo.Blogo/1461929662_full.png" target="_blank"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhejQnaGreqxF1jHwWh2kVR5CMRUpqv8Q_fZ2nCOW9lEfdWn6N2tBc9sdmWDF-tZ3VM3jxeDQPVeLtU2fiFTwc8mo2rbLCr55GJ2lteAb0O2XUB_uCOfF783PDphB23jvTLCELSSQ/"></a></div><p>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.</p><p>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.</p><p>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</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhdgQdrkijYGeZ_TIgcQOMsF7BRIPtzY-Tw42LXyegQO2ms3V4sACJuNz0NqjaX2R4pMJGyyQvWmn6tWnexu213GDLhwHGKXsauZEkoORmfMOLAf2WbfQ8NKFUpsBzP3jH5iB0fvQ/" target="_blank"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBoKwSZZz4TfB0PVpRKDgNsbCBKvQaK0B4Rw0jziBO3kqMueORCNWxPioXvwvGFjOBejTv51q0NXg0ao-x-RuOOWl1Xyd0gTa3hdQ5BQtEYGUzFXdQ6JIsI2L9SDRQP7mm-YXxRA/"></a></div><p><br>¿Y qué significa esto? Pues básicamente que</p><p>a) Los “<em>low performers</em>” (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.</p><p>b) El rendimiento de los “<em>low performers</em>” 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 <em>high performers </em>para poder percibir esta situación:</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiz8FBhE2HkU1PtQm-Z3og6cAmLOvLdifsmt0zen8Q84kz71tSifE-CUHIPRI-l_tcUKNsrSMUkNc5B8VLm0vPp6ZGDZJ-JjT6A7DFiFlJq_gRHETW2WyivbuzI3-qXNXfbQ8ydeA/" target="_blank"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOkpIkZblLYbnnd0GeZRO03d3pniVi8wQPDi0KXNGfu9Qat27QxadsA9uCk5IFRKxkDtjUnAOc0bkhPFArNOWEe5r5l0AV2-_1ksT9iup123do0nPfh1XlQRFWfxjtRuzLCyVIow/"></a></div><p><br></p><p>c) Con respecto a los “<em>Mid Performers</em>”, 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)</p><p>d) Finalmente, los “<em>High Performers</em>”. 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 (!!!)</p><p>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?”.</p><p>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</p><div class="separator" style="clear: both; text-align: center;"><a href="file:///Users/avalle/Library/Containers/com.blogo.Blogo/Data/Library/Caches/com.blogo.Blogo/1461871155_full.png" target="_blank"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiFr-7RgNaztTtXu6buLm8eBlTdPBEUN7JocejtwV8UU1JyDcCRcL6T5qBk67H2Z06FqBkixe0P4IcyfwmksY_e6NJWWUiC8G_fp5YcEh-nhWGsq3JYPJHFsQwIpf_YJhui_wyp9w/"></a></div><p>Ok, pues esto nos muestra que se está produciendo una brecha inmensa que está separando a los <em>high performers</em> del resto del mundo a una velocidad pasmosa y eso es un problema.</p><p>Ahora piensa en todos aquellos que están hablando sobre <u><strong>Transformación Digital</strong></u>. 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?</p><p>Y resulta que todo el concepto de <strong>Transformación Digital</strong> se basa en cuatro palabras: <strong>experimentar, innovar, aprender y digitalizar.</strong> 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.</p><p>¿Y cómo puedes conseguir eso en un entorno <em>digitalizado</em>? Pues con <u>velocidad</u>. Necesitas que en IT tu flujo de aportación de valor sea muy rápido y que tu <em>lead time</em> 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.</p><p>Resulta que los high performers han llegado a una situación en la que su <em>lead time</em> 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 <em>high performers</em> 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”: <u>o espabilamos o se nos comen!!</u></p><p>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: <br></p><ul><li>una cultura de colaboración<br></li><li>una organización transversal que huye de los silos verticales<br></li><li>equipos multidisciplinares<br></li><li>flujo de valor<br></li><li>aprendizaje<br></li><li>automatización<br></li></ul><p>En definitiva, <strong>Lean-IT, Agile y DevOps </strong>o lo que nosotros llamamos<u><strong> Agile IT Management.</strong></u></p><p>Y esos cimientos debes construirlos rápido: los high performers llevan años haciéndolo así que no te van a dejar respirar.</p><p>No tardes y empieza ya!</p>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.com0tag:blogger.com,1999:blog-24620302.post-16501545138633302072016-03-30T23:43:00.005+02:002017-06-15T14:40:57.955+02:00La X Muda<p>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.</p><p>¿Que qué pasa el 23 de Marzo?</p><p>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…</p><p>Aqui tienes la primera entrada de este blog: <a href="http://www.gobiernotic.es/2006/03/la-cmdb-federada.html" target="_blank">La CMDB Federada</a> (qué ojo!! jeje)</p><p>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 <strong>una década de GobiernoTIC</strong>.</p><div class="separator" style="clear: both; text-align: center;"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmErbg9tpDpVgupTut9T9Oe5rXjWX7o3XqugjwDIPXnJxDnxz9b1GjaT4obXt2ZWzqEXcI-gk1Hj9sduyWcO8kdYch5S6NHKYwdVRB2D7PMadTkZOt_thit08c9LV196qFYbPOdA/"></div><p><u><strong>La X Muda</strong><br></u><br>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:<br></p><ul><li><strong>Muda</strong>: tipos de trabajo o acción que resultan en derroche de tiempo, esfuerzo, recursos, ...<br></li><li><strong>Mura</strong>: grupo de las ineficiencias producidas por falta de homogeneidad en las entradas, en las tareas, en las personas, ...</li><li><strong>Muri</strong>: grupo de las ineficiencias que se producen por el stress o sobretensión en personas y medios de producción</li></ul><p>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 <a href="https://en.wikipedia.org/wiki/Muda_(Japanese_term)" target="_blank">los 7 tipos de muda</a>):<br></p><ul><li>Transportation<br></li><li>Inventory<br></li><li>Motion<br></li><li>Waiting<br></li><li>Overprocessing<br></li><li>Overproduction<br></li><li>Defects<br></li></ul><p>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.</p><p>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).</p><p>Sin embargo, no aparecen en esta clasificación mudas que tengan que ver con el <em>cómo </em> se hacen las tareas, desde el punto de vista humano y no del procesos; desde el punto de vista de los “<em>soft-skills”. <br></em><br></p><blockquote>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!! </blockquote><p>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.</p><p>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 <strong>X MUDA: LA FRICCION<br></strong><br>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.</p><p>Podemos ver ejemplos de fricción cuando se pide hacer una tarea y se te activa la Tercera Ley de Newton: <em>"Actioni contrariam semper & æqualem esse reactionem” o sea "</em><u>Con toda acción ocurre siempre una reacción igual y contraria"<br></u><br>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.</p><p>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"</p><p>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.</p><p>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.</p><p>… y así es como yo veo la <strong>Décima forma de Muda: la FRICCION</strong>, 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…</p>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.comtag:blogger.com,1999:blog-24620302.post-14442332713569294972016-02-03T17:02:00.003+01:002017-06-15T14:40:57.945+02:00Umbrales de Tolerancia - Aprendiendo a delegar<p>Un par de semanas después de hacer el taller que <a href="http://www.gobiernotic.es/2016/02/acordando-niveles-de-delegacion.html" target="_blank">contaba en el post anterior</a> 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.</p><div class="separator" style="clear: both; text-align: center;"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjH_xAGB5izhDXWrPH7tjBm18RKJIkvTMLNB9OqZVKXbeumqO9JJCcCxuj2HUyBVK3hKzpCutCb4WyqVafm8Nhwn9uwi0eBhxRKqQ8NBzHfshkeNP5-DOk2lfwF-PaEPol-DIrcDg/"></div><p>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!</p><p>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”.</p><p>Que cosa más común, no?</p><p>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.</p><blockquote>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 <em>honeypot </em>para jefes!<br></blockquote><p>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.</p><p>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?</p><p>Y aquí es donde entra en juego este nuevo concepto: <strong>los umbrales de tolerancia. <br><br></strong></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1HeNJIxUyzcITbnx9Mzv8TFgVAEPeGaSh9LaOePBEsfVt8vdpOT-iXKj7qmrRttYX8fcb7xHl9CcojvgDPsGCUWZToFSgKDfzE6hNSMKbg9fpaeHBeDfXdhPlSq6hsdQMtqDE5A/" target="_blank" style="margin-left: auto; margin-right: auto;"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1HeNJIxUyzcITbnx9Mzv8TFgVAEPeGaSh9LaOePBEsfVt8vdpOT-iXKj7qmrRttYX8fcb7xHl9CcojvgDPsGCUWZToFSgKDfzE6hNSMKbg9fpaeHBeDfXdhPlSq6hsdQMtqDE5A/"></a></div><p><br></p><p>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).</p><p>Y tradicionalmente serán los del 5º sigma los que entran a saco en el micro management.</p><p>Si delegas un trabajo, tienes que estar dispuesto a que lo que recibas no sea <strong>exactamente</strong> 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.</p><blockquote>Delegar significa estar dispuesto a recibir el trabajo diferente a como te lo esperabas.<br></blockquote><p>Así que si delegas, prepárate a recibir cosas que no son <strong>exactamente</strong> 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.</p><p>Y cuando juegues al poker, el equipo pedira siempre un <strong>1 - Tell</strong>, 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"</p><p>¿Has tenido un jefe del quinto sigma? ¿Cómo lo has vivido?</p><p>¡¡Pues no lo seas tu!!</p><p>PS:: Mis agradecimientos a <a href="https://itilblues.wordpress.com" target="_blank">Rui Soares</a> 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! </p><p>Foto original de <a href="https://stocksnap.io/author/5032" target="_blank">Krzysztof Puszczyński</a></p>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.com2tag:blogger.com,1999:blog-24620302.post-15513797802078290362016-02-01T15:39:00.002+01:002017-06-15T14:40:57.948+02:00Acordando niveles de delegación<p>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 <a href="https://nl.linkedin.com/in/paul-wilkinson-20b396" target="_blank">Paul Wilkinson</a> quien, desde que yo conozco esto de la Gestión de Servicios, ha sido monotemático: lo importante son<strong> las personas</strong> [y desde 2004 que sigo oyendo el eco de sus palabras "las personas, las personas, …”]</p><p>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.<br></p><blockquote>Yo lo que necesito es que ellos tomen las decisiones sin que yo tenga que entrar al micromanagement, dijo el CIO.<br></blockquote><p>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.</p><p>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 <a href="https://es.linkedin.com/in/gabrielprat" target="_blank">Gabri Prat</a>, <a href="https://es.linkedin.com/in/angelm" target="_blank">Angel Medinilla</a> y <a href="https://es.linkedin.com/in/adiazmaroto/en" target="_blank">Angel Diaz-Maroto</a>.<br></p><div class="separator" style="clear: both; text-align: center;"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4Od4DjjyFtaeEr6B95uCjtefwyZpU4yVgo4qd4L_oczdr2PmfnVxxHySOA04rkwB-qdptrbeqLhPa2R8POZo57reE1ZTlCMO9CyPcY5-b-BeQhactqZYmN_uGsR6Z0dLof2GNxw/"></div><p>La idea que subyace detrás de este taller es identificar el conjunto de <strong>decisiones</strong> 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.</p><p>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!!<br><br>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.</p><p>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.</p>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.comtag:blogger.com,1999:blog-24620302.post-24483724944195815832015-11-20T16:46:00.001+01:002017-06-15T14:40:57.971+02:00La muerte del proyecto o el Nirvana del Flow<p>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.</p><p>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.</p><p>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).</p><p>¿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. </p><p>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.</p><p>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. </p><p>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.</p><p>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.</p><p>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!!).</p><p>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. </p><p>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).</p><p>Esta manera de pensar ha sido <u>“la muerte del proyecto”</u> 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.</p><p>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! </p><p><strong>El mes que viene hay hackaton. ¿Te animas?<br></strong><br>———<br>REFERENCIAS:</p><p>Para los conceptos de MVP y experiementación para incorporar la innovación, Lean Startup de<strong> Eric Ries</strong><br>Para los ciclos cortos de desarrollo y contacto con el cliente, Agile<br>Para la automatización de los ciclos de desarrollo-pruebas-despliegue, Integración Continua de <strong>Jezz Humble</strong><br>Para la cohesion de equipos multidisciplinares (de verdad), DevOps y Agile.<strong> Gene Kim y Jezz Humble</strong><br>Para la motivación de los equipos y mantenerlos a tu lado, Management 3.0 de <strong>Jurgen Appelo</strong><br>Para aprender más de todo esto sin tener que leerte la Biblioteca de Alejandria, <a href="http://www.gedos.es" target="_blank">G2 Gobierno y Gestión de TI</a></p>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.comtag:blogger.com,1999:blog-24620302.post-66119309656428727312015-10-20T16:26:00.001+02:002015-11-06T12:28:00.210+01:00Mi ruta en el Vision15Ya está aquí el <a href="http://www.itsmf.es/index.php?option=com_content&view=article&id=1694:congreso-anual-vision15&catid=79:noticias&Itemid=401" target="_blank">Vision15</a>, 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.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<img border="0" src="http://www.itsmf.es/images/uploaded/congreso_nacional_vision_15/banner/baner_alargado.jpg" height="83" width="640" /></div>
<br />
<br />
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!!.<br />
También he decidido dejarme algunos<b> huecos libres</b>: 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. <br />
<br />
<i>¿Que tienes ganas de que hablemos de algo concreto?</i><br />
Pues me he dejado cuatro slots el primer dia y dos el segundo para comentar. <br />
<i><br /></i>
<i>¿Que quieres una demo de Process Mining? </i><br />
Pues tenemos tiempo más que de sobras para mirarlo con calma.<br />
<i><br /></i>
<i>¿Que quieres que nos tomemos una cerveza mientras hablamos de un plan de formación en DevOps? </i><br />
Tenemos sofás y tiempo. Yo pago la cerveza ;-)<br />
<br />
El primer día a las 12:20 es mi ponencia sobre el <b><a href="http://itsmf.es/index.php?option=com_content&view=article&id=1841" target="_blank">uso de la Minería de Procesos en ITSM</a></b>; luego por la tarde, a las 17:10 es la ponencia de Telefónica explicando su <b><a href="http://itsmf.es/index.php?option=com_content&view=article&id=1844" target="_blank">caso de éxito en el uso de la Minería de Procesos </a></b>y el viernes a las 10:20 es la ponencia sobre <b><a href="http://itsmf.es/index.php?option=com_content&view=article&id=1857" target="_blank">integración de herramientas ITSM</a> </b>multifabricante, un caso muy interesante de integración en escenarios de outsourcing multiproveedor en el que <a href="http://www.gedos.es/" target="_blank">G2</a> ha tenido una participación importante.<br />
<br />
En fin, sin más preámbulos, esta es mi selección. <br />
<br />
<b><span style="font-size: large;">Jueves 12</span></b>:<br />
<span style="font-family: "courier new" , "courier" , monospace;">9:45 - 10:20 PP.1 El IT como bróker de Servicios<br />10:20 - 11:00 PP.2 Hacking Físico<br />11:00 - 11:40 CAFE<br />11:40 - 12:20 <span style="background-color: orange;"><<LIBRE>></span></span><br />
<strong><span style="font-family: "courier new" , "courier" , monospace;">12:20 - 13:00 <a href="http://itsmf.es/index.php?option=com_content&view=article&id=1841" target="_blank" title="Esta es mi ponencia! No te la pierdas! :-D">Posibilidades de uso en la minería de procesos </a></span></strong><br />
<span style="font-family: "courier new" , "courier" , monospace;">13:00 - 13:40 Cómo conseguir un SLA adaptado<br />13:40 - 14:20 Ingeniería del Éxito<br />14:20 - 15:30 COCTEL</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">15:30 - 16:10 <span style="background-color: orange;"><<LIBRE>></span><br />16:10 - 16:50 <span style="background-color: #cfe2f3;">¿Cómo es una organización Ágil?</span><br />16:50 - 17:10 <span style="background-color: orange;"><<LIBRE>></span><br />17:10 - 18:00 Ojo de Halcón<br />18:00 - 18:40 Influencia del Factor Humano<br />18:40 - 18:50 Resumen jornada (SALÓN ATOCHA)<br />18:50 - 20:00 <span style="background-color: orange;"><<LIBRE>></span></span><br />
<br />
<b><span style="font-size: large;">Viernes 13:</span></b><br />
<span style="font-family: "courier new" , "courier" , monospace;">09:00 - 09:40 PP.3 Recuerdos del futuro presente<br />09:40 - 10:20 Aplicación de tecnologías analíticas<br />10:20 - 11:00 <span style="background-color: #cfe2f3;">Integración herramientas ITSM multifabricante </span><br />11:00 - 11:30 CAFE<br />11:30 - 12:10 Hacia la excelencia con Lean(Out)sourcing <br />12:10 - 12:50 Cuarto y mitad de gobierno, por favor.<br />12:50 - 13:30 <span style="background-color: #cfe2f3;">ITSM2020 nuevo modelo para la gestión de negocios</span><br />13:30 - 13:50 <span style="background-color: orange;"><<LIBRE>></span><br />13:50 - 15:00 PP.4 PANEL DE EXPERTOS/MESA DEBATE<br />15:00 - 15:30 AC.4 Entrega de galadornes y cierre del Congreso<br />15:30 - 16:30 <span style="background-color: orange;"><<LIBRE>></span></span><br />
<span style="font-size: x-small;"><br /></span>
¿Cuál es tu selección? ¿Me pierdo algo que no debería?Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.comtag:blogger.com,1999:blog-24620302.post-1749942162968329722015-10-16T14:03:00.003+02:002017-06-15T14:40:57.958+02:00La minería de procesos en acción<p>Hacía mucho tiempo que tenía ganas de hacer esto. Un pequeño vídeo que demostrara las capacidades de la minería de procesos de tal forma que te pudieras hacer una idea más clara de lo que se puede llegar a conseguir con este tipo de herramientas.</p><p>La semana pasada organizamos en G2 el evento Business Process Transformation, donde explicamos varias técnicas que nos permiten facilitar la mejora continua y la transformación de los procesos de negocio, y entre ellas hablamos de la minería de procesos. Un “problemilla” técnico deslució mucho una demo en la que tenía puestas muchas ilusiones así que he aprovechado un rato que tenía disponible para preparar este video. No soy un profesional de la edición, así que ha quedado como ha quedado… pero estoy seguro de que te activará las neuronas y te dejará imaginando cómo podrías aplicar este tipo de ideas en tus procesos.</p><p>Sólo una pista a tener en cuenta: cuando hablamos de “proceso” hablamos de “cosas que cambian en el tiempo”… así que podemos aplicar estas técnicas para analizar la evolución en el tiempo de cualquier concepto. Por ejemplo, mi compañero <strong>Jorge</strong> hizo una extracción de datos de LinkedIN para representar el mapa de cuáles son los caminos más exitosos para que una persona se convierta en CIO. Mi amigo <strong>Mariano</strong> quiere utilizarlo pasa estudiar el comportamiento de los alumnos en los MOOC de la Generalitat y yo lo he utilizado para estudiar el <strong>proceso de conformación de facturas</strong> o el <strong>factor de rotación de personal de un outsourcer</strong> del que no se mucho más que el rastro que dejan sus operadores en mis herramientas de gestión.</p><p>Abre tu mente, imagina cómo podrías utilizarlo y ponte en contacto con nosotros en <a href="http://www.gedos.es/" target="_blank">http://www.gedos.es</a> si quieres un piloto o una prueba con tus propios datos. ¡Aprender es gratis!</p><div class="embed-wrapper" style="clear: both; text-align: center;"><iframe src="https://player.vimeo.com/video/142614666" width="600" height="337" frameborder="0" webkitallowfullscreen="" mozallowfullscreen="" allowfullscreen=""></iframe></div>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.com0tag:blogger.com,1999:blog-24620302.post-22890865747760784822015-07-23T19:31:00.001+02:002017-06-15T14:40:57.965+02:00DevOps Foundations<p>Hace sólo un par de días se ha publicado el <a href="https://puppetlabs.com/2015-devops-report" target="_blank">State of DevOps Report 2015,</a> 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 <em>Key Findings </em>son para dejar con la boca abierta a cualquiera:<br></p><blockquote><ul><li><strong>High-performing IT organizations experience 60 times fewer failures and recover from failure 168 times faster than their lower-performing peers.</strong> 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.<br><br></li><li><strong>Lean management and continuous delivery practices create the conditions for delivering value faster, sustainably</strong>. 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.<br></li></ul></blockquote><p><br>La promesa de ser capaz de llevar valor al negocio en forma de funcionalidades TIC <strong>30 veces más frecuentemente, 200 veces más rápido y de una forma 60 veces más estable</strong> 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.<br><br>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 <strong>DevOps Foundations</strong>, una experiencia de 20 horas en la que combinamos unas 5 horas de teoría y le sacamos brillo a nuestros skills más <em>techies</em> con unas 15 deliciosas horas de práctica.</p><p>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:<br></p><ul><li><span>Una</span><span> <strong>Keynote</strong> 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.</span><br></li><li>Una <strong>Master Class</strong> 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. </li><li>Un curso <strong>DevOps Foundations</strong> 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 <em>por qué las cosas se hacen así </em>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:<ul><li>El control de versiones</li><li>El Build</li><li>Las pruebas unitarias</li><li>La conexión con el repositorio de binarios</li><li>La gestión de la configuración</li><li>Las pruebas de integración</li><li>Las pruebas de carga</li><li>El despliegue al entorno de producción</li><li>La monitorización de los sistemas</li><li>La monitorización de la aplicación</li><li>La representación en el dashboard y la correlación con los despliegues</li></ul></li></ul><p>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.</p><div class="separator" style="clear: both; text-align: center;"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiBH74JFCks3K8v9ecN6BXSJ_Nm3-ZH6ZBp_JJh8wwc5YUKnNrls9zZ3Auye29AgF1oBCulwxMWk9WVbAIRB8HRJ6V61hYdliSYjJ4D7566flzlFP4He_NajvP1qsU_Gs4N5Han8A/" alt="Obviamente, también hemos jugado...." title="Obviamente, también hemos jugado...."></div><p><br>Queda abierta la puerta para el desarrollo de un curso de nivel <strong>Advanced</strong> 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. </p><p>Tambien vemos necesaria la creación de un nivel <strong>FusionSM</strong>, 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... </p><p>¿Te imaginas hacer un <em><strong>push</strong></em> 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?<strong> ¿Se lo imagina tu negocio?<br></strong></p>Antonio Vallehttp://www.blogger.com/profile/06837335195928034488noreply@blogger.com0