6 tipos de deuda técnica: la deuda técnica no es una carga, sino una herramienta estratégica para el éxito

xguru · 2023-03-20T11:21:01+09:00

Lo necesario para ver la deuda técnica como una herramienta estratégica Reconocer y resolver las suposiciones negativas sobre la deuda técnica Clasificar los 6 tipos de deuda técnica y responder de forma diferenciada Determinar la magnitud de la deuda técnica Cómo decidir la prioridad de la deuda técnica How to Not Manage Tech Debt 4 suposiciones que llevan a gestionar mal la deuda técnica Suposición #1: deuda técnica = algo malo No toda deuda técnica debe clasificarse como “mala” Es mucho mejor ponerle nombre a cada una, medir el tamaño del dolor que causa y clasificar las deudas técnicas Hay deudas técnicas que conviene tener, y todos los equipos deberían tener deuda técnica El caso de Twitter, que “tuvo buena deuda técnica”: usó almacenamiento público y luego desarrolló Manhattan, su propia base de datos distribuida Preguntas para responder a la suposición “deuda técnica = algo malo” Si acumulamos esta deuda técnica ahora y la resolvemos el próximo mes, ¿qué ganamos? ¿En qué situación la dirección se interesaría por esta deuda técnica? Si el CTO fuera a presentarla ante la dirección, ¿cómo deberíamos transmitir la información para ayudar en ese pitch? ¿Cómo puede esta iniciativa conectarse con la visión más grande de la empresa o con su dirección estratégica? Suposición #2: toda deuda técnica = trabajo complejo Igual que con cualquier trabajo difícil, hay varias formas de abordar el trabajo complejo, no solo en deuda técnica En particular, en deuda técnica existe una forma de abordar trabajo Defined/Undefined (definido/no definido) Defined = el trabajo tiene inicio y fin Undefined = el trabajo tiene un inicio, pero no un final claro Para responder a la suposición de que deuda técnica = complejidad Aclarar si la deuda técnica en cuestión es Defined o Undefined En el caso de Defined, entender el tiempo estimado para completar el trabajo y dejar un pequeño margen de buffer En el caso de Undefined, enumerar las partes ambiguas y comunicarlas a las partes interesadas para que entiendan por qué el trabajo es complejo y no tiene una fecha clara de cierre, y pedir su opinión sobre la mejor forma de avanzar Dividir la deuda técnica Undefined en partes de trabajo más digeribles para hacerla menos compleja Pasar de un trabajo complejo y grande a tareas pequeñas que siguen siendo complejas pero ejecutables puede motivar más al equipo para resolver parte de la deuda técnica durante un sprint o un periodo trimestral definido Preguntas para responder a la suposición “deuda técnica = trabajo complejo” ¿Qué suposiciones incorrectas tenemos sobre el sistema? Si trajéramos a alguien con experiencia o familiaridad en esta área, ¿qué preguntas tendríamos que hacerle sí o sí? ¿Nuestro equipo tiene el personal y el conocimiento adecuados para realizar este trabajo? Si no, ¿cómo deberíamos considerar redistribuir la información y cuándo sería el momento ideal para resolver este problema? ¿Cuál es la mejor forma de explicarle la complejidad de esta deuda técnica a alguien que no la entiende en absoluto? Suposición #3: deuda técnica ≠ trabajo de producto Las organizaciones tienen claridad sobre cómo el trabajo de producto mejorará las métricas de la empresa Pero normalmente la deuda técnica queda fuera de eso Resolver la deuda técnica a tiempo puede ser clave para impulsar el crecimiento de la empresa, aunque no se pueda cuantificar de inmediato Para responder a la suposición de que deuda técnica ≠ trabajo de producto Aunque un área concreta de deuda técnica no esté conectada directamente con una métrica, pensar de manera amplia en qué experiencia de usuario o de producto puede ayudar a mejorar En vez de enfatizar solo las ventajas técnicas, si se remarcan por igual los beneficios para el usuario y para el producto, será más fácil que otras personas entiendan por qué el equipo debería interesarse en este trabajo Dedicar tiempo a confirmar que el liderazgo de negocio y el liderazgo técnico están alineados (on the same page) Preguntas para responder a la suposición “deuda técnica ≠ trabajo de producto” ¿Cuál es la razón más importante por la que debemos hacer este trabajo ahora? ¿Quién necesita entender el impacto de este trabajo? ¿Por qué debería importarle? ¿Qué es lo que quiero comunicar? ¿Coincide con lo que la parte interesada quiere escuchar? Si no, ¿cómo puedo resolver su problema? ¿Qué considero yo o mi equipo un resultado razonable vs. uno excelente? ¿Estamos prometiendo demasiado sobre los resultados esperados? ¿Podemos nivelar expectativas separando lo excelente de lo bueno? Suposición #4: el dolor individual = el dolor de la organización Los ingenieros que están más cerca de la deuda técnica suelen repetir con frecuencia que lidiar con ella es doloroso a nivel personal Para el empleado puede sentirse como el fin del mundo, pero el resto de la organización no siente ese mismo dolor Es algo común en personas en etapas tempranas de su carrera, y normalmente surge por falta de contexto estratégico más amplio Para responder a la suposición de que el dolor individual = el dolor de la organización Cuando te topes con áreas de alta prioridad dentro de la deuda técnica, detente un momento a ver si se trata de un pain point a nivel individual o a nivel organizacional Normalmente, los problemas a nivel organizacional afectan directamente al cliente o al negocio de alguna forma Intenta pensar desde la perspectiva de alguien que tenga más contexto organizacional que tú. También puedes explicárselo a alguien de otro equipo Preguntas para responder a la suposición “el dolor individual = el dolor de la organización” ¿Cuántos equipos se benefician si clasificamos y resolvemos esta deuda técnica? ¿Cuándo ha reconocido o recompensado la empresa a alguien por encargarse de trabajo de deuda técnica? ¿Qué tipo de deuda técnica era y por qué era necesaria en ese momento? ¿Se puede hablar de cómo esa persona posicionó ese trabajo? ¿Mi engineering manager entiende el valor del trabajo de deuda técnica? ¿Defenderá mi contribución en este trabajo durante la evaluación de desempeño? 6 tipos de deuda técnica Maintenance debt (deuda de mantenimiento) Cuando el equipo no logra mantenerse al día con las actualizaciones de la tecnología También incluye no eliminar código muerto después de iniciar un experimento / hacer rollout de una feature / revertir un despliegue, así como no actualizar librerías, no comentar el código contextual o no documentar decisiones de implementación Ej.) se experimentó con la función “log in with Spotify” y, al cancelarla, no se eliminó ese código Developer efficiency debt (deuda de eficiencia del desarrollador) Cuando la empresa no cuenta con pruebas, monitoreo y sistemas de alertas adecuados para el producto Es un tipo común de deuda donde el workflow de ingeniería es muy ineficiente, los despliegues/builds toman horas o días, y los desarrolladores no detectan problemas técnicos antes de entrar en producción Ej.) la organización creció de 15 a 50 personas en un año, mientras se ejecutaban demasiados experimentos. Las releases para corregir bugs detectados en producción llevan 2 o 3 versiones de retraso. Las nuevas pruebas para la experiencia de compra se siguen quedando atrás Stability debt (deuda de estabilidad) Cuando se acumulan varios tipos de deuda técnica en la organización y eso afecta la estabilidad de la infraestructura En vez de gestionar el on-call de forma preventiva, se termina llamando después a la persona experta cuando surge un problema, o todo el equipo acaba haciendo on-call Esto es un gran dolor de cabeza para los ingenieros y para el equipo de rotación de on-call, pero para el resto de la empresa incluso resulta imposible identificar y explicar el problema La deuda de estabilidad también afecta la confiabilidad del producto y puede generar problemas con los que se topan los clientes Ej.) el equipo móvil tiene más desarrolladores de iOS, así que prioriza iOS sobre la app de Android. Como resultado, a la app de Android le faltan lineamientos de producto para flujos críticos del negocio y además conserva código débil (“Kryptonite”) que un tercero desarrolló al inicio. Esto hace que a los usuarios de Android se les cierre la app al acceder a funciones antiguas, lo que termina dañando la calificación en Google Play Security debt (deuda de seguridad) Cuando se usa un stack tecnológico con vulnerabilidades de seguridad, como ataques de fuerza bruta o filtraciones de datos Como a las personas les cuesta planear y evaluar cosas que podrían pasar (o no pasar), muchas organizaciones acumulan deuda de seguridad Ej.) por problemas en procesos internos de la empresa no se aplicaron actualizaciones a tiempo y no se parcheó una vulnerabilidad conocida, lo que provocó una filtración de datos personales de clientes (desde empresas pequeñas hasta casos como Equifax, donde 140 millones de personas se vieron afectadas) Technical product debt (deuda técnica de producto) Cuando el impacto negativo sobre el producto se vuelve evidente Es la deuda más fácil y más conveniente de resolver, porque también afecta al usuario y todos los equipos dentro de la organización ven el impacto en ventas/ingresos Ej.) a un usuario le toma varios segundos realizar una tarea específica dentro del producto. Esto puede surgir por distintos tipos de deuda, pero impacta la experiencia central del usuario con el producto Decision debt (deuda de decisión) Cuando se paga el costo de una decisión técnica previa porque fue incorrecta en X%, o porque implicó compensaciones en alcance, tiempo o recursos Es la forma más común de deuda técnica Ej.) se utilizó un tercero para cierto experimento en el sitio web. Tras crecer enormemente durante varios años, ahora lo visitan millones de usuarios. Como resultado, los equipos técnicos, de datos y de producto sufren cada vez que intentan hacer experimentos complejos. Esto ocurre porque el equipo tomó una decisión de trade-off entre un tercero y desarrollo interno, lo que generó deuda de decisión. En ese momento era la opción correcta, pero ahora ya se sienten sus efectos Determinar la escala de la deuda técnica: Acute vs Systemic Una vez que entiendes los tipos de deuda técnica, debes determinar la magnitud del costo para compararlo con lo que vas a obtener Cuando el equipo pregunta “¿cuándo vamos a tener tiempo para trabajar en la deuda técnica?”, es difícil saber si se trata de algo pequeño o grande en términos de tiempo, pensamiento y esfuerzo Deuda técnica Acute (aguda) Deuda técnica relativamente pequeña Ej.) para lanzar una nueva función, se omitió el trabajo para una plataforma/navegador con poco uso. Si no hubiera otras tareas, se podría agregar fácilmente en un día Deuda técnica Systemic (sistémica) Deuda técnica de gran a enorme escala Ej.) el CTO o fundador tomó una decisión sobre el producto (e indirectamente sobre la tecnología) hace 5 años, y todo se construyó sobre esa base. Si se cambia, afectará muchas cosas. Esta deuda técnica no se resuelve fácilmente y el cambio puede tomar de meses a años Priorizar estratégicamente la deuda técnica Una forma flexible de considerar y evaluar Confidence: ¿es alta la probabilidad de que esto termine en un problema grave? bajo/alto Time: ¿cuándo se volverá un problema? no urgente/urgente Impact to User: si no hacemos esto, ¿se producirán problemas de velocidad o calidad que dañen la experiencia del usuario? bajo/alto Sequence: ¿esto impide llegar a un milestone importante? impacto pequeño/bloqueo Accumulated debt: ¿cuánta deuda ya decidimos acumular? poca/mucha Portafolio estratégico de deuda técnica según la etapa de crecimiento de la empresa Traction: Antes del Product-Market fit Se deben tomar decisiones de ingeniería priorizando velocidad por encima de exactitud, estabilidad y procesos. Gran escala de deuda de eficiencia del desarrollador En general, esto significa elegir frameworks full stack como Django, Rails o PHP para desarrollar rápido Inflection: Momento en que aparecen señales de PMF y el producto entra en un loop escalable El equipo se da cuenta de que necesita ciertos procesos (empieza a resolverse la deuda de eficiencia del desarrollador), pero como todavía está equilibrando procesos internos y experiencia de usuario, la deuda técnica de producto aumenta Scale: Etapa de hyper-growth de la empresa A medida que se encuentra el balance entre prácticas y procesos internos y experiencia de usuario, la deuda técnica de producto y la deuda de eficiencia del desarrollador empiezan a disminuir y estabilizarse Como resultado del crecimiento muy rápido, aumentan la deuda de seguridad, la deuda de mantenimiento y la deuda de decisión Se producen muchos cambios y ajustes en automatización de pruebas, sistemas de despliegue, monitoreo y alertas, logging e instrumentación, testing y staging, ETL, etc. Expansion: Inicio de la saturación. El negocio se vuelve más maduro Debido a la gran cantidad de código y decisiones antiguas, la deuda de mantenimiento y la deuda de decisión siguen creciendo Mientras el equipo busca nuevas oportunidades de crecimiento, la deuda de eficiencia del desarrollador comienza a subir otra vez La deuda técnica de producto, la deuda de seguridad y la deuda de estabilidad se van equilibrando después del periodo anterior Consejos para gestionar el portafolio de deuda técnica Procesos para reducir la deuda técnica que se crea Aunque acumular deuda técnica puede ser una estrategia, a veces también conviene implementar procesos desde el inicio para evitar que se genere Esto es especialmente cierto en las etapas de Inflection y Scale, donde la deuda de eficiencia del desarrollador debería disminuir a medida que se incorporan más ingenieros Cuando baja la deuda de eficiencia del desarrollador, puede sustituirse por un aumento de deuda de decisión y deuda de mantenimiento Ejemplos de estos procesos: revisión de código/PR, estándares de monitoreo, aprobación de QA y revisión técnica/de diseño Herramientas para prevenir la formación de ciertos tipos de deuda Invertir en herramientas básicas puede evitar que se formen algunos tipos de deuda Esto es especialmente importante en la etapa de Scale para prevenir problemas de seguridad (deuda de seguridad), bugs que afectan la experiencia de usuario (deuda técnica de producto) y consistencia del código (deuda de eficiencia del desarrollador) Ejemplos de estas herramientas: linter y pipelines de CI/CD Trabajo de sprint para deuda técnica Reactive & Acute Cuando la organización alcanza una escala donde se necesita on-call, los sprints de on-call deberían dedicarse a apagar incendios actuales o a trabajo reactivo relacionado con deuda técnica Esto permite a la organización abordar ítems urgentes de deuda técnica y ejecutar acciones reales sobre problemas actuales o pasados a través del equipo de on-call Hacer posible el on-call para trabajo reactivo es especialmente importante en las etapas de Scale/Expansion, porque resolver deuda técnica urgente permite que otros equipos creen nuevas funciones/productos y procesen deuda adicional Trabajo de roadmap para deuda técnica proactiva y sistémica Incluir deuda técnica en el roadmap requiere mucho trabajo de alineación entre equipos Ejemplos de incluir deuda técnica en el roadmap: reescrituras a gran escala, reajuste del sistema de datos de funciones que usan principalmente los clientes, definición e implementación de alertas para rutas críticas, cambio del sistema de pagos, etc. Cómo convertir la deuda técnica de una carga en una herramienta estratégica A través de la deuda técnica acumulada, el equipo puede tomar decisiones estratégicas integrales sobre qué iniciativas llevar adelante Pensar en las suposiciones comunes sobre deuda técnica que el equipo enfrentará. ¿Te opones a “deuda técnica = algo malo” o a “deuda técnica ≠ trabajo de producto”? ¿Estás escuchando a colegas que creen que “el dolor individual = el dolor de la organización”? No usar el término paraguas “deuda técnica”. Ponerle nombre: deuda de mantenimiento, deuda de eficiencia del desarrollador, deuda de estabilidad, deuda de seguridad, deuda técnica de producto, deuda de decisión Determinar la escala de la deuda técnica para hacerla menos ambigua. ¿Es Acute o Systemic? Priorizar estratégicamente la deuda técnica comparándola con otras áreas de la empresa. Priorizar en función de vectores como confianza, tiempo e impacto sobre el usuario Hacer evolucionar y mantener equilibrado el portafolio de deuda técnica según los cambios y necesidades del crecimiento de la empresa

