El mundo de la transformación digital está llena de términos confusos: Design Thinking, Agilidad, OKRs, MVP, Valor, y muchas otras. En este programa hemos desmitificado varias, y ahora le ha llegado el turno a una palabra que no solo es confusa, sino que además también hay gente que activamente dice que lo hace, y no tiene idea de lo que hace. En este Solcast vamos a ver qué diablos implica ese apellido de “OPS” y realmente qué tareas y actividades abarca.
Contexto
El solcast 22 hablamos de qué es agilidad. Hablamos de cómo un puñado de nerds fueron a esquiar y se pusieron de acuerdo para escribir un manifiesto que establecía una manera ágil de construir software
La agilidad tomaba las mejores prácticas de disciplinas como Lean o Xtreme Programming, y básicamente se centraba en quitar como todo el bullshit alrededor de construir sofware que provoca entregar tarde, mal y sin cumplir expectativas.
La agilidad estuvo al centro de muchos startups, porque agilidad se lleva super bien con Lean Startup y Lean UX. Los primeros Startups, cuando eran dos vatos (blancos privilegiados que se conocieron en Stanford, obvio) que trabajaban en construir un MVP que les permitiera ganar usuarios y poder hacer una ronda de inversión, pues ellos hacían todo. Casi siempre era un dude de tecnología y un dude de negocio, o un Diseñador y un Dev.
Este equipo era la definición de ágil, porque ellos son sus propios habilitadores. El Dev hace de todo, front, back, sysadmin, base de datos, analytics, porque es un equipo pequeño, enfocado, construyendo un entregable que tiene que funcionar.
Pero cuando la agilidad comenzó a buscar integrarse a equipos más complejos, apareció un problema. En un equipo grande, por la escala de trabajo, el Dev rara vez es responsable de TODO el delivery de la solución, es más, los Devs normalmente trabajan en equipos en dónde cada uno de ellos es responsable de una solución.
Imaginemos que estoy construyendo un sistema de pagos. El sistema implica un conjunto de sistemas. que dependiendo de cómo funcione incluso puede requerir considerar varias tecnologías, varios tipos de devs, que construyen partes del sistema. Alguien construye un bloque de código que autentica la transacción, otro un bloque de código que busca errores, otro construye un servicio o una api que envía o recibe información.
Pero luego todos esos bloques de código no hacen nada si no se conectan al sistema. Se tienen que subir a un servidor, ese servidor tiene que tener un firewall, una dirección de red, un servicio de hosting.
Básicamente lo que esto implica es que, mientras que la agilidad se centra en producir la mejor calidad de código posible, pensando en que código es como un equipo de Devs genera valor, realmente ese código es inútil si no se implementa en una solución tecnológica, y la realidad es que esto es lo que pasa en la mayoría de las organizaciones.
La mision de la agiliad de poner una solución en manos de los clientes no siempre es compatible con la realidad de las organizaciones. En el ejemplo que les di, el equipo de Devs depende de un equipo de IT para poner la solución en productivo. Y generalmente IT atiende a TODA la organización, desde un teléfono hasta intranets o asignación de equipos, IT no trabaja exclusivamente para los Devs, y eso implica que puede haber retrazos en los tiempos
Los Devs quieren poner una solución en manos de la gente, pero IT los detiene, no porque sean malos, sino simplemente porque IT no trabaja en agilidad. No puedes asignar equipos por Sprints, la verdad es que no todos generan valor en ciclos e iteraciones.
Es en ese contexto que nace el concepto de Ops.
DevOps no tiene un origen claro. No es idea de una consultora o de una persona. lo más antiguo que encuentro es una mención en un evento de 2008, justamente como consecuencia de equipos tratando de implementar ágil (que es de 2001). Dev Ops significa Developer Operations, y es como un cruce Dev + Ops, siendo Ops en este contexto el equipo de IT, el que opera el código.
Eso es el contexto en dónde nace el concepto que vamos a ver hoy. Tratar de integrar agilidad con procesos no ágiles.
Definición
DevOps, como muchas otras cosas que hemos visto en el programa, ha sido víctima de convertirse en un buzzword, una palabreja que la gente avienta y que no entiende qué significa. Que aplica a Agilidad, NPS, MVP, Usabilidad, UX, Diseño, Etc, etc etc. Pero para eso estamos aquí.
Si vemos que DevOps se trata de que un equipo que es ágil pueda manejar tiempos de entrega e implementación con un equipo compuesto de personas, roles y herramientas diferentes… eso significa que DevOps es un marco de trabajo.
No es un rol, no es una palabreja, ni si quiera es un “proceso” per se. Es un mindset o un cambio cultural en integrar a dos modelos de trabajo diferentes, con tiempos y procesos diferentes, que necesitan integrarse.
Y es aquí donde llegan otras encarnaciones de Ops: Design Ops y Research Ops, que son los Ops que conozco (porque yo hago Diseño) pero es probable que existan otros. En mi investigacción encontré BizDevOps y SecDevOps
El apellido Ops básicamente es un apellido que lo que le suma es “el proceso de…” O sea, Dev Ops es el proceso de integrar Dev, Design Ops es integrar Diseño, Research Ops es el proceso de investigar. Haciendo una diferencia entre los procesos y herramientas que abarcan el proceso por si mismo, vs el proceso de integrar ese proceso a otros procesos.
Déjenme explicar.
Voy a utilizar algo que les enseñé en el Solcast 1, y que hemos usado en todos los programas desde entonces: Pensamiento de sistemas.
Dev, Design, Research, Seguridad, Producto, lo que quieran, es un sistema.
Un sistema es un conjunto de procesos cuyo resultado es mayor que la suma de sus partes. Por ejemplo. En Dev, tengo un framework y métodos y clases y variables y punteros de memoria y bla bla. Mi código, un conjunto de métodos, arroja un resultado mejor que si usara cada método de manera individual.
Diseño, igual es un sistema. Tengo mis herramientas de investigación y de ideación y de prototipado y bla bla. Y convierto data en un plan para construir una solución. Con Research convierto la información de los usuarios en hallazgos que puedo usar para saber qué construir.
La primer característica de los sistemas es que convierten una cosa en otra. (Resarch convierte palabras en hallazgos)
La segunda cosa es que los sistemas tienen sistemas adentro (Research abarca cosas como la etnografía, por ejemplo. Que podría ser un sistema por si mismo)
Pero hay una tercera propiedad, los sistemas dependen y son afectados por otros sistemas.
Eso quiere decir que tengo Dev, por ejemplo, y lo que hace Dev está afectado por lo que hace Negocio, o Diseño, o Tecnología, o Google, o Amazon, o Apple. Todo está conectado.
Ops, básicamente habla del proceso de conectar el sistema que estamos analizando, con otros sistemas de los que depende y a los que sirve. Ops es la cultura de trabajo que permite que las personas que componen estos sistemas trabajen juntos.
Ops es el proceso de romper silos, y trabajar juntos, interconectando dos sistemas, para crear un nuevo sistema integrado, más eficiente y que entrega mejores resultados.
¿Cómo funciona?
Aquí es donde se pone complicado.
DevOps no es un estándar, es más una idea. Y la gente que lo ha implementado sabe que hay algunos principios que hacen que un proceso de Ops sea Ops y no otra cosa. Porque la verdad es que en este tipo de conceptos, a veces es más útil saber que no es algo.
DevOps, al ser una extensión de agilidad, tiene iteración continua en el centro. Porque estamos tratando de habilitar un proceso iterativo (Dev, Design, Research), o sea algo que tiene que estarse haciendo todo el tiempo, en ciclos, y en incrementos. Entonces Integración contínua, entrega contínua e implementación contínua son parte de la fórmula, es decir, una característica deseable de hacer Ops es que las cosas estén pasando de manera periódica.
Donde se empieza a poner complejo, es que las características para generar esa iteración contínua varía DRÁSTICAMENTE de organización en organización. O sea, imagínate. Depende de la gente que trabaja ahí, sus hábitos, rutinas, sus prioridades, su modelo de trabajo, experiencia, herramientas… O componentes extrínsecos como el tipo de beneficios que les dan, cómo los evalúan. Hasta cosas como quién es el jefe.
Por ejemplo, en mi investigación, hay procesos de DevOps que abarcan soluciones en la nube, sistemas de manejo de incidencias, configuración centralizada, plataformas de colaboración, microservicios, contenedores, automatización de tareas. Si tienes esas cosas estás haciendo DevOps ¡No! pero ¿Te ayuda tenerlo? ¡Si! porque obvio cloud te permite tener un espacio donde puedes lanzar algo de manera asincrónica o tener plataformas de colaboración te permite que varios trabajen en una misma cosa todo el tiempo o reducir tiempos de handoff.
Hay algunas publicaciones que han hecho un esfuerzo por establecer un roadmap super claro de los pasos, métodos y procesos que pueden abarcar un gran número de pasos, en la descripción del video están referencias con las que pueden profundizar, pero el día de hoy de lo que se trata es simplificar.
Esta es mi propuesta
Devops se trata de gestionar 3 recursos:
Personas, procesos y entregables.
Se que las personas no son recursos, pero me da flojera decir talento Y recursos.
Entonces nuestro Dev Ops es gestionar gente, para que aplique procesos y genere resultados. Como todo sistema, tenemos que pensar en los inputs, los procesos que procesan esos inputs y los convierten en un output.
Entonces, conocemos la parte interna del sistema. Un proceso ágil de Dev, de Diseño o de Investigación.
Lo primero que tenemos que hacer es conectar a las personas.
Si tengo un equipo de investigación, lo primero que tengo que revisar es cómo inicia el proceso de investigación, los inputs que ese equipo recibe. Qué áreas o que roles participan y revisar si los inputs coinciden con lo que el proceso de Research necesita. Igual con Dev ¿Cómo les piden las cosas? ¿Para cuando? ¿Se los pide alguien que sabe? ¿Les imponen tiempos? O sea tenemos que entender quiénes son los inputs.
Luego tenemos que revisar los outputs ¿Qué está entregando el equipo? ¿A quién lo entrega? ¿Cómo?
Si ven un diagrama como el que está ahí arriba, pueden ver los inputs y los outputs: Dev recibe monitoreo por parte de la parte “ops” (IT o seguridad o lo que sea que implemente) y entonces ellos hacen un plan, siguen un proceso (code, build, test) y hacen un release como parte del output.
Si pensamos en Diseño ¿Cuál es el output? ¿Pantallas? ¿Maquetas? ¿Vacían las cosas directo a un Sistema de Diseño? ¿Alguien lo tiene que aprobar? ¿Lo aprueba alguien que sabe?
Lo primero es realizar un inventario de las personas, quienes son y qué hacen. NN/g lo llama “How we work together”
Si observamos a las personas, podemos observar los procesos que esas personas aplican. Un proceso es la serie de pasos que realizan para completar un objetivo o una tarea. Por ejemplo. Ya sabemos que hay 2 personas: un diseñador y un jefe ¿Cuál es el proceso que sigue el jefe para evaluar la entrega? ¿Su criterio? ¿La opinión de alguien?
El tercer punto es revisar el entregable que ese proceso genera. Una vez que el Diseñador hace la entrega al jefe ¿Qué pasa con esa entrega? ¿Se implementa directamente? ¿Se conecta con otra área? ¿A través de qué? ¿El jefe hace algún tipo de cambio en el proceso?
Se que están pensando: ¿Hacer Ops es hacernos preguntas?
Y pues… o sea. Si.
El problema con todos estos Ops es que no son procesos estándar. Tenemos que realiar un diagnóstico de la organización para identificar las prácticas de Ops que mejor nos funcionen. Por ponerles un ejemplo:
Si tu quieres implementar un proceso de Research Ops (yo estoy en eso) tienes la opción de crear un repositorio centralizado con los hallazgos de investigación para sea consultado por toda la organización pero ¿Quién lo va a mantener? ¿Todos lo pueden ver? ¿Y la información personal de los usuarios? ¿Qué pasa si alguien mal interpreta los hallazgos? Una vez me tocó ver a un equipo muy grande tomar una decisión muy estúpida por no saber interpretar un sesgo cognitivo.
Pero también tienes la opción de crear un repositorio gestionado por un equipo que consulte la información, la analice y la procese y atienda peticiones de datos. ¿Cómo va a ser el proceso de solicitar información? ¿Son solicitudes pre asignadas? ¿Cuánto tiempo toma atenderla?
Cuál es la mejor manera de hacer Ops depende fuertemente del tipo de organización en el que se está implementando.
En algunas organizaciones hacer Ops es comprar licencias y gestionar tiempo de vacaciones. En otras organizaciones Ops es dar capacitación constante, en otros lados es establecer métricas o procesos de evaluación o medición. No hay una sola definición de Ops, y es por eso que la manera en la que lo “hacemos” es haciéndonos preguntas, porque no podemos implementar un modelo que no se adapta a la realidad de nuestra organización.
Quiero cerrar esta sección cerrando que LA pregunta que tenemos que contestar es ¿Cómo aseguramos la construcción, entrega e implementación contínua? De eso se trata Ops, de eliminar las barreras que generan cargas burocráticas, silos, procesos innecesarios, retrabajo, confusión y en general bloqueos a la entrega contínua de valor. Exactamente cómo se contesta esa pregunta varía mucho de organización a organización.
¿Para qué sirve?
DevOps, obviamente nació como un proceso de poder habilitar el cambio ágil en las organizaciones. Es un mindset de trabajo colaborativo, para alinear a un grupo de personas que no tienen nada que ver, a preguntarse cómo garantizar la entrega contínua de valor a través de cosas como Tecnología, Diseño o Investigación. El beneficio es claro y evidente.
Incluso métodos como SAfE buscan integrar DevOps como una herramienta para garantizar la entrega contínua de valor
Y hacen un intento de establecer un proceso con una gestión del Value Stream o flujo de valor en el cetro, justo este diagnóstico del que estábamos hablando.
Me siento un poco sucio de reconocer que hasta SAfE hace un intento bastante acertado por tratar de estandarizar el proceso, pero la verdad es que es un proceso tan complejo y tan variable, que vale la pena tomar todas las referencias posibles.
Otra utilidad que tienen los procesos de Ops es identificar la madurez de los equipos.
El proceso con el que un equipo recaba información, la analiza, la procesa y la integra en su flujo de trabajo es un evidente indicador de si la organización tiene capacidad de entregar valor de manera constante, porque obviamente si no están aprendiendo constantemente ¿De dónde va a salir el valor? Entonces ese también es otro beneficio del proceso de Ops, que te permite identificar no solo la mejor manera de generar ese valor, sino también ubicar en dónde estamos vs dónde deberíamos estar.
Entonces, en resumen.
Ops hace referencia al mindset que nos permite garantizar la entrega contínua de valor, implementando Dev, Diseño, Research, o lo que sea, a través de varios equipos y usando procesos colaborativos e integradores, para construir una solución en conjunto.
Exactamente cómo se ve Ops en una organización varía, pero abarca 3 grandes bloques: personas, procesos y entregables, quiénes hacen qué para lograr qué. En algunos equipos Ops es una persona, en otros es un área, en otros es un conjunto de personas, un mindset, principios, herramientas, procesos, la verdad es que varía, depende y no hay una sola manera de implementarlo.
Si tu quieres implementar Ops en tu organización, lo primero es revisar los inputs y los outputs de tu proceso, diagnosticarlo y buscar eliminar barreras, burocracia y procesos que generan desperdicio y retrabajo. Recuerda la pregunta es “¿Cómo garantizamos la entrega contínua de valor?”
Ojalá este programa te sirva para entender mejor si estás implementando un proceso de Ops o si quieres implementarlo. Si te gusó el programa, recuerda que puedes apoyarme en Redes y con donaciones. Nos vemos el siguiente miércoles.
Notas del programa
What Is DevOps?
https://theagileadmin.com/what-is-devops/
What is DevOps? The ultimate guide
https://searchitoperations.techtarget.com/definition/DevOps
What is DevOps? “In Simple English”
https://medium.com/geekculture/what-is-devops-in-simple-english-6550fbb129bd
DesignOps 101
https://www.nngroup.com/articles/design-operations-101/
Design Ops: ¿Por qué debemos operativizar el diseño de experiencias?
ResearchOps 101
https://www.nngroup.com/articles/research-ops-101/
Success in ResearchOps: An indicator of UX maturity
DesignOps Handbook
https://s3.amazonaws.com/designco-web-assets/uploads/2019/05/InVision_DesignOperationsHandbook.pdf
DevOps SAfE 5.0
