Gestión de Proyectos

Proyecto ?

Proyecto Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único A Guide to the Project Management Body of Knowledge 3ra edición, 2004

Temporal Posee fecha de inicio y término definida, es decir tiene duración finita El proyecto termina Se cumplieron los objetivos Es claro que no se puede cumplir los objetivos La necesidad ha dejado de existir La ventana de mercado ha sido sobrepasada La noción de temporal no se aplica al producto, servicio o resultado que se crea

Producto, Servicio o Resultado Único Un proyecto crea entregables únicos, que son productos, servicios o resultados El proyecto crea Un producto o artefacto que es producido (completo o parte de otro producto) La capacidad de prestar un servicio Un resultado (documentos en una consultoría)

Proyecto vs. Trabajo Operativo Las organizaciones trabajan para lograr objetivos. El trabajo se puede categorizar como proyecto u operaciones Los rasgos comunes Desarrollados por personas Restringido por la limitación de los recursos Planificados, ejecutados y controlados

Proyecto vs. Trabajo Operativo La mayor diferencia es que los proyectos son temporales y únicos mientras que las operaciones son continuas y repetitivas Los objetivos de los proyectos y de las operaciones son diferentes El propósito de un proyecto es lograr los objetivos y terminar El propósito de las operaciones es sostener el negocio

Proyecto vs. Trabajo Operativo Ejemplos de proyectos son Desarrollo de un nuevo producto o servicio Cambios en la estructura de una organización Diseñar un nuevo vehículo de transporte Desarrollar un sistema de información Construir un edificio Desarrollar una campaña política para un candidato Implementar un nuevo proceso

Proyectos y Planificación Estratégica Los proyectos son formas de organizar actividades que no pueden ser tratadas dentro de los límites operacionales de la organización Los proyectos son en general utilizados para lograr la planificación estratégica de una empresa

Proyectos y Planificación Estratégica Los proyectos son realizados como resultado de una o más de las siguientes consideraciones estratégicas Demanda del mercado Necesidad de la organización Solicitud de un cliente Avance tecnológico Requerimiento legal

Gestión de Proyectos (Project Management) ?

Gestión de Proyectos (Project Management) Aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto. La gestión de proyectos se logra mediante la aplicación e integración de los procesos de gestión de inicio, planificación, ejecución, monitoreo y control, y cierre. A Guide to the Project Management Body of Knowledge 3ra edición, 2004

Responsabilidades del Jefe de Proyecto Identificar los requerimientos Establecer objetivos claros y alcanzables Equilibrar las demandas concurrentes de calidad, alcance, tiempo y costo Adaptar las especificaciones, los planes y el enfoque a las inquietudes y expectativas de los interesados

Triple Restricción Triple restricción Alcance Tiempo Costo La calidad del proyecto depende del equilibrio entre estos factores Un proyecto de alta calidad es aquel que entrega el producto, servicio o resultado con el alcance requerido, puntualmente y dentro del presupuesto

Gestión de la Integración Acta de constitución Alcance preliminar Plan de gestión Dirección y gestión de la ejecución Monitoreo y control del trabajo Control de cambios Cierre del proyecto

Gestión del Alcance Planificación del alcance Definición del alcance Creación del WBS Verificación del alcance Control del alcance

Gestión del Tiempo Definición de actividades Secuenciamiento de actividades Estimación de recursos de las actividades Estimación de duración de las actividades Desarrollo del cronograma Control del cronograma

Gestión del Costo Estimación del costo Preparación del presupuesto Control del costo

Gestión de la Calidad Planificación de calidad Realizar aseguramiento de calidad Realizar control de calidad

Gestión de los Recursos Humanos Planificación de los recursos humanos Conseguir el equipo del proyecto Desarrollar el equipo del proyecto Administrar el equipo del proyecto

Gestión de las Comunicaciones Planificación de las comunicaciones Distribución de la información Informes de rendimiento Administración de los interesados

Gestión de las Adquisiciones Planificación de compras y adquisiciones Planificar la contratación Solicitar cotizaciones Selección de proveedores Administración de contratistas Cierre de contratos

Áreas de Expertise Gestión de proyectos Conocimientos, normas y regulaciones del área de aplicación Comprensión del entorno del proyecto Conocimientos y habilidades de dirección general Habilidades interpersonales

Entorno del Proyecto Entorno cultural y social Entorno internacional y político Entorno físico

Conocimientos y Habilidades de Dirección General Gestión financiera y contabilidad Compras y adquisiciones Ventas y comercialización Contratos y derecho mercantil Manufactura y distribución Logística y cadena de suministro Planificación estratégica, planificación táctica y planificación operacional Estructuras y comportamiento de la organización, administración de personal, compensaciones, beneficios y planes de carrera

