Gestión de Proyectos Conceptos Básicos.

Presentación del tema: "Gestión de Proyectos Conceptos Básicos."— Transcripción de la presentación:

1 Gestión de Proyectos Conceptos Básicos

2 Definición de proyecto
Proceso único, consistente en un conjunto de actividades controladas, con fecha de inicio y finalización, llevadas a cabo para lograr un objetivo conforme con requisitos específicos, incluidas las limitaciones de tiempo, costo y recursos. Sistema de Gestión de la Calidad. Fundamentos y vocabulario. ISO Ginebra: Secretaría Central ISO, Suiza). OTERO IGLESIAS, Jacinta, BARRIOS OSUNA, Irene y ARTILES VISBAL, Leticia. Reflexiones en torno a la definición de Proyecto. Rev Cubana Educ Med Super. [online]. abr.-jun. 2004, vol.18, no.2 [citado 14 Septiembre 2006], p.1-1. Disponible en la World Wide Web: < &lng=es&nrm=iso>. ISSN

3 Definición de proyecto
Es el conjunto de acciones o actividades que se realiza a partir de una situación actual para obtener una situación futura o esperada.

4 Rasgos más saltantes Es la unidad operativa más pequeña que se ejecuta en forma independiente o autónoma. Se compone de un conjunto de tareas o actividades enlazadas en orden lógico. Tiene un fin específico. Requiere de inversión financiera. Requiere de participación humana. Tiene como limitación el tiempo.

5 Definición de Gestión Definición 1: Coordinar todos los recursos disponibles para alcanzar determinados objetivos. Definición 2: Proceso mediante el cual se obtiene, despliega o utiliza una variedad de recursos básicos con el fin de apoyar los objetivos de la organización.

6 Gestión de Proyectos de Software
Definición 1: Implica la planificación supervisión y control del personal, el proceso y los eventos que ocurren mientras el software esta en desarrollo. Definición 2: Proceso por el cual se planifica, dirige y controla el desarrollo de un producto software con un costo mínimo y en un tiempo razonable.

7 ¿Porque fracasa un proyecto?
Me olvide de que las tareas las realizan las personas. No mantuve una comunicación fluida con el cliente sobre todo al inicio lo que deviene en un producto que no sirve. No tome atención al proceso y por lo tanto no lo utilice adecuadamente. No conté con un plan de proyecto adecuado.

8 El espectro de la gestión
El personal Organizar adecuadamente al Personal. El producto Determinar correctamente el alcance y los requisitos del Producto.

9 El espectro de la gestión
El proceso Seleccionar el Proceso que se adecue más al personal y al producto. El proyecto Planificar el Proyecto estimando esfuerzo y tiempo para cumplir las tareas. Definir entregables Establecer puntos de control y mecanismos de supervisión. Controlar el trabajo planificado.

10 El personal Es el factor más importante dentro del proceso de ingeniería de software. Debemos preocuparnos por captar, aumentar, motivar desplegar y retener el talento con el fin de hacer a la organización más capaz.

11 El personal Es tan importante que el SEI define un modelo de madurez de la capacidad de gestión de personal. Áreas clave: Reclutamiento Retribución Selección Desarrollo de carrera Gestión de rendimiento Diseño del trabajo Entrenamiento Desarrollo de equipo

12 Aspectos clave de su gestión
Es el elemento más importante en la gestión de proyectos. Se debe mantener un entorno acogedor para que pueda trabajar de la mejor forma. Se debe seleccionar al personal más adecuado. Sin embargo muchas veces el personal es tratado como un recurso de segunda categoría.

13 Los participantes Gestores superiores. Gestores técnicos del proyecto.
Profesionales. Clientes. Usuarios finales.

14 El jefe de equipo Su labor es organizar el equipo de proyecto de manera que se maximicen las habilidades de sus integrantes. Son los que conducen todo o parte de un proyecto de software. El jefe de equipo debe ser un líder.

15 La función del jefe de equipo
Entender el problema. Canalizar el flujo de ideas de los miembros del equipo. Saber hacia donde se va dentro del proyecto. Que en resumidas cuentas es a producir software de calidad.

16 Qué habilidades debe tener
Se utiliza el modelo MOI para determinar las habilidades de un jefe (WEINBERG). Motivación: Habilidad para hacer que el personal produzca un 110% Organización: Habilidad para acomodar los procesos existentes a las necesidades del proyecto. Ideas/Innovación: La habilidad de hacer trabajar a la gente aún en el límite.

17 Habilidades del jefe de equipo
Resolución de problemas. Ser flexible al cambio. Capacidad de diagnóstico Debe estructurar soluciones o motivar la solución. Dotes de gestión. Resolución de problemas Diagnosticar aspectos técnicos y de gestión. Estructurar una solución o motivar la solución por parte de los miembros del equipo. Retroalimentarse de proyectos anteriores. Ser flexible en los cambios en la gestión si las cosas no salen como debieran. Dotes de gestión. Incentivo por logros. Premiar por iniciativa y logros. NO penalizar si se corren riesgos controlados. Influencia y construcción de espíritu de equipo. Debe mantener el control en situaciones críticas. Debe entender las necesidades de su gente.

