Costes: presupuesto, TCO y valor ganado (EVM)
De dónde sale el dinero que cuesta un proyecto software, cómo se convierte una estimación en presupuesto, cómo saber a mitad de camino si vas bien de coste y de plazo con tres números, y cómo cambia todo esto en ágil.
- Enumerar los costes de un proyecto software y explicar qué es el coste total de propiedad (TCO).
- Construir un presupuesto con la cadena trabajo → esfuerzo → recursos → coste, y explicar por qué estimación ≠ presupuesto ≠ coste real.
- Calcular e interpretar PV, EV, AC, CV, SV, CPI, SPI y las previsiones EAC, ETC y VAC.
- Estimar el coste en ágil (capacidad del equipo) y comparar las dos lógicas.
Tema 2, diap. 47-54. Uno de los objetivos del tema es "entender cómo se realizan los cálculos de costes". El valor ganado es el candidato número uno a pregunta de cálculo + interpretación ("calcula CPI y SPI e interprétalos", está en la misión). Ampliación: CV, SV, EAC, ETC, VAC, TCPI (las diapositivas sólo dan PV, EV, AC, CPI, SPI), tipos de costes y TCO. Ojo: la diap. 52 escribe "EMV" donde debe decir EVM (Earned Value Management). EMV es el valor monetario esperado de los riesgos (lección 13).
1. Qué significa gestionar el coste
El objetivo: asegurar que el proyecto utiliza los recursos económicos de forma sostenible para conseguir el valor esperado. Fíjate en las dos últimas palabras: no es "gastar lo menos posible", es conseguir el valor con un gasto sostenible. Las actividades principales:Tema 2, diap. 48. PMBOK 7.
- Estimar costes
- Presupuestar el proyecto
- Asignar y controlar recursos
- Medir el coste real y el progreso
- Prever el coste final
- Tomar decisiones ante desviaciones
La idea de fondo, que cierra el bloque en las diapositivas: la gestión del coste consiste en tomar decisiones económicas informadas, no simplemente en gastar menos.Tema 2, diap. 54. Recortar pruebas para ahorrar es "gastar menos" hoy y pagar mucho más mañana (lección 1, coste del error).
2. Cuáles son los costes
Las diapositivas los enumeran así:Tema 2, diap. 49.
- Personas → el principal coste en muchos proyectos software.
- Infraestructura y herramientas, incluidos cloud y servicios externos (APIs de pago, licencias).
- Pruebas, integración y despliegue (entornos, dispositivos de prueba, pipelines).
- Seguridad y cumplimiento (auditorías, pentesting, evaluación de impacto de protección de datos).
- Mantenimiento y operación.
- Cambios y trabajo (retrabajo, gestión de cambios).
Clasificaciones clásicas útiles (ampliación):
| Clasificación | Tipos | TusBus |
|---|---|---|
| Por imputación | Directos (atribuibles al proyecto) / indirectos (compartidos: oficina, dirección, RR. HH.) | Directo: sueldos del equipo, API de mapas. Indirecto: alquiler de la oficina de la consultora |
| Por comportamiento | Fijos (no varían con el volumen) / variables (crecen con el uso) | Fijo: licencia anual del IDE. Variable: coste cloud por petición en hora punta |
| Por naturaleza contable | CAPEX (inversión) / OPEX (gasto operativo) | Comprar servidores = CAPEX; pagar cloud mensual = OPEX |
Coste total de propiedad (TCO)
Las diapositivas lo dicen en una frase: el coste de desarrollar una funcionalidad no es necesariamente su coste total de propiedad. El TCO (Total Cost of Ownership) suma todo lo que cuesta algo a lo largo de toda su vida: desarrollo + infraestructura + operación + mantenimiento + soporte + formación + seguridad + retirada.
En software, el mantenimiento y la evolución suelen costar más que el desarrollo inicial a lo largo de la vida del sistema.Ampliación. Sommerville, Software Engineering, 10ª ed., cap. 9 "Software evolution". Por eso:
- Una funcionalidad "barata de hacer" puede ser cara de mantener (el modo oscuro animado del gold plating, lección 3).
- La deuda técnica (lección 8) es un coste: sus "intereses" son el sobrecoste de cada cambio futuro.
- En el estudio de viabilidad económica (lección 6) hay que comparar beneficios con el TCO, no sólo con el desarrollo.
3. Estimar el coste en un proyecto tradicional
En un proyecto predictivo, normalmente se intenta estimar el coste global antes de comenzar la ejecución, con esta cadena:Tema 2, diap. 50. Hughes, Cotterell y Mall (2017), Software Project Management, 6ª ed.
El ejemplo de las diapositivas:
| Recurso | Esfuerzo | Coste/h | Coste |
|---|---|---|---|
| Analista | 120 h | 40 € | 4.800 € |
| Desarrollador | 600 h | 35 € | 21.000 € |
| Tester | 180 h | 30 € | 5.400 € |
| Infraestructura | — | — | 3.000 € |
| Total | 34.200 € | ||
De dónde sale cada columna: el trabajo es la EDT (lección 9); el esfuerzo, la estimación de cada paquete (lección 10); el coste/h es el coste para la empresa (salario + cargas sociales + parte de indirectos), no el sueldo neto de la persona.
Estimación ≠ presupuesto ≠ coste real
El aviso de las diapositivas: los 34.200 € son una estimación. La incertidumbre debe reflejarse mediante reservas y contingencias (lección 13):
La línea base de costes (lección 9) es la referencia contra la que se mide: es el BAC (Budget at Completion) que usa el valor ganado. Y se reparte en el tiempo según el cronograma, formando la típica curva en S de coste acumulado (lento al principio, rápido en el centro, lento al final).
4. Controlar el coste: valor ganado (EVM)
El presupuesto sólo es útil si podemos comprobar cómo evoluciona el proyecto respecto a lo previsto. Cuatro preguntas:Tema 2, diap. 51-52. Fleming y Koppelman (2016), Earned Value Project Management, 4ª ed., PMI.
- ¿Cuánto trabajo hemos realizado? → EV
- ¿Cuánto nos ha costado? → AC
- ¿Cuánto deberíamos haber gastado (hasta hoy, según el plan)? → PV
- ¿Cuánto esperamos gastar finalmente? → EAC
Por qué hace falta el valor ganado: mirar sólo "planificado vs. gastado" engaña. Si a mitad de proyecto has gastado exactamente lo planificado, ¿vas bien? Depende de cuánto trabajo has hecho con ese dinero. El EVM añade esa tercera dimensión.
Los tres valores básicos
| Sigla | Nombre | Pregunta | Cómo se obtiene |
|---|---|---|---|
| PV | Planned Value · valor planificado | ¿Cuánto trabajo debía estar hecho a hoy, en euros de presupuesto? | De la línea base: presupuesto del trabajo programado hasta hoy |
| EV | Earned Value · valor ganado | ¿Cuánto trabajo está hecho, en euros de presupuesto? | % realmente completado × BAC (o suma del presupuesto de los paquetes terminados) |
| AC | Actual Cost · coste real | ¿Cuánto hemos gastado de verdad? | De la contabilidad / partes de horas |
La clave: EV y PV se expresan en "euros de presupuesto", no en euros gastados. EV es "lo que el plan decía que costaría el trabajo que realmente hemos hecho".
Variaciones e índices
Regla mnemotécnica: todas empiezan por EV. Coste se compara con AC (lo gastado); plazo, con PV (lo planificado). Mayor que 1 (o positivo) = bien; menor que 1 (o negativo) = mal.
Previsiones
Las dos fórmulas de EAC reflejan dos hipótesis: BAC/CPI supone que la ineficiencia es estructural y seguirá (es la más usada y la más realista, porque los CPI rara vez mejoran mucho pasado el 20 % del proyecto); AC + (BAC − EV) supone que fue un hecho aislado. El TCPI muestra si recuperar es realista: un TCPI de 1,25 significa que, para acabar en presupuesto, el resto del proyecto tendría que ser un 25 % más eficiente que lo planificado. Casi nunca ocurre.
Ejemplo completo con TusBus
BAC = 120.000 €, 12 meses, gasto planificado lineal. Fin del mes 6:
- Según el plan, debería estar hecho el 50 % → PV = 60.000 €.
- Midiendo con criterios objetivos (paquetes terminados), está hecho el 45 % → EV = 0,45 × 120.000 = 54.000 €.
- Contabilidad: se han gastado AC = 66.000 €.
Interpretación (lo que de verdad se pregunta): el proyecto va por encima de coste y con retraso. Con CPI = 0,82, la previsión es un sobrecoste del 22 %; recuperarlo exigiría una eficiencia del 122 %, poco realista. La decisión de gestión (la "A" del PDCA, lección 11) no es "trabajar más": es buscar la causa (¿estimación inicial optimista? ¿retrabajo? ¿problemas con la API?) y decidir con el sponsor: usar reserva, recortar alcance (Could/Should), o aprobar una nueva línea base mediante control de cambios.
Los cuatro cuadrantes
| SPI ≥ 1 (en plazo o adelantado) | SPI < 1 (retrasado) | |
|---|---|---|
| CPI ≥ 1 (en coste o por debajo) | Todo bien | Barato pero lento: ¿falta gente? ¿bloqueos? |
| CPI < 1 (sobrecoste) | Rápido pero caro: ¿se está pagando para adelantar (horas extra, más personas)? | Lo peor: caro y lento. Acción urgente |
Cuidado con el EVM en software
Las diapositivas lo advierten: en software, estas métricas deben interpretarse con cuidado: medir "porcentaje completado" de funcionalidades puede generar una falsa sensación de precisión. El EVM es tan bueno como el EV, y el EV depende de cómo se mide el avance:
- Si el EV sale del "porcentaje" que dice cada desarrollador, el síndrome del 90 % (lección 11) infla el EV y el proyecto parece ir bien hasta el final.
- Remedio: reglas objetivas (0/100, 50/50, hitos ponderados) y paquetes de trabajo pequeños.
- Al final del proyecto, el SPI tiende a 1 siempre (cuando todo está hecho, EV = PV = BAC), aunque se haya terminado tarde. Para el plazo en la última parte, se usan técnicas complementarias (p. ej. earned schedule) o simplemente el camino crítico.Ampliación. Ver Earned value management, sección "Limitations".
- El EVM mide coste y plazo frente al plan, no el valor para el usuario: puedes tener CPI = 1 construyendo algo que nadie quiere.
5. El coste en ágil
En ágil, normalmente no se intenta fijar simultáneamente alcance, plazo y coste con precisión desde el principio. Se fija relativamente el equipo y la duración, lo que da la capacidad y el coste, y se adaptan el alcance y las prioridades.Tema 2, diap. 53. Cohn, M. (2005), Agile Estimating and Planning.
Es el "triángulo invertido" de la lección 7: en predictivo se fija el alcance y se estiman tiempo y coste; en ágil se fijan tiempo y coste y el alcance es la variable.
El ejemplo de las diapositivas: un equipo de 6 personas con un coste mensual de 30.000 € → un sprint de 2 semanas cuesta aproximadamente 15.000 €. Ampliándolo con la velocidad:
Y lo importante, el cambio de pensamiento: de "¿Cuánto costará exactamente todo el producto?" a "¿Qué valor podemos obtener con los recursos disponibles?". La prioridad del backlog determina qué se aborda primero: si el dinero se acaba en el sprint 8, se ha construido lo más valioso.
Tradicional frente a ágil
| Tradicional / predictivo | Ágil / adaptativo | |
|---|---|---|
| Presupuesto | Se estima inicialmente | Se relaciona con equipo y horizonte |
| Alcance | Intenta fijarse | Se prioriza y adapta |
| Planificación | Detallada inicialmente | Rolling wave / iterativa |
| Estimación | Horas, recursos, actividades | Story points, capacidad, velocidad |
| Control | Coste planificado vs. real | Coste por iteración + valor entregado |
| Cambios | Analizar impacto en presupuesto/plazo | Re-priorizar backlog |
| Pregunta clave | "¿Nos ajustamos al presupuesto?" | "¿Estamos obteniendo suficiente valor?" |
Tema 2, diap. 54. Fuentes: PMBOK 7; Cohn (2005); Forsgren, Humble y Kim (2018), Accelerate.Ojo con "velocidad": las diapositivas de personas avisan de "no confundir velocidad con capacidad futura" (lección 16). Que el equipo hiciera 30 puntos por sprint no garantiza 30 cuando cambie su composición o el tipo de trabajo.
- "CPI = AC / EV": al revés; es EV / AC. Todas empiezan por EV.
- "SPI > 1 significa que vamos retrasados": SPI > 1 = adelantados.
- "Si AC = PV, vamos bien de coste": no se sabe sin EV.
- "EV es el dinero que hemos ganado": es el presupuesto del trabajo realizado, no ingresos.
- "El coste del proyecto es el coste de desarrollarlo": falta el TCO (operación, mantenimiento, deuda…).
- "EMV y EVM son lo mismo": EMV = valor monetario esperado (riesgos); EVM = gestión del valor ganado (coste/plazo).
- "La reserva de gestión forma parte del BAC": el BAC es la línea base (incluye la de contingencia, no la de gestión).
Práctica
Empareja cada fórmula con lo que calcula.
- EV / AC
- EV / PV
- EV − AC
- EV − PV
- BAC / CPI
- EAC − AC
Usa estos datos para las cuatro preguntas siguientes. Proyecto con BAC = 200.000 €. Hoy: PV = 100.000 €, EV = 80.000 €, AC = 100.000 €.
¿Cuál es el CPI?
¿Cuál es el SPI?
¿Cuál es la EAC suponiendo que la eficiencia de coste actual se mantiene?
Fíjate en que en este proyecto AC = PV. Un directivo dice: "Hemos gastado exactamente lo planificado, así que vamos bien". ¿Qué le respondes?
- Tiene razón, porque el gasto real coincide exactamente con el plan
- Vamos bien de coste pero mal de plazo, porque el SPI es menor que 1
- Vamos mal en ambos: con ese gasto debíamos haber hecho más trabajo
- No se puede saber nada hasta que termine el proyecto y se cierre
Interpreta cada combinación.
- CPI = 1,1 · SPI = 1,2
- CPI = 0,85 · SPI = 0,9
- CPI = 0,9 · SPI = 1,15
- CPI = 1,05 · SPI = 0,8
Un equipo ágil de 5 personas cuesta 22.500 € al mes. Trabajan en sprints de 2 semanas (considera que un mes = 2 sprints) y su velocidad media es de 25 puntos por sprint. ¿Cuánto costaría un backlog de 50 puntos?
¿Qué costes forman parte del coste total de propiedad (TCO) de TusBus?
- El servidor cloud durante los cinco años de vida de la app
- Las horas de corrección de errores tras la publicación
- El desarrollo inicial de la app y del backend
- Las auditorías de seguridad y protección de datos
- El coste de los autobuses de la empresa municipal
¿Qué diferencia mejor la pregunta clave del control de costes en ágil frente al tradicional?
- Ágil: "¿cuántas horas llevamos?"; tradicional: "¿cuántos puntos?"
- Ágil: "¿cuánto costará todo?"; tradicional: "¿qué valor obtenemos?"
- Ágil: "¿cuál es el CPI?"; tradicional: "¿cuál es la velocidad?"
- Ágil: "¿obtenemos suficiente valor?"; tradicional: "¿nos ajustamos?"
Un proyecto lleva el 30 % y tiene CPI = 0,75. El JP dice al sponsor: "No os preocupéis, recuperaremos en lo que queda". ¿Qué le dirías, usando EAC y TCPI?
Repaso espaciado · lecciones 6, 10, 13
¿Qué parte del presupuesto está fuera de la línea base de costes?
- La reserva de gestión
- La reserva de contingencia
- Las estimaciones de los paquetes
- El coste de las personas
PERT: O = 6, M = 9, P = 18 semanas. ¿Cuál es la estimación?
Para profundizar
Earned value management (inglés: fórmulas, ejemplo y limitaciones). Para el enfoque de las diapositivas: Fleming y Koppelman (2016), Earned Value Project Management, PMI; y Cohn (2005), Agile Estimating and Planning, caps. sobre velocidad y planificación de releases. En el SWEBOK v4, la KA Software Engineering Economics cubre TCO y decisiones económicas.
El EVM se aprende haciendo: pide a un asistente cinco escenarios con BAC, PV, EV y AC, calcula CV, SV, CPI, SPI, EAC y VAC, e interprétalos en una frase cada uno. La interpretación es lo que más pesa en una respuesta corta.