The Phoenix Project

Una novela sobre TI, DevOps y cómo ayudar a tu empresa a ganar

Descubre cómo DevOps puede aumentar el valor de tu empresa.

Parts Unlimited, una empresa de fabricación y venta al por menor de automóviles, tiene una nueva iniciativa informática. Se llama “Proyecto Fénix”, y se supone que integrará a la perfección los canales de venta al por menor y de comercio electrónico de la empresa; esto dará a Parts una ventaja competitiva y aumentará su base de clientes.

Parts Unlimited, una empresa de fabricación y venta al por menor de automóviles, tiene una nueva iniciativa informática.

Phoenix es fundamental para el éxito de la empresa. También va muy retrasado y por encima del presupuesto. Así que el Director General quiere poner a alguien a cargo de arreglar el desaguisado. Tendrá 90 días para cambiar las cosas y, si no lo consigue, todo el departamento informático se quedará sin trabajo.

The Phoenix Project
SPONSOR

Aunque la historia que sigue es ficticia, los problemas y soluciones que ilustra son muy reales, como reconocerá cualquiera que trabaje en TI. Este resumen describe cómo un conflicto central y continuo entre Desarrollo y Operaciones de TI supone el fracaso no sólo del departamento de TI, sino de la empresa en su conjunto. Y revelan cómo un conjunto de prácticas denominadas DevOps pueden conducir a una eficiencia increíble, un rendimiento de vanguardia, un mayor valor y muchos menos quebraderos de cabeza.

