Proceso para planear y mantener un proyecto

---

Objetivo

• Definir la estrategia del proyecto, asegurando el alineamiento y monitoreo de todos los planes, la comprensión común del alcance y la validación de la estrategia con el stakeholder mediante la milestone “Stakeholder consensus”.

---

Entradas

1. Proyecto inicial con un cliente
2. Juntas con stakeholders
3. Plantilla del Plan de Proyecto
4. Plantillas de: SRS, Plan de Gestión de Datos, Plan de Pruebas, Plan de Comunicación, Plan de Recursos, Plan de Capacitación
5. Política de gestión de datos y estándar de arquitectura
6. Documento de ciclos de vida de proyecto

---

Proceso

Fase	Descripción	Responsable	Meta y práctica específica del CMMI
1. Conformar el equipo	Definir los roles y responsabilidades del equipo. Establecer pilares y acuerdos de trabajo de Code&Co	Project Manager	OPD 1.7 (Establecer las reglas y guías para los equipos)
2. Identificación de stakeholders	Usar la plantilla de involucramiento de los stakeholders para identificar los actores clave por fase del proyecto, especificando su rol, relevancia y nivel de interacción esperado. Nota: Consulta la Lista de criterios para proveedores apropiados de requisitos.	Project Manager, Product Owner	PP, SP 2.6 (Planificar la involucración de las partes interesadas)
3. Definir la Especificación de Requisitos de Software (SRS)	Agendar juntas semanales con los stakeholders durante las primeras cuatro semanas para completar la plantilla del SRS. Estas reuniones permitirán definir los siguientes puntos: -Alcance del proyecto -Perspectiva del producto -Funciones del producto -Atributos de calidad -Características de los usuarios -Limitaciones -Suposiciones	Project Manager/Team Lead, Team members	REQM SP 1.1 (Comprender los requisitos), PP, SP 2.6 (Planificar la involucración de las partes interesadas), PP, SP 1.1 (Estimar el alcance del proyecto).
	Consultar y aplicar las tecnicas necesarias descritas en Empatizar con el socio para la recopilación de requisitos durante las juntas.	Team members	RD SP 1.1 (SP 1.1 Educir las necesidades.)
4. Priorización de requisitos	En base a la información recopilada definir requisitos del proyecto consulta la sección ¿Cómo se decide qué requisitos aceptar?	Team members	REQM SP 1.1 (Comprender los requisitos)
	Revisar y organizar las historias de usuario según su relevancia y viabilidad. Aplicar la técnica MoSCoW para priorizar.	Product Owner
Identificación de Funcionalidades Clave	Desglosar las historias de usuario en funcionalidades específicas.	Team members	RD, SP 3.2 (Establecer y mantener una definición de la funcionalidad requerida)
Definición del Alcance del MVP y MBI	Establecer qué funcionalidades serán parte del MVP y MBI.	Equipo de Producto	REQM, SP 1.2 (Obtener compromiso con los requisitos)
	Definir los criterios de éxito del MVP y MBI (considera las fases de construcción y transición).	Equipo de Producto	RD, SP 3.3 (Analizar requisitos)
