Despriorizar la calidad sacrifica tanto la estabilidad como la velocidad del software, lo que genera problemas costosos. Invertir en calidad aumenta la velocidad y los resultados.

Invertir en calidad de software suele ser más fácil de decir que de hacer. Aunque muchos gerentes de ingeniería expresan su compromiso con el software de alta calidad, a menudo son cautelosos a la hora de asignar recursos sustanciales a iniciativas centradas en la calidad. Presionados por plazos ajustados y prioridades contrapuestas, los líderes con frecuencia enfrentan decisiones difíciles sobre cómo asignan el tiempo y el esfuerzo de su equipo. Como resultado, las inversiones en calidad suelen ser las primeras en recortarse.

La tensión entre invertir en calidad y priorizar la velocidad es fundamental en cualquier organización de ingeniería y especialmente en proyectos de ciencia de datos y aprendizaje automático más avanzados donde la entrega de resultados está a la vanguardia. A diferencia del desarrollo de software tradicional, los sistemas de aprendizaje automático a menudo requieren actualizaciones continuas para mantener el rendimiento del modelo, adaptarse a las distribuciones de datos cambiantes e integrar nuevas funciones. Los problemas de producción en los procesos de aprendizaje automático (como problemas de calidad de los datos, desvíos de modelos o fallas en la implementación) pueden interrumpir estos flujos de trabajo y tener efectos en cascada en los resultados comerciales. Equilibrar la velocidad de la experimentación y la implementación con una rigurosa garantía de calidad es crucial para que los equipos de aprendizaje automático puedan ofrecer modelos confiables y de alto rendimiento. Al aplicar un enfoque científico estructurado para cuantificar el costo de los problemas de producción, como se describe en esta publicación de blog, los equipos de ML pueden tomar decisiones informadas sobre dónde invertir en mejoras de calidad y optimizar su velocidad de desarrollo.

La calidad a menudo se enfrenta a un rival formidable: la velocidad. A medida que se intensifica la presión para cumplir los objetivos empresariales y ofrecer funciones críticas, resulta difícil justificar cualquier enfoque que no tenga en cuenta directamente
salida del variador. Muchos equipos reducen al mínimo las actividades no relacionadas con la codificación, centrándose en las pruebas unitarias mientras restan prioridad a las pruebas de integración, retrasan las mejoras técnicas y dependen de herramientas de observabilidad para detectar problemas de producción, con la esperanza de abordarlos solo si surgen.

Equilibrar velocidad y calidad rara vez es una elección sencilla y esta publicación no pretende simplificarla. Sin embargo, lo que los líderes suelen pasar por alto es que la velocidad y la calidad están profundamente conectadas. Al restar prioridad a las iniciativas que mejoran la calidad del software, los equipos pueden terminar con lanzamientos lentos y plagados de errores. Cualquier beneficio al implementar más funciones rápidamente
puede erosionarse rápidamente, ya que los problemas de mantenimiento y una afluencia constante de problemas finalmente socavan la velocidad del equipo.

Sólo comprendiendo el impacto total de la calidad en la velocidad y el retorno de la inversión esperado de las iniciativas de calidad podrán los líderes tomar decisiones informadas sobre cómo equilibrar el trabajo pendiente de su equipo.

En esta publicación, intentaremos proporcionar un modelo para medir el ROI de la inversión en dos aspectos para mejorar la calidad del lanzamiento: reducir la cantidad de problemas de producción y reducir el tiempo que dedican los equipos a estos problemas cuando ocurren.

Escapar de los defectos, los errores que llegan a producción

Prevenir regresiones es probablemente la medida más directa y de primer nivel para reducir la sobrecarga de los problemas de producción en el equipo. Los problemas que nunca ocurrieron no sobrecargarán al equipo, no causarán interrupciones ni amenazarán la continuidad del negocio.

Por muy atractivos que puedan ser los beneficios, hay un punto de inflexión después del cual defender el código de los problemas puede ralentizar los lanzamientos hasta detenerlos. En teoría, el equipo podría triplicar la cantidad de revisiones de código requeridas, triplicar la inversión en pruebas y construir un aparato de prueba de carga riguroso. Se encontrará evitando más problemas, pero también será extremadamente lento para publicar contenido nuevo.

Por lo tanto, para justificar la inversión en cualquier tipo de esfuerzo para evitar regresiones, necesitamos comprender mejor el ROI. Podemos intentar aproximar el ahorro de costos de cada disminución del 1% en las regresiones sobre el desempeño general del equipo para comenzar a establecer un marco que podamos utilizar para equilibrar la inversión en calidad.

