Proyectos software

2,042 views

Published on

Una aproximación teórica e introductoria para la gestión de proyectos de software para alcanzar el éxito en tiempo y recursos.

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,042
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

Proyectos software

  1. 1. Dirección de proyectos software Hermenegildo Romero © 2009 DATABASE TEAM http:// www.db - team.com
  2. 2. <ul><li>INDICE </li></ul><ul><ul><li>Introducción </li></ul></ul><ul><ul><li>PMBOK </li></ul></ul><ul><ul><li>Buenas Prácticas en Gestión de Proyectos </li></ul></ul><ul><ul><li>Metodologías Ágiles para la Gestión de Proyectos </li></ul></ul>Dirección de proyectos software
  3. 3. INTRODUCCIÓN
  4. 4. Introducción <ul><li>Qué es la administración: </li></ul><ul><ul><li>Es el proceso de planear, organizar, dirigir y controlar, las actividades y el uso de los recursos con el fin de lograr uno o más objetivos. </li></ul></ul><ul><li>Qué es un proyecto: </li></ul><ul><ul><li>Es un trabajo o esfuerzo que se ejecuta una sola vez y que persigue un fin específico, y tiene como característica principal producir resultados únicos como un producto o un servicio. </li></ul></ul><ul><ul><li>Para alcanzar el fin establecido, es necesario definir objetivos o metas (qué hacer) y actividades o procesos (cómo hacer) que deberán cumplirse en un tiempo asignado, considerando para ello el inicio y termino del mismo. </li></ul></ul><ul><ul><li>Necesario es entonces también, la asignación y organización de todos los recursos involucrados para su ejecución. </li></ul></ul><ul><ul><li>Para su ejecución y éxito, el proyecto debe seguir una serie de pasos realizados por roles involucrados, para ir cumpliendo objetivos y/o desarrollando/utilizando productos y recursos. </li></ul></ul>
  5. 5. Introducción <ul><li>Los principales parámetros de un proyecto son: </li></ul><ul><ul><li>Alcance </li></ul></ul><ul><ul><li>Recursos (costo del esfuerzo principalmente) </li></ul></ul><ul><ul><li>Tiempo </li></ul></ul><ul><li>Estos parámetros reúnen las 2 características siguientes: </li></ul><ul><ul><li>Cada parámetro es función de los otros 2 </li></ul></ul><ul><ul><li>Mover un parámetro implica cambios a los otros (por lo menos a 1) </li></ul></ul><ul><li>En conclusión podemos decir que un proyecto es la ejecución en un momento determinado de un proceso o actividades con un tiempo, un costo y un alcance definido y es el principal objetivo del líder de proyecto el planearlos y controlarlos. </li></ul>
  6. 6. Perfil del líder del proyecto <ul><li>El líder de proyecto, o administrador de proyectos, es responsable de administrar proyectos desde que inicia hasta que se completa. </li></ul><ul><li>Entre sus responsabilidades se incluye: </li></ul><ul><ul><li>el desarrollo del plan del proyecto, </li></ul></ul><ul><ul><li>la identificación de los requerimientos y el alcance del proyecto, </li></ul></ul><ul><ul><li>la comunicación, </li></ul></ul><ul><ul><li>la administración de los recursos humanos y materiales, </li></ul></ul><ul><ul><li>el control de tiempos, </li></ul></ul><ul><ul><li>identificación y control de riesgos, </li></ul></ul><ul><ul><li>administración de los costos/presupuesto, el aseguramiento de la calidad, </li></ul></ul><ul><ul><li>el reporte y evaluación del desempeño del proyecto. </li></ul></ul>
  7. 7. Perfil del líder del proyecto <ul><li>El líder de proyecto debe mantener su foco en asegurar que el proyecto se termine en el tiempo y presupuesto planeado, y muy frecuentemente con tiempos limitados. </li></ul><ul><li>Algunas de las cualidades que uno debe tener para convertirse en un buen líder de proyecto son las siguientes: </li></ul><ul><ul><li>Organizado y metódico </li></ul></ul><ul><ul><li>Facilidad para relacionarse con gente </li></ul></ul><ul><ul><li>Buena comunicación oral y escrita </li></ul></ul><ul><ul><li>Liderazgo </li></ul></ul><ul><ul><li>Conocimientos técnicos básicos </li></ul></ul>
  8. 8. El Triangulo de administración de proyectos <ul><li>El concepto básico que todo administrador de proyectos debe de manejar es el referente al triángulo de administración de proyectos. Se trata de tener muy claro desde un principio cuál es el alcance del proyecto, el tiempo requerido y los recursos/presupuesto necesario para completarlo. Son los tres parámetros básicos con los que tendrá que lidiar el administrador de proyectos y que, al final, determinarán en gran medida si el proyecto fue o no exitoso. </li></ul>
  9. 9. El Triangulo de administración de proyectos <ul><li>En un principio hay que identificar cuál es el alcance del proyecto, es decir cuáles son los requerimientos a satisfacer en el proyecto. Con base en esta información podemos determinar cuántos recursos (gente, herramientas, presupuesto) necesitamos para poder desarrollarlo. Pero, esto dependerá del tiempo en el que se requiera completar el proyecto. Si tenemos disponibilidad de recursos, entonces podremos reducir el tiempo. Si no hay presión de tiempo entonces podremos disponer de menos personal y recursos para poderlo completar. </li></ul>
  10. 10. El Triangulo de administración de proyectos <ul><li>Si se nos da flexibilidad en cuanto al alcance a cubrir, entonces podremos reducir tiempos y/o recursos para el proyecto. </li></ul><ul><li>Nuestro cliente en el proyecto nos puede restringir dos de los tres parámetros, pero nunca los tres. Cuando inicies un proyecto dale a escoger 2 de 3: alcance, tiempo o costo. Si pretende imponerte los 3 la probabilidad de tener un proyecto exitoso será cercana a cero. </li></ul>
  11. 11. El Triangulo de administración de proyectos
  12. 12. El Triangulo de administración de proyectos <ul><li>Determinar los tiempos y costes es una tarea de por sí complicada. </li></ul><ul><li>Si decides aceptar una fecha límite con recursos limitados con un objetivo o alcance no negociable, entonces estás en serios problemas. </li></ul><ul><li>Si se da el caso de que tú y tu equipo sobrevivan al proyecto y lo terminen bajo estas condiciones, muy probablemente el nivel de calidad del producto terminado dejará mucho que desear. </li></ul><ul><li>Comenzar un proyecto con un plan de trabajo irreal es la mejor fórmula para fracasar en la administración de tu proyecto. </li></ul>
  13. 13. Modelos <ul><li>PMBOK </li></ul><ul><li>CMMI </li></ul>
  14. 14. PMBOK
  15. 15. PMBOK <ul><li>La Guía de los fundamentos de la dirección de proyectos (más conocida como PMBOK) es el estándar más ampliamente reconocido para manejar y administrar proyectos. </li></ul><ul><li>En realidad, se trata de una obra realizada por personas con un agudo sentido práctico, y que tiene incorporada la concepción de que un proyecto exitoso va a ser resultado de la colaboración (y los conflictos) entre los integrantes del proyecto </li></ul><ul><li>Citando uno de los párrafos introductorios del PMBOK: «“Buenas prácticas” no quiere decir que los conocimientos descritos deban aplicarse siempre de manera uniforme en todos los proyectos: el equipo de dirección del proyecto es el responsable de determinar lo que es apropiado para cada proyecto determinado.» </li></ul>
  16. 16. PMBOK <ul><li>Carácter y finalidad del PMBOK </li></ul><ul><ul><li>El conjunto de conocimientos (the body of knowledge) para dirigir un proyecto “residen en los practicantes y académicos que los aplican y los desarrollan”. </li></ul></ul><ul><ul><li>Estos conocimientos representan un conjunto vivo, extraordinariamente amplio, producto tanto de la experiencia como del estudio y del desarrollo sistemáticos. </li></ul></ul><ul><ul><li>La finalidad del PMBOK, no es la de exponer las disciplinas, técnicas y experiencias aplicables a la dirección de proyectos, sino simplemente la de identificar el subconjunto de éstas que es generalmente reconocido como buenas prácticas. </li></ul></ul>
  17. 17. PMBOK <ul><li>Para que estas buenas prácticas sean asequibles, el PMBOK divide el conjunto de conocimientos para la dirección de proyectos en cuatro grupos de procesos: todo proyecto (así como sus distintas fases e iteraciones) tiene que transitar por una serie de actividades de inicio, de planeación, de ejecución y cierre, bajo el gobierno de un grupo de procesos más general de supervisión y cierre. </li></ul>
  18. 18. PMBOK <ul><li>Estos grupos de procesos no representan fases rígidas ni recetas, sino que, grosso modo, equivalen al modelo “planear, hacer, revisar y actuar”. </li></ul>
  19. 19. PMBOK <ul><li>PMBOK está agrupado en nueve áreas de conocimiento, que son propiamente las que contienen las técnicas para poder realizar los proyectos. </li></ul><ul><li>Las nueve áreas de conocimiento son: </li></ul>
  20. 20. PMBOK <ul><li>Para cada una de estas áreas de conocimiento, el PMBOK recomienda la realización de una serie de procesos. </li></ul><ul><ul><ul><li>Por ejemplo, la Gestión del alcance comprende los procesos Planificar alcance, Definición del alcance, Crear estructura de desglose de tareas, Verificación de alcance y Control de alcance. </li></ul></ul></ul>
  21. 21. PMBOK <ul><li>Para cada uno de estos procesos de las áreas de conocimiento, el PMBOK plantea o sugiere una serie de entradas, técnicas y salidas. </li></ul><ul><ul><li>Como hemos visto con anterioridad, el PMBOK identifica las mejores prácticas que son generalmente aceptadas para la realización de cada uno de estos procesos. </li></ul></ul>
  22. 22. PMBOK Áreas de conocimiento <ul><li>Gestión de la Integración </li></ul><ul><ul><li>Se refiere a los procesos requeridos para asegurar que los elementos varios de un proyecto están coordinados apropiadamente. </li></ul></ul><ul><ul><li>Consiste en </li></ul></ul><ul><ul><ul><li>el desarrollo de un plan de proyecto </li></ul></ul></ul><ul><ul><ul><li>ejecución del plan de proyecto </li></ul></ul></ul><ul><ul><ul><li>control de cambios en general. </li></ul></ul></ul>
  23. 23. PMBOK Áreas de conocimiento <ul><li>Gestión del Alcance </li></ul><ul><ul><li>Se refiere al proceso requerido para asegurar que el proyecto incluye todo trabajo requerido, y sólo el trabajo requerido, para completar el proyecto de manera exitosa. </li></ul></ul><ul><ul><li>Consiste en </li></ul></ul><ul><ul><ul><li>planeación del alcance </li></ul></ul></ul><ul><ul><ul><li>definición del alcance </li></ul></ul></ul><ul><ul><ul><li>verificación del alcance </li></ul></ul></ul><ul><ul><ul><li>control de cambio al alcance. </li></ul></ul></ul>
  24. 24. PMBOK Áreas de conocimiento <ul><li>Gestión del Tiempo </li></ul><ul><ul><li>Se refiere a los procesos requeridos para asegurar la terminación a tiempo del proyecto. </li></ul></ul><ul><ul><li>Consiste en </li></ul></ul><ul><ul><ul><li>la definición de las actividades </li></ul></ul></ul><ul><ul><ul><li>secuencia de las actividades </li></ul></ul></ul><ul><ul><ul><li>estimación de duración de las actividades </li></ul></ul></ul><ul><ul><ul><li>desarrollo del cronograma </li></ul></ul></ul><ul><ul><ul><li>control de la programación. </li></ul></ul></ul>
  25. 25. PMBOK Áreas de conocimiento <ul><li>Gestión de los Costes </li></ul><ul><ul><li>Se refiere a los procesos requeridos para asegurar que el proyecto es completado dentro del presupuesto aprobado. </li></ul></ul><ul><ul><li>Consiste en </li></ul></ul><ul><ul><ul><li>la planificación de recursos </li></ul></ul></ul><ul><ul><ul><li>estimación de costos </li></ul></ul></ul><ul><ul><ul><li>presupuesto de costos </li></ul></ul></ul><ul><ul><ul><li>control de costos </li></ul></ul></ul>
  26. 26. PMBOK Áreas de conocimiento <ul><li>Gestión de la Calidad </li></ul><ul><ul><li>Se refiere a los procesos requeridos para asegurar que el proyecto va a satisfacer las necesidades para lo cual fue desarrollado. </li></ul></ul><ul><ul><li>Consiste en </li></ul></ul><ul><ul><ul><li>la planificación de la calidad </li></ul></ul></ul><ul><ul><ul><li>aseguramiento de la calidad </li></ul></ul></ul><ul><ul><ul><li>control de calidad. </li></ul></ul></ul>
  27. 27. PMBOK Áreas de conocimiento <ul><li>Gestión de los Recursos Humanos </li></ul><ul><ul><li>Se refiere a los procesos requeridos para hacer el uso más eficiente de las personas involucradas en el proyecto. </li></ul></ul><ul><ul><li>Consiste en </li></ul></ul><ul><ul><ul><li>Planificación de la organización </li></ul></ul></ul><ul><ul><ul><li>Contratación </li></ul></ul></ul><ul><ul><ul><li>Desarrollo del equipo </li></ul></ul></ul>
  28. 28. PMBOK Áreas de conocimiento <ul><li>Gestión de las Comunicaciones </li></ul><ul><ul><li>Se refiere a los procesos requeridos para asegurar la generación apropiada y a tiempo, colección, diseminación, almacenamiento, y la disposición final de la información del proyecto. </li></ul></ul><ul><ul><li>Consiste en </li></ul></ul><ul><ul><ul><li>la planificación de la comunicación </li></ul></ul></ul><ul><ul><ul><li>distribución de la información </li></ul></ul></ul><ul><ul><ul><li>informes de desempeño </li></ul></ul></ul><ul><ul><ul><li>cierre administrativo. </li></ul></ul></ul>
  29. 29. PMBOK Áreas de conocimiento <ul><li>Gestión del Riesgo </li></ul><ul><ul><li>Se refiere a los procesos relacionados con la identificación, análisis, y respuesta al riesgo del proyecto. </li></ul></ul><ul><ul><li>Consiste en </li></ul></ul><ul><ul><ul><li>Identificación del riesgo </li></ul></ul></ul><ul><ul><ul><li>cuantificación del riesgo </li></ul></ul></ul><ul><ul><ul><li>desarrollo de la respuesta al riesgo </li></ul></ul></ul><ul><ul><ul><li>control de la respuesta al riesgo. </li></ul></ul></ul>
  30. 30. PMBOK Áreas de conocimiento <ul><li>Gestión de las adquisiciones </li></ul><ul><ul><li>Se refiere a los procesos requeridos para adquirir bienes y servicios de fuera de la organización que ejecuta el proyecto. </li></ul></ul><ul><ul><li>Consiste en </li></ul></ul><ul><ul><ul><li>Planificación de la gestión de la adquisición </li></ul></ul></ul><ul><ul><ul><li>Planificación de solicitudes </li></ul></ul></ul><ul><ul><ul><li>Realización de solicitudes </li></ul></ul></ul><ul><ul><ul><li>Selección de proveedores </li></ul></ul></ul><ul><ul><ul><li>Administración de contratos </li></ul></ul></ul><ul><ul><ul><li>Cierre de contratos. </li></ul></ul></ul>
  31. 31. BUENAS PRÁCTICAS EN GESTIÓN DE PROYECTOS
  32. 32. Guía básica de gestión de proyectos <ul><li>Conoce tu proyecto </li></ul><ul><li>Planifica las actividades, tiempos y recursos </li></ul><ul><li>Ejecuta y monitoriza el proyecto, manteniendo la visibilidad hacia el exterior </li></ul><ul><li>Aprende de tus errores </li></ul>
  33. 33. Guía básica de gestión de proyectos <ul><li>Conoce tu proyecto </li></ul><ul><ul><li>¿cuál es el objetivo a cumplir? </li></ul></ul><ul><ul><li>Identifica a las personas que te pueden proporcionar información al respecto </li></ul></ul><ul><ul><li>Ubica bien a las personas que tienen la información. </li></ul></ul><ul><ul><li>Consulta hasta el menor detalle posible. </li></ul></ul><ul><ul><li>Determina claramente los requerimientos del proyecto. </li></ul></ul>
  34. 34. Guía básica de gestión de proyectos <ul><li>Planifica las actividades, tiempos y recursos </li></ul><ul><ul><li>Número de recursos humanos. </li></ul></ul><ul><ul><li>Perfiles requeridos. </li></ul></ul><ul><ul><li>Esfuerzo requerido por cada uno de los integrantes del equipo. </li></ul></ul><ul><ul><li>Tiempos necesarios para completar cada una de las tareas. </li></ul></ul><ul><ul><li>Presta atención a los </li></ul></ul><ul><ul><ul><li>Tiempos muertos </li></ul></ul></ul><ul><ul><ul><li>Recursos infrautilizados </li></ul></ul></ul><ul><ul><ul><li>Recursos sobrevalorados </li></ul></ul></ul>
  35. 35. Guía básica de gestión de proyectos <ul><li>Ejecuta y monitoriza el proyecto, manteniendo la visibilidad hacia el exterior </li></ul><ul><ul><li>Una vez diseñado el plan hay que seguirlo </li></ul></ul><ul><ul><ul><li>Para esto es necesario monitorizar continuamente para poder reaccionar de manera oportuna. </li></ul></ul></ul><ul><ul><ul><ul><li>¿Ya inicio la gente el trabajo que le corresponde? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>¿Ya terminó el trabajo que debía terminar? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>¿por qué se está atrasando? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>¿cuánto se está desviando? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>¿qué puedes hacer para que no se siga retrasando? </li></ul></ul></ul></ul><ul><ul><li>Tu jefe y tu cliente también quieren saber como va el proyecto </li></ul></ul><ul><ul><ul><li>Es mejor mantenerlos continuamente informados, esto te permitirá tomar decisiones consensuadas y evitar las sorpresas de última hora. </li></ul></ul></ul>
  36. 36. Guía básica de gestión de proyectos <ul><li>Aprende de tus errores </li></ul><ul><ul><li>Aprender continuamente te ayudará en gran medida a que tus resultados sean cada vez mejores. </li></ul></ul><ul><ul><li>Comparte el conocimiento </li></ul></ul><ul><ul><li>Einstein dijo: </li></ul></ul><ul><ul><ul><li>“ no hay nada peor que hacer las cosas igual y esperar resultados diferentes” </li></ul></ul></ul><ul><ul><ul><ul><li>Si descubriste que hay cosas que ocasionan retrasos y problemas en tus proyectos...¡¡No lo vuelvas a repetir!! </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Si hubo actividades que ayudaron al éxito del proyecto, entonces ...¡¡ Procura volver a realizarlas!! </li></ul></ul></ul></ul><ul><ul><li>Localiza buenas practicas de otros que ya han pasado por lo que tu estás pasando </li></ul></ul><ul><ul><ul><li>Libros, internet, etc... Te ayudarán a compartir el conocimiento </li></ul></ul></ul>
  37. 37. Recopilación de Requerimientos <ul><li>El líder de proyecto debe utilizar cualquier medio posible para obtener los requerimientos del sistema. Esto lo realiza en especial durante la primera fase del proyecto. Aunque es normal que siga haciéndolo en las demás fases en menor medida, pues difícilmente se podrán tener los requerimientos totalmente estables ni completos desde un principio. </li></ul><ul><li>Una de las principales formas de obtener dicha información es mediante reuniones donde el analista debe guiar la entrevista y documentar todos los puntos importantes que allí se vayan mencionando. </li></ul>
  38. 38. Recopilación de Requerimientos <ul><li>Se deben analizar los documentos con los que se cuente para preparar una agenda y cuestionarios para cada entrevista y así obtener mejores resultados. </li></ul><ul><li>Debe de tomar en cuenta la opinión de los diferentes stakeholders del proyecto, desde el responsable del área a la cual se le está desarrollando el sistema, hasta el usuario final. </li></ul><ul><li>Durante las reuniones se deben de elaborar actas con los acuerdos y enviarlas a los participantes para su validación. </li></ul><ul><ul><li>Si no responden en un tiempo acordado con sus observaciones se considerarán como aceptadas. </li></ul></ul><ul><ul><li>La información documentada en las actas no reemplaza a los documentos formales de requerimientos, como podrían ser la visión, la especificación y matriz de requerimientos, las especificaciones de casos de uso o la especificación suplementaria. </li></ul></ul>
  39. 39. Recopilación de Requerimientos <ul><li>Se recomienda utilizar mecanismos que faciliten la retroalimentación y participación de usuarios, como es el caso de modelos, prototipos no funcionales y casos de uso. </li></ul><ul><li>Durante la fase preliminar (Concepción en el caso del Proceso Unificado) hay que identificar los requerimientos de alto nivel del sistema en un documento de Visión y detallarlos en Especificaciones de casos de uso y especificación suplementaria durante la fase de Análisis (fase de Elaboración para el caso de UP). </li></ul><ul><li>Los requerimientos documentados son la base para que el administrador realice las estimaciones y el plan del proyecto en general. </li></ul><ul><ul><li>Necesitará la validación del usuario a todos los documentos donde se especifiquen los requerimientos. </li></ul></ul>
  40. 40. Recopilación de Requerimientos <ul><li>El administrador no debería asumir nada. </li></ul><ul><ul><li>Es importante que se asegure que está entendiendo correctamente lo que el usuario quiso decir, por lo que debe validar la información escrita y formalizarla por medio de firmas de aprobación de los usuarios. </li></ul></ul>
  41. 41. Planificación del proyecto <ul><li>El administrador del proyecto, una vez que comienza el proyecto y recopila la información básica de requerimientos en la fase inicial, realiza un plan de trabajo especificando los diferentes aspectos en cuanto a la forma de trabajo, llenando las diferentes secciones del documento correspondiente. </li></ul><ul><li>Utilizando el ciclo de vida elegido desarrolla el desglose de actividades en un plan (por ejemplo en un Gantt) al máximo detalle posible, procurando que las actividades duren en promedio 2 a 3 días, dependiendo del tamaño del proyecto. </li></ul><ul><ul><li>En proyectos pequeños las actividades deberían de ser de unas cuantas horas. </li></ul></ul>
  42. 42. Planificación del proyecto <ul><li>Se estima el esfuerzo apoyándose con los recursos que llevarán a cabo dichas actividades. </li></ul><ul><li>A las actividades les asigna responsabilidades y dependencias de acuerdo a la cantidad de recursos y al ciclo de vida. </li></ul><ul><li>Para facilitar el desarrollo de este Gantt se recomienda utilizar un formato ya establecido con las fases y actividades típicas para el proyecto. </li></ul><ul><li>Una vez desarrollado el plan debería registrar la versión de dicho plan en el control de versiones correspondiente. </li></ul><ul><ul><li>Es importante llevar un control de la evolución del plan. </li></ul></ul><ul><ul><li>El plan es algo vivo que está en constante cambio y evolución. </li></ul></ul>
  43. 43. Estimación del esfuerzo del proyecto <ul><li>Existe una relación importante entre el tiempo y el esfuerzo. </li></ul><ul><ul><li>El esfuerzo se refiere a la suma de los tiempos que le dedicarán los diferentes recursos a cierta actividad o al proyecto. </li></ul></ul><ul><ul><li>Se mide en </li></ul></ul><ul><ul><ul><li>horas/hombre </li></ul></ul></ul><ul><ul><ul><li>días/hombre </li></ul></ul></ul><ul><ul><ul><li>semanas/hombre, etc. </li></ul></ul></ul><ul><ul><li>No importa que el trabajo se haga de forma secuencial por un solo recurso o en paralelo por diferentes personas. Se suman los tiempos de cada uno de ellos para obtener el esfuerzo total. </li></ul></ul>
  44. 44. Estimación del esfuerzo del proyecto <ul><li>Cuando hablamos de tiempos del proyecto, normalmente nos referimos al periodo en el calendario que será necesario para poder cumplir ciertos objetivos. </li></ul><ul><ul><li>Por ejemplo, para terminar el proyecto podríamos determinar un tiempo necesario de tres meses, mientras que el esfuerzo para dicho proyecto podría ser de seis meses/hombre si trabajaran todo ese tiempo dos personas en paralelo. </li></ul></ul><ul><li>Si el proyecto sigue un ciclo de vida iterativo incremental, al estilo de UP (Proceso Unificado), se debe realizar una estimación inicial en la fase de concepción, pero dicha estimación debe ser refinada al completar la fase siguiente (fase de elaboración). </li></ul><ul><ul><li>En la fase de elaboración se tiene mayor detalle de los requerimientos y la arquitectura del sistema, información que permite estimar con mayor precisión. </li></ul></ul>
  45. 45. Estimación del esfuerzo del proyecto <ul><li>Cada participante del equipo de trabajo debería de estimar el esfuerzo de sus actividades, desglosando dichas actividades a un nivel de granularidad tal que las actividades tengan un esfuerzo menor a 2 o 3 días. </li></ul><ul><ul><li>Incluso puede ser de sólo unas horas. </li></ul></ul><ul><li>Tal estimación debe ser revisada por el administrador del proyecto para validar que los tiempos sean razonables y realistas y que no falten actividades dentro del desglose del trabajo. </li></ul>
  46. 46. Estimación del esfuerzo del proyecto <ul><li>Algunas recomendaciones para realizar la estimación del esfuerzo del proyecto. </li></ul><ul><ul><li>No des una estimación sin antes haber analizado tranquilamente todo el trabajo que implica </li></ul></ul><ul><ul><li>Incluye en tu plan, tiempo para realizar esta estimación </li></ul></ul><ul><ul><li>Usa datos de proyectos anteriores </li></ul></ul><ul><ul><li>Establece una política de estimación por consenso </li></ul></ul><ul><ul><li>Asigna niveles de complejidad a los casos de uso y asócialos con tiempos de acuerdo a tu experiencia (complejo, medio y simple) </li></ul></ul><ul><ul><li>Granulariza al máximo nivel de detalle tus actividades del plan </li></ul></ul><ul><ul><li>No omitas tareas necesarias, básate en las plantillas de plan o en planes anteriores de proyectos exitosos </li></ul></ul><ul><ul><li>Confirma tu estimación con la opinión de otras personas o comparándola contra alguna técnica como serían Puntos de Función o Puntos de Casos de Uso </li></ul></ul><ul><ul><li>Cuantifica el impacto que podrían tener los riesgos de tu proyecto </li></ul></ul>
  47. 47. Riesgos en la administración de proyectos <ul><li>Evaluación del riesgo </li></ul><ul><ul><li>Hacer una lista de todos los peligros potenciales que afectarán el proyecto (identificación del riesgo) </li></ul></ul><ul><ul><li>Determinar la probabilidad de las consecuencias de la ocurrencia y de la pérdida del potencial de cada elemento identificado (cuantificación del riesgo) </li></ul></ul><ul><ul><li>Clasificar los elementos  (del más al menos peligroso) </li></ul></ul>
  48. 48. Riesgos en la administración de proyectos <ul><li>Control del riesgo </li></ul><ul><ul><li>Establecer técnicas y estrategias para atenuar los riesgos más altos (planeación del riesgo) </li></ul></ul><ul><ul><li>Ejecutar estrategias para resolver los factores de alto riesgo (respuesta del riesgo) </li></ul></ul><ul><ul><li>Supervisar de la eficacia de las estrategias y de los niveles de modificación de  riesgos a lo largo del proyecto </li></ul></ul>
  49. 49. Riesgos en la administración de proyectos <ul><li>La información para determinar el riesgo se recoge de: </li></ul><ul><ul><li>Descripción del producto. </li></ul></ul><ul><ul><ul><li>La naturaleza del producto del proyecto tendrá un efecto mayor en los riesgos identificados. </li></ul></ul></ul><ul><ul><ul><ul><li>Por ejemplo, los productos que implican tecnología probada, en igualdad de circunstancias, implicarán menos riesgo que productos que requieren innovación o invención. </li></ul></ul></ul></ul><ul><ul><li>Documentos/planes del proyecto </li></ul></ul><ul><ul><ul><li>Las revisiones del documento de alcance, del plan del proyecto, del plan de adquisición del personal, etc. pueden revelar riesgos. </li></ul></ul></ul><ul><ul><li>Información histórica </li></ul></ul><ul><ul><ul><li>Bases de Datos del proyecto, expedientes del proyecto, experiencia del personal. </li></ul></ul></ul><ul><ul><li>Entrevistas del Cliente y/o Usuario y estudios de viabilidad </li></ul></ul>
  50. 50. Riesgos en la administración de proyectos <ul><li>Identificación del riesgo </li></ul><ul><ul><li>La identificación del riesgo debe considerar riesgos internos y externos. </li></ul></ul><ul><ul><ul><li>Los riesgos internos son los elementos que el equipo de proyecto puede controlar o influenciar, por ejemplo asignaciones del personal. </li></ul></ul></ul><ul><ul><ul><li>Los riesgos externos van más allá del control o de la influencia del equipo de proyecto, tal como cambios de mercado o acciones del Gobierno. </li></ul></ul></ul><ul><ul><li>Podemos también hablar de riesgo inherente que resultan de la naturaleza de los objetivos y del alcance o riesgo adquirido que resulta del enfoque, metodologías, herramientas, técnicas, habilidades y de la experiencia que se aplican al proyecto </li></ul></ul>
  51. 51. Riesgos en la administración de proyectos <ul><li>Herramientas y técnicas para la identificación del riesgo </li></ul><ul><ul><li>Checklists </li></ul></ul><ul><ul><ul><li>Las listas de comprobación se agrupan típicamente por la fuente del riesgo. </li></ul></ul></ul><ul><ul><li>Diagramas  </li></ul></ul><ul><ul><ul><li>Los diagramas pueden ayudar al equipo de proyecto a entender mejor las causas y efectos de los riesgos. </li></ul></ul></ul><ul><ul><li>Entrevistas </li></ul></ul><ul><ul><ul><li>Las entrevistas orientadas a riesgos con los involucrados (personas que serán afecatadas) pueden ayudar a identificar riesgos no tenidos en cuenta durante la planificación. </li></ul></ul></ul><ul><ul><ul><li>Los registros de las entrevistas previas al proyecto deben estar disponibles   </li></ul></ul></ul><ul><ul><ul><ul><li>por ejemplo, las aplicadas durante el estudio de viabilidad. </li></ul></ul></ul></ul>
  52. 52. Fuentes de Riesgo <ul><li>Riesgos asociados al Cliente y/o Usuario </li></ul><ul><ul><li>Requerimientos (requisitos) confusos / incompletos </li></ul></ul><ul><ul><li>Cambios frecuentes a los requerimientos (requisitos) del proyecto durante la ejecución del mismo </li></ul></ul><ul><ul><li>Cliente y/o Usuario que no es eficiente a la hora cumplir sus responsabilidades del proyecto </li></ul></ul><ul><ul><li>Cliente y/o Usuario que no está lo suficientemente disponible o que no conoce lo suficiente para proporcionar  información precisa de los requerimientos (requisitos)  y /o proceso de revisión. </li></ul></ul><ul><ul><li>Cliente y/o Usuario que no tiene expectativas realistas sobre los resultados del proyecto. </li></ul></ul><ul><ul><li>Restricciones Contractuales </li></ul></ul><ul><ul><ul><li>como penalizaciones por no lograr fechas límite o penalizaciones de la terminación. </li></ul></ul></ul>
  53. 53. Fuentes de Riesgo <ul><li>Riesgos asociados a los calendarios </li></ul><ul><ul><li>Tareas o Hitos (Milestones) faltantes </li></ul></ul><ul><ul><li>Duración inexacta de la métrica </li></ul></ul><ul><ul><li>Estimaciones no precisas </li></ul></ul><ul><ul><li>Un calendario basado en cantidades exageradas de tiempo extra para todo el equipo. </li></ul></ul>
  54. 54. Fuentes de Riesgo <ul><li>Riesgos asociados a los recursos </li></ul><ul><ul><li>Roles y/o responsabilidades NO claras </li></ul></ul><ul><ul><li>Recursos NO disponibles </li></ul></ul><ul><ul><li>Habilidades y/o Conocimientos requeridos NO satisfechos o inadecuados </li></ul></ul><ul><ul><li>Equipo insuficiente o Inadecuado </li></ul></ul><ul><ul><li>Rotación del personal </li></ul></ul>
  55. 55. Fuentes de Riesgo <ul><li>Riesgos asociados a la Experiencia </li></ul><ul><ul><li>Nueva Tecnología </li></ul></ul><ul><ul><li>Nuevo ambiente de desarrollo </li></ul></ul><ul><ul><li>Nuevo Hardware </li></ul></ul>
  56. 56. Fuentes de Riesgo <ul><li>Riesgos asociados al Proceso de Administración de Proyectos </li></ul><ul><ul><li>Descomposición de Tareas (WBS) </li></ul></ul><ul><ul><ul><li>Descomposición inadecuada al identificar todas las actividades que son parte del proyecto. </li></ul></ul></ul><ul><ul><li>Métricas </li></ul></ul><ul><ul><ul><li>Estimaciones de tiempo y coste </li></ul></ul></ul><ul><ul><ul><ul><li>las estimaciones agresivas o las desarrolladas con información insuficiente de tiempo conducen a un riesgo mayor. </li></ul></ul></ul></ul><ul><ul><li>Fallos en el Flujo de Trabajo </li></ul></ul><ul><ul><ul><li>En la entrega, en la autorización de la terminación, el no cumplimiento de  fechas límite en tareas. </li></ul></ul></ul><ul><ul><li>Fallos en el control de Calidad </li></ul></ul><ul><ul><ul><li>Existencia de procesos con fallos, carencia de la función de control de calidad </li></ul></ul></ul>
  57. 57. Seguimiento del proyecto <ul><li>Se debe tener una visibilidad adecuada en el progreso del proyecto. </li></ul><ul><ul><li>Esto ayudará para que el administrador del proyecto puedan tomar acciones correctivas cuando el desempeño del proyecto se desvía de manera significativa del plan del proyecto. </li></ul></ul><ul><li>El administrador del proyecto debe de reunirse con cierta frecuencia con los miembros del equipo para: </li></ul><ul><ul><li>Comparar los avances contra lo planeado </li></ul></ul><ul><ul><li>Identificar problemas que pudieran poner en riesgo el proyecto </li></ul></ul><ul><ul><li>Planear las acciones correctivas necesarias para garantizar el éxito del proyecto. </li></ul></ul>
  58. 58. Seguimiento del proyecto <ul><li>Para lograr el éxito de un proyecto es indispensable mantener un control o seguimiento a todos los parámetros básicos del proyecto: </li></ul><ul><ul><li>Alcance. </li></ul></ul><ul><ul><ul><li>Cantidad y Estado de los requerimientos, número de cambios </li></ul></ul></ul><ul><ul><li>Tiempo. </li></ul></ul><ul><ul><ul><li>Cumplimiento de las fechas y retrasos contra lo planeado. </li></ul></ul></ul><ul><ul><li>Progreso. </li></ul></ul><ul><ul><ul><li>Avance real vs planeado, desviación de fechas compromiso dado el trabajo terminado, productividad actual contra esperada, desviación proyectada. </li></ul></ul></ul><ul><ul><li>Coste. </li></ul></ul><ul><ul><ul><li>Costes reales vs planeados, rentabilidad planeada vs esperada, rentabilidad proyectada </li></ul></ul></ul><ul><ul><li>Calidad. </li></ul></ul><ul><ul><ul><li>Defectos, resultados de pruebas y revisiones, ritmo en que se han encontrado y corregido los errores </li></ul></ul></ul><ul><ul><li>Riesgos. </li></ul></ul><ul><ul><ul><li>Número de riesgos, ritmo en que se han resuelto </li></ul></ul></ul>
  59. 59. Seguimiento del proyecto <ul><li>El líder del proyecto debe enviar o presentar en una reunión un informe del estatus del proyecto al gerente responsable con información como la anteriormente mencionada. </li></ul><ul><li>En dichas reuniones deben de revisarse los planes, deben de actualizarse y en caso necesario hacer las modificaciones necesarias al plan para corregir cualquier desviación. </li></ul><ul><li>Puede ser de bastante utilidad utilizar una herramienta de software para llevar el control de los avances y el estado del proyecto. </li></ul><ul><ul><li>Por ej. Herramientas de gestión de proyectos y colaboración que actualmente podemos encontrar en servicios tipo SAS (software as a Service) </li></ul></ul>
  60. 60. Validar requerimientos con usuarios <ul><li>Parte indispensable del proyecto consiste en asegurar que el equipo de desarrollo entiende adecuadamente las necesidades del usuario para así desarrollar un sistema que cumpla con sus expectativas. </li></ul><ul><li>Para facilitar esto, el usuario debe revisar y firmar de autorizado los documentos donde estén especificados los requerimientos. </li></ul><ul><ul><li>casos de uso </li></ul></ul><ul><ul><li>el documento de Visión </li></ul></ul><ul><ul><li>cualquier otro documento donde hayan quedado documentados. </li></ul></ul><ul><li>El documento de visión debe validarlo el usuario al completarse la fase de concepción, y los requerimientos a detalle al completar la fase de elaboración. El líder de proyecto debe asegurarse que se realice dicha validación. </li></ul>
  61. 61. Control de cambios a los requerimientos <ul><li>Lo único constante en los proyectos son los cambios. </li></ul><ul><li>Debemos de acostumbrarnos a ellos y aceptarlos como algo normal. </li></ul><ul><ul><li>Cambios que solicitan los usuarios porque comprenden mejor lo que necesitan, o porque cambian las necesidades del negocio, porque se identifica una mejor forma de hacer las cosas o por cualquier otra razón. </li></ul></ul><ul><li>El problema no son los cambios a los requerimientos, sino el hecho de que se agreguen a la lista de requerimientos del proyecto sin considerar el impacto que tendrán sobre el plan. </li></ul><ul><ul><li>No hacerlo significa que cuando el proyecto se termine en una fecha posterior a la acordada originalmente, o con un presupuesto mayor al considerado, se le podría achacar al líder del proyecto como un fracaso. </li></ul></ul>
  62. 62. Control de cambios a los requerimientos <ul><li>El control de cambios es el proceso mediante el cual se asegura que no se realicen cambios que afecten el éxito del proyecto, y que aquellos que se implementen sean analizados, negociados y planeados de una manera adecuada. </li></ul><ul><li>Estando dentro de la fase de Elaboración o después de haber negociado el alcance y el plan de trabajo, si el usuario llegara a solicitar un cambio a los requerimientos establecidos, el administrador u otra persona debería de llenar una solicitud de cambio con la descripción del cambio. </li></ul>
  63. 63. Control de cambios a los requerimientos <ul><li>El cambio es analizado y se evalúa el impacto en costo y tiempo, si es aceptable para los recursos disponibles y el tiempo que se le puede asignar a dicho cambio, debe, además de ser aceptado por el usuario y autorizado por la gerencia. </li></ul><ul><li>Sólo una vez cumplido lo anterior se acepta la solicitud. </li></ul><ul><li>Si no se cumple, debe registrarse como una solicitud rechazada. </li></ul>
  64. 64. Control de cambios a los requerimientos <ul><li>El impacto del cambio debe ser estimado por los recursos involucrados en las actividades relacionadas con dicho cambio para después negociarlo con el cliente. </li></ul><ul><ul><li>Dicho impacto puede significar tiempos o costos adicionales, por lo que requiere la aprobación correspondiente del gerente y del cliente. </li></ul></ul><ul><li>Independientemente de que la solicitud sea aceptada o rechazada debe registrarse en el control de cambios del proyecto con un identificador único y algunos datos básicos de acuerdo al formato establecido para ello, o de acuerdo a la herramienta de control de cambios que se utilice. </li></ul>
  65. 65. Validar avances con usuarios <ul><li>El líder del proyecto debe asegurarse que el usuario se mantenga informado del progreso del proyecto y de obtener retroalimentación oportuna sobre la funcionalidad completada. </li></ul><ul><li>En el caso de los proyectos que se planeen con iteraciones, al final de cada iteración se debe de llevar a cabo una revisión de avances donde se le muestre la funcionalidad completada hasta la fecha comparándolo contra el alcance planeado originalmente para dicha iteración. </li></ul><ul><li>En el caso de no programar iteraciones se considerará cierta frecuencia para realizar dichas presentaciones. </li></ul>
  66. 66. Validar avances con usuarios <ul><li>El usuario debe firmar una carta de revisión de avances, donde podrá indicar sus observaciones y proporcionar retroalimentación para ser considerada dentro del proyecto. </li></ul><ul><li>Es muy útil tener retroalimentación frecuente del usuario respecto a los avances logrados, y no sólo cuando el proyecto ya va a finalizar. </li></ul><ul><ul><li>El coste de los cambios propuestos a la finalización del proyecto pueden ser muy altos y poner en riesgo el éxito del proyecto. </li></ul></ul>
  67. 67. Administración de la configuración <ul><li>Se debe contar con un directorio con una estructura estándar establecida para los proyectos, dentro de un repositorio de administración de la configuración (p.ej. CVS). </li></ul><ul><ul><li>Si es un proyecto o módulo nuevo se creará un nuevo directorio en el repositorio. </li></ul></ul><ul><ul><li>Si se trata de mantenimiento se utilizará el que ya exista para ese proyecto. </li></ul></ul><ul><li>Se deben de establecer y controlar los permisos necesarios para el acceso y mantenimiento de dicha información para el equipo de trabajo y la gente involucrada en su elaboración. </li></ul><ul><li>Este repositorio puede estar en el servidor central de proyectos y lo debe de crear el administrador de la configuración al comenzar un nuevo proyecto en la fase de concepción, a solicitud del líder de proyecto. </li></ul>
  68. 68. Administración de la configuración <ul><li>El líder del proyecto debe asegurarse de que los miembros del equipo mantengan actualizados sus respectivos productos/documentos del proyecto en el repositorio de administración de la configuración del proyecto, dentro del subdirectorio que les corresponda y utilizando los estándares para la identificación de los archivos y sus distintas versiones. </li></ul><ul><li>Todos los documentos y archivos del proyecto se manejarán de forma centralizada en dicha librería, incluyendo el código y librerías ejecutables. </li></ul>
  69. 69. Diez Maneras para desmotivar a tu equipo
  70. 70. Diez Maneras para desmotivar a tu equipo <ul><li>10 poner objetivos inalcanzables para ver donde está el límite de las personas que integran el equipo. </li></ul>
  71. 71. Diez Maneras para desmotivar a tu equipo <ul><li>9 Nunca expliques el razonamiento que te lleva a tomar una decisión </li></ul><ul><li> “ por que lo digo yo…” </li></ul>
  72. 72. Diez Maneras para desmotivar a tu equipo <ul><li>8 Asignar tareas sin sentido </li></ul>
  73. 73. Diez Maneras para desmotivar a tu equipo <ul><li>7 No importa lo bueno o malo que sea un trabajo, ¡criticalo! </li></ul>
  74. 74. Diez Maneras para desmotivar a tu equipo <ul><li>6 Llévate todos los créditos </li></ul>
  75. 75. Diez Maneras para desmotivar a tu equipo <ul><li>5 soluciona tus problemas creando nuevos procedimientos burocráticos. </li></ul>
  76. 76. Diez Maneras para desmotivar a tu equipo <ul><li>4 Escucha como si fueras una pared </li></ul><ul><li>“ pero haz como que estas interesado…” </li></ul>
  77. 77. Diez Maneras para desmotivar a tu equipo <ul><li>3 Descarta ideas para hacer el trabajo más efectivo </li></ul>
  78. 78. Diez Maneras para desmotivar a tu equipo <ul><li>2 Trata a tu equipo como si fueran máquinas que nunca se romperán </li></ul>
  79. 79. Diez Maneras para desmotivar a tu equipo <ul><li>1 Nunca , bajo ninguna circunstancia, des a nadie reconocimiento por su trabajo </li></ul>
  80. 80. Muchas Gracias Hermenegildo Romero Database Team [email_address] www.db-team.com

×