En este resumen, descubrirás

    • qué tienen que ver las TI con una planta de fabricación;
    • Los cuatro tipos de TI.
    • los cuatro tipos de trabajo de TI;y
    • por qué el fracaso repetido es la receta del éxito.

    El caos en el departamento de informática supone un fracaso para toda la empresa.

    Es martes por la mañana y Bill llega tarde al trabajo. Va a toda velocidad por la autopista cuando recibe la llamada: tiene que ir a ver al director general, Steve, en cuanto llegue.

    Uh-oh, piensa. Me van a despedir. No sería una gran sorpresa. Como jefe de un grupo de tecnología de gama media en Parts Unlimited, Bill siempre se ha enorgullecido de hacer bien su trabajo. Se ha forjado una reputación de persona fiable, eficiente y cándida; al fin y al cabo, fue marine. Pero Parts ha tenido problemas, a lo grande.

    Bill echa un vistazo al aparcamiento casi vacío en el que está aparcando. Parece que sus competidores están innovando constantemente, y Parts se está quedando en una estela de polvo. Con todos los despidos de los dos últimos años, el departamento de Bill ha tenido que hacer cada vez más con menos recursos.

    Pero Steve no está de acuerdo.

    Pero Steve no le despide. Le va a dar a Bill un “ascenso”. Como nuevo vicepresidente de Operaciones Informáticas, Bill dependerá directamente de Steve y se asegurará de que el inminente lanzamiento del Proyecto Phoenix sea un éxito. El futuro de la empresa depende de Phoenix, dice Steve; Bill lo sabe, ¿verdad? Los clientes tienen que poder comprar en Piezas tanto por Internet como en tiendas físicas. De lo contrario, pronto no habrá clientes: la empresa dejará de existir.

    El mensaje clave aquí es: El caos en el departamento informático significa el fracaso de toda la empresa.

    Bill no quiere el ascenso: estaría aceptando el papel de conserje, encargado de limpiar un colosal desastre informático. Así que se horroriza al ver que estrecha la mano de Steve en señal de aceptación.

    ¿Por dónde se supone que tiene que empezar? Toda la infraestructura informática está en completo desorden.

    John, del departamento de Seguridad de la Información, está provocando continuamente interrupciones SEV1 -incidentes críticos que todo el mundo tiene que arreglar a toda prisa- porque se salta los procedimientos de autorización adecuados para imponer cambios en el Desarrollo que él considera importantes para los auditores. Por supuesto, Operaciones nunca puede probar estos cambios primero; no hay entorno de pruebas porque no hay presupuesto.

    Por otra parte, Patty, la directora de Soporte de Servicios Informáticos, informa a Bill de que los cambios nunca se documentan; nadie quiere dedicar tiempo a utilizar las engorrosas herramientas de gestión de cambios de la empresa. Y nadie asiste a las reuniones semanales del Consejo Asesor de Cambios (CAC).

    ¿Cómo puede alguien estar al tanto de todo lo que ocurre? Bill se da cuenta de que la respuesta es: no lo hacen. No me extraña que las cosas se hayan ido a la mierda.

    Bill mira hacia su escritorio. Su viejo portátil mostraba la pantalla azul de la muerte, así que acaba de recibir uno de repuesto. Tiene al menos diez años, es un dinosaurio voluminoso y pesado. La mitad de las letras están gastadas y la batería está pegada con cinta adhesiva.

    No puede evitar preguntarse si el universo le está diciendo algo.

    Las Operaciones de TI, como las Operaciones de Planta, se rigen por la teoría de las restricciones.

    Se supone que Phoenix debe desplegarse en diez días, pero sólo tres de las 12 tareas finales del proyecto están hechas, porque el departamento de TI ha estado gestionando problemas de emergencia.

    ,

    Las Operaciones de TI, como las Operaciones de Planta, se rigen por la teoría de las restricciones.

    Más exactamente, Brent, su ingeniero jefe, se ha estado ocupando de ellos. Pobre Brent. Bill no entiende cómo un tipo parece estar reforzando a toda la organización. Es un niño prodigio resolviendo cualquier problema que se le presenta. Y por eso se le presentan todos.

    El mensaje clave aquí es: Las Operaciones Informáticas, como las Operaciones de Planta, se rigen por la teoría de las restricciones.

    Justo cuando Bill se está sumergiendo en sus nuevas responsabilidades, le dicen que tiene que reunirse con Erik, un posible miembro del consejo que al parecer es un pez gordo de la tecnología. Pero cuando llega a la sala de reuniones, la única persona que hay es un repartidor de donuts con pantalones arrugados y camisa vaquera. Huh, piensa Bill, mientras empieza a apilar los donuts en su plato. No sabía que hicieran entregas a domicilio.

    De repente, el repartidor se da la vuelta, extiende la mano y dice: “Soy Erik”. E inmediatamente se lanza a contarle a Bill todo lo que está mal en el departamento de TI de Parts. Existe el mito de que las TI son un trabajo de puro conocimiento, dice Erik. La gente cree que es inmune a la estandarización y la documentación. Pero TI podría aprender mucho de Operaciones de Planta. Para demostrarlo, Erik le dice a Bill que coja sus cosas: van a dar una vuelta.

    Cinco minutos más tarde, llegan a una de las plantas de fabricación de Piezas. Dentro, mientras observan la planta, Erik introduce la teoría de las limitaciones: En la mayoría de las fábricas, hay unos pocos recursos -materiales, máquinas o personas- que determinan el rendimiento de todo el sistema. Éstos son los cuellos de botella, o limitaciones.

    Para maximizar la eficiencia, primero identifica la limitación. Si no sabes dónde está tu limitación, no sabrás dónde centrar las mejoras. Y cualquier mejora que no se haga en la limitación es inútil. Imagínatelo a lo largo de una línea: Si una mejora se hace después de la restricción, significa más espera. Si se hace antes del cuello de botella, lo único que se consigue es acumular existencias.

    El segundo paso es explotar la restricción. Tu restricción no debería estar nunca inactiva ni esperando a ningún otro recurso, y siempre debería estar abordando el compromiso de mayor prioridad.

    Explotar la restricción.

    Por último, subordina la restricción. El Boy Scout más lento dicta el ritmo de marcha de toda la tropa, así que muévelo al frente de la fila. En otras palabras, libera todo el trabajo en función de lo rápido que pueda gestionarlo la restricción.

    Brent, Bill se da cuenta: el ingeniero que acaba resolviendo los problemas de todos. ¡Por supuesto! Él es su restricción. Por eso los cambios sencillos de 30 minutos llevan a Brent semanas. Siempre está utilizado al 100% o más, así que cualquier trabajo que se le asigne se queda en la cola a menos que haya una emergencia.

    Todo parece muy lógico. Bill tiene que averiguar cómo adaptar el ritmo de trabajo a Brent. ¿Quién iba a pensar que el trabajo informático sería como dirigir una fábrica?

    Comprender los cuatro tipos de trabajo informático te ayudará a cumplir tus compromisos.

    Faltan pocos días para el despliegue de Phoenix, y la reunión de gestión del proyecto no va bien. A pesar de la petición de Bill de más tiempo, Sarah, de Operaciones Minoristas, presiona para que el lanzamiento se lleve a cabo según lo previsto. Cuando ella acusa al equipo de Operaciones de TI de dar largas al asunto, Bill respira hondo.

    Él ya ha visto esta película antes. El envío de un proyecto no puede retrasarse por las promesas hechas a los clientes o a Wall Street. Los desarrolladores usurpan el calendario, sin dejar tiempo para realizar pruebas de funcionamiento adecuadas. Como resultado, se toman atajos absurdos, y el producto de software final suele ser inestable o incluso inutilizable. ¿Quién tiene que pasar la noche en vela, reiniciando continuamente los servidores y pegando tiritas metafóricas para compensar un código de mala calidad? Operaciones de TI.

    Bill suspira. Ha estado dándole vueltas a algo que mencionó Erik: los cuatro tipos de trabajo. El rigor y la disciplina sólo te llevarán hasta cierto punto, dijo Erik. Hasta que Bill no supiera en qué consistía realmente el “trabajo” de Operaciones de TI, no iba a poder enfrentarse con éxito a la entrega de proyectos, las interrupciones y el cumplimiento de la normativa.

    El mensaje clave aquí es: Comprender los cuatro tipos de trabajo informático te ayudará a cumplir tus compromisos.

    Hacer que Phoenix se desplegara era trabajo, le había dicho Bill a Erik. Pero Erik no estaba impresionado. Las iniciativas oficiales de la empresa, o proyectos empresariales, eran sólo una categoría de trabajo, había dicho.

    Así que Bill se está devanando los sesos. ¿Cuáles podrían ser las otras categorías? De repente, se le ocurre algo.

    El segundo tipo de trabajo son los proyectos informáticos internos. Se trata de proyectos de infraestructura o de operaciones informáticas que crean los proyectos empresariales; también son iniciativas de mejora, como automatizar las implantaciones o crear nuevos entornos. Los proyectos internos no suelen tener un seguimiento centralizado, lo que hace que su flujo de trabajo sea difícil de controlar.

    Cambios, el tercer tipo de trabajo, suele ser el resultado de proyectos empresariales e internos; son cualquier actividad que pueda afectar a los servicios que se prestan. Dado que los cambios en Operaciones y Desarrollo de TI se registran en sistemas separados, es habitual que se produzcan errores y pérdidas de tiempo, especialmente cuando se trata de traspasos.

    Por último, pero no por ello menos importante, está el trabajo no planificado. El trabajo no planificado es como la extinción de incendios. Es ocuparse de todos los incidentes o emergencias causados por los otros tres tipos de trabajo. Y siempre se interpone en el camino de los compromisos de trabajo planificados: es lo que está comprometiendo el lanzamiento de Phoenix.

    El trabajo no planificado te impide alcanzar tus objetivos. En ese sentido, es “antitrabajo”, así que haz lo que sea necesario para librarte de él. La vida no es perfecta. Las cosas van mal, y el trabajo no planificado siempre aparecerá. La clave está en ser capaz de gestionarlo de forma eficaz, lo que empieza por saber de dónde procede.

    A menudo, es el resultado de la deuda técnica, en la que incurres al tomar atajos convenientes, pero en última instancia tontos. Al igual que la deuda financiera, la deuda técnica tiene un interés compuesto que crece con el tiempo. Si no amortizas la deuda, toda tu energía se gasta en pagar intereses, en forma de trabajo no planificado.

    Los grandes equipos destacan por la confianza, la comunicación, el compromiso, la responsabilidad y la concentración en el éxito conjunto.

    Bill intenta poner en práctica las lecciones de Erik. Pero Steve, el director general, interviene; insiste en hacer las cosas a la vieja usanza, según el calendario imposible. Como era de esperar, el lanzamiento de Phoenix fracasa estrepitosamente. Y Bill ni se inmuta.

    En lugar de eso, renuncia.

    Sin él, el proyecto cae aún más en picado. Los distintos departamentos -Operaciones de TI, Desarrollo, la empresa- intentan frenéticamente poner orden en el caos. Pero están constantemente en guerra entre ellos, echándose la culpa unos a otros como si fuera una patata caliente.

    Necesitan a Bill. Así que, con un poco de engatusamiento y una tentadora prima, vuelve.

    El mensaje clave aquí es: Los grandes equipos ponen de relieve la confianza, la comunicación, el compromiso, la responsabilidad y la concentración en el éxito conjunto.

    Cuando Bill entra en la sala de reuniones, Steve está hablando de su infancia. Dice que su familia era muy pobre. ¡Solía pasar los veranos recogiendo algodón con sus hermanos, y fue el primero en ir a la universidad.

    Uf!

    Uf, piensa Bill. Odio este rollo sensiblero. Pero tienen que romper este ciclo de perro-caza-cola, o se acabará para Parts Unlimited. Así que todos los jefes de departamento se sientan juntos para hablar del libro favorito de Steve, Las Cinco Disfunciones de un Equipo.

    La confianza, Steve, es la clave del éxito.

    Según Steve, la confianza es la base del trabajo en equipo, necesario, por supuesto, para resolver cualquier problema empresarial complejo. La ausencia de confianza, por tanto, es la primera disfunción de un equipo. Los líderes pueden verse sumidos en conflictos y en un bajo rendimiento crónico simplemente porque no hay confianza. Y se produce un efecto de goteo: cuando los líderes no confían los unos en los otros, tampoco lo hacen los equipos.

    Entonces, ¿cómo se cultiva la confianza? Pues empieza con la vulnerabilidad, por eso Steve dirige un ejercicio de historia personal. Comparte de dónde vienes y qué te impulsa para modelar la vulnerabilidad. Y luego pide a cada persona del grupo que haga lo mismo.

    Miedo al conflicto es la segunda disfunción. Elegir la armonía artificial en lugar del debate constructivo y acalorado es un camino abierto a ninguna parte. Las discusiones sinceras sobre temas polémicos pueden ser difíciles. Exigen que los líderes y los equipos superen comportamientos arraigados, pero aceptar el conflicto puede impulsar el progreso.

    La tercera disfunción es la falta de compromiso. Especialmente cuando se trata de decisiones de grupo, el falso compromiso introduce ambigüedad y apatía en el entorno de la empresa.

    La falta de compromiso es una de las principales disfunciones.

    Evitar la rendición de cuentas es la cuarta disfunción. No asumir la responsabilidad y, a la inversa, no llamar la atención a los compañeros por su comportamiento contraactivo, ambas cosas establecen un bajo nivel de exigencia.

    Evitar la responsabilidad es la cuarta disfunción.

    Por último, está la falta de atención a los resultados. Cuando antepones tus ganancias personales, tu estatus o tu ego al éxito del equipo, nunca es una situación en la que todos salgan ganando.

    La Primera Vía implica el flujo de trabajo desde Desarrollo a Operaciones de TI y al cliente.

    La reunión de liderazgo no lo resuelve todo, pero esa no es la cuestión. Bill ve que lo que el equipo tiene ahora es aún mejor: una visión compartida mientras avanzan hacia una solución. Es hora de que todos trabajen juntos. Es hora, dice Erik, de DevOps: un conjunto de prácticas que integra el desarrollo de software – “Dev”- y las operaciones de TI – “Ops”

    .

    Hoy en día, DevOps está haciendo por las TI lo que la revolución industrial hizo por la fabricación. En lugar de optimizar el proceso de convertir materias primas en productos acabados, DevOps muestra cómo actualizar el flujo de valor de TI, es decir, acelerar el tiempo de comercialización, crear sistemas más flexibles y resistentes, e integrar pruebas para sondear rápidamente posibles innovaciones.

    Los principios empresariales que subyacen a DevOps son los siguientes

    Los principios empresariales que subyacen a las pautas de trabajo de DevOps reflejan los de la industria. Erik los denomina Las Tres Vías, y la primera tiene que ver con el flujo de trabajo.

    Las Tres Vías.

    El mensaje clave aquí es: La Primera Vía tiene que ver con el flujo de trabajo desde Desarrollo a Operaciones de TI y al cliente.

    Una parte fundamental de la Primera Vía es crear un flujo rápido de trabajo a través de Desarrollo y Operaciones de TI. En lugar de perder el tiempo recortando las listas de tareas pendientes y volviendo a priorizar los compromisos en las revisiones semanales de los ejecutivos, crea un consejo kanban.

    Esencialmente, un consejo kanban es una visualización de los proyectos informáticos en curso. Al poner todos los proyectos en un solo lugar, todos los miembros de un equipo pueden ver exactamente cuánto se está haciendo y qué hay que hacer en cada momento; no hay necesidad de clasificar o hacer un seguimiento de correos electrónicos fragmentados, mensajes de texto o llamadas telefónicas.

    Para hacer un tablero kanban, es necesario que los miembros de un equipo estén al tanto de todo lo que se está haciendo y lo que hay que hacer en cada momento.

    Para hacer un consejo kanban, crea tres columnas en una pared: Listo, Haciendo y Hecho. Etiqueta fichas con todas las actividades de trabajo en curso y colócalas en sus respectivas columnas. Ahora, aquí está el truco: limita la cantidad de Trabajo en curso, o WIP, a sólo cuatro o cinco fichas a la vez. Un elemento clave de la Primera Vía es reducir el número de piezas móviles. Esto permite al equipo centrarse en un pequeño número de tareas y completarlas rápidamente antes de pasar a la siguiente. Cuando se completa una tarea, mueve la tarjeta a su nueva ubicación. Por ejemplo, cuando inicies una tarea, mueve su tarjeta de Listo a Haciendo.

    La Primera Vía de Erik se centra en el éxito de todo el sistema, en contraposición a un departamento o silo de trabajo específico. Además de reducir el trabajo en curso, los consejos kanban también ayudan a los equipos a comprometerse con el trabajo adecuado -y en la cantidad adecuada-, destacando lo que más importa para el rendimiento de la empresa en su conjunto. La conclusión es que hasta que el código no está en producción, no se genera valor, por lo que eliminar del sistema el trabajo innecesario suele ser más importante que añadir más. Y ser capaz de decir que no a los compromisos es crucial; recuerda, cuanto menos trabajo en curso, más eficaz serás.

    La Segunda Vía implica arreglar la calidad en el origen para evitar la repetición del trabajo.

    Una moto dragster Suzuki Hayabusa 2007 es una belleza, dice Erik. Puede ir a más de 230 mph. Tiene una caja de engranajes constante de seis marchas y una transmisión por cadena #532. Lo que no tiene es marcha atrás.

    Intenta demostrar algo. Al igual que la motocicleta de alta velocidad, el flujo de trabajo informático no debería tener marcha atrás. El trabajo que retrocede -como consecuencia de defectos o ambigüedad- es literalmente un desperdicio. Lo ideal es que el flujo de trabajo vaya en una sola dirección: hacia adelante.

    Para continuar con las analogías automovilísticas: los cambios de aceite preventivos y el mantenimiento de los vehículos son de lo que trata la Segunda Vía.

    El mensaje clave aquí es: La Segunda Vía implica reparar la calidad en origen para evitar la repetición del trabajo.

    Los intervalos de publicación del Proyecto Phoenix son actualmente de nueve meses. Pero si Bill quiere diseñar la calidad del producto en las primeras fases y garantizar el flujo de avance, es un plazo demasiado largo. Necesita bucles de retroalimentación mucho más rápidos y amplificados desde el cliente o desde Operaciones de TI hasta Desarrollo.

    O, como dice Erik: “Deja de pensar en cañones de la época de la Guerra Civil. Piensa en cañones antiaéreos”

    El objetivo es el flujo de una sola pieza, o una unidad de producto que fluye entre los distintos procesos. En otras palabras, trabajar en una pieza cada vez. Al reducir el tiempo de espera entre los pasos, maximizas el rendimiento, limitas la IP W y minimizas los errores.

    Toma un ejemplo de fabricación: El infame cambio de troquel en un minuto de Toyota. Este término describe cómo, mediante una serie de mejoras, la empresa consiguió el flujo de una sola pieza y redujo su tiempo de cambio de estampación de capuchones de tres días a menos de diez minutos.

    En TI, el flujo de una sola pieza puede conseguirse mediante el enfoque de entrega continua, que hace hincapié en tres cosas. La primera es el tamaño reducido de los lotes. Trabajar en lotes más pequeños te permite aplicar rápidamente bucles de retroalimentación y corregir el rumbo si es necesario.

    El segundo es detener el flujo de una sola pieza.

    La segunda es detener la cadena de producción cuando surgen problemas. Eso significa no asumir ningún trabajo nuevo cuando fallan las compilaciones, las pruebas o los despliegues.

    En tercer lugar, crea conjuntos de pruebas rápidas y automatizadas para garantizar que el código esté siempre listo para ser desplegado. Recuerda, el código no está “terminado” cuando Desarrollo termina de codificar; lo está cuando el código se ha probado y funciona tal como se diseñó.

    Cuidado con el código.

    Erik sugiere un pequeño cambio en los intervalos de lanzamiento de Phoenix. En lugar de hacer un despliegue cada nueve meses, Bill debería intentar hacer diez despliegues al día.

    Imposible, piensa Bill.

    Pero eso es exactamente lo que consiguió Flickr en 2009. Por aquel entonces, la mayoría de las organizaciones de TI realizaban despliegues trimestrales o anuales. Gracias al trabajo conjunto de Desarrollo y Operaciones con la empresa y a la aplicación de los métodos de la Segunda Vía, Flickr pudo crear un procedimiento de creación y despliegue de entornos en un solo paso, ¡y realizar diez despliegues al día! Eso es mil veces más rápido que cualquiera de sus contemporáneos.

    Hoy en día, esa cifra es aún mayor. Amazon, Netflix y Google -sólo algunas de las organizaciones que han adoptado los procesos y prácticas culturales de DevOps- son capaces de desplegar miles de cambios de producción al día sin dejar de ofrecer una estabilidad y seguridad excepcionales.

    La Tercera Vía consiste en crear una cultura de experimentación, fracaso y mejora continuos.

    Bill está mirando su nuevo y reluciente portátil. Sus aplicaciones y datos están todos ahí, su correo electrónico funciona, todas las piezas están intactas; en resumen, funciona perfectamente. Si el viejo portátil de Bill era una metáfora de todo lo que iba mal en Parts Unlimited, su nuevo portátil representa todo lo que su equipo ha logrado junto en los últimos meses.

    Las interrupciones de la SEV1 se han reducido en dos tercios, y el tiempo de recuperación de incidentes se ha reducido a la mitad. El sistema de tickets se ha purgado de trabajo innecesario. Existe un proceso estandarizado de creación de entornos -o procedimiento de construcción– para mantener sincronizados el Desarrollo y las Operaciones y eliminar las desviaciones.

    Los Desarrolladores están trabajando con el Planificador de Seguridad.

    Los desarrolladores están trabajando con Seguridad para crear proyectos preventivos en lugar de asegurar las cosas después de su despliegue. Han apaciguado a los auditores y han reducido el trabajo relacionado con la seguridad en un 75%, lo que permite centrar los esfuerzos en otras cosas.

    Todo esto significa que el flujo de proyectos se ha acelerado. Phoenix funciona sin problemas. La gente tiene claras cuáles son sus tareas; se sienten realizados y felices porque pueden hacer su trabajo. Y, a través de la Tercera Vía, están innovando más que nunca.

    El mensaje clave aquí es: La Tercera Vía consiste en crear una cultura de experimentación, fracaso y mejora continuos.

    La Tercera Vía consiste en crear una cultura de experimentación, fracaso y mejora continuos.

    Según la Tercera Vía, si no mejoras, empeoras. Esto tiene tres partes. La primera tiene que ver con la experimentación. Para vencer a los competidores, tienes que experimentar más que ellos, por lo que es importante fomentar la innovación y la asunción de riesgos.

    En Parts, hay un nuevo proyecto centrado en la innovación, llamado “Unicornio”. Utilizando datos y entornos copiados de Phoenix, los ingenieros crearon una base de datos idéntica pero completamente separada, en la que pueden desarrollar y probar continuamente cosas como promociones dirigidas a los clientes, sin interrumpir la aplicación en vivo.

    La segunda parte trata del fracaso. Para ello, Parts creó su proyecto “Mono del Caos del Ejército Simio”. ¿Su tarea? Crear fallos devastadores para matar procesos o servidores enteros. Al principio, fue un caos; la infraestructura de pruebas se bloqueaba repetidamente. Pero a medida que los departamentos de Desarrollo y Operaciones de TI colaboraron para hacer que el código y la infraestructura fueran más duraderos, los servicios de TI se hicieron inmunes a los fallos.

    El tercer aspecto consiste en poner en práctica los principios de la tecnología de la información.

    El tercer aspecto consiste en anteponer la mejora del trabajo diario al trabajo cotidiano. En Parts, todos los gerentes deben mejorar algo -lo que sea- cada dos semanas. Estos ciclos denominados kata de mejora mantienen el sistema bajo una presión constante y lo obligan a avanzar.

    En artes marciales, kata es el acto de practicar un patrón para que se convierta en algo natural. Los hábitos son los que conducen a la maestría. Los estudios demuestran que cinco minutos de práctica diaria son más eficaces que tres horas una vez a la semana, así que cuanto más a menudo se practique un hábito, mejor.

    En el mundo tecnológico actual, la informática no es sólo un departamento. Es una habilidad, como saber leer o escribir. Los gerentes de empresa necesitan poseer esa habilidad para asumir riesgos calculados, que a su vez son necesarios para vencer a los competidores. Cuando la empresa y el departamento informático se dan cuenta de que son fundamentalmente inseparables, y aplican los principios y prácticas de DevOps, toda la organización sale ganando.

    Conclusiones

    El mensaje clave de estas Conclusiones es que:

    En el entorno actual impulsado por la tecnología, el departamento de TI a menudo constituye la columna vertebral de una empresa. Así que cuando la comunicación y el flujo de trabajo entre los equipos de Desarrollo y Operaciones de TI están desalineados, repercute hasta la cima. Pero el caos interno no tiene por qué ser la norma. Entra DevOps: una estrategia de TI unificada que se centra en las “Tres Vías”. Estos principios empresariales hacen hincapié en bucles de retroalimentación cortos, comunicación racionalizada y una cultura de experimentación, repetición y práctica. Poniendo en práctica estos procesos, puedes llevar a tu organización de TI -y a toda la empresa- a cotas sin precedentes.

    Y aquí tienes un resumen de los principios de la estrategia de TI.

    Y aquí tienes más Consejos Accionables:

    Los procesos de TI y la cultura de la experimentación, la repetición y la práctica.

    Crea un consejo kanban personal.

    Además de evitar los atascos de trabajo e impulsar la productividad a escala organizativa, los consejos kanban también pueden aumentar la eficiencia a un nivel más personal, ayudándote a comprometerte con la cantidad adecuada de trabajo y a visualizar tu progreso. Así que cambia esas listas de tareas detalladas y contextuales por una pared en blanco y algunos Post-its. Clasifica todo el trabajo que tienes que hacer en tres columnas: Listo, Haciendo y Hecho. Limita tu trabajo en curso a unos cuatro o cinco elementos en un momento dado, ¡y ponte manos a la obra! A medida que avances, esas tarjetas se moverán de izquierda a derecha, y probablemente alcanzarás tus objetivos más rápido que nunca.

Add a comment

Deja un comentario

Advertisement