¿Cómo vender una deuda técnica desde una perspectiva de DevOps?

A menudo se argumenta dramática y patéticamente que es mejor no crear deuda técnica. Sí, es mejor sin él, claro. Pero las consecuencias aún pueden eliminarse.

Me refiero a deuda técnica como todos los cambios y mejoras, modificaciones de infraestructura y cambios de procesos, cambios en las estructuras del equipo destinados a eliminar brechas (realizados conscientemente o no en el marco del lanzamiento de productos) y características que interfieren mucho con el tiempo.

Y dado que estas cosas no se pueden solucionar sin un trabajo en equipo firme y seguro de los departamentos de producción y operaciones, esta historia trata directamente sobre DevOps.

Deuda técnica: ¿de quién es?

Pero primero, la raíz del problema: ¿por qué hablo siquiera de deuda técnica? Porque me ofende mucho que las empresas no le dediquen tiempo. Este hilo rojo recorre todos los informes, reuniones y comunicaciones entre desarrolladores y operaciones.

Los negocios malvados, malos y terribles no dedican tiempo a trabajar con deuda técnica. Incluso surge una pregunta justa: "¿No necesitan calidad en absoluto?" De cara al futuro diré: "Nadie necesita calidad". Pero revelaré este pensamiento un poco más adelante.

Para analizar esta situación, consideremos por qué las empresas nos hacen esto. Y para obtener una respuesta, debemos pensar de quién es la deuda técnica. ¿Quién es el responsable de esto?

Después de años de participación, me di cuenta de que éramos como Frodo, que les ofrecía un anillo a todos. Es como "¡Ayúdame a llevar esta carga!" Estamos esperando que las empresas quieran (exactamente quieran) que nos ocupemos de la deuda técnica. Pero la causa fundamental de nuestro mutuo malentendido con las empresas es que éstas nunca querrán hacerlo.

Para nosotros, es un desafío de ingeniería, una forma de mejorar la excelencia del producto o incluso un mecanismo para aumentar el orgullo por nuestro producto. Pero para los negocios, siempre es una molestia, un mal necesario (o una necesidad) al que hay que dedicarle tiempo.

Imagínese que se sube a un taxi y el conductor le pregunta: "¿Puedo parar en el lavado de autos?".

La empresa en esta situación es un cliente y los desarrolladores son el taxista.

• El negocio está indignado: "¡¿Cómo es eso?! ¡Yo pago el tiempo de viaje y tú irás al lavado de autos!"

• A lo que el taxista responde razonablemente: "¿No quieres viajar en un coche limpio y que huela bien?".

• La empresa responde: "¡Hombre, por supuesto que sí! Pero lo espero por defecto y no estoy dispuesto a pasar por el lavadero de autos ahora porque sí".

Así tratan las empresas la deuda técnica. Es como una sugerencia de pasar por un lavado de autos. Elijo la categoría adecuada cuando pido un taxi para tener un salón limpio o lujoso. En la etapa de pedido, estoy dispuesto a invertir en él, pero pasar por el lavado de autos no.

Porque, como dije antes, nadie quiere calidad. Pero se espera por defecto.

Es un deber. Las empresas no pueden resignarse a no ir al túnel de lavado y no pueden ir allí a costa de su propio tiempo. ¿Asi que que hacemos? Una empresa es una locomotora. Necesita características, ventas y clientes. Es imposible vender la deuda técnica a una empresa mediante nuestro "quiero" y "deseo". Pero es posible motivar a las empresas de otra manera.

A lo largo de mi viaje, he formado 3 categorías de motivación empresarial para "comprar" deuda técnica:

• Indiferencia "gorda". Cuando hay un inversor rico, el director ejecutivo puede permitirse el lujo de contar con un equipo de desarrollo formado por geeks raros. Es como, "Bueno, ¡déjalos hacerlo! Lo principal es terminar el producto y el espíritu de equipo es increíble, todo está bien y seríamos la mejor oficina del mundo".

  
  

  En mi opinión, es un estilo libre genial que a menudo conduce al desastre porque la deuda técnica requiere pragmatismo. Cuando no lo hacemos de manera pragmática, creamos un Leviatán de arquitectura pseudo-cool.

• Miedo. Este es uno de los modelos de deuda técnica más eficaces, extendidos y eficientes. ¿De qué tipo de "deseo" podemos hablar aquí cuando da miedo? Se trata de cuando sucede algo como que un cliente se fue debido a una falla o un hack. Y todo es por mala calidad, frenos o algo más. Pero vender sin rodeos por miedo también es malo. La especulación con miedo va en contra de la confianza. Debe vender con cuidado y la mayor honestidad posible.

