gestiÓn de proyectos de ti

GESTIÓN DE PROYECTOS GESTIÓN DE PROYECTOS DE TIDE TI

Introducción

TEMAS

• I. Proyectos– Definición

– Gestión de proyectos

• II. Desarrollo de Software– Problemática. 36 errores típicos

– 6 Mejores prácticas

TEMA N° 1TEMA N° 1

PROYECTOS

¿QUÉ ES UN PROYECTO?

• Las organizaciones ejecutan trabajos, ya sea en la forma de proyectos o de operaciones. Ambos tienen en común:– Ejecutados por personas

– Recursos restringidos

– Se planifican, ejecutan y controlan

• Se diferencian en:– Las operaciones son continuas y repetitivas

– Los proyectos son únicos y temporales.

– Temporal quiere decir que todo proyecto tiene un inicio y un final definidos.

– Único quiere decir que el producto o servicio es diferente a otros productos o servicios similares.


Un proyecto es un esfuerzo temporal llevado a cabo para crear un producto o servicio único.

Guía del PMBOX®©2004 Project Management Institute


– Los proyectos pueden ser ejecutados por 1 persona o por 10,000 personas.

– Los proyectos pueden tomar 100 horas o 10’000,000 de horas.

– Los proyectos pueden involucrar a distintas áreas de una organización.

• Ejemplos de proyectos:– Desarrollo de un nuevo producto o servicio– Llevar a cabo un cambio dentro de la organización– Diseñar un nuevo vehículo de transporte– Construir un edificio de viviendas.– Organizar un congreso de estudiantes– Desarrollar un software para el manejo de una

agencia bancaria– Realizar un cambio organizacional


NATURALEZA TEMPORAL DE UN PROYECTO

• Todo proyecto tiene un inicio y un fin.

• Se llega al fin cuando se cumplen los objetivos del proyecto o cuando se determina que no se pueden cumplir.

• Temporal no quiere decir en un corto tiempo, quiere decir que tiene una duración finita.

• Lo temporal no aplica al servicio o producto generado por el proyecto. Ejemplo: un monumento nacional que será visitado por muchos años.

• Los proyectos tienen que ver con hacer algo que no se ha hecho antes, y por lo tanto es algo único.– Por ejemplo, la construcción de un edificio de oficinas

puede parecer repetitivo, pero para cada desarrollo podemos tener un nuevo cliente, otro lugar, leyes distintas, distinto contratista, etc..

• El hecho de ser único, requiere que las características finales se van elaborando y refinando poco a poco, mediante una buena definición de los alcances

PRODUCTO O SERVICIO ÚNICO (I)PRODUCTO O SERVICIO ÚNICO (I)

SUB-PROYECTO

• Los proyectos se pueden dividir en componentes más manejables, también llamados sub-proyectos.

• Los sub-proyectos muchas veces se sub-contratan a empresas externas o a otras unidades funcionales en la organización ejecutante.

Recursos

Tie

mpo

s Costos

Resultados / Tecnología

Fuente: Harold Kezner

Recursos del Proyecto

Personas

Información y Tecnología

Equipos

Materiales

Fondos

Edific

ios y

Terre

nos

Recursos del Proyecto

• Necesidad del Liderazgo

– Dinámica cambiante del entorno

– Presiones de tiempo

– Complejidad de los problemas

– Interacciones personales internas y externas

– Multiplicidad de factores intervinientes

Liderazgo del Proyecto

• Perfil del Gerente de Proyecto– Visión integradora– Capacidad conducción– Planificador– Organizador– Capacidad determinar necesidades– Negociador amplio– Manejo de conflictos– Capacidad técnica– Motivador

Liderazgo del Proyecto

La gestión de proyecto es la aplicación de conocimientos, habilidades herramientas y técnicas en el sentido de concluir actividades que atiendan o excedan a las necesidades y expectativas de los stakeholders de este proyecto.

¿Qué es la Gestión del Proyecto ?

Los procesos de dirección de proyectos se pueden organizar en cinco grupos.

