Gerente de Proyectos + Arquitecto de Solución= Proyectos Orientados al Éxito

Transcripción

1 Gerente de Proyectos + Arquitecto de Solución= Proyectos Orientados al Éxito Jorge Arias (jorge.arias@oracle.com / jor-aria@uniandes.edu.co ) Solutions Architect Oracle Consulting Latin America Division (LAD) IX Jornada de Gerencia de Proyectos de TI Marzo 24 y 25 de 2011 Bogotá - Colombia

2 Objetivos Presentar como la correcta articulación de los roles de gerente de proyecto y arquitecto de solución ayudan a enfrentar la complejidad inherente a los proyectos hoy en día, y orientar los mismos hacia el éxito. Describir, a partir de experiencias en el campo, las principales responsabilidades que debe asumir un rol de arquitectura, y como estas complementan las realizadas por un gerente de proyectos.

3 Agenda Contexto Arquitectura & Gerencia de Proyectos Dimensiones de un rol de arquitectura Conclusiones

4 Motivación & Contexto Proyecto = Experiencia + Simplicidad Experiencia es lo que tú consigues, cuando no consigues lo que quieres Randy Pausch, 2008 CMU (En su best seller The last lecture ) Simplicidad es una ilusión, es tan sólo complejidad bien administrada Anne Thomas- Burton Group

5 Motivación & Contexto En dónde estamos (Los tiempos cambian) Tiempo Calidad Recursos ( $$$, Gente) Usabilidad Alcance Por qué la mejora? Orientación al negocio, Gerencia de proyectos, Evolución de frameworks de arquitectura Sólo el 16.2% de los proyectos son exitosos 31.1% de los proyectos son cancelados antes de terminarlos 52.7% de los proyectos terminados no cumplen con los requerimientos funcionales mínimos. La complejidad de los problemas a resolver será la misma? Sólo el 32% de los proyectos son exitosos 24% de los proyectos son cancelados antes de terminarlos 44% de los proyectos terminados no cumplen con los requerimientos funcionales mínimos. Fuente:

6 Motivación & Contexto Alcance de los proyectos de TI Granularidad de los procesos de negocio N-0: Macroprocesos N-1: Grupos de procesos N-2: Proceso de negocio N-3: Actividades de negocio N-4: Procedimientos/Tareas de negocio N-5: Pasos/Requermientos de negocio

7 Motivación & Contexto Alcance de los proyectos de TI Granularidad de los procesos de negocio vs. Tipo de proyectos Enterprise X-Telco Level 0 Major Business Functions 7.0 Manage IT 8.0 Manage Financial Resources 9.0 Acquire, Construct & Manage Property Level 1 Process Groups 8.6 Process AP & Expense Reimbursement 8.7 Manage Treasury Operations 8.8 Manage Internal Controls Level 2 Business Process Expense Reimbursement Process Accounts Payable Level 3 Business Activity (2) Adoptar un Establish & Communicate ERP Expense Policies Process Reimbursements & Advances Approve Reimbursements & Advances (1) Desarrollo de a la medida Level 4 Business Task Complete Expense Request Review Expense Request Approve Expense Request Verify Expense Request Transfer Funds Level 5 Business Step Review (3)Proyecto Change Ratede Integración Verify Expense Policy Compliance

8 Motivación & Contexto Alcance de los proyectos de TI Diferencias entre ingeniería y Gestión Ingeniería del proyecto Tres DIREFERENTES tipos de proyectos de TI Desarrollo a la medida Adopción de un CRM Proyecto de integración Gestión del proyecto Gestión del alcance Gestión del riesgo Gestión del tiempo Gestión de recursos Gestión de costos Metodología Modelos de estimación Arquitectura Tecnología Roles Diferente y dependiente del tipo de proyecto Igual para los tres proyectos

