Para ser sincero, cuando el producto principal de tu empresa es el software, sabes algo sobre el desarrollo de software. En esta entrada, te contaré la revelación que tuve sobre cómo el proceso de desarrollo de software se puede aplicar a cualquier otro aspecto de tu negocio (y de tu vida), independientemente de tu sector, tu puesto o tu departamento. [Alerta de spoiler: ¡hay un libro que no te puedes perder —«The Phoenix Project»— esperándote!]
Hemos elegido«The Phoenix Project»para nuestro club de lectura interno. Al principio no tenía intención de escribir una reseña, pero este libro de negocios tan atípico nos ha proporcionado tantos momentos reveladores que no podemos quedárnoslos solo para nosotros. Aunque no soy desarrolladora (aunque trabajo con algunos que son fantásticos), he aprendido cómo abordan su trabajo y he descubierto herramientas interesantes como [Kanban] para la visualización y la gestión del flujo de trabajo. ¡Herramientas que pueden funcionar y funcionarán para cualquiera!
«El Proyecto Fénix: una novela sobre TI, DevOps y cómo ayudar a tu empresa a triunfar»
Por Gene Kim, Kevin Behr y George Spafford
Imagina una novela de ficción sobre un grupo de personas muy diferentes que se unen para derrotar a un dragón y rescatar un pueblo; solo que, en esta historia, los «guerreros» son profesionales del mundo empresarial, el pueblo es una empresa manufacturera en crisis (integrada verticalmente con componentes de comercio electrónico y venta al por menor) y el dragón representa los problemas a los que se enfrenta la empresa, especialmente la miríada de retos que plantean las operaciones de TI (¡que, como descubrimos, están interrelacionadas con todos los demás departamentos!).
Cualquier empresa —o cualquier persona— que trabaje con, en, para o en el ámbito de «DevOps» debería leer esta novela, a la vez divertida y, a menudo, aterradora. Si lo reducimos a nuestro entorno empresarial actual y, más concretamente, al mercado laboral global, eso significa que este libro es para TODOS.
Casi todas las empresas, literalmente, funcionan gracias a DevOps —y están gestionadas por él—. Es una pieza fundamental del sistema nervioso de la organización. A menos que seas un niño que tiene un puesto de limonada en el jardín de casa donde solo se paga en efectivo.
¿Qué es DevOps?
En términos de tecnologías de la información, DevOps es una combinación de desarrollo (Dev) y operaciones (Ops). La cultura del software actual, que ya no está «compartimentada», fusiona a estos profesionales en un único equipo que trabaja a lo largo de todo el ciclo de vida de la aplicación, desde el desarrollo y las pruebas hasta la implementación, pasando por las operaciones, el control de calidad y la seguridad. La experiencia nos enseña que trabajar de forma aislada en cualquier ámbito, es decir, sin compartir información ni conocimientos con los demás, genera más problemas de los que resuelve.
La historia del «Proyecto Fénix» y por qué es importante DevOps
DevOps es la «revolución industrial» de nuestra época. A través de la empresa tecnológica ficticia Parts Unlimited (PU), los autores ilustran cómo suelen funcionar muchos entornos corporativos (¡de forma disfuncional!) y cómo cualquier cambio —o la ausencia del mismo— puede suponer una transformación, en la que DevOps ocupa un lugar central. El software es una parte integral de cualquier negocio, a todos los niveles. La historia ofrece una visión muy interesante desde todas las perspectivas, y no está dirigida únicamente a los expertos en tecnología.
Nuestra historia de PU (juego de palabras intencionado) comienza con una catástrofe a punto de ocurrir. Un director de TI de nivel medio (Bill), cuyos jefes han «dimitido» misteriosamente, es ascendido a vicepresidente de Operaciones de TI, un puesto que ni ansía ni quiere aceptar. Su misión (piensa en «Misión: Imposible») —asignada directamente por el director general, que al principio resulta encantador— consiste en restablecer las operaciones críticas de la empresa y evitar que esta acabe en las portadas de los periódicos… todo ello en medio de un nuevo producto, el Proyecto Fénix, que lleva años de retraso y cuyo alcance es excesivo, y con la confianza financiera pública de la empresa tambaleándose.
La misiva de Bill parece abocada al fracaso; el Proyecto Fénix es la «toda una apuesta» de PU. Hay intrigas políticas en la empresa en torno al proyecto, y la directora de marketing (y heredera natural del director general), Sarah, es la principal antagonista, con una extraña habilidad para culpar a los demás de sus meteduras de pata, al menos según el departamento de TI.
Entonces surge el primer problema… los sistemas de nóminas están FUBAR (Fouled Up Beyond All Recognition, es decir, «una auténtica catástrofe»). La orden de Bill es clara: salvar a la empresa de sí misma.
La desconexión
Nuestro equipo ficticio parte con todas las características propias de personas que ni confían en sus compañeros ni les prestan la más mínima atención. La falta de comunicación es la menor —y, en última instancia, la principal— de sus preocupaciones. En lugar de unir fuerzas para resolver los problemas, se culpan unos a otros y sacan conclusiones precipitadas e inapropiadas sobre sus compañeros. Las personalidades se interponen en el camino de la profesionalidad. La condescendencia y el «teatro» corporativo están a la orden del día.
La discordia entre los distintos departamentos es evidente. Los autores nos dan una idea de lo que piensa el personal de operaciones de TI sobre el resto de la empresa:
- Los profesionales del marketing son «licenciados en Bellas Artes o en Música, no personas con formación en estrategias tecnológicas».
- Los comerciales prometen a los clientes lo imposible y esperan que el departamento de TI se las apañe y cumpla con lo prometido; no son de fiar: «Ya conoces el dicho, ¿verdad? La forma de saber que un proveedor miente es cuando mueve los labios».
- Los vicepresidentes se pasan todo el día haciendo presentaciones en PowerPoint —entre ellos—.
- Los desarrolladores «echan leña al fuego»: siempre están colapsando los sistemas; están distraídos o de vacaciones; a menudo causan problemas y luego desaparecen, dejando que el departamento de operaciones de TI se encargue de arreglar el desastre.
- La seguridad de la información en la sala es la mejor forma de asegurarse de que algo NO se lleve a cabo.
Un miembro del personal comenta que la popular serie de televisión británica «The IT Crowd» (¡una de mis favoritas!) refleja con precisión la realidad a la que se enfrentan los de Operaciones de TI. El equipo de TI —que interpreta las siglas CIO como «Career Is Over» (se acabó la carrera profesional) en lugar de Chief Information Officer (director de sistemas de información)— cree que un ascenso no es necesariamente algo bueno. Mantener un perfil bajo ayuda a evitar la burocracia de la empresa. Me hizo pensar en los «flotantes» de algunos programas de telerrealidad.
A medida que se desarrolla la historia de PU, aumentan las sospechas y surgen teorías conspirativas sobre cómo los competidores siguen adelantándose a ellos. ¿Se está filtrando información?
Y la cosa empeora. No se redactan las especificaciones por escrito. A pesar de las necesidades de marketing de alta tecnología de la empresa, no se consulta en absoluto al departamento de TI/Operaciones, y el departamento de marketing suele externalizar las compras de TI, eludiendo por completo a dicho departamento.
Los traspasos, sobre todo entre Desarrollo y Operaciones de TI, nunca se gestionan bien. Siempre están esos proyectos «para cuando haya tiempo»: las actualizaciones y el mantenimiento de TI que se posponen constantemente porque surgen emergencias imprevistas y otras prioridades les dejan en segundo plano. Es una guerra entre bandos.
La evaluación: el sistema no funciona
Bill se toma su ascenso —y todos los problemas que hay que resolver— con calma. Su estilo de gestión, basado en estar presente en el terreno (y en plantear las preguntas difíciles), le ayuda a situar los problemas de la empresa en una perspectiva más amplia, en lo que respecta al propio negocio.
Sabe que, en realidad, el personal de operaciones no debería estar desempeñando funciones de bomberos y, aunque PU, al ser una empresa grande, cuenta con más personal disponible para hacer frente a los «simulacros de incendio» diarios, que se suceden a un ritmo frenético, que las empresas más pequeñas, los problemas siguen siendo los mismos. Todo se califica de urgente. Sin embargo, si todo es urgente, ¿se puede tratar algo con urgencia?
Existen procesos, procedimientos y sistemas para la gestión del cambio, pero rara vez se siguen. Lo habitual es que falte una planificación adecuada en la que «todos participen». No existen los entornos de prueba necesarios, supuestamente por falta de presupuesto. Se fijan fechas arbitrarias para la puesta en marcha en producción, sin tener en cuenta en absoluto lo que realmente hay que hacer antes del despliegue.
El apoyo no llega desde lo más alto de la cadena de mando de la empresa. Disponer de equipamiento actualizado y formación son lujos que no se pueden permitir. La empresa está, básicamente, actuando a ciegas. No hay conciencia de la situación. La mano izquierda no sabe lo que hace la derecha.
La actitud proactiva es algo secundario. Se necesita urgentemente transparencia.
La ejecución de los proyectos se ve impulsada por plazos límite arbitrarios —aunque siempre urgentes—, debido a compromisos externos adquiridos por la alta dirección sin comprender del todo los problemas internos. El equipo de desarrollo se ve entonces obligado a tomar atajos escandalosos e inaceptables para cumplir con los plazos. Es casi seguro que el producto resultará inutilizable, y quienes lo reclaman se llevarán una gran decepción. La experiencia del cliente será tan mala que acabará llevándolos a la competencia. El departamento de operaciones de TI tendrá que hacer todo lo posible para que funcione —y ocultar lo que está sucediendo entre bastidores—.
El equipo se esfuerza por evitar que lo perfecto sea enemigo de lo bueno. Sin embargo, las repercusiones en el negocio serán devastadoras; la empresa no está funcionando a nivel empresarial.
El software Phoenix, recién lanzado, está causando furor.
Punto único de fallo: ¿Quién es tu Brent?
Luego está el «punto único de fallo»: ese empleado indispensable que se encuentra en el centro de todos los proyectos importantes y al que tiran en un millón de direcciones diferentes. Al parecer, nada puede suceder sin su participación. No se le puede sustituir ni replicar. En «El proyecto Fénix», se llama Brent.
No es posible gestionar la producción sin una lista centralizada de proyectos: el departamento de Producción (PU) desconoce sus prioridades en materia de demanda y sus compromisos, el estado de los trabajos en curso y la disponibilidad de recursos. El departamento de Operaciones de TI se encuentra en medio de todos los flujos de trabajo, lo que genera un cuello de botella en los trabajos en curso, los entregables de los proyectos, las interrupciones del servicio y el cumplimiento normativo.
En PU, dedicar tiempo a planificar las prioridades se había considerado una pérdida de tiempo. No siguen la regla general de que, si algo pasa a tener mayor prioridad (por su urgencia), otra cosa tiene que pasar a un segundo plano. No han encontrado la manera de reducir el volumen de trabajo de reparación de averías para poder llevar a cabo proyectos que generen ingresos.
¿Cómo abordar el punto único de fallo de tu empresa? El libro comienza explicando la Teoría de las Restricciones.
¿Qué es la Teoría de las Restricciones?
La teoría de las restricciones (TOC) es un concepto de gestión según el cual solo unas pocas restricciones (ese único punto de fallo en la dotación de personal o ese cuello de botella, como en una línea de producción industrial) son lo único que te impide alcanzar tus objetivos. Si te concentras, puedes identificar cuál es la restricción y encontrar una solución para sortearla. Piensa en el dicho: «Una cadena no es más fuerte que su eslabón más débil».
Sin embargo, si se introduce una mejora en cualquier otro punto, ya sea antes o después del cuello de botella, esa limitación sigue existiendo. En nuestro escenario de fabricación, el trabajo se acumula en la parte inicial del proceso, mientras que el trabajo en curso (WIP) escasea en la parte final del cuello de botella.
La gestión de procesos en DevOps no difiere mucho de la fabricación o la gestión de una fábrica, y viceversa. Todos los departamentos pueden aprender unos de otros. Se pueden utilizar las mismas herramientas y técnicas para documentar procesos, identificar el desperdicio de tiempo o de materiales y mejorar el sistema en su conjunto.
Uno de los miembros del consejo de administración de PU fue mentor de Bill. Su forma de ser le proporcionó una orientación muy útil para la tarea que tenía entre manos, al esbozar los «Cuatro tipos de trabajo» y las «Tres formas».
Comprender las tres vías
«Las Tres Vías» describen los valores y las filosofías que marcan los procesos, los procedimientos y las prácticas de todo sistema. El objetivo de cualquier empresa, de cualquier departamento y de cada uno de los empleados es comprender —y valorar— verdaderamente el sistema para mejorar su trabajo y ofrecer mejores productos y servicios:
- Pensamiento sistémico: controlar las limitaciones y agilizar el flujo de trabajo, trabajando de izquierda a derecha (para obtener resultados más rápidos)
- Potenciar la retroalimentación: acortar el ciclo de retroalimentación, trabajando de derecha a izquierda (ofrecer una mejor calidad)
- Cultura de la experimentación y el aprendizaje: fomentar y promover la realización de pruebas para aplicar más rápidamente las lecciones aprendidas de los fracasos (mitigar el riesgo y lograr una mejora continua).
Comprender los cuatro tipos de trabajo
Dividir en compartimentos lo que hacemos y asignar indicadores a cada tipo de trabajo nos ayuda a identificar mejor los cuellos de botella, es decir, las limitaciones:
- Proyectos empresariales: trabajar en iniciativas que tengan un impacto directo en los resultados, como nuevos productos o nuevas funcionalidades.
- Proyectos internos de TI y operaciones: tareas necesarias para respaldar proyectos empresariales, como I+D (investigación y desarrollo), nuevas arquitecturas, infraestructuras o ingeniería.
- Cambios: modificaciones en el trabajo programado de los «proyectos internos» que dan apoyo a los «proyectos empresariales»
- Trabajo no planificado: errores, defectos, reelaboraciones, gestión de crisis, etc., que restan tiempo a los «proyectos empresariales» generadores de ingresos.
Es evidente que la conclusión es que los proyectos internos, cuando se llevan a cabo correctamente, tienen un efecto positivo en los proyectos empresariales y, además, reducen la cantidad de trabajo no planificado.
Sin desvelar el final del libro (¡«Project Unicorn»!), digamos simplemente que las tensiones se intensifican hasta llegar a un terreno que ningún empresario ni empleado —ya sea directivo o no— quiere explorar.
La solución está a tu alcance
- Automatiza los procesos recurrentes en la medida de lo posible, controla y documenta el trabajo (especialmente los cambios) y revisa, revisa y revisa.
- Detectar los problemas antes, dividir el trabajo en partes más manejables, consultar con todas las partes interesadas para comprobar los resultados, introducir los cambios necesarios y entregar los resultados con mayor rapidez
- Estandarizar para obtener resultados mejores, más repetibles, más precisos y más rápidos
- Comunicarse
«El Proyecto Fénix» me ha hecho ver muchas cosas desde una nueva perspectiva. Por ejemplo, todo es un sistema: una empresa, una planta de fabricación, el plan de transporte de una ciudad, incluso tu familia o tu propio cuerpo. Las soluciones para gestionar todos estos «sistemas» son sorprendentemente similares. No puedo recomendaros lo suficiente que leáis este libro.
Conclusiones
- Conocer a los clientes a un nivel más profundo puede ser lo más valioso que puede hacer una empresa.
- La burocracia es algo inherente a cualquier empresa. A medida que la empresa crece, se necesitan nuevos mecanismos de seguridad para garantizar que la comunicación sea fluida. Si tu empresa es pequeña y hay rotación de personal, también surgen esos problemas de comunicación propios de las grandes empresas.
- El proceso de gestión del cambio requiere disciplina: desarrollarlo resulta arduo, pero es mucho peor si NO existe. «No se puede alcanzar lo estratégico hasta que no se domine lo táctico».
- Si alguien te pregunta cómo has solucionado algo, no hay nada peor que responder: «No lo sé». ¡Documenta todo! La próxima vez que ocurra, tendremos la respuesta. El conocimiento es poder. El conocimiento que no se comparte no sirve para nada y, lo que es peor, genera caos.
- Si un departamento cumple con un hito importante, pero otro grupo de la empresa se ve afectado negativamente, no organices una «fiesta de la cerveza» ni envíes un correo electrónico masivo. Es de muy mal gusto. Probablemente no te gustó cuando invitaron a toda tu clase de quinto curso —excepto a ti— a la fiesta de cumpleaños del chico más popular. Y si tú eras el chico más popular, deberías avergonzarte. Recuerda: nadie es una isla. O nos hundimos o nadamos juntos. Deja la fiesta para más adelante, hasta que todos podamos celebrarlo juntos.
- Si tienes alguna noticia que compartir, hazlo. Quizá el nuevo proceso de gestión del cambio que se acaba de implantar te haya salvado de un desastre: ¡difunde la noticia! Destaca lo que está funcionando bien. Los elogios, las palmaditas en la espalda y las palabras de agradecimiento llevan poco tiempo y reportan enormes beneficios en cuanto a moral y entusiasmo. «Más vale prevenir que curar», pero el problema de la prevención es que la gente rara vez se entera de ella. ¡Comunica los éxitos!
- Si todos comprenden cómo su trabajo pone en riesgo los indicadores clave de rendimiento (KPI) de la empresa —es decir, las medidas del rendimiento general del negocio—, en lugar de desmoralizarse, es más probable que se sientan capacitados y tomen mejores decisiones empresariales y laborales.
- Siempre surgen problemas. No saques conclusiones precipitadas. No actúes a la ligera y empeores la situación. No traicones a nadie, no eches la culpa a otros ni te dediques a buscar chivos expiatorios. Asegúrate de que existen los procesos adecuados. Sigue el proceso. Participa de forma proactiva en la solución y mejora el proceso cuando sea necesario.
- Conoceros —y comprenderos— mutuamente, tanto a nivel personal como profesional. Esto fomenta el respeto, la confianza y unas mejores relaciones laborales. Cuando conozco a alguien, sobre todo a alguien con quien trabajo (¡o a quien entrevisto para contratar!), mi nueva pregunta favorita es: «¿Qué diferencia para ti un buen día de trabajo de uno malo?»
Conclusión
En nuestra última reunión del club de lectura, mis compañeros de trabajo se rieron un poco al ver que cada uno de nosotros parecía identificarse con uno o varios de los personajes, rasgos de comportamiento y/o acciones. Después, nos recompusimos, nos sacudimos el polvo y hablamos de nuestro propio progreso interno a la hora de trabajar para lograr una mayor estructura, mejores procesos y una mayor apertura al cambio, con el fin de ofrecer mejores productos y servicios a nuestros clientes.
En xTuple valoramos la innovación, así como la interconexión en toda la empresa y el intercambio de diferentes perspectivas, tanto a nivel interno con el personal como a nivel externo con los clientes y la comunidad tecnológica en general.
Acabemos con esta locura y comuniquémonos. Creemos un proceso definido y sostenible con el que todos estemos de acuerdo. Las definiciones son importantes. La comprensión es importante. Sigamos ajustando el proceso hasta que funcione. Se puede conseguir.
