Una forma de vida
Dejame darte algo de contexto; quizás al principio no tenga mucho sentido, pero tené paciencia. Crecí en un país donde la inflación llega a los dos dígitos. Hay una carrera continua entre los salarios y el costo de vida. Sufrió varias crisis económicas. Y sin embargo, la gente se las arregla para llevar una vida “normal” o, al menos, una rutina. En algo que todo el mundo en mi país es bastante experto es en las finanzas de la deuda. Yo encaro la deuda técnica exactamente de la misma manera y quiero compartirlo con vos.
La plaga que cayó sobre nuestro proyecto
La naturaleza del problema
No es raro escuchar a la gente hablar de la deuda técnica como algo que les pasó. Una tragedia que los golpeó por razones externas. Algo que no pueden controlar y que fue inesperado. Los proyectos de software, al menos los que están impulsados por la rentabilidad o dentro del contexto de un negocio, son el producto de dos mundos muy distintos. De un lado está la ingeniería, una disciplina que, con suficiente planificación, puede producir una solución adecuada a la mayoría de los problemas que sobrevivirá tanto al problema como al ingeniero. Uno suele escuchar historias sobre software antiguo corriendo en hardware que ya no se fabrica, todavía funcionando, para empresas y procesos que desaparecieron hace mucho. Del otro lado está el negocio, que también está atravesado por las oportunidades de mercado y el impulso de las tendencias comerciales. Tratar de amalgamar un oficio que puede aumentar la calidad de lo que entrega afilando las herramientas y planificando por el tiempo que sea necesario con otro que puede sacar un gran provecho de los eventos y las entregas oportunas conducirá, casi siempre, a una solución de compromiso.
Estamos todos en el mismo barco
Un equipo de ingeniería zarpará para un viaje determinado, cargará provisiones y asumirá que, trabajando durante el viaje, lo que tiene que entregar estará listo para cuando lleguen a puerto. El equipo de negocio pasará el viaje señalando puertos, estudiando mapas, hablando con los barcos que se cruzan y, en algún momento, decidirá que el próximo puerto es el nuevo destino. En ese punto se produce un choque de voluntades, donde la realidad del negocio dicta que la mejor ganancia se obtendrá si el producto se vende a mitad de viaje. Así es como nace la deuda técnica la mayor parte del tiempo.
De vuelta a mis raíces.
Yo fui ese marinero.
No puedo decir que esto nunca me pasó. En nuestra analogía, estuve a mitad de viaje con ventas apuntando a la costa y medio producto en las manos que necesitaba “completarse” en un plazo poco realista. Parché con cinta adhesiva y creí que tendría tiempo de completarlo, según los planes originales, más adelante.
La realidad odia los planes
No importa qué tan bien planificado esté un producto, va a cambiar en cuanto toque al cliente. Pensar que un plan es tan bueno que el cliente va a recibir un producto que le va a calzar tan perfectamente que completarlo según lo planeado es el mejor camino, es una mentira que nos gusta contarnos:
- El tiempo cambia el contexto del producto
- El tiempo cambia a los clientes
- El contacto con el cliente crea nuevas necesidades
Más anécdotas
Volviendo a mi introducción, así es como manejábamos la extraña realidad económica en la que vivíamos: haciendo predicciones sobre cómo nuestros ingresos iban a seguir a la inflación (el contexto lo permite hasta cierto punto) podíamos inferir qué tasas de crédito iban a producir pérdida 0 y, a veces, incluso un resultado positivo. En algún momento de mi vida, tenía sentido pagar la compra mensual del supermercado en 12 cuotas mensuales. Usando instrumentos financieros que reducían la tasa de interés por debajo de la inflación, uno podía esperar que el precio total de los bienes representara un porcentaje más chico de sus ingresos para cuando terminaba de pagarlo que si lo pagaba en efectivo. Si esto cuesta de entender, pensalo en el contexto de una economía más normal. Puede que tengas ahorrado suficiente dinero para comprar un auto cero kilómetro. Tu banco podría tener una buena oferta donde podés conseguir un préstamo para pagar el auto a bajo interés. Si podés pensar una manera de hacer que tu dinero genere, al menos, el mismo interés que la tasa del banco, deberías pedir el préstamo:
- Podrías encontrar un mejor préstamo para refinanciar en el futuro, ahorrándote dinero
- Podrías necesitar esa liquidez más adelante para mejores inversiones u otra cosa y la tendrías disponible al instante
- La inflación podría superar las tasas de tu préstamo y, si tus ingresos también lo hacen, tu auto saldría más barato.
Y ahora en tecnología
La explicación de arriba es bastante análoga a cómo encaro la deuda técnica:
El diseño inicial del producto contiene una carga alta de objetivos e intenciones de negocio. Hay mucho más input sobre el efecto deseado que sobre la solución que se pretende brindar.
Cada nueva funcionalidad se planifica como si tuviera que estar terminada en el primer puerto. Sin ser descuidado (la seguridad y la estabilidad son siempre una preocupación, la escalabilidad todavía no) planeo construir la mayor parte de mi producto con componentes mínimos y rápidos. Se hace una lista de prioridades y luego, con cada puerto en el que no atracamos, esa lista se va consumiendo completando ítems.
Casi nunca retraso la entrega para completar algo, lo perfecto es enemigo de lo bueno.
Nunca dejo que el alcance crezca sin una preocupación realista (de nuevo, estabilidad o seguridad). Una vez que algo llega a un cliente está destinado a cambiar, así que cuanto menos construyamos, más nuestro trabajo futuro será construir y no remodelar (que es significativamente más difícil).
Antes de empezar cada nueva funcionalidad o gran bloque de trabajo en un proyecto, reviso cómo la deuda existente va a afectar al proyecto en cuestión. Siempre elijo pagar la deuda si lo afecta; un nuevo proyecto puede usarse como refinanciación, pero apilar deuda sobre deuda es una receta para el desastre.
Aprovechá los posibles momentos de baja para pagar deuda. Si se lleva bien, el libro contable de la deuda técnica debería estar priorizado. El criterio de orden debería ser según lo que sea importante para el equipo, pero además debería calcularse el tiempo estimado de arreglo. Uno debería tomar de lo más alto de la prioridad cuando el tiempo lo permite, o simplemente resolver los más rápidos si no es posible.
Una feliz llegada a puerto
Para terminar la analogía náutica (a esta altura queda claro que no tengo ni idea de navegación). Esta metodología me mantuvo a flote durante varios viajes. Rara vez estoy sobrecargado de deuda técnica. Una forma de pensar que me gustaría usar para cerrar acá y que me ayudó hasta ahora es: no deberíamos pensar los proyectos de software como algo con un principio y un fin. Yo concibo mi software como si estuviera vendiendo contratos de servicio; brindo un servicio de desarrollo y, si estamos en el negocio, siempre vas a recibir software fresco para la necesidad del momento. Enfocarse en una entrega periódica ayuda a aliviar la ansiedad por la finalización.