El documento define un proyecto como un emprendimiento temporal para lograr un resultado único. Explica diferentes modelos de ciclo de vida de proyectos como el modelo en cascada, orientado a hitos, orientado a prototipos y de programación extrema. También describe los procesos de gestión de proyectos como inicio, planificación, ejecución, control y cierre que se aplican a diferentes áreas como alcance, tiempo, costo y riesgo.

1. Curso de Gestión de Proyectos Cristian Sanchez Flores [email_address] SIDET 2010 Proyectos

2. Un Proyecto es Un emprendimiento temporario para lograr un resultado único. Temporario: Su extensión se prevé limitada en el tiempo. Producto único: no se ha realizado antes nada igual, Curso de Gestión de Proyectos

3. Un proyecto es una acción en la que recursos humanos, financieros y materiales se organizan de una nueva forma para acometer un trabajo único. En este trabajo, dadas unas especificaciones y dentro de unos límites de costes y tiempo, se intenta conseguir un cambio beneficioso dirigido por unos objetivos cualitativos y cuantitativos. Definición de proyecto Curso de Gestión de Proyectos

4. Ejemplos de proyectos. Lanzamiento de un nuevo producto. Construcción de una nueva Planta Realización de un viaje. Desarrollo de un programa de entrenamiento. Instalación de un nuevo software. Curso de Gestión de Proyectos

5. ¿cómo nace un proyecto? Curso de Gestión de Proyectos A partir de un problema, oportunidad, necesidad se genera una IDEA Debemos Transformar esa idea en un OBJETIVO Luego alcanzar ese objetivo obteniendo un PRODUCTO Ese producto debe dar solución al problema u oportunidad original. Esto lo haremos través de la realización de un proyecto dentro el marco de las ORGANIZACIONES involucradas.

6. Diferenciar La duración del proyecto, del ciclo de vida del producto del proyecto. La Definición del proyecto, de la gestión de la ejecución del proyecto. Los responsables pueden diferir. Curso de Gestión de Proyectos

7. Curso de Gestión de Proyectos La gestión de proyectos TI es más compleja por : Complejidad intrínseca al desarrollo de software Imprecisión en la planificación del proyecto y estimación de los costos. Baja calidad de las aplicaciones. Dificultad de mantenimiento de las aplicaciones. Esto hace surgir una rama de la ciencia que se llama Ingeniería de Software que intenta resolver estos problemas Proyectos de TI

8. Ciclo de vida de un proyecto Curso de Gestión de Proyectos Es la forma en la que se divide un proyecto en etapas y cómo se avanza entre estas etapas Según la metodología hay varios modelos, pero analizaremos los siguientes: En cascada Orientado a hitos Orientado a prototipos Programación extrema

9. Modelo en cascada (I) Es el modelo clásico Las fases se deben ejecutar de forma secuencial, pero se puede volver a la fase anterior Cada etapa genera una documentación o un producto que recibe de entrada la siguiente fase Especificación de requisitos Análisis Diseño Codificación Pruebas Mantenimiento Implantación

10. Modelo en cascada (II) Objetivo de cada una de las etapas: Especificación de requisitos: Documento con la especificación de requisitos (ERQ) Análisis: Documento de análisis funcional Diseño: Documento de diseño técnico Codificación: Código fuente de la aplicación y manuales de usuario Pruebas: Documentación de pruebas Implantación: Documento de operación

11. Modelo en cascada (III) Ventajas Minimiza la repetición de tareas de desarrollo La planificación es sencilla Facilita el control, permitiéndonos afrontar proyectos grandes Inconvenientes Solo es adecuado cuando hay requerimientos muy bien definidos y que no van a cambiar Retroceder para corregir fases previas o introducir cambios es muy costoso El cliente sólo ve los resultados al final

12. Modelo orientado a hitos (I) Consiste en introducir hitos entregables al cliente durante el desarrollo del proyecto Especificación de requisitos Análisis Diseño de arquitectura Codificación y pruebas A Codificación y pruebas B Entrega B Codificación y pruebas C Entrega A Entrega C

13. Modelo orientado a hitos (II) Ventajas El cliente va viendo los resultados Permite reducir mucho el riesgo en proyectos grandes si se gestionan sus módulos de menor prioridad con esta técnica Inconvenientes Se analiza todo el sistema al principio, y se puede perder mucho tiempo en la especificación y diseño de funcionalidades que al final no nos da tiempo a implementar

14. Modelo orientado a prototipos (I) Se desarrolla un primer prototipo relativamente completo, frecuentemente destinado a ser ya utilizado por cliente. El cliente aporta realimentación y con ella se desarrolla el siguiente prototipo Se van repitiendo los ciclos de iteración hasta alcanzar una versión final. Prototipo 1 Prototipo 2 Prototipo 3

15. Modelo orientado a prototipos (II) Ventajas Es muy frecuente que los requisitos sean cambiantes, con lo cual se van adaptando los prototipos El cliente ya puede ir trabajando con los prototipos, viendo el resultado y aportando feedback Inconvenientes En proyectos grandes es imposible saber cuando se terminará Los desarrolladores tienen a saltarse las fases de análisis y diseño

