Fases del proyecto

Completado

Normalmente las metodologías de implementación dividen un proyecto general en partes más pequeñas, lo que le permite realizar un seguimiento más fácil de la progresión. En general, independientemente de la metodología específica que se utilice, estas partes más pequeñas del proyecto se denominan también sprints o iteraciones. Sea cual sea su nombre, estos fragmentos más pequeños del proyecto son un hito en la progresión del proyecto cuando finaliza su ejecución.

El tiempo que se dedique a cada fase y a cada proyecto variará mucho. Algunos proyectos pasan de la fase de idea a la de funcionamiento en solo unos meses, mientras que otros requieren al menos un año de detección antes de que el trabajo pueda iniciarse.

Las fases del proyecto varían a medida que avanza el proyecto. Si la metodología utilizada en el proyecto es ágil, puede repetir fases de la ruta, desde la preventa hasta el funcionamiento.

Normalmente, un proyecto seguirá una ruta: preventa, inicio, implementación, despliegue y funcionamiento.

Algunos miembros del equipo están especializados en una fase; sin embargo, muchos miembros del equipo del proyecto tienen un rol flotante y acuden al punto del proyecto donde se les necesita. Es normal que los miembros de un equipo se unan a un proyecto en cualquier punto situado entre la fase de la idea y la de implementación.

Preventa

La actividad principal de la preventa es apoyar al equipo de ventas a conseguir el proyecto. En la preventa, la atención se centra en el mínimo esfuerzo necesario para obtener el proyecto y, al mismo tiempo, en asegurarse de que el equipo de ventas no venda más de lo que se puede proporcionar. Las actividades de esta fase de interacción se pueden clasificar principalmente de la siguiente manera:

• Respuestas a solicitudes de propuestas (RFP)
• Reuniones introductorias con el cliente
• Prueba de conceptos o demostraciones
• Planificación de soluciones

Inicio

Mientras el proyecto avanza en la fase de diseño de la solución, el arquitecto de soluciones lo dirige. Según la metodología que se use, parte de este trabajo podría completarse por adelantado o, más frecuentemente, realizarse con cada sprint o iteración en proyectos más ágiles.

• Talleres de clientes: estos requisitos reflejan las reuniones con los usuarios profesionales que trabajan para conseguir una comprensión en profundidad de sus necesidades.
• Validación y aclaración de requisitos: revise los requisitos detallados que se han recogido, incluidos los especificados como historias de usuario. El objetivo es garantizar que sean requisitos implementables, claros y concisos. En este proceso, el equipo debe intentar detectar requisitos no funcionales y agregarlos en función de las necesidades. Esta tarea puede requerir un seguimiento adicional con el cliente o el equipo para garantizar la comprensión de los requisitos antes de la creación de una solución.
• Arquitectura general: el arquitecto de soluciones dirige el diseño de la topología general de la solución y se encarga de comunicar esta información al equipo del proyecto en general. En esta evaluación, se incluye todo servicio de Dynamics 365, Microsoft AppSource u otros servicios externos que se vayan a utilizar, incluida una visión amplia de las interacciones con los sistemas y servicios internos y externos.
• Arquitectura detallada de la solución: este es el proceso donde se definen más detalles. Incluye el diseño de los modelos de seguridad y datos, así como la estrategia de integración general de cada sistema y servicio externo. Además, en este proceso se incluye la especificación de las personalizaciones de las aplicaciones de Dynamics 365 y cualquier otra aplicación ya existente que se vaya a utilizar. Los equipos del proyecto suelen usar un análisis de lagunas para detectar las posibles lagunas existentes entre los requisitos y las capacidades listas para usar.
• Revisión de diseños técnicos: cuando la arquitectura empiece a entrar en los diseños más detallados realizados por el equipo del proyecto en general, el arquitecto de soluciones asumirá el rol de revisor para asegurarse de que los diseños se ajusten a la arquitectura deseada.
• Gestión de cambios: la gestión de cambios es un elemento clave para garantizar la elaboración de soluciones realizadas puntualmente y dentro del presupuesto que harán que los clientes disfruten. El equipo debe evitar las dudas y cambios en el ámbito cubierto, todo ello sin dejar de permitir cambios que sean fundamentales para cumplir los criterios de éxito del proyecto. La gestión de cambios excepcionales es necesaria a partir de este momento en el proyecto.

Implementación

En la fase de implementación, el equipo del proyecto se centra en compilar la solución conforme al diseño y ámbito de la solución acordados. Las revisiones de implementación se introducen en esta fase. Estas revisiones son útiles para que el equipo aborde en profundidad las cuestiones relacionadas con aspectos específicos del diseño de la solución (modelo de datos, seguridad, integración) y las prácticas de implementación (administración del ciclo de vida de las aplicaciones y estrategia de pruebas). Durante la fase de implementación, puede esperar que se le formulen preguntas relativas al diseño de componentes específicos, opciones de tecnología, cambios previstos, la hoja de ruta, la puesta en desuso de elementos, la administración del ciclo de vida de las aplicaciones (ALM) y la compilación. Trabaje proactivamente con los clientes para asegurarse de que la solución desarrollada siga los procedimientos recomendados y que, estratégicamente, concuerde con la hoja de ruta del producto.

Despliegue

En la fase de despliegue, la solución ya se ha desarrollado y probado, y el equipo del proyecto se está preparando para la ronda final de pruebas de aceptación de usuario (UAT) y formación. Además, se han concedido todas las aprobaciones necesarias del cliente, se han realizado las revisiones de seguridad de la información, se ha definido el plan de transición (incluidos los criterios de si proceder o no), se han programado eventos de puesta en marcha de prueba, el modelo de soporte está listo y el runbook de despliegue se ha completado con tareas, propietarios, duraciones y dependencias definidas.

Funcionamiento

Ahora ya ha planificado, desarrollado e implementado la aplicación, pero todavía no ha terminado. El objetivo de la fase de funcionamiento es validar que el despliegue se haya realizado bien, revisar las lecciones que se han aprendido con el proyecto y planificar la transición a la siguiente fase, o bien proporcionar soporte de transición al equipo de mantenimiento. Una vez que el cliente esté activo, el arquitecto de soluciones debe realizar una revisión posterior a la puesta en marcha. Discuta el plan de transición y compártalo con el equipo de mantenimiento.