Este perfil WoLF (Trabaja en el Último «Fuego»/Incidencia, Works on Latest Fire) se genera, o por motivaciones propias de la persona mal enfocadas o por una dirección de los equipos en direcciones dispares. En cusalquier caso siempre producen trabajo adicional solucionando problemas a los que no se presta atención en el camino hasta que tarde o temprano deben afrontarse con el consiguiente coste económico y de pérdida de oportunidad entre otros.
Si con el desarrollo software se quisiera crear una película como las de la mafia, el argumento podría ser el siguiente:
… Julia, la propietaria de "La Casa para el cuidado de Bambinos abandonados" desea salvarla de la ejecución hipotecaria, y se le ocurre implementar rápidamente la nueva aplicación de juegos "Buscador-de-Niños-Abandonados" a tiempo para la temporada navideña. Su esperanza es que los ingresos por suscripción y publicidad le salven el día al orfanato. Desafortunadamente, para que su aplicación saliera a tiempo con éxito, hace un poco de trampa al asumir la responsabilidad de una deuda de definición técnica consecuencia de un elemento de acumulación de incentivos para los jugadores de nivel épico. Todo parece perfecto, el hogar para los niños parece seguro, sus inquilinos una vez más ensayan para el concurso anual de Navidad … hasta que Carmen de Atención al Cliente realiza un informe de errores que detendría ese optimismo y arruinaría los ingresos relacionados con dicha deuda de definición. Debido a que el equipo de Julia ya está en el camino para entregar las nuevas características necesarias para obtener capital de riesgo, ignoran el informe de Carmen … eso es hasta que Luís, el cobrador de deudas técnicas, el Scrum entre los Scrums, con una nota Post-it® roja brillante … clavada al final de un bate de béisbol. No hace falta decir que el resto de la película implica que Julia pasó los días averiguando y luego solucionando todas las implicaciones de no haber solucionado esos errores de definición en el momento inicial, desviando los ingresos de la aplicación necesarios para evitar que los niños fueran arrojados al frío en la víspera de Navidad.
Sí, es evidente, un cliché muy usado, pero muy familiar para los profesionales de desarrollo de producto. Está claro que Julia está haciendo labores de WoLF. Si a este perfil se le añaden uno o varios perfiles PUFFIN (Plans unending feature factory initiatives) el caos y el conflicto ya es el de una palícula apocalíptica.
Cómo se llega a está situación
Al igual que nuestra heroína Julia, también dejamos de lado las deudas técnicas con la promesa de que la pagaremos más tarde, cuando haya más tiempo.
El problema es que nunca hay tiempo suficiente por diversas razones. Unos ejemplos reales podrían ser los siguientes (sin nombres ni detalles fácilmente identificadores por supuesto):
- El vicepresidente de Ventas Increíbles ha prometido al cliente Big Fish la función «XYZ» antes de una fecha fija que probablemente se ofreció con una consulta mínima del equipo responsable de la entrega de los productos.
- El socio capitalista ansioso que busca salir quiere asegurarse de que un determinado dominio o vertical esté cubierto antes de la próxima salida a bolsa.
- El programador aburrido, que esá construyendo su curriculum, y necesita experiencia práctica en la creación de informes BI basados en API y entregados utilizando Angular, aprovechando lo último en tecnología de aprendizaje automático en un clúster de Apache Spark.
- El Dueño de Producto Hambriento de Promoción que quiere sorprender al jefe con fabulosas características frontales durante los cuatro meses previos a su revisión de desempeño.
Todos suenan como candidatos a una priorización no basada en datos, que supondran un un precio potencialmente enorme de pagar y un gran coste de oportunidad.
Entonces, ¿por qué lo racionalizamos así? Quizás porque trabajar con la deuda técnica es divertido, aproximadamente durante la primera semana. Después de eso, se convierte en un juego siniestro de sobornar y extorsionar a los compañeros, además estafar a algún otro miembro desprevenido del equipo para que haga el trabajo sucio.
Cómo evitar llegar a estos escenarios
Para aquellos (pocos) que aún no han experimentado la ‘alegría’ de la visita de un amigable cobrador de deudas técnicas, vala la pena tener en cuenta estos 7 principios a los cuales prestar atención durante el proceso.
Apoye, investigue y priorice estos principios o situaciones:
- Si un ingeniero está luchando contra una deuda técnica para terminar un trabajo.
- Si crea una función con una deuda de Experiencia de Usuario (UX) obvia.
- Si se requiere investigación porque no existían datos.
- El trabajo no está contribuyendo al valor del cliente, cuando estaba planificado que sucediese.
- Se publicitó una historia y luego fue necesario jugar a justificar lo dicho.
- Se ha fallado al validar el impacto.
- Se comprende la la idea, pero aún asi se está creando más tareas, rehaciendolas, recortando funciones, aumentando la carga operativa,… a cada paso se vuelve menos impresionante.
La audacia y sinceridad es fundamental en la toma de medidas para que el equipo, la administración, las partes interesadas, los patrocinadores y, si es posible, los clientes sean conscientes de que las futuras versiones del producto o servicio incluirán las deudas constraidas. Al menos hay que establecer una correcta gestión de las expectativas explicando los «accidentes desafortunados» que podrían ocurrir si las responsabilidades adquiridas no se pagan.
Ya sea que decida simplemente pagar el interés o pagar el total, hay que tener en cuenta que, al igual que frente a un usurero, el precio de su acumulación técnica probablemente aumentará en coste durante el período de tiempo en el que permanece sin resolver.
Referencias
- Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations’ — Nicole Forsgren & Jez Humble
- ‘The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations’— Gene Kim, et.al.