(reforge.com)

47 puntos por xguru 2023-03-20 | 2 comentarios | Compartir por WhatsApp

Lo necesario para ver la deuda técnica como una herramienta estratégica
- Reconocer y resolver las suposiciones negativas sobre la deuda técnica
- Clasificar los 6 tipos de deuda técnica y responder de forma diferenciada
- Determinar la magnitud de la deuda técnica
- Cómo decidir la prioridad de la deuda técnica

How to Not Manage Tech Debt

4 suposiciones que llevan a gestionar mal la deuda técnica

Suposición #1: deuda técnica = algo malo

No toda deuda técnica debe clasificarse como “mala”
Es mucho mejor ponerle nombre a cada una, medir el tamaño del dolor que causa y clasificar las deudas técnicas
Hay deudas técnicas que conviene tener, y todos los equipos deberían tener deuda técnica
El caso de Twitter, que “tuvo buena deuda técnica”: usó almacenamiento público y luego desarrolló Manhattan, su propia base de datos distribuida
Preguntas para responder a la suposición “deuda técnica = algo malo”
- Si acumulamos esta deuda técnica ahora y la resolvemos el próximo mes, ¿qué ganamos?
- ¿En qué situación la dirección se interesaría por esta deuda técnica? Si el CTO fuera a presentarla ante la dirección, ¿cómo deberíamos transmitir la información para ayudar en ese pitch?
- ¿Cómo puede esta iniciativa conectarse con la visión más grande de la empresa o con su dirección estratégica?