• Confianza. Es cuando una empresa te da todo el tiempo que necesitas para trabajar en la deuda técnica. La confianza funciona y se preserva sólo cuando uno es cuidadosamente pequeño respecto de la participación total y lo más pragmático posible al tomarse este tiempo. De lo contrario, se destruye la confianza. Además, no se acumula. Un proceso constante va en oleadas: la confianza aumenta y luego se desvanece.

A continuación, hablaré de mi experiencia y de lo que funciona para mí y para mi fantástico equipo.

¿Qué tan profunda es la madriguera del conejo con la deuda técnica?

Cuando me uní a la nueva empresa hace 3 años, necesitaba entender de cuánto era esta deuda técnica. Sabía que existía por las estadísticas de solicitudes, incluidas las de empresas y socios. Necesitaba descubrir a qué me estaba enfrentando en general.

Este es un primer paso normal y obligatorio para trabajar con deuda técnica. No debes apresurarte a hacer lo primero que encuentres. Debes analizar la situación en su conjunto.

Según lo que vi entonces, supuse que uno de los problemas fundamentales es un gran acoplamiento de código. Ahora involucro menos a todos en este proceso, pero en aquel entonces, reuní a todo el equipo de producción para arreglar qué capas queríamos enfatizar en nuestro conjunto de aplicaciones.

Nuestra aplicación tenía al menos 80 componentes diferentes (distribuciones, no instalaciones). Después de descubrir la situación, había que solucionarla.

Fase 1. Equipos Virtuales

Siendo tan inteligente, se me ocurrió la idea de fingir que todos tenían tiempo y formar un equipo virtual en torno a cada componente. Parecía: "Chicos, ¿quién asumirá qué componente? Formen sus sugerencias sobre cómo mejorarlo". Pero para mantenernos enfocados, todos juntos formulamos los criterios para optimizar la primera fase:

• Bajo acoplamiento
• Escalabilidad rentable
• Fácil conexión de nuevos desarrolladores (principios simples y claros: qué se puede hacer exactamente en este componente y qué no, además del aislamiento del código que no todos pueden "tocar")
• Posibilidad de utilizar una API externa cuando sea necesario
• Accesibilidad de la pila tecnológica propuesta.
• Optimizaciones QuickWin en soluciones actuales
• Facilidad de monitoreo y resolución de problemas
• Principios de pureza de auditoría + licencia
• Principios de versionado y obsolescencia.

Por supuesto, esto no era un enfoque sino un conjunto de criterios para casi todos los aspectos del desarrollo de software. La lista completa se puede reemplazar con una frase: "Arreglar todo".

Esta fase terminó en un fiasco, en el sentido de que simplemente no pasó nada. Avanzamos muy poco en la implementación de algunas cosas porque estaba tratando de planificarlas a través de un trabajo pendiente compartido. Las tareas eran incomprensibles. Se pusieron a trabajar manualmente. Rápidamente me di cuenta de que era difícil tanto para mí como para el equipo, además los conflictos y discusiones crecían constantemente.

Entonces pasé a la fase 2.

Fase 2. La deuda técnica es mía

En la fase 1, acordé con el director general de nuestra empresa que introduciríamos una cuota de atrasos. Gastaríamos el 70% en cuestiones comerciales, el 15% en eliminación de defectos y el 15% en deuda técnica.

En segundo lugar, en la fase anterior me di cuenta de que si todos son responsables de un tema, nadie es responsable de ese tema. Esta no es una declaración turquesa en absoluto. A mí no me gusta. Pero lo contrario requiere un altísimo nivel de madurez y trabajo en equipo. Por eso decidí formar un sistema de líderes técnicos.

Pero no sólo designé a una persona para que fuera el líder técnico de un componente. Expuse mis expectativas tanto como fuera posible, definí su camino de desarrollo y los hice responsables de la situación de producción. Los expertos de OPS no están despiertos si su componente falla en la producción. Eres tú quien está intentando resolver la situación.

Y así partimos. Hay líderes técnicos (los que están a cargo) y una cuota del 15% de deuda técnica (hay tiempo). Pero, ¿cómo fue la realidad al final?

Lo primero que encontramos fue que tenemos FinTech, cumplimiento y segregación de funciones, es decir, yo y el desarrollo no tenemos acceso a la producción y no podemos tenerla por definición. Y, sin embargo, les digo: "¡Chicos, ustedes son responsables de la situación en producción!"