• Procesos de Iniciación. Autorización del proyecto o de una fase del mismo

• Procesos de Planificación. Definición y refinamiento de objetivos, selección de la mejor alternativa entre posibles cursos de acción para lograr los objetivos del proyecto

Proceso de Gestión del Proyecto

• Procesos de Control. • Supervisar y medir el avance • Identificar variaciones con respecto al plan • Tomar las acciones correctivas cuando sea necesario.

• Procesos de Cierrre. Formalización de la aceptación del proyecto o de una fase y organización de un fin ordenado.

Proceso de Gestión del Proyecto

Contexto de la Gestión del Proyecto

Estructura enfocada a proyectos

Ciclo de vida de un proyecto

• Los niveles de coste y RRHH son bajos al comienzo, creciendo hasta el final del proyecto y cayendo rápidamente en la conclusión del mismo. • La probabilidad de terminar con éxito el proyecto es pequeña, con riesgos eincertidumbres, al comienzo.• La capacidad de los gestores para variar las características del proyecto es mayor al principio, viéndose disminuida según va avanzando el proyecto.• El coste de los cambios y la corrección de posibles errores es mayor según va progresando el proyecto.

• Cuando finaliza– en el tiempo previsto– cumpliendo el presupuesto– con los resultados y especificaciones esperadas– con la aceptación del cliente– nos permite usar al cliente como referencia– sin perturbar el flujo de trabajo de la organización– sin conflictos con la cultura de la organización

Proyecto exitoso

¿QUÉ ES GESTIÓN DE PROYECTOS?

Es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un

proyecto para satisfacer los requisitos del proyecto.

Guía del PMBOX®©2004 Project Management Institute

• Relaciones humanas en la Organización del Proyecto

• Balance entre las funciones técnicas y de administración

• Enfrentar los riesgos asociados al proyecto

• Superar las limitaciones de la Organización

Interfase de Gestión

IniciaciónPlaneamiento

Control Ejecución

Cierre

Procesos en la Gestión de Proyectos


• La gestión de un proyecto incluye:– Identificar los requisitos

– Establecer unos objetivos claros y posibles de realizar

– Equilibrar las demandas concurrentes de calidad, alcance, tiempo y costos.

– Adaptar las especificaciones, los planes y el enfoque a las diversas inquietudes y expectativas de los diferentes interesados.


• El conocimiento sobre gestión de Proyectos puede organizarse en muchas maneras.

• El documento PMBOK está organizado en tres grandes secciones:

– El Marco Conceptual de la Dirección de Proyectos

– Norma para la Dirección de Proyectos de un proyecto.

– Las Áreas de conocimiento de la Dirección de Proyectos

• Fundado en 1969 por cinco miembros en Pennsylvania, con el propósito de difundir las prácticas de Project Management

• Durante 1980 se llevó a cabo el primer exámen para la certificación PMP (Project Management Profesional) que actualmente posee reconocimiento ISO.

• En 1990 publicó los primeros estándares en PM: “The Guide to tje Project Management Body of Knowledge”. PMPBOK®

• Hoy circulan en el mundo más de 250000 copias• Posee más de 100000 asociados en 125 paises• Han certificado como PMP´s más de 10000 miembros

Project Management Institute

AREAS DE CONOCIMIENTO DE LA GESTIÓN DE PROYECTOS

RecursosHumanos

Comunicación AdquisicionesRiesgos

Gestiónde

Proyectos

AlcanceVisión

Integral

CalidadCostosTiempos

Modelo según Project Management Institute

9.-Adquisiciones

8.- Riesgos

7.- Comuni-

cación

6.- Recursos

Humanos

5.- Calidad

4.- Costos

3.- Tiempos

2.- Alcance

1.- Integración

CierreControlEjecuciónPlaneamientoIniciación

ProcesosAreas de

Conocimiento

Modelo según Project Management Institute

SECCIÓN I: Marco Conceptual de la Gestión de Proyectos

• Proporciona una estructura básica para entender la dirección de proyectos.

