{"id":34157,"date":"2019-10-31T21:56:43","date_gmt":"2019-10-31T18:56:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-nachat-devops-transformatsiyu\/"},"modified":"2019-10-31T21:56:43","modified_gmt":"2019-10-31T18:56:43","slug":"kak-nachat-devops-transformatsiyu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-nachat-devops-transformatsiyu","title":{"rendered":"C\u00f3mo iniciar una transformaci\u00f3n DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Si no entiende qu\u00e9 es DevOps, aqu\u00ed tiene un breve resumen. DevOps es un conjunto de pr\u00e1cticas que reducen los temores de los ingenieros<\/strong> y disminuyen el n\u00famero de fallos en la producci\u00f3n de software. Por lo general, tambi\u00e9n acortan el tiempo de lanzamiento al mercado<\/strong> \u2014 el periodo desde la idea hasta la entrega del producto final a los clientes, lo que permite realizar r\u00e1pidamente experimentos comerciales.<\/strong>.<\/p>\n

\u00bfC\u00f3mo comenzar una transformaci\u00f3n DevOps? En resumen: elegimos el servicio con el que comenzaremos el proceso, identificamos a quienes est\u00e1n relacionados con el servicio, construimos un mapa de flujo de valor, creamos un equipo temporal que se encargar\u00e1 de la transformaci\u00f3n al principio y le asignamos tareas. Repetimos el ciclo tantas veces como sea necesario.<\/p>\n

\"C\u00f3mo<\/p>\n

Un plan detallado de la transformaci\u00f3n DevOps con ejemplos e instrucciones se encuentra en la descripci\u00f3n de Alexey Sidorin<\/a><\/noindex> Andrey Aleksandrov<\/b> \u2014 del ingeniero en la empresa Express42, que asesora sobre el crecimiento de DevOps, acelerando este proceso porque ya ha construido un mapa de los obst\u00e1culos. Si cree que la transformaci\u00f3n no es necesaria o si su especificidad hace que las pr\u00e1cticas de DevOps no sean adecuadas, utilice el informe como una gu\u00eda para identificar y eliminar limitaciones.
\n<\/a><\/noindex>
\nSi le preocupa la transformaci\u00f3n DevOps, entonces tiene una gran empresa y necesita escalar este proceso gradualmente en toda la estructura. Mientras exista la necesidad de transformar un equipo o eliminar alguna limitaci\u00f3n, el algoritmo a continuaci\u00f3n se puede repetir.<\/p>\n

Selecci\u00f3n del servicio<\/h2>\n

\nSe ha delineado un plan, comenzamos con el primer paso: la elecci\u00f3n del servicio. El primer criterio es la vida \u00fatil<\/strong>: hay servicios antiguos \u2014 legacy, y nuevos. Se puede comenzar tanto con unos como con otros.<\/p>\n

Elegir un servicio joven tiene sentido<\/strong>: es nuevo, a\u00fan no hay un proceso de trabajo establecido en el equipo que se encarga de \u00e9l. No hay una gran carga t\u00e9cnica a su alrededor; no necesitamos repararlo todo el tiempo. Podemos hacer con \u00e9l todo lo que queramos.<\/p>\n

En el caso de un servicio antiguo, existen problemas relacionados con el hecho de que cambiar siempre es dif\u00edcil.<\/strong>Ya hay un conjunto de limitaciones serias, pero, quiz\u00e1s, hay personas involucradas que est\u00e1n dispuestas a hacer cambios \u2014 est\u00e1n cansadas y quieren hacer las cosas de manera diferente porque les duele.<\/p>\n

Trabajar con un servicio antiguo crea un poderoso precedente<\/strong> en su empresa \u2014 se puede cambiar algo. Si ha modificado un servicio nuevo, se lanza a producci\u00f3n 100 veces por hora, y todo va bien, entonces las personas en su empresa pueden decir:<\/p>\n

\u2014 \u00a1Es un nuevo servicio! Todo era f\u00e1cil, intenten hacer algo con nuestro cachivache.<\/em><\/p>\n

Un servicio legado tiene sentido transformarlo cuando lo haces con alguien, por ejemplo, si has invitado a un consultor externo. Seamos sinceros, la transformaci\u00f3n va a desafiar todo lo que se pueda.<\/strong>. Est\u00e1s experimentando y no sabes a d\u00f3nde llegar\u00e1s, qu\u00e9 tecnolog\u00edas y para qu\u00e9 vas a usar, d\u00f3nde y qu\u00e9 obst\u00e1culos surgir\u00e1n en los procesos. Por lo tanto, es m\u00e1s f\u00e1cil cambiar a uno nuevo.<\/p>\n

Si lo haces todo t\u00fa mismo y la empresa no tiene competencias serias, opta por el nuevo servicio. Si conoces a un consultor externo y tienes recursos, elige el antiguo.<\/p><\/blockquote>\n

\nHay servicios que son solo una interfaz para los usuarios, como un sitio sencillo o una aplicaci\u00f3n m\u00f3vil. Pero hay cuestiones serias como la facturaci\u00f3n. Si algo sale mal con la facturaci\u00f3n, ser\u00e1 complicado solucionarlo. Aqu\u00ed tambi\u00e9n tenemos opciones.<\/p>\n

Trabajamos ya sea con un servicio cr\u00edtico<\/strong>, pero ya estamos sufriendo por \u00e9l, crea limitaciones, o trabajamos con la interfaz<\/strong>. Este es el segundo criterio de elecci\u00f3n. De manera similar, hay la posibilidad de atraer a un consultor experimentado; trabajamos con la opci\u00f3n m\u00e1s complicada.<\/p>\n

Pero incluso en este caso, no recomendar\u00eda hacerlo, porque, hasta que no se entienda con qu\u00e9 trabajar y hacia d\u00f3nde transformar, tomar algo cr\u00edtico y reorganizarlo no es una buena idea. Por lo tanto, en este caso preferimos trabajar con la interfaz, cuya falla no es cr\u00edtica.<\/p>\n

A continuaci\u00f3n, examinaremos el equipo del servicio<\/b>. Con aquellos que manejan este servicio, tendremos que trabajar constantemente y colaborar en contacto muy estrecho.<\/p>\n

Las personas en el equipo se dividen, en t\u00e9rminos generales, en dos categor\u00edas: conservadores<\/strong> \u2014 viven en el viejo mundo, o simplemente no saben nada sobre DevOps, y innovadores<\/strong>, que traen todas las pr\u00e1cticas modernas. Los segundos no siempre entienden el tema, pero al menos est\u00e1n dispuestos a ello.<\/p>\n

Por un lado, los conservadores son personas experimentadas: llevan mucho tiempo en la empresa, conocen todo al detalle, pero no saben sobre las pr\u00e1cticas. Por el otro lado, los innovadores, que han o\u00eddo algo, pero probablemente no han estado en la empresa tanto tiempo. \u00bfCon qui\u00e9n es mejor trabajar?<\/p>\n

Con los conservadores hay que interactuar de todos modos, ya que es su servicio. Tendremos que comunicarnos con ellos, aclarar la especificidad del servicio, qu\u00e9 se puede hacer de esta manera y qu\u00e9 de otra. Dependemos de sus consultas. Seguramente habr\u00e1 que encargarles algo, porque ellos conocen su servicio mejor. Por eso, es importante con qu\u00e9 equipo finalmente tendremos contacto.<\/p>\n

Es l\u00f3gico elegir a innovadores para el equipo, porque los conservadores pueden poner obst\u00e1culos.\n<\/p><\/blockquote>\n

\nEn la pr\u00e1ctica, a menudo sucede que las personas conservadoras tienen una experiencia significativa, pero no comprenden c\u00f3mo avanzar. Simplemente tienen miedo de que, despu\u00e9s de la transformaci\u00f3n y renovaci\u00f3n del servicio, ser\u00e1n despedidos por no ser necesarios. A veces, simplemente por no entender lo que est\u00e1 sucediendo, sabotean el trabajo.<\/p>\n

Tuve un caso en el que un chico del equipo reparaba cualquier cosa, porque supuestamente era m\u00e1s cr\u00edtico que lo que est\u00e1bamos haciendo en ese momento. Establecemos una tarea: implementar esta parte hoy; no, en el otro extremo del mundo hay un incendio, vamos a repararlo. Trabajar con tales personas es complicado.<\/p>\n

Las personas del equipo conservador a menudo ignoran las tareas o las posponen hasta el \u00faltimo momento. Y si, Dios no lo quiera, cometiste un error y les pusiste KPI por la cantidad de tareas completadas, y alguna parte no est\u00e1 incluida en el KPI por alguna raz\u00f3n, entonces no har\u00e1n nada. En realidad, tendr\u00edan raz\u00f3n, porque entonces perder\u00edan su bonificaci\u00f3n.<\/p>\n

Con los innovadores es m\u00e1s f\u00e1cil, son m\u00e1s leales.<\/strong>Ya han escuchado algo, quieren avanzar, as\u00ed que ayudar\u00e1n. Necesitamos personas que est\u00e9n dispuestas a sufrir un poco al principio: si el servicio cambia, los innovadores ser\u00e1n los que soporten las dificultades como pioneros. Los innovadores quieren lo m\u00e1s nuevo y moderno, y est\u00e1n dispuestos a afrontar las dificultades.<\/p>\n

Los conservadores se pueden convertir en creyentes m\u00e1s tarde. Cuando muestres que has cambiado una parte y todo funciona bien, lo m\u00e1s probable es que tambi\u00e9n quieran probar y acepten la nueva religi\u00f3n DevOps.<\/p>\n

\"C\u00f3mo
\n<\/p>\n

En resumen. Si estamos haciendo toda la transformaci\u00f3n en nuestra empresa nosotros mismos, entonces elegimos: un nuevo servicio, preferiblemente con una interfaz simple, para no sufrir demasiado por su fallo, y un equipo de innovadores.<\/p><\/blockquote>\n

\nSi hay posibilidad de llamar a un consultor externo, en lugar de uno nuevo, tomamos el viejo servicio, del cual ya estamos sufriendo. Las personas que han estado en la transformaci\u00f3n durante un tiempo en diferentes compa\u00f1\u00edas han visto varios casos y ya entienden c\u00f3mo hacer las cosas correctamente y hacia d\u00f3nde deben dirigirse.<\/p>\n

\u00bfQui\u00e9n est\u00e1 involucrado?<\/h2>\n

\nNecesitamos encontrar a todos los que tengan alguna relaci\u00f3n con el servicio: desarrolladores, testers, administradores, expertos en seguridad, gerentes y, posiblemente, Product Owners. A pesar de que los Product Owners no son t\u00e9cnicos, tienen relaci\u00f3n con el servicio: toman decisiones y establecen tareas.<\/p>\n

\"C\u00f3mo
\n<\/p>\n

Todos los que tomen alguna decisi\u00f3n e influyan en lo que sucede con el servicio deben ser encontrados, presentados y comunicados.<\/p><\/blockquote>\n

\n\u00bfPara qu\u00e9 los necesitamos? Para saber con qui\u00e9n negociar.<\/strong>Durante la transformaci\u00f3n, cuando se cambia el principio habitual de trabajar con el servicio, habr\u00e1 una serie de problemas. Habr\u00e1 fallas durante un tiempo mientras probamos nuevos enfoques. La gente debe estar preparada para esto y estar de acuerdo.<\/p>\n

Luego, tendremos que construir un Value Stream Map y no podr\u00e1s hacerlo sin estas personas, porque solo ellos conocen toda la imagen de lo que est\u00e1 sucediendo. Una persona nunca sabe todo lo que ocurre con el servicio.<\/p>\n

Ellos aconsejar\u00e1n a personas para el equipo. M\u00e1s tarde discutiremos por qu\u00e9 se necesita un equipo separado. Tendremos que incluir a personas de los departamentos existentes. Aquellos que tienen relaci\u00f3n con el servicio podr\u00e1n recomendar colegas que piensen en nuestra direcci\u00f3n, que puedan ayudarnos y que tengan competencia en lo que necesitamos.<\/p>\n

Luego, reunimos a todas estas personas de diferentes departamentos en una sala y comenzamos a construir el Value Stream Map.<\/p>\n

Construimos el Value Stream Map.<\/h2>\n

\nEl Value Stream Map es un esquema o mapa que muestra el flujo de valores al cliente.<\/strong>Es todo el proceso desde la generaci\u00f3n de la idea hasta su implementaci\u00f3n, incluyendo todos los pasos intermedios y c\u00f3mo el valor finalmente llega a nuestros clientes.<\/p>\n

El Value Stream Map es necesario para visualizar todas las etapas del desarrollo,<\/strong>localizar problemas a trav\u00e9s de las medidas que existen en el proceso actual y comenzar a eliminarlos, y establecer un objetivo inicial.<\/strong>Este es el lugar donde comenzaremos a hacer algo de verdad.<\/p>\n

M\u00e9tricas<\/h3>\n

\nEn la literatura sobre Value Stream Map se describen muchas m\u00e9tricas diferentes, pero para empezar, solo necesitamos tres.<\/p>\n

Lead Time \u2014 retraso\/espera.<\/strong> \u2014 el tiempo que esperamos. Por ejemplo, un probador espera a que se libere un stand para las pruebas, y durante ese tiempo no puede hacer nada.<\/p>\n

Tiempo de Valor A\u00f1adido \u2014 tiempo de trabajo \u00fatil<\/strong> \u2014 el tiempo que gastamos en una etapa determinada para crear valor final para el usuario. Por ejemplo, un probador ejecuta su prueba y comienza a verificar algo. Este es el tiempo de trabajo \u00fatil, cuando realmente estamos haciendo algo por el producto. Esto es por lo que los clientes pagan: por software de calidad.<\/p>\n

%C\/A \u2014 porcentaje de trabajo aceptado. <\/strong>Tenemos una etapa \u2014 desarrollo, la segunda etapa \u2014 pruebas. Cu\u00e1ntas caracter\u00edsticas aceptaron los probadores de los desarrolladores, y existe este porcentaje.<\/p>\n

As\u00ed es como se ve nuestro mapa.<\/p>\n

\"C\u00f3mo
\n
\nPuede verse de manera diferente dependiendo de la estructura de la organizaci\u00f3n, la cantidad de departamentos y lo que hagas. Pero en general, en el mapa habr\u00e1 dos etapas: idea <\/strong>y an\u00e1lisis<\/strong>. En esta etapa se esperan datos, por ejemplo, Lead Time 2 semanas y Tiempo de Valor A\u00f1adido 2 d\u00edas.<\/p>\n

Cubrir m\u00e9tricas en todas las etapas.<\/p><\/blockquote>\n

\nBacklog<\/strong> \u2014 cu\u00e1ntas tareas quedaron despu\u00e9s de que los analistas las idearon.<\/p>\n

Desarrollo<\/strong> \u2014 cu\u00e1ntas semanas los desarrolladores esperaron aclaraciones sobre tareas, stands o equipos \u2014 no importa, pero estaban esperando algo. Por ejemplo, 4 d\u00edas implementan una caracter\u00edstica. Aqu\u00ed aparece la m\u00e9trica %C\/A. Los desarrolladores tomaron del Backlog solo el 80% de las tareas. Ellos consideran que las otras 20% no tienen un T\u00e9rmino de Referencia suficientemente claro, y las enviaron para revisi\u00f3n.<\/p>\n

Pruebas<\/strong>. En el esquema, LT est\u00e1 asignado 4 d\u00edas. Por ejemplo, los probadores esperaban la liberaci\u00f3n del stand de prueba, VA 2 d\u00edas realmente est\u00e1n probando algo, y %C\/A = 40 %. \u2014 solo el 40 % del c\u00f3digo o caracter\u00edsticas que enviaron los desarrolladores fueron considerados adecuados por los probadores. Todo lo dem\u00e1s no les gust\u00f3 por alguna raz\u00f3n.<\/p>\n

No entrar\u00e9 en detalle sobre c\u00f3mo realizar estas mediciones; al final del art\u00edculo recomendaremos literatura de la cual se puede aprender sobre ellas.<\/p>\n

Lo \u00fanico que recomendar\u00e9 es que no conf\u00eden en las personas que elaborar\u00e1n el mapa de flujo de valor con ustedes. Ellos representan cu\u00e1nto tiempo consumen diferentes procesos, pero estas estimaciones no siempre son precisas, por lo que es mejor medirlo uno mismo.<\/p>\n

Tuvimos un caso en el que fuimos al departamento de Operaciones y preguntamos cu\u00e1nto tiempo lleva implementar una nueva caracter\u00edstica en producci\u00f3n. Nos respondieron que 10 minutos, y pensamos: \u00bfpor qu\u00e9 venimos a esta empresa? Result\u00f3 que 10 minutos es el tiempo que toma el script que toma el c\u00f3digo y lo env\u00eda al servidor. Pero antes de eso, la versi\u00f3n permanece tres d\u00edas en el servidor sin hacer nada; hay una tarea en el Backlog que necesita ser desplegada. Entonces, hay una etapa de espera antes de la etapa de despliegue, donde el proyecto simplemente queda estancado. Si no hubi\u00e9ramos ido con un cuaderno, no hubi\u00e9ramos notado la tarea en Jira y no hubi\u00e9ramos empezado a hacer seguimiento, pensar\u00edamos que todo est\u00e1 bien y que no hay problema.<\/p>\n

Por lo tanto, tendr\u00e1s que realizar las mediciones t\u00fa mismo, preferiblemente m\u00e1s de una vez, para tener una idea m\u00e1s cercana a la realidad. Dependiendo del Value Stream Map, tomar\u00e1s decisiones sobre desde d\u00f3nde comenzar y qu\u00e9 corregir primero.<\/p>\n

Equipo temporal<\/h2>\n

\nMuchas empresas que han decidido implementar DevOps crean un equipo, pero no uno temporal, sino uno que existe desde hace varios a\u00f1os. Si consultaras un servicio de DevOps que describe diferentes patrones de estructura organizacional en DevOps, entender\u00edas que esto es un antipatr\u00f3n.<\/p>\n

Cuando un equipo de DevOps existe de manera constante durante varios a\u00f1os, es un gran error, porque DevOps se trata de la comunicaci\u00f3n entre departamentos, de rapidez y eficacia.<\/p><\/blockquote>\n

\nSi el equipo existe entre departamentos solo para hacer algo separado y dura mucho tiempo, crea una barrera innecesaria. Ahora, en lugar de que el programador vaya directamente al administrador para resolver un problema, primero debe dirigirse al departamento de DevOps, y este \u00faltimo se encargar\u00e1 de avanzar.<\/p>\n

Por lo tanto, para comenzar, se debe crear un equipo temporal.<\/strong>. Existir\u00e1 temporalmente durante seis meses, como m\u00e1ximo un a\u00f1o, dependiendo de la tarea planteada, solo para eliminar una restricci\u00f3n que hemos elegido. Luego morir\u00e1. Si elegimos otro punto donde nos duele mucho y entendemos que tambi\u00e9n necesitamos un equipo separado para ello, lo crearemos de nuevo. Pero en una situaci\u00f3n 'permanente', esos equipos no deber\u00edan existir; de lo contrario, solo interrumpen la comunicaci\u00f3n y asumen tareas completamente distintas, solo para hacer algo. Esas tareas pueden no estar relacionadas en absoluto con DevOps y la transformaci\u00f3n. \u00bfPor qu\u00e9 no delegar esa tarea a los departamentos existentes?<\/p>\n

Por qu\u00e9 se necesita un equipo temporal<\/h3>\n

\nConflicto con los procesos actuales<\/strong>. La transformaci\u00f3n DevOps implica no solo un cambio en las tecnolog\u00edas y herramientas que utilizamos, sino en el propio proceso de trabajo, el pensamiento y los valores. Si el equipo trabaja como ya est\u00e1 acostumbrado, no podr\u00e1 probar otros enfoques.<\/p>\n

Estas personas deben vivir bajo otras reglas: ignorar todos los KPI de la empresa, porque est\u00e1n intentando trabajar de manera diferente. Los equipos temporales no llenar\u00e1n solicitudes para obtener un servidor, sino que ir\u00e1n directamente al departamento encargado, exigiendo que se les proporcione primero lo que necesitan, porque es una tarea prioritaria y porque est\u00e1n intentando vivir de manera diferente. El equipo tiene un conflicto total con todos los procesos actuales. Para que los m\u00e9todos de trabajo existentes no les obstruyan ahora y ellos no molesten a otros, aislamos a estas personas en un equipo separado.<\/p>\n

Evitar la burocracia en los experimentos<\/strong>. En los equipos temporales no hay burocracia, no llenan informes de horas trabajadas, no rinden cuentas a los directivos. Es un mundo completamente separado, donde las personas viven y piensan de manera diferente, y se ocupan de cosas completamente distintas. No hay que interrumpirles innecesariamente.<\/p>\n

Trabajo ininterrumpido en el servicio<\/strong>. En el primer punto, elegimos algo sobre lo que experimentaremos. Experimentar y buscar maneras de trabajar mejor es bueno, pero tambi\u00e9n queremos desarrollar funcionalidades. Si todo el equipo se dedica a la transformaci\u00f3n en lugar de a las funcionalidades, comenzaremos a perder ingresos, los errores se quedar\u00e1n pendientes durante mucho tiempo, lo cual no queremos. Crear un equipo temporal permite experimentar sin detener el trabajo en el producto.<\/p>\n

No perder tiempo en tareas laborales<\/strong>. Esto vuelve a ser sobre el producto. Lleva mucho tiempo a la equipo probar otras herramientas y dem\u00e1s. Para que las personas dominen las herramientas, comiencen a implementarlas y las utilicen correctamente, se necesitar\u00e1n al menos seis meses. Si adem\u00e1s se ocupan del producto, esos seis meses se alargar\u00e1n enormemente. Si las personas trabajan en el producto, nuevamente est\u00e1n lidiando con procesos antiguos: no necesitamos eso.<\/p>\n

Por lo tanto, de diferentes departamentos estamos seleccionando personas para formar un equipo separado que se encargar\u00e1 de la transformaci\u00f3n del servicio. Como resultado, el servicio funciona, contin\u00faa desarroll\u00e1ndose, y al mismo tiempo realizamos algunos experimentos sobre \u00e9l.<\/p>\n

El equipo temporal se ocupa solo de la transformaci\u00f3n de DevOps: eliminar las limitaciones que hemos encontrado, y nada m\u00e1s.<\/p><\/blockquote>\n

\nEl equipo est\u00e1 compuesto por personas vers\u00e1tiles<\/strong>. Esto significa que no solo hemos tomado desarrolladores. No llegamos al servicio y nos llevamos media equipo: no, hemos tomado personas de diferentes departamentos<\/strong>. Hace algunos puntos descubrimos diferentes departamentos y empleados que est\u00e1n relacionados con el servicio que se est\u00e1 transformando. De ellos formamos el equipo, pues debe ser vers\u00e1til: cambiaremos tanto el proceso de prueba, como el de desarrollo y el de mantenimiento del servicio. Se necesitan diversas competencias.<\/p>\n

Normalmente seleccionamos a un desarrollador, un probador y un ingeniero \u2014 uno de cada uno, y en conjunto con ellos ideamos una soluci\u00f3n que permite vivir de manera diferente.<\/p>\n

Es deseable que estas personas tengan autoridad en la organizaci\u00f3n<\/strong>. Puede que tengamos que llevar a un conservador, aunque no es lo que queremos. Si tenemos una gran empresa, no todos creer\u00e1n en nuestra idea, y algunos pueden obstaculizarnos, por ejemplo, neg\u00e1ndose a asignar un entorno. Aqu\u00ed es donde se necesitar\u00e1 la 'autoridad': una persona respetada con mucha experiencia, que se ha ganado la buena voluntad de sus colegas. La autoridad de un empleado en el equipo facilitar\u00e1 la tarea y el trabajo del equipo temporal. La gente pensar\u00e1:<\/p>\n

\u2014 Ah, este chico genial, que todos conocemos y queremos, se ha incorporado \u2014 debe haber algo en DevOps que vale la pena ver.<\/em><\/p>\n

Establecemos un objetivo<\/h2>\n

\nHemos reunido a las personas, elegido el servicio, observado las limitaciones, determinado a qui\u00e9nes influiremos. Ahora necesitamos establecer un objetivo y debe ser directamente seg\u00fan SMART<\/strong> \u2014 todo como nos gusta.<\/p>\n

Espec\u00edfico \u2014 espec\u00edfico<\/strong>.<\/p>\n

Medible \u2014 medible<\/strong>. Este es un punto muy importante de SMART. Si no puedes medir algo, no puedes cambiarlo y comprender qu\u00e9 hiciste mejor o peor.<\/p>\n

Alcanzable \u2014 alcanzable<\/strong>. Ajusta a tu especificidad. Si eres una empresa grande con una larga historia y una gran carga de responsabilidades, que lanza una versi\u00f3n del producto una vez al a\u00f1o, no podr\u00e1s alcanzar el lanzamiento de nuevas versiones cada hora en medio a\u00f1o. No se puede hacer. Por lo tanto, establece un objetivo realista que sea alcanzable en un plazo razonable.<\/p>\n

Relevante \u2014 relevante. <\/strong>Eliminamos solo la restricci\u00f3n que realmente persigue nuestros objetivos actuales.<\/p>\n

Limitado en el tiempo \u2014 limitado en el tiempo<\/strong>. Si no hay una fecha l\u00edmite, el equipo har\u00e1 cualquier cosa: probar 15 tecnolog\u00edas en lugar de 3, escribir informes enormes, realizar investigaciones in\u00fatiles, pulir su implementaci\u00f3n hasta el brillo, cuando ya se ha alcanzado el objetivo.<\/p>\n

El objetivo lo tomamos usando Value Stream Map \u2014 nuevamente reunimos a todas las personas y dibujamos. Pero solo que ahora, sobre la base del anterior Value Stream Map, dibujamos lo que queremos obtener.<\/p>\n

\"C\u00f3mo
\n
\nDestacamos una restricci\u00f3n que vamos a eliminar de inmediato, y eso es lo que har\u00e1 el equipo. Por ejemplo, tom\u00e9 la espera desde que se completa el lanzamiento hasta su despliegue en producci\u00f3n \u2014 esta es la restricci\u00f3n m\u00e1s com\u00fan con la que la gente se acerca a los consultores.<\/p>\n

Bas\u00e1ndonos en esto, establecemos la tarea: queremos que la espera entre el lanzamiento terminado y la entrada en acci\u00f3n sea de m\u00e1ximo una hora.<\/p>\n

Ejemplos de tareas.<\/p>\n