Módulo 5 — Presupuesto y control: costo, tiempo y contexto

7. Velocidad real contra velocidad percibida

Siguiente →

Descripción

Al terminar esta lección vas a poder tomar los datos que ya vienes registrando desde la lección 2 (costo por tarea) y la lección 6 (condiciones de parada) y convertirlos en un solo número defendible: el costo total hasta código integrado. Vas a poder presentar ese número ante tu equipo o ante quien te pida cuentas —un jefe, un comité de presupuesto, una revisión trimestral— sin caer en la promesa vacía del multiplicador ("somos 3x más productivos con IA"), que suena bien en una diapositiva y se derrumba en la primera pregunta incómoda. Y vas a poder explicar, con precisión y sin miedo a la incomodidad, qué dice hoy la evidencia pública sobre agentes de código y productividad, y qué parte de esa evidencia sigue genuinamente en disputa.

Esto importa porque en algún momento alguien con poder de decisión te va a hacer la pregunta directa: "¿cuánto nos ahorra usar agentes?" Responder con un titular de blog ajeno —o peor, con una cifra inventada porque "se siente" que estás yendo más rápido— es exactamente el error que el Módulo 1 ya te enseñó a temer: la sensación de velocidad y la velocidad medida no siempre apuntan en la misma dirección. Aquí no vas a repetir esa lección. Vas a usar los números que ya instrumentaste en este módulo para responder esa pregunta con algo que sobrevive el escrutinio seis meses después, cuando alguien pida ver los datos otra vez.

Conexión con el módulo: cada lección anterior te dio una pieza —cuánto cuesta una tarea en dólares e iteraciones (lección 2), por qué el contexto largo encarece una conversación (lección 3), cuándo el modelo caro se paga solo (lección 4), cuándo cortar antes de que una tarea se coma la tarde (lección 6)—. Esta lección no agrega un instrumento nuevo: te enseña a sumar los que ya tienes en un número único, y a comunicarlo con la misma honestidad con la que lo mediste.

El costo no termina cuando el agente termina de escribir

Un pastelero saca un pastel del horno. Se ve perfecto: parejo, dorado, con la superficie firme. Lo manda a la vitrina y lo marca como terminado en su lista de pedidos del día. Dos horas después, el centro se hunde —no había terminado de cocinarse por dentro— y el cliente lo devuelve. El pastelero tiene que hacer otro, desde cero.

¿Cuánto costó ese pedido? No lo que costó el segundo pastel, el que sí llegó a la mesa del cliente. El primero también gastó harina, huevos, cuarenta minutos de horno encendido y la mano de obra de quien lo decoró antes de mandarlo a la vitrina. Ese gasto es real, ocurrió, y no desaparece porque el pastel que lo generó nunca llegó a la mesa. El costo real del pedido es la suma de las dos hechuras, aunque en la lista de pedidos del pastelero solo quede registrada la segunda como "entregada".

Una tarea delegada a un agente de código deja el mismo rastro cuando algo no sale a la primera. El agente puede entregar algo que se ve terminado —los tests pasan, el diff se ve razonable— y ese resultado, igual que el pastel recién horneado, todavía no pasó la prueba que de verdad importa: seguir en pie, integrado y estable, días después. Si ese primer intento se abandona porque disparó una de las condiciones de parada de la lección anterior —la misma corrección repetida, el diff que crece sin que el problema se mueva—, su costo no desaparece del total solo porque no fue el intento que terminó mergeado. El costo total hasta código integrado es la suma de todos los intentos que llevaron hasta ahí, no solo el último.

Esto no es una variación cosmética de "tiempo hasta el merge estable", el concepto que ya viste en el módulo anterior de esta guía. Es el mismo principio aplicado hacia atrás en el tiempo, no solo hacia adelante: así como el costo de una tarea sigue corriendo después del merge (mientras esperas ver si vuelve como incidente), también corre antes del merge, en cualquier intento abandonado que consumió tokens reales y minutos reales de tu atención antes de que decidieras cambiar de estrategia.

Ejemplo trabajado completo

Vamos a construir el número con una tarea real, extendiendo el mismo hábito de registro de la lección 2 —un archivo CSV que ya vienes llenando— con una columna que todavía no habías necesitado: a qué tarea pertenece cada intento, para poder sumarlos aunque hayan ocurrido en sesiones distintas, con modelos distintos, en días distintos.

