← Últimos artículos
💻 computer science

Stakeholder Criteria in Technical Debt Decision-Making: A Practitioner-Informed Taxonomy

Basado en un estudio cualitativo de 11 profesionales del software en Brasil, este artículo propone una taxonomía y un modelo conceptual informados por la práctica que categoriza los criterios de las partes interesadas para la toma de decisiones sobre la deuda técnica en seis familias, distinguiendo cómo estos criterios funcionan como mecanismos de permiso para la adquisición de deuda frente a mecanismos de autorización para el reembolso.

Autores originales: Joao Pedro Bittencourt, Rita Suzana Pitangueira Maciel

Publicado 2026-06-23
📖 6 min de lectura🧠 Análisis profundo

Autores originales: Joao Pedro Bittencourt, Rita Suzana Pitangueira Maciel

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás construyendo una casa. A veces, necesitas mudarte rápido porque la familia está esperando un bebé, o el propietario está subiendo el alquiler. Así que decides saltarte la instalación del aislamiento elegante y costoso en el ático y simplemente colocas unos paneles delgados y baratos por ahora. Sabes que no es perfecto y sabes que tendrás que arreglarlo más tarde, pero necesitas mudarte ahora. En el mundo del software, esto se llama Deuda Técnica. Es tomar un atajo hoy para ahorrar tiempo, sabiendo que te costará más esfuerzo (y tal vez dinero) arreglarlo después.

Este artículo plantea una pregunta simple pero difícil: ¿Cómo decide la gente cuándo tomar estos atajos y cómo deciden cuándo pagar finalmente la cuenta?

Los autores descubrieron que estas decisiones no se tratan solo de matemáticas o código. Son una mezcla desordenada de presión empresarial, sentimientos del equipo y política de oficina. Para ayudarnos a entender esto, crearon un "menú" (una taxonomía) de las razones que la gente utiliza para tomar estas decisiones.

Aquí está el desgrecado de sus hallazgos, utilizando analogías simples:

1. Las dos caras de la misma moneda

El artículo destaca que contraer deuda (el atajo) y pagar la deuda (arreglar el desastre) son dos conversaciones muy diferentes, aunque hablen de lo mismo.

  • Adquisición (Tomar el atajo): Piensa en esto como un "Permiso Escrito". El equipo está preguntando: "¿Está bien si nos saltamos el aislamiento por ahora?". Las razones que utilizan son como permisos que dicen: "Sí, adelante, ¡porque el bebé nace mañana!".
  • Reembolso (Arreglar el desastre): Piensa en esto como una "Solicitud de Autorización". El equipo está preguntando: "¿Podemos dejar de construir la nueva cocina para arreglar el aislamiento del ático?". Esto es mucho más difícil. Necesitan un "Sí" del jefe para dejar de hacer trabajo nuevo y empezar a arreglar problemas viejos.

2. Las seis familias de razones (La taxonomía)

Los investigadores entrevistaron a 11 profesionales del software en Brasil y descubrieron que todos utilizan seis tipos principales de razones para tomar estas decisiones. Piensa en estas como seis diferentes "lentes" a través de los cuales ven el problema:

  1. Valor orientado a los interesados (La "Sonrisa del Cliente"):

    • Qué es: ¿Estará contento el cliente? ¿Se lanzará el producto a tiempo?
    • La analogía: Si el atajo deja la casa lista para la fiesta de cumpleaños de la familia, es un "Sí". Si el mal aislamiento hace que la casa sea demasiado fría para los invitados, es un "¡Arréglalo ahora!".
  2. Presión de entrega y recursos (El "Reloj en Cuenta Regresiva"):

    • Qué es: Plazos, presupuesto y qué tan cansado está el equipo.
    • La analogía: "Tenemos que mudarnos el viernes, así que no podemos esperar por el aislamiento". Pero luego, "No podemos arreglar el aislamiento porque estamos demasiado ocupados pintando las paredes".
  3. Integridad técnica y riesgo sistémico (La "Solidez Estructural"):

    • Qué es: ¿Se va a derrumbar el código (o la casa)? ¿Es seguro?
    • La analogía: "Si no arreglamos los cimientos, toda la casa podría caerse". Este es el discurso del ingeniero. Pero a menudo, el jefe solo escucha si la casa realmente está temblando, no solo porque el ingeniero dice que podría temblar.
  4. Base de decisión y estilo epistémico (La "Prueba vs. Intuición"):

    • Qué es: ¿Cómo sabemos que esta es la decisión correcta? ¿Tenemos datos o solo estamos adivinando?
    • La analogía: Tomar un atajo suele basarse en una "intuición" o urgencia ("Siento que podemos hacer esto"). Pagar la deuda a menudo requiere "pruebas sólidas" ("Mira este gráfico que muestra que la casa pierde calor cada día").
  5. Gobernanza y legitimación (La "Política de Oficina"):

    • Qué es: ¿Quién tiene el poder de decir "Sí"? ¿Está esta decisión permitida por las reglas de la empresa?
    • La analogía: Puede que sepas que necesitas arreglar el techo, pero si el propietario (la organización) no ha firmado el papeleo, no puedes hacerlo. Tienes que convencerlos de que es un gasto válido.
  6. Sostenibilidad humana y del equipo (El "Estado de Ánimo del Equipo"):

    • Qué es: ¿Se está agotando el equipo? ¿Están frustrados?
    • La analogía: "Si no arreglamos este techo con goteras, los trabajadores renunciarán porque están hartos de mojarse". A veces, arreglar la deuda es simplemente para mantener al equipo feliz y trabajando eficientemente.

3. El gran descubrimiento: La brecha entre "Permiso" y "Autorización"

Lo más importante que encontró el artículo es que es mucho más fácil obtener permiso para tomar un atajo que obtener autorización para arreglarlo.

  • ¿Por qué? Cuando tomas un atajo, estás prometiendo un problema futuro para obtener una victoria presente (como un cliente feliz o cumplir un plazo). El "Permiso Escrito" es fácil de firmar porque la recompensa es inmediata.
  • La trampa: Cuando intentas arreglar la deuda más tarde, estás pidiendo dejar de hacer trabajo nuevo y emocionante para arreglar problemas viejos e invisibles. La "Autorización" es difícil de obtener porque la recompensa es invisible (prevenir un desastre futuro) y el costo es inmediato (detener el progreso actual).

4. Cómo ocurren realmente las decisiones

El artículo sugiere que estas razones no solo se quedan en una lista. Pasan por un proceso para convertirse en una decisión real:

  1. Interpretación: Alguien tiene que decidir qué significa un problema (por ejemplo, "¿Es un error de código o es un riesgo de negocio?").
  2. Traducción: El equipo técnico tiene que explicar el problema en lenguaje de negocios (por ejemplo, en lugar de decir "La base de datos es lenta", dicen "Los clientes se irán si el sitio es lento").
  3. Legitimación: Finalmente, la organización tiene que acordar que esta es una razón válida para gastar tiempo y dinero.

Resumen

Este artículo no ofrece una fórmula para saber cuánta deuda tomar. En su lugar, nos da un mapa de la conversación que ocurre en los equipos de software. Muestra que decidir tomar atajos o arreglarlos no es solo cuestión de "buen código" frente a "mal código". Es una danza compleja entre plazos, clientes felices, trabajadores cansados y política de oficina.

La idea principal es que somos muy buenos justificando los atajos (porque las razones son ruidosas e inmediatas), pero somos muy malos justificando los arreglos (porque las razones son silenciosas y enfocadas en el futuro). Comprender esta brecha ayuda a los equipos a tener conversaciones mejores y más honestas sobre su deuda técnica.

¿Ahogado en artículos de tu campo?

Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.

Probar Digest →