Habilidades Interpersonales Comunicación efectiva Influencia en la organización Liderazgo Motivación Negociación y manejo de conflictos Resolución de problemas

¿Por Qué Fallan los Proyectos? Poca claridad del alcance 53% Bajo patrocinio a la gestión 43% Recursos inadecuados 37% Pobre definición de requerimientos 33% Pobre comunicación 23% Ausencia de una metodología estándar Pobre planeación 13 Fuente: Forrestete - 2004

7 Claves de Éxito en Gestión Compromiso de los stakeholders (participantes) Comprensión de los beneficios del negocio Plan de trabajo y cronogramas predecibles Equipo de trabajo de alto desempeño Alcance es realista y manejable Riesgos son mitigados Comprensión de los beneficios de los entregables para la organización

Tipos de Riesgos Riesgos funcionales Riesgos de gestión Riesgos de recursos Riesgos organizacionales Riesgos técnicos Riesgos de ejecución (compromiso, soporte, etc.)

Proceso de Desarrollo de Producto Definición y Planificación Desarrollo Manufactura Distribución Post venta Marketing y ventas Técnico Producción Gestión de proyecto Calidad

Definición y Planificación Define el producto de acuerdo a las necesidades del mercado Define lo que el producto debe hacer, no como se debe hacer Define el impacto comercial del producto (ingresos y costos) Define los equipos de trabajo necesarios para el desarrollo del producto

Definición y Planificación Define las etapas del desarrollo Planifica el trabajo del equipo Define puntos de control (go / no go)

Desarrollo Especificación Diseño Implementación Integración Pruebas Gestión de proyecto Calidad

Aseguramiento Calidad Flujo de Desarrollo Especificación del sistema Co simulación Partición HW/SW Diseño e imp. HW Diseño e imp. SW Integración y pruebas Aseguramiento Calidad

Especificación del Sistema Traduce la definición del sistema en requerimientos del sistema. Requerimientos del tipo Funcionales De testing De calidad De ambiente Interfaces De desarrollo De Post desarrollo

Especificación del Sistema Define como el sistema será probado Define los casos de prueba que serán usados para probar el sistema Define los recursos necesarios al desarrollo y las pruebas del sistema Identifica los riesgos, supuestos, dependencias y restricciones Identifica los factores claves del éxito

Especificación del Sistema Define el sistema en algún tipo de lenguaje de alto nivel Realiza verificaciones de funcionalidad a través de simulaciones Particiona el sistema en componentes de HW y SW

Entregables Documento de Requerimientos del Sistema Documento de Pruebas del Sistema Documento de Especificación de la Componente hardware del Sistema Documento de Especificación de la Componente Software del Sistema

Partición Especificación del sistema Partición Evaluación Cumple Requerimiento?

Especificación Componente Hardware Define los requerimientos de HW del sistema Identifica riesgos. Define los supuestos, dependencias y restricciones de la componente HW Define como será probado el hardware y los casos de pruebas que se usarán Define los recursos necesarios al desarrollo de HW Realiza una revisión de pares del documento de requerimientos de HW

Entregables Documento de Requerimientos de HW Documento Pruebas del HW

Especificación Componente Software Define los requerimientos de SW del sistema Identifica riesgos. Define los supuestos, dependencias y restricciones de la componente SW Define como será probado el software y los casos de pruebas que se usarán Define los recursos necesarios al desarrollo de SW

Especificación Componente Software Especifica el ciclo de vida que se usará Especifica la arquitectura del SW Realiza una revisión de pares del documento de requerimientos de SW

Entregables Documento de Requerimientos de SW Documento de Pruebas de SW Documento de Arquitectura de SW

Ciclos de Vida ?

Ciclos de Vida Waterfall (cascada) Incremental Evolutivo Modelo espiral Modelo V Modelo V con prototipaje

Cascada Requirements Design Code and test Integration System test Delivery Evolution

Cascada Defina lo que quiere Defina un método para lograrlo Ejecute el método Pruebe los resultados Entregue Repita para otros requerimientos

Incremental Serie planificada de modelos cascada entregando más y más funcionalidad No util para productos en ROM, útil para familias de productos en ROM

Evolutivo Similar al incremental planificando solamente la próxima entrega Confunde desarrollo y evolución Ventajas: Puede ser usado en ambientes cambiantes Se cuenta con un sistema funcional despueés de cada entrega Se planifica solo lo que se puede predecir