9 Motivación & Contexto Alcance de los proyectos de TI Diferencias entre ingeniería y Gestión Ingeniería del producto Tres DIREFERENTES tipos de proyectos de TI Adopción de un CRM (Telcos) Adopción de un CRM ( Banca) Adopción de un CRM (Retail) Gestión del producto Gestión del alcance Gestión del riesgo Gestión del tiempo Gestión de recursos Gestión de costos Metodología (=) Modelos de estimación (<>) Tecnología (=) Roles (<>) Conocimiento de industria (<>) Arquitectura (<>) Diferente y dependiente del tipo de proyecto Igual para los tres proyectos

10 Motivación & Contexto Los proyectos de TI son cada vez más complejos Modelo Cliente/Servidor dos niveles Cliente -Presentación -Negocio Servidor Datos Modelo Cliente/Servidor modificado Cliente -Presentación Servidor -Negocio -Datos 1980 Problema de negocio 1998 Modelo SOA/BPM 2009 Canales (Web2.0) Portal Terminal (Browser) Terminal 1970 BPM Dashboard ESB Host WebServer AppServer DBServer 2005 Modelo host -Presentación -Negocio - Datos Lógica Presentación Lógica Negocio (componentes) Datos Pesentación Negocio Datos Multicapas

11 Motivación & Contexto Los proyectos de TI son cada vez más complejos (2) Las arquitecturas han tenido que venir evolucionando como forma de respuesta a las necesidades, cada vez más exigentes y diversas, del negocio. Los estilos de arquitectura no son una moda, son una clara forma de resolver y responder a la complejidad (Legacy, Client-Server, Multicapas, Servicios, etc.) Proyecto Ingeniería de TI soportado Gestión en cada estilo de Diferente arquitectura Igual

12 Alcance empresarial Motivación & Contexto Los proyectos de TI son cada vez más complejos (3) Solución de negocio ( Proyectos tipo: desarrollo a la medida, implantación de plataforma de TI, COTs) Implantación de procesos transversales (CRM Integración ERP/ Facturador) Implantación de un COTS (ERP, CRM, Facturador, etc.) Proyecto de implantación de herramientas de tecnología ( ESB, BPM, iam, BI) Desarrollo a la medida Heterogeneidad de habilidades requeridas

13 Motivación & Contexto Ejemplo: Habilitar una capacidad de negocio Sistem Atención al cliente ( Siebel, People Soft) Sistema de Sistema de facturación ordenes de trabajo Aprovisionamiento en linea planes de datos Sistema Financiero ( SAP) Proyecto de adoptar un CRM Proyecto desarrollo a la medida (Modificar el facturador) Proyecto de integración (Implantar un Bus)

14 Motivación & Contexto Resumen: La complejidad de los proyectos de TI es cada ves mayor Estilos de arquitectura Metodologías diferentes Roles & Skills Diferentes industrias (Telco, Banca, Retail, etc.) Los principios de administración y gestión del proyecto se mantienen entre proyectos de TI Motivadores de negocio Desarrollo a la medida Adopción de un COTs (CRM, ERP) Implantar plataformas técnicas (Bus, iam, BPM, Sistemas operativos)

15 PROYECTO Motivación & Contexto Resumen El PM Puede asumir la gestión e ingeniería? Solución = Producto QUÉ? CÓMO? Procesos de negocio Metodología Modelos de datos Mapas de solución Aplicaciones Arquitectura Motivadores de negocio Equipo de trabajo Tecnología Gerente de proyectos? Alcance Gestión Tiempo Costes Riesgo Recursos Otros.

16 Si vamos hacia un mundo de especialización; porque esperamos o motivamos escenarios para que el PM le apueste a la generalización? Vamos a ser más competitivos y eficientes en nuestros proyectos cuando le apostamos a la especialización ( Ingeniería y gestión correctamente articulado)

17 Motivación & Contexto Qué piensan y cómo se sienten los Gerentes de proyectos? Proyectos complejos hoy en día: Costos, alcance, tiempo, recursos, arquitectura, metodología, conocimiento de industria etc. Llegamos a situaciones de desespero en donde no sabemos si gritar o correr

18 Agenda Contexto Arquitectura & Gerencia de proyectos Dimensiones de un rol de arquitectura Conclusiones