– El Capítulo 1, Introducción, define los términos clave y proporciona una descripción general del resto de la Guía del PMBOK®.

– El Capítulo 2, Ciclo de Vida del Proyecto y Organización describe el entorno en el cual operan los proyectos. El equipo de dirección del proyecto debe comprender este amplio contexto.

Sección II: Norma para la Gestión de Proyectos

• Especifica todos los procesos de dirección de proyectos que usa el equipo del proyecto para gestionar un proyecto.

– El Capítulo 3, describe los cinco Grupos de Procesos de Dirección de Proyectos aplicables a cualquier proyecto y los procesos de dirección de proyectos que componen tales grupos.

– Este capítulo describe la naturaleza multidimensional de la dirección de proyectos.

Sección III: Áreas de Conocimiento de la Gestión de Proyectos

• Organiza los 44 procesos de dirección de proyectos de los Grupos de Procesos de Dirección de Proyectos del Capítulo 3 en nueve Áreas de Conocimiento.

• La introducción de la Sección III describe la leyenda de los diagramas de flujo de procesos que se usan en cada capítulo de Área de Conocimiento y en la introducción de todas las Áreas de conocimiento.


• El Capítulo 4, Gestión de la Integración del Proyecto, describe los procesos y actividades que forman parte de los diversos elementos de la dirección de proyectos.

• El Capítulo 5, Gestión del Alcance del Proyecto, describe los procesos necesarios para asegurarse de que el proyecto incluya todo el trabajo requerido, y sólo el trabajo requerido, para completar el proyecto satisfactoriamente.

• El Capítulo 6, Gestión del Tiempo del Proyecto, describe los procesos relativos a la puntualidad en la conclusión del proyecto.

• El Capítulo 7, Gestión de los Costes del Proyecto, describe los procesos involucrados en la planificación, estimación, presupuesto y control de costes de forma que el proyecto se complete dentro del presupuesto aprobado.


• El Capítulo 8, Gestión de la Calidad del Proyecto, describe los procesos necesarios para asegurarse de que el proyecto cumpla con los objetivos por los cuales ha sido emprendido.

• El Capítulo 9, Gestión de los Recursos Humanos del Proyecto, describe los procesos que organizan y dirigen el equipo del proyecto.

• El Capítulo 10, Gestión de las Comunicaciones del Proyecto, describe los procesos relacionados con la generación, recogida, distribución, almacenamiento y destino final de la información del proyecto en tiempo y forma.

• El Capítulo 11, Gestión de los Riesgos del Proyecto, describe los procesos relacionados con el desarrollo de la gestión de riesgos de un proyecto.


• El Capítulo 12, Gestión de las Adquisiciones del Proyecto, describe los procesos para comprar o adquirir productos, servicios o resultados, así como para contratar procesos de dirección.


DESARROLLO DE SOFTWARE:

Los 36 errores clásicos del desarrollo del software

31% de los proyectos son cancelados antes de completarse.

53% de los proyectos cuestan 190% del costo estimado.

En las grandes empresas el costo se desvía aprox. un 9%.

En las PYMES el costo se desvía aprox. un 16%.

ESTADÍSTICAS SOBRE DESARROLLO DE SW

INTERROGANTES EN EL DESARROLLO DE SW

¿Por qué se consume tanto tiempo en culminar los sistemas informáticos?

¿Por qué es tan elevado el costo de los proyectos de sistemas?

¿Por qué no se identifican todos los errores del

software antes de entregarlo al cliente?

¿Por qué es tan difícil medir el avance del desarrollo del

software?

¿Los usuarios finales están totalmente satisfechos con los sistemas informáticos que utilizan?

36 ERRORES CLÁSICOS

• Tipos:– De la Gente

– Del Proceso

– Del Producto

– De la tecnología

GENTE

• Baja motivación

• Personal débil– Débil vs. Junior

• Empleados problemáticos no controlados

• Héroes

• Agregar gente a un proyecto atrasado

GENTE

• Ruido, hacinamiento

