La deuda técnica es salir despeinado de casa para llegar al avión
La deuda técnica es salir despeinado de casa para llegar al avión
Cómo gestionar la deuda técnica del equipo y utilizarla a tu favor
La semana pasada fue el South Summit. Aproveché para hablar con muchos profesionales que, a pesar de su título de “director de negocio”, desempeñan un papel de product manager. Todos tenían perfiles super completos:
Entre 10 y 15 años en el sector, con mucho dominio del “negocio”
Puestazo dentro de la empresa, reportando directamente al CEO
Ingenioso, curioso, “listo”, … vamos, con buena materia gris
Y todos venían con la misma banda sonora. Estamos apostando muy fuerte por la digitalización o el negocio ya ha cambiado y sólo los que nos estamos reinventando saldremos adelante y la IA es la clave, el IoT es la clave, el *** es la clave …
A esas empresas les va a ir bien. Lo han visto venir y han puesto a alguien dentro de la empresa que va a saber gestionar estos cambios de paradigma para mejor.
Ninguno de estos directores ha recibido ninguna formación formal de cómo ser product manager, y aun así todos aplican buenas prácticas del gremio (entender el negocio, conocer al cliente, MVPs, feedback, …).
Sin embargo, todos tenían la misma queja:
Llevamos varios meses parados por la dichosa deuda técnica.
Para el que esté aprendiendo este término por primera vez, si buscamos ¿Qué es la deuda técnica? encontramos lo siguiente:
Por lo general la deuda técnica se puede englobar en tres tipos:
Falta de automatización de pruebas y despliegue
Deuda en el diseño o la arquitectura del producto
Código de baja calidad
Falta de automatización de pruebas y despliegue
En el desarrollo de software hay un montón de procesos repetitivos: pasar tests, subir código a distintos entornos, retroceder a versiones estables, …La falta de automatización de estos procesos, puede generar una deuda técnica significativa,
ya que en los procesos manuales es fácil cometer errores. Además, consumen mucho tiempo del equipo que le impide entre otras cosas automatizarlos para poder solucionarlos.
Para gestionar esta deuda técnica, es necesario implementar un conjunto sólido de pruebas automatizadas, incluidas pruebas unitarias, de integración y de aceptación. Además, es beneficioso automatizar el proceso de compilación, prueba y despliegue para garantizar una entrega continua y reducir la posibilidad de errores humanos.
Este tipo de deuda, a la larga, es la más costosa. Si cada vez que hay que corregir un error, tienes que realizar 8 horas de tareas manuales, subirás cosas a producción con menos frecuencia. Tendrás que reunir trabajo de considerablemente más de 8 horas para que la subida merezca la pena. Si, por el contrario, cómo desarrollador tardas 5 minutos, podrás hacer subidas más pequeñas.
Tampoco hace falta automatizar todo al 100%, cuanto más quieres automatizar más se complica el desarrollo. Analizando cuantas subidas a producción quieres hacer al mes debería ser fácil calcular cuánto tiempo quieres dedicarles a procesos manuales que no aportan valor.
Diseño y arquitectura deficientes
La arquitectura de un producto se refiere a “cómo está construido”. El lenguaje, las bases de datos, autenticación, … En desarrollo de software, todo tiene sus pros cons. Por ejemplo, al elegir un tipo de base de datos, ciertas búsquedas irán muy bien, y un tipo de datos se guardarán muy mal. A la hora de elegir ciertas piezas del diseño de la aplicación, corremos el riesgo de limitarnos en el futuro.
Para poder gestionar esta deuda técnica, es importante invertir tiempo en la planificación y el diseño adecuados desde el principio del proyecto. Diseña de acuerdo a tu caso de uso. Esto implica utilizar patrones de diseño sólidos, abordar la modularidad y la cohesión, y tener una arquitectura escalable y flexible. Además, es crucial realizar revisiones de diseño periódicas y refactorizar cuando sea necesario.
El origen de este tipo de deuda viene de cerrar los casos de uso del producto al inicio, cuando tenemos poca información del producto final y el camino que seguirá la compañía.
Ejemplo práctico: No podemos meter patinetes en la aplicación porque el usuario sólo iba a poder reservar coches. Es una frase que para las personas de producto carece de todo sentido, pero que cuando te metes en bases de datos y en código se entiende.
Desarrollar con arquitecturas en base a dominios, suele mitigar el impacto de estas decisiones y permite introducir nuevos conceptos de manera aislada al resto de la aplicación.
Es común asumir este tipo de deuda al principio de los proyectos para poder ser más rápidos entregando las primeras versiones del producto. Pero cuidado con depender mucho de ella. Crear una arquitectura demasiado sencilla te limitará en el futuro a la hora de querer incorporar casos de uso más complejos.
Código de baja calidad
La calidad del código, no se mide en el grado en el que resuelve una necesidad del producto. Tiene más que ver con la capacidad de transformarse y adaptarse a las nuevas versiones y la facilidad de trabajar en equipo sobre una base sin perder el contenido base.
Si no se tiene en cuenta esto, la calidad del código puede deteriorarse debido a la falta de buenas prácticas de programación, la falta de pruebas unitarias adecuadas, la falta de comentarios y documentación, entre otros factores.
La única forma de evitar un deterioro del código es seguir unas buenas prácticas de desarrollo de software, como la escritura de código limpio y legible, la adopción de estándares de codificación, la realización de pruebas unitarias exhaustivas y la implementación de revisiones de código.
Por lo general nadie quiere desarrollar código de baja calidad, pero hay ocasiones en las que puede tener sentido ser menos exigente. Por ejemplo, para hacer pruebas con usuarios o de herramientas externas, puede tener sentido escribir código de baja calidad. Eso sí, es importante una vez terminadas estas pruebas, dedicarle el tiempo necesario a dejar ese código acorde a las bases fijadas en el equipo, asegurando la sostenibilidad a futuro.
La deuda técnica en sí no es mala. Es comparable a la deuda financiera. Si eres capaz de generar más valor que los intereses, es buena. Si, por el contrario, no haces más que añadir deuda a tu tarjeta de crédito, con el tiempo la cuenta será demasiado dolorosa de pagar. La única forma de gestionar bien esta deuda es hacerle seguimiento. Por favor, no mires hacia otro lado cuando se hable de deuda técnica en tu equipo. Escucha y entiende las carencias de tu producto para que la próxima vez que toque priorizar no te lleves las manos a la cabeza con la deuda técnica.