16. Programación extrema (I) Consiste en llevar la límite el modelo de prototipos, haciendo entregas continuas con pequeños cambios en la funcionalidad

17. Programación extrema (II) Sus principios fundamentales son: Desarrollo iterativo e incremental Pruebas unitarias continuas Programación en parejas Frecuente interacción con el usuario Corrección de todos los errores antes de añadir nueva funcionalidad Hacer entregas frecuentes Refactorización del código Propiedad del código compartida Simplicidad en el código

18. Programación extrema (III) Ventajas Es muy realista con respecto a la relación con el cliente Le da importancia el diseño simple y las pruebas, un punto normalmente descuidado Aporta muy buenas ideas Inconvenientes Solo vale para proyectos relativamente pequeños (entre 2 y 12 desarrolladores) Sus principios no pueden ser aplicados a rajatabla, es necesario saber decidir cuando aplicar ciertas cosas y cuándo no

19. Cada área pasa por esos Procesos Curso de Gestión de Proyectos Proceso/Gestión Inicio Planificación Ejecución Control Cierre Alcance Tiempos Costos Riesgos Logística RRHH Comunicaciones Calidad Integración

20. ¿para qué? La Gestión de proyectos es el conjunto de conceptos técnicas y habilidades que permiten incrementar la probabilidad de éxito de un proyecto. ¿qué es un proyecto exitoso? ¿porqué hay tantos fracasos? Curso de Gestión de Proyectos

21. LAS 3 PROMESAS. DESEMPEÑO: el producto del proyecto cumple con lo esperado. TIEMPO: Se completa en el tiempo requerido. COSTO: Se completa dentro del presupuesto asignado. Interdependientes: se plantean múltiples trade-off entre las 3 dimensiones de éxito. Curso de Gestión de Proyectos

22. Errores frecuentes en las reuniones (I) Acompañarse de gente con experiencia en reuniones Nunca decir precios en reuniones de toma de requisitos (esperar al presupuesto) No dar a entender que el proyecto es sencillo, puede dar una idea equivocada sobre el precio que le vamos a dar al cliente No hablar de más, desvelando excesiva información sobre nuestra empresa u otros proyectos

23. Errores frecuentes en las reuniones (II) Cuidar la vestimenta, las formas y el lenguaje corporal No ignorar a los técnicos Tomar notas (puede estar bien grabarlas en audio o incluso levantar un “acta” de la reunión y enviarla por email) ¡Cuidado con las conversaciones informales!

24. Especificación de Requisitos (I) La captura de requisitos es parte esencial: evita cambios posteriores en el sistema y facilita el entendimiento con el cliente Deben especificar lo siguiente: Funcionalidad Interfaz externa Rendimiento Atributos Restricciones de diseño

25. Especificación de Requisitos (II) Como deben ser los requisitos: Completos Implementación independiente Consistentes y no ambiguos Precisos Verificables Que puedan ser leídos Modificables Muy importante: que nos permitan hacer un presupuesto

26. Especificación de Requisitos (III) La toma de requisitos: Introspección: ponerse en lugar del cliente e imaginar como desea que funcione el sistema Reuniones con el cliente Escuchar la problemática del cliente Entender la solución que espera Ser capaz de orientar y aconsejar al cliente durante la entrevista para orientarlo hacia nuestros productos o tecnologías Hay modelos estándard para la toma de requisitos, de los cuales se cubre lo que necesitemos

27. Presupuestación ¿Cuanto dinero va a costar realizar el proyecto? Lo más difícil a la hora de hacer un presupuesto de un proyecto TI: Diferenciar las tareas a presupuestar Estimar el tiempo de cada tarea Acotarlo de forma que el cliente no nos pueda “colar” tareas no estimadas inicialmente A la hora de poner un precio, las tareas de implementación se suelen cobrar por hora, pero hay más cosas que contemplar en los presupuestos...

28. Qué presupuestar (I) Análisis: el análisis del problema posterior al presupuesto previo a la elaboración del documento de análisis funcional y del diseño técnico Consultoría: cuando el objetivo del proyecto es la recomendación de medidas apropiadas y prestación de asistencia en la aplicación de dichas recomendaciones. Preparación del entorno: instalación de servidores, aplicaciones (CVS, IDEs, etc), etc.

29. Qué presupuestar (II) Implementación: las tareas de programación en sí Dirección de proyecto: las horas que dedica el director de proyecto a la coordinación de los programadores (se suele poner un 25% del tiempo de implementación) Implantación: instalación de la aplicación en los entornos del cliente. Cuidado con las subidas de los hitos entregables a los entornos del cliente

30. Qué presupuestar (II) Formación: suele estar hasta bien visto por el cliente dar un par de charlas de formación a los usuarios sobre la aplicación Documentación: análisis funcional, diseño técnico, manuales, documentos de puesta en producción, etc. Desplazamientos: cuando el cliente se encuentre a una distancia considerable, se incluyen dietas. Material: sobre todo hardware que se va a instalar en el cliente...