La tarea: "El endpoint de exportación de reportes falla de forma intermitente bajo carga; no hay patrón visible en los logs."

Intento 1 — Sonnet 5, mismo día. Después de la segunda corrección que ataca el mismo síntoma sin resolverlo —la señal de bucle improductivo de la lección anterior—, se dispara el límite duro de tres iteraciones que definiste de antemano. La decisión, siguiendo las cuatro opciones de esa misma lección, es cambiar de modelo. El intento se abandona sin código integrado.

Intento 2 — Opus 4.8, sesión nueva. Como viste en la lección 4, escalar a mitad de una conversación invalida el descuento de caché de esa conversación, así que conviene cerrar la sesión anterior y arrancar una nueva directamente con el modelo más capaz. Esta vez el agente encuentra que el fallo ocurre solo cuando dos workers procesan el mismo reporte en paralelo y pisan el mismo archivo temporal. El fix se integra y no vuelve a fallar en los diez días siguientes.

Así se ve el registro, con un task_id compartido que amarra ambos intentos a la misma tarea real:

task_id,task_type,model,cost_usd,iterations,review_minutes,rework_minutes,status
BUG-207,bug-fix-small,sonnet-5,0.34,2,4,0,integrated
RPT-114,report-export-fix,sonnet-5,0.42,3,14,0,abandoned
RPT-114,report-export-fix,opus-4.8,0.68,2,20,0,integrated

(BUG-207 es una tarea de un solo intento, para que veas el contraste. Los números son una muestra inventada para ilustrar el método —los tuyos van a verse distintos.)

Un script corto, extendiendo el que ya usaste en la lección 2, suma todos los intentos por task_id y convierte los minutos humanos en dólares usando una tarifa cargada —una hipótesis que declaras de entrada, no un número universal—:

# total_cost_until_integrated.py
# Suma TODOS los intentos de una misma tarea -integrados o abandonados-
# y expresa el costo total en un solo número, en dólares.
import csv
from collections import defaultdict

HOURLY_RATE_USD = 75.0  # hipótesis de tarifa cargada de un ingeniero; ajusta a tu propio equipo


def load_attempts(path: str) -> list[dict]:
    """Lee el registro de intentos, uno por fila, amarrados por task_id."""
    with open(path, newline="", encoding="utf-8") as f:
        return list(csv.DictReader(f))


def total_cost_until_integrated(rows: list[dict], hourly_rate: float = HOURLY_RATE_USD) -> dict:
    """Agrupa por task_id y suma todos los intentos, sin importar su status."""
    totals = defaultdict(
        lambda: {"cost_usd": 0.0, "human_minutes": 0.0, "task_type": None, "attempts": 0}
    )
    for row in rows:
        task_id = row["task_id"]
        totals[task_id]["cost_usd"] += float(row["cost_usd"])
        totals[task_id]["human_minutes"] += float(row["review_minutes"]) + float(row["rework_minutes"])
        totals[task_id]["task_type"] = row["task_type"]
        totals[task_id]["attempts"] += 1

    summary = {}
    for task_id, data in totals.items():
        human_cost = (data["human_minutes"] / 60) * hourly_rate
        summary[task_id] = {
            "task_type": data["task_type"],
            "attempts": data["attempts"],
            "token_cost_usd": round(data["cost_usd"], 2),
            "human_cost_usd": round(human_cost, 2),
            "total_cost_usd": round(data["cost_usd"] + human_cost, 2),
        }
    return summary


if __name__ == "__main__":
    rows = load_attempts("task-lifecycle.csv")
    summary = total_cost_until_integrated(rows)
    for task_id, stats in sorted(summary.items()):
        print(
            f"{task_id:10s} {stats['task_type']:20s} attempts={stats['attempts']} "
            f"tokens=${stats['token_cost_usd']:.2f} humano=${stats['human_cost_usd']:.2f} "
            f"total=${stats['total_cost_usd']:.2f}"
        )

Comando:

python total_cost_until_integrated.py

Qué esperar:

BUG-207    bug-fix-small        attempts=1 tokens=$0.34 humano=$5.00 total=$5.34
RPT-114    report-export-fix    attempts=2 tokens=$1.10 humano=$42.50 total=$43.60