19 Arquitectura y Gerencia de Proyectos Estructura dimensional del problema y esencia cambiante del mismo Estrategia de Negocio Ciclos de reconovación más cortos Define Define Define Procesos de negocio 15% - 20% Modelo de información Aplicaciones Tecnología Cultura y Gestión del Cambio Iniciativa o Proyecto #1 Iniciativa o Proyecto #2 Proyectos cambiantes Iniciativa o Proyecto #N Gobernabilidad

20 PROYECTO Motivación & Contexto El PM necesita alguien que le da claridad en el QUE y en el CÓMO del proyecto Arquitecto Solución = Producto QUÉ? CÓMO? Motivadores de negocio Metodología Procesos de negocio Mapas de solución Conocimiento de industria Modelos de datos Arquitectura Aplicaciones Equipo de trabajo Tecnología Alcance Gestión Tiempo Costes Gerente de proyectos Riesgo Recursos Otros.

21 Arquitectura y Gerencia de Proyectos En TI el PM si debe conocer de TI. No es tan fácil aislarse de la ingeniería de la solución (Sería todo un riesgo) Gestión de proyectos Gerente Proyectos Habilidades de comunicación Conocimiento de industria Metodología Tecnología Arquitectura Arquitecto

22 Arquitectura y Gerencia de Proyectos Génesis y componentes de un proyecto Problema de negocio QUÉ CÓMO Implementación / Implantación COMO Alcance Contrato Comunicación Riesgos Calidad Tiempo Costos Recursos Adquisiciones

23 Arquitectura y Gerencia de Proyectos Articulación de dos roles (Arquitectura + Gerencia de Proyectos) (1) Ingeniería del producto / Solución Problema de negocio QUÉ CÓMO Implementación / Implantación COMO Arquitecto de solución Gerencia del producto / solución Tiempo Alcance Contrato Gerente de Proyectos Comunicación Recursos Adquisiciones Riesgos Calidad Costos

24 Arquitectura y Gerencia de Proyectos Articulación de dos roles (Arquitectura + Gerencia de Proyectos) (2) Ingeniería del producto / Solución Problema de negocio QUÉ CÓMO Implementación / Implantación COMO Enfoques & Habilidades (Industria, metodologia, tecnologia, estilos, etc.) Gerencia del producto / solución Tiempo Alcance Contrato Gerente de Proyectos Comunicación Recursos Adquisiciones Riesgos Calidad Costos

25 Arquitectura y Gerencia de Proyectos Solución basada en restricciones & Realidades Regulaciones de industria Requerimientos no funcionales Presupuesto Estandares Cultura Organizacional Solución Herramientas Arquitecto Tecnologías disponibles Alcance Contrato Comunicación Riesgos Calidad Gerente de proyectos Tiempo Costos Recursos Adquisiciones

26 Arquitectura y Gerencia de Proyectos Gestión del Cambio Regulaciones de industria Requerimientos no funcionales Presupuesto Estandares Cultura Organizacional Cambio Herramientas Arquitecto Tecnologías disponibles Alcance Contrato Comunicación Riesgos Calidad Gerente de proyectos Tiempo Costos Recursos Adquisiciones

27 Gerentes de proyectos & Arquitectos de solución: Instrumentos para atacar complejidad Escenario de cooperación #1: Proyecto de conceptualización como enfoque de mitigación de riesgos en proyectos de gran escala, alta incertidumbre, presupuestos altos.

28 Arquitectura y Gerencia de Proyectos Importancia de los proyectos de conceptualización Discovery / Scoping Analisis Especificaci ón de Negocio Análisis Diseño Construcció n Pruebas Roll-out Proyecto de conceptualización Proyecto de implementación/implantación Forma de contratación: Time & Materials Enfoque arquitectónico: Entender el QUÉ vía un análisis de arquitectura empresarial

29 Motivación & Contexto El QUÉ no sólo se resuelve con tecnología Arquitectura tecnológica Solución Arquitectura e Implementación 29

30 Motivación & Contexto El QUÉ requiere de un análisis multidimensional del problema (1) Arquitectura Empresarial Arquitectura de Procesos de Negocio Arquitectura de datos e información Arquitectura de interfaces & Aplicaciones Solución Arquitectura tecnológica

