Acta del Proyecto Talent 360
v 2.2
Acerca de CR Organizacional
CR Organizacional es una empresa de consultoría dedicada al desarrollo y gestión de talento. Su propósito es ayudar a los colaboradores de distintas empresas a alcanzar su mejor versión.
Necesidad
Automatizar la aplicación de los diagnósticos organizacionales y la generación de reportes, a fin de profesionalizar sus servicios y ofrecerle una mejor experiencia a sus cliente
Misión
Atender la ineficiencia en el proceso de diagnóstico de los colaboradores, junto con la falta de personalización en los formularios de captura de datos y en los planes de desarrollo.
Objetivos
- Reducir en un 30% el tiempo invertido en la generación de reportes por parte del equipo dedicado a la consultoría y desarrollo organizacional de CR.
Alcance y restricciones
Creación, asignación y retroalimentación de formularios, para evaluar el desempeño de los colaboradores de las empresas cliente de CR Organizacional de manera intregral.
- El uso del software requiere conexión a internet.
- El sistema es desarrollado en Odoo Community v 17.
- El sistema se verá restringido al soporte que Odoo presente.
Stakeholders
| Categoría | Encargado |
|---|---|
| Customer or Client | CR Organizacional |
| Project Core Team | Black Dot |
| Program Manager | Denisse Dominguez y Alejandra Cabrera |
| Product Owner | Diego Vega |
| Team Lead | Mafer Moreno |
| Architecture Owner | Ricardo Rosales |
| Project Team Member | Juan Pablo Cabrera, David Langarica, Miguel Angel Tena, José Riosmena, Daniel Fuentes, Carlos Velasco, Daniel Cajas, Diego Llaca, Uri Gopar, Damariz Licea |
Matriz de Stakeholders CR
Entregables
- Código fuente
- Manual de Usuario
- Manual de Arquitectura
- Perfil de desarrollador
- Acta del proyecto
Ciclo de vida del proyecto
El proyecto seguirá el ciclo de vida básico de Disciplined Agile Delivery (DAD):
Objetivos de cada fase
Cada una de las fases mencionadas en el ciclo anterior tienen diferentes objetivos. Es importante mencionar que se tienen tantas fases de construcción y transición como productos (MVP, MBI).
| Fase | Objetivos |
|---|---|
| Inicio | Formar el equipo inicial |
| Desarrollar una visión común | |
| Alinear el proyecto con la dirección de la empresa | |
| Explorar el alcance inicial | |
| Identificar la estrategia técnica inicial | |
| Desarrollar el plan inicial de liberaciones | |
| Asegurar el financiamiento | |
| Formar el ambiente de trabajo | |
| Identificar riesgos | |
| Desarrollar la estrategia inicial de pruebas | |
| Construcción | Probar la arquitectura temprano |
| Producir una solución potencialmente consumible | |
| Encargarse de las necesidades cambiantes del stakeholder | |
| Mantener o mejorar los niveles existentes de calidad | |
| Acercarse a la visión desplegable | |
| Transición | Asegurarse que la solución está lista para producción |
| Desplegar la solución hacia producción | |
| Constantemente | Lograr la misión del proyecto |
| Desarrollar las habilidades del equipo | |
| Aprovechar y mejorar la infraestructura existente | |
| Manejar el riesgo | |
| Mejorar los procesos del equipo y el ambiente |
Iteraciones del proyecto
Hitos del Proyecto
| Entrega | Hitos | Fecha Planeada |
|---|---|---|
| Inicio | ¿El stakeholder está de acuerdo con tu estrategia? | 11/03/2024 |
| ¿Realmente puedes construir la solución propuesta? | 12/04/2024 | |
| MVP | ¿El proyecto sigue teniendo sentido? | 01/05/2024 |
| ¿Tiene sentido liberar la solución actual? | 08/05/2024 | |
| ¿La solución va a funcionar en producción? | 14/05/2024 | |
| ¿Están contentos los stakeholders con la solución desplegada? | 21/05/2024 | |
| MBI 1.0 | ¿El proyecto sigue teniendo sentido? | 24/05/2024 |
| ¿Tiene sentido liberar la solución actual? | 27/05/2024 | |
| ¿La solución va a funcionar en producción? | 28/05/2024 | |
| ¿Están contentos los stakeholders con la solución desplegada? | 31/05/2024 | |
| MBI 2.0 | ¿El proyecto sigue teniendo sentido? | 04/06/2024 |
| ¿Tiene sentido liberar la solución actual? | 07/06/2024 | |
| ¿La solución va a funcionar en producción? | 11/06/2024 | |
| ¿Están contentos los stakeholders con la solución desplegada? | 14/06/2024 |
Arquitectura
Propuesta elegida:
Utilizar la arquitectura de Odoo (framework de Python) por que los socios formadores la utilizan en sus operaciones de empresa y nosotros, a pesar de no conocer la tecnología, creemos que lo mejor es adaptarnos a la arquitectura de Odoo, ya que una ventaja muy importante es que podemos utilizar las funcionalidades ya existentes para desarrollar nuestro módulo de evaluaciones.
Otras propuestas:
Utilizar la arquitectura de React (biblioteca de Javascript) junto a un sistema de base de datos (como MariaDB). Esta propuesta se rechazó por que consideramos que a largo plazo resultaa muy costoso (nos íbamos a tardar mucho tiempo en desarrollar toda la solución) porque sería empezar el proyecto desde cero (a comparación de utilizar Odoo) y entrenar a los stakeholders con las nuevas tecnologías que implementaríamos.
Planeación y Riesgos del Proyecto
En el Plan de Valor Ganado se puede encontrar la planeación de cada iteración y los items de trabajo. Se encuentra el dashboard del proyecto con las gráficas de costo real vs. costo planeado, valor ganado vs. valor planeado, calidad y la división de las horas invertidas.También en otra pestaña está el seguimiento a los riesgos.
Control de cambios
| Versión | Cambio | Autor del cambio | Revisado por | Fecha de cambio |
|---|---|---|---|---|
| v 1.0 | Creado | Alejandra Cabrera, Diego Vega, David Langarica, Carlos Velasco | 28/02/2024 | |
| v 2.0 | Actualización del Acta de Proyecto y Stakeholders | Alejandra Cabrera | Carlos Velasco | 23/04/2024 |
| v 2.1 | Corrección ortográfica y refraseo | Mike Tena, Damariz Licea | 23/04/2024 | |
| v 2.2 | Actualización del nombre del producto de trabajo | Panda | 30/04/2024 |