RPT-114 costó más de ocho veces lo que costó BUG-207, y esa diferencia no viene principalmente de los tokens —$1.10 contra $0.34, apenas tres veces más—. Viene de que fueron dos sesiones completas de atención humana en vez de una, y de que el intento abandonado no dejó de costar solo porque no llegó a la mesa del cliente. Si hubieras reportado el costo de esta tarea usando únicamente la sesión que sí funcionó —$0.68 en tokens más los 20 minutos de revisión de esa sesión, unos $25.68 en total— habrías subestimado el costo real en más del 40%. Ese es exactamente el error que la siguiente sección te enseña a no cometer cuando presentas este número hacia afuera.

Cómo presentarlo sin la promesa vacía del multiplicador

Una diapositiva dice: "Este trimestre adoptamos agentes de código. El equipo es 3x más productivo." Suena bien, es corta, y es exactamente el tipo de afirmación que no sobrevive la primera pregunta seria: ¿3x de qué línea base, medida cómo? ¿Ese 3x es el promedio de qué tareas, y qué pasó con las que no mejoraron? ¿Alguien puede repetir ese cálculo con los datos crudos? Si la respuesta a cualquiera de esas preguntas es "no sé" o "no lo anotamos", la cifra no es un dato: es una promesa vacía, y el día que alguien la ponga a prueba —un feature que salió más caro, no más barato, como viste que puede pasar en la lección 2— esa cifra se lleva tu credibilidad con ella.

La alternativa no es más difícil de construir; es solo más honesta, y ya tienes los tres ingredientes de este módulo para armarla:

  • Repórtalo por tipo de tarea, nunca como un promedio único. Mezclar un renombre mecánico con un feature de especificación floja en el mismo "3x" esconde exactamente la varianza que la lección 4 te enseñó a distinguir. Usa la tabla de costo por tipo de tarea que ya vienes construyendo.
  • Declara tus supuestos junto con el número. La tarifa cargada que usaste para convertir minutos en dólares, la ventana de estabilidad que exigiste antes de contar una tarea como "integrada", el tamaño de tu muestra (n). Sin esos tres datos, nadie más puede reproducir tu cálculo, y un número que no se puede reproducir no se puede defender.
  • Compara contra tu propia línea base, no contra un promedio de internet. El mismo error que la lección 2 nombró para comparar costos entre tareas aplica acá para comparar "antes" contra "después": tu línea base es el registro de trabajo manual del Módulo 1, no una cifra de un caso de estudio ajeno con otro código, otro equipo y otra especificación.
  • Muestra también las categorías que no mejoraron. Si una categoría de tarea salió más cara —no más barata— una vez sumado el retrabajo, dilo. Es exactamente la clase de honestidad que distingue un reporte creíble de una promesa de marketing, y es más fácil defenderla en la siguiente revisión que explicar por qué el número de la vez pasada no se sostuvo.

Así se ve la diferencia con datos reales del ejemplo anterior, más el registro de la lección 2:

Tipo de tareanCosto total antes (estimado, línea base del Módulo 1)Costo total hoy (medido, con agente)Cambio
bug-fix-small8~$45$5.34 promedio-88%
code-review-pass6~$60$12.06 promedio-80%
feature-new5~$80$35.90 promedio, con retrabajo activo-55%, vigilar de cerca
refactor-module4~$70$19.15 promedio-73%

Tarifa cargada usada: $75/hora. Ventana de estabilidad: dos semanas sin reversión. La columna "antes" es un estimado manual de tu propio registro del Módulo 1, no medido con el mismo rigor que la columna "hoy" —nombrar ese sesgo explícitamente, en vez de esconderlo, es justamente lo que el proyecto de la siguiente lección te va a pedir hacer con más cuidado.

Esta tabla no dice "somos 3x más rápidos". Dice algo más útil y más defendible: en tres de cuatro tipos de tarea el costo total bajó de forma sustancial, y en el cuarto bajó también pero con una señal de retrabajo que merece seguimiento antes de declarar victoria. Esa frase, con la tabla detrás, sobrevive la pregunta incómoda. El "3x" solo, sin la tabla, no.

Qué dice la evidencia pública, y qué sigue en disputa