4. Arquitectura inicial	Definir la visión de la arquitectura inicial: - Manual de arquitectura + stack tecnológico - Plan de pruebas - Hacer un plan de gestión de datos que se adhiera a políticas de gestión de datos, y revisarlo periódicamente para asegurar su cumplimiento	Team members	PP, SP 2.3 (Planificar la gestión de los datos), PP, SP 3.1 (Revisar los planes que afectan al proyecto). , PP, SP 1.1 (Estimar el alcance del proyecto).
5. WBS y Work Items	En base a los tres puntos anteriores, seguir la Guía para elaborar un WBS (Work Breakdown Structure) y define la "work items list" inicial con todas las tareas.	Todo el equipo	PP, SP 2.3 (Planificar la gestión de los datos), PP, SP 3.1 (Revisar los planes que afectan al proyecto). , PP, SP 1.1 (Estimar el alcance del proyecto).
6. Recursos y capacitación	Seguir la guía de recursos y capacitaciones para crear un plan de recursos y capacitaciones.	Todo el equipo	PP, SP 2.4, PP 2.5 (Planificación del proyecto y habilidades), PP, SP 3.1 (Revisar los planes que afectan al proyecto).
7. Visión inicial	Identificar la necesidad real del proyecto, con el fin de establecer la misión, visión, valores y objetivos iniciales del equipo.	Project Manager, Cliente	RD SP 1.1 (Educir las necesidades)
8. Planeación y organización inicial	Definir el ciclo de vida que se va a seguir considerando las ventajas y desventajas según la guía de ciclos de vida.	Architecture Owner	PP SP 1.3 (Definir las fases del ciclo de vida del proyecto), OPD SP 1.2 (Modelos de ciclo de vida)
9. Plan de proyecto	Llenar la plantilla de Plan de Proyecto con base en las tareas del Work Items List.	Team Lead	PP, SP 2.7 (Establecer el plan de proyecto)
	Asignar puntos a cada tarea considerando: - Complejidad y número de interfaces - Volumen de datos - Velocidad - Complejidad del equipo - Elementos de la arquitectura. Si hay desacuerdos, usa la fórmula PERT: (Estimación más optimista + estimación más pesimista + estimación más probable*4 ) / 6.	Todo el equipo	PP, SP 1.2 (Establecer las estimaciones de los atributos de los productos de trabajo y de las tareas)
	Ordenar tareas según fechas fijas, dependencias y prioridad del SRS.	Team Lead, Product Owner	PP, SP 2.1 (Establecer el presupuesto y el calendario)
	Establecer fechas aproximadas con base en la disponibilidad de recursos y, si en algún punto es necesario, hacer ajustes en tareas, tiempos o planes para que los recursos alcancen.	Team Lead, Product Owner	PP, SP 2.1 (Establecer el presupuesto y el calendario), PP, SP 1.2 (Establecer las estimaciones de los atributos de los productos de trabajo y de las tareas), PP, SP 3.2 (Conciliar los niveles de trabajo y de recursos), PMC SP 1.1 (Monitorear parámetros del proyecto)
	Asignar un lider reponsable del éxito de las tareas correspondientes a su área de especialidad.	Team Leader	PP, SP 2.7 (Establecer el plan de proyecto)
Cronograma	En Proyectos/Documentación/Planificación de Docusaurus define fases, hitos y fechas de entrega.	Team Lead	PP, SP 2.1 (Establecer el presupuesto y el calendario) , OPD, SP 1.2
Plan de comunicación	Llenar la plantilla de plan de comunicación con stakeholders con medios y frecuencia de contacto.	Team Lead	PP, SP 2.6 (Planificar la involucración de las partes interesadas)
	Actualizar regularmente el plan de comunicación e involucramiento de los stakeholders para reflejar cambios reales en el equipo o en el proyecto.	Team Lead	PP, SP 2.6 (Planificar la involucración de las partes interesadas), PP, SP 3.1 (Revisar los planes que afectan al proyecto).
Gestión de riesgos	Iniciar la gestión de riesgos siguiendo el proceso de gestión de riesgos.	Team Lead	PP, SP 2.2 (Identificar los riesgos del proyecto), PP, SP 1.3 (Monitorizar los riesgos del proyecto), PP, SP 3.1 (Revisar los planes que afectan al proyecto)
10. Revisión de alineamiento	Asegúrarte que todos los planes tengan una comprensión común del alcance, misión, visión y objetivos. Si la visión o algún plan cambia, actualiza los demás si es necesario. - SRS - Plan de Valor Ganado - Manual de arquitectura - Plan de gestión de datos - Plan de recursos y capacitaciones - Plan de pruebas - Gestión de Riesgos - Plan de comunicación con stakeholders	Todo el equipo	PP, SP 3.1 (Revisar los planes que afectan al proyecto).
11. Compromiso con el plan	Formalizar el compromiso con el plan por parte del equipo y el stakeholder con la siguiente acta.	Project Manager	PMC SP 1.2 (Monitorizar los compromisos), PP, SP 3.3 (Obtener el compromiso con el plan).
12. Validación con el stakeholder	Realizar una presentación "kick-off" para validar la estrategia, discutir puntos clave y alcanzar la milestone "Acuerdo sobre la visón del stakeholder".	Project Manager	PMC SP 1.2 (Monitorizar los compromisos), PP, SP 3.3 (Obtener el compromiso con el plan).
13. Seguimiento y actualización	-Actualizar tareas diariamente. -Reestimar costos según la hoja “Estimación y reestimación de costos” y actualizar la fórmula de “costo estimado” según sea necesario. -Monitorear gráficas de valor ganado y costo acumulado.	Todo el equipo	PMC, SP 1.1 (Monitorizar los parámetros de planificación del proyecto), MA SP 2.1, 2.2, PP, SP 1.4 (Estimar el esfuerzo y el coste), PP, SP 2.1 (Establecer el presupuesto y el calendario)
	Calcular el valor SPI = valor real acumulado / valor planeado. Calcular la desviación con: (1 - SPI) * 100. - 0-15%: Aún es factible el plan. - 15-30%: Se deben analizar y atender los motivos del atraso y tomar decisiones drásticas. - Más del 30%: Es necesaria una re-planeación.	Team Lead	PMC, SP 1.1 (Monitorizar los parámetros de planificación del proyecto), PP, SP 2.1 (Establecer el presupuesto y el calendario), PP, SP 3.1 (Revisar los planes que afectan al proyecto), PP, SP 3.2 (Conciliar los niveles de trabajo y de recursos), REQM SP 1.5, Asegurar el alineamiento entre el trabajo del proyecto y los requisitos

