🏇 Planear y mantener un proyecto
Este proceso define cómo planear un proyecto desde su inicio y cómo asegurar su mantenimiento alineado con los objetivos organizacionales y las necesidades del stakeholder. Establece criterios claros para aceptar requisitos, detalla los entregables y conecta las prácticas con el modelo CMMI.
🎯 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
- Proyecto inicial con un cliente
- Juntas con stakeholders
- Plantilla del Plan de Proyecto
- Plantillas de: SRS, Plan de Gestión de Datos, Plan de Pruebas, Plan de Comunicación, Plan de Recursos, gits, Plan de Capacitación
- Política de gestión de datos y estándar de arquitectura
- 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), RD, SP1.2 (Transformar las necesidades de las partes interesadas en requisitos.) |
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) RD SP2.1 (Establecer requisitos del producto y de los componentes del producto) |
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.), RD, SP1.2 (Transformar las necesidades de las partes interesadas en requisitos.) | |
4. Priorización de requisitos | En base a la información recopilada define los requisitos del proyecto. Consulta la sección ¿Cómo se decide qué requisitos aceptar? para apoyarte. | Team members | REQM SP 1.1 (Comprender los requisitos), RD SP2.1 (Establecer requisitos del producto y de los componentes del producto) |
Crea una copia de la Plantilla de requerimientos y sigue la guía para completarla. Asegurate de haber cumplido con lo siguiente: | Team members | REQM SP 1.1 (Comprender los requisitos) RD SP2.1 (Establecer requisitos del producto y de los componentes del producto) RD SP 3.4 (Analizar los requisitos para conseguir un equilibrio) | |
Revisar y organizar las historias de usuario según su relevancia, viabilidad y riesgos. Aplicar la técnica MoSCoW para priorizar. | Product Owner | PPQA, SP 1.2 Evaluar objetivamente los productos de trabajo y los servicios | |
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) | |
5. Identificar requisitos de interfaz | Identificar los distintos tipos de interfaces del sistema (usuario, internas entre módulos, externas con otros sistemas, hardware) y documentarlas claramente. | Team members, Architecture Owner | RD SP 2.3 (Identificar requisitos de interfaz) |
Iniciar con el diseño de interfaces de usuario usando herramientas como Figma. | Todo el equipo | RD SP 2.3 (Identificar requisitos de interfaz) | |
Generar una tabla de requisitos de interfaz que detalle: componente origen, destino, tipo de datos, protocolo o medio, condiciones funcionales y no funcionales. | Todo el equipo | RD SP 2.3 (Identificar requisitos de interfaz) | |
Asociar cada diseño Figma a requisitos funcionales correspondientes en el SRS para asegurar trazabilidad. | Todo el equipo | RD SP 2.3 (Identificar requisitos de interfaz) | |
6. Arquitectura inicial | Definir la visión de la arquitectura inicial: - Siguiendo el proceso, crear el Manual de arquitectura + stack tecnológico - Plan de pruebas - Seguir el proceso para crear la Estrategia técnica inicial - 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). RD SP2.1 (Establecer requisitos del producto y de los componentes del producto). TS, SP 2.1 (Diseñar el producto o los componentes de producto). |
7. 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). |
8. 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). |
9. 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), RD, SP1.2 (Transformar las necesidades de las partes interesadas en requisitos.) |
10. Planeación y organización inicial | Definir el ciclo de vida que se va a seguir considerando las ventajas y desventajas según laguí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) |
11. 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) |
12. 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). |
13. Compromiso con el plan | Formalizar el compromiso con el plan por parte del equipo y el stakeholder con la siguiente acta. Añadirla a Google Drive dentro de la carpeta correspondiente según la Guía de Documentación de Google Drive. | Project Manager | PMC SP 1.2 (Monitorizar los compromisos), PP, SP 3.3 (Obtener el compromiso con el plan). |
14. 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), RD, SP1.2 (Transformar las necesidades de las partes interesadas en requisitos.) |
15. 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), PPQA, SP 1.2 Evaluar objetivamente los productos de trabajo y los servicios |
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 y se debe de aplicar el Proceso de acciones correctivas. | Team Lead | PMC SP 1.1 (Monitorizar los parámetros de planificación del proyecto) PMC SP 2.1 (Analzar la cuestiones) 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 PPQA P 1.2 Evaluar objetivamente los productos de trabajo y los servicios |
✔️ 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) |
📤 Salidas
- Sección de roles departamentales y lineamientos de liderazgo en los Acuerdos de trabajo
- Documento de involucramiento de stakeholders
- Especificación de Requisitos de Software (SRS)
- Historias de usuario desglozadas y priorizadas
- MVP y MBI definido
- Manual de arquitectura + stack tecnológico
- Plan de pruebas
- Plan de gestión de datos
- Estructura de descomposición del trabajo (WBS) del proyecto
- Plan de recursos y capacitaciones
- Documentación de misión, visión, valores y objetivos iniciales del equipo
- Ciclo de vida del proyecto definido
- Plan de valor ganado con lista de tareas priorizadas, estimadas y con fechas
- Plan de comunicación con stakeholders
- Matriz de riesgos actualizada
- Acta de compromiso con el plan firmada
- Tabla de requisitos de interfaz (usuario, técnica, interna, externa)
- Diseños Figma vinculados a requisitos funcionales
📎 Recursos relacionados
📚 Historial de cambios
Versiones
Versión | Descripción | Fecha | Colaborador |
---|---|---|---|
1.0.0 | Creación inicial del proceso | 04/03/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 Ramírez |
1.1.0 | Correcciones de ortografía y redacción | (fecha) | Carlos Iván Fonseca Mondragón |
1.2.0 | Adición del formato de compromiso con el plan | (fecha) | Juan Pablo Chávez Leal, Rommel Toledo Crespo |
1.3.0 | Adición de la hoja de disponibilidad de recursos | (fecha) | Carlos Iván Fonseca Mondragón, Miguel Ángel Uribe Esquivel |
1.4.0 | Añadir PMC 1.1 a fases faltantes | (fecha) | Daniel Contreras Chávez, Juan Pablo Chávez Leal |
1.5.0 | Definición de cuándo y cómo decidimos qué requisitos aceptar | 07/04/2025 | Angélica Ríos Cuentas |
1.6.0 | Agregar SG 3.1 de PP | 08/04/2025 | Mariana Juárez Ramírez |
1.7.0 | Refactorización | 18/04/2025 | Diego Fuentes |
1.8.0 | Correcciones de PMC y REQM | 22/04/2025 | Juan Pablo Chávez Leal |
1.9.0 | Correcciones de auditoría del 26 de abril de 2025 | 26/04/2025 | Paola María Garrido Montes |
2.0.0 | Plan de Datos | 28/04/2025 | Pablo Hurtado |
2.1.0 | Integración de versiones | 28/04/2025 | Diego Fuentes |
2.2.0 | Agregar subpráctica OPD1.2 | 13/05/2025 | Nicolás Hood |
3.0.0 | Modificación del proceso acorde a CMMI y simplificación | 16/05/2025 | Valeria Zúñiga, Paola Garrido |
3.1.0 | Agregar PPQA al proceso | 19/05/2025 | Valeria Zúñiga, Paola Garrido |
3.2.0 | Agregar RD1.2 al proceso | 26/05/2025 | Juan Eduardo Rosas Cerón |
3.3.0 | Agregar RD2.1 al proceso | 26/05/2025 | Nicolas Hood Figueroa |
3.3.1 | Correcciones ortográficas y de enlaces | 29/05/2025 | Valeria Zúñiga, Nicolas Hood |
3.4.0 | Mapeo de RD 3.4 y RD 3.5 en el proceso. | 30/05/2025 | Paola María Garrido, Carlos Iván Fonseca Mondragón |
3.5.0 | Mapeo de RD 2.3 Identificación y documentación de requisitos de interfaz | 01/06/2025 | Emiliano Gomez Gonzalez |
3.5.1 | Mapeo de PMC 2.1 en el proceso. | 30/05/2025 | Paola María Garrido, Angel Mauricio Ramírez Herrera |
3.5.2 | Implementar acciones correctivas. | 05/06/2025 | Max Toscano |
3.5.3 | Mapeado procesos para crear un plan de arquitectura y la estrategia técnica. | 05/06/2025 | Emiliano Valdivia |