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 líder de ejecución de proyectos 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. La familia System Architect incluye System Architects (SA), Senior System Architects (SSA) y Lead System Architects (LSA). Los System Architects colaboran con BA de Pega y partes interesadas del negocio para desarrollar la aplicación utilizando Pega GenAI Blueprint™. Los LSA son responsables de importar el archivo Blueprint al entorno de Pega Platform y utilizarán las historias de usuario creadas por Blueprint y Pega BA para configurar los requerimientos funcionales y técnicos de la aplicación. Los BA de Pega traducen la información técnica proporcionada por los System Architect 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 analistas de calidad se aseguran de que la funcionalidad de la aplicación cumpla con los requerimientos del negocio documentados. Mediante historias de usuario escritas por los BA de Pega como punto de partida para su trabajo, los analistas de calidad 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 "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 analistas de negocios (Business Analysts) son representantes de la organización cliente en el equipo del proyecto. El analista de negocios es el principal responsable de documentar el proceso actual "tal cual", los requerimientos de datos y los requerimientos del negocio. Los BA de Pega colaboran con los analistas de negocios 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.

• Solutions Consultant: El Solutions Consultant trabaja con el cliente durante las fases iniciales del proceso de venta. En muchos casos, el Solutions Consultant diseña el Blueprint en colaboración con las partes interesadas del negocio. Si el cliente avanza en el proceso de ventas, el Solutions Consultant realizará la transición del Blueprint a los Business Architects y System Architects de Pega responsables de la entrega del proyecto antes del inicio del mismo.

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:  

Para apoyar el desarrollo de aplicaciones eficiente y escalable, Pega Platform™ ofrece potentes herramientas para gestionar la colaboración y la configuración. Los espacios de trabajo y la ramificación ayudan a los equipos a organizar su trabajo, mantener el control de versiones y agilizar el ciclo de vida del desarrollo.  Los espacios de trabajo proporcionan entornos personalizados para diferentes roles y tareas dentro del proyecto, mientras que la ramificación permite a los desarrolladores aislar los cambios antes de fusionarlos en un ruleset compartido. En conjunto, estas características garantizan que los esfuerzos de desarrollo permanezcan alineados, seguros y adaptables a las necesidades cambiantes de los proyectos.

Espacios de trabajo

Los espacios de trabajo en Pega Platform ofrecen un espacio seguro y enfocado para que las partes interesadas involucradas en el desarrollo de aplicaciones construyan y administren funciones de aplicaciones de forma independiente. Cada espacio de trabajo está vinculado a un operador específico con acceso para desarrolladores y está asociado exclusivamente a una aplicación.

Dentro de una aplicación, cada operador tiene un espacio de trabajo creado de forma predeterminada, pero un operador puede crear varios espacios de trabajo dentro de esa aplicación. Los cambios permanecen privados dentro de un único espacio de trabajo hasta que se comparten con una sucursal, lo que ayuda a evitar conflictos de reglas cuando varios desarrolladores trabajan en la misma aplicación.

Cada espacio de trabajo pertenece a una aplicación y un operador. Los desarrolladores pueden crear y cambiar entre varios espacios de trabajo, que solo muestran sus propios cambios. Algunos tipos de reglas pueden requerir acceso a Dev Studio según los permisos.

Los espacios de trabajo están disponibles en App Studio y Dev Studio y se pueden habilitar con la configuración EnableWorkspace. 

El siguiente tema contiene información que es importante para su comprensión de los espacios de trabajo y para aprobar el examen de certificación de Business Architect: Developing Applications in Workspaces.

Ramas

Pega Platform™ utiliza ramas para ayudar a los equipos a manejar el desarrollo paralelo en entornos distribuidos. Una rama es un contenedor de rulesets con registros que se someten a desarrollo y cambios rápidos. 

Las ramas son muy útiles para proyectos de desarrollo tanto a gran escala como a pequeña escala, donde uno o más equipos trabajan de manera simultánea en las reglas de una aplicación. Las ramas benefician también el desarrollo de características cuando el tiempo de finalización de cada una es distinto. Una estrategia frecuente a la hora de crear una aplicación en Pega Platform es crear una rama para cada característica que desarrolle su equipo. Una rama dedicada a cada característica le permite a su equipo desarrollar cada característica de forma independiente en un espacio aislado (la rama) sin afectar a los otros equipos. Por ejemplo, su equipo crea una rama para cambiar las propiedades en un formulario y crea otra rama para cambiar una sección de UI. Los cambios no afectan a los otros equipos hasta que sean cambios estables, se resuelvan los conflictos y se otorgue la aprobación para hacer que los cambios estén disponibles para todos los equipos de desarrollo.

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, tecnología de Pega y Blueprint 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.