• Roces con el cliente

• Expectativas no realistas

• Politización

• Soñadores

GENTE

• Falta de auspiciadores efectivos

• Falta de Stakeholders interesados

• No tener el punto de vista del usuario

• Schedule optimista

• Manejo insuficiente del riesgo

• Falla de proveedores

• Planeamiento Insuficiente

• Planes que ceden a la presión

PROCESO

• Tiempo desperdiciado al inicio

• Actividades fundamentales acortadas

• Diseño inadecuado

• Aseguramiento de la calidad recortado

PROCESO

• Control insuficiente

• Convergencia frecuente o prematura

• Omisión de tareas al estimar

• Planear recuperarse “después”

• Programación “Code-like-hell” (Ir directo a codificar)

PROCESO

• Exceso en los requerimientos

• Plantear demasiados objetivos a la vez

• Desarrolladores “dorados” (fascinación por los avances tecnológicos)

• Mala Negociación

• Desarrollo investigativo

PRODUCTO

• Síndrome de la Panacea

• Sobre-estimación de ahorros por nuevas herramientas

– Capricho

– Snobismo

• Cambio de herramientas a mitad del proyecto

• Falta de control de fuentes

TECNOLOGIA


DESARROLLO DE SOFTWARE:

Las 6 mejores prácticas

CONTROLAR CAMBIOS

ADMINISTRAR REQUERIMIENTOS

ArquitecturasBasadas en

Componentes

DesarrollarIterativamente

Verificar Calidad

ModelizarVisualmente

LAS 6 MEJORES PRÁCTICAS

PlaneamientoPlaneamientoInicialInicial

PlaneamientoPlaneamiento

RequerimientosRequerimientosAnálisis y DiseñoAnálisis y Diseño

ImplementaciónImplementación

PruebaPrueba

DistribuciónDistribución

EvaluaciónEvaluación

Ambiente deAmbiente deAdministraciónAdministración

1. DESARROLLAR SOFTWARE ITERATIVAMENTE

• Cada iteración resulta en un release ejecutable

CONTROLAR CAMBIOS



Componentes


Verificar Calidad



• Los desentendimientos importantes se evidencian tempranamente

• Se alienta el feedback del usuario

• Focalización en los temas más críticos, sin distracciones

• Testing continuo e iterativo: evaluación objetiva

• Inconsistencias entre requerimientos, diseños e implementaciones se detectan tempranamente


• Carga de trabajo mejor repartida en el tiempo

• El equipo puede analizar las lecciones aprendidas en las primeras iteraciones

• Integración progresiva en lugar de Big Bang

• Evidencias concretas a los sponsors

• Se facilita la reutilización

• Arquitectura más robusta

2. ADMINISTRAR LOS REQUERIMIENTOS

• Requirements Management, enfoque sistemático que involucra:– Obtener, organizar y documentar la funcionalidad y

restricciones requeridas a un sistema

– Analizar los cambios solicitados y evaluar impactos

– Registrar y documentar las alternativas y decisiones tomadas

CONTROLAR CAMBIOS



Componentes


Verificar Calidad


Modelo de DiseñoModelo de Implementación Modelo de Test

verificaRealización influenciados por

Los Casos de Uso

direccionan el trabajo desde

el análisis hasta el test

Modelo de Casos de Uso


• Los requerimientos pueden ser adecuadamente capturados y comunicados a través de Casos de Uso

• Los Casos de Uso son importantes instrumentos de planificación


• Las comunicaciones están basadas en requerimientos bien definidos

• Los requerimientos pueden ser priorizados, filtrados y monitoreados

• Es posible realizar evaluaciones objetivas acerca del éxito de un proyecto

• Las inconsistencias se detectan fácilmente

• Con herramientas adecuadas: repositorio de requerimientos, con atributos y relaciones

¿Cómo son interpretados los requerimientos?

Necesito algo para balancearme bajo un árbol

¿Cómo lo explicó el cliente?


¿Cómo lo entendió el líder del proyecto?

¿Cómo fue descrito por el consultor?