Ya viste en el módulo 1 el hallazgo más citado sobre esta brecha: el estudio de METR donde desarrolladores experimentados terminaron 19% más lentos con IA mientras seguían convencidos de haber sido 20% más rápidos. Lo que no viste ahí —y vale la pena mirar de cerca antes de citar ese número en una conversación seria— es lo que el propio estudio dice sobre sus límites, porque ahí está la clave de por qué la evidencia pública, en su conjunto, es contradictoria.

Los autores de METR fueron explícitos: su muestra fue de 16 desarrolladores trabajando sobre repositorios open source grandes y maduros —más de 22.000 estrellas y un millón de líneas de código en promedio—, con tareas reales de dos horas de duración típica. Ellos mismos advierten que su resultado no demuestra que "los sistemas de IA actuales no aceleran a la mayoría de los desarrolladores" en general: es, en sus propias palabras, una fotografía de las capacidades de la IA de comienzos de 2025 en un entorno particular. Advierten además que no pueden descartar efectos de aprendizaje más allá de las 50 horas de uso de la herramienta específica que estudiaron, y que la IA probablemente rinde peor justo en el tipo de entorno que eligieron: código con estándares de calidad muy altos y muchos requisitos implícitos que a un humano le toma tiempo aprender —exactamente el perfil de un repositorio open source grande y viejo, no el de cualquier tarea de programación.

Contrasta eso con el estudio aleatorizado original de GitHub sobre Copilot: desarrolladores completaron una tarea acotada y bien especificada —escribir un servidor HTTP en JavaScript— un 55% más rápido con la herramienta. Es una cifra real, de un experimento controlado real, y apunta en la dirección exactamente opuesta a la de METR. La diferencia no es que uno de los dos estudios esté mal hecho: es que miden perfiles de tarea completamente distintos. Un servidor HTTP desde cero, con un criterio de éxito cerrado, es el terreno donde un agente rinde mejor, como ya viste en la lección 4 de este módulo. Depurar un fallo intermitente en un millón de líneas de código ajeno, con requisitos implícitos que nadie escribió, es el terreno opuesto.

El reporte 2025 de DORA agrega un matiz más, y distinto al de la edición 2024 que ya citaste en el módulo anterior: mientras el reporte de 2024 encontraba una mejora percibida a nivel individual junto con una caída medida en la estabilidad de equipo, la edición 2025 encuentra que la adopción de IA se asocia con una mejora medida —no solo percibida— en el throughput de entrega y en el desempeño del producto. La caída en la estabilidad de entrega, sin embargo, se mantiene. Y el propio reporte nombra qué separa a los equipos que ganan de los que pierden: no es el modelo que usan, es si tienen arquitecturas desacopladas, ciclos de retroalimentación rápidos y pruebas automatizadas robustas — el marco que el reporte llama "la IA como amplificador": magnifica la fuerza o la debilidad que el equipo ya tenía, no la reemplaza.

Ahí está lo que de verdad está en disputa, y no es "¿la IA ayuda o no ayuda?" —esa pregunta ya no tiene sentido plantearla así—. Lo que está en disputa es de qué depende el resultado, y la evidencia pública apunta, de forma consistente entre estudios que en apariencia se contradicen, a tres variables: qué tan cerrado es el perfil de la tarea (lección 4), qué tan maduras son las prácticas de especificación y verificación del equipo que la ejecuta (módulos 2 y 4 de esta guía), y qué generación de modelo se está usando en el momento del estudio —algo que cambia más rápido de lo que cualquier estudio puede repetirse—. Ninguno de esos tres factores es igual entre tu equipo y los 16 desarrolladores de repositorios open source de METR, ni entre tu equipo y los participantes del experimento de GitHub. Por eso nadie te puede dar, hoy, un número universal de "cuánto más rápido es trabajar con agentes": existe el número de METR, existe el número de GitHub, existe el de DORA, y los tres son reales y a la vez incompletos para tu caso, porque ninguno midió tu tarea, tu equipo ni tu disciplina de especificación.

La respuesta honesta que le das a tu jefe cuando te pida ese número universal no es citar el estudio que más te convenga. Es decirle que ese número no existe en abstracto —existe el tuyo, medido con tu propia tabla, como la que construiste en la sección anterior—.

Errores comunes

