Cuando se trabaja en un equipo que desarrolla productos digitales, a veces la realidad, los requisitos empresariales, el tiempo y los plazos, la calidad del código y las exigencias del contexto no van por el mismo camino. Por lo tanto, conciliar algunos aspectos con otros puede ser un desafío difícil de resolver. Difícil, pero no imposible.
Por un lado, el término «deuda técnica» hace referencia al defecto, más o menos conocido, que tiene un producto de software. Puede deberse a una mala codificación, a procesos de implementación deficientes, a decisiones inadecuadas sobre arquitecturas, a software desactualizado, entre otros motivos. Esa falla ataca o genera problemas en el desarrollo o el ciclo de vida del producto. Por otro lado, la «escalabilidad» hace referencia a la propiedad que tiene un producto de software, lo que le permite crecer en función de los cambios necesarios en el producto de software o en referencia a las crecientes necesidades de la empresa (por ejemplo: si aumenta la cantidad de usuarios, aumenta el número de solicitudes y el producto de software necesita más potencia de cálculo). La escalabilidad puede aplicarse a los módulos de software —el código escrito— o a la infraestructura —en la que se ejecutan los módulos de software—. Es importante desarrollar software escalable si queremos que los productos de software sobrevivan, crezcan y tengan éxito. Cuando desarrollamos un nuevo producto de software, generalmente tenemos dos antagonistas en conflicto: el deseo de lanzar un producto al mercado pronto y generar valor para la empresa, y el deseo de hacer todo con la mayor calidad posible, que es uno de los requisitos más importantes para tener productos de software escalables. Un producto de software que pretenda tener éxito debe ser capaz de generar valor de manera oportuna y crecer en función de las necesidades de los usuarios. Desafortunadamente, esto no es fácil porque generar valor de manera oportuna suele generar deuda técnica, la enemiga de la escalabilidad. Entonces, ¿cómo podemos resolver este conflicto?
La clave para hacer que la deuda técnica y la escalabilidad coexistan y especialmente para evitar que la deuda técnica perjudique la escalabilidad es gestionar la deuda técnica. Debemos evitar la deuda técnica imprudente e involuntaria. De lo contrario, deberíamos generar una deuda técnica conocida que el equipo conozca. «Considero que documentar la deuda técnica en herramientas accesibles para todo el equipo es útil, ya que ayuda a todos a ser conscientes de su existencia y a las personas con menos experiencia del equipo a entender su importancia», explica Emanuel Friedrich, ingeniero de Full Stack de nuestro equipo. Algunas empresas pueden optar por tener equipos especializados dedicados a velar por la escalabilidad de los productos, lo cual es una idea excelente, aunque no siempre asequible desde el punto de vista económico. Dedicar tiempo y espacio a los sprints para tratar la deuda técnica que se está generando puede ser la opción de otros equipos que prefieren abordar la deuda técnica más rápido, antes de que comience a ser problemática.
El primer paso para dejar una deuda técnica manejable es probar el producto de software de la mejor manera posible, de modo que la deuda técnica esté cada vez más relacionada con problemas de escalabilidad y no con la corrección de errores. Cuanta más cobertura de pruebas tenga nuestro producto, menos probabilidades hay de que falle inesperadamente y, por lo tanto, menos posibilidades de que los usuarios finales detecten los errores. «... es necesario (...) contratar personal de control de calidad que pueda aportar rigor a las pruebas en el proceso de lanzamiento. Las pruebas de regresión, la compatibilidad con versiones anteriores, la interfaz de usuario y las pruebas de rendimiento deberían formar parte del proceso de control de calidad antes de que se apruebe el lanzamiento de un producto», explica Shirin Dehgran (2021).
Es posible tener deuda técnica con el propósito de entregar valor de manera oportuna sin descuidar la escalabilidad, siempre y cuando el equipo lo sepa, lo documenta, comprende su importancia y la trata a tiempo. ¿Cómo? Estas son cinco (5) claves con las que nos gustaría compartir:
El liderazgo se vuelve extremadamente importante para lograr todo esto, ya que los líderes deben entender y ser capaces de transmitir la importancia de la deuda técnica y los problemas que conlleva para la escalabilidad. La mayoría de los líderes y desarrolladores con experiencia deben transmitir al resto del equipo dónde está la deuda técnica y cómo afecta al desarrollo y la supervivencia del producto. El término proviene del sector financiero; así como cuando acudimos al banco para solicitar un préstamo por necesidad para invertir en un negocio o construir una casa, la deuda técnica suele ser necesaria en las primeras etapas del desarrollo de software. Sin embargo, además del préstamo del banco, la deuda que no se está pagando ni tratando, genera más intereses. Tratar la deuda técnica que ha «generado intereses» tiende a exigir más esfuerzo y genera un malestar e insatisfacción inevitables en el equipo, que tiene que dedicarse más al mantenimiento que a generar nuevas funcionalidades.
Probablemente, alguna deuda técnica sea inevitable, pero no tiene por qué generar problemas para la empresa e insatisfacción en el equipo que la trata, siempre teniendo en cuenta que se generó con un propósito justificable. En palabras similares, Dehgan afirma: «La deuda técnica es la realidad de todos los directores ejecutivos que emprenden una expansión. Ignorarla no es una opción, ni detener la innovación. La única manera de abordar este problema es incluir el costo de tiempo y recursos en sus planes. En resumen, pónganse al día con sus deudas técnicas antes de que afecten a sus negocios» (2021). En general, el equipo tolera más la deuda técnica relacionada con la generación de valor que la deuda técnica que aparece por descuido y no es intencional. La generación de valor y su promoción —es decir, que los equipos de productos destaquen su valor, su importancia para la empresa y la valoración de los usuarios y los clientes— pueden mantener la motivación del equipo a pesar de la deuda técnica a la que tienen que hacer frente. Además, los equipos pueden buscar más recursos para tratar la deuda técnica en caso de que sea necesario y para respaldar el crecimiento esperado, favoreciendo todos los procesos de Scalability. Los equipos satisfechos y los clientes o usuarios satisfechos son la combinación perfecta para el éxito de los productos digitales.
Referencias
Dehghan, S. (2021, 25 de marzo). El dilema de la expansión del software: ¿deuda técnica o nuevas funciones? La capital de las ranas. https://frogcapital.com/scale-up/the-software-scale-up-dilemma-technical-debt-or-new-features/
.svg)