¡Dale a la gente los troncos!

Cuando le des responsabilidad a las personas, por favor dales una herramienta en sus manos. Y eso fue lo primero que hicimos con los expertos de OPS, proporcionando registros a los técnicos para que pudieran ver los registros de sus componentes.

Y tuvimos un esfuerzo realmente colaborativo: nuestro primer paso hacia DevOps, donde las operaciones y el desarrollo trabajan juntos. La explotación configuró la transferencia de registros (Kibana, etc.), mientras que el desarrollo tuvo que garantizar que los registros no contuvieran información confidencial (datos personales, etc.).

El 5% se considera afortunado...

La realidad es que a pesar de la cuota del 15%, en cada sprint hay algunas crisis empresariales e inyecciones urgentes porque "¡El socio lo necesita ahora o se irá!". Por supuesto, esta deuda técnica primero se elimina del sprint; como resultado, tuvimos sprints con 0%.

También hubo sprints con un 15%, pero solo teníamos entre un 5% y un 8% de deuda técnica en promedio. Este es un gran problema porque un programador no puede saber cuánto tiempo tendrá para la implementación.

Por mi parte, intenté ayudar en esta situación volando incansablemente una cometa sobre todos los equipos. Aprendimos a recopilar métricas detalladas para cada sprint y miré el sprint al final.

El Sprint Hacking se produce cuando se viola sistemáticamente la cuota de deuda técnica. Si no se alcanza la cuota en un sprint, no significa que todo esté mal. De hecho, hay diferentes situaciones y hay que ser flexible.

Pero cuando esto se repitió sistemáticamente, reuní a los expertos en producción, discutí y les expliqué lo importante e inaceptable que era porque la cuota estaba acordada. Era mi trabajo diario mover el proceso en ese modelo.

Y se movió, pero ahora creo que este enfoque tiene sus propias deficiencias importantes.

Limitaciones del enfoque

Los propietarios de productos están acostumbrados a que el trabajo pendiente sea todo suyo y que todas las tareas las coordinen ellos: "¡La cuota es buena, pero sólo nosotros decidimos qué hará el equipo en esta cuota de deuda técnica!"

Y cuando a los desarrolladores se les ocurrieron tareas (recuerde la conectividad sólida) como refactorizar, eliminar textos estándar, etc., obtuvieron una reacción lógica: "¡¿Qué?! ¿Qué texto estándar? ¿De qué estamos hablando?".

Como resultado, las tareas fueron sustituidas por aquellas que podrían denominarse deuda técnica pero que eran condicionalmente beneficiosas para el proveedor. Por eso tuve que tomar una postura dura y decir: "¡La deuda técnica es mía! Y afirmo que se incluirá en la deuda técnica de cada equipo de producto en la cuota de deuda técnica de cada sprint".

Así vivíamos. Aunque vivíamos y trabajábamos con normalidad, la desconfianza se hizo más fuerte. Cuando hacemos algo y no le decimos a nadie qué es, y no dedicamos el tiempo a tareas comerciales, no todos tienen claro qué resultado obtenemos.

Dado que las estadísticas sobre la utilización de la cuota de deuda técnica se estaban disparando, nos enfrentamos al hecho de que no podíamos realizar grandes proyectos. Además, los grandes proyectos suelen requerir varios equipos. Esto también fue imposible porque cada equipo de producto se centra en su producto y vive en sus realidades. Es imposible abordarlos sobre un tema complejo.

Además, nadie incluyó operaciones en los sprints. No tienen sprints ni retrasos como en la producción. Están inundados de tareas relacionadas con la producción, pero eso no estaba incluido en los planes generales. Y cuando el desarrollo llegó con algo hecho dentro de esas pequeñas partes de deuda técnica para implementarlo en producción, podría permanecer en las solicitudes de OPS durante bastante tiempo.

Porque realmente no tenían tiempo, se les cargaban tareas adicionales y se les impedía trabajar.

Pero a pesar de los aspectos negativos de este enfoque, logramos mucho.

¿Qué hemos logrado con este enfoque?

En primer lugar, hemos desarrollado la masa muscular de los autotests. Al rediseñar sustancialmente todo el proceso de CI, lo convertimos en un proceso civilizado del que no nos avergonzamos.

En segundo lugar, implementamos con éxito la lucha contra el código espagueti en muchos componentes.