31 Arquitectura y Gerencia de Proyectos Arquitectura Empresarial como nuevo enfoque de análisis (1) Negocio AS-IS Problema Datos & Información de negocio a soportar sobre una Aplicaciones solución IT Tecnología TO-BE Sistemas Actuales Estandares actuales Operación diaria Motivadores de Negocio y Condiciones de mercado Modelos de referencia Buenas prácticas & Regulaciones

32 Arquitectura y Gerencia de Proyectos Arquitectura Empresarial como nuevo enfoque de análisis (2) AS-IS GAP Problema de negocio a soportar sobre una solución IT ROADMAP TO-BE Sistemas Actuales Estandares actuales Operación diaria Este roadmap debe ser priorizado y concertado entre los diferentes stakeholders Motivadores de Negocio y Condiciones de mercado Modelos de referencia Buenas prácticas & Regulaciones 32

33 Arquitectura y Gerencia de Proyectos Arquitectura Empresarial como nuevo enfoque de análisis (3) 2 1. Levantar AS-IS 2. Determinar TO-BE 3. Identificar brechas 4. Priorizar 5. Elaborar roadmap Arquitectura de negocio 6 MOTIVADORES DE NEGOCIO Levantar AS-IS 2. Determinar TO-BE 3. Identificar brechas 4. Priorizar 5. Elaborar roadmap Arquitectura de datos e Información 4 1. Levantar AS-IS 2. Determinar TO-BE 3. Identificar brechas 4. Priorizar 5. Elaborar roadmap Arquitectura de Aplicaciones 5 1. Levantar AS-IS 2. Determinar TO-BE 3. Identificar brechas 4. Priorizar Arquitectura Tecnología Elaborar roadmap

34 Arquitectura y Gerencia de Proyectos Importancia de los proyectos de conceptualización Discovery / Scoping Analisis Especificaci ón de Negocio Análisis Diseño Construcció n Pruebas Roll-out Proyecto de conceptualización Proyecto de implementación/implantación Forma de contratación: Fixed-Price Enfoque arquitectónico: Entender el COMO vía un análisis de arquitectura de solución

