Interacciones con las partes interesadas

Como BA de Pega, colabora con una o más de las siguientes partes interesadas del proyecto para garantizar que exista una alineación constante entre los equipos de proyecto de negocio y de TI:

• Product Owner (PO): El Product Owner (PO) es uno de los representantes del cliente en el equipo de negocio del proyecto. El PO es el principal responsable de gestionar el alcance del proyecto y priorizar los requerimientos a lo largo del proceso de desarrollo de software. Los BA de Pega colaboran estrechamente con la orden de compra para garantizar que su aplicación de Pega Platform™ entregue los resultados estratégicos del proyecto en el plazo esperado.

• Project Delivery Lead (PDL): el Project Delivery Lead (líder de ejecución de proyectos) de Pega, a veces conocido como gerente de proyectos, es el principal responsable de liderar el equipo de entrega de Pega, mantener la gobernanza del proyecto y servir de enlace con el equipo de liderazgo del cliente. Los BA de Pega colaboran estrechamente con el Project Delivery Lead (PDL) para garantizar que el proyecto se ajuste a tiempo, dentro del presupuesto y del alcance, de modo que las partes interesadas, tanto del equipo de negocio como de TI, estén alineadas en sus expectativas en cuanto al cronograma y el costo de las entregas del proyecto.

• Scrum Master: El Scrum Master es responsable de promover y respaldar Scrum, un framework de entrega de software basado en Agile. El Scrum Master es responsable de organizar el equipo de Scrum, facilitar las ceremonias de Scrum que incluyen la planificación de sprints, el dimensionamiento, el refinamiento del backlog y las reuniones retrospectivas, y es responsable del éxito del equipo de Scrum. 

• System Architects (SA): los System Architects son los desarrolladores de Pega en el equipo del proyecto que configuran las aplicaciones de Pega. Los SA utilizan las historias de usuario creadas por los BA para configurar la aplicación. Los BA de Pega traducen la información técnica proporcionada por los SA a las partes interesadas del negocio para garantizar que comprendan la aplicación en desarrollo y que cumpla con sus requerimientos.

• Quality Analysts (QA): Los Quality Analysts (analistas de calidad) se aseguran de que la funcionalidad de la aplicación cumpla con los requerimientos del negocio documentados. Mediante user stories (historias de usuario) escritas por los BA de Pega como punto de partida para su trabajo, los QA crean scripts de prueba y pruebas de escenario que confirman que la aplicación funciona según lo esperado. Los QA también participan en rituales de Scrum, como sesiones de refinamiento y dimensionamiento, para garantizar que el tiempo y el esfuerzo asociados con las pruebas de la aplicación se dimensionen adecuadamente.

• Subject Matter Experts (SME): Los Subject Matter Experts son representantes de la organización cliente en el equipo del proyecto que tienen un profundo conocimiento de primera mano de los pasos requeridos en el proceso de negocio. Los SME proporcionan los requisitos operativos y funcionales específicos asociados con estos pasos. Los BA de Pega colaboran con los SME, por lo general en un tutorial operativo, para observar a los usuarios finales que navegan por el proceso y las aplicaciones "as-is" (tal cual). El BA de Pega trabaja con los SME para comprender todo el trabajo (tanto dentro como fuera del sistema) que los usuarios finales deben realizar para satisfacer las necesidades del cliente y el resultado estratégico deseado. 

• Business Analysts: Los Business Analysts (analistas de negocios) son representantes de la organización cliente en el equipo del proyecto. El Business Analyst es el principal responsable de documentar el proceso actual "as-is" (tal cual), los requerimientos de datos y los requerimientos del negocio. Los BA de Pega colaboran con los Business Analyst para recolectar y revisar esta documentación a fin de identificar oportunidades de mejora, incluida la eliminación de redundancias y cuellos de botella, la recomendación de automatizaciones de flujo de trabajo, la determinación de las necesidades de recursos y la definición de detalles técnicos, como los requerimientos de datos e interfaz.

• Diseñadores de UX: El diseñador de UX garantiza que el diseño de la aplicación satisfaga las necesidades del usuario final, cumpla con los estándares de accesibilidad y ofrezca una experiencia uniforme en todos los canales de entrega de aplicaciones. Los BA de Pega colaboran con el diseñador de UX para diseñar la interfaz de usuario que se alinee con los requisitos de experiencia del usuario, maximice el uso de las funciones listas para usar de Pega y cumpla los objetivos estratégicos del negocio.

El tamaño y la estructura de un equipo de proyecto varía de un proyecto a otro, y es posible en proyectos más pequeños que algunos miembros del equipo desempeñen más de un rol; por ejemplo, el Business Architect puede tener que actuar como Product Owner del proyecto.

Independientemente de la combinación exacta de partes interesadas de su proyecto, es importante que usted, como BA de Pega, garantice la alineación entre estas áreas de responsabilidad en todo el equipo del proyecto. Esta es la única manera de asegurarse de que el proceso de negocio transformado cumpla con sus objetivos estratégicos de la manera más eficiente y rentable posible. 

En la siguiente figura, haga clic en los íconos + para obtener más información sobre cómo interactúa con las partes interesadas del proyecto para lograr la alineación: 

Como Business Architect de Pega, usted es un enlace crucial entre las partes interesadas del proyecto, y trabaja constantemente para garantizar que estén comprometidas, alineadas y se comuniquen de manera efectiva.   

Para enfrentar el reto de guiar a los equipos de negocios y TI para que colaboren, creen soluciones innovadoras y logren resultados de negocio, combine su experiencia con lo siguiente:

• Habilidades analíticas y de resolución de problemas para desglosar procesos de negocio complejos e identificar oportunidades de mejora y simplificación.

• Habilidades de diseño de procesos y conocimiento del diseño de procesos de negocio para innovar nuevos procesos y formas de trabajar a fin de obtener el resultado del negocio. 

• Conocimientos de diseño de sistemas y tecnología de Pega para alinear los requerimientos del negocio y las necesidades del usuario final con las funciones listas para usar de Pega. 

• Habilidades activas de escucha, comunicación y facilitación para crear un lenguaje común y una comprensión tanto de las necesidades del negocio como de las capacidades de Pega entre el equipo del proyecto y otras partes interesadas. 

• Conocimiento de los cambios empresariales para ayudar a su equipo de negocio a adoptar la nueva solución de Pega y convertirse en defensores de la nueva solución en su organización.