Procedimiento para reunión de kickoff

La reunión de kickoff es el punto de arranque para el proceso de Gestión de Plataformas que se modela con una RFP. Esta reunión es un foro común entre los interesados en el proceso.

Los objetivos de esta reunión son:

• Acordar y/o comunicar de forma lo más detallada posible los objetivos y requisitos del proyecto (plazos, alcance, pruebas, etc.).
• Identificar participantes, y en general a los interesados del proyecto.
• Identificar riesgos y limitaciones del proyecto.
• Avanzar en el diseño y/o la arquitectura de la solución, y propuesta de alternativas.
• Si aplica, definir un plan de comunicación.
• Incluso, se puede llegar a la conclusión de que no es necesario crear una Plataforma o modificar sustancialmente una existente, sino que la solución es más simple y se puede implementar con la ejecución de una o varias PLs. Igualmente, en el caso de que se necesite hacer un estudio y/o una prueba de concepto, la solución pasaría por una SVT.

Se puede resumir la operativa en los siguientes puntos:

• Se detecta la necesidad de una nueva infraestructura o de modificar sustancialmente una existente para dar soporte a una aplicación/servicio. RESPONSABLE PRODUCTO

• El Responsable de Producto (promotor) identifica los grupos de la STIC necesarios para la asistencia al Kickoff por su involucramiento en el proyecto (ver la estructura de las áreas en el gráfico) , pudiendo añadirse más actores interesados durante las distintas reuniones que puedan producirse en el proceso del Kickof . Hay que tener en cuenta que los señalados en azul siempre son obligatorios. RESPONSABLE PRODUCTO

• Se debe preparar una agenda de reunión y un borrador del DGT (puedes acceder a la plantilla aquí, en los entregables de las órdenes de trabajo de la sección Plantillas) con los objetivos y alcance de la RFP, que detalle todo lo posible los requerimientos técnicos, que se distribuirá en la convocatoria del ‘Kick-off meeting’. PROVEEDOR o RESPONSABLE PRODUCTO

• El Responsable de Producto (promotor) convoca a los representantes del producto que estime oportunos, a su homólogo en el Área de Sistemas,  Infraestructuras y Comunicaciones (RAN), que será el Responsable de Sistemas de la aplicación que se desplegará en la plataforma,  y a los actores identificados en el punto 2. RESPONSABLE PRODUCTO

• El RAN reenvía la convocatoria a los diseñadores/constructores pertinentes (representantes de CTI). RAN/RESPONSABLE SISTEMAS

• Se mantienen las sesiones pertinentes tras la que se autoriza el arranque de la RFP, con un DGT que se adaptará a los acuerdos conseguidos y recogerá objetivos y alcance inicial. El arranque estará supeditado a la aceptación de requisitos previos por el Área de Sistemas, Infraestructura y Comunicaciones. TODOS

• Registro de la RFP  (en el proyecto de la plataforma en JIRA, no en el de la aplicación) y comienzo del proyecto, que comenzará con la fase de estudio y aprobación de la RFP. RESPONSABLE PRODUCTO o PROVEEDOR