Qué es (y qué no es) gestionar un proyecto software
Proyecto frente a operación, por qué el software es especial, las restricciones que compiten y qué significa de verdad "salir bien".
- Decidir si una actividad es un proyecto o una operación, y justificarlo con los rasgos de la definición.
- Explicar qué tiene el software que lo hace más difícil de gestionar que, por ejemplo, un edificio.
- Ante un conflicto entre alcance, plazo, coste y calidad, saber cuál es la respuesta de gestión correcta (y por qué las demás fallan).
- Argumentar si un proyecto ha tenido éxito o no más allá de "a tiempo y dentro del presupuesto".
Esta lección es el cimiento del curso. Todo lo que viene después (requisitos, riesgos, costes, calidad, DevOps) es una respuesta concreta a los problemas que aparecen aquí. Si entiendes bien por qué gestionar es difícil, el resto del temario deja de parecer una lista de técnicas y pasa a ser una caja de herramientas con un propósito.
Los exámenes antiguos de la asignatura preguntan casi literalmente tres cosas de esta lección: qué rasgos distinguen un proyecto de una operación, qué elementos son clave en la definición de proyecto y cuál es la mejor estrategia ante "restricciones que compiten". Son puntos fáciles si entiendes el porqué, y trampas si lo memorizas a medias.
El caso que usaremos todo el curso
Para que nada se quede en abstracto, vamos a trabajar con un proyecto ficticio que irá creciendo lección a lección:
La empresa municipal de autobuses de una ciudad mediana quiere una app móvil que diga a los viajeros cuántos minutos faltan para que llegue el próximo autobús a su parada. Los autobuses ya llevan GPS. Tu empresa, una consultora de software de 12 personas, se plantea presentarse al encargo. El ayuntamiento quiere la app antes de la feria de agosto, que es cuando más visitantes hay.
Con esto en mente, empecemos por lo más básico: ¿TusBus es siquiera un proyecto?
1. Proyecto frente a operación
La definición de las diapositivas viene del PMI (el Project Management Institute, autor de la guía PMBOK):Tema 1, diap. 4. La definición es la del PMBOK®, ver también Saylor, §1.2.
Un proyecto es un esfuerzo temporal para crear un producto, servicio o resultado único.
Cada palabra de esa frase hace trabajo. Vamos a desmontarla:
"Temporal"
Tiene un inicio y un final definidos. No significa "corto": un proyecto puede durar dos semanas o seis años. Significa que termina: cuando se cumplen los objetivos, cuando se ve que no se pueden cumplir, cuando se acaba la financiación o cuando la necesidad desaparece.Las condiciones de finalización están en el PMBOK; resumidas en Saylor, §1.2. Como el trabajo termina, el equipo también es temporal: se forma para el proyecto y se disuelve (o se reasigna) al acabar.
"Único"
El resultado no se ha hecho antes exactamente igual. Puede parecerse a otros (has hecho otras apps), pero esta tiene sus usuarios, sus datos, su ciudad, sus restricciones. Esa unicidad es la raíz de la incertidumbre: si fuera repetido, sabrías exactamente cuánto cuesta y cuánto tarda.
"Producto, servicio o resultado"
Ojo a esto: no tiene por qué ser un producto. Un proyecto puede dar como resultado un servicio (poner en marcha un soporte técnico), o un resultado/conocimiento (un estudio de viabilidad, una auditoría, una migración). "El proyecto debe generar al menos un producto" es falso.
Lo que no es un proyecto: la operación
Una operación es trabajo continuo y repetitivo que sostiene a la organización: hacer las copias de seguridad cada noche, atender incidencias, facturar cada mes.Tema 1, diap. 4: "No es lo mismo que una operación recurrente o repetitiva". No termina; si terminara, la organización dejaría de funcionar.
| Rasgo | Proyecto | Operación |
|---|---|---|
| Duración | Temporal: inicio y fin definidos | Continua, sin fin previsto |
| Propósito | Lograr unos objetivos y terminar | Sostener la organización |
| Resultado | Único | Repetitivo, el mismo una y otra vez |
| Equipo | Temporal; no tiene por qué seguir la estructura de departamentos | Funcional; alineado con la estructura de la organización |
| Incertidumbre | Alta (nunca se ha hecho igual) | Baja (se conoce bien el proceso) |
Aplicado a nuestro caso: construir TusBus es un proyecto (único, con fecha de fin: la feria). Pero una vez publicada, mantener la app funcionando, atender los fallos y renovar certificados cada año es una operación. El mismo producto pasa de proyecto a operación al cerrarse el proyecto, y esa transferencia es precisamente una de las tareas del cierre (lo veremos en la lección 11).
- "Debe durar al menos 3 meses": falso. La duración no define nada; lo que define es que termina.
- "Debe generar al menos un producto": falso. Producto, servicio o resultado.
- "El jefe de proyecto suele ser un jefe de departamento": falso. Esa es la lógica de la operación (equipos funcionales). En un proyecto, el equipo es transversal y temporal.
- Un "proyecto" que nunca termina (p. ej. "mejorar la web continuamente") suele ser en realidad una operación, o una serie de proyectos.
2. Por qué el software es especialmente difícil de gestionar
Gestionar la construcción de un puente y la de una app comparten muchas técnicas.Tema 2, diap. 5: las técnicas de ingeniería de proyectos e investigación operativa son aplicables al software. Pero el software tiene cinco particularidades que lo complican.Tema 1, diap. 5. Para cada una, piensa en qué obliga a hacer al gestor, porque esa es la parte que se pregunta en un examen de aplicar.
| Particularidad | Qué significa | Qué obliga a hacer al gestor |
|---|---|---|
| Producto intangible | No puedes ver un 60 % de app como ves un 60 % de puente. | Hacer el avance verificable: entregables, demos, pruebas que pasan. |
| Requisitos y solución evolucionan | El cliente descubre lo que quiere al ver la app; el mercado cambia. | Gestionar el cambio (priorizar, renegociar) en vez de prohibirlo. |
| Alta incertidumbre técnica y organizativa | ¿Los GPS de los buses dan datos fiables? ¿Quién decide en el ayuntamiento? | Reducir lo desconocido pronto: prototipos, pruebas de concepto, preguntar. |
| El progreso no siempre es visible | "Está al 90 %" durante semanas. El código escrito no es valor entregado. | Medir resultados, no actividad; desconfiar de "porcentajes completados". |
| El coste del cambio crece con el tiempo | Cambiar una frase del requisito hoy cuesta minutos; cambiar la arquitectura en producción cuesta meses. | Detectar errores lo antes posible: revisiones, validación temprana. |
Fíjate en que estas cinco ideas reaparecen por todo el temario. La incertidumbre justifica la gestión de riesgos (lecciones 12-13); que el progreso no se vea explica por qué las métricas de valor ganado hay que leerlas con cuidado en software (lección 14)Tema 2, diap. 52: "medir porcentaje completado de funcionalidades puede generar una falsa sensación de precisión".; que los requisitos cambien explica los ciclos de vida adaptativos (lección 7).
3. Gestionar no es programar
La gestión de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas para cumplir los requisitos del proyecto, equilibrando sus restricciones.Tema 1, diap. 6.
Programar es una actividad dentro del proyecto. Gestionar es otra cosa: es decidir y controlar.Tema 1, diap. 7.
| Gestionar es decidir… | …y reaccionar para controlar |
|---|---|
| qué hacer · por qué · cuándo · con qué recursos · quién participa · qué riesgos aceptar | plazos y costes · personas e interacciones · imprevistos y desviaciones · cambios |
En TusBus, un programador decide cómo calcular el tiempo estimado de llegada. El gestor decide si ese cálculo se hace en la primera versión o en la segunda, si se compra una librería o se desarrolla, quién lo hace, y qué pasa si el GPS falla. Son decisiones de naturaleza distinta.
La gestión como sistema de decisiones
Las diapositivas lo resumen como una cadena:Tema 1, diap. 8.
Dos ideas importantes salen de aquí:
- Cada decisión condiciona las siguientes. Si el objetivo es "reducir colas en la parada", los requisitos irán hacia tiempos precisos; si fuera "atraer turistas en la feria", irían hacia mapas e idiomas. La solución técnica y el plan se derivan de eso.
- La gestión mantiene la coherencia entre todas. Si a mitad de proyecto cambia un objetivo, no basta con añadir un requisito: hay que revisar si la solución, el plan y los recursos siguen teniendo sentido. Un proyecto se rompe cuando una pieza cambia y las demás no se actualizan.
Esta cadena es, de hecho, el índice del Tema 1: RFP y definición (objetivos), requisitos, viabilidad y arquitectura (solución), planificación (plan), ejecución y control, cierre (resultados).
4. Las restricciones que compiten
Todo proyecto opera dentro de seis restricciones:Tema 1, diap. 9-10. alcance, plazo, coste, calidad, recursos y riesgos.
De la tríada clásica a las múltiples restricciones
El modelo clásico (la "triple restricción" o "triángulo de hierro") hablaba solo de alcance, tiempo y coste: si tocas uno, se mueven los otros. Si quieres más funcionalidad (alcance) en el mismo plazo, te costará más (más gente). Si quieres gastar menos y en el mismo plazo, tendrás que hacer menos.
La visión moderna añade algo fundamental: la calidad y el riesgo no pueden tratarse como variables secundarias. El error clásico es "ajustar" el triángulo sacrificando calidad en silencio (menos pruebas, código apresurado), lo que genera deuda técnica y riesgo que estallan después. En proyectos modernos hay múltiples restricciones y objetivos en tensión, y ninguno se puede sacrificar sin que se note.
¿Qué hace un buen gestor cuando chocan?
Vuelve a TusBus. A seis semanas de la feria, el ayuntamiento pide añadir avisos push de "tu bus llega en 2 minutos". La fecha no se mueve. ¿Qué haces?
Mira las respuestas posibles. Todas las que empiezan por "no debo permitir que…" comparten el mismo fallo: blindan una restricción de forma rígida, sin mirar el contexto.
- "No permito que la fecha se mueva": ¿y si la única forma es sacrificar las pruebas y la app falla en plena feria?
- "No permito que crezca el alcance": ¿y si los avisos son lo que más valor aporta y se puede quitar otra cosa menos importante?
- "No permito que afecte a la calidad / al presupuesto": igual de rígido.
La respuesta de gestión es: analizar la situación con el equipo (y el cliente), hacer explícito el compromiso (trade-off) y decidir de forma consciente, gestionando los riesgos que esa decisión provoca. Por ejemplo: "Entramos los avisos si sacamos el modo offline a la versión de septiembre; el riesgo es X y lo vigilamos así". Esto encaja con lo que dicen las diapositivas sobre deuda técnica: la gestión responsable consiste en "hacer explícito el compromiso".Tema 1, diap. 59, "Relación entre deuda y gestión".
Cuando una pregunta te ofrezca una opción tipo "analizar con el equipo, decidir explícitamente y gestionar los riesgos" frente a varias de "nunca permitir X", la primera es casi siempre la correcta. La gestión es equilibrar, no proteger una variable a cualquier precio.
5. ¿Qué es un proyecto con éxito?
"Terminar a tiempo y dentro del presupuesto" era la definición clásica. Las diapositivas la ponen en duda.Tema 1, diap. 11. También importan:
- Valor para el negocio o el usuario: ¿resuelve el problema?
- Calidad y sostenibilidad, incluidos múltiples aspectos de calidad (seguridad, mantenibilidad…).
- Deuda técnica: ¿cuánto "préstamo" dejamos para el futuro?
- Satisfacción de los stakeholders (las partes interesadas).
- Cumplimiento legal y organizativo (p. ej. protección de datos).
Imagina que TusBus se entrega en fecha y presupuesto, pero los tiempos de llegada fallan por 5 minutos, nadie la usa, guarda la ubicación de los usuarios sin consentimiento y el código es tan frágil que nadie se atreve a tocarlo. ¿Éxito? Según el criterio clásico, sí. Según el moderno, es un fracaso con cuatro caras: sin valor, sin calidad, sin cumplimiento y con deuda.
6. Por qué fracasan los proyectos y cuánto cuesta equivocarse tarde
Las causas más habituales de fracaso:Tema 1, diap. 12.
- Objetivos ambiguos
- Requisitos inestables o mal entendidos
- Estimaciones demasiado optimistas
- Riesgos ignorados o mal gestionados
- Problemas técnicos subestimados
- Comunicación deficiente
- Problemas del personal
Fíjate en algo: casi ninguna es "el código estaba mal escrito". Son fallos de gestión: de definición, de estimación, de riesgos, de personas. Por eso existe la asignatura. Y cada una tiene su lección: objetivos → lección 3; requisitos → 4-5; estimaciones → 10; riesgos → 12-13; personas y comunicación → 16.
El coste de los errores
Un error detectado pronto es barato de corregir; el mismo error detectado durante la integración o en producción puede ser muy caro.Tema 1, diap. 13. El T2 da un dato en la misma línea para seguridad: detectar vulnerabilidades pronto ahorra en torno a un 80 % frente a post-producción (diap. 99). ¿Por qué? Porque un error tardío no se corrige en un solo sitio: arrastra todo lo que se construyó encima (diseño, código, pruebas, datos, documentación, usuarios que ya lo usan).
En TusBus: si nadie comprueba al principio que los GPS de los buses envían la posición solo cada 2 minutos, todo el cálculo "llega en 1 minuto" se diseña sobre un supuesto falso. Descubrirlo en la semana 1 cuesta una llamada. Descubrirlo en la feria cuesta la reputación del proyecto.
Conclusión que el temario repite: la gestión busca reducir la incertidumbre cuanto antes. Esta idea justifica los estudios de viabilidad, los prototipos, la priorización por riesgo, el "shift left" de DevSecOps… Retenla: explica medio curso.
7. Las ocho preguntas que todo proyecto debe responder
Las diapositivas cierran esta parte con las cuestiones clave en la práctica.Tema 1, diap. 14. Te las pongo junto a la herramienta del temario que las responde, porque esa asociación es la que te permite razonar en el examen:
| Pregunta | Herramienta del temario |
|---|---|
| ¿Qué problema resolvemos? | Definición del proyecto, Project Charter |
| ¿Para quién(es)? | Análisis de stakeholders |
| ¿Qué se incluye y qué queda fuera? | Alcance (in scope / out of scope) |
| ¿Cómo sabremos que funciona? | Criterios de aceptación, criterios de éxito |
| ¿Es viable? | Estudio de viabilidad |
| ¿Qué puede salir mal? | Identificación y análisis de riesgos |
| ¿Cómo lo evitamos o mitigamos? | Tratamiento de riesgos |
| ¿Qué necesitamos para ejecutarlo? | Planificación, costes, personas |
Gestionar un proyecto software es tomar decisiones bajo incertidumbre, equilibrando restricciones que compiten, de forma explícita y lo antes posible.Es, casi literal, la primera de las "Ideas clave: ¡no olvidar!" del Tema 1, diap. 71.
Práctica
Ahora toca recuperar de memoria. No vuelvas a leer arriba mientras respondes: el esfuerzo de recordar es lo que fija el conocimiento. Fallar aquí es útil; fallar en el examen, no.
¿Cuál de estas actividades es un proyecto y no una operación?
- Atender cada día las incidencias del correo corporativo
- Migrar el correo corporativo a un nuevo proveedor externo
- Hacer cada noche la copia de seguridad de los servidores
- Enviar cada semana el boletín interno a toda la plantilla
En el contexto de diferenciar un proyecto de una operación, ¿qué afirmaciones corresponden a un proyecto?
- Los equipos son temporales y no tienen por qué seguir la estructura de la organización
- El propósito es sostener el funcionamiento diario de la organización a largo plazo
- El propósito es lograr unos objetivos concretos y, una vez logrados, terminar
- Los equipos son funcionales y están alineados con los departamentos de la organización
- El trabajo es temporal, con un punto de comienzo y un final definidos de antemano
- El trabajo se realiza de forma continuada y repetida, sin un final previsto en el tiempo
¿Cuáles son elementos clave de la definición de proyecto?
- Debe generar como resultado al menos un producto
- Es un esfuerzo temporal, con un inicio y un fin
- Su duración debe ser de al menos tres meses
- Su equipo se disuelve cuando el proyecto termina
- Su resultado es único, no se repite tal cual
- Lo dirige normalmente un jefe de departamento
Empareja cada particularidad del software con lo que obliga a hacer al gestor.
- El producto es intangible y el progreso no siempre se ve
- Requisitos y solución evolucionan con frecuencia
- Hay alta incertidumbre técnica y organizativa
- El coste del cambio crece con el tiempo
En TusBus, a seis semanas de la feria, el cliente pide añadir avisos push. La fecha es fija. ¿Cuál es la mejor estrategia de gestión?
- Rechazar el cambio: el alcance pactado no se toca, porque cualquier ampliación supone costes que no podemos asumir
- Aceptar el cambio y recortar las pruebas planificadas, porque la fecha de la feria es lo único realmente inamovible
- Aceptar el cambio y añadir horas extra al equipo, porque el presupuesto en software son las horas y aún nos quedan
- Analizar con el equipo y el cliente qué se puede intercambiar, decidir de forma explícita y gestionar los riesgos resultantes
¿Qué afirmación resume mejor la evolución de la "tríada de restricciones" según el temario?
- Se ha sustituido por completo: hoy alcance, tiempo y coste ya no se consideran restricciones
- Sigue siendo alcance, tiempo y coste, y la calidad se ajusta según lo que quede al final
- Se amplía: calidad y riesgo no pueden ser secundarias y hay múltiples objetivos en tensión
- Se reduce a dos variables, tiempo y coste, porque el alcance en software siempre es variable
Según el temario, además de plazo y presupuesto, ¿qué debe tenerse en cuenta para decir que un proyecto ha tenido éxito?
- El valor que aporta al negocio o al usuario
- El número total de líneas de código escritas
- La deuda técnica que deja para el futuro
- El cumplimiento legal y organizativo exigido
- Que el equipo no haya necesitado vacaciones
- La satisfacción de las partes interesadas
Empareja cada situación con la causa de fracaso del temario que mejor la describe.
- El ayuntamiento dice que quiere "mejorar la movilidad", pero nadie sabe qué cifra lo demostraría
- Se calculó el plan suponiendo que nadie se pondría enfermo ni habría ningún imprevisto
- Se sabía que el proveedor de GPS iba con retraso, pero nadie lo vigiló ni preparó alternativa
- El equipo cambió el formato de las paradas y el diseñador se enteró dos semanas después
- Cada reunión con el cliente añade o cambia funciones sin que nadie las registre ni priorice
A mitad de TusBus, el ayuntamiento cambia el objetivo: ya no es "informar de tiempos" sino "vender billetes desde la app". Según la idea de la gestión como sistema de decisiones, ¿qué debe hacer el gestor?
- Añadir los requisitos de pago al final de la lista y seguir con el plan que ya teníamos
- Revisar en cadena requisitos, solución, plan y recursos para mantener la coherencia
- Pedir a los programadores que decidan ellos cómo encajar el pago en la app existente
- Ignorar el cambio hasta terminar la versión actual, porque cambiar a mitad es un error
Sin mirar: ¿cuáles son las seis restricciones del proyecto que aparecen en el temario?
Explica, en 2-3 frases y con un ejemplo propio (no el del GPS), por qué un error es más caro cuanto más tarde se detecta, y qué implicación tiene para la gestión.
Caso: un proyecto de intranet se entregó en plazo y un 5 % por debajo del presupuesto. Seis meses después, nadie la usa porque los empleados siguen con el correo, y el equipo de mantenimiento dice que cualquier cambio rompe algo. ¿Fue un éxito? Argumenta usando los criterios del temario.
Para profundizar
Relee las diapositivas 4-14 del Tema 1: ahora que entiendes el porqué, verás que cada línea encaja. Son el resumen de lo explicado en clase; el examen puede ir más allá, por eso esta lección amplía con fuentes generales de la disciplina.
Complemento de calidad: Saylor, Project Management: From Simple to Complex, §1.2 "Project Defined". Explica la definición del PMI y la diferencia con las operaciones con ejemplos (en inglés, ~10 min).
Para ver el mapa completo de la disciplina: SWEBOK v4.0 (IEEE Computer Society), gratuito. El área Software Engineering Management recoge los fundamentos universales de esta asignatura; lo usaremos a partir de la lección 2.
Pregúntame lo que no te haya quedado claro, por pequeño que sea: soy tu profesor para esto. Si fallaste alguna pregunta, cuéntame cuál y por qué elegiste lo que elegiste; los errores razonados son la mejor pista de qué reforzar en la siguiente lección.
Resumen imprimible: Referencia · Fundamentos de la gestión de proyectos.