31. Los márgenes Margen de riesgo Se añade a las tareas para cubrir errores en las estimaciones Margen comercial Se añade para cubrir las tareas comerciales y para poder negociar bajando el precio al bajar este margen Margen de calidad Se deja para el control de calidad del código Margen al tiempo de entrega Se añade para cubrirse frente a que los recursos se tenga que dedicar a otras tareas

32. El flujo de caja Determina los plazos en los que el cliente va a pagar el proyecto Se suele intentar marcar hitos en el proyecto e ir cobrando un porcentaje a la entrega de esos hitos Muy importante no cobrar sólo al final del proyecto, sobre todo en proyectos largos, porque nos puede traer problemas financieros Tener cuidado con empresas que pagan con pagarés a 30, 60 o incluso 90 días

33. Clausulas de penalización En algunos casos los clientes pueden pedir que se incluyan clausulas que penalicen el retraso del proyecto Limitarlas a un porcentaje del costo total del proyecto (un 20% como mucho) Cubrirse las espaldas en la estimación de tiempos, sobre todo aplicando margen al tiempo de entrega

34. El cálculo de la rentabilidad Es muy importante tener un modelo de presupuesto que luego nos permita hacer un cálculo de la rentabilidad sobre los tiempos estimados Para ello durante la fase de implementación mediremos los tiempos que lleva cada tarea y los compararemos con el estimado (control de tareas) Esto nos será de mucha ayuda en futuros presupuestos

35. Otras formas de presupuestar Muchas veces lo que se presupuestan no son sólo proyectos, pueden ser: Productos de software ya terminados: lo que se vende es la licencia y en muchos casos la implantación. Mantenimientos mensuales: con una cuota fija al mes para realizar tareas de mantenimiento de una aplicación. Packs de horas: se le cobran al cliente X horas que éste irá consumiendo según se vayan realizando desarrollos solicitados.

36. Licencias Una vez que tenemos un proyecto de software desarrollado podemos establacer licencias para venderlo a varios clientes. Estas licencias pueden ser: Por empresa Por usuario de la empresa Por cliente de la empresa que utilice la aplicación Por CPU de servidor etc.

37. Volvamos al primer problema : Transformar la IDEA en un OBJETIVO del proyecto. dentro del Entorno Estratégico de la Empresa. requiere un ENFOQUE METODOLÓGICO PRÁCTICO Curso de Gestión de Proyectos

38. el QUÉ del proyecto. Curso de Gestión de Proyectos OBJETIVO idea Expresión concreta del resultado a obtener en términos de : Alcance, desempeño, tiempo y costo .

39. Objetivos específicos Se debe definir específicamente que debo lograr (en tiempos y/o costos y/o técnicamente) con la ejecución del proyecto para alcanzar el objetivo general. Cada objetivo específico que defina consumirá recursos para alcanzarse. Curso de Gestión de Proyectos

40. Características : Deben ser: concretos, no generales verificable objetivamente que se alcanzó el objetivo realistas y alcanzables Consistentes con los recursos disponibles o previstos Consistentes con los planes, políticas y procedimientos de la empresa No excesivamente complejos. Curso de Gestión de Proyectos

41. Entregables ¿Cómo alcanzo los objetivos específicos? ¿Qué debo tener al final del proyecto para decir que cada objetivo específico se alcanzó? Entregables: Resultados tangibles y verificables que marcan que uno o varios objetivos se alcanzaron. Curso de Gestión de Proyectos

42. Entregables Están relacionados con el “cómo” voy a realizar el proyecto. ¿ Qué productos voy a entregar para alcanzar el objetivo? Ej.: para poder obtener la información de un cliente en menos de 10 segundos puedo tener distintos entregables según como lo implemente: Una bibliorato con un sistema fácil de índice Un software con una base de datos ....... Curso de Gestión de Proyectos

43. Ahora sí: La definición de los entregables dispara toda la metodología analítica conocida y en uso. A lo largo de la ejecución del proyecto toda la gestión de los cambios, la delegación y la gestión de riesgos se ve a la luz de la línea estratégica de la empresa. Curso de Gestión de Proyectos

44. Dos realidades Las empresas que realizan proyectos en su seno: el producto del proyecto se integra a la empresa. Las empresas que ejecutan proyectos para terceros: viven de ejecutar proyectos para otros. Curso de Gestión de Proyectos

45. Curso de Gestión de Proyectos Dos tipos de problemas 1. Incorrecta definición inicial del alcance y la especificación del mismo. 2. Modificaciones al alcance durante el desarrollo del proyecto Por ej. Un proyecto tiene un presupuesto de 1000 Si se hubiera planificado desde el inicio, con el nuevo alcance costaría 2000. Pero al introducir la modificación durante la ejecución del proyecto lleva los costos a 5.000 en lugar de 2000.