El beneficio directo de prevenir problemas es, en primer lugar, el tiempo que el equipo dedica a solucionarlos. Los estudios muestran que los equipos actualmente dedican entre el 20% y el 40% de su tiempo a trabajar en cuestiones de producción, lo que supone una pérdida sustancial de productividad.

¿Cuál sería el beneficio de invertir en prevenir problemas? Usando matemáticas simples podemos comenzar a estimar la mejora en la productividad para cada problema que se puede prevenir en etapas anteriores del proceso de desarrollo:

Dónde:

• Tsaved​ es el tiempo ahorrado mediante la prevención de problemas.
• tejidos es el tiempo actual dedicado a cuestiones de producción.
• PAG es el porcentaje de problemas de producción que podrían evitarse.

Este marco ayuda a evaluar el costo versus el valor de las inversiones en ingeniería. Por ejemplo, un gerente asigna dos desarrolladores por semana para analizar problemas de rendimiento utilizando datos de observabilidad. Sus esfuerzos reducen los problemas de producción en un 10%.

En un equipo de 100 desarrolladores donde se dedica el 40% del tiempo a la resolución de problemas, esto se traduce en una ganancia de capacidad del 4%, más un 1,6% adicional debido a la reducción del cambio de contexto. Con un 5,6% de capacidad recuperada, la inversión en dos desarrolladores demuestra que vale la pena y demuestra cómo este enfoque puede guiar la toma de decisiones prácticas.

Es sencillo ver el impacto directo de prevenir cada uno de los 1% de las regresiones de producción en la velocidad del equipo. Esto representa un trabajo sobre regresiones de producción que el equipo no necesitaría realizar. La siguiente tabla puede brindar algo de contexto ingresando algunos valores:

Teniendo en cuenta estos datos, a modo de ejemplo, el directo Ganar recursos de equipo para cada uno. 1% mejora para un equipo que gasta 25% de su tiempo ocupándose de cuestiones de producción sería 0,25%. Si el equipo pudiera evitar el 20% de los problemas de producción, significaría 5% De vuelta al equipo de ingeniería. Si bien esto puede no parecer una cantidad suficientemente grande, existen otros costos relacionados con problemas que también podemos intentar optimizar para lograr un impacto aún mayor.

Tiempo medio de resolución (MTTR): reducción del tiempo perdido para resolver problemas

En el ejemplo anterior, analizamos el aumento de productividad logrado al prevenir problemas. Pero ¿qué pasa con aquellos problemas que no se pueden evitar? Si bien algunos errores son inevitables, aún podemos minimizar su impacto en la productividad del equipo reduciendo el tiempo que lleva resolverlos, conocido como tiempo medio de resolución (MTTR).

Normalmente, resolver un error implica varias etapas:

1. Triaje/Evaluación: El equipo reúne a expertos en la materia relevante para determinar la gravedad y urgencia del problema.
2. Investigación/Análisis de Causa Raíz (RCA): Los desarrolladores profundizan en el problema para identificar la causa subyacente, lo que suele ser la fase que lleva más tiempo.
3. Reparación/Resolución: El equipo implementa la solución.

Entre estas etapas, la fase de investigación suele representar la mayor oportunidad para ahorrar tiempo. Al adoptar herramientas más eficientes para el seguimiento, la depuración y el análisis de defectos, los equipos pueden optimizar sus esfuerzos de RCA, reducir significativamente el MTTR y, a su vez, aumentar la productividad.
Durante la clasificación, el equipo puede involucrar a expertos en la materia para evaluar si un problema pertenece al trabajo pendiente y determinar su urgencia. A continuación se realiza la investigación y el análisis de la causa raíz (RCA), donde los desarrolladores profundizan en el problema. Finalmente, la fase de reparación implica escribir código para solucionar el problema.
Curiosamente, las dos primeras fases, especialmente la investigación y el RCA, suelen consumir entre el 30% y el 50% del tiempo total de resolución. Esta etapa tiene el mayor potencial de optimización, ya que la clave es mejorar la forma en que se analiza la información existente.