35 Arquitectura y Gerencia de Proyectos Abstracción de la solución 50,000fts Arquitecto Empresarial 1,000fts Arquitecto de Solución 200fts Analista de requerimientos, Developer / Programer 0fts 100fts QUE? Procesos de negocio Entidades de negocio Modelos de da<tos Mapa de aplicaciones Mapa de integración Mapa tecnológico Funcionalidades de negocio Definición de Componentes lógicos Modelos de persistencia Esquemas de Integración basada en servicios vs. RMI vs. CORBA Enfoques de replicación y alta disponibilidad Caso de uso Diagrama de clases Diagrama de secuencia Modelo detallado de datos Prototipo de GUI Problema de negocio Solución COMO? Análisis AS-IS vs. TO-BE de procesos Asignación de dueños de datos Asignación de dueños de funcionalidades Selección del estilo de arquitectura (SOA, N- tier, Client/server, etc. Patrones de arquitectura. Composiciones basadas en BPEL y SCA Estructura de componentes requeridos (Lógicos & Infraestructura) Estilos de mensajería Balanceo de carga RR y disponibilidad basada en virtualización Patrones de diseño Clases en Java Componentes JEE Modelo de datos en Oracle RDBMS Mensajería basada en JMS Idioms G e r e n c i a d e p r o y e c t o s

36 Arquitectura y Gerencia de Proyectos Arquitectura Empresarial & Arquitectura de Solución QUÉ? Arquitectura Empresarial Iniciativa o Proyecto Corporativo CÓMO? Arquitectura de Solución Detalle de la solución

37 Gerentes de proyectos & Arquitectos de solución: Instrumentos para atacar complejidad Escenario de cooperación #2: Empresa proveedora de servicios (Software House, Consultora, etc.)

38 Arquitectura y Gerencia de Proyectos Ciclo de vida.. Generación de demanda Venta Bid-Transition Delivery Dimensión Preventa Dimensión Delivery

39 Arquitectura y Gerencia de Proyectos Ciclo de vida.. Generación de demanda Venta Transición Venta- Entrega Entrega - Speaker en eventos: Compartir experiencias en proyectos x industria, tendencias - Participar en comunidades / Comités de arquitectura de la industria - Oferta de valor de la organización para hacer proyectos de TI - Escribir artículos de casos de estudio (análisis post-morterm: Lecciones aprendidas)

40 Arquitectura y Gerencia de Proyectos Ciclo de vida.. Generación de demanda Venta Transición ventaentrega Entrega - Conceptualizar y abstraer las problemáticas de negocio que tiene el cliente; y las cuales motivan contratar un proyecto de TI. - Visionar una arquitectura conceptual de solución que responda a las problemas de negocio del cliente - Ayudar a estructurar un proyecto para implantar la solución conceptualizada (roles, tiempos, esfuerzos, dependencias funcionales y técnicas) - Planear y participar en la ejecución de un proyecto de conceptualización. - Explicar, defender y vender la solución frente al cliente

41 Arquitectura y Gerencia de Proyectos Ciclo de vida.. Generación de demanda Venta Transición ventaentr Delivery - Explicar al PM asignado al proyecto el alcance funcional y técnico de la solución vendida al cliente. - Elaborar un WBS template de cómo ejecutar el proyecto en terminos de: Fases metodológicas, tareas de alto nivel x fase, esfuerzo y dependencias. - Explicar y transferir al PM los riesgos que se asumieron durante la venta para ganar el negocio. - Ayudar al PM al elaborar el ETC (Estimated to be completed) para que este pueda compararlo contra el BID (Valor del proyecto (Costo + Margen estimado) ( Siempre le cuadra que el ETC inicial es igual al BID?)

42 Arquitectura y Gerencia de Proyectos Ciclo de vida.. Generación de demanda Venta Bid-Transition Entrega - Participar activamente en la fases de conceptualización (inception) y elaboración - Elaborar la arquitectura de solución del proyecto (Lógica y Física) - Generar lineamientos, principios diseños, y practicas para el equipo de diseño e implementación - En la fase construcción realizar actividades de QA (1 vez al mes) que permitan validar que la solución esta siendo construida acorde a la arquitectura planteada (Evitar desviaciones) - A lo largo del proyecto: servir de ente consultivo respecto a temas de ingeniería del PM y manejo de expectativas frente al cliente.

43 Gerentes de proyectos & Arquitectos de solución: Instrumentos para atacar complejidad Escenario de cooperación #2: Empresa Compradora de tecnología

44 Agenda Contexto Arquitectura & Gerencia de proyectos Dimensiones de un rol de arquitectura Conclusiones

45 Dimensiones de un rol de arquitectura Ejes estructurales del rol Experiencia Capacidad Abstracción Habilidades de comunicación Conocimiento de industria Tecnología Metodología

46 Dimensiones de un rol de arquitectura Desarrollador vs. Especialista técnico/producto vs. Arquitecto Arquitecto Solución

47 Agenda Contexto Arquitectura & Gerencia de proyectos Dimensiones de un rol de arquitectura Conclusiones

48 Arquitectura y Gerencia de Proyectos Resumen Gerencia de proyectos y Arquitectura deben ir de la mano para enfrentar la complejidad inherente de los proyectos de hoy en día. La naturaleza de los proyectos está obligando a que Arquitectura y Gerencia de proyectos sean roles ejecutados por personas y/o grupos diferentes (Demasiadas cosas para ser ejecutadas por la misma persona, no obstante tenga en cuenta el tamaño del proyecto) No se deje engañar de las vistas a alto nivel (50,000fts, 30,000fts), donde todo es fácil, simple, etc. (Recuerde el que nada sabe nada teme) El rol de arquitectura al interior de los proyectos no es una moda, es una respuesta a la complejidad de los proyectos, y está convirtiéndose en el mejor seguro de los gerentes de proyectos.

49 Preguntas & Respuestas