Suposición #2: toda deuda técnica = trabajo complejo

Igual que con cualquier trabajo difícil, hay varias formas de abordar el trabajo complejo, no solo en deuda técnica
En particular, en deuda técnica existe una forma de abordar trabajo Defined/Undefined (definido/no definido)
- Defined = el trabajo tiene inicio y fin
- Undefined = el trabajo tiene un inicio, pero no un final claro
Para responder a la suposición de que deuda técnica = complejidad
- Aclarar si la deuda técnica en cuestión es Defined o Undefined
  - En el caso de Defined, entender el tiempo estimado para completar el trabajo y dejar un pequeño margen de buffer
  - En el caso de Undefined, enumerar las partes ambiguas y comunicarlas a las partes interesadas para que entiendan por qué el trabajo es complejo y no tiene una fecha clara de cierre, y pedir su opinión sobre la mejor forma de avanzar
- Dividir la deuda técnica Undefined en partes de trabajo más digeribles para hacerla menos compleja
  - Pasar de un trabajo complejo y grande a tareas pequeñas que siguen siendo complejas pero ejecutables puede motivar más al equipo para resolver parte de la deuda técnica durante un sprint o un periodo trimestral definido
Preguntas para responder a la suposición “deuda técnica = trabajo complejo”
- ¿Qué suposiciones incorrectas tenemos sobre el sistema?
- Si trajéramos a alguien con experiencia o familiaridad en esta área, ¿qué preguntas tendríamos que hacerle sí o sí?
- ¿Nuestro equipo tiene el personal y el conocimiento adecuados para realizar este trabajo? Si no, ¿cómo deberíamos considerar redistribuir la información y cuándo sería el momento ideal para resolver este problema?
- ¿Cuál es la mejor forma de explicarle la complejidad de esta deuda técnica a alguien que no la entiende en absoluto?