Para medir el efecto de mejorar el tiempo de investigación sobre la velocidad del equipo, podemos tomar el porcentaje de tiempo que el equipo dedica a un problema y reducir el costo proporcional de la etapa de investigación. Por lo general, esto se puede lograr mediante la adopción de mejores herramientas para el seguimiento, la depuración y el análisis de defectos. Aplicamos una lógica similar a la evaluación de la prevención de problemas para tener una idea de cuánta productividad podría ganar el equipo con cada porcentaje de reducción en el tiempo de investigación.

1. Tsaved : Porcentaje de tiempo ahorrado del equipo
2. R: Reducción del tiempo de investigación
3. T_investigation : Tiempo por número dedicado a esfuerzos de investigación
4. T_issues : Porcentaje de tiempo dedicado a cuestiones de producción

Podemos probar cuál sería la ganancia de rendimiento en relación con el T_investigationy T_issuesvariables. Calcularemos la ganancia marginal por cada porcentaje de reducción del tiempo de investigación. R .

A medida que estos números comiencen a acumularse, el equipo podrá lograr una ganancia significativa. Si somos capaces de mejorar el tiempo de investigación en un 40%, por ejemplo, en un equipo que dedica el 25% de su tiempo a resolver problemas de producción, estaríamos recuperando otro 4% de la productividad de ese equipo.

Combinando los dos beneficios

Teniendo en cuenta estas dos áreas de optimización, podemos crear una fórmula unificada para medir el efecto combinado de optimizar tanto la prevención de problemas como el tiempo que el equipo dedica a problemas que no puede prevenir.

Volviendo a nuestra organización de ejemplo que dedica el 25% del tiempo a los problemas de producción y el 40% del tiempo de resolución por problema a la investigación, una reducción del 40% en el tiempo de investigación y la prevención del 20% de los problemas daría como resultado un 8,1%. mejora de la productividad del equipo. Sin embargo, estamos lejos de haber terminado.

Contabilización del costo oculto del cambio de contexto

Cada uno de los ingenuos cálculos anteriores no tiene en cuenta una penalización importante incurrida por la interrupción del trabajo debido a problemas de producción no planificados: el cambio de contexto (CS). Existen numerosos estudios que muestran repetidamente que el cambio de contexto es costoso. ¿Qué tan caro? Una penalización de entre un 20% y un 70% de trabajo extra debido a interrupciones y cambios entre varias tareas. Al reducir el tiempo de trabajo interrumpido, también podemos reducir la penalización por cambio de contexto.

Nuestra fórmula original no tenía en cuenta esa importante variable. Una forma sencilla aunque ingenua de hacerlo sería asumir que cualquier trabajo no planificado que maneje problemas de producción incurrirá en una penalización equivalente por cambio de contexto en los elementos del trabajo pendiente ya asignados al equipo. Si somos capaces de ahorrar un 8% de la velocidad del equipo, eso debería resultar en una reducción equivalente del cambio de contexto al trabajar en las tareas planificadas originalmente. Al reducir el 8 % del trabajo no planificado, también hemos reducido la penalización de CS del equivalente al 8 % del trabajo planificado que el equipo también debe completar.

Agreguemos eso a nuestra ecuación:

Siguiendo con nuestro ejemplo, nuestra organización hipotética descubriría que el impacto real de sus mejoras es ahora de poco más del 11%. Para un equipo de desarrollo de 80 ingenieros, serían más de 8 desarrolladores libres para hacer algo más para contribuir al trabajo pendiente.

Utilice la calculadora de retorno de la inversión

Para facilitar las cosas, he subido todas las fórmulas anteriores como una simple calculadora HTML a la que puedes acceder aquí:

Calculadora de retorno de la inversión

Medir el ROI es clave

Los problemas de producción son costosos, pero un marco claro de retorno de la inversión ayuda a cuantificar el impacto de las mejoras de calidad. Reducir el tiempo medio de resolución (MTTR) mediante una clasificación e investigación optimizadas puede aumentar la productividad del equipo. Por ejemplo, una reducción del 40% en el tiempo de investigación
recupera el 4% de la capacidad y reduce el costo oculto del cambio de contexto.

Utilice la Calculadora de ROI para evaluar inversiones de calidad y tomar decisiones basadas en datos. Accede a él aquí para ver cómo las mejoras específicas mejoran la eficiencia.

Referencias:
1. ¿Cuánto tiempo dedican los desarrolladores a escribir código?
2. Cómo escribir buen software más rápido (pasamos el 90% de nuestro tiempo depurando)
3. Encuesta: Corrección de errores que roban tiempo al desarrollo
4. Los costos reales del cambio de contexto