Espiral Basado en la reducción de riesgos Realiza varias iteraciones evaluando los riesgos En cada iteración se evalua el riesgo Si el riesgo es alto, se hace otro prototipo Sino se desarrolla el sistema final usando cascada

Espiral

Modelo V Los requerimientos sistema están completos y no son ambiguos Simple de aplicar y gestionar Énfasis en la verificación y la validación Mala gestión de riesgos No hay ningún sistema usable hasta el final del ciclo de desarrollo.

Modelo V

Modelo V con Prototipaje

Eligiendo un Ciclo de Vida Conocimiento/completitud de los requerimientos Certeza de los requerimientos detallados Volatilidad de requerimientos Tecnología / herramientas nuevas Tiempos de entrega Longevidad de la aplicación Complejidad de la aplicación Grado de reusabilidad

Matriz de Selección

Requerimientos Propósito: Tener un entendimiento común en que es el sistema y que hace Siempre se tienen requerimientos Pueden ser escritos o no Pueden estar bien o mal definidos Pueden ser estables o volátiles Proveen una base de evaluación La especificación de los requerimientos (Libro de Requerimientos) registra todos los requerimientos

Libro de Requerimientos Información general y objetivos del sistema Requerimientos funcionales Requerimientos de prueba Matriz de requerimientos funcionales / prueba Requerimientos de calidad Requerimientos de interfaz Requerimientos de desarrollo Arquitectura del sistema Matriz componentes arquitecturales / requerimientos

Participación del Cliente Un representante del cliente debe participar activamente Es como un arquitecto diseñando una casa Si el cliente no está involucrado, existe una alta probabilidad de fracaso En ausencia del cliente, marketing puede asumir este rol

Requerimientos son Objetivos del Sistema Si los objetivos no están claros No se puede lograrlos No se puede probar que se lograron No pueden probar que no lo logramos No se pueden evaluar diferentes ideas de diseño Se termina especificando medios en vez del fin

Diseño Arquitectural Propósito: Crear un modelo del software del sistema La arquitectura es la decisión más crítica del diseño Incluye componentes principales y sus interacciones Es la base para el desarrollo evolutivo Son difíciles de diseñar de la nada, pero pueden ser tomadas de diseños previos o de libros

Estilos de Arquitectura Layers Event-based implicit invocation Interpreters Pipes and filters Blackboard Model-view-controller Micro-kernels Software Architecture, Mary Shaw and David Garlan, Prentice-Hall, 1996.

Layers

Diseño Detallado Propósito: Hacer y registrar decisiones de diseño algoritmos estructuras de datos variables y constantes locales y globales interfaces entre módulos y procedimientos otros Es mejor tomar las decisiones antes de codificar están documentadas no se encuentran ocultas por detalles del código Prototipos de código pueden ser hechos durante el diseño para verificar los algoritmos

Codificación Propósito: Transformar el diseño en código ejecutable Si se tiene un diseño completo, la codificación es principalmente la traducción del diseño en el lenguaje de programación Solo se debe preocuparse del lenguaje y de las herramientas El problema ya se resolvió durante el diseño La codificación es también una oportunidad de encontrar errores en el diseño

Testing Propósito: Asegurarse que el código es consistente con los requerimientos y las necesidades del usuario Hay varias formas de probar, realícelas todas Test unitario Test de integración Test del sistema Test de aceptación / calificación

Test Unitario Propósito: Asegura que el código funciona de acuerdo al diseño Es realizado informalmente Para probar una función se debe Llamar la función Tener disponible las funciones que serán llamadas Si alguna no está disponible se debe hacer un mockup

Test Integración Propósito: Asegurar que no hay errores de interfaz. Encuentra defectos en el sistema Hay cierto nivel de formalidad ya que el código es normalmente hecho por varias personas

Test Sistema Propósito: Asegurar que se cumple los requerimientos Proceso formal Planificada Casos de test especificados Registro de resultados Errores encontrados son documentados y clasificados

Test de aceptación / calificación Propósito: Certificar que los requerimientos se cumplen satisfactoriamente y que la producción es posible Puede ser interna o por aprobación cliente La formalidad depende de cada caso

Entrega Propósito: Entregar al cliente una versión estable y aprobada del producto Los entregables deben estar definidos de antemano Se debe formalizar a través de una carta por ejemplo

Evolución y Gestión de Cambio El cambio es inevitable Creamos ideas más rápido de lo que las implementamos El cambio puede venir de Cambios en el ambiente o regulaciones Competencia Nuevas necesidades de los clientes Mejor entendimiento del sistema y la tecnología No se oponga al cambio, manéjelo!