Hemos hecho modularización y reducido los modelos estándar. Estas tareas no se pueden vender a la empresa ni siquiera por miedo. Si las brechas tecnológicas en su producto contienen estos problemas y necesita solucionarlos (si están ahí, es necesario hacerlo primero), ni siquiera necesita intentar venderlos. Esto sólo se puede hacer mediante el modelo "La deuda técnica es mía", sólo mediante cuotas.

He visto muchos intentos y traté de hacerlo de otra manera en la primera fase. No funcionó.

De hecho, trabajar en este modo no puede durar mucho tiempo. Es una carta blanca limitada que la gerencia le brinda, confiando en usted como CTO y líder del equipo.

Fase 3. Proyecto Legítimo

Luego iniciamos la fase 3: un proyecto "legítimo" para trabajar en deuda técnica. La suposición era que nos estábamos alejando de una cuota cerrada, planificando a través de una cartera de productos común (es decir, los propietarios de productos aceptan que estos proyectos deben realizarse) y acercándonos a una venta limpia. Para que esto suceda, hicimos 2 cosas:

• Reduje al máximo el alcance del trabajo que comenzamos a realizar en el marco de este proyecto.

• Formé expectativas concretas sobre por qué lucharemos en la producción. Fue un rechazo total al idealismo porque nuestras tareas deberían ser lo más pragmáticas posible, comprensibles y útiles para el servicio desde el punto de vista empresarial.

Un punto importante es que tenemos una cierta ilusión de que estamos intentando calcular el valor empresarial de la deuda técnica, aunque esto rara vez es posible. Y si todavía se puede calcular, ¡entonces tenemos una deuda técnica de pesadilla!

El valor positivo funciona mejor para las empresas que el valor negativo. Si dice: "Este cliente se irá. Trae mucho dinero", hasta que no se vaya, no funcionará. No es un valor comercial. Además, la cultura de trabajar con riesgos aún no es muy alta, por lo que la moda es: "No hay pérdida hasta que se vayan".

Tampoco es necesario mostrar valor comercial. Donde puedes mostrarlo, pero puedes mostrar el valor tecnológico, solo hay que calcularlo.

Guía sobre cómo vender deuda técnica

Aquí está el flujo de trabajo completo de esta fase de venta de deuda técnica.

Elija un área de enfoque (solo una)

Dado que esto es vender por miedo, elige un área que realmente afecte tu negocio. Las áreas pueden ser diferentes: disponibilidad, velocidad de retrabajo, seguridad de las pruebas y experimentos A/B y costo del retrabajo. Hay una gran cantidad de áreas y temas.

En mi caso, elegí la accesibilidad porque estaba en el radar del negocio y tenía cierto impacto en nuestro servicio. Es vital no exagerar y elegir un solo tema.

Hacer análisis integral

Analicé las estadísticas de disponibilidad e incidentes del año y analicé detalladamente todas las autopsias de todas las situaciones que ocurrieron durante el año. Después de eso, adquirí un entendimiento de alto nivel sobre en qué debemos trabajar tanto como sea técnicamente posible, pero nuevamente, de manera sustancial.

La primera regla de disponibilidad es no intentar construir un sistema que siempre esté disponible, sino que esté listo cuando ocurra un incidente. Eso es lo que tenemos que garantizar.

La segunda cuestión y regla básica de disponibilidad es el acuerdo de degradación: algo sucederá algún día y usted debe estar preparado para preservar su servicio, tal vez a costa de renunciar a alguna funcionalidad que proporciona. Este acuerdo debe mantenerse, incluso a nivel de programa.

La tercera cuestión se refiere al seguimiento y la observabilidad. Se trata de la rápida localización de las fuentes de incidentes y el tiempo de detección de respuesta. Si tiene muchas pruebas deficientes, tendrá que dejar de confiar en su seguimiento. Si sus pruebas de producción tienen instrucciones para reacciones de la mesa de servicio como, "Si no se apaga en 5 minutos, llámeme", no está monitoreando la situación de producción. La prueba debe ser lo más inequívoca posible: "Se nota, significa que hay problemas en alguna parte, ¡vamos!".

Hacer análisis componente por componente

Para ello, hemos formado qué haremos exactamente para cada dirección y componente. Nos referimos a dónde introduciremos la malla de servicios, cómo cambiaremos el seguimiento y en función de qué. Aquí hemos enumerado alrededor del 15%, pero de hecho, hay muchas mejoras en el programa.