---

¿Cómo se decide qué requisitos aceptar?

Para garantizar que los requisitos definidos sean viables y valiosos para el proyecto, se aplican los siguientes criterios de aceptación:

Criterios de Evaluación

Criterio	Descripción	Prioridad
Viabilidad técnica	¿Contamos con las capacidades técnicas para desarrollarlo?	Alta (Obligatoria)
Viabilidad temporal	¿Contamos con el tiempo necesario para implementarlo?	Alta (Obligatoria)
Valor al negocio	¿El requisito aporta valor al proyecto?	Alta (Obligatoria)
Alineación estratégica	¿Se alinea con la necesidad del socio?	Media (Recomendable)
Esfuerzo requerido	¿Requiere un esfuerzo proporcional al beneficio que aporta?	Media (Recomendable)

Reglas para la Aceptación

• Un requisito será aceptado si cumple los tres criterios obligatorios:
  Viabilidad técnica, Viabilidad temporal y Valor al negocio.
• Se recomienda que además cumpla al menos uno de los dos criterios restantes (Alineación estratégica o Esfuerzo requerido), para priorizarlo dentro del desarrollo.

---

Salidas

1. Sección de roles departamentales y lineamientos de liderazgo en los Acuerdos de trabajo
2. Documento de involucramiento de stakeholders
3. Especificación de Requisitos de Software (SRS)
4. Juntas con stakeholders
5. Historias de usuario desglozadas y priorizadas
6. MVP y MBI definido
7. Manual de arquitectura + stack tecnológico
8. Plan de pruebas
9. Plan de gestión de datos
10. Estructura de descomposición del trabajo (WBS) del proyecto
11. Plan de recursos y capacitaciones
12. Documentación de misión, visión, valores y objetivos iniciales del equipo
13. Ciclo de vida del proyecto definido
14. Plan de valor ganado con lista de tareas priorizadas, estimadas y con fechas
15. Plan de comunicación con stakeholders
16. Matriz de riesgos actualizada
17. Acta de compromiso con el plan firmada

---

Historial de Cambios

Tipo de Versión	Descripción	Fecha	Colaborador
1.0	Creación del proceso	4/3/2025	Valeria Zúñiga, Max Toscano, Carlos Fonseca, Mariana Juárez, Sofía Osorio, Diego Alfaro, Arturo Sánchez, Juan Eduardo Rosas, Pablo Hurtado, Juan Carlos Calderón, Emiliano Gómez González, Angel Mauricio Ramirez
1.1	Correcciones de ortografía y redacción		Carlos Iván Fonseca Mondragón
1.2	Adición del formato de Compromiso con el plan		Juan Pablo Chávez Leal, Rommel Toledo Crespo
1.3	Adición de la hoja de Disponibilidad de Recursos		Carlos Iván Fonseca Mondragó, Miguel Angel Uribe Esquivel
1.4	Añadir PMC 1.1 a fases faltantes		Daniel C. y Juan Pablo C.
1.5	Definición de cuándo y cómo decidimos qué requisitos aceptar	07/4/2025	Angélica Ríos Cuentas
1.6	Agregar SG 3.1 de PP	8/4/2025	Mariana Juárez Ramírez
1.7	Refactorización	18/4/2025	Diego Fuentes
1.8	Correcciones de PMC y REQM	22/04/2025	Juan Pablo Chávez Leal
1.9	Correcciones de auditoria del 26 de abril del 2025.	26/04/2025	Paola María Garrido Montes
2.0	Plan de Datos	28/04/2025	Pablo Hurtado
2.1	Integración de versiones	28/04/2025	Diego Fuentes
2.2	Agregar subpráctica OPD1.2	13/05/2025	Nicolas Hood
3.0	Modificación del proceso acorde al CMMI y simplificación	16/05/2025	Valeria Zúñiga, Paola Garrido