¿Cómo fue analizado y diseñado?


¿Cómo fue programado?

¿Cómo fue documentado?

¿Cómo fue instalado?

División de Alta Tecnología


¿Cómo fue cobrado?

¿Qué soporte se brindó?

¿Qué necesitaba realmente el cliente?

3. UTILIZAR ARQUITECTURAS BASADAS EN COMPONENTES

• La Arquitectura de Software representa el conjunto de decisiones significativas sobre la organización de un sistema de software– Selección de los elementos estructurales, y sus

interfaces, por los cuales el sistema está compuesto

– Comportamiento, especificado como colaboraciones entre los elementos

– Composición en subsistemas de los elementos estructurales y de comportamiento

– Estilo de arquitectura que guía a la organización

CONTROLAR CAMBIOS



Componentes


Verificar Calidad


System-System-softwaresoftware

MiddlewareMiddleware

NegocioNegocio

AplicaciónAplicación

Arquitectura basada en componentes


• Un componente de software puede definirse como una pieza no trivial de software, un módulo o un subsistema que completa una función clara, tiene límites claros y puede ser integrado en una arquitectura bien definida


• Definir arquitecturas muy modulares e identificar, aislar, diseñar, desarrollar y probar componentes bien formados

• Desarrollar componentes para ser reutilizados. Formar la base de reuso de la organización

• Industria de infraestructura de componentes– COM+ - Microsoft Component Object Model

– CORBA - Common Object Request Broker Architecture - OMG

– JavaBeans - SUN

– Assemblys .NET

– Servicios Web

Código

Clases

Subsistemas

La Modelización Visual eleva el nivel de abstracción

4. MODELAR SOFTWARE VISUALMENTE

CONTROLAR CAMBIOS



Componentes


Verificar Calidad


BENEFICIOS

• Los casos de uso permiten especificar comportamiento sin ambigüedades

• Quedan expuestas las arquitecturas inflexibles o no modulares

• El diseño refleja sus inconsistencias más rápidamente

• Existen herramientas que proveen soporte para la modelización visual

Uc Pagar Servicio

Cajero

Registrar Pago

5. VERIFICAR LA CALIDAD DEL SOFTWARE

• La actividad fundamental de esta práctica es el testing

• Evaluar continuamente la calidad de un sistema con respecto a funcionalidad, confiabilidad, performance

Desarrollo Implementación

CostoEncontrar y reparar un

problema de software

después de la implementación

puede resultar de 100 a 1000

veces más costoso

CONTROLAR CAMBIOS



Componentes


Verificar Calidad


BENEFICIOS

• La evaluación del estado del proyecto es objetiva, se evalúan resultados de test.

• Se exponen inconsistencias en requerimientos, diseños e implementaciones

• Se focaliza en las áreas de riesgo más alto

• Los defectos se identifican en forma temprana

• Existen herramientas automatizadas para el testing de funcionalidad, confiabilidad y performance

El manejo del cambio es más que apenas comprobar dentro y fuera de archivos. Incluye el manejo de espacios de trabajo, del desarrollo

paralelo, de la integración y de construcciones.

6. CONTROLAR LOS CAMBIOS AL SOFTWARE

CONTROLAR CAMBIOS



Componentes


Verificar Calidad


6. CONTROLAR LOS CAMBIOS AL SOFTWARE

• Controlar, registrar y monitorear los cambios para posibilitar el desarrollo iterativo

• Establecer “workspaces” seguros para cada desarrollador

• Automatizar la integración y la administración de construcciones.

BENEFICIOS

• Las solicitudes de cambios formales facilitan la claridad de comunicación

• Los espacios de trabajo aislados reducen la interferencia entre los miembros del equipo que trabajan en paralelo

• Las estadísticas de cantidad de cambios proveen buenas métricas para evaluar objetivamente el estado del proyecto

• La propagación del cambio es evaluable y controlable

• Los cambios pueden ser mantenidos en sistemas automáticos

gestiÓn de proyectos de ti

Documents