Lo hemos expuesto todo, pero aún no es comercializable. Para salir y mostrarlo abiertamente ahora, hemos hecho lo siguiente para cada proyecto de esta fase.

Formular indicadores sustantivos y cuantitativos

Tenemos mucho miedo de los indicadores cuantitativos: ¿cómo podemos medir la calidad del trabajo de los desarrolladores en indicadores cuantitativos? Tenemos muchos argumentos en contra de los indicadores cuantitativos, pero no deberíamos abordarlos frontalmente.

El valor no debe tomarse únicamente como valor comercial. Pueden expresarse, por ejemplo, como "no más de X falsos positivos".

Puede enumerar un conjunto específico de componentes para los cuales es fundamental proporcionar versiones canary o la capacidad de garantizar una reversión de parches garantizada. Por supuesto, la disponibilidad global debería ser un indicador cuantitativo. Es un deber.

Defender los proyectos

Con este conjunto de proyectos pragmáticos, con métricas lo más claras posible y los resultados que necesitamos lograr, dije: "Chicos, necesito una cuota de deuda técnica. Necesito que incluyan estos proyectos en su grupo para acelerarlos y que entrar en la planificación general sobre una base totalmente legal junto con los objetivos comerciales."

Se escuchó, lo hicimos y funcionó. Creo que es como el vídeo sobre cómo dibujar un búho: "Dibuja un óvalo y dos guiones". Al final, magia, ¡obtienes un búho! Pero toda la magia es que tienes que concretar todo este proyecto y llevarlo hasta el final.

No sólo hacer algunas cosas en esta dirección sino llevarlas al resultado. Es decir, alcanzar los indicadores cuantitativos planteados y mostrarlos. Este abismo no se puede saltar el 95% de las veces. Hay que saltarlo por completo.

Ventajas del enfoque

Entonces, empezamos a saltar (sobre el abismo). Lo estamos haciendo con éxito. Ahora estamos en la segunda ronda de este proyecto. Es decir, arrastramos el primer grupo de proyectos y acordamos el segundo grupo de proyectos. ¿Que ha cambiado?

Aumento de la confianza

La confianza aumenta poderosamente a través de la apertura si mostramos métricas reales y cuantificables. Pero la verdad es que la venta de deuda técnica se produce a través del miedo. Este paso no se puede evitar. Pero tampoco hay que tener miedo ni avergonzarse de ello. Lo principal es no especular sobre el miedo sino analizarlo realmente, como he demostrado en diferentes fases (análisis integral, análisis componente por componente).

Haciendo grandes proyectos

Dado que ahora son proyectos legitimados, podemos sincronizarnos entre equipos y realizar proyectos realmente grandes. Algunos proyectos se realizaron secuencialmente de sprint a sprint. La composición del equipo de tecnología nos realiza un seguimiento regular (una vez por semana) dentro de ese proyecto y entendemos quién está dónde (en qué fase).

Esta información es lo más abierta y transparente posible. El progreso de los proyectos y los estados actuales se publican y están disponibles para los propietarios de productos (y cualquier otra persona que quiera verlo).

OPS'ers en el Proyecto

Lo más importante es que nos dimos cuenta de que teníamos muchas cosas que rediseñar en la infraestructura y el proceso de implementación. Los miembros de OPS fueron incluidos explícitamente en este proyecto.

En mi opinión, esto es más DevOps que Kubernetes y Docker cuando los OPS discuten con los desarrolladores cómo cambiar la arquitectura de un componente, y los desarrolladores discuten con los OPS cuál es la mejor manera de cambiar la infraestructura.

¿Por qué no lo hice de inmediato?

Aquí volvemos a lo que hablaba al final de la fase 2: antes no habría funcionado. Porque lo que hicimos en la Fase 2 (el código espagueti que rediseñamos, el desarrollo muscular de las pruebas y el rediseño de los procesos de CI) habría sido imposible de vender a la empresa en términos de métricas mensurables.

Esa situación no se atribuyó a ningún temor en particular, y nuestro argumento estándar, "Estamos tardando mucho en codificar porque el código espagueti", nadie en el negocio escucha. Por lo tanto, no habríamos podido prolongar ese enfoque.

Desde mi punto de vista, si tienes una plataforma tecnológica que requiere una revisión infraestructural tan profunda, no puedes evitar la fase 2.

Tienes que intentarlo, pero tienes que estar preparado no sólo para revolotear como una cometa todo el tiempo, sino también para cerrar esta tienda lo suficientemente rápido como para no perder la confianza en tu negocio.