Suposición #3: deuda técnica ≠ trabajo de producto

Las organizaciones tienen claridad sobre cómo el trabajo de producto mejorará las métricas de la empresa
Pero normalmente la deuda técnica queda fuera de eso
Resolver la deuda técnica a tiempo puede ser clave para impulsar el crecimiento de la empresa, aunque no se pueda cuantificar de inmediato
Para responder a la suposición de que deuda técnica ≠ trabajo de producto
- Aunque un área concreta de deuda técnica no esté conectada directamente con una métrica, pensar de manera amplia en qué experiencia de usuario o de producto puede ayudar a mejorar
- En vez de enfatizar solo las ventajas técnicas, si se remarcan por igual los beneficios para el usuario y para el producto, será más fácil que otras personas entiendan por qué el equipo debería interesarse en este trabajo
- Dedicar tiempo a confirmar que el liderazgo de negocio y el liderazgo técnico están alineados (on the same page)
Preguntas para responder a la suposición “deuda técnica ≠ trabajo de producto”
- ¿Cuál es la razón más importante por la que debemos hacer este trabajo ahora?
- ¿Quién necesita entender el impacto de este trabajo? ¿Por qué debería importarle?
- ¿Qué es lo que quiero comunicar? ¿Coincide con lo que la parte interesada quiere escuchar? Si no, ¿cómo puedo resolver su problema?
- ¿Qué considero yo o mi equipo un resultado razonable vs. uno excelente?
- ¿Estamos prometiendo demasiado sobre los resultados esperados? ¿Podemos nivelar expectativas separando lo excelente de lo bueno?

