Project Manager Vs Business Analyst

¿Por qué necesitamos analistas de negocio y administradores de proyectos?

Los roles  El administrador de proyecto asegura entregar el producto al cliente en tiempo, dentro del presupuesto.  El analista de negocio asegura que el producto se construye de acuerdo a los requerimientos del cliente.

Entre los dos…  Asegura que el producto se construye de acuerdo a los requerimientos del cliente en el tiempo y el presupuesto acordados.

El analista de negocio Las soluciones generalmente incluyen un componente de sistema, pero puede contener también una mejora de procesos o un cambio en la organización.

El analista de negocio Es responsable de:  Identificar las necesidades de cliente.  Cerrar la brecha entre las áreas de TI y las usuarias.  Desarrollar y administrar los requerimientos, específicamente, de obtener, analizar, validar y documentar los requerimientos organizacionales y operacionales.  Servir como el arquitecto de la solución junto con el líder técnico.  Observar a la organización desde dentro y fuera.

El reto de ser BA y PM al mismo tiempo  Jugar un rol a la vez!

Diferencias PM Dirige al equipo Ayuda al equipo a realizar las tareas Remueve barreras

BA Escucha al cliente Ayuda al cliente a describir cómo realiza su tareas Identifica factores clave en la organización

La metodología  Business Analysis Body of Knowledge  Análisis de la organización  Planeación y administración de los requerimientos  Obtención de los requerimientos  Análisis y documentación de los requerimientos  Comunicación de los requerimientos  Evaluación y validación de la solución

Requerimiento  Una condición o capacidad necesitada por un grupo de interés para resolver un problema o alcanzar un objetivo  Una condición o capacidad que debe cubrir o poseer un sistema para satisfacer un contrato, estándar,o especificación

Tipos de requerimientos  De negocio u organización  Enunciado de alto nivel de las metas, objetivos y necesidades de la organización

 De usuario  Enunciado de las necesidades de los grupos de interés. Describe cómo el grupo interactúa com la solución.

 Funcionales  Describen el comportamiento y la información que la solución maneja. Describe las capacidades que el sistema es capaz de desempeñar en términos de comportamiento y operación.

Tipos de requerimientos  De calidad de servicio  Captura las condiciones que no están relacionadas a la funcionalidad, pero describe las condiciones del contexto en el que la solución será efectiva y las carácterísticas de calidad del sistema.

 De implementación  Describe las cpaacidades que tendrá la solución para facilitar la transición del estado actual al estado futuro.

 Limitaciones y asunciones

Planeación y administración de los requerimientos  En coordinación con el PM  Tareas:  Identificación de roles  Identificación de grupos de interés  Consulta de material de referencia  Definición de la estrategia de trabajo  Identificación de necesidades y ubicación de los grupos de interés  Determinar el equipo y actividades para la obtención, análisis, documentación y comunicación de requerimientos  Determinar el equipo y las actividades para la evaluación y validación de la solución  Estructurar los requerimientos para trazabilidad

Adminstración del cambio de requerimientos  Quién, cómo y cuándo  Impacto del cambio Proceso del cambio 1. Identificar el cambio 2. Crear la requisición formal de cambio 3. Definir ligas a otros requerimientos 4. Enviar cambio para aprobación

Obtención de requerimientos Técnicas:  Lluvia de ideas  Análisis de documentos  Focus Group  Entrevistas  Observación  Prototipo  Taller  Cuestionario

Obtención de requerimientos  Lluvia de ideas  Mapa mental  Alrededor de una idea central

 Focus Group  Grupo de expertos alrededor de ideas específicas  Dirigido por un moderador  Investigación cualitativa

Obtención de requerimientos  Taller de requerimientos  Forma estructurada para captar requerimientos  Utilizado para definir alcance y prioridad de los requerimientos encapsulados en el sistema  Joint Application Design  Se requiere de moderador y escribano  Para alcanzar consenso y acuerdo de los requerimientos  Detalle de los requerimientos

Análisis de requerimientos  Describe cómo se analizan, estructuran y especifican los requerimientos para diseño y construcción de la solución.

Técnica de análisis  Análisis de procesos de la organizaciónenfocado al mejoramiento de los procesos de la organización de acuerdo con su misión, visión y objetivos.  Business process mapping (diagramas de flujo y flujos de trabajo, mapas de procesos)

Análisis de Requerimientos         

Estructurar requerimientos Generar Modelo Analizar requerimientos de usuario Analizar requerimientos funcionales Analizar requerimientos de calidad de servicio Determinar las limitaciones y asunciones Determinar los atributos de los requerimientos Documentar la especificación de requerimientos Validar la especificación de requerimientos

Estructurar requerimientos  Descomposición de las metas  Descomposición de las carácterísticas de la solución (prioridad, complejidad y versión de implementación)  Descomposición funcional Entregable: Modelo de la solución

Generación de modelo  Describir mestado actual y estado futuro  Utilizado para asumir el estado actual de la organización  Utilizado para tener la visión compartida de la solución Entregable: Documento de modelo actual y futuro

Análisis de requerimientos de usuario  Describir los requerimientos por usuario o grupos de usuario Considerar:  Cómo se distribuye y aplica la solución?  Número de grupos de usuarios  Complejidad de la solución  Consenso entre los grupos de interés

Análisis de requerimientos funcionales  Describe el comportamiento deseado de la solución.  Estos requerimientos describen las capacidades del sistema (acción-respuesta) El comportamiento incuye:  El efecto que tendrá la solución acerca de un problema dado  La interacción de personas o sistemas con la solución propuesta  El eumplimiento de un estándar

Documentación de requerimientos      

Evento/condición Sujeto Acción Objeto Reglas Resultado

Análisis de requerimientos de calidad de servicio  Requerimientos del contexto (regulatorios, políticos, estándates, políticas, condiciones físicas)  Requerimientos de auditoría  Requerimientos de localización (tropicalización)  Requerimientos de la interfaz  Glosario  Requerimientos de operacionales  Requerimientos de desempeño y disponibilidad  Requerimientos de calidad  Privacidad de la información  Requerimientos de seguridad  Entrenamiento

Limitaciones y asunciones  Limitaciones de la organización  Limitaciones técnicas  Asunciones (algo que se cree cierto pero no se puede verificar y si cambia, puede afectar negativamente el proyecto)

Atributos de los requerimientos  Metadata incluye: quién lo hace, cuándo lo hace, quién autorizó  Uso de imperativos  Elementos:         

Referencia Criterio de aceptación Autor Complejidad Propiedad Fuente Estabilidad (madurez del req.) Status (propuesto, aceptado, verificado) Urgencia

Validación de requerimientos  Firma!!!