18 Habilidades del jefe de equipo
Incentivo por logros. Premiar la iniciativa NO penalizar el “riesgo controlado”. Construcción de espíritu de equipo. Mantener el control y entender las necesidades de su gente.

19 Organizar el equipo Hay varias formas y depende de:
La cantidad de personas. La forma de gestión de la empresa. Los niveles de preparación del personal. La dificultad del problema. Consideremos n personas trabajando en un proyecto que durará k años. N personas. M tareas funcionales a realizar.

20 Organización informal
Si N individuos se asignan a M tareas donde N <= M. Poca coordinación. Coordinar es trabajo del jefe. Si N personas son asignadas a M funciones (N>M). Se establecen equipos informales. Coordinar todavía es trabajo del jefe.

21 Organización de equipo formal
N personas se organizan en T equipos y cada equipo tiene una o más tareas funcionales que realizar. Los equipos tienen una estructura uniforme. La coordinación la hace el equipo y el jefe. Es considerada la mejor organización de equipo.

22 Estructura de MANTEI Se definen 7 factores a considerar a la hora de estructurar el equipo. La dificultad del problema. El tamaño del software LDC ó PF. La vida del equipo. La modularidad del problema. La rigidez de la fecha de entrega. La calidad y fiabilidad del sistema. El nivel de sociabilidad requerido.

23 Descentralizado Democrático DD
Comunicación horizontal, no hay jefe permanente, las decisiones son por consenso. Se nombran coordinadores a corto plazo.

24 Descentralizado Controlado DC
Existe un jefe. La resolución de problemas es en grupo. La asignación de tareas la hace el jefe. La comunicación es horizontal y vertical.

25 Centralizado Controlado CC
El jefe de equipo se encarga de resolver los problemas y coordinar a alto nivel. La comunicación vertical.

26 Qué estructura elegir La estructura CC La estructura DC
Más rápida y adecuada para manejar problemas sencillos. Para proyectos grandes debido a que el rendimiento de equipo inversamente proporcional a la cantidad de comunicación que se debe realizar. Se adecua bien a modularidad alta (cada quien hace lo suyo). Tienden a producir menos defectos que los descentralizados. La estructura DC Se pueden aplicar a la solución de problemas sencillos. También adecuado para proyectos grandes. Se adecuan bien a modularidad alta. La estructura DD Tiene más éxito en problemas complejos. Mejor para problemas difíciles. Son mejores para proyectos largos. Se adecuan a modularidad baja. La cantidad de defectos dependerá de las actividades de garantía de calidad.

27 Paradigma Cerrado Similar a CC
Jerarquía tradicional. Trabajan bien para producir software similar a otros.

28 Paradigma aleatorio. Dependen de la iniciativa de cada miembro. Son efectivos cuando se requiere avance tecnológico. Son malos para rendimiento ordenado.

29 Paradigma Abierto Similar al descentralizado controlado.

30 Paradigma Sincronizado
Organiza al equipo para trabajar en partes del problema con poca comunicación entre ellos.

31 Trabajo de clase Cuales son las características de un equipo cuajado.
A que se le denomina toxicidad de equipo. Que factores la producen y como se evita. Cuáles son las características del software moderno por las que un proyecto se vuelve problemático. ¿Cómo se evitan? Como categorizan las técnicas de coordinación según Kraul y Streeter. A que se refiere JACKMAN cuando dice que un equipo se enfrenta a diferentes rasgos humanos. Equipos de alto rendimiento. Debemos convertir el caos en un equipo de alto rendimiento. Los miembros deben confiar unos en otros. Distribuir las habilidades de acuerdo al problema Mantener la unión del equipo. El equipo ideal No todo grupo de gente trabajando junta es un equipo Deben tener espíritu de equipo. Debe ser un equipo cuajado. El todo es mayor que las partes. Comparten una meta común, cultura común y poseen un “sentimiento elitista”. Toxicidad de Equipo Factores que llevan a la toxicidad de equipo Atmósfera de trabajo frenética. Los miembros se salen de los objetivos a desarrollar (1). Alta frustración. Mala definición del modelo de procesos que se convierte en obstáculo (2). Definición confusa de los roles (3). Continua exposición al fallo (4). Como evitar la Toxicidad Para (1), se debe entregar toda la información posible al equipo y definir las metas y objetivos del trabajo. Malas noticias no se deben ocultar. Para (2), darle control al equipo para tomar decisiones técnicas y de proceso. Permitirle al equipo seleccionar el proceso con su compromiso de calidad. Para (3), el gestor debe definir claramente roles y responsabilidades al inicio del proyecto. Para (4), El equipo se debe retroalimentar de los fallos, un fallo de uno se debe tomar como fallo del equipo, para evitar el culparse y desconfiar y mejorar el acercamiento del equipo a la solución. Un factor importante es entender que los seres humanos somos distintos. Como Coordinar Los motivos por los que un proyecto puede tener problemas son: La escala. La incertidumbre La interoperatividad. Se deben establecer métodos formales o informales para coordinar al equipo o los equipos de trabajo. Mecanismos formales: Comunicación escrita, reuniones organizadas y medias no interactivos o impersonales. Mecanismos informales: Medios interactivos y personales. Técnicas de Coordinación Formal, impersonal. Informes, memos, peticiones de cambio, código fuente. Formal, interpersonal: Reuniones de revisión de estado, inspecciones de diseño y de código. Garantía de calidad. Informal, interpersonal: Reuniones de grupo para resolver problemas o divulgar información. Red interpersonal: Discusiones entre miembros del equipo u otros que pueden ayudar por su experiencia y visión.