Suposición #4: el dolor individual = el dolor de la organización

Los ingenieros que están más cerca de la deuda técnica suelen repetir con frecuencia que lidiar con ella es doloroso a nivel personal
Para el empleado puede sentirse como el fin del mundo, pero el resto de la organización no siente ese mismo dolor
Es algo común en personas en etapas tempranas de su carrera, y normalmente surge por falta de contexto estratégico más amplio
Para responder a la suposición de que el dolor individual = el dolor de la organización
- Cuando te topes con áreas de alta prioridad dentro de la deuda técnica, detente un momento a ver si se trata de un pain point a nivel individual o a nivel organizacional
  Normalmente, los problemas a nivel organizacional afectan directamente al cliente o al negocio de alguna forma
- Intenta pensar desde la perspectiva de alguien que tenga más contexto organizacional que tú. También puedes explicárselo a alguien de otro equipo
Preguntas para responder a la suposición “el dolor individual = el dolor de la organización”
- ¿Cuántos equipos se benefician si clasificamos y resolvemos esta deuda técnica?
- ¿Cuándo ha reconocido o recompensado la empresa a alguien por encargarse de trabajo de deuda técnica? ¿Qué tipo de deuda técnica era y por qué era necesaria en ese momento? ¿Se puede hablar de cómo esa persona posicionó ese trabajo?
- ¿Mi engineering manager entiende el valor del trabajo de deuda técnica? ¿Defenderá mi contribución en este trabajo durante la evaluación de desempeño?