Reportar un multiplicador agregado que mezcla tipos de tarea muy distintos (conceptual). Qué pasa: alguien calcula "3x más rápido" dividiendo el costo total de todas las tareas del trimestre, sin distinguir un renombre mecánico de un feature con especificación floja, y presenta ese único número como si describiera cualquier tarea futura. Por qué ocurre: un promedio agregado es más fácil de citar en una diapositiva que una tabla con cuatro filas, aunque la tabla sea la que de verdad describe lo que pasó. Cómo detectarlo: si nadie puede decirte cuál fue el tipo de tarea que peor rindió dentro de ese promedio, el número está escondiendo su propia varianza. Cómo corregirlo: reporta siempre por tipo de tarea, con su propio n, como en la tabla de la sección anterior; el promedio agregado, si alguien lo pide, es un resumen derivado de esa tabla, no el dato principal.

Resolver la "contradicción" citando solo el estudio que conviene, en vez de explicar qué los distingue (conceptual). Qué pasa: frente a un escéptico, alguien cita solo el 55% de GitHub para justificar más inversión en agentes; frente a un comité cauteloso, alguien cita solo el 19% de METR para frenarla. En los dos casos se usa la cifra como arma retórica, no como evidencia completa. Por qué ocurre: es más rápido citar un número que explicar por qué dos estudios reales, bien hechos, midieron cosas distintas —perfil de tarea, madurez de prácticas, generación de modelo—. Cómo detectarlo: si en la conversación nunca se menciona qué tipo de tarea o qué población midió el estudio citado, se está usando la cifra sin su contexto. Cómo corregirlo: cuando cites cualquiera de estos estudios, nombra en la misma frase el perfil de tarea o población que midió —"en tareas bien especificadas como esta, la evidencia de GitHub..."—, no la cifra sola.

Calcular el costo total hasta integrado usando solo la sesión que funcionó, olvidando los intentos abandonados (práctico). Qué pasa: al reportar cuánto costó una tarea, se toma el costo de la sesión final —la que sí llegó a producir código integrado— y se ignoran los intentos anteriores que se abandonaron por haber disparado una condición de parada de la lección anterior. Por qué ocurre: esos intentos no dejaron código en el repositorio, así que se sienten como si no hubieran "contado", aunque consumieron tokens y minutos reales. Cómo detectarlo: si tu registro de costo por tarea no tiene una columna que amarre varios intentos al mismo task_id, no tienes forma de sumar los abandonados. Cómo corregirlo: usa un identificador de tarea compartido entre intentos, como en el ejemplo trabajado, y suma todos los intentos —integrados o no— antes de reportar el costo de esa tarea.

Ejercicios

Ejercicio 1. Una tarea (AUTH-88, tipo auth-bug-fix) tuvo dos intentos: el primero con Sonnet 5 costó $0.51 en tokens, con 10 minutos de revisión y 0 de retrabajo, y se abandonó al disparar el límite de iteraciones de la lección anterior. El segundo, con Opus 4.8 en una sesión nueva, costó $0.94 en tokens, con 16 minutos de revisión y 0 de retrabajo, y sí se integró. Calcula el costo total hasta código integrado de esta tarea usando una tarifa cargada de $60 por hora.

Ver solución

Costo en tokens: $0.51 + $0.94 = $1.45.

Minutos humanos totales: (10 + 0) + (16 + 0) = 26 minutos = 26/60 = 0.4333 horas.

Costo humano: 0.4333 × $60 = $26.00.

Costo total hasta integrado: $1.45 + $26.00 = $27.45.

Por qué funciona: el costo total suma ambos intentos —el abandonado y el integrado— porque los dos consumieron tokens y atención real antes de llegar al resultado final. Reportar solo el segundo intento ($0.94 en tokens más $16.00 de revisión, $16.94 en total) habría subestimado el costo real en casi un 40%, el mismo error que viste en el ejemplo trabajado con RPT-114.

Ejercicio 2. Un equipo mide, por tipo de tarea, el cambio de costo tras adoptar agentes: bug-fix-small -80%, code-review-pass -75%, feature-new +10% (más caro que antes, por retrabajo). En su reporte trimestral escriben: "Adoptamos agentes de código este trimestre. En promedio, el equipo es 3x más rápido." ¿Qué error de esta lección comete esa afirmación, y cómo la reescribirías?

Ver solución

Comete el error de reportar un multiplicador agregado que mezcla tipos de tarea muy distintos. El "3x" promedia tres categorías que mejoraron con una que empeoró, y esconde exactamente la categoría que más necesita atención —feature-new, que salió 10% más caro, no más barato, una vez contado el retrabajo—. Cualquiera que reciba ese reporte y luego descubra el detalle de feature-new va a desconfiar de todo el resto del número, con razón.

Una reescritura honesta: "Adoptamos agentes de código este trimestre. En bug-fix-small y code-review-pass, el costo total bajó 80% y 75% respectivamente (n=8 y n=6). En refactor-module bajó de forma similar. En feature-new, en cambio, el costo total subió 10% frente a nuestra línea base, por retrabajo posterior a tareas con especificación floja; estamos revisando cómo especificar mejor esa categoría antes de delegarla, siguiendo lo que vimos en el módulo de especificación." Es más larga, pero cada frase sobrevive la pregunta "¿cómo lo mediste?".

Por qué funciona: una afirmación desglosada por categoría, con las que no mejoraron incluidas, no puede ser desmentida por un solo caso —ya reconoce por adelantado que existe, y explica qué se está haciendo al respecto.

Ejercicio 3. Un colega te dice: "Leí que METR encontró que los desarrolladores son 19% más lentos con IA, así que no tiene sentido que sigamos invirtiendo en esto." En tres o cuatro frases, explica por qué ese estudio y el hallazgo de 55% más rápido del experimento original de GitHub Copilot no se contradicen realmente, y qué determina de qué lado cae el trabajo de tu propio equipo.

Ver solución

No se contradicen porque midieron perfiles de tarea casi opuestos: GitHub midió una tarea acotada y bien especificada desde cero (escribir un servidor HTTP), el terreno donde un agente rinde mejor; METR midió a desarrolladores experimentados navegando repositorios open source grandes, maduros, con muchos requisitos implícitos —el terreno donde, según los propios autores de METR, la IA rinde peor—. Los autores de METR incluso advierten explícitamente que su resultado no muestra que la IA no acelere a la mayoría de los desarrolladores; es una fotografía de un entorno particular. Lo que determina de qué lado cae el trabajo de tu propio equipo no es cuál estudio "tiene razón", sino qué tan cerrado es el perfil de tus tareas y qué tan maduras son tus propias prácticas de especificación y verificación —las mismas variables que el reporte DORA 2025 señala como las que separan a los equipos que ganan de los que pierden con IA.

Por qué funciona: tratar la pregunta como "¿cuál estudio es el correcto?" ignora que ambos son correctos para lo que midieron; la pregunta útil es "¿mi trabajo se parece más a la tarea de GitHub o a la de METR?", y esa solo la responde tu propia tabla, no un titular ajeno.

Resumen y siguiente paso

Aprendiste a convertir los datos que ya instrumentaste —costo por tarea de la lección 2, condiciones de parada de la lección 6— en un solo número defendible: el costo total hasta código integrado, que incluye los intentos abandonados y no solo el que llegó a la mesa. Aprendiste a presentar ese número por tipo de tarea, con tus supuestos declarados y comparado contra tu propia línea base, en vez de arriesgar tu credibilidad en un multiplicador único que no sobrevive la primera pregunta incómoda. Y viste que la evidencia pública —METR, el experimento original de GitHub Copilot, DORA 2025— no es contradictoria por error de nadie: mide perfiles de tarea y niveles de madurez distintos, y ese es exactamente el motivo por el que no existe un número universal que puedas pedir prestado. Existe el tuyo, y ya sabes cómo calcularlo.

Antes de avanzar deberías poder: tomar el registro de una tarea con varios intentos y calcular su costo total hasta integrado sumando todos los intentos, no solo el exitoso; señalar el error en un reporte que promedia tipos de tarea muy distintos en un solo multiplicador; y explicar en tres frases, sin citar un solo titular, por qué dos estudios públicos que parecen contradecirse en realidad están midiendo cosas distintas.

Lo que hiciste aquí —convertir instrumentación cruda en un número defendible— es exactamente lo que el proyecto de cierre de este módulo te va a pedir hacer de forma sistemática: cinco tareas reales, con este mismo criterio, incluyendo la re-medición de dos tareas del Módulo 1 con la disciplina que ya tienes ahora y que no tenías entonces —y nombrando, sin esconderlo, el sesgo que esa comparación arrastra desde su propia línea base.

Recursos

← Anterior6. Condiciones de parada y límites de gastoSiguiente →8. Proyecto: flujo instrumentado con presupuesto