32 El problema Al inicio de un proyecto nos enfrentamos al siguiente dilema Se requiere un plan organizado y estimaciones cuantitativas pero no tenemos información sólida. El analisis de requisito nos daria las medidas necesarias pero puede llevar semanas o meses Aun peor los requisitos pueden ser fluidos y cambiantes Debemos por lo menos establecer el ámbito del producto y delimitarlo.

33 El problema

34 Definir el ámbito del software
El contexto Como encaja el producto dentro del sistema o negocio que lo contiene. Objetivos de información Qué objetos de datos de datos visibles al cliente se obtienen y que se necesita como entrada Función de rendimiento Qué funciones realiza el software para transformar la entrada en salida y características de rendimiento necesarias.

35 Datos a considerar en el ámbito
Los Datos cuantitativos se anotan explícitamente. Número de usuarios concurrentes. Volumen de información. Tempo máximo de respuesta. Se detallan las limitaciones Costo vs. tamaño de memoria. No se usarán dispositivos de captura de datos especiales. Se describen factores de reducción de riesgos Los algoritmos son más claros en Java. Se debe conocer quien realiza los cambios.

36 Descomposición del problema
Se basa en el análisis de requisitos. No intenta descomponer el problema totalmente. La descomposición se centra en: La funcionalidad a entregar. El proceso que se empleara para entregar la funcionalidad. Las funciones definidas en el ámbito se evalúan y refinan para proporcionar más detalle antes de estimar. Se utiliza la técnica de divide y vencerás.

37 El proceso Proporciona la estructura para establecer un plan detallado de desarrollo. Se elige el modelo de proceso a utilizar Se toma un conjunto reducido de actividades estructurales y dentro de ellas se definen las tareas, entregables y puntos de control. Son las tareas las que hacen que las actividades estructurales se amolden al proyecto y al equipo. Existen actividades protectoras que se realizan a lo largo del proceso de software.

38 El Proceso El gestor del proyecto debe seleccionar el modelo de proceso adecuado: Para el personal que trabajará y el cliente. Para el producto en sí. Para el entorno de trabajo. El gestor define un plan de proyecto preliminar basado en actividades estructurales. Luego empieza la descomposición asignando las tareas para cubrir las actividades estructurales.

39 Combinar producto y proceso
El trabajo de gestor es estimar: los recursos, la fecha de inicio y la fecha final a las tareas asociadas a cada producto de trabajo y los productos de trabajo que producirá cada tarea

40 El Proyecto Digamos que la única manera de gestionar la complejidad de la labor de desarrollo de software es mediante la planificación y el control. Aun hoy un gran porcentaje de proyectos fallan o se exceden en costo, tiempo.

41 Porque fracasan los proyectos
La gente de software no comprende las necesidades de los clientes. Definición del ámbito muy pobre. Cambios mal hechos. Tecnología elegida cambia.

42 Porque fracasan los proyectos
Necesidades de negocio que cambian. Fechas de entrega poco realistas. Usuarios que se resisten. Perdida de patrocinadores.

43 Porque fracasan los proyectos
Carencia de personal capacitado. Se evitan buenas prácticas de desarrollo.

44 Como evitar el fracaso Empezar con el pie derecho.
Establecer objetivos y expectativas realistas. Darle al equipo autonomía, autoridad y la tecnología necesaria para hacer el trabajo

45 Como evitar el fracaso Mantenerse
El administrador debe motivarlos para conseguir una rotación de personal mínima. Proporcionar incentivos, resaltar calidad y los administradores dejar trabajar, no presionar

46 Como evitar el fracaso Seguimiento del Progreso
Dar seguimiento mientras se realizan los productos y aprobarlos a través de revisiones. Recopilar métricas para evaluar progreso contra índices establecidos

47 Como evitar el fracaso Tomar decisiones inteligentes.
Decisiones sencillas, mantener lo simple. Usar software similar, reutilizar componentes, estandarizar interfaces, identificar y evitar riesgos obvios, asignar más tiempo que el necesario a tareas complejas o riesgosas

48 Como evitar el fracaso Realizar un análisis postmorten del proyecto.
Extraer lecciones aprendidas. Evaluar la planificación real y la estimada. Recoger y analizar métricas del proyecto. Retroalimentarse de los miembros del equipo y de los clientes. Registrar hallazgos en forma escrita.