El proyecto de principio a fin
Ya conoces todas las piezas. Esta lección las pone en orden: qué haces el primer día, con quién hablas, qué documento sale de cada paso y qué haces después. Un único proyecto, TusBus, contado como un libro desde que llega la petición hasta que se archiva.
- Recitar en orden los pasos de un proyecto real, desde la RFP hasta las lecciones aprendidas.
- Decir, para cada paso, con quién se habla y qué documento o artefacto sale.
- Describir el bucle de ejecución y control: qué pasa cada día, cada sprint, cada semana y cada mes.
- Ante "estamos en tal punto del proyecto", decir cuál es el siguiente paso y por qué.
Las diapositivas presentan el Tema 1 como un recorrido por las etapas de un proyecto (T1, diap. 15 y el mapa global de las diap. 69-70) y el Tema 2 como las preocupaciones que lo acompañan de principio a fin. Las preguntas cortas del profesor suelen situarte en un momento del proyecto ("el cliente pide un cambio a mitad…", "vais a empezar a planificar…"). Si tienes el recorrido en la cabeza, sabes en qué lección buscar la respuesta y qué toca hacer después. Esta lección no añade teoría nueva: ordena la que ya tienes.
0. El mapa antes de empezar T1 diap. 15 · 69-70
Las diapositivas dan dos versiones del mismo camino. La corta:Tema 1, diap. 15 y diap. 69-70. Lección 2, sección 6.
Y la larga, que es el orden del curso:
Más una frase que es la clave de todo: en todo el ciclo están presentes stakeholders + riesgos + calidad + deuda técnica. No son un paso: son cuatro registros que abres al principio y no cierras hasta el final.
En esta lección lo agrupamos en cuatro fases y 25 pasos. Cada paso tiene una ficha con tres datos que son justo lo que se olvida: con quién, qué sale (el documento, en este formato) y en qué lección está la teoría.
El ayuntamiento quiere una app que diga a los ciudadanos cuándo llega su autobús, y la quiere publicada antes de la feria de agosto. Tú eres el jefe de proyecto (JP) de una consultora pequeña. Presupuesto máximo: 60.000 €. Equipo previsto: 4 personas. Ciclo de vida: híbrido (contrato e hitos predictivos, desarrollo en iteraciones de 2 semanas). Es el mismo TusBus de las lecciones anteriores, ahora contado de corrido.
Los pasos se presentan en orden porque así se aprenden, pero en un proyecto real se solapan y se repiten: los requisitos se refinan durante la ejecución, los riesgos se revisan cada semana, el plan se rehace al final de cada iteración. Lo que sí es fijo es lo que tiene que existir antes de lo siguiente: no se planifica sin alcance, no se ejecuta sin plan aprobado, no se cierra sin aceptación. Recuerda la lección 11: los procesos de planificación y de control no terminan antes de que empiece la ejecución.
Fase 1 · Inicio: de la petición al proyecto autorizado Enero T1 diap. 15-22 · 41-43 · 51-54
Objetivo de la fase: pasar de "el ayuntamiento quiere una app" a "existe un proyecto autorizado, con un JP nombrado, objetivos medibles y alguien que paga". Hasta que no termina esta fase, no se gasta dinero en construir nada.
1Leer la RFP y entender el problema
Llega el pliego (la RFP) del ayuntamiento. Lo lees entero buscando: contexto y problema, objetivos, requisitos, entregables, plazos, criterios de evaluación (cómo van a elegir al ganador) y presupuesto. Tu primera tarea no es pensar en Flutter o Kotlin: es entender qué problema tiene el ayuntamiento (¿quejas por las esperas? ¿imagen ante la feria?). Apuntas cada ambigüedad ("antes de la feria": ¿publicada o con usuarios?) y cada supuesto que estás haciendo ("los autobuses ya llevan GPS"). Si el pliego permite ronda de preguntas, las mandas.
- Con quién
- El técnico de contratación del ayuntamiento (preguntas por escrito); internamente, tu dirección.
- Qué sale
- Lista de dudas y supuestos
- Lección
- L3 · RFP y cómo responderla
2Decidir si presentarse: viabilidad rápida
Antes de dedicar una semana a una propuesta, compruebas por encima las cinco viabilidades: técnica (¿sabemos hacer mapas en tiempo real?), económica (¿60.000 € nos cubre?), temporal (¿llegamos a agosto?), organizativa (¿quién la mantendrá?) y legal (datos de ubicación, RGPD, accesibilidad). Para la económica y la temporal haces una estimación por analogía con un proyecto parecido: es lo único posible sin EDT, y sabes que está en la parte ancha del cono de incertidumbre. Resultado: seguir, no seguir o seguir redefiniendo.
3Escribir la propuesta
Respondes a la RFP siguiendo las cuatro reglas de las diapositivas: (1) demuestras que has entendido el problema; (2) explicitas supuestos y ambigüedades; (3) propones alcance, solución, plan, equipo y costes; (4) explicitas riesgos y exclusiones. La parte que más te protegerá después es la 4: "No incluye venta de billetes. Supone que el ayuntamiento entrega la API de GPS antes del 1 de marzo; si no, el plazo se revisará".
- Con quién
- Tu dirección (aprueba precio y equipo); el equipo técnico (solución y estimación).
- Qué sale
- Propuesta técnica y económica
- Lección
- L3 · responder a una RFP
4Adjudicación y contrato
El ayuntamiento compara propuestas con sus criterios y elige la tuya. Se firma el contrato, que recoge (o lleva anexo) el SOW: qué trabajo se va a hacer y qué se entrega. A partir de aquí, cualquier cosa fuera de ese alcance será una petición de cambio, no un "ya que estáis".
- Con quién
- Contratación del ayuntamiento y tu dirección (firman); tú revisas que el alcance coincida con la propuesta.
- Qué sale
- Contrato SOW
- Lección
- L3 · documentos del origen del proyecto
5Redactar el Project Charter y que lo firme el sponsor
El primer documento del proyecto. Lo redactas tú y lo firma el sponsor, el concejal de movilidad, porque es quien pone los recursos. Corto (1-3 páginas): propósito, objetivos SMART, criterios de éxito (publicada antes de la feria, 15.000 descargas el primer mes, error medio < 1 min, sin incidencias de datos), alcance de alto nivel, hitos principales, presupuesto, stakeholders clave, y tu nombramiento como JP con tu autoridad. Desde ahora, ante cualquier propuesta, la pregunta es "¿encaja con el charter?".
En el charter (o junto a él) queda también la gobernanza: quién decide qué. Por ejemplo: "cambios de más de 2 semanas o 10.000 € los aprueba el comité de dirección del ayuntamiento; por debajo, el JP con el sponsor".
En la práctica el charter se presenta en una reunión de arranque (kick-off) con sponsor, equipo y stakeholders principales: todos oyen lo mismo el mismo día.
6Identificar y analizar a los stakeholders
Haces la lista de todos los que afectan o se ven afectados: concejal, empresa de autobuses, interventor municipal, informática del ayuntamiento, conductores, asociación de usuarios, comercios. Para cada uno, su punto de vista e intereses (que pueden chocar). Los colocas en la matriz poder/interés y decides la estrategia: gestionar de cerca al concejal y a la empresa de autobuses, mantener satisfecho al interventor, informar a los usuarios, monitorizar a los comercios. De ahí sale el plan de comunicaciones: qué recibe cada uno, cada cuánto, por qué canal y quién lo envía.
Contrato y SOW · Charter firmado · Gobernanza (quién decide) · Registro de stakeholders · Plan de comunicaciones. Prueba: si alguien te pregunta "¿esto está aprobado?, ¿quién manda?, ¿qué es éxito?", tienes un documento que lo responde.
Fase 2 · Definición y planificación: qué, cómo, cuándo y cuánto Febrero T1 diap. 24-61 · T2
Objetivo de la fase: convertir el charter en un plan aprobado con línea base. Al final sabrás qué se construye (y en qué orden), cómo, quién, cuándo, cuánto cuesta, qué puede salir mal y cómo se va a comprobar la calidad.
7Obtener los requisitos y hacerlos verificables
Talleres y entrevistas con quienes van a usar el sistema: usuarios del bus, la empresa de autobuses, el personal municipal que publicará incidencias. Separas funcionales ("mostrar el tiempo de llegada de cada línea en una parada") de no funcionales (error medio < 60 s, disponibilidad 99,5 %, accesible, cumple RGPD). A cada requisito le pones criterios de aceptación: así, al final, "terminado" no será una opinión. Y montas la matriz de trazabilidad: objetivo del charter → requisito → diseño → prueba. Un requisito que no cuelga de ningún objetivo es candidato a salir.
Aquí entra también el cumplimiento desde el principio: tratar la ubicación de los usuarios genera requisitos de protección de datos y de accesibilidad que van al documento ahora, no en la semana 15. Para TusBus: evaluación de impacto (EIPD) del RGPD, accesibilidad del sector público y Esquema Nacional de Seguridad.
- Con quién
- Usuarios y sus representantes, empresa de autobuses, informática municipal, delegado de protección de datos.
- Qué sale
- Especificación de requisitos (o backlog inicial) con criterios de aceptación · Matriz de trazabilidad · Enunciado del alcance (in / out, supuestos, restricciones)
- Lección
- L4 · requisitos · L3 · alcance · L17 · compliance
8Priorizar
La fecha es fija (la feria), así que la única variable que se puede mover sin destrozar la calidad es el alcance. Con el concejal y la empresa de autobuses aplicas MoSCoW: Must = tiempo de llegada, mapa de paradas, RGPD; Should = favoritos, avisos de incidencias; Could = modo oscuro; Won't (esta vez) = pago de billetes. Combinas criterios: lo de más riesgo y dependencias (la integración GPS) va primero aunque no luzca.
- Con quién
- El concejal (sponsor) y la empresa de autobuses deciden valor; el equipo informa de coste y riesgo.
- Qué sale
- Backlog priorizado (lista MoSCoW)
- Lección
- L5 · MoSCoW, WSJF, riesgo
9Confirmar la viabilidad y decidir la arquitectura
Ahora la viabilidad va en serio, con los requisitos delante. El supuesto más peligroso ("el GPS envía la posición cada 15 s") se comprueba con una prueba técnica rápida con datos reales: un supuesto sin verificar es un riesgo. Luego decides la arquitectura guiado por los requisitos no funcionales (no por modas) y escribes un ADR por cada decisión importante: contexto, decisión, alternativas, consecuencias. "ADR-003: Flutter para iOS y Android con un solo equipo".
- Con quién
- El equipo técnico; informática del ayuntamiento (hosting, seguridad, la API de GPS).
- Qué sale
- Estudio de viabilidad · Documento de arquitectura · ADRs
- Lección
- L6 · viabilidad, arquitectura y ADR
10Elegir el ciclo de vida
Con los cuatro factores (estabilidad de requisitos, riesgo e incertidumbre, entorno del cliente, equipo) eliges híbrido: el contrato, los hitos y el presupuesto con el ayuntamiento son predictivos; el desarrollo, iterativo e incremental en iteraciones de 2 semanas, porque los requisitos cambiarán en cuanto la gente pruebe la app. La decisión se escribe con su porqué.
- Con quién
- El sponsor (tiene que aceptar ver demos frecuentes y repriorizar) y el equipo.
- Qué sale
- La decisión, registrada en el plan del proyecto (o en un ADR)
- Lección
- L7 · ciclos de vida
11Planificar el trabajo y el calendario
Descompones todo el trabajo (en una EDT, hasta paquetes de trabajo), estimas esfuerzo y duración (no son lo mismo), ves las dependencias (sin la API de GPS no hay cálculo de llegada) y el camino crítico, y lo pintas en un Gantt con hitos comprobables ("API de GPS integrada y probada con datos reales", 15 de abril). Asignas personas según capacidad real (un sprint de 10 días con 4 personas da unas 192 h útiles, no 320). Estimas en rangos y con el equipo; la estimación no es un compromiso.
12Identificar, analizar y responder a los riesgos
Sesión de riesgos con el equipo (un premortem funciona muy bien: "es el día después de la feria y TusBus ha sido un desastre, ¿qué pasó?") y repaso de los supuestos de la fase 1, porque cada supuesto es un riesgo potencial. Cada riesgo se escribe causa → evento → consecuencia, se valora en probabilidad × impacto, recibe una respuesta (evitar, mitigar, transferir, aceptar; plan de contingencia si se materializa), un propietario con nombre y un indicador (KRI) que avise antes de que pase. Con los riesgos ya puedes dimensionar las reservas.
Ejemplo: R-03 "Como la API depende de informática municipal, que tiene otras prioridades, podría llegar tarde, lo que bloquearía el cálculo de llegada y retrasaría la entrega". P 40 %, impacto alto. Mitigación: pedir acceso en la firma del contrato y trabajar con datos simulados. Contingencia: usar el feed público de horarios. Propietario: tú. KRI: "sin credenciales de prueba el 15 de febrero".
13Presupuestar
Con las estimaciones de esfuerzo, los recursos y los riesgos, calculas el coste: personas (lo principal en software), licencias, hosting, publicación en tiendas, y piensas en el coste total (los 3 años de operación también cuentan para el ayuntamiento). Sumas las reservas para riesgos. El presupuesto repartido en el tiempo es la base que luego usará el valor ganado (PV).
- Con quién
- Tu dirección (tarifas); el interventor municipal (que aprueba pagos: mantener satisfecho).
- Qué sale
- Presupuesto (línea base de costes + reservas)
- Lección
- L14 · costes y EVM
14Planificar la calidad
Seleccionas y adaptas al proyecto los estándares y procedimientos: qué significa "terminado" (Definition of Done: código revisado, pruebas automáticas pasando, criterios de aceptación cumplidos), revisiones de código, tipos de prueba, estándar de accesibilidad, atributos de calidad prioritarios (fiabilidad del tiempo de llegada, usabilidad en la parada). La calidad se planifica, no se "añade al final".
- Con quién
- El equipo; el ayuntamiento si tiene estándares propios.
- Qué sale
- Plan de calidad
- Lección
- L15 · calidad
15Preparar al equipo y el entorno de trabajo
Roles claros, acogida de quien llegue nuevo, sin depender de una sola persona en lo crítico (bus factor: dos personas deben saber de la integración GPS). Y la infraestructura: repositorio, tablero de tareas, pipeline de integración y despliegue continuos con pruebas automáticas y análisis de seguridad desde el primer día (DevSecOps: la seguridad entra en el pipeline, no al final).
16Aprobar el plan: la línea base
Presentas al sponsor el plan completo (alcance, cronograma con hitos, presupuesto, riesgos principales, plan de calidad y de comunicaciones). Cuando lo aprueba, eso se convierte en la línea base: la foto contra la que vas a medir todas las desviaciones. A partir de aquí, sólo cambia mediante control de cambios.
- Con quién
- El sponsor (aprueba); el comité de dirección si la gobernanza lo pide.
- Qué sale
- Plan del proyecto aprobado = Línea base (alcance + cronograma + coste)
- Lección
- L9 · línea base
Requisitos con criterios de aceptación · Matriz de trazabilidad · Alcance in/out · Backlog priorizado · Estudio de viabilidad · Arquitectura y ADRs · Plan (EDT, Gantt, hitos, recursos) · Registro de riesgos · Presupuesto con reservas · Plan de calidad · Pipeline · Línea base aprobada.
Fase 3 · Ejecución y control: el bucle Marzo – julio T1 diap. 62-66 · T2 diap. 44 · 51-54
Aquí el libro deja de ser una lista y se convierte en un ciclo que se repite hasta el final: hacer, medir, decidir, ajustar (PDCA). Es la fase más larga y la que más se olvida porque "no tiene documento nuevo": lo que hace es mantener vivos los documentos de la fase 2. Organízalo por ritmos.
17Al empezar cada iteración: decidir qué entra
Con el backlog priorizado y la capacidad real del equipo, se elige qué se hará en estas dos semanas y se descompone en tareas concretas que alguien puede coger. Si hay elementos nuevos o cambios aprobados, se repriorizan frente a lo existente: lo que entra hace salir otra cosa.En Scrum (Tema 3) esta reunión se llama sprint planning.
18Cada día: construir y desbloquear
El equipo desarrolla. Una reunión diaria breve (daily stand-up): qué hice, qué haré, qué me bloquea. Tu trabajo como JP no es repartir órdenes: es quitar bloqueos (llamar a informática porque el servidor de pruebas está caído) y vigilar la carga de cada persona. Cada cambio de código pasa por revisión y por el pipeline (pruebas, análisis de seguridad) antes de integrarse.
19Al acabar cada iteración: enseñar y mejorar
Revisión: demo de software funcionando a los stakeholders (el concejal, la empresa de autobuses). Es la medida principal de progreso y la fuente de feedback: aquí aparecen los cambios. Retrospectiva: el equipo, solo, analiza qué funcionó y qué cambiar en su forma de trabajar, sin buscar culpables. Es una pequeña sesión de lecciones aprendidas cada dos semanas.
- Con quién
- Revisión: equipo + stakeholders clave. Retrospectiva: sólo el equipo.
- Qué sale
- Incremento aceptado o rechazado · Backlog actualizado · Acciones de mejora · lecciones aprendidas parciales
- Lección
- L11 · revisiones frecuentes, lecciones aprendidas
20Cada semana: la reunión de seguimiento (PDCA)
Comparas lo real con la línea base y te haces las cuatro preguntas de las diapositivas: ¿vamos tarde? ¿qué ha cambiado? ¿qué riesgo ha cambiado? ¿qué decisión debemos tomar ahora? Mides con criterios objetivos (hitos cumplidos, funcionalidades que pasan su aceptación), no con "estoy al 90 %". Y actualizas los registros, cada cosa en el suyo:
- Riesgos (futuro): ¿alguno sube, baja o se materializa? Miras los KRIs.
- Problemas (presente): "la API devuelve datos con 2 min de retraso" ya no es un riesgo, es un problema. Si estaba previsto, activas su contingencia.
- Peticiones de cambio: van al control de cambios (paso 22).
- Decisiones: qué se decidió, quién y por qué.
- Deuda técnica: qué atajos se han tomado y cuándo se pagarán.
21Cada mes (o según el plan de comunicaciones): informar
Calculas el valor ganado (PV, EV, AC → CPI y SPI) y lo interpretas: CPI 0,9 y SPI 0,95 significa que gastas más de lo previsto y vas algo tarde. Preparas el informe de estado para cada stakeholder según el plan de comunicaciones: al concejal, una página con hitos, CPI/SPI, riesgos principales y las decisiones que necesitas de él; a la asociación de usuarios, novedades de la app. Un semáforo RAG (verde, ámbar, rojo) es habitual; un informe siempre en verde hasta la última semana es un fallo de gestión.
22Cuando alguien pide un cambio: control de cambios
En la demo de mayo el concejal dice: "¿y si añadimos pago de billetes?". No dices "sí" ni "no" en la reunión. Sigues el procedimiento:
El análisis de impacto usa la matriz de trazabilidad (qué toca), el plan (cuánto retrasa), el presupuesto (cuánto cuesta) y el registro de riesgos (qué riesgo añade: pagos = PCI, más seguridad). Decide quien tenga autoridad según la gobernanza del paso 5: si supera 2 semanas o 10.000 €, el comité. Con fecha fija, la alternativa típica es "entra si sale otra cosa" o "va en una segunda versión". Si se aprueba, se actualiza la línea base y se comunica.
Las cuatro preocupaciones transversales del mapa global, cada una con su pregunta semanal:
- Stakeholders: ¿alguien ha cambiado de posición o se está quedando sin información?
- Riesgos: ¿qué riesgo ha cambiado?
- Calidad: ¿estamos cumpliendo el plan de calidad o "ya lo arreglaremos"?
- Deuda técnica: ¿qué atajo hemos tomado esta semana y cuándo se paga?
Y las personas: carga equilibrada (nadie al 100 %), conflictos normales de un equipo que se está formando (Tuckman), seguridad psicológica para que los problemas se cuenten pronto. Ante un retraso, añadir gente tarde suele empeorarlo (ley de Brooks).
Fase 4 · Entrega y cierre Julio – agosto T1 diap. 67-68 · T2 diap. 56-66
Objetivo de la fase: que el cliente acepte formalmente, que el sistema pase a operación con quien lo va a mantener, y que el conocimiento del proyecto no se pierda. Entregar el producto no es cerrar el proyecto.
23Validar y obtener la aceptación
Pruebas de aceptación con el ayuntamiento contra los criterios de aceptación del paso 7 (por eso se escribieron al principio). Verificación: ¿cumple lo especificado? Validación: ¿sirve a los usuarios reales en la parada? Si cumple, el cliente lo acepta formalmente, por escrito. Sin eso, el proyecto "no termina nunca".
24Poner en producción y transferir a operación
Se publica la app en las tiendas (con el pipeline, quizá primero a un porcentaje de usuarios). Y se entrega el sistema a quien lo va a operar y mantener: documentación, manuales, guías de qué hacer si algo falla, formación al personal municipal que publicará incidencias. Si no, operación recibe una caja negra y los fallos llegan a un equipo de desarrollo que ya no existe. En DevOps el producto sigue vivo: lo que termina es el proyecto de desarrollo inicial.
25Cerrar: contratos, recursos, lecciones aprendidas y celebración
Cierras lo administrativo: última factura, contratos con proveedores (mapas, hosting), documentación archivada donde se pueda encontrar. Liberas los recursos: las personas vuelven a otros proyectos. Haces la sesión final de lecciones aprendidas, sin culpables y con frases accionables: "la API del ayuntamiento tardó 6 semanas; en el próximo proyecto con ellos, pedir acceso en la firma del contrato". Esas lecciones serán la base de la próxima estimación por analogía (paso 2 del próximo proyecto). Y celebras con el equipo.
Un detalle que se olvida: algunos criterios de éxito del charter (15.000 descargas el primer mes) sólo se pueden medir después. Deja dicho quién lo medirá y cuándo.
- Con quién
- Tu dirección y el ayuntamiento (cierre administrativo); el equipo y los stakeholders clave (lecciones aprendidas).
- Qué sale
- Documento de lecciones aprendidas · Informe de cierre · proyecto archivado
- Lección
- L11 · cierre y lecciones aprendidas
El kit de documentos Resumen
Todo lo anterior, visto desde los papeles. La columna "Vida" es lo importante: casi ningún documento se escribe una vez y se olvida.
| Documento | Nace en | Lo hace / lo aprueba | Vida |
|---|---|---|---|
| RFP (pliego) | Antes del proyecto (paso 1) | El cliente | Fija; se consulta |
| Propuesta | Paso 3 | El proveedor (tú) | Fija; base del contrato |
| Contrato / SOW | Paso 4 | Cliente y proveedor firman | Fijo salvo adenda |
| Project Charter | Paso 5 (el primero del proyecto) | El JP redacta; el sponsor firma | Referencia de decisiones; cambia sólo formalmente |
| Registro de stakeholders y plan de comunicaciones | Paso 6 | El JP | Vivos todo el proyecto |
| Requisitos + matriz de trazabilidad + alcance | Paso 7 | El equipo con los usuarios; el cliente valida | Se refinan; los cambios, por control de cambios |
| Backlog priorizado | Paso 8 | El cliente decide valor; el equipo informa | Se repriorizan cada iteración |
| Estudio de viabilidad | Paso 2 (rápido) y 9 (serio) | El JP con el equipo; decide el sponsor | Se revisa si cambian los supuestos |
| Arquitectura y ADRs | Paso 9 | El equipo técnico | Un ADR nuevo por decisión; los viejos no se borran |
| Plan del proyecto (EDT, Gantt, hitos, recursos) | Paso 11 | El JP con el equipo | Se actualiza; la línea base sólo por cambio aprobado |
| Registro de riesgos | Paso 12 | El JP; cada riesgo tiene propietario | Revisión semanal |
| Presupuesto | Paso 13 | El JP; aprueba el sponsor | Se controla con EVM |
| Plan de calidad | Paso 14 | El JP y el equipo | Se aplica y mejora |
| Línea base | Paso 16 | Aprueba el sponsor | Sólo cambia por control de cambios |
| Registros de problemas, decisiones, cambios y deuda técnica | Fase 3 | El JP y el equipo | Vivos hasta el cierre |
| Informe de estado | Fase 3, periódico | El JP | Uno por periodo |
| Acta de aceptación | Paso 23 | El cliente firma | Fija; cierra el alcance |
| Lecciones aprendidas | Durante (retrospectivas) y paso 25 | Todo el equipo | Pasan al siguiente proyecto |
Versión imprimible de una página: Flujo del proyecto: checklist.
¿Y si el proyecto no es como TusBus? Ampliación
El esqueleto (autorizar → definir y planificar → ejecutar y controlar → cerrar) es universal: es el mismo que el SWEBOK llama Initiation and Scope Definition → Planning → Enactment → Review and Evaluation → Closure y el que el PMBOK 8 llama áreas de enfoque (Inicio, Planificación, Ejecución, Seguimiento y control, Cierre).SWEBOK v4, KA Software Engineering Management. PMBOK 8, áreas de enfoque (lección 2). Lo que cambia según el entorno es quién hace cada paso y cuánto papel genera:
- Proyecto interno (tu empresa se hace su propio software): no hay RFP, propuesta ni contrato. Los pasos 1-4 se sustituyen por un business case que justifica que merece la pena y que aprueba la dirección. Desde el charter, todo igual.
- Startup o producto propio, ágil puro: el charter puede ser una página con la visión y la métrica de éxito; el plan es un backlog y una hoja de ruta; los pasos 17-21 son casi todo el proyecto. Pero los riesgos, la calidad, los stakeholders y la deuda técnica siguen ahí, aunque se gestionen con menos papel.
- Administración pública grande o sector regulado: más gobernanza (comités, auditorías), cumplimiento más pesado (ENS, accesibilidad, IA de alto riesgo), contratos más rígidos. Más papel, pero los mismos pasos.
La regla que vale para todos: tanta documentación como haga falta y no más ("justa y suficiente", T1 diap. 65). Un documento existe para que alguien decida o recuerde algo; si nadie lo va a leer, sobra.
Primero se autoriza (charter), luego se define y planifica hasta tener una línea base aprobada, después se repite hacer-medir-decidir hasta terminar, y al final se acepta, transfiere y aprende; stakeholders, riesgos, calidad y deuda técnica se gestionan en todas las fases.
Práctica
Hazla sin mirar arriba. Lo que se entrena aquí es el orden y el "qué sale de cada paso": si fallas, vuelve a la ficha de ese paso.
¿En qué fase nace cada documento?
- Project Charter firmado por el sponsor
- Registro de riesgos con propietario y respuesta
- Petición de cambio con análisis de impacto
- Acta de aceptación firmada por el cliente
- Registro de stakeholders y matriz poder/interés
- Matriz de trazabilidad de requisitos
Acabas de recibir la RFP de TusBus. Tu equipo ya discute qué framework móvil usar. ¿Qué toca hacer primero?
- Estimar el esfuerzo de la app con planning poker
- Escribir el ADR con la elección del framework móvil
- Entender el problema y anotar dudas y supuestos
- Redactar el Project Charter para que lo firme el JP
¿Qué tiene que existir antes de que el equipo empiece a construir la app?
- El acta de aceptación firmada por el ayuntamiento
- Un plan aprobado por el sponsor como línea base
- El documento final de lecciones aprendidas del equipo
- Todos los requisitos cerrados y sin cambios posibles
¿Con quién hablas en cada situación?
- Firmar el Project Charter
- Estimar el esfuerzo de los paquetes de trabajo
- Aprobar un cambio de 4 semanas y 15.000 €
- La retrospectiva de la iteración
- Recibir manuales, guías y formación al final
En la reunión semanal de seguimiento de TusBus, ¿qué haces?
- Preguntar qué riesgo ha cambiado desde la semana pasada
- Redactar el Project Charter con los nuevos objetivos
- Comparar el avance real con la línea base aprobada
- Pasar a problemas los riesgos que ya han ocurrido
- Aprobar sobre la marcha los cambios que pida el cliente
- Decidir qué hacer con las desviaciones encontradas
En la semana 9 se confirma que el GPS envía la posición cada 2 minutos, no cada 15 s como se supuso. Estaba en el registro de riesgos con contingencia. ¿Qué haces?
- Lo anotas como riesgo nuevo y esperas a ver si se repite
- Lo dejas fuera del informe para no alarmar al concejal
- Pides una nueva línea base sin pasar por control de cambios
- Lo pasas a problema y activas la contingencia prevista
Verdadero o falso: "Cuando el ayuntamiento acepta la app y se publica en las tiendas, el proyecto ha terminado".
- Verdadero
- Falso
Es el día siguiente a la firma del contrato. Sin mirar, escribe en orden los pasos hasta que el equipo pueda empezar a construir, y el documento que sale de cada uno.
En la demo de mayo, el concejal pide añadir pago de billetes "para la feria". Describe paso a paso qué haces, qué documentos consultas y quién decide.
Repaso espaciado · lecciones 3, 13, 15
¿Qué distingue un supuesto de una restricción?
- El supuesto se cree cierto sin comprobar; la restricción limita
- El supuesto lo impone el cliente; la restricción, el equipo técnico
- El supuesto afecta al plazo; la restricción afecta sólo al coste
- El supuesto se negocia siempre; la restricción no se negocia nunca
"Si la API llega tarde, usaremos el feed público de horarios" es una respuesta de tipo…
- Mitigación, porque reduce la probabilidad del riesgo
- Transferencia, porque pasa el riesgo a un tercero
- Contingencia, porque se activa si el riesgo ocurre
- Aceptación pasiva, porque no se hace nada por ahora
Para profundizar
SWEBOK v4, KA Software Engineering Management: está organizada justo en este orden (inicio y definición del alcance, planificación, ejecución, revisión y evaluación, cierre) y es gratuita. Léela después de esta lección: verás cada paso con otras palabras, que es lo que hace falta si el profesor pregunta algo que no está tal cual en las diapositivas.
Prueba esto con un asistente: pídele que se invente otro proyecto (una web de reservas para un gimnasio, una app interna de una empresa) y que te diga "estamos en tal momento, ¿qué haces ahora, con quién hablas y qué documento sale?". Contesta tú y que te corrija con esta lección. Si algo de una ficha no te queda claro, pregúntalo en tutoría o al asistente: es mejor una duda resuelta que un paso memorizado sin entender.
Resúmenes imprimibles: Flujo del proyecto · Fundamentos · Glosario.