tratado para la dirección y gestión agil de proyectos, en entornos de alta incertidumbre
DESCRIPTION
Cómo mejorar la situación de nuestros proyectos, antes incluso de iniciarlos, cómo conseguir una dinámica exitosa dentro de los diferentes ciclos en los que nos envuelve la incertidumbre, cómo convertir el caos en orden de manera sistemática, cómo mejorar los resultados una vez declarado el fracaso, cómo cambiar una situación en la que no es posible conseguir los objetivos trazados por otra en la que esos objetivos tracen nuestra dinámica hacia el éxito de nuestro proyecto.TRANSCRIPT
Tratado para la Dirección y Gestión Ágil de Proyectos, en entornos de alta incertidumbre Base de conocimientos para las
certificaciones SMA, SMP y SMT
Cómo aplicar realmente toda la teoría que vamos encontrando por el mundo, cómo
mejorar la situación de nuestros proyectos, antes incluso de iniciarlos, cómo conseguir
una dinámica exitosa dentro de los diferentes ciclos en los que nos envuelve la
incertidumbre, cómo convertir el caos en orden de manera sistemática, cómo mejorar
los resultados una vez declarado el fracaso, cómo cambiar una situación en la que no es
posible conseguir los objetivos trazados por otra en la que esos objetivos tracen nuestra
dinámica hacia el éxito de nuestro proyecto.
Versión 3.2 1-6-2011
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 1 de 141
Versión 3.2
SMPartners®, todos los derechos reservados.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 2 de 141
Versión 3.2
Índice de Contenidos
AGRADECIMIENTOS ................................................................................... 7
LOS AUTORES ............................................................................................... 8
CAPÍTULO 1 INTRODUCCIÓN ............................................................... 9
1.1 El enfoque de SMPartners® .......................................................................................... 10
1.2 Evocando la Dirección de Proyectos ...................................................................... 11
1.3 Introducción a la complejidad y salida de la incertidumbre.................... 12
1.3.1 Complejidad ................................................................................................................... 12
1.3.2 El Enfoque Empírico .................................................................................................... 13
1.3.3 Sistemas Adaptativos Complejos ........................................................................... 15
1.3.4 El Origen de Scrum ..................................................................................................... 16
CAPÍTULO 2 CULTURA ORGANIZACIONAL .................................... 19
2.1 Estructura tradicional de la Organización (causante de la
complejidad) ...................................................................................................................................... 20
2.2 Paradigmas Culturales ................................................................................................... 22
2.2.1 Paradigma cultural de clan ....................................................................................... 23
2.2.2 Paradigma cultural de jerarquía ............................................................................. 23
2.2.3 Paradigma cultural de adhocracia ......................................................................... 23
2.2.4 Paradigma cultural de mercado .............................................................................. 23
2.2.5 Conclusiones .................................................................................................................. 24
2.3 La gestión del cambio y de la transición ............................................................. 25
2.3.1 El cambio como evolución | El cambio como revolución .............................. 25
2.3.2 Cambio Organizacional .............................................................................................. 26
2.3.3 Dimensiones del Cambio ........................................................................................... 27
2.3.4 ¿Preparado para el cambio? .................................................................................... 29
2.3.5 Las siete fases del cambio ........................................................................................ 30
2.3.6 Implementación del Cambio .................................................................................... 33
2.3.7 El Cambio Sistemático ............................................................................................... 36
CAPÍTULO 3 LA PLANIFICACIÓN Y SUS PERSPECTIVAS .......... 37
3.1 Ejecución Incremental por Fases ............................................................................. 38
3.2 Actividades ejecutadas vs Valor entregado ....................................................... 39
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 3 de 141
Versión 3.2
3.3 Una panorámica al flujo de trabajo ........................................................................ 40
3.4 Modelos tradicionales, en ocasiones útiles ........................................................ 41
3.4.1 Descomposición ............................................................................................................ 41
3.4.2 Planificación Gradual .................................................................................................. 42
3.4.3 Plantillas .......................................................................................................................... 43
3.4.4 Método de Diagramación por Precedencia (PDM) ........................................... 43
3.4.5 Determinación de Dependencias ............................................................................ 43
3.4.6 Aplicación de Adelantos y Retrasos ...................................................................... 44
3.4.7 Plantillas de Red del Cronograma .......................................................................... 45
3.4.8 Análisis de la Red del Cronograma........................................................................ 45
3.4.9 Método de la Ruta Crítica .......................................................................................... 45
3.4.10 Método de la Cadena Crítica .................................................................................... 46
3.4.11 Nivelación de Recursos .............................................................................................. 47
3.4.12 Análisis “¿Qué pasa si…?” ......................................................................................... 47
3.4.13 Compresión del Cronograma ................................................................................... 48
3.4.14 Estimación Análoga ..................................................................................................... 48
3.4.15 Estimación Paramétrica ............................................................................................. 49
3.4.16 Estimación Ascendente .............................................................................................. 49
3.4.17 Estimación por Tres Valores .................................................................................... 50
3.4.18 Análisis de Reserva ..................................................................................................... 50
3.4.19 Análisis de Propuestas para Licitaciones ............................................................. 50
3.4.20 Análisis Costo-Beneficio............................................................................................. 51
3.4.21 Costo de la Calidad (COQ) ........................................................................................ 51
3.4.22 Diagramas de Control ................................................................................................ 51
3.4.23 Estudios Comparativos .............................................................................................. 52
3.4.24 Diseño de Experimentos ............................................................................................ 52
3.4.25 Muestreo Estadístico ................................................................................................... 52
3.4.26 Diagramas de Flujo ..................................................................................................... 53
3.4.27 Metodologías Propietarias de Gestión de la Calidad ....................................... 53
3.4.28 Herramientas Adicionales de Planificación de Calidad ................................... 53
3.4.29 Diagramas de Causa y Efecto ................................................................................. 54
3.4.30 Diagramas de Control ................................................................................................ 54
3.4.31 Histograma ..................................................................................................................... 55
3.4.32 Diagrama de Pareto .................................................................................................... 55
3.4.33 Diagrama de Comportamiento ................................................................................ 55
3.4.34 Diagrama de Dispersión ............................................................................................ 56
3.4.35 Evaluación de Probabilidad e Impacto de los Riesgos ................................... 56
3.4.36 Matriz de Probabilidad e Impacto .......................................................................... 56
3.4.37 Evaluación de la Calidad de los Datos sobre Riesgos .................................... 58
3.4.38 Categorización de Riesgos ........................................................................................ 58
3.4.39 Evaluación de la Urgencia de los Riesgos ........................................................... 58
3.4.40 Técnicas de Recopilación de Información ........................................................... 59
3.4.41 Análisis de las Listas de Control ............................................................................. 60
3.4.42 Análisis de Supuestos ................................................................................................. 60
3.4.43 Técnicas de Diagramación ........................................................................................ 60
3.4.44 Análisis SWOT (o DAFO, Debilidades, Amenazas, Fortalezas y
Oportunidades) ................................................................................................................................ 60
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 4 de 141
Versión 3.2
CAPÍTULO 4 ORGANIZANDO EL HORIZONTE................................ 62
4.1 Armonizando el trabajo | Implicancias tangibles .......................................... 63
4.1.1 Planificación ágil ........................................................................................................... 65
4.1.2 Planificación vs Plan .................................................................................................... 65
4.1.3 Objetivos de la planificación ágil ............................................................................ 66
4.1.4 Principios Armónicos ................................................................................................... 68
4.1.5 Los Roles (Director del Proyecto, Gestor de Expectativas y Gestor de la
Ejecución) .......................................................................................................................................... 69
4.1.6 Reuniones, ¿cuáles son y por qué tan pocas? .................................................. 71
4.1.7 Artefactos y herramientas | Mecánicas a aplicar ............................................. 72
4.1.8 Pila de la Fase ............................................................................................................... 74
4.2 Formalizando el inicio ..................................................................................................... 75
4.3 Identificando a los interesados ................................................................................ 76
4.4 Recopilando Requisitos.................................................................................................. 78
4.4.1 Reunión de Recopilación de Requisitos | Construcción de la Pila del
Producto Inicial ................................................................................................................................ 78
4.5 Estimando Recursos y Calculando Costes ........................................................... 91
4.5.1 Estimación Relativa ..................................................................................................... 92
4.5.2 Técnicas de Estimación .............................................................................................. 93
4.5.3 Otros costes ................................................................................................................... 96
4.6 Cerrando el horizonte 1 | Alcance inicial ............................................................ 97
4.6.1 Priorización ..................................................................................................................... 97
4.6.2 Establecer la longitud de las Fases ..................................................................... 101
4.6.3 Estimar la velocidad .................................................................................................. 102
4.6.4 Planificar las entregas .............................................................................................. 102
4.7 Planificación de la Calidad | Orientación ISO10006 ................................... 103
4.7.1 Condiciones de Satisfacción ................................................................................... 103
4.8 Planificando con personas ......................................................................................... 105
4.8.1 Mentor ............................................................................................................................ 105
4.8.2 Facilitador ..................................................................................................................... 105
4.8.3 Solucionador de Problemas .................................................................................... 106
4.9 Comunicando | El proceso.......................................................................................... 107
4.10 Abrazando la incertidumbre | Gestionando los riesgos ........................... 108
4.10.1 Riesgos asociados al alcance ................................................................................. 108
CAPÍTULO 5 EJECUTANDO LA PLANIFICACIÓN ......................... 109
5.1 Dirección y gestión de la ejecución | Proyectos con alta
incertidumbre .................................................................................................................................. 110
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 5 de 141
Versión 3.2
5.2 Gestión de las expectativas del cliente .............................................................. 111
5.3 Control integrado de cambios .................................................................................. 112
5.4 Planificación de la fase N ............................................................................................ 113
5.4.1 Recopilar requisitos y determinar el horizonte de la fase N | Reunión de
planificación de la fase ................................................................................................................ 113
5.4.2 Planificación de las comunicaciones en la Fase N.......................................... 116
5.4.3 Planificación de la Gestión de Riesgos en la Fase N ..................................... 117
5.5 Gestión de la Calidad en la Fase N ........................................................................ 118
5.5.1 Calidad del Producto ................................................................................................. 118
5.5.2 Calidad de los Procesos ........................................................................................... 118
5.6 Gestión de las Personas en la Fase N .................................................................. 119
5.7 Control y Seguimiento .................................................................................................. 120
5.7.1 Monitorizar y controlar los riesgos ...................................................................... 120
5.7.2 Monitorizar y controlar el trabajo ........................................................................ 122
5.7.3 Controlar el cronograma | Seguimiento del desempeño ............................ 124
5.7.4 Controlar los costes................................................................................................... 125
5.7.5 Asegurando la calidad .............................................................................................. 125
5.7.6 Comunicaciones .......................................................................................................... 125
5.8 Cierre de la Fase N .......................................................................................................... 126
5.8.1 Control y cierre de la calidad ................................................................................. 126
5.8.2 Informes de Desempeño ......................................................................................... 127
5.8.3 Mejora continua | aprendiendo ............................................................................. 127
CAPÍTULO 6 CIERRE DEL PROYECTO ............................................. 131
6.1 Cierre Administrativo del proyecto y sus fases ............................................. 132
CAPÍTULO 7 COMPLEMENTANDO EL CONOCIMIENTO............. 133
7.1 Contratos Ágiles ............................................................................................................... 134
7.1.1 Evaluación de los contratos ................................................................................... 134
7.1.2 Información que debe incluirse en el contrato ............................................... 135
7.1.3 Algunos enfoques contractuales ........................................................................... 135
7.2 Claves de la comunicación ......................................................................................... 138
7.2.1 El Canal y su Ancho de Banda .............................................................................. 138
7.2.2 Comprender ................................................................................................................. 139
7.2.3 Ser Comprendidos ..................................................................................................... 140
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 6 de 141
Versión 3.2
Índice de Figuras
Figura 1.1: Complejidad........................................................................................ 12
Figura 2.1 Características de Estructuras de las Organizaciones ......... 20
Figura 2.2: Paradigmas Culturales ................................................................... 22
Figura 2.3: Pirámide de Maslow ......................................................................... 25
Figura 2.4: Dimensiones del Cambio ............................................................... 29
Figura 2.5: Matriz liderazgo / dirección .......................................................... 33
Figura 3.1: Matriz de Probabilidad e Impacto .............................................. 57
Figura 4.1: Triángulo de Hierro .......................................................................... 63
Figura 4.2: Enfoque tradicional vs Enfoque Ágil ......................................... 64
Figura 4.3: Principios Armónicos ....................................................................... 68
Figura 4.4: Equipo de Proyecto .......................................................................... 71
Figura 4.5: Ejemplo de Ficha de Historia de Usuario ................................ 83
Figura 4.6: Comenzando a crear el Mapa de Historias de Usuario ...... 87
Figura 4.7: Mapa de Historias de Usuario ...................................................... 88
Figura 4.8: Walking Skeleton .............................................................................. 89
Figura 4.9: Determinación de las diferentes releases ............................... 89
Figura 4.10: Relación Esfuerzo - Precisión a la hora de estimar .......... 91
Figura 4.11: Valor - Riesgo .................................................................................. 98
Figura 4.12: Reducción de la incertidumbre - Enfoque Tradicional
(adaptación de Cohn 2006) ................................................................................. 99
Figura 4.13: Reducción de la incertidumbre - Enfoque Ágil
(adaptación de Cohn 2006) ............................................................................... 100
Figura 5.1: Diseño básico de un Panel de Tareas ..................................... 123
Figura 5.2: Diagrama de quemado o burndown ....................................... 124
Figura 7.1: Esquema de Comunicación ......................................................... 138
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 7 de 141
Versión 3.2
AGRADECIMIENTOS
Queremos daros las gracias a todos los que habéis colaborado con nosotros
en esta iniciativa. Una iniciativa que busca, humildemente, aportar un valor diferencial al mundo del Management Global. Todos nuestros esfuerzos se han dirigido hacia un objetivo central: hacer de este tratado, de nuestro
tratado, de vuestro tratado, una guía de “buen hacer”, tan gentil como efectiva para gestionar ágilmente frente a contextos llenos de incertidumbre
y poca claridad. De esta manera buscamos apoyar a la consecución de los más complejos objetivos, en la mayor diversidad de “tipos” de proyecto.
Los autores.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 8 de 141
Versión 3.2
LOS AUTORES
SMPartners®, nace de la conjunción de 4 profesionales del mundo del management y los negocios, 4 reconocidos personajes que tras diferentes
experiencias y haber caminado por diferentes países, sectores, proyectos, temáticas, éxitos y no éxitos; deciden dotar al mundo de un know how
diferente, una serie de técnicas no escritas hasta el día de hoy, con una altísima cuota de aplicabilidad. Es así que nace para el mundo, una nueva dinámica, una nueva vía de gestión, un compendio de buen hacer y una
nueva forma de gobernar proyectos, en cualquier situación, contexto o lugar.
Jesús Candón Rosado Juan Manuel Espinoza
Óscar Ramírez Muñoz Jesús Cobos Romano
www.scrummanagementpartners.org
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 9 de 141
Versión 3.2
Capítulo 1
INTRODUCCIÓN
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 10 de 141
Versión 3.2
1.1 El enfoque de SMPartners®
Queremos con este trabajo, dar a conocer al mundo una nueva vía de
gestión, una vía que nos ayude a trascender por sobre lo tradicional, lo
rígido, lo estático y sobre todo aquello que limita la creatividad de los
verdaderos directores de proyecto, aquellos que gestionan sus días, sus
horas y sus momentos, con criterio, con emoción y muchísimo sentido
común… ¿no es acaso la vida misma, un proyecto complejo?
Nuestro Tratado no es un compendio de teorías caducas, no es un modelo
meramente filosófico, ni es una visión sesgada de una realidad inexistente;
no es simplemente un compendio rígido que “marque el camino” y que
sentencia toda “opción ajena” como una “desviación. Nuestro Tratado es la
vía que nos permitirá al dirigir y gestionar proyectos, generar ventajas
sobre desventajas, cambiar giros y reveses bruscos, por dinámicas suaves
pero constantes, con puntos reales de conciencia, y con bases sostenibles
hacia una mejor gestión del tiempo, del presupuesto y del alcance (aunque
todo esto cambie en el día +1).
El mundo ha cambiado y, hoy por hoy, podemos ser testigos, sin hacer
mucho esfuerzo, de lo caduco de muchos modelos de gestión, de cómo la
balanza se ha inclinado hacia sectores o países donde ayer reinaba la
incertidumbre y una inmensa necesidad de adaptación, y cómo por el
contrario, donde todo estaba “en orden” y “estandarizado” hemos visto
sucumbir, bajo la poca o casi nula capacidad de adaptación y previsión, a
las más grandes economías.
Esta situación no ha sido exclusiva de los mercados, ni se limita a las
grandes economías o a las grandes inversiones, no; es una situación que sin
temor a equivocarnos, hemos visto todos los que gestionamos proyectos día
a día, el “cómo hacer 4 con 8″ ha pasado a ser “como hacer 8 con 1″ y
aunque suena imposible no lo es, es solo cuestión de adaptación,
planificación, y adaptación otra vez. Solo gestionando los proyectos o
programas de esta manera, conseguiremos el éxito en el día a día de
nuestro negocio y el de nuestros socios/clientes, y seremos fuertes y
altamente eficientes, cuando no haya necesidad de una adaptación tan
dinámica y tan exhaustiva.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 11 de 141
Versión 3.2
1.2 Evocando la Dirección de Proyectos
Existen suficientes evidencias como para tener claro que la dirección de
proyectos no es algo nuevo, no es algo que se haya inventado alguna
entidad de algún país desarrollado y está claro que es una necesidad que el
mundo viene satisfaciendo de época en época, con mejores o peores
herramientas, con más o menos “éxito” y con buenas y malas técnicas.
Cuando pensamos en la dirección de proyectos, es natural que miremos
hacia atrás, sí, pero no a la versión 1 de “la norma”, sino muchísimo más
atrás aún. Sabemos que desde tiempos inmemoriales, el hombre ha
fabricado construcciones de todo tipo, algunas colosales, otras simplemente
inexplicables, otras no tan notorias, y muchísimas que de seguro quedan
por descubrir.
Seria quizás algo soberbio afirmar que estos señores no utilizaban ya
alguna técnica para la dirección de sus proyectos. Es probable que incluso
fueran mucho más efectivas que las que actualmente existen; basándonos
simplemente en lo imposible que resultaría repetir algunas de las obras que
hace miles de años ya se llevaban a cabo de manera sistemática.
Entonces, partamos de que la dirección de proyectos lleva en el mundo
quizás más años que muchos de los miles que ahora leemos este tratado, y
que sin lugar a dudas, seguirá aquí cuando muchos otros nos hallamos ido;
por lo tanto, es necesario aportar nuevos enfoques, nuevos planteamientos
que la enriquezcan cada vez más, aportar complementos que la hagan más
aplicable a cualquier situación y a cualquier contexto. Para ello estamos
aquí.
Nuestro tratado escapa completamente al planteamiento reducido y limitado
que ha llevado a las técnicas y métodos ágiles, a “llevar por apellido” el
desarrollo de software o cosas similares.
Gestionando con “El Tratado” podremos dirigir y gestionar la construcción
de un barco, la ampliación de una autopista, el desarrollo de un sistema
operativo, la puesta en marcha y posterior gobierno de una Software
Factory, la implementación de oficinas de proyecto y de servicios (PMO,
SMO, con éxito), los servicios que brindamos o queremos brindar a nuestros
clientes, nuestra organización interna y la relación externa (entre
empresas), la puesta en marcha de eventos (p.e. un congreso internacional
en tiempo record), la creación de una empresa, el lanzamiento de una
nueva línea de negocio (con el equipo implicado), y un largo etcétera.
¿Está orientado al desarrollo de software? Si lo necesitas, sí, pero esto va
mucho más allá y el limite solo lo estableces tú.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 12 de 141
Versión 3.2
1.3 Introducción a la complejidad y salida de la incertidumbre
1.3.1 Complejidad
Podemos caracterizar los proyectos por su complejidad, determinada por la
incertidumbre existente en dos dimensiones:
QUÉ es lo que se quiere hacer
CÓMO queremos hacerlo
La siguiente gráfica caracteriza las distintas tipologías de proyectos en
función de esta definición de complejidad:
Figura 1.1: Complejidad
1.3.1.1 Proyectos Simples
Son aquellos donde se conoce prácticamente al detalle QUÉ hay que hacer y
se dispone de la forma y los medios que definen CÓMO hacerlo.
En estos casos, existe un proceso definido que resuelve el problema con
unos recursos determinados en un tiempo conocido. En este contexto
funciona el enfoque predictivo, puesto que el grado de incertidumbre aquí
es mínimo.
La dirección de proyectos simples se basa en dos actividades principales:
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 13 de 141
Versión 3.2
Planificación inicial predictiva: haciendo un desglose de actividades,
estimando los recursos y el tiempo y estableciendo las líneas
maestras del plan.
Control: verificar que el proyecto se desarrolla según el cronograma
planteado.
1.3.1.2 Proyectos Complicados
En este tipo de proyectos se conoce QUÉ y se conoce CÓMO pero su tamaño
y/o por los riesgos implicados estas dimensiones podrían variar
ligeramente. La labor de dirección aquí se complica respecto a los proyectos
simples, obligando a tener una especial atención en la definición inicial de
los riegos y en su gestión a lo largo del ciclo de vida.
1.3.1.3 Caos
El caos es el terreno de la inspiración, de las ideas, de muchos proyectos de
investigación. No se ha definido en concreto QUÉ se quiere conseguir ni
CÓMO conseguirlo. Se trabaja de forma anárquica y no planificada. En este
entorno el éxito suele llegar de la mano de la serendipia.
1.3.1.4 Proyectos Complejos
En los proyectos complejos tenemos una visión clara, pero no tenemos
completamente definidos al inicio QUÉ es lo que hay que hacer y CÓMO hay
que hacerlo. Existe incertidumbre en ambas dimensiones, por tanto son
impredecibles. El enfoque predictivo aquí tiene unos resultados desastrosos,
puesto que es imposible predecir lo que no se conoce.
1.3.2 El Enfoque Empírico
Para llevar las riendas de un proyecto de estas características es importante
tener en cuenta que muchos procesos implicados en nuestra vida diaria
funcionan únicamente porque su grado de imprecisión es aceptable.
Pensemos en una bicicleta. Las ruedas se tambalean, el manillar se
desalinea, los frenos son inestables, pero todo ello no nos impide ir en bici.
Lo que ocurre es que todo ello sucede a un nivel del que no tenemos
consciencia.
Si quisiéramos construir una bicicleta, uniríamos una serie de piezas con
una precisión que consideráramos aceptable (por ejemplo que no se note al
ojo humano las uniones de los tubos del cuadro). Somos capaces de
gestionar muchos procesos únicamente porque la precisión de sus
resultados está limitada a nuestra percepción.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 14 de 141
Versión 3.2
Ahora bien, imaginamos que somos constructores de bicicletas y queremos
acceder al mercado profesional. Es posible que nuestros clientes requieran
que nuestros procesos constructivos alcance un nivel de precisión superior
para que las prestaciones de la bici satisfagan las especiales necesidades de
este mercado. En este caso deberemos controlar el proceso paso por paso
asegurándonos que se obtiene un resultado con un grado de aceptación
aceptable. Conocemos el QUÉ (con sus restricciones, como es el grado de
precisión aceptable), conocemos el CÓMO (a través de un proceso repetible
que produce un resultado con una calidad determinada). Si este resultado
no se produce, tendremos que hacer ajustes en el proceso hasta que vuelva
a estar en el rango de precisión aceptable. A este tipo de control del
proceso se le denomina definido.
Pero si no podemos lograr un control definido del proceso debido a la
complejidad de las actividades necesarias para desarrollar el producto hay
que emplear un control empírico del proceso.
El control empírico del proceso exige mayor coste que el control definido del
proceso. Pero si la complejidad de las actividades es lo suficientemente
grande, en el largo plazo, hacer productos bien a la primera con un control
empírico del proceso resulta ser mucho más barato que rehacer un proceso
que da lugar continuamente a productos inadecuados usando un control
definido del proceso.
1.3.2.1 Claves del Control de Proceso Empírico
Las tres claves del Control Empírico del Proceso son: visibilidad, inspección
y adaptación.
Visibilidad: los aspectos que influyen en el resultado deben ser
visibles para facilitar el control del proceso.
Inspección: estos aspectos deben ser controlados con frecuencia para
detectar las variaciones inaceptables.
Adaptación: una vez detectada estas variaciones o identificados
puntos de mejora, deben realizarse los cambios precisos en el
proceso para mejorarlo.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 15 de 141
Versión 3.2
1.3.3 Sistemas Adaptativos Complejos
En este contexto de alta incertidumbre, nos centramos en la resolución de
los problemas que hemos identificados como complejos.
En la mayoría de los casos la complejidad de estos problemas es tal que son
muy difíciles, imposibles o inviables de resolver por una única persona. Por
esta razón se opta por que la resuelvan un conjunto de personas,
entendiendo que así será más sencillo, o será posible o será viable.
Esta aproximación intuitiva tiene cierta base científica. Existen los
denominados Sistemas Multi Agente o SMA que, como su propio nombre
indica, son sistemas compuestos por múltiples agentes inteligente
interactuando entre ellos. Inteligentes hace referencia a que son capaces de
tomar decisiones.
Ahora bien, hay un tipo de SMA que es el que nos interesa para comprender
por qué funciona Scrum. Nos referimos a los Sistemas Adaptativos
Complejos SAC. Son también sistemas multiagente, pero tienen la
particularidad de que tanto los elementos como el propio sistema es
adaptativo; es decir, tienen la capacidad de aprender de la experiencia y
adaptarse para conseguir mejores resultados. Este le confiere la capacidad
de auto organización.
Sin entrar a profundizar más en la teoría, valga con comprender que lo que
aquí se plantea es que los equipos de trabajo se comporten como Sistemas
Adaptativos Complejos. Para lograr esto merece la pena destacar tres
características fundamentales que se deben fomentar en estos equipos:
Relaciones horizontales: cada elemento es igual al otro en cuanto a
oportunidad de participar, aportar y expresar, sin cabida a la
discriminación y sin presiones. Fomentando que todos los integrantes
se sientan socios y no jefes y subordinados. No existe elemento más
valioso. Está claro que no todos son netamente iguales, pero sí son
igualmente importantes.
Confianza: como dice Fukuyama: “la confianza es como un lubricante
que hace que cualquier grupo u organización funcione mejor,
permitiendo que cada uno exprese sus ideas plenamente con la
certeza de que no será sancionado o criticado, a actuar con libertad
sabiéndose en un espacio de todos”. Es esa la clase de confianza
esencial para que un equipo ágil pueda desarrollarse en plenitud de
facultades.
Comunicación: es la piedra angular que favorece la creación del resto
de circunstancias. Una comunicación fluida, clara y directa. Es el
punto sin duda más importante porque conforma la mayor clave de
éxito y de fracaso en los equipos en la mayoría de los proyectos.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 16 de 141
Versión 3.2
1.3.4 El Origen de Scrum
Scrum es un marco de trabajo ágil para la gestión de proyectos de cuyos
principios bebe el presente tratado. Estos principios comenzaron a emerger
y a ponerse en negro sobre blanco en 1986, fecha de publicación de “The
New Product Development Game”, de Hirotaka Takeuchi and Ikujiro
Nonaka, un estudio que habla de cómo incrementar la rapidez y la
flexibilidad en el desarrollo de nuevos productos comerciales, utilizando
como base casos de estudio de Estados Unidos y Japón procedentes la
industria automovilística así como de la fabricación de cámaras fotográficas,
impresoras y ordenadores. En este estudio se comparaba el
comportamiento de los componentes de los equipos de trabajo
multidisciplinares con las estrategias presentes en el juego del rugby. Por
esta razón, posteriormente la aproximación descrita en este artículo fue
referenciada como Scrum (lo que es en español “la melé”).
En 1995, los que están considerados como los padres del marco de trabajo
Scrum, Ken Schwaber y Jeff Sutherland coincidieron en un importante
evento relacionado con el desarrollo del software presentando en paralelo
un conjunto de artículos en los que describían Scrum. A partir de ese
encuentro comenzaron a colaborar, aunando su conocimiento, sus
experiencias y las mejores prácticas existentes para desarrollar lo que se
conoce en la actualidad como Scrum.
Pero es imposible comprender el sentido de Scrum sin hacer referencia al
“Manifiesto por el Desarrollo Ágil de Software”, en cuya elaboración, en
2001, participaron los creadores de Scrum junto con otros quince
profesionales del desarrollo de software que estaban en desacuerdo con el
enfoque basado en procesos que hasta la fecha predominaba en el sector.
En él se expresa lo siguiente:
“Estamos descubriendo formas mejores de desarrollar software tanto
por nuestra propia experiencia como ayudando a terceros. A través
de este trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos
más los de la izquierda.”
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 17 de 141
Versión 3.2
Y además exponen doce principios en los que se basa el desarrollo ágil de
software:
“Seguimos estos principios:
Nuestra mayor prioridad es satisfacer al cliente mediante la
entrega temprana y continua de software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías
del desarrollo. Los procesos Ágiles aprovechan el cambio para
proporcionar ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de tiempo más
corto posible.
Los responsables de negocio y los desarrolladores trabajamos
juntos de forma cotidiana durante todo el proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay
que darles el entorno y el apoyo que necesitan, y confiarles la
ejecución del trabajo.
El método más eficiente y efectivo de comunicar información al
equipo de desarrollo y entre sus miembros es la conversación cara
a cara.
El software funcionando es la medida principal de progreso.
Los procesos Ágiles promueven el desarrollo sostenible. Los
promotores, desarrolladores y usuarios debemos ser capaces de
mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño
mejora la Agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no
realizado, es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de
equipos auto-organizados.
A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo para a continuación ajustar y perfeccionar su
comportamiento en consecuencia.”
Scrum es un marco de trabajo que cristalizó en un contexto de desarrollo de
software pero se ha demostrado efectivo en muchos otros ambientes. La
característica común de los contextos donde Scrum funciona es la
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 18 de 141
Versión 3.2
complejidad, factor que hemos analizado anteriormente y que da sentido al
presente tratado.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 19 de 141
Versión 3.2
Capítulo 2
CULTURA ORGANIZACIONAL
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 20 de 141
Versión 3.2
2.1 Estructura tradicional de la Organización (causante de la
complejidad)
Un factor importante que influye dramáticamente en el modo de dirigir los
proyectos es la estructura de la organización.
Las estructuras típicas se debaten entre dos extremos. Por un lado tenemos
la organización funcional clásica. Se trata de una organización jerarquía
donde cada empleado tiene un superior claramente definido. Sobre ellos, los
miembros del personal están agrupados por especialidades, como pueden
ser: producción, ingeniería o contabilidad. Las especialidades pueden
dividirse en organizaciones funcionales, como la ingeniería mecánica y la
ingeniería eléctrica. Cada uno de estos departamentos desempeña el
trabajo del proyecto de forma independiente de los demás departamentos.
En el extremo opuesto de la organización funcional, tenemos la organización
orientada a proyectos. En este tipo de organizaciones, los miembros del
equipo están localizados en un mismo lugar, la mayor parte de los recursos
de la organización participa en el trabajo de los proyectos y los directores
del proyecto tienen mucha más independencia y autoridad. Estas
organizaciones suelen contar con unidades organizacionales denominadas
departamentos, pero estos grupos dependen directamente del director del
proyecto, o bien prestan sus servicios a varios proyectos.
Funcional
Matricial
Débil
Matricial
Equilibrada
Matricial
Fuerte
Orientada
a
Proyectos
Autoridad del
Director del
Proyecto
Poca o
Ninguna Limitada
Baja a
Moderada
Moderada a
Alta
Alta a Casi
Total
Disponibilidad
de recursos
Poca o
Ninguna Limitada
Baja a
Moderada
Moderada a
Alta
Alta a Casi
Total
Quién controla
el Presupuesto
del Proyecto
Gerente
Funcional
Gerente
Funcional Mixta
Director del
Proyecto
Director del
Proyecto
Dedicación del
Director del
Proyecto
Parcial Parcial Completa Completa Completa
Dedicación del
Personal
Administrativo
de la Dirección
de Proyectos
Parcial Parcial Parcial Completa Completa
Figura 2.1 Características de Estructuras de las Organizaciones
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 21 de 141
Versión 3.2
Entre ambas, nos encontramos con las organizaciones matriciales, que
presentan una mezcla de características de las organizaciones funcionales y
de las orientadas a proyectos.
Las denominadas matriciales débiles mantienen muchas de las
características de una organización funcional, y el rol del director del
proyecto es más bien el de un coordinador o expedidor, que el de un
verdadero director del proyecto.
Las matriciales fuertes tienen muchas de las características de la
organización orientada a proyectos: pueden tener directores del proyecto
dedicados de tiempo completo y una autoridad considerable, y personal
administrativo dedicado de tiempo completo. Si bien la organización
matricial equilibrada reconoce la necesidad de contar con un director del
proyecto, no le confiere autoridad plena sobre el proyecto ni su
financiamiento.
Bien es cierto en que muchas organizaciones coexisten todas estas
estructuras a diferentes niveles, lo que se denomina organización
combinada. Por ejemplo, imaginemos que una organización eminentemente
funcional tiene un equipo del proyecto especial para gestionar un proyecto
crítico, que puede tener muchas de las características de un equipo del
proyecto de una organización orientada a proyectos.
El equipo puede incluir personal dedicado de tiempo completo obtenido de
varios departamentos funcionales, puede disponer de sus propios
procedimientos desarrollar su propio conjunto de procedimientos.
Dada la naturaleza de los proyectos a los que se circunscribe el presente
tratado, la estructura propuesta está cercana a la organización por
proyectos, pero va más allá del enfoque tradicional.
En cualquier caso, en lo que atañe a la estructura, la organización debe
dotar de la importancia, el poder y los recursos necesarios al Director del
Proyecto para llevar a cabo su labor con la mayor probabilidad de éxito.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 22 de 141
Versión 3.2
2.2 Paradigmas Culturales
De manera informal e intuitiva, podemos definir el concepto de Cultura
Organizacional como el conjunto de experiencias, hábitos, costumbres,
creencias, y valores de las personas que conforman una organización. Es un
concepto íntimamente ligado al de estructura organizacional, puesto que
ambas conforman el contexto de la organización.
La cultura organizacional de una empresa determina, en muchos casos, el
éxito o el fracaso de la incorporación de una metodología o marco de
trabajo. Muchas organizaciones, admirando las virtudes de una metodología
(la que sea, es independiente a este nivel de análisis) y deciden incorporarla
sin preocuparse de verificar si su cultura organizacional está alineada con la
metodología o viceversa. O en el caso de que quieran incorporarla sí o sí, la
implantación de la metodología en muy contadas ocasiones comienza por el
cambio cultural. Todas las organizaciones deben aspirar a obtener el mayor
rendimiento de sus recursos. Por ello deben conjuntar los diferentes
aspectos organizacionales para que funcionen en armonía. No deben pasar
por alto que la conjunción de elementos que conforman la cultura
organizacional de la empresa se convierte en un activo fundamental que
puede acelerar, frenar o malograr la implementación de cualquier cambio en
la empresa.
Con objeto de ilustrar la importancia de la cultura de una organización, vamos a poner nuestra atención en cuatro paradigmas o cuadrantes definidos por Cameron y Quinn (1999), distribuidos en dos dimensiones:
1. Flexibilidad, discreción y dinamismo vs estabilidad, orden y control
2. Orientación interna, integración y unidad vs orientación externa, diferenciación y rivalidad
Figura 2.2: Paradigmas Culturales
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 23 de 141
Versión 3.2
2.2.1 Paradigma cultural de clan
En una organización de clan las premisas básicas son las siguientes:
1. El ambiente puede manejarse mejor por medio del trabajo
colaborativo y el desarrollo de los empleados
2. Los consumidores deben ser vistos como socios
3. La organización “está en el negocio” de desarrollar un ambiente
humano de trabajo
4. la mayor tarea de la gerencia es otorgarles a los empleados el poder
de decisión y facilitar su participación, dedicación, compromiso y
lealtad.
2.2.2 Paradigma cultural de jerarquía
Este paradigma está basado en los atributos clásicos de la burocracia de
Max Weber: reglas, especialización, “meritocracia” (supervisión mediante
premios y sanciones), jerarquía, propiedad separada, impersonalidad y
responsabilidad. Estas características fueron adoptadas por empresas e
instituciones cuyo mayor reto fue generar eficiencia, confiabilidad, flujos
planos y resultados predecibles. Por tanto, suele ser adecuada en ambientes
predecibles.
2.2.3 Paradigma cultural de adhocracia
En este paradigma la principal labor directiva es lograr que se adopten
la creatividad, el emprendimiento y la actividad de “permanecer en el
límite”. La adaptación y la innovación son vías para conseguir nuevos
recursos y lograr la rentabilidad; consecuentemente, se remarca de
manera especial la creación de una visión del futuro, una “anarquía
organizada” y una capacidad de imaginación considerable. Para los
autores Cameron y Quinn (2006), este tipo de cultura organizacional
representa un diseño organizacional de re‐construcción permanente.
Las adhocracias tienen un carácter eminentemente temporal, se
reconstituyen con rapidez cuando se presentan otras circunstancias.
Una meta esencial de la organización adhocrática es crear
adaptabilidad, flexibilidad y creatividad para combatir la incertidumbre,
la ambigüedad y la carga excesiva de información, típicas de la era de
la información que estamos viviendo
2.2.4 Paradigma cultural de mercado
Las premisas fundamentales de la cultura de mercado son:
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 24 de 141
Versión 3.2
1. El ambiente externo no es benigno sino hostil
2. Los consumidores son sensibles y están interesados en el
coste del producto o servicio (el valor agregado es
importante)
3. La compañía está inmersa en el “negocio” de incrementar
su posición competitiva
4. La tarea mayor de la gerencia es conducir a la
organización hacia la productividad, los resultados y las
ganancias. Para ello se necesita de propósitos claros y
una estrategia agresiva.
2.2.5 Conclusiones
Estos cuatro paradigmas son extremos. En la mayoría de las organizaciones
obtendremos combinaciones con elementos de unos y de otros. Pero es
importante conocer en qué términos la empresa define el éxito y el modo de
conseguirlo.
En un contexto de alta incertidumbre, los equipos de trabajo funcionarán
bajo un paradigma de clan, cercano a la adhocracia. A medida que vayamos
avanzando en la lectura de este tratado, iremos razonando sobre las
cuestiones culturales del marco de trabajo.
La organización que alberga este equipo de proyecto puede trabajar bajo
otro paradigma. Esto es posible. Aunque es necesaria la incorporación de
elementos adaptadores, que permitan aislar y conectar al equipo del
proyecto con el resto de la organización cuando se requiera.
No obstante, siempre es conveniente que toda la organización esté alineada
y que trabaje bajo un marco compartido de experiencias, hábitos,
costumbres, creencias, y valores.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 25 de 141
Versión 3.2
2.3 La gestión del cambio y de la transición
2.3.1 El cambio como evolución | El cambio como
revolución
El cambio es inherente a la realidad. La cultura oriental ya nos cuenta que
“la única constante en el universo es el cambio”. Maslow ya ilustró de forma
muy gráfica a través de su famosa pirámide que el ser humano tiene una
serie de necesidades que debe satisfacer. Estas necesidades se disponen
por niveles conceptuales. Lograr satisfacer las necesidades de un nivel hace
que la persona se plantee necesidades de niveles inferiores. Así tenemos
cinco principales estratos, que son:
• Necesidades básicas u homeostáticas, que son fisiológicas, relativas a
la salud, como alimentarse o respirar.
• Necesidades de seguridad y protección.
• Necesidades de afiliación y afecto.
• Necesidades de estima y reconocimiento.
• Autorrealización.
Figura 2.3: Pirámide de Maslow
•creatividad
•aceptación de hechos
• resolución de problemas
Autorrealización
•autorreconocimiento
•confianza
• respeto
•éxito
Reconocimiento
•amistad
•afecto
• intimidad sexual
Afiliación
• física
•de empleo
•de recursos
Seguridad
• respiración
•alimentación
•descanso
Fisiología
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 26 de 141
Versión 3.2
La evolución, la satisfacción de las necesidades y el acceso a las
necesidades superiores implican evolución en la persona. Implican cambio.
Hay muchos tipos de cambio. Muchos de estos cambios implican
incertidumbre. Muchas personas responden a estas transiciones en su vida
con miedo, otras con ilusión. Unas buscan situaciones de incertidumbre (“ir
a la aventura”) y otras prefieren avanzar planificadamente.
Por otro lado, las personas desarrollamos un sentimiento de paz y sosiego
cuando nos encontramos dentro de nuestra “zona de confort”; es decir,
cuando hacemos algo que dominamos y cuya incertidumbre es
relativamente baja. Fuera de esta zona, están las situaciones nuevas, está
la incertidumbre, pero también está el aprendizaje. Salir de la zona de
confort implica un cambio. De atención, de actitud, nos hemos de activar,
porque la incertidumbre hace su aparición. Y fuera de la zona de confort, en
la medida que respondemos a situaciones nuevas, se produce el
aprendizaje.
Hay quienes buscan este aprendizaje de manera continua, dónde se hace
natural al flujo de vida, los cambios se realizan por convencimiento. Hay
una vocación inherente a la evolución.
Pero hay otras personas u otras situaciones en las que el cambios es
drástico, dramático en muchos casos. Imaginamos el caso de una persona
que esté harta de la situación de su trabajo y decide poner fin a esa relación
laboral. Su paradigma cambia de la noche al día. Se produce un cambio por
revolución.
En cualquier caso, la vida del ser humano está llena de cambios, cotidianos
y excepcionales. La forma en la que respondemos a estos tiene su reflejo en
nuestra capacidad aprendizaje.
2.3.2 Cambio Organizacional
En una sociedad tan acelerada como la que nos encontramos en la
actualidad, cualquier organización debe estar lo suficientemente preparada
para adaptarse y evolucionar en entornos dinámicos, complejos y de gran
incertidumbre.
En épocas anteriores, las organizaciones han trabajado en entornos
relativamente estables en el que la gestión del cambio no era una prioridad
y sí la gestión del crecimiento o la fidelización de los nichos de mercado que
habían conquistado. Eran momentos donde la excelencia en las actividades
de planificación y control proporcionaban altos niveles de seguridad y
estabilidad en el seno de las organizaciones y en el que los planes de
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 27 de 141
Versión 3.2
cambio se acometían de manera excepcional y como paso previo a grandes
periodos de estabilidad.
En la actualidad, la situación es muy diferente. Los cambios se aceleran en
diferentes planos y de manera simultánea como la ciencia, la tecnología, la
economía, la sociedad, etc., por lo que se hace imprescindible dar
respuestas ágiles y rápidas a situaciones emergentes de escasa
predictibilidad, y donde la cultura organizacional se convierte en el factor
clave de éxito para llevar a cabo tales desafíos.
La experiencia, la creatividad, la iniciativa, el compromiso o la co-
responsabilidad son características, entre otras, que deben impregnar a
cualquier organización que desee ejecutar de manera efectiva cualquier
proceso de cambio. Por tanto, la gestión del cambio se ha convertido en un
arte de gran importancia estratégica y que debe ejecutarse de manera
continuada perfectamente integrada en el día a día de las organizaciones,
requiriendo que éstas apuesten por un cambio cultural y que sean capaces
de desarrollar de manera orgánica marcos de trabajo que potencien su
capacidad de transformación.
2.3.3 Dimensiones del Cambio
Generalmente, las organizaciones suelen responder a diferentes desafíos
como la incorporación o desarrollo de nuevas tecnologías, la aparición y
penetración en nuevos mercados, la aparición de nuevos competidores y a
la propia motivación que mueve a las organizaciones por ser mejores y más
grandes, a través de programas perfectamente diseñados y orientados a
superar todos aquellos obstáculos que se interponga en el camino de la
mejora de la organización.
Estos programas habitualmente se pueden categorizar de la siguiente
manera:
Cambios estructurales. Son los provocados por nuevas fusiones,
adquisiciones, consolidaciones, desinversiones de unidades
operativas.
Reducción de costes. Estos programas focalizan la atención en la
eliminación de todas aquellas actividades que no aportan valor de
negocio.
Cambio de procesos. Este tipo de cambios pretenden cambiar la
forma en la que se llevan a cabo las cosas para que se desarrollen
procedimientos más rápidos, ágiles, eficaces, fiables y menos
costosos.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 28 de 141
Versión 3.2
Cambio cultural. Estos programas ponen toda la atención el el factor
humano y cómo éste impacta en la forma en el que la organización
hace los negocios o como se relaciona la dirección con los empleados.
Independientemente del programa de cambio que tenga pensado llevar a
cabo, es fundamental que inicialmente sea capaz de identificar en qué
categoría se encuentra su programa para que a continuación pueda prever
los potenciales impedimentos que pueden afectar al transcurrir normal del
proceso de cambio.
Ya hemos visto que existen diferentes tipos de programas de cambio pero lo
que debemos preguntarnos realmente es cuál es el objetivo que se
persigue. Normalmente suelen ser dos:
Una mejora económica a corto plazo normalmente como
consecuencia de una crisis financiera. La consecución de este objetivo
suele ir acompañado de la eliminación total de actividades que
anteriormente no consiguieron demostrar una creación tangible de
valor, siendo especialmente vulnerables las relacionadas con la I+D
Una mejora de las capacidades de la organización con la firme
intención de desarrollar culturas organizacionales más dinámicas,
planas, con una formidable participación de los empleados y donde se
apoye el aprendizaje, impulsando así el éxito financiero.
Ninguno de estos enfoques es garantía de éxito. Sin embargo, aquellas
empresas que sean capaces de combinar de manera efectiva ambos
enfoques al cambio, tendrán mayor predisposición a recoger importantes
recompensas en productividad y rentabilidad.
Dimensiones del cambio
Mejora
económica a corto plazo
Mejora de las
capacidades de la
organización
Enfoque combinado
Objetivos
Incrementar al
máximo el valor para el accionista
Desarrollar las
capacidades de la
organización
Equilibrio
entre el valor económico y la capacidad
de organización
Liderazgo Dirección/Gestión impulsado por la
directiva
Fomentar la
participación de abajo
hacia arriba
Establecer la dirección
desde los ejecutivos
involucrando a los empleados
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 29 de 141
Versión 3.2
Enfoque/concentración Centrado en la estructura y
sistemas
Cultiva la cultura
organizacional
Focalizar de
manera simultánea en
ambos
Proceso Planificación y
control
Inspeccionar
y adaptarse
Planificar la
espontaneidad
Recompensas Incentivos financieros
Utilizar el
compromiso como
motivación y el sueldo
como
respuesta justa
Facilitar incentivos
para reforzar el cambio y no
para
impulsarlo
Ayuda de asesores externos
Analizan
problemas y proponen
soluciones
Apoyan a la dirección para
que
encuentren soluciones
Facilita y Democratiza
la toma de decisiones
entre los empleados
Figura 2.4: Dimensiones del Cambio
2.3.4 ¿Preparado para el cambio?
Una vez conocida las diferentes dimensiones del cambio, de poco le servirá
a la organización llevar a cabo los programas de cambio si ésta no está
preparada. Las condiciones necesarias que se deben dar en cualquier
organización para que el cambio se ejecute de manera efectiva son las
siguientes:
Que exista la figura de líder eficaz, servicial y respetado por todos.
Que exista una buena motivación en la organización por cambiar. En
este tipo de situaciones, se debe evitar por todos los medios
respuestas reactivas ante situaciones de crisis. Lo deseable sería
responder con una actitud proactiva sin recurrir a las tácticas
tradicionales en época de crisis. Aquí presentamos algunas
actividades que se pueden llevar a cabo para conseguir este objetivo:
o Generar debate constructivo entre los empleados respecto a
los problemas actuales y futuros de la organización
transmitiendo la información sobre la situación competitiva de
la organización
o Facilitar oportunidades dentro de la organización para que los
empleados eduquen a la dirección en cuanto a la insatisfacción
y problemas que experimentan
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 30 de 141
Versión 3.2
Que existe un paradigma colaborativo en el seno de la organización,
pues las estructuras jerárquicas no facilitan el trabajo en
colaboración, que al mismo tiempo es una de las habilidades más
importantes que deben tener los empleados de una empresa
preparada para el cambio.
A continuación, presentamos algunas claves que le serán de utilidad para
evaluar si su organización está preparada para el cambio:
Evalúe diferentes unidades de negocio y comience el cambio por
aquellas que están preparadas
Fomente el trabajo colaborativo facilitando la toma de decisiones
desde los puestos menos directivos, transmitiendo y compartiendo
información, eliminando símbolos que denoten jerarquía o estatus,
experimentando in situ el trabajo del resto de empleados, etc.
Dele voz a la gente apoyando el pensamiento creativo e innovador,
mostrando respeto, delegando, tomando riesgos.
Elimine el miedo
2.3.5 Las siete fases del cambio
2.3.5.1 Fase 1
Objetivo: Potenciar la energía, el compromiso y la dedicación a través de la
identificación conjunta de los problemas del negocio y sus soluciones.
Es fundamental desarrollar un sentido de urgencia alrededor de la necesidad
de cambio que sirva como empujón inicial para despertar la motivación y
así el movimiento de cambio.
Es importante la identificación del problema pero también lo es la manera
en la que se identifica.
Se deben generar espacios abiertos donde se dialogue y discuta de lo que
está pasando en el mercado y su competencia.
Por último, hay que desarrollar un plan de acción donde todas las partes se
encuentren involucradas, formando parte de la solución. En cualquier caso,
es fundamental en este punto en el que un porcentaje muy alto de los
puestos directivos se encuentren convencidos y comprometidos con la
propuesta de cambio.
2.3.5.2 Fase 2
Objetivo: Desarrollar una visión compartida de cómo organizarse y dirigir
para ser competitivo.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 31 de 141
Versión 3.2
Todas las soluciones e ideas recogidas previamente deben estar vinculadas
a una visión general y compartida que todo el mundo pueda entender y
recordar sin problemas, que proporcione sentido. La comunicación en este
punto es fundamental. Sea claro, conciso, indicando los beneficios que
supondrá para todos. Una visión eficaz debe tener las siguientes
características:
Describe un futuro deseable
Debe ser apremiante
Ser realista
Estar concentrado
Ser flexible
Fácil de comunicar
Debe poder ser traducida a acciones concretas
Compatible con los valores de la empresa
2.3.5.3 Fase 3
Objetivo: Identificar el liderazgo.
Convencer a la gente de que el cambio es necesario implica un fuerte
liderazgo y apoyo visible por parte de gente clave dentro de la organización.
Gestionar el cambio no es suficiente. También tiene que liderarlo.
Puede encontrar líderes del cambio dentro de la empresa. Para liderar el
cambio, debe reunir una coalición o equipo de personas influyentes cuyo
poder proviene de una variedad de fuentes, incluyendo los puestos que
ocupan, status, experiencia e importancia política.
Una vez formada, su “coalición” necesita trabajar como equipo, en la
continua construcción de la urgencia y del impulso en torno a la necesidad
del cambio. Los líderes del cambio comparten tres características:
Creen de forma persistente que la revitalización es la clave de la
competitividad
Fundamentan su convicción bajo una visión creíble y apremiante.
Tienen las habilidades necesarias para relacionarse con las personas
y son poseedoras de un gran conocimiento de la organización,
poniendo en práctica la visión.
2.3.5.4 Fase 4
Objetivo: Concentrarse en los resultados y no en las actividades.
Es preferible establecer unos objetivos mensurables de actuación a corto
plazo aparcando inicialmente los largos planes de preparación, formación,
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 32 de 141
Versión 3.2
desarrollo de cursos, etc. Se pretende obtener soluciones satisfactorias más
que óptimas.
2.3.5.5 Fase 5
Objetivo: Empezar el cambio en la periferia, dejando que después se
extienda a otras unidades sin presionar desde arriba.
El proceso de cambio tendrá mayor probabilidad de éxito en la medida que
el cambio se impulse desde unidades pequeñas y bastante autónomas.
Estas unidades deberán percibir que obtienen claras ventajas respecto al
statu quo, que es compatible con los valores, experiencias y necesidades,
desde un punto de vista directivo, las exigencias son comprensibles,
además de proporcionar la oportunidad a los empleados de experimentar el
modelo de cambio a pequeña escala.
2.3.5.6 Fase 6
Objetivo: Institucionalizar el éxito por medio de políticas, sistemas y
estructuras formales
Muchos proyectos de cambio fracasan por celebrar los éxitos de manera
anticipada. El cambio real sucede muy profundamente. Las victorias
tempranas son sólo el comienzo de lo que se necesita hacer para lograr los
cambios a largo plazo. Pero la búsqueda de las mejoras debe ser incesante.
Cada victoria proporciona una oportunidad para construir sobre lo que salió
bien y determinar qué se puede mejorar. La mejora continua es el objetivo
máximo y final.
2.3.5.7 Fase 7
Objetivo: Vigilar atentamente y ajustar las estrategias en respuesta a los
problemas del proceso de cambio.
En general, cualquier programa de cambio no se cumple al pie de la letra.
Durante su ejecución, es normal encontrarse en el camino con una gran
cantidad de problemas no previstos o impedimentos, ya sean de carácter
interno y/o externo. Por ello, es fundamental que los líderes del cambio
sean flexibles y que tengan la suficiente resiliencia como para adecuarse
a las posibles alteraciones.
En cualquier programa de cambio, hay una delgada línea que separa el
liderazgo de la de dirección. Mientras que el líder crea una visión atractiva
de futuro y desarrollan todo un plan para hacerla realidad motivando a la
gente, la dirección debe preocuparse y ocuparse que todas las tareas
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 33 de 141
Versión 3.2
necesarias para llegar a tal fin funcionen sin ningún tipo de problemas. A
continuación, presentamos la relación entre el liderazgo y la dirección a
través de la siguiente matriz:
2.3.6 Implementación del Cambio
En muy pocas ocasiones, la implantación del cambio se realiza sin
sobresaltos pues entra dentro de la normalidad que se cometan
equivocaciones, que los factores externos trastornen la planificación,
rotaciones de personas clave, falla la comunicación, etc.
Una implantación efectiva del cambio comienza por tener en cuenta y ser
consciente de los principales problemas que se producen en la puesta en
marcha de un cambio y son los siguientes:
Desviaciones en tiempo respecto a lo que se estimó inicialmente
Aparición de problemas no identificados inicialmente
Figura 2.5: Matriz liderazgo / dirección
0
0 ++
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 34 de 141
Versión 3.2
Baja eficiencia en la coordinación de las actividades de puesta en
práctica
Actividades enfrentadas y crisis distrajeron la atención de la
implantación
Falta de capacidades y habilidades de las personas implicadas
Poca adecuación de la formación a la puesta en práctica del cambio
Factores externos incontrolables
Para mejorar las probabilidades de éxito, es fundamental tener éxito en los
siguientes desafíos:
Conseguir el apoyo y la implicación de personas clave
Idear un plan de puesta en práctica
Apoyar el plan a través de conductas y mensajes consistentes
Desarrollar unas estructuras facilitadoras
Celebrar los hitos conseguidos
Comunicar
2.3.6.1 Conseguir el apoyo y la implicación de personas clave
Todo inicio de cambio debe comenzar consiguiendo un equipo de trabajo
efectivo e implicado que sean capaces de actuar conjuntamente para
conseguir unos objetivos establecidos. Para ello, este equipo de personas
deberá estar formado por directivos y empleados que sean respetados por
los demás, que proporcione credibilidad al resto y que cuenten con
capacidades, habilidades y responsabilidades clave dentro de la
organización.
2.3.6.2 Idear un plan de puesta en práctica
Una visión clara y compartida del cambio facilita la canalización de los
esfuerzos del equipo de trabajo para conseguir los objetivos
propuestos. Pero este equipo también necesita un plan que describa
qué es lo que tienen que hacer, cuándo y cómo tienen que hacerlo.
Un plan efectivo suele presentar las siguientes características:
o Sencillo
o Es generado por todas aquellas personas en los diferentes
niveles que se vean afectados por el cambio. Con esto
conseguiremos una mayor implicación de todos. Los cambios
por convicción suelen ser menos resistentes que los cambios
por imposición
o Estructurado en actividades que se pueden alcanzar.
o Definir roles y responsabilidades
o Flexible y vivo antes nuevos cambios y revisiones
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 35 de 141
Versión 3.2
2.3.6.3 Apoyar el plan a través de conductas y mensajes
consistentes
Es vital para el transcurrir normal de la puesta en marcha, que una vez
conseguido el apoyo necesario para ejecutarlo, éste se mantenga a través
de comportamientos y mensajes coherentes.
2.3.6.4 Desarrollar unas estructuras facilitadoras
Este plan de acción es sostenido a través de actividades y programas que
facilitan la consecución de los objetivos marcados. Generalmente, este tipo
de actividades incluyen programas piloto, formación y un sistema de
recompensa. Los programa piloto proporcionan oportunidades a personas
para que éstas aborden la implantación y los problemas pero a una escala
más pequeña. Los programas de formación están orientados a facilitar y
mejorar la implantación del cambio. Por último, un sistema de recompensa
bien diseñado facilita la motivación y la productividad en este tipo de
programas de cambio.
2.3.6.5 Celebrar los hitos conseguidos
Es necesario para mantener altos niveles de energía y estados emocionales
positivos.
2.3.6.6 Comunicar
Es fundamental comunicar sin descanso, de forma que motive e implique a
todas las partes interesadas para superar con la mayor suavidad posible la
resistencia al cambio preparando a todos ante posibles altibajos,
desviaciones, etc. Los mensajes de comunicación suelen ir orientados a
comunicar los siguientes aspectos:
Naturaleza del cambio
Motivos del cambio
Aclarar el alcance del cambio, ya sea positivo o negativo
Usar herramientas visuales para explicar el proyecto de cambio
Pronosticar los aspectos negativos de la implantación
Medición de hitos y criterios que se utilizarán para indicarnos el éxito
Recompensas asociadas a los éxitos
Repetir el propósito del cambio y las acciones planificadas
Variar el estilo de comunicación atendido a su audiencia
Facilitar la comunicación bidireccional
Ser un anuncio viviente del programa de cambio
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 36 de 141
Versión 3.2
2.3.7 El Cambio Sistemático
Los beneficios de un único proyecto de cambio en los tiempos en los que
nos movemos no suelen durar para siempre. Aquellas organizaciones que
durante programas de cambio desarrollaron productos y servicios
despuntando en los mercados, ven como de manera gradual van pasando
de la innovación a la defensa a muerte de un segmento de clientes. Por otro
lado, paulatinamente la organización sufre un acomodamiento progresivo y
reactivo, lo que termina en una urgente necesidad de hacer grandes
cambios.
Por lo tanto, es absolutamente fundamental que la organización esté
continuamente respondiendo a toda clase de estímulos externos (clientes,
mercados, competidores, etc.) al mismo tiempo que mejorando los factores
internos para proporcionar una respuesta adecuada.
El cambio por tanto se produce de manera natural y continuada a través de
pequeños cambios proporcionando los siguientes beneficios:
Facilita la gestión de los cambios
Aumenta la probabilidad de éxito
Mejora el control de impedimentos
Se obtienen niveles estables de competitividad, preparación y buena
disposición al cambio
A continuación, ofrecemos una serie de consejos destinados a poner en
práctica el cambio continuo y progresivo en una organización y aumentar
las probabilidades de éxito:
Preparar a la organización para el cambio
Monitorizar sistemáticamente el mundo exterior
Monitorizar interna continua
Dotar a los equipos de trabajo de cosas que proporcionen sentido de rutina,
familiaridad y continuidad, pues científicamente está probado que un exceso
de cambio es insalubre, perturbador e inquietante. Teniendo en cuenta que
las personas somos animales sociales y que el trabajo tiene una importante
dimensión social, algunas actividades para mantener estos vínculos bien
intactos suelen ser las que facilitan oportunidades compartiendo almuerzos,
realizando actividades de ocio (deporte) y cosas por el estilo.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 37 de 141
Versión 3.2
Capítulo 3
LA PLANIFICACIÓN Y SUS PERSPECTIVAS
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 38 de 141
Versión 3.2
3.1 Ejecución Incremental por Fases
La ejecución por fases plantea no hacer un único entregable al final del
proyecto, sino planificar diferentes hitos intermedios con sus
correspondientes entregables que nos sirvan para validar nuestro progreso
e identificar nuestros errores cuanto antes, con el objetivo de abaratarlos lo
máximo posible. El proyecto se planifica en bloques temporales,
comúnmente llamado iteraciones o fases. En general, en cada fase se repite
un proceso de trabajo similar.
Los métodos iterativos o por fases, muy presentes en la matemática
computacional, se suelen utilizar para resolver problemas que implican tal
número de variables que los métodos directos (es decir, lo que intentan
resolver el problema de una sola vez) tendrían un coste inviable.
Recordemos que nos movemos en un entorno donde la incertidumbre es
alta, donde el problema que pretendemos resolver es complejo, el número
de variables es grande y donde por tanto sería conveniente no esperar
hasta el final del proyecto para validar si lo que estamos haciendo es
correcto o por el contrario nos estamos equivocando en algo.
La ejecución incremental se basa en el desarrollo por fases, pero incluye
importantes matices con el objetivo de que el entregable producido en cada
iteración tenga mucho más valor.
En el enfoque incremental cada entrega es un subconjunto del producto
final. A medida que se suceden las entregas se incrementan las
características y el valor del producto final. Por lo que es vital generar desde
la primera fase un producto que tenga valor, que se pueda validar, que se
pueda evaluar, del que se pueda extraer conclusiones y aprender para
aplicar ese nuevo conocimiento en la siguiente fase.
De este modo el cliente obtiene beneficios del proyecto de forma
incremental, proporcionando resultados anticipados y disminuyendo el “time
to market”.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 39 de 141
Versión 3.2
3.2 Actividades ejecutadas vs Valor entregado
En la gestión de proyectos tradicional, la forma habitual de proceder a
planificar un proyecto es recopilar requisitos, determinar el alcance, derivar
las tareas necesarias para darles cumplimiento y estimar el tiempo y los
recursos necesarios para llevarlas a cabo.
El paradigma ágil no se basa en el desglose de actividades, sino en la
definición de características que al crearlas proporcionan valor para el
cliente. Esta es la base para una ejecución incremental por fases.
Esto supone un cambio de paradigma enorme en cuyo epicentro se sitúa el
cliente y que está plenamente orientado a ayudarle a que emerjan sus
necesidades, a descubrir lo que realmente desea y a satisfacerle
plenamente.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 40 de 141
Versión 3.2
3.3 Una panorámica al flujo de trabajo
El proyecto comienza con una visión de lo que se va a desarrollar. El reto
está en entregarles la consecución de la visión de un modo que maximice su
ROI en todo momento. Para ello, se construye una lista de requerimientos
potencialmente entregables que supone un punto de inicio. Sus contenidos
y prioridades cambiarán a medida que el proyecto avance.
La ejecución del proyecto es por fases, de forma incremental. Todas las
fases tendrán la misma duración para conseguir un ritmo sostenible y
consolidar los hábitos efectivos de trabajo.
En cada fase, primero se decidirá QUÉ se va a hacer y luego CÓMO se va
llevar a cabo, de modo que el trabajo en esa fase se define y se acota. Esta
planificación cristaliza en una lista de tareas que transformarán los
requisitos seleccionados para esa fase en un incremento de características
del producto final. Una consecuencia directa es que las personas encargadas
de la ejecución estén plenamente focalizadas durante la fase.
Cada día de ejecución, se comparte el desempeño y los impedimentos, se
sincroniza el trabajo de todos los miembros del equipo, se da visibilidad a
los progresos de cada miembro y se comienzan a resolver los
impedimentos.
Al final de la fase se revisa el producto desarrollado durante la misma.
Antes del comenzar la siguiente fase se revisan los procesos y prácticas
utilizados en el proyecto, de modo que sean más efectivos y más
agradables en la siguiente fase.
Sin entrar en detalles en este punto, en esta panorámica ya se intuye cómo
se pone de manifiesto valores como la comunicación o la inspección y
adaptación empíricas referidos cuando hablamos sobre la complejidad.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 41 de 141
Versión 3.2
3.4 Modelos tradicionales, en ocasiones útiles
A continuación presentamos una serie de técnicas que han venido
utilizándose en el paradigma (la tan reconocida ANSI/PMI 99-001-2004)
tradicional de planificación de actividades, y que en las ocasiones donde
todo es susceptible de ser previsto y esquematizado son muy útiles; por
tanto merece la pena conocer.
3.4.1 Descomposición
La descomposición es la subdivisión de los entregables del proyecto en
componentes más pequeños y más manejables, hasta que el trabajo y los
entregables queden definidos al nivel de paquetes de trabajo. El nivel de
paquetes de trabajo es el nivel más bajo en la EDT, y es aquél en el que el
costo y la duración de las actividades del trabajo pueden estimarse y
gestionarse de manera más confiable. El nivel de detalle para los paquetes
de trabajo varía en función del tamaño y la complejidad del proyecto.
La descomposición de la totalidad del trabajo del proyecto en paquetes de
trabajo implica generalmente las siguientes actividades:
• identificar y analizar los entregables y el trabajo relacionado
• estructurar y organizar la EDT
• descomponer los niveles superiores de la EDT en componentes
detallados de nivel inferior
• desarrollar y asignar códigos de identificación a los componentes de
la EDT
• verificar que el grado de descomposición del trabajo sea el necesario
y suficiente
La estructura de la EDT puede crearse de diferentes maneras, tales como:
• Usando las fases del ciclo de vida del proyecto como primer nivel de
descomposición, con los entregables del producto y del proyecto
insertados en el segundo nivel.
• Usando los entregables principales como primer nivel de
descomposición.
• Usando subproyectos que pueden ser ejecutados por organizaciones
externas al equipo del proyecto, como trabajo contratado. En el
marco de un trabajo mediante contrato, el vendedor desarrollará la
estructura de desglose del trabajo contratado correspondiente.
La descomposición de los componentes del nivel superior de la EDT requiere
subdividir el trabajo para cada uno de los entregables o subproyectos en
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 42 de 141
Versión 3.2
sus componentes fundamentales, hasta el nivel en que los componentes de
la EDT representen productos, servicios o resultados verificables.
La EDT puede estructurarse como un esquema, un organigrama, un
diagrama de espina de pescado o cualquier otro método. La verificación de
la exactitud de la descomposición requiere determinar que los componentes
de nivel inferior de la EDT sean los necesarios y suficientes para completar
los entregables de alto nivel correspondientes.
Cada entregable diferente puede tener diferentes niveles de
descomposición. Para llegar al nivel del paquete de trabajo, en el caso de
algunos entregables sólo se necesitará descomponer el trabajo al siguiente
nivel, mientras que en otros casos será necesario añadir niveles
suplementarios de descomposición. Conforme se descompone el trabajo en
niveles de mayor detalle, la capacidad de planificar, gestionar y controlar el
trabajo es mayor. Sin embargo, una descomposición excesiva puede
ocasionar un esfuerzo improductivo de gestión, un uso ineficaz de recursos
y una disminución de la eficiencia de realización del trabajo.
En el caso de entregables o subproyectos cuya realización se sitúe en un
futuro lejano, es probable que no pueda realizarse la descomposición.
Normalmente, el equipo de dirección del proyecto espera hasta que el
entregable o subproyecto sea lo suficientemente claro para poder
desarrollar los detalles de la EDT. Esta técnica se denomina a veces
planificación gradual.
La EDT representa todo el trabajo necesario para realizar el producto o el
proyecto, e incluye el trabajo de gestión del proyecto. El total del trabajo en
los niveles inferiores de la EDT debe corresponder al cúmulo de los niveles
superiores, de modo que no se omita nada y que no se efectúe ningún
trabajo innecesario. Esto se denomina a veces la regla del 100 %.
3.4.2 Planificación Gradual
La planificación gradual es una forma de planificación mediante elaboración
gradual, donde se planifica en detalle el trabajo que debe desarrollarse en el
corto plazo y el trabajo futuro se planifica a un nivel superior de la EDT.
Por lo tanto, dependiendo de su ubicación en el ciclo de vida del proyecto, el
trabajo puede existir en diferentes niveles de detalle. Por ejemplo, durante
la planificación estratégica temprana, donde la información está menos
definida, los paquetes de trabajo pueden descomponerse a nivel de hitos.
Conforme se conoce más acerca de los próximos eventos en el corto plazo,
pueden descomponerse en actividades.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 43 de 141
Versión 3.2
3.4.3 Plantillas
Una lista de actividades estándar o una parte de una lista de un proyecto
previo, puede utilizarse a menudo como plantilla para un nuevo proyecto.
La información relacionada con los atributos de las actividades de las
plantillas también puede incluir otra información descriptiva útil para la
definición de las actividades. Las plantillas también pueden utilizarse para
identificar hitos típicos del cronograma.
3.4.4 Método de Diagramación por Precedencia (PDM)
El método de diagramación por precedencia (PDM) es utilizado en el método
de la ruta crítica (CPM) para crear un diagrama de red del cronograma del
proyecto que utiliza casillas o rectángulos, denominados nodos, para
representar las actividades, que se conectan con flechas que muestran sus
relaciones lógicas. Esta técnica también se denomina actividad en el nodo
(AON) y es el método utilizado por la mayoría de los paquetes de software
de gestión de proyectos.
El método de diagramación por precedencia incluye cuatro tipos de
dependencias o relaciones lógicas.
Final a Inicio. El inicio de la actividad sucesora depende de la
finalización de la actividad predecesora.
Final a Final. La finalización de la actividad sucesora depende de la
finalización de la actividad predecesora.
Inicio a Inicio. El inicio de la actividad sucesora depende del inicio de
la actividad predecesora.
Inicio a Final. La finalización de la actividad sucesora depende del
inicio de la actividad predecesora.
El tipo de relación de precedencia final a inicio es el más comúnmente
utilizado por el método de diagramación por precedencia. La relación inicio
a final se usa esporádicamente, pero se incluye aquí para proporcionar una
lista completa de los tipos de relaciones de este método.
3.4.5 Determinación de Dependencias
Para definir la secuencia entre las actividades, se emplean tres tipos de
dependencias:
Dependencias obligatorias. Las dependencias obligatorias son
aquéllas requeridas por contrato,
a) o inherentes a la naturaleza del trabajo. El equipo del proyecto
determina qué dependencias son obligatorias durante el proceso
de establecimiento de la secuencia de las actividades. Las
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 44 de 141
Versión 3.2
dependencias obligatorias a menudo implican limitaciones físicas,
como en un proyecto de construcción, donde es imposible erigir la
superestructura hasta tanto no se construyan los cimientos;
b) o en un proyecto de electrónica, donde se debe construir el
prototipo antes de poder probarlo. A veces se utiliza la expresión
“lógica dura” para referirse a las dependencias obligatorias.
Dependencias discrecionales. El equipo del proyecto determina
qué dependencias son discrecionales durante el proceso de
establecimiento de la secuencia de las actividades. A veces, las
dependencias discrecionales se denominan lógica preferida, lógica
preferencial o lógica blanda. Las dependencias discrecionales se
establecen con base en el conocimiento de las mejores prácticas
dentro de un área de aplicación determinada o a algún aspecto poco
común del proyecto, donde se desea una secuencia específica,
aunque existan otras secuencias aceptables. Las dependencias
discrecionales deben documentarse totalmente, ya que pueden crear
valores arbitrarios de holgura total y pueden limitar las opciones
posteriores de planificación. Cuando se emplean técnicas de
ejecución rápida, estas dependencias discrecionales deben revisarse,
y debe considerarse su modificación o eliminación.
Dependencias externas. El equipo de dirección del proyecto
determina qué dependencias son externas durante el proceso de
establecimiento de la secuencia de las actividades. Las dependencias
externas implican una relación entre las actividades del proyecto y
aquéllas que no pertenecen al proyecto. Normalmente, estas
dependencias están fuera del control del equipo del proyecto. Por
ejemplo, la actividad de prueba en un proyecto de software puede
depender de la entrega del hardware por parte de una fuente
externa, o en el caso de un proyecto de construcción, puede ser
necesario realizar informes gubernamentales de evaluación del
impacto ambiental antes de iniciar la preparación del emplazamiento.
3.4.6 Aplicación de Adelantos y Retrasos
El equipo de dirección de proyecto determina las dependencias que pueden
necesitar un adelanto o un retraso para definir con exactitud la relación
lógica. No deben utilizarse adelantos y retrasos para sustituir la lógica de la
planificación. Deben documentarse las actividades y sus supuestos
relacionados.
Un adelanto permite una aceleración de la actividad sucesora. Por ejemplo,
en un proyecto para la construcción de un nuevo edificio de oficinas, puede
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 45 de 141
Versión 3.2
planificarse que el desmonte del terreno comience dos semanas antes de la
fecha programada para completar la lista de pendientes. Esto debe
mostrarse como una relación lógica final a inicio, con un adelanto de dos
semanas.
Un retraso ocasiona una demora en la actividad sucesora. Por ejemplo, un
equipo de redacción técnica puede comenzar a editar el borrador de un
documento extenso quince días después de haber comenzado a escribirlo.
Esto puede mostrarse como una relación lógica inicio a inicio con un retraso
de 15 días.
3.4.7 Plantillas de Red del Cronograma
Para acelerar la preparación de las redes de actividades del proyecto,
pueden emplearse plantillas normalizadas del diagrama de red del
cronograma del proyecto. Pueden abarcar un proyecto completo o sólo una
parte del mismo. Las partes de un diagrama de red del cronograma del
proyecto se denominan a menudo subred o fragmento de red. Las plantillas
de las subredes son especialmente útiles cuando un proyecto abarca varios
entregables idénticos o casi idénticos, como los pisos de un edificio alto de
oficinas, los estudios clínicos de un proyecto de investigación farmacológica,
los módulos de codificación de programas de un proyecto de software o la
fase de lanzamiento de un proyecto de desarrollo.
3.4.8 Análisis de la Red del Cronograma
El análisis de la red del cronograma es una técnica utilizada para generar el
cronograma del proyecto. Emplea diversas técnicas analíticas, tales como el
método de la ruta crítica, el método de la cadena crítica, el análisis “¿Qué
pasa si…?” y la nivelación de recursos, para calcular las fechas de inicio y
finalización tempranas y tardías para las partes no completadas de las
actividades del proyecto. Algunos caminos de red pueden tener puntos de
convergencia o divergencia de rutas que pueden identificarse y emplearse
en el análisis de compresión del cronograma o en otros análisis.
3.4.9 Método de la Ruta Crítica
El método de la ruta crítica calcula las fechas teóricas de inicio y finalización
tempranas y tardías para todas las actividades, sin considerar las
limitaciones de recursos, realizando un análisis que recorre hacia adelante y
hacia atrás toda la red del cronograma.
Las fechas de inicio y finalización tempranas y tardías resultantes no
constituyen necesariamente el cronograma, sino que más bien indican los
periodos dentro de los cuales pueden planificarse las actividades, teniendo
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 46 de 141
Versión 3.2
en cuenta las duraciones de las actividades, las relaciones lógicas, los
adelantos, los retrasos y otras restricciones conocidas.
Las fechas de inicio y finalización tempranas y tardías calculadas pueden ser
afectadas por la holgura total de la actividad que proporciona flexibilidad al
cronograma y cuyo valor puede ser positivo, negativo o nulo.
En cualquier camino de red, la flexibilidad del cronograma se mide por la
diferencia positiva entre las fechas tempranas y tardías, lo cual se conoce
como “holgura total”.
Las rutas críticas tienen una holgura total igual a cero o negativa y las
actividades del cronograma en una ruta crítica reciben el nombre de
“actividades críticas”.
Una ruta crítica se caracteriza normalmente por el hecho de que su holgura
total es igual a cero. Las redes pueden tener varias rutas casi críticas.
Puede ser necesario realizar ajustes a las duraciones de las actividades, a
sus relaciones lógicas, a los adelantos y a los retrasos, o a otras
restricciones del cronograma para lograr caminos de red con una holgura
total igual a cero o positiva.
Una vez que se ha calculado la holgura total de un camino de red, entonces
puede determinarse la holgura libre, que es la cantidad de tiempo que una
actividad puede retrasarse dentro de un camino de red, sin demorar la
fecha de inicio temprana de cualquier actividad sucesora inmediata dentro
de dicho camino de red.
3.4.10 Método de la Cadena Crítica
La cadena crítica es una técnica de análisis de la red del cronograma que
permite modificar el cronograma del proyecto para adaptarlo a los recursos
limitados. Inicialmente, el diagrama de red del cronograma del proyecto se
elabora mediante los estimados de la duración, con las dependencias
requeridas y las restricciones definidas como entradas.
Entonces se calcula la ruta crítica. Una vez que se ha identificado la ruta
crítica, se ingresa la disponibilidad de recursos y se determina el resultado
del cronograma con recursos limitados. A menudo, el cronograma
resultante presenta una ruta crítica modificada. La ruta crítica con
restricciones de recursos se conoce como cadena crítica.
El método de la cadena crítica agrega colchones de duración, que son
actividades del cronograma que no requieren trabajo y que se utilizan para
manejar la incertidumbre. Un colchón que se coloca al final de la cadena
crítica se conoce como colchón del proyecto y protege la fecha de
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 47 de 141
Versión 3.2
finalización objetivo contra cualquier retraso a lo largo de la cadena crítica.
Se colocan colchones adicionales, conocidos como colchones de
alimentación, en cada punto donde una cadena de tareas dependientes, que
está fuera de la cadena crítica, la alimenta. De este modo, los colchones de
alimentación protegen la cadena crítica contra retrasos a lo largo de las
cadenas de alimentación.
La dimensión de cada colchón debe tener en cuenta la incertidumbre en la
duración de la cadena de tareas dependientes que conducen a ese colchón.
Una vez que se han determinado las actividades del cronograma con
colchón, las actividades previstas se planifican en base a sus fechas posibles
de inicio y finalización programadas más tardías.
Consecuentemente, en lugar de gestionar la holgura total de los caminos de
red, el método de la cadena crítica se concentra en gestionar las duraciones
restantes de los colchones en función de las duraciones restantes de las
cadenas de tareas.
3.4.11 Nivelación de Recursos
La nivelación de recursos es una técnica de análisis de la red del
cronograma que se aplica a un cronograma que ya ha sido analizado por
medio del método de la ruta crítica.
La nivelación de recursos puede utilizarse cuando los recursos compartidos
o críticos necesarios sólo están disponibles en ciertos momentos o en
cantidades limitadas, o para mantener la utilización de recursos en un nivel
constante.
La nivelación de recursos es necesaria cuando los recursos han sido sobre
asignados, es decir, cuando un recurso se ha asignado a dos o más tareas
para el mismo periodo, o cuando los recursos compartidos o críticos
necesarios sólo están disponibles en ciertos periodos o en cantidades
limitadas. La nivelación de recursos provoca a menudo cambios en la ruta
crítica.
3.4.12 Análisis “¿Qué pasa si…?”
Éste es un análisis de la pregunta “¿Qué pasa si se produce la situación
representada por el escenario ‘X’?” Se realiza un análisis de la red del
cronograma, usando el cronograma para calcular los diferentes escenarios,
tales como un retraso en la entrega de un componente principal, la
prolongación de la duración de un diseño específico o la introducción de
factores externos, como una huelga o un cambio en el procedimiento para
la obtención de permisos.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 48 de 141
Versión 3.2
Los resultados del análisis del escenario “Qué pasa si…” pueden usarse para
evaluar la viabilidad del cronograma del proyecto bajo condiciones
adversas, y para preparar planes de contingencia y respuesta para superar
o mitigar el impacto de situaciones inesperadas.
La simulación implica calcular múltiples duraciones del proyecto a partir de
diferentes conjuntos de supuestos sobre las actividades. La técnica más
común es la del análisis Monte Carlo, en el cual se define una distribución
de duraciones posibles para cada actividad, que es usada para calcular una
distribución de posibles resultados para todo el proyecto.
3.4.13 Compresión del Cronograma
La compresión del cronograma reduce el calendario del proyecto sin
modificar el alcance del mismo, para cumplir con las restricciones del
cronograma, las fechas impuestas u otros objetivos del cronograma. Las
técnicas de compresión del cronograma incluyen:
Compresión. Una técnica de compresión del cronograma en la cual
se analizan las concesiones entre costo y cronograma para
determinar cómo obtener la mayor compresión con el menor
incremento de costo. Ejemplos de compresión pueden incluir la
aprobación de horas suplementarias, el aporte de recursos
adicionales o un pago adicional para acelerar la entrega de las
actividades que se encuentran en la ruta crítica. La compresión sólo
funciona para actividades en las que los recursos adicionales
permiten acortar la duración. La compresión no siempre resulta una
alternativa viable y puede ocasionar un incremento del riesgo y/o del
costo.
Ejecución rápida. Una técnica de compresión del cronograma en la
cual las fases o actividades que normalmente se realizarían en forma
secuencial, se realizan en paralelo. Un ejemplo de esto es la
construcción de los cimientos de un edificio antes de finalizar todos
los planos arquitectónicos. La ejecución rápida puede dar como
resultado un reproceso y un aumento del riesgo. La ejecución rápida
sólo funciona en actividades que pueden superponerse para acortar la
duración.
3.4.14 Estimación Análoga
La estimación de costos por analogía utiliza los valores de parámetros como
el alcance, el costo, el presupuesto y la duración, o medidas de escala tales
como el tamaño, el peso y la complejidad de un proyecto anterior similar,
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 49 de 141
Versión 3.2
como base para estimar el mismo parámetro o medida para un proyecto
actual.
Cuando se trata de estimar los costos, esta técnica utiliza el costo real de
proyectos similares anteriores como base para estimar el costo del proyecto
actual. Es un método de estimación del valor bruto, que a veces se ajusta
en función de diferencias conocidas en cuanto a la complejidad del
proyecto.
La estimación de costos por analogía se emplea frecuentemente para
estimar un parámetro cuando existe una cantidad limitada de información
detallada sobre el proyecto, como es el caso, por ejemplo, en sus fases
iniciales. La estimación de costos por analogía utiliza la información
histórica y el juicio de expertos.
Por lo general, la estimación de costos por analogía es menos costosa y
requiere menos tiempo que las otras técnicas, pero también es menos
exacta. Puede aplicarse a todo un proyecto o a partes del mismo, y puede
utilizarse en conjunto con otros métodos de estimación.
La estimación análoga es más confiable cuando el proyecto anterior es
similar, no sólo en apariencia sino en los hechos, y cuando los miembros del
equipo del proyecto responsables de efectuar las estimaciones poseen la
experiencia necesaria.
3.4.15 Estimación Paramétrica
La estimación paramétrica utiliza una relación estadística entre los datos
históricos y otras variables (p.e., metros cuadrados de construcción) para
calcular una estimación de parámetros de una actividad tales como costo,
presupuesto y duración.
Con esta técnica pueden lograrse niveles superiores de exactitud,
dependiendo de la sofisticación y de los datos que utilice el modelo. La
estimación paramétrica de costos puede aplicarse a todo un proyecto o a
partes del mismo, en conjunto con otros métodos de estimación.
3.4.16 Estimación Ascendente
La estimación ascendente es un método para estimar los componentes del
trabajo. El costo de cada paquete de trabajo o de cada actividad se calcula
con el mayor nivel de detalle. El costo detallado luego se resume o
“acumula” en niveles superiores para fines de información y seguimiento.
En general, la magnitud y complejidad de la actividad o del paquete de
trabajo individual influyen en el costo y la exactitud de la estimación
ascendente de costos.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 50 de 141
Versión 3.2
3.4.17 Estimación por Tres Valores
La exactitud de las estimaciones de costos de una actividad única puede
mejorarse tomando en consideración la incertidumbre y el riesgo. Este
concepto se originó con la Técnica de Revisión y Evaluación de Programas
(PERT). PERT utiliza tres estimados para definir un rango aproximado de
costo de una actividad:
• Más probable (cM). El costo de la actividad se basa en una
evaluación realista del esfuerzo necesario para el trabajo requerido y
cualquier gasto previsto.
• Optimista (cO). El costo de la actividad se basa en el análisis del
mejor escenario posible para esa actividad.
• Pesimista (cP). El costo de la actividad se basa en el análisis del
peor escenario posible para esa actividad.
El análisis según el método PERT calcula un costo Esperado (CE) de la
actividad utilizando un promedio ponderado de estas tres estimaciones:
cE = (cO + 4cM + cP) / 6
Las estimaciones de costos basadas en esta ecuación (o aun en un
promedio simple de los tres valores) pueden proporcionar una mayor
exactitud, y los tres valores aclaran el rango de incertidumbre de las
estimaciones de costos.
3.4.18 Análisis de Reserva
Las estimaciones de costos pueden incluir reservas para contingencias
(llamadas a veces asignaciones para contingencias) para tener en cuenta la
incertidumbre del costo. La reserva para contingencias puede ser un
porcentaje del costo estimado, una cantidad fija, o puede calcularse
utilizando métodos de análisis cuantitativos.
A medida que se dispone de información más precisa sobre el proyecto, la
reserva para contingencias puede utilizarse, reducirse o eliminarse. Debe
identificarse claramente esta contingencia en la documentación del
cronograma. Las reservas para contingencias forman parte de los requisitos
de financiamiento.
3.4.19 Análisis de Propuestas para Licitaciones
Los métodos de estimación de costos pueden incluir el análisis de cuánto
debe costar el proyecto, con base en las propuestas de proveedores
calificados.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 51 de 141
Versión 3.2
En los casos en los que los proyectos se otorgan mediante procesos
competitivos, se puede solicitar al equipo del proyecto un trabajo adicional
de estimación de costos para examinar el precio de los entregables
individuales y obtener un costo que sustente el costo total final del
proyecto.
3.4.20 Análisis Costo-Beneficio
Los principales beneficios de cumplir con los requisitos de calidad pueden
incluir un menor reproceso, una mayor productividad, menores costos y una
mayor satisfacción de los interesados. Un caso de negocio para cada
actividad de calidad permite comparar el costo del procedimiento de calidad
con el beneficio esperado.
3.4.21 Costo de la Calidad (COQ)
El costo de la calidad incluye todos los costos en los que se ha incurrido
durante la vida del producto en inversiones para prevenir el incumplimiento
de los requisitos, para evaluar la conformidad del producto o servicio con
los requisitos, y por no cumplir con los requisitos (reproceso). Los costos
por fallos se clasifican a menudo en internos (constatados por el equipo del
proyecto) y externos (constatados por el cliente). Los costos por fallos
también se denominan costo por calidad deficiente.
3.4.22 Diagramas de Control
Los diagramas de control se utilizan para determinar si un proceso es
estable o no, o si tiene un desempeño predecible. Los límites superior e
inferior de las especificaciones se basan en los requisitos del contrato.
Reflejan los valores máximo y mínimo permisibles.
Puede haber sanciones asociadas con el incumplimiento de los límites de las
especificaciones. El director del proyecto y los interesados apropiados
establecen los límites de control superior e inferior para reflejar los puntos
en los cuales deben implementarse acciones correctivas para evitar que se
sobrepasen los límites de las especificaciones.
Para procesos repetitivos, los límites de control se establecen por lo general
en ± 3σ. Un proceso se considera fuera de control cuando un punto de
datos excede un límite de control o cuando siete puntos consecutivos se
encuentran por encima o por debajo de la media.
Los diagramas de control pueden utilizarse para monitorear diferentes tipos
de variables de salida. Aunque se utilizan más frecuentemente para rastrear
actividades repetitivas tales como las relativas a la fabricación de lotes, los
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 52 de 141
Versión 3.2
diagramas de control también pueden usarse para monitorear las
variaciones del costo y del cronograma, la cantidad y frecuencia de los
cambios en el alcance, u otros resultados de gestión, para ayudar a
determinar si los procesos de dirección del proyecto se encuentran bajo
control.
3.4.23 Estudios Comparativos
Los estudios comparativos implican comparar prácticas reales o planificadas
del proyecto con las de proyectos comparables para identificar las mejores
prácticas, generar ideas de mejoras y proporcionar una base para la
medición del desempeño. Estos otros proyectos pueden estar dentro o fuera
de la organización ejecutante y pueden pertenecer a la misma área de
aplicación o a otra.
3.4.24 Diseño de Experimentos
El diseño de experimentos (DoE) es un método estadístico para identificar
qué factores pueden influir en variables específicas de un producto o
proceso en fase de desarrollo o de producción. El DoE debe emplearse
durante el proceso Planificar la Calidad para determinar la cantidad y el tipo
de pruebas por efectuar, así como su impacto en el costo de la calidad.
El DoE también juega un papel en la optimización de productos o procesos.
Puede utilizarse para reducir la sensibilidad del desempeño del producto a
las fuentes de variación causadas por diferencias ambientales o de
fabricación.
Un aspecto importante de esta técnica es que proporciona un marco
estadístico para cambiar sistemáticamente todos los factores importantes,
en lugar de cambiar un factor a la vez. El análisis de los datos
experimentales debería proporcionar las condiciones óptimas para el
producto o proceso, resaltar los factores que influyen en los resultados y
revelar la presencia de interacciones y sinergia entre los factores.
Por ejemplo, los diseñadores de automóviles emplean esta técnica para
determinar qué combinación de suspensión y neumáticos producirá las
mejores características de marcha a un costo razonable.
3.4.25 Muestreo Estadístico
El muestreo estadístico consiste en seleccionar una parte de la población de
interés para su inspección (por ejemplo, una selección al azar de diez
planos de ingeniería a partir de una lista de setenta y cinco planos). La
frecuencia y el tamaño de la muestra deben determinarse durante el
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 53 de 141
Versión 3.2
proceso Planificar la Calidad, de modo que el costo de la calidad incluya el
número de pruebas, los rechazos esperados, etc.
Existe un cuerpo sustancial de conocimientos sobre muestreo estadístico.
En algunas áreas de aplicación, puede ser necesario que el equipo de
dirección del proyecto esté familiarizado con diferentes técnicas de
muestreo para asegurarse de que la muestra seleccionada sea realmente
representativa de la población de interés.
3.4.26 Diagramas de Flujo
Un diagrama de flujo es una representación gráfica de un proceso que
muestra las relaciones entre las etapas del proceso. Existen muchos estilos
de diagramas de flujo, pero todos muestran las actividades, los puntos de
decisión y el orden de desarrollo del proceso.
Durante la planificación de la calidad, los diagramas de flujo pueden ayudar
al equipo del proyecto a anticipar problemas de calidad que pudieran
ocurrir. Tener consciencia de los problemas potenciales puede permitir el
desarrollo de procedimientos de prueba o métodos para abordarlos.
3.4.27 Metodologías Propietarias de Gestión de la Calidad
Existen numerosas metodologías propietarias, entre las que se incluyen, sin
pretender dar una lista exhaustiva o de recomendaciones, Six Sigma, Lean
Six Sigma, Despliegue de Funciones de Calidad (Quality Function
Deployment), CMMI®, etc.
3.4.28 Herramientas Adicionales de Planificación de
Calidad
A menudo se emplean otras herramientas de planificación de calidad para
ayudar a definir mejor los requisitos de calidad y a planificar actividades
eficaces de gestión de calidad. Éstas incluyen, entre otras:
• Tormenta de ideas
• Diagramas de afinidad, que se usan para identificar visualmente
los agrupamientos lógicos en base a relaciones naturales.
• Análisis de campos de fuerzas, que son diagramas de las fuerzas
a favor y en contra de un cambio.
• Técnicas de grupo nominal, que permiten que las ideas se analicen
en una tormenta de ideas en grupos pequeños y luego sean revisadas
por un grupo más amplio.
• Diagramas matriciales, que incluyen dos, tres o cuatro grupos de
información, y muestran las relaciones entre factores, causas y
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 54 de 141
Versión 3.2
objetivos. Los datos dentro de una matriz se organizan en filas y
columnas, con celdas de intersección que pueden completarse con
información que describe la relación demostrada entre los elementos
de la fila y los de la columna.
• Matrices de priorización, que brindan un modo de clasificar por
orden de importancia un conjunto de problemas diversos y/o
polémicas (identificados normalmente por medio de tormentas de
ideas).
3.4.29 Diagramas de Causa y Efecto
Los diagramas de causa y efecto, también conocidos como diagramas de
Ishikawa o diagramas de espina de pescado, ilustran la manera en que
diversos factores pueden estar vinculados con un problema o efecto
potencial. Una causa posible puede descubrirse preguntando continuamente
“¿por qué?” o “¿cómo?” a lo largo de una de las líneas. Los diagramas “por
qué-por qué” y “cómo-cómo” pueden utilizarse en el análisis causal. Los
diagramas de causa y efecto también pueden usarse en el análisis de
riesgos.
3.4.30 Diagramas de Control
En este proceso se recopilan y analizan los datos pertinentes para indicar el
estado de la calidad de los procesos y productos del proyecto. Los
diagramas de control ilustran la manera en que se comporta un proceso a lo
largo del tiempo y cuándo un proceso está sujeto a variación por una causa
especial, lo que crea una condición fuera de control.
Estos diagramas responden gráficamente a la pregunta: “¿La variación del
proceso se encuentra dentro de los límites aceptables?” El patrón de puntos
de datos en un diagrama de control puede revelar valores fluctuantes
aleatorios, saltos repentinos en el proceso o una tendencia gradual al
incremento de la variación. Por medio del monitoreo de las salidas de un
proceso a lo largo del tiempo, un diagrama de control puede ayudar a
evaluar si la aplicación de cambios a dicho proceso logró las mejoras
deseadas.
Cuando un proceso se encuentra dentro de los límites aceptables, significa
que está controlado y no requiere ajustes. Por el contrario, cuando un
proceso se encuentra fuera de los límites aceptables, entonces debe
ajustarse. Una sucesión de siete puntos consecutivos fuera de los límites de
control superior o inferior indica que el proceso está fuera de control.
Normalmente, los límites de control superior e inferior se fijan en ± 3σ,
siendo 1σ una desviación estándar.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 55 de 141
Versión 3.2
3.4.31 Histograma
Un histograma es un diagrama de barras verticales que ilustra la frecuencia
de ocurrencia de un estado particular de variación. Cada columna
representa un atributo o característica de un problema/ una situación. La
altura de cada columna representa la frecuencia relativa de la característica.
Esta herramienta ayuda a ilustrar la causa más común de los problemas en
un proceso por medio del número y las alturas relativas de las barras.
3.4.32 Diagrama de Pareto
Un diagrama de Pareto es un tipo específico de histograma, ordenado por
frecuencia de ocurrencia. Muestra cuántos defectos se generaron por tipo o
categoría de causa identificada. El ordenamiento por categoría se emplea
para guiar la acción correctiva. El equipo del proyecto debería atender en
primer lugar las causas que provocan el mayor número de defectos.
Los diagramas de Pareto están relacionados conceptualmente con la ley de
Pareto, que establece que un número relativamente pequeño de causas
provocará generalmente la mayoría de los problemas o defectos. Esto se
denomina comúnmente principio 80/20, donde el 80 por ciento de los
problemas se debe al 20 por ciento de las causas. Los diagramas de Pareto
también se pueden usar para resumir diversos tipos de datos y analizarlos
según el principio 80/20.
3.4.33 Diagrama de Comportamiento
De manera similar a un diagrama de control pero sin mostrar los límites, un
diagrama de comportamiento muestra el historial y el patrón de
variaciones. Un diagrama de comportamiento es una gráfica lineal que
muestra los puntos de datos trazados en el orden en que suceden. Los
diagramas de comportamiento muestran las tendencias, variaciones,
deterioros o mejoras de un proceso a lo largo del tiempo.
El análisis de tendencias se realiza mediante diagramas de comportamiento
e implica utilizar técnicas matemáticas para proyectar resultados futuros
basándose en resultados históricos. El análisis de tendencias se usa a
menudo para supervisar:
• El desempeño técnico. ¿Cuántos errores o defectos se han
identificado y cuántos permanecen sin corregir?
• El desempeño del costo y del cronograma. ¿Cuántas actividades se
completaron por periodo con variaciones significativas?
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 56 de 141
Versión 3.2
3.4.34 Diagrama de Dispersión
Un diagrama de dispersión, muestra la relación entre dos variables. Esta
herramienta permite al equipo de calidad estudiar e identificar la posible
relación entre los cambios observados en dos variables. Se trazan las
variables dependientes frente a las variables independientes. Mientras más
próximos se encuentren los puntos con respecto a una línea diagonal,
mayor será su relación.
3.4.35 Evaluación de Probabilidad e Impacto de los
Riesgos
Mediante esta evaluación se estudia la probabilidad de ocurrencia de cada
riesgo específico. La evaluación del impacto de los riesgos investiga el
efecto potencial de los mismos sobre un objetivo del proyecto, tal como el
cronograma, el costo, la calidad o el desempeño, incluidos tanto los efectos
negativos en el caso de las amenazas, como positivos, en el caso de las
oportunidades.
Para cada riesgo identificado, se evalúan la probabilidad y el impacto. Los
riesgos pueden evaluarse en entrevistas o reuniones con participantes
seleccionados por su familiaridad con las categorías de riesgo en la agenda.
Entre ellos, se incluyen los miembros del equipo del proyecto y, quizás,
expertos que no pertenecen al proyecto.
Durante estas entrevistas o reuniones, se evalúan el nivel de probabilidad
de cada riesgo y su impacto sobre cada objetivo del proyecto. También se
registran los detalles explicativos, incluidos los supuestos que justifican los
niveles asignados. Las probabilidades e impactos de los riesgos se califican
de acuerdo con las definiciones proporcionadas en el plan de gestión de
riesgos. Los riesgos con una baja calificación en cuanto a probabilidad e
impacto se incluirán en una lista de supervisión para su seguimiento futuro.
3.4.36 Matriz de Probabilidad e Impacto
Los riesgos pueden priorizarse para realizar un análisis cuantitativo
posterior y elaborar respuestas basadas en su calificación. Por lo general,
estas reglas de calificación de los riesgos son definidas por la organización
antes del inicio del proyecto y se incluyen en los activos de los procesos de
la organización.
Las reglas de calificación de los riesgos pueden adaptarse al proyecto
específico durante el proceso Planificar la Gestión de Riesgos.
Habitualmente, la evaluación de la importancia de cada riesgo y, por
consiguiente, de su prioridad de atención, se efectúa utilizando una tabla de
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 57 de 141
Versión 3.2
búsqueda o una matriz de probabilidad e impacto. Dicha matriz especifica
las combinaciones de probabilidad e impacto que llevan a calificar los
riesgos con una prioridad baja, moderada o alta. El área gris oscuro (con las
cifras más altas) representa un riesgo alto, el área gris intermedio (con las
cifras más bajas) representa un riesgo bajo y el área color gris claro (con
las cifras intermedias) representa el riesgo moderado.
Ilustrativo:
Impacto (escala relativa) sobre un objetivo (p.e., costo, tiempo, alcance o
calidad). Cada riesgo es calificado de acuerdo con su probabilidad de
ocurrencia y el impacto sobre un objetivo en caso de que ocurra. Los
umbrales de la organización para riesgos bajos, moderados o altos se
muestran en la matriz y determinan si el riesgo es calificado como alto,
moderado o bajo para ese objetivo.
Probabilidad Amenazas Oportunidades
0,90 0,05 0,09 0,18 0,36 0,72 0,72 0,36 0,18 0,09 0,05
0,70 0,04 0,07 0,14 0,28 0,56 0,56 0,28 0,14 0,07 0,04
0,50 0,03 0,05 0,10 0,20 0,40 0,40 0,20 0,10 0,05 0,03
0,30 0,02 0,03 0,06 0,12 0,24 0,24 0,12 0,06 0,03 0,02
0,10 0,01 0,01 0,02 0,04 0,08 0,08 0,04 0,02 0,01 0,01
0,05 0,10 0,20 0,40 0,80 0,80 0,40 0,20 0,10 0,05
Figura 3.1: Matriz de Probabilidad e Impacto
Como se ilustra en el Gráfico, una organización puede calificar un riesgo por
separado para cada objetivo (p.e., costo, tiempo y alcance). Además, puede
desarrollar formas de determinar una calificación general para cada riesgo.
Puede elaborarse un esquema de calificación para el proyecto global, con el
propósito de reflejar la preferencia de la organización por un objetivo
determinado sobre otros y la utilización de tales preferencias para proceder
a una ponderación de los riesgos evaluados para cada objetivo.
Finalmente, las oportunidades y las amenazas pueden manejarse en la
misma matriz, utilizando las definiciones de los diversos niveles de impacto
apropiados para cada una de ellas.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 58 de 141
Versión 3.2
La calificación de los riesgos ayuda a guiar las respuestas a los riesgos. Por
ejemplo, los riesgos que, si se concretan (amenazas), tienen un impacto
negativo sobre los objetivos, y que se encuentran en la zona de riesgo alto
(gris oscuro) de la matriz, pueden necesitar prioridad de acción y
estrategias de respuesta agresivas. Las amenazas en la zona de riesgo bajo
(gris intermedio) pueden no necesitar una acción de gestión proactiva, más
allá de ser incluidas en una lista de supervisión o de ser agregadas a una
reserva para contingencias.
De manera similar, debe darse prioridad a las oportunidades que se
encuentran en la zona de riesgo alto (gris oscuro), ya que pueden
obtenerse más fácilmente y proporcionan mayores beneficios. Las
oportunidades en la zona de riesgo bajo (gris medio) deben monitorearse.
Los valores proporcionados son representativos. El número de etapas en la
escala será determinado por la organización y depende de ella.
3.4.37 Evaluación de la Calidad de los Datos sobre
Riesgos
Para ser creíble, un análisis cualitativo de riesgos requiere datos exactos y
sin prejuicios. El análisis de la calidad de los datos sobre riesgos es una
técnica para evaluar el grado de utilidad de los datos sobre riesgos para su
gestión. Implica examinar el grado de entendimiento del riesgo y la
exactitud, calidad, fiabilidad e integridad de los datos relacionados con el
riesgo. Si la calidad de los datos es inaceptable, puede ser necesario
recopilar datos de mayor calidad.
3.4.38 Categorización de Riesgos
Los riesgos del proyecto pueden categorizarse por fuentes de riesgo (p.e.,
utilizando la RBS), por área del proyecto afectada (p.e., utilizando la EDT) u
otra categoría útil (p.e., fase del proyecto) para determinar qué áreas del
proyecto están más expuestas a los efectos de la incertidumbre. La
agrupación de los riesgos en función de sus causas comunes puede llevar al
desarrollo de respuestas efectivas a los riesgos.
3.4.39 Evaluación de la Urgencia de los Riesgos
Los riesgos que requieren respuestas a corto plazo pueden ser considerados
de atención más urgente. Los indicadores de prioridad pueden incluir el
tiempo para dar una respuesta a los riesgos, los síntomas y las señales de
advertencia, y la calificación del riesgo.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 59 de 141
Versión 3.2
En algunos análisis cualitativos, la evaluación de la urgencia de un riesgo
puede estar asociada con la calificación del riesgo, la cual se determina a
partir de la matriz de probabilidad e impacto para obtener una calificación
final de la severidad del riesgo.
3.4.40 Técnicas de Recopilación de Información
Algunos ejemplos de técnicas de recopilación de información utilizadas en la
identificación de riesgos son:
• Tormenta de ideas. La meta de la tormenta de ideas es obtener
una lista completa de los riesgos del proyecto. Por lo general, el
equipo del proyecto efectúa tormentas de ideas, a menudo con un
grupo multidisciplinario de expertos que no forman parte del equipo.
Bajo el liderazgo de un facilitador, se generan ideas acerca de los
riesgos del proyecto, ya sea por medio de una sesión tradicional y
abierta de tormenta de ideas, con ideas que aportan los
participantes, o en una sesión estructurada donde se utilizan técnicas
de entrevista masiva, tales como las técnicas de grupo nominal.
Como marco de referencia, pueden utilizarse categorías de riesgo,
tales como una Estructura de Desglose de Riesgos. Luego, los riesgos
son identificados y categorizados según su tipo, y sus definiciones
son refinadas.
• Técnica Delphi. La técnica Delphi es una manera de lograr un
consenso de expertos. Los expertos en riesgos del proyecto
participan en esta técnica de forma anónima. Un facilitador utiliza un
cuestionario para solicitar ideas acerca de los riesgos importantes del
proyecto. Las respuestas son resumidas y luego enviadas
nuevamente a los expertos para que realicen comentarios
adicionales. En pocas rondas, mediante este proceso se puede lograr
el consenso. La técnica Delphi ayuda a reducir la distorsión en los
datos y evita que cualquier persona ejerza influencias inapropiadas
en el resultado.
• Entrevistas. La realización de entrevistas a los participantes
experimentados del proyecto, a los interesados y a los expertos en la
materia puede ayudar a identificar los riesgos.
• Análisis causal. El análisis causal es una técnica específica para
identificar un problema, determinar las causas subyacentes que lo
ocasionan y desarrollar acciones preventivas.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 60 de 141
Versión 3.2
3.4.41 Análisis de las Listas de Control
Las listas de control para identificación de riesgos pueden desarrollarse
basándose en la información histórica y el conocimiento acumulado a partir
de proyectos similares anteriores y otras fuentes de información.
También puede utilizarse como lista de control de riesgos el nivel más bajo
de la estructura de desglose de riesgos. Si bien una lista de control puede
ser rápida y sencilla, es imposible elaborar una lista exhaustiva.
El equipo debe asegurarse de explorar elementos que no aparecen en la
lista de control. La lista de control debe revisarse durante el cierre del
proyecto para incorporar nuevas lecciones aprendidas y mejorarla para su
utilización en proyectos futuros.
3.4.42 Análisis de Supuestos
Cada proyecto y cada riesgo identificado se conciben y desarrollan tomando
como base un grupo de hipótesis, escenarios y supuestos. Este análisis
explora la validez de los supuestos según se aplican al proyecto. Identifica
los riesgos del proyecto debidos al carácter inexacto, inestable, incoherente
o incompleto de los supuestos.
3.4.43 Técnicas de Diagramación
Las técnicas de diagramación de riesgos pueden incluir:
• Diagramas de causa y efecto. Estos diagramas también se
conocen como diagramas de Ishikawa o diagramas de espina de
pescado y son útiles para identificar las causas de los riesgos.
• Diagramas de flujo o de sistemas. Estos diagramas muestran
cómo se interrelacionan los diferentes elementos de un sistema, y el
mecanismo de causalidad.
• Diagramas de influencias. Estos diagramas son representaciones
gráficas de situaciones que muestran las influencias causales, la
cronología de eventos y otras relaciones entre las variables y los
resultados.
3.4.44 Análisis SWOT (o DAFO, Debilidades, Amenazas,
Fortalezas y Oportunidades)
Esta técnica examina el proyecto desde cada uno de los aspectos DAFO
(debilidades, amenazas, fortalezas y oportunidades) para aumentar el
espectro de riesgos identificados, incluyendo los riesgos generados
internamente.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 61 de 141
Versión 3.2
La técnica comienza mediante la identificación de las fortalezas y
debilidades de la organización, enfocándose ya sea en la organización del
proyecto o bien en aspectos comerciales en un sentido más amplio.
A menudo, estos factores se identifican utilizando la tormenta de ideas. El
análisis DAFO identifica entonces cualquier oportunidad y amenaza para el
proyecto, procedentes respectivamente de las fortalezas y debilidades de la
organización.
El análisis DAFO también examina el grado en el que las fortalezas de la
organización contrarrestan las amenazas, y las oportunidades que pueden
servir para superar las debilidades.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 62 de 141
Versión 3.2
Capítulo 4
ORGANIZANDO EL HORIZONTE
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 63 de 141
Versión 3.2
4.1 Armonizando el trabajo | Implicancias tangibles
Los proyectos en entornos de alta incertidumbre tienen la particularidad de
que no se pueden definir todos los requisitos del proyecto desde el inicio
con la suficiente precisión como para poder cerrar alcance, recursos y
tiempo.
Por tanto se ha de optar por otras estrategias que permitan iniciar el
proyecto con información suficiente como para dimensionarlo y
caracterizarlo.
Los proyectos, tradicionalmente, se caracterizan mediante la definición de
tres variables fundamentales: alcance, costo y tiempo.
Alcance: conjunto de requisitos y entregables que se han de
satisfacer para dar por terminado un proyecto.
Tiempo: duración total del proyecto, tiempo requerido para cumplir
con el alcance teniendo en cuenta los recursos establecidos y la
naturaleza de los trabajos que hay que llevar a cabo.
Costo: recursos necesarios para cumplir con el alcance en el tiempo
determinado.
Esta tripla suele estar representada a través de la figura conocida por unos
como el “triángulo de hierro o férreo” y por otros por el “triángulo de oro o
áureo”, cuya representación gráfica mostramos a continuación:
Figura 4.1: Triángulo de Hierro
En el centro del triángulo, como se aprecia, aparece encubierta una variable
vital para considerar el éxito o el fracaso de un proyecto, y es la calidad. En
la medida en que las variables cambien su magnitud y el triángulo se
desvirtúe, la calidad se verá afectada.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 64 de 141
Versión 3.2
Hay diferencias notables entre el planteamiento tradicional y el enfoque ágil
respecto a la definición de estas variables. Tradicionalmente todo el
esfuerzo de planificación se hace al inicio del proyecto, con el objetivo de
obtener la mejor definición posible del alcance, de modo que se pueda
hacer un desglose de actividades realista para poder afinar al máximo en
las estimaciones de costo y tiempo.
Bien, en contextos de alta incertidumbre, donde aspiramos a resolver
problemas complejos, no es posible hacer una buena definición de alcance
inicial que permita proceder de este modo por dos razones fundamentales:
Al inicio no se dispone de la información necesaria para definir al
detalle el alcance.
Los cambios van a estar presentes durante todo el ciclo de vida del
proyecto.
Estamos hablando de proyectos en los que es más rentable comenzar a
trabajar y generar así la información necesaria para ir descubriendo el
alcance (enfoque empírico) que invertir ingentes cantidades de recursos y
tiempo para intentar resolver por completo el problema a priori (enfoque
predictivo).
Si en este escenario el trabajo no está dirigido por el alcance, ¿cómo
caracterizamos el proyecto? Las diferencias de enfoque entre el paradigma
tradicional y el ágil se muestran muy claras con el siguiente diagrama:
Figura 4.2: Enfoque tradicional vs Enfoque Ágil
Mientras que en el enfoque tradicional el esfuerzo inicial se centra en fijar el
alcance y a partir de ahí estimar el costo y el tiempo, en el enfoque ágil, se
trata al inicio de establecer un marco sobre costo y tiempo, y a partir de ahí
orientar los trabajos que se van a realizar en este marco siguiendo la
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 65 de 141
Versión 3.2
perspectiva del valor desde la óptica del cliente. A medida que el proyecto
avanza, se irá incrementando el valor del resultado generado de forma
incremental, buscando la implicación y la satisfacción del cliente desde los
albores del proyecto y proyectando una ejecución siempre guiada por el
objetivo de maximizar el ROI.
4.1.1 Planificación ágil
Nos enfrentamos a un proyecto complejo en un contexto donde la
incertidumbre es alta, donde hay multitud de variables en juego cuyos
comportamiento son impredecibles.
Planteemos los dos extremos:
a) No planificar nada
b) Invertir el esfuerzo necesario para lograr un “plan correcto”.
La primera opción deja el proyecto en un estado de deriva, en el que nunca
se tiene información suficiente como para tomar decisiones fundadas o
plantear algún tipo de previsión tal como “¿podemos tener listo el producto
para Abril?”. El trabajo del equipo estaría totalmente desenfocado y
difícilmente se satisfaría al cliente. Dejar de gobernar el barco no es un
opción válida para un profesional en dirección de proyectos.
La segunda opción implica invertir cantidades ingentes de tiempo y esfuerzo
que muy probablemente no se vean reflejados en un aumento de la
precisión en el plan. Sobre todo teniendo en cuenta que el número de
variables en un entorno de alta incertidumbre y el número de cambios que
pueden sufrir suponen un número de escenarios posibles cuyo coste de
estudio y control es inviable. Eso unido a que en un contexto de alta
incertidumbre, no existen los planes correctos.
4.1.2 Planificación vs Plan
Uno de cuatro puntos del manifiesto ágil dice:
“Valoramos más responder a los cambios que seguir un plan”
¿Quiere decir esto que planificar no sirve para nada? Vamos a citar a un
gran estratega:
“Los planes son inútiles, pero la planificación es indispensable”.
Dwight D. Eisenhower
El plan no es más que el resultado de la planificación. Pero tenemos que ser
conscientes que en un contexto de alta incertidumbre no sólo puede haber
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 66 de 141
Versión 3.2
cambios, sino que es completamente necesario que los haya, como
respuesta al nuevo conocimiento que se va generando. Por otro lado, la
labor de planificación es absolutamente indispensable, porque aunque el
plan varíe, se adquiere muchísimo conocimiento planificando, y este
conocimiento es tremendamente valioso para identificar riesgos, para
responder a los cambios o para enfrentarnos a imprevistos.
El hecho de que los cambios no sólo estén permitidos, sino que se
fomenten, es lo que hace idóneo este tipo de enfoque en esta clase de
proyectos.
Por tanto, dotemos al plan la importancia que merece. Es un instrumento
que nos servirá para guiarnos y para facilitarnos la comprensión del
proyecto y la toma de decisiones.
Y no es un documento cerrado. De hecho, los planes generados a partir de
una planificación ágil deben ser herramientas que se puedan cambiar
fácilmente, puesto que los cambios van a estar presentes durante toda la
vida del proyecto.
Por ello, la planificación es una actividad que no sólo se hace al inicio, sino
que se extiende a lo largo de la vida del proyecto.
En definitiva, la planificación ágil se caracteriza por:
Fomenta el cambio
Está focalizada más en la actividad de planificación que en el plan
No es una actividad que se haga sólo al inicio, sino que se extiende a
lo largo de todo el proyecto.
Se traduce en planes que se pueden cambiar fácilmente.
4.1.3 Objetivos de la planificación ágil
Bajo el enfoque ágil, la planificación no está dirigida por las tareas que hay
que llevar a cabo, sino por el valor que se le entrega al cliente.
Planificar significa encontrar la mejor solución a la pregunta ¿QUÉ queremos
hacer? Para responderla el equipo considerará funcionalidades, recursos y
tiempo, pero no podemos resolver esta cuestión completamente al principio
del proyecto.
El enfoque ágil plantea ir construyendo la solución de modo iterativo e
incremental, buscando los siguientes objetivos:
Reducir los riesgos
Reducir la incertidumbre
Apoyar una mejor toma de decisiones
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 67 de 141
Versión 3.2
Generar confianza
Compartir información y aprender de ella
4.1.3.1 Reducir riesgos
Planificar permite darnos cuenta de muchos de los riesgos asociados al
proyecto, lo que facilita tomar decisiones importantes desde fases
tempranas, como, por ejemplo, no seguir con el proyecto. Planificar saca a
la luz los posibles puntos negros del proyecto.
4.1.3.2 Reducir incertidumbre
A medida que el proyecto avanza, se genera nuevo conocimiento que
permite planificar y estimar mejor. Este nuevo conocimiento es utilizado en
cada iteración para mejorar el proceso de planificación y estimar cada vez
con mayor precisión.
El riesgo más importante en la mayoría de los proyectos es desarrollar un
producto incorrecto. A través de la planificación ágil este riesgo se reduce
drásticamente hasta prácticamente eliminarlo.
4.1.3.3 Apoyar una mejor toma de decisiones
Planificar y estimar implica poner sobre la mesa conocimiento para poder
tomar mejores decisiones. Como por ejemplo, decidir si comenzar o no un
proyecto, decidir entre dos proyectos, conocer QUÉ vamos a desarrollar y
CÓMO.
4.1.3.4 Generar confianza
Hacer cada vez estimaciones más realistas, esto genera confianza entre el
cliente y quienes desarrollan el producto. Y esta confianza hace que las
estimaciones sean cada vez más útiles para tomar mejores decisiones
respecto al proyecto.
4.1.3.5 Compartir información y aprender de ella
Permite al responsable del QUÉ y a los responsables del CÓMO compartir
información, negociar y aprender mutuamente. Permite establecer y
gestionar de forma efectiva las expectativas de ambas partes.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 68 de 141
Versión 3.2
4.1.4 Principios Armónicos
En el presente Tratado se plantea un marco de trabajo basado en la filosofía
ágil e inspirado en Scrum. Lo realmente importante para aplicar cualquier
marco de trabajo con éxito es comprender los principios que lo hacen
realmente efectivo. A continuación presentamos una nube de tags en la que
aparecen algunos de los principios más importantes que se ven
referenciados a lo largo de este Tratado de forma directa o indirecta y que
forman la base cultural necesaria para conseguir el alto rendimiento en
entornos de alta incertidumbre.
Figura 4.3: Principios Armónicos
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 69 de 141
Versión 3.2
4.1.5 Los Roles (Director del Proyecto, Gestor de
Expectativas y Gestor de la Ejecución)
La labor del Director del Proyecto ha sido tradicionalmente ingente para
dirigir y gestionar todos los aspectos del proyecto. Ha sido la luz y la
interfaz para todo y para todos. Pero ocuparse de todas las
responsabilidades hace que se desfocalice al no disponer por desgracia del
don de la ubicuidad. Este exceso de carga en las responsabilidades del
Director del Proyecto hace que en muchas ocasiones no pueda hacer lo que
tiene que hacer y está en la raíz del fracaso de muchos proyectos.
En otro orden de las cosas, hemos visto cómo para resolver problemas
complejos, la solución más efectiva la conforman los Sistemas Adaptativos
Complejos, cuyas características principales son: comunicación, confianza y
relaciones horizontales, y su capacidad más notable es la auto organización.
El Director del Proyecto en un entorno de alta incertidumbre tiene que
aprender a provocar esta auto organización. Tiene que fomentar que todos
y cada uno de los miembros del equipo de proyecto tengan
responsabilidades respecto de la gestión. Tiene que crear, mantener y
fomentar un ambiente en el que la interacción entre los miembros y entre
los interesados sea efectiva.
Por ello no recaerá en él todas las responsabilidades de decisión. El director
del proyecto se encargará de que el proceso funcione de la mejor forma
posible. Esto implica que debe actuar como facilitador, asegurando que se
llevan a cabo correctamente los procesos implicados en la gestión del
proyecto, favorecer el flujo de comunicación entre los miembros del Equipo,
facilitar la resolución de impedimentos y conflictos y procurar aumentar las
capacidades y habilidades del Equipo. Es decir; se aleja de la figura del líder
jerárquico para erigirse como un líder servicial, que está al frente del
proyecto y al servicio del resto del equipo.
El Director del Proyecto es de facto el director de orquesta del equipo. Para
potenciar que el equipo funcione en condiciones de alto rendimiento, sus
llamadas “habilidades blandas” para la gestión de personas tienen una
relevancia suprema. El Director del Proyecto tiene que actuar aquí no como
un líder jerárquico, sino como un líder servicial, que está al frente del
proyecto y al servicio del resto del equipo. Generar y mantener la confianza
es esencial en estos equipos de proyecto, puesto que el equipo trabaja
como una unidad.
4.1.5.1 Qué no hará un Director del Proyecto
Las principales responsabilidades que no recaerán sobre el Director del
Proyecto son las siguientes:
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 70 de 141
Versión 3.2
• Gestionar las comunicaciones con los interesados y gestionar sus
expectativas
• Decidir sobre QUÉ se quiere crear mediante el proyecto
• Decidir sobre CÓMO se va a ejecutar el proyecto.
• Ejecutar el proyecto.
Para llevar a cabo estas responsabilidades, aparecen dos roles
fundamentales que contribuirán a conseguir el alto rendimiento del equipo:
• Gestor de Expectativas.
• Gestores de Ejecución.
4.1.5.2 El Gestor de Expectativas
Es la persona responsable de gestionar las expectativas del cliente y el
resto de implicados externos. En el ámbito del proyecto, el Gestor de
Expectativas es la voz del cliente y es el único que puede decidir respecto a
QUÉ características del producto se van a crear.
Será el encargado de priorizar el trabajo. Él es el principal canal de
comunicación entre los Gestores de Ejecución y los interesados. De este
modo, la complejidad de las comunicaciones disminuye drásticamente.
4.1.5.3 Los Gestores de Ejecución
Son los miembros del equipo destinado a ejecutar el proyecto. Son los
únicos que pueden decidir sobre el plano del CÓMO, puestos que son ellos
los que tienen la responsabilidad de ejecutarlo. Por ello son gestores,
porque tienen la responsabilidad de gestionar el trabajo que deben llevar a
cabo.
Se recomienda que el número de Gestores de Ejecución esté entre 5 y 9.
Con menos de 5 se pierde capacidad y efectividad potencial y a partir de 9
comienza a crecer dramáticamente el esfuerzo de coordinación. Esto no
quiere decir que no se puedan rebasar estos límites, simplemente que entre
estos dos valores suelen darse los mejores resultados.
4.1.5.4 El Equipo del Proyecto
Por tanto, un equipo de proyecto contará con:
• Director del Proyecto
• Gestor de Expectativas
• Gestores de Ejecución
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 71 de 141
Versión 3.2
Figura 4.4: Equipo de Proyecto
4.1.6 Reuniones, ¿cuáles son y por qué tan pocas?
Uno de los principios armónicos más importante es la comunicación. Las
reuniones son vehículos para el intercambio de información y la generación
de conocimiento. Cuando hablamos de vehículos queremos hacer referencia
a que son un medio, no un fin por sí mismas.
El coste de las comunicaciones en la mayoría de proyectos tradicionales,
unido al coste del retrabajo provocado por una mala comunicación supone
en la mayoría de los casos graves problemas y en muchos de ellos, el
fracaso absoluto del proyecto. Es una fuente inagotable de desviaciones. Por
tanto, hay que prestar un especial cuidado a este factor.
Este marco de trabajo tiene las siguientes reuniones claves:
• Reunión de recopilación de requisitos
• Reunión de planificación inicial
• Reunión de planificación de fase
• Reunión diaria de sincronización
• Reunión de revisión del entregable
• Reunión de retrospectiva
Estos son los principales puntos de intercambio de información. Sus
duraciones y objetivos están definidos y todos los participantes conoces sus
responsabilidades en cada una de ellas.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 72 de 141
Versión 3.2
Son 6 tipos de reuniones. Pueden parecer pocas. Aquí la clave no está en el
número de tipos de reuniones que se llevan a cabo, sino que se hacen de
forma sistemática. Porque en este tipo de entornos, donde la incertidumbre
es alta, en el ámbito del proyecto no sólo se crea valor mediante la
ejecución del proyecto, sino que también se crea conocimiento, sobre el
QUÉ y sobre el CÓMO, y este conocimiento es un activo importante que
revierte de nuevo en el valor generado.
Lo que queremos provocar es que exista un intercambio sistemático de
conocimiento de modo que la incertidumbre en ambas dimensiones
disminuya. Y además queremos que esta transmisión de conocimiento esté
plenamente focalizada, reduciendo el riesgo de infoxicación (intoxicación
por exceso de información) por ambas partes (equipo e interesados).
4.1.7 Artefactos y herramientas | Mecánicas a aplicar
Si queremos dirigir y gestionar proyectos de forma ágil, las herramientas
que utilicemos deben ser herramientas ágiles, fáciles de usar, mantener y
gestionar.
Llamaremos artefactos a aquellos elementos conceptuales esenciales que
son necesarios para gestionar el proyecto. Llamaremos herramientas a los
elementos de gestión visual que nos facilitan la comprensión de la
información durante el proyecto.
Con este espíritu, vamos a centrarnos en este tratado en los artefactos y
herramientas necesarias para llevar a cabo esta labor. Esto no quiere decir
que se tengan que utilizar únicamente estas, simplemente que se han
demostrado útiles por sí mismas para llevar a buen puerto este tipo de
proyectos.
Los artefactos básicos son:
1. Pila del Producto
2. Pila de la Fase
Las herramientas básicas son
1. Panel de Tareas
2. Diagrama de quemado o burndown del proyecto.
3. Diagrama de quemado o burndown de la fase.
Vamos a detenernos en este punto a describir someramente los artefactos y
las dinámicas en las que están implicados. Las herramientas serán descritas
más adelante, en el momento en que hagamos uso de ellas.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 73 de 141
Versión 3.2
4.1.7.1 Pila del Producto
La Pila del Producto es una lista priorizada de elementos, cada uno de los
cuales representa una característica del producto que una vez
implementada proporciona valor al cliente. El Gestor de Expectativas es el
responsable de su contenido, priorización y disponibilidad.
La Pila del Producto es dinámica. El Gestor de Expectativas ha de
gestionarla y realizar los cambios necesarios para que en todo momento
represente qué necesita el producto para ser apropiado, competitivo y útil.
Es importante comprender que la Pila del Producto nunca está completa.
Comienza siendo una estimación inicial de requerimientos y a lo largo del
desarrollo incremental por fases, va evolucionado a medida que evoluciona
el producto, el entorno, y el conocimiento generado sobre ambos.
Por tanto no tiene porqué ser desechada al finalizar el proyecto. Puede que
el alcance del proyecto contemple la creación del producto y no su mejora
posterior. Por lo que tras su construcción inicial, el ciclo de vida del proyecto
llega a su fin, pero no el ciclo de vida del producto. La Pila del Producto
tiene sentido siempre que exista el producto, y trasciende la vida del
proyecto. Por lo tanto, tras el cierre del proyecto, la Pila del Producto puede
seguir siendo un instrumento útil. Esta es una de las razones por la que se
la prefiere llamar pila del producto y no del proyecto.
4.1.7.1.1 Estructura de la Pila del Producto
Los elementos de esta pila pueden tener diferentes formatos. No es
obligatorio optar por ninguno de ellos, lo que sí es conveniente es que sea
cual sea el formato elegido para representarlos, permita:
Actualizar la pila rápidamente
Facilitar su comprensión por parte del Gestor de Expectativas y de los
Gestores de Ejecución
Cada elemento de la pila del producto debe contener, al menos:
Descripción de la característica que representa
Representación del valor de negocio que tiene para el cliente
Estimación del coste necesario para desarrollarla
Representación del riesgo asociado al elemento
Un formato muy utilizado en equipos ágiles es el de historias de usuario. En
la sección Recopilando Requisitos del presente tratado, explicamos con
detalle esta técnica.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 74 de 141
Versión 3.2
4.1.8 Pila de la Fase
En la planificación de cada fase, los Gestores de Ejecución deben
determinar, en función de su capacidad, la lista de elementos de la Pila del
Producto que van a convertir durante la fase en un incremento de valor
entregable, siguiendo la prioridad marcada por el Gestor de Expectativas.
La Pila de la Fase es una lista de actividades o tareas que los Gestores de
Ejecución han de llevar a cabo para convertir el segmento de la Pila de
Producto que seleccionó para esa fase en un incremento de valor
entregable.
Es por tanto, un instrumento que guía el trabajo del equipo y que facilita su
focalización.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 75 de 141
Versión 3.2
4.2 Formalizando el inicio
El inicio del proyecto usualmente se formaliza a través de un documento
que firman todas las partes implicadas y que refleja los objetivos y
condicionantes del proyecto que se quiere iniciar. Es muy buena práctica
reflejar en un documento la visión del proyecto, y en el que se establece
una aproximación respecto al alcance, presupuesto y calendario.
Esto no significa cerrar el triángulo, simplemente poner por escrito las
intenciones de la parte cliente y la parte ejecutora de trabajar juntos para
llevar a cabo el proyecto.
Si ya se ha decidido quiénes asumirán los diferentes roles, es interesante
reflejarlo en el documento así como los poderes, responsabilidades y
obligaciones de cada uno de ellos.
También es interesante conocer diferentes opciones de contratación para
proyectos ágiles. En el Capítulo 7: Conocimiento Adicional ampliamos
información sobre este tipo de contratos.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 76 de 141
Versión 3.2
4.3 Identificando a los interesados
Lo primero que hay que decir sobre los interesados es que pueden ser
personas y organizaciones (como son los clientes, etc), todos aquellos que
estén involucrados de forma activa o cuyos intereses se vean afectados
positiva o negativamente por el proyecto. Ellos tienen un grado de
influencia sobre el proyecto y sobre los entregables.
Una labor importante del Gestor de Expectativas es identificar a los
interesados tanto internos como externos, para determinar los requisitos
del proyecto y las expectativas de todas las partes involucradas. Además,
deberá gestionar la influencia de los diversos interesados con relación a los
requisitos del proyecto, para asegurar el éxito del proyecto.
Es importante tener en cuenta que los interesados tienen diferentes niveles
de responsabilidad y autoridad cuando participan en un proyecto y éstos
pueden cambiar durante el ciclo de vida del mismo. Su responsabilidad y
autoridad pueden variar desde una participación ocasional hasta el apoyo
financiero y político.
Del mismo modo no hay que perder de vista que los interesados pueden
tener un impacto negativo en los objetivos del proyecto.
En cualquier caso, El Gestor de Expectativas debe identificar a los
interesados de forma continua.
Para cada uno de los interesados, el proyecto puede tener resultados tanto
positivos como negativos. Es obvio por tanto que para aquellos con
expectativas positivas, sus intereses serán mejor atendidos si contribuyen
al éxito del proyecto. Por contra, los de los interesados negativos se verán
mejor atendidos si impiden el avance del proyecto. Es un verdadero error
no tener en cuenta a los interesados negativos. Esto aumenta la
probabilidad de fracaso del proyecto.
A menudo los objetivos de los interesados son muy diferentes o
contradictorios. El Gestor de Expectativas debe balancear estos intereses y
asegurarse de que ser el canal por el que el equipo del proyecto interactúe
con los interesados de una manera profesional y cooperativa.
Por tanto, para el éxito del proyecto, resulta fundamental identificar a los
interesados desde sus inicios y analizar sus niveles de interés, expectativas,
importancia e influencia. El Gestor de Expectativas deberá elaborar una
estrategia para abordar a cada uno de ellos y determinar el nivel y el
momento de su participación, a fin de maximizar las influencias positivas y
reducir los impactos negativos potenciales. Como proceso sujeto a la
inspección y adaptación, la evaluación y la estrategia deben revisarse de
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 77 de 141
Versión 3.2
forma periódica durante la ejecución del proyecto para responder a los
continuos cambios.
Generalmente, el análisis de los interesados sigue los siguientes pasos:
1. Identificación de los principales interesados en el proyecto e
información relevante, como por ejemplo sus roles, departamentos,
intereses, niveles de conocimiento, expectativas y niveles de
influencia. Por lo general, resulta fácil identificar a los interesados
clave. Aquí debe imperar el sentido común. No tiene mucho sentido
que se pierdan ingentes cantidades de tiempo y energías
identificando a absolutamente todos aquellos que pueden verse
mínimamente afectados por el proyecto. El Gestor de Expectativas
debe hacer un esfuerzo de abstracción para identificar aquellos
verdaderamente claves y en cuya vigilancia y mantenimiento de la
relación merece la pena invertir tiempo y esfuerzo.
2. Identificación del impacto o apoyo potencial que cada interesado
podría generar, y su clasificación para definir la estrategia de
abordaje. Como comentamos anteriormente hay que priorizar a los
interesados clave a fin de garantizar el uso eficaz del esfuerzo para
comunicar y gestionar sus expectativas.
Una parte fundamental del trabajo que hay que realizar respecto a los
interesados, a lo largo del proyecto es gestionar las comunicaciones. El
Gestor de Expectativas debe determinar las necesidades de información de
los interesados en el proyecto para establecer un enfoque eficaz y eficiente;
es decir, suministrar únicamente la información necesaria, en el formato
adecuado, en el momento justo y con el impacto apropiado.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 78 de 141
Versión 3.2
4.4 Recopilando Requisitos
Nos encontramos en un contexto de alta incertidumbre, donde los requisitos
ni están definidos ni siquiera se pueden definir completamente al inicio,
porque el cliente y el resto de interesados necesitarán del nuevo
conocimiento que genere el proyecto para irlos descubriendo de forma
iterativa e incremental.
El proyecto en sus inicios parte de una visión. La visión es una idea, y el
mundo de las ideas se mueve, teniendo en cuenta el diagrama de
complejidad, en el área del caos. La misión del Gestor de Expectativas es
lograr reducir la incertidumbre en el eje del QUÉ de modo que el problema
se sitúe lo más cercano posible al área de lo complejo.
Es responsabilidad del Gestor de Expectativas gestionar las expectativas de
los interesados y procurar la máxima satisfacción del cliente. Para ello
deberá celebrar y pilotar reuniones con ellos para que emerjan sus
verdaderas necesidades y para priorizarlas.
4.4.1 Reunión de Recopilación de Requisitos | Construcción
de la Pila del Producto Inicial
4.4.1.1 Objetivos
Recopilar los requisitos del cliente y el resto de interesados en
términos de características que representen unidades que tiene valor
para ellos y representarlos en una pila priorizada.
Determinar las condiciones de satisfacción que supondrán el éxito de
la entrega de cada una de estas unidades de valor.
4.4.1.2 Participantes
Gestor de Expectativas: deberá llevar el peso de la reunión
aplicando su capacidad de comunicación, negociación, empatía,
análisis y síntesis para poder traducir las necesidades del cliente y el
resto de interesados a una pila priorizada de características que
representan valor.
Clientes: refiriéndonos a quiénes financian el proyecto y tienen el
mayor poder de decisión sobre el mismo.
Otros interesados: a quienes afecte el proyecto y/o puedan aportar
conocimiento sobre el valor del producto.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 79 de 141
Versión 3.2
4.4.1.3 Prerrequisitos
Es conveniente disponer de un espacio tranquilo, alejado de
interrupciones, donde los participantes puedan interactuar de forma
cómoda.
Es esencial utilizar herramientas visuales que ayuden a comunicar y,
sobre todo, que ayuden a pensar de manera colaborativa. Una
pizarra o un flipchart no debería faltar.
Para representar los diferentes elementos de la pila, es aconsejable
usar algún medio tangible y fácil de manipular, como por ejemplo,
fichas rayadas.
4.4.1.4 Organización
Un buen punto de inicio para esta reunión es asegurar que todos los
participantes comparten una misma visión del proyecto. Para ello es
conveniente escuchar todas las voces y llegar a un consenso que satisfaga a
todos. Es importante establecer este marco común para que todos los que
van a trabajar para definir el valor del producto remen en la misma
dirección y se eviten discusiones innecesarias por tener un norte final
diferente o ambiguo.
Esta visión compartida debe estar siempre presente. No tiene por qué ser
inamovible, podrá variar en función del conocimiento que se vaya
generando en la reunión, pero siempre deberá ser comprendida y apoyada
por los participantes.
Teniendo en cuenta la visión del proyecto, el Gestor de Expectativas debe
averiguar los objetivos de negocio que se pretenden conseguir, haciendo las
preguntas necesarias para llegar a las verdaderas necesidades. Es vitar
trascender de lo que los interesados quieren a priori y descubrir con ellos
qué es lo que realmente necesitan. La búsqueda de la causa raíz de sus
requerimientos permite despejar incertidumbre sobre el QUÉ y afinar mucho
más el concepto de valor.
El Gestor de Expectativas tiene que procurar siempre maximizar el ROI del
cliente en el proyecto. Identificar correctamente el valor de los
requerimientos es indispensable para lograrlo.
Durante la reunión, el Gestor de Expectativas debe ir guiando a los
participantes a concretar sus requerimientos en una lista priorizada por el
valor que les aporta. El nivel de detalle en este punto no es preciso, son
requisitos de alto nivel, pero el nivel de conocimiento generado debe ser el
suficiente como para caracterizar el proyecto.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 80 de 141
Versión 3.2
4.4.1.5 Técnicas
4.4.1.5.1 Historias de Usuario
4.4.1.5.1.1 Introducción
Las historias de usuario son elementos de definición de requisitos de
carácter informal y ligero, muy utilizada por los equipos ágiles, que lleva
asociada poca carga de documentación en virtud de un gran trabajo de
comunicación.
El concepto de usuario hace referencia a quien utilizará el producto, servicio
o resultado del proyecto. Y el concepto de historia se refiere a qué los
requisitos se toman en base a una necesidad, deseo u oportunidad que
tiene un contexto y un razonamiento, o lo que es lo mismo, que tiene su
historia.
Generalmente las historias de usuarios se escriben en fichas, tarjetas o
notas adhesivas. La ficha donde se escribe cada historia de usuario no es
representativa por sí misma; sólo es un recordatorio de la comunicación
establecida para definirla.
Con esto queremos decir que la historia no es únicamente el soporte físico,
sino todo el proceso comunicativo que representa, que es lo que, al fin y al
cabo, le dota de su alta eficacia como método de definición de requisitos.
Las historias de usuario evolucionan a medida que el proyecto avanza, y
potencian la colaboración.
Según Mike Cohn (2004) Una historia de usuario está compuesta, al menos,
por:
Una descripción escrita de la historia usada:
o Para planificar
o Como recordatorio
Conversaciones sobre la historia que sirven para profundizar en los
detalles de la historia.
Tests que transmiten y documentan los detalles de la historia y que
pueden ser usados para determinar cuándo una historia está
completa.
Según Jeffries (2001), debido a que normalmente las historias se escriben
a mano sobre una tarjeta, llama a estos tres aspectos:
Tarjeta: es el soporte físico donde se escribe cada historia.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 81 de 141
Versión 3.2
Conversación: es el proceso de comunicación necesario para definir
cada historia y del que la tarjeta no es más que un mero
recordatorio.
Confirmación: condiciones cuya satisfacción hace que la historia se
considere como terminada.
Son las tres claves de esta técnica, donde la tarjeta es la parte más
tangible, pero no la más importante.
4.4.1.5.1.2 ¿Cómo se escribe una historia de usuario?
La técnica no tiene asociada un formato específico, pero muchos autores,
entre los que nos incluimos, prefieren utilizar, siempre que se pueda, un
patrón como el siguiente:
Como [ROL] quiero [REQUISITO] para [BENEFICIO].
El objeto de esta plantilla es “forzar” que se responda explícitamente a tres
preguntas claves:
¿QUÉ es lo que se quiere? EXPECTATIVAS
¿Cuál es el beneficio que se consigue? VALOR
¿A QUIÉN/ES beneficia? INTERESADO/S
Ahora bien, como siempre, debe imperar el sentido común. No es necesario
que todas las historias se escriban con este patrón, sólo queremos poner de
manifiesto que el uso del mismo aporta valor en la mayoría de los casos.
Vamos a profundizar en estos aspectos:
4.4.1.5.1.3 Rol
En no pocos proyectos se crean características del producto final que
resultan no beneficiar a nadie y al final no son utilizadas o quedan relegadas
al ostracismo. Con la declaración explícita de A QUIÉN beneficia la historia
se pretende evitar este tipo de situaciones.
4.4.1.5.1.4 Requisito
Esto es el QUÉ, lo que el beneficiario de la historia desea que se desarrolle.
En la tarjeta aparecerá una descripción mínima que permita recordar la
conversación mantenida. En muchos proyectos, se crean características de
más, porque se entiende que el producto así está “más completo” o es
“mejor”, olvidando que ese tipo de valoraciones ha de hacerlas quienes
reciben el valor, no quienes lo crean.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 82 de 141
Versión 3.2
4.4.1.5.1.5 Beneficio
Hemos dicho que en este contexto, la ejecución estará dirigida por valor. El
beneficio es la razón, la causa, la necesidad, la oportunidad que da sentido
a la ejecución de la historia. Es la justificación de la misma. Esto obliga a
que cuando se están definiendo las historias de usuario explícitamente han
de clarificarse las razones por la que se quiere desarrollar tal o cual
característica, obligando a especificarlas y a debatirlas. Este debate puede
derivar en muchas ocasiones, gracias al conocimiento que el propio debate
genera, a rechazar historias o a incluir otras nuevas.
4.4.1.5.1.6 Formato de tarjeta
Generalmente el soporte más utilizado para crear y manejar las historias
de usuario es el de tarjeta, usualmente, fichas rayadas, aunque el formato
de la tarjeta no es relevante. Eso sí, debe facilitar su manipulación.
Además de la descripción de la historia, en la ficha suele aparecer la
siguiente información:
Un título: que sirva para darle entidad a la historia y poder
referenciarla de forma breve, sin entrar en detalles.
Estimación de Coste: asignación del esfuerzo necesario para
desarrollar la historia de usuario. Normalmente se utilizan “Puntos de
Historia” (véase Estimando Recursos y Calculando Costes).
Valor o Prioridad: un campo utilizado para establecer qué lugar de
la Pila de Producto le corresponde a la historia en cuestión. Hay
quienes prefieren estimar cuantitativamente el valor y que la cifra de
prioridad sea el cociente entre Valor / Coste, lo que informalmente
llamamos ROI. Otros prefieren directamente señalar una cifra de
prioridad, teniendo en cuenta la estimación de coste, sin realizar
operaciones matemáticas adicionales. Existe la posibilidad de utilizar
escalas determinadas (como potencias de 2 o fibonacci) pero vale con
asignar valores mayores a las historias más prioritarias, donde, por
ejemplo, una historia de 60 es más prioritaria que otra de 50.
Pruebas de aceptación: han de aparecer todas las condiciones que
se han de cumplir para considerar que una historia está acabada.
Esto servirá de recordatorio al Equipo para saber cuándo debe dejar
de trabajar en ella y también al Líder del Producto, a la hora de
comprobar que la historia está correcta.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 83 de 141
Versión 3.2
Figura 4.5: Ejemplo de Ficha de Historia de Usuario
4.4.1.5.1.7 Características que deben tener
Una buena historia de usuario debe tener las siguientes seis características,
como bien apunta Bill Wake (2003a):
Independiente
Negociable
Evaluable
Estimable
Pequeña
Testeable
El citado autor propuso el acrónimo INVEST atendiendo a las iniciales de
estas palabras en inglés.
4.4.1.5.1.8 Independiente
Hay que procurar que las historias tengan entre ellas las menores
dependencias posibles para evitar problemas a la hora de planificar y
priorizar.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 84 de 141
Versión 3.2
4.4.1.5.1.9 Negociable
Esto quiere decir que la tarjeta no es un contrato inamovible, sino que
representa una conversación previa y que requerirá de otras conversaciones
a medida que avanza su ejecución para hablar sobre detalles y dudas que
vayan surgiendo.
4.4.1.5.1.10 Evaluable
Una historia representa algo que tiene valor para los interesados, por tanto,
una vez desarrollada debe ser evaluable por ellos.
Hay que tener en cuenta que en la mayoría de proyectos hay trabajos que
no son visibles para los interesados y que por tanto, no pueden evaluar,
pero que son necesarios, a veces indispensables.
Por ejemplo, el diseño de una base de datos, en un software. ¿Quiere decir
que hay que evitar realizar estos trabajos? No. La idea es que estos formen
parte de una historia que tenga como objetivo final algo que los interesados
puedan evaluar.
Vamos a explicarlo con un ejemplo: en el desarrollo de software, la base de
datos normalmente es algo absolutamente opaco para los interesados. No
pueden evaluar el diseño de la base de datos si no tienen conocimiento
específico sobre bases de datos y buscan un diseño particular y específico.
Pero normalmente los interesados no están al tanto, ni necesitan estarlo, de
estos detalles. ¿Quiere decir esto que hay que renunciar a la base de datos?
No. Significa que habrá que ir metiéndole mano en la medida en que lo
vayamos necesitando porque sea indispensable para satisfacer un requisito
que sí aporta valor para el cliente.
Por ejemplo, el cliente quiere el software pueda dar de alta un usuario en el
sistema. Esto implica que hay que crear la base de datos y que hay que
realizar las consultas precisas para llevarlas a cabo. Pero lo que evalúa el
cliente no es la base de datos en sí, sino que el programa sea capaz de
crear un usuario.
Esto representa un cambio de paradigma importante, que separa
sustancialmente el QUÉ del CÓMO, y que ilustra la importancia de las
figuras diferenciadas del Gestor de Expectativas y de los Gestores de
Ejecución.
Seguramente, desde el punto de vista del equipo, la base de datos está
muy bien hecha, es eficiente y su cota de calidad técnica es superlativa.
Pero nada de esto tiene ninguna importancia si no se reflejado en VALOR
para el cliente y el resto de interesados.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 85 de 141
Versión 3.2
4.4.1.5.1.11 Estimable
La historia de usuario se ha de poder estimar. Hay tres razones por las que
una historia puede no ser estimable por los Gestores de Ejecución:
Falta conocimiento respecto al problema.
Habrá que reducir la incertidumbre hablando con el Gestor de
Expectativas.
Faltan conocimientos técnicos respecto a la solución.
Habrá que reservar unos recursos determinados para que
alguno/s de los Gestores de Ejecución adquiera/n los
conocimientos necesarios para estimarla.
Es demasiado grande.
Habrá que dividirla en historias que sean más sencillas de
estimar.
4.4.1.5.1.12 Pequeña
Una historia debe ser concreta, con un tamaño suficiente para ser estimada
y usada para planificar y priorizar. Las historias grandes se denominan
épicas o epopeyas. Pueden admitirse cuando están situadas debajo de la
Pila del Producto. Pero cuando emergen y han de ser resueltas, hay que
dividirlas en historias más manejables y estimarlas convenientemente. Por
el contrario, si una historia es demasiado pequeña no merece la pena
siquiera el esfuerzo de estimarla. Es mucho más útil fusionar varias
historias de este tipo en una con entidad suficiente para ser procesada.
4.4.1.5.1.13 Testeable
Las historias han de poder probarse que están correctamente desarrolladas.
Esto es fundamental por varias razones: por un lado, para que los Gestores
de Ejecución sepan cuándo el desarrollo de una historia ha finalizado y por
otro lado, para que el Gestor de Expectativas pueda probar que
efectivamente se satisfacen los requisitos representados por la historia.
4.4.1.5.2 Temas e Historias Épicas
A la hora de construir y evolucionar la Pila del Producto, no todos los
elementos de la pila tienen que estar definidos al detalle. Hay dos tipos de
elementos que pueden existir en la Pila del Producto y que no cumplen con
las características de Historia de Usuario: los temas y las historias épicas.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 86 de 141
Versión 3.2
4.4.1.5.2.1 Tema
Se denomina tema al elemento de la pila sobre el cual no se ha reducido la
incertidumbre lo suficiente como para estar detallado, por ser poco
prioritario en ese punto de la ejecución. Por ejemplo: “Módulo de
informes”. Es útil conocer que más adelante se ha de realizar un módulo
de informes, pero no es útil invertir más esfuerzos en intentar desgranar
este módulo porque en el momento actual no es prioritario y porque en
función del conocimiento generado durante el proyecto, la definición de este
elemento puede variar drásticamente.
Por tanto, este elemento se desgranará en el “último momento
responsable”; es decir, cuando se pueda obtener la máxima precisión con
el mínimo coste.
4.4.1.5.2.2 Historia Épica
Se denomina historia épica al elemento de la pila que aunque se ha
concretado y discutido sobre ello, es demasiado grande como ser
considerado una Historia de Usuario. Por ejemplo: “gestión de
proveedores”.
4.4.1.6 Mapa de Historias de Usuario
Esta técnica es muy utilizada para facilitar la construcción de la Pila del
Producto utilizando Historias de Usuario. En lugar de plantear de inicio una
estructura lineal de pila, se crea, a medida que se va conversando y van
emergiendo las diferentes historias de usuario, un mapa bidimensional que
aporta una mayor información sobre las necesidades y requerimientos de
los interesados, enriquece la discusión y ayuda a priorizar.
La idea principal de la técnica es aprovechar todo el conocimiento generado
a través de las reuniones de planificación plasmándolo en una estructura
que permita situar a cada historia en su contexto de interrelación con las
demás historias. Al usar pilas planas, esta información adicional se pierde,
al menos, de forma explícita.
El Mapa de Historias de Usuario es una técnica visual basada en una
herramienta para pensar y facilita el no perderle la pista a cada historia
dentro del contexto del proyecto.
En el proceso de creación del Mapa de Historias de Usuario se establecen
básicamente dos niveles conceptuales:
Grupo de Actividades: que son historias épicas, de gran dimensión,
que representan grandes cosas que hay que hacer. Normalmente
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 87 de 141
Versión 3.2
constan de varios pasos y no siempre se puede determinar su flujo.
Por ejemplo: “gestionar clientes” podría ser una actividad.
Tareas de Usuario: representan acciones concretas que deberán
poder llevarse a cabo para cumplir un objetivo específico. Cumplen la
definición de Historia de Usuario que comentamos anteriormente. Por
ejemplo: “crear una ficha de cliente” podría ser una tarea de usuario.
4.4.1.6.1 Creación de una Pila de Producto utilizando un Mapa de
Historias de Usuario
Visualicemos el proyecto como una gran historia, que debe ser contada por
los que en este contexto llamamos “usuarios”; aquellos que van a
interactuar con el producto y van a proporcionar feedback.
Lo primero que tenemos que hacer es pensar en alto nivel. ¿Qué actividades
o grupo de características de alto nivel son necesarias para cumplir con los
objetivos del proyecto?
Una vez se tienen más o menos claras se comienza a construir el mapa.
Consideremos dos ejes: el horizontal simboliza la secuencia en la que se
necesitarán o se usarán las características del producto (se puede
considerar también como una línea temporal) y la vertical hace referencia a
la prioridad de las tareas de usuario.
Una vez hecho esto se dispone el grupo de tareas sobre el eje horizontal,
siguiendo la secuencia de uso / necesidad.
Figura 4.6: Comenzando a crear el Mapa de Historias de Usuario
Una vez están definidas, es hora de pensar en términos de funcionalidades
o características concretas que son necesarias para determinar cada
actividad. Lo ideal es colocar estas características bajo las actividades en
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 88 de 141
Versión 3.2
orden de importancia o criticidad. Si son tareas alternativas, se pone una
bajo la otra dependiendo de su prioridad. Si son tareas consecutivas, se
pone una a la derecha de la otra.
Figura 4.7: Mapa de Historias de Usuario
Construyendo el mapa de este modo, obtenemos una información visual del
proyecto muy interesante.
En primer lugar, permite la identificación de partes del producto que no se
han considerado. Imaginemos que queremos diseñar un avión. Viendo el
mapa podríamos ver fácilmente si falta algún componente principal, como
las alas.
Otra ventaja importante de utilizar esta disposición es que identifica
explícitamente la parte mínima de puede tener valor de mercado. La
primera fila se corresponde con lo absolutamente indispensable. Es lo que
Alistair Cockburn llama walking skeleton o esqueleto andante; la parte
mínima de funcionalidad que dota de valor real al producto. Todavía le
faltan detalles (músculos, tendones, piel…) pero la parte fundamental la
forma este conjunto de características.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 89 de 141
Versión 3.2
Figura 4.8: Walking Skeleton
Además, esta disposición de historias ayuda a decidir para proyectos que
admitan varios lanzamientos o releases qué características formarán parte
de las diferentes releases. Es decir, es una herramienta que permite
determinar el alcance.
Figura 4.9: Determinación de las diferentes releases
La Pila del Producto del proyecto (o de cada release) se forma leyendo de
izquierda a derecha y de arriba abajo las historias dispuestas en el mapa.
Se recomienda mantener el mapa siempre visible para que la disposición
plana de la pila no pierda la información valiosa generada al construir esta
herramienta.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 90 de 141
Versión 3.2
4.4.1.6.2 Ventajas de los Mapas de Historias de Usuario
En resumen, el uso de los Mapas de Historias de Usuario proporciona las
siguientes ventajas:
Hace visible la cadena de valor del proyecto
Muestra las relaciones existentes entre historias
Ayuda a verificar el grado de completitud de la Pila del Producto.
Provee un contexto útil para la priorización.
Permite dividir el proyecto en diferentes capas completas y
evaluables de funcionalidad, de modo que de una forma visual se
pueda ver qué entra en el presente proyecto y qué es potencialmente
entregable en sucesivos proyectos.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 91 de 141
Versión 3.2
4.5 Estimando Recursos y Calculando Costes
La piedra angular de la planificación es la estimación. Estimar es en esencia
tratar de imaginar qué va a pasar en el futuro. Pero la precisión de la
estimación no es, en general, proporcional al esfuerzo que se invierte en
estimar. Mike Cohn, en base a su experiencia y a la de otros colegas,
sostiene que la relación entre el esfuerzo invertido en estimar y la precisión
obtenida tiene un comportamiento similar a esta curva:
Figura 4.10: Relación Esfuerzo - Precisión a la hora de estimar
Y señala dos claves importantes:
Independientemente del esfuerzo que se invierta en estimar:
Nunca se conseguirá un 100% de precisión.
Una estimación no es más que una estimación.
Las estimaciones fallan la mayoría de las veces, sobre todo al inicio de los
proyectos y esto se produce porque las estimaciones, por definición, son
mediciones imaginarias, no reales.
Si fuera viable medir, no sería necesario estimar. Y no podemos aspirar al
100% de precisión, mucho menos en proyectos complejos, donde el cambio
de las variables implicadas cambia continuamente el tablero de juego.
El enfoque que vamos a seguir es estimar lo indispensable para poder
avanzar, y como parte fundamental en la planificación, se hará no sólo al
inicio, sino durante la vida del proyecto.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 92 de 141
Versión 3.2
A estimar se aprende estimando. La precisión de las estimaciones será
tanto mayor a medida que el proyecto avance y se obtenga más
información sobre las características del producto, del entorno y de la forma
de trabajar del propio equipo.
4.5.1 Estimación Relativa
Tradicionalmente las estimaciones se han venido haciendo utilizando
medidas de estimación absolutas basadas en el tiempo, como hombre / día.
Pone el foco de la estimación en la capacidad de quienes han de ejecutar el
elemento de la pila.
Sin embargo esta magnitud no deja de ser una falacia, entendiendo que dos
personas no tienen el mismo rendimiento al día. Más aun, la misma
persona, dos días diferentes, puede que no alcance el mismo rendimiento.
Por otro lado, se presupone que esa persona trabaja el día completo en el
proyecto, cosa que puede no ser cierto, y obliga a realizar cálculos de ajuste
para afinar la estimación.
Por ello, preferimos utilizar una medida relativa basada en el esfuerzo,
tamaño o complejidad, como son los puntos imaginarios, también llamados
“Puntos de Historia”.
4.5.1.1 Puntos imaginarios o “Puntos de Historia”
En un entorno de alta incertidumbre, generalmente se prefiere estimar la
complejidad de los elementos de la pila en puntos imaginarios, también
llamados “puntos de historia”. Son medidas subjetivas y propias de cada
equipo y cada proyecto.
Pone el foco de la estimación en el elemento de la pila (o historia) que se
quiere resolver, por lo tanto es independiente del número de personas del
equipo o de su rendimiento.
Además, nos facilitará el control del cronograma además de establecer una
métrica para evaluar la capacidad del equipo (la velocidad), como veremos
más adelante.
Generalmente se utilizan escalas para determinar la complejidad de un
elemento de la pila, como pueden ser las de potencias de 2.
En el presente tratado, para explicar lo relativo a estimaciones, utilizaremos
la serie de Fibonacci simplificada:
0, 1, 2, 3, 5, 8, 13, 20, 40, 100
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 93 de 141
Versión 3.2
4.5.2 Técnicas de Estimación
4.5.2.1 Juicio de Expertos
Una persona experta, en base a su bagaje, puede dar una estimación
fundada. Sin embargo, su criterio tiene mucho más peso en un proyecto
tradicional que un proyecto ágil debido a que en primer escenario las
estimaciones se realizan sobre actividades y por el contrario, aquí se
estiman características orientadas al valor del cliente, que en esencia
contendrán múltiples actividades que requieren diversos perfiles para
componer una estimación fundada, en lugar de la opinión de una sola
persona.
4.5.2.2 Analogía
Otra técnica de estimación es hacer analogías con elementos de la Pila ya
entregados. Comparaciones como “el tamaño de este elemento es como el
de los anteriores juntos” pueden servir para dar una estimación con
fundamento en base al conocimiento que ya se ha generado con
anterioridad.
4.5.2.3 División
Esta es la aplicación de “divide y vencerás”. Si un elemento es demasiado
grande o demasiado complejo como para dar una estimación satisfactoria,
entonces es conveniente dividir esa elemento en otros más pequeñas y más
fáciles de estimar.
No es lo mismo hacer la siguiente analogía: “este elemento es dos veces
este otro elemento”, a decir: “este elemento es cuarenta veces esta otro
elemento”. Seguramente con tal tamaño requerirá ser dividido para poder
estimarla correctamente.
4.5.2.4 Planning Poker
El Planning Poker es una técnica de estimación propuesta por Grenning
(2002) cuyo uso es generalizado en los equipos ágiles, básicamente por dos
razones:
Es efectiva
Es divertida
Combina las tres técnicas explicadas anteriormente:
Juicio de Expertos
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 94 de 141
Versión 3.2
Analogía
División
Deben participar los tres roles de gestión que integran el Equipo de
Proyecto:
Director del Proyecto
Gestor de Expectativas
Gestores de Ejecución
El objetivo fundamental del Planning Poker no es predecir el futuro con el
máximo de precisión. Ya hemos dicho que eso es imposible en este
contexto.
el objetivo es obtener la mejor estimación con el mínimo esfuerzo
Es importante que en el Planning Poker participen todos Gestores de
Ejecución, que representen todos los posibles perfiles que colaborarán en la
ejecución del proyecto para poder obtener una visión global de la
complejidad de lo que se desea hacer.
Cada miembro del Equipo dispone de un juego de cartas. Cada carta tiene
dibujado un número que representa una posible estimación. Como
anunciamos anteriormente, utilizaremos la serie de fibonacci simplificada:
0, 1, 2, 3, 5, 8, 13, 20, 40, 100
Además se suelen añadir dos cartas adicionales:
? : esta carta representa que no se ha comprendido bien el elemento
que se quiere estimar.
café: esta carta sugiere que se debería de tomar un breve receso
para reponer fuerzas.
Antes de explicar la dinámica es importante conocer por qué funciona:
Permite obtener muchas opiniones de expertos de las diferentes
disciplinas implicadas en el proyecto. El conocimiento generado
durante las conversaciones es muy valioso para reducir la
incertidumbre acerca del elemento en cuestión.
Los Gestores de Ejecución deben justificar sus estimaciones. Esto
fomenta que se generen y se aporten diferentes puntos de vista y
que las estimaciones se mejoren de forma incremental y fundada.
Es divertido.
La dinámica del Planning Poker es muy sencilla. Una persona debe actuar
como moderador. Puede ser cualquier miembro del equipo, aunque es
aconsejable que sea el Director del Proyecto. No tiene asociado ningún
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 95 de 141
Versión 3.2
privilegio especial, simplemente será el que presente cada elemento de la
pila para iniciar el debate.
Se comienza a trabajar con la Pila del Producto priorizada, comenzando por
el primer elemento. El moderador lee su descripción. Los Gestores de
Ejecución hacen preguntas al Gestor de Expectativas, y éste la responde,
con el objetivo de ir reduciendo la incertidumbre sobre el QUÉ.
Cuando se han respondido todas las preguntas, cada Gestor de Ejecución
elige la carta que representa la estimación que él considera oportuna, pero
no debe ser visible por el resto aun. En el momento en el que todos ya han
elegido la suya, el moderador insta a que todos muestren sus cartas a la
vez.
Es importante que esto se haga así para asegurar que ninguna estimación
se ve influida previamente por la estimación de otros. Hay que tener en
cuenta que en el equipo puede haber gente con más o menos experiencia o
con más o menos seguridad en sí mismo. Se debe dar la oportunidad por
tanto, de opinar sin interferencias.
Normalmente, y de forma aconsejable, sobre la mesa habrá estimaciones
muy diferentes. Los dos extremos (quien haya hecho la estimación más
baja y quien haya hecho la más alta) deberán en este punto explicar sus
estimaciones.
Una vez hecho esto, el equipo puede discutir sobre el elemento y sobre sus
estimaciones. El moderador controlará el tiempo, que deberá estar acotado
para no fomentar discusiones interminables. Para ello es buena idea utilizar
alguna herramienta visual de control de tiempo, como por ejemplo, un reloj
de arena de un par de minutos.
El moderador también puede anotar en el elemento de la pila alguna de las
consideraciones que se hayan expuesto sobre la mesa y que crea que
puedan ser útiles.
Tras este período, se vuelven a utilizar las cartas para estimar.
Normalmente las estimaciones convergen en segunda ronda, pero si no es
así, se repite el proceso.
Hay que tener en cuenta que aunque se persiga la convergencia plena de
los asistentes, no es necesario estar celebrando nuevas rondas si se puede
llegar a un acuerdo antes. Imaginemos que todos los estimadores asignan 8
puntos al elemento y uno le asigna 5.
Si este último acepta cambiar su estimación, se puede hacer sin problemas,
dejando el elemento en 8 puntos.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 96 de 141
Versión 3.2
4.5.3 Otros costes
El Director del Proyecto deberá considerar otros costes asociados al
proyecto. Especialmente debe tener en cuenta los requisitos de
comunicaciones no sólo del Gestor de Expectativas con los interesados, sino
también entre los propios Gestores de Ejecución. En proyectos donde el
equipo esté disperso, es un factor importante que incide, no sólo en el coste
de las comunicaciones, sino también en el rendimiento del equipo.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 97 de 141
Versión 3.2
4.6 Cerrando el horizonte 1 | Alcance inicial
4.6.1 Priorización
No habrá tiempo ni recursos para desarrollarlo todo. Así que hay que
priorizar. Es fundamental para focalizar los esfuerzos con el objetivo de
maximizar el ROI del proyecto.
La responsabilidad del Gestor de Expectativas lleva implícita una dificultad
considerable. Debe considerar diferentes factores, como valor de negocio,
coste de desarrollo, nuevo conocimiento generado y riesgo implicado, cada
uno de los cuales poseen su propia complejidad.
4.6.1.1 Valor de Negocio
Es el principal factor de priorización, y uno de los más complicados de
caracterizar. ¿Cómo cuantificamos el valor de negocio? Habrá unas pocas
ocasiones en que podamos cuantificar el impacto financiero de resolver un
elemento, pero en la mayor parte de las veces, nos será imposible, o el
tiempo necesario para hacerlo lo hace inviable. Es conveniente, por tanto,
utilizar un método alternativo de estimación del valor. Lo importante no es
método que se use, sino que permita comparar elementos en base al valor
que su desarrollo proporciona al cliente.
4.6.1.2 Coste de Ejecución
Es otro factor importante a la hora de priorizar. Imaginemos un elemento
de la pila que hace referencia a una característica del producto
absolutamente fantástica, teniendo en cuenta el valor que aporta… hasta
que se considera el coste necesario para ejecutarla. Conviene no olvidar,
aunque sea una obviedad, que el tiempo de las personas que se dedican a
ejecutar un proyecto cuesta dinero.
4.6.1.3 Riesgo
Podemos definir el riesgo como cualquier cosa que no ha pasado pero
podría pasar y que puede afectar, limitar o poner en peligro el éxito del
proyecto.
Se podrían establecer diferentes taxonomías de los riesgos de un proyecto.
Considerando las tres variables del triángulo, podemos destacar estos tres:
Riesgos relacionados con el tiempo
Riesgos relacionados con el coste
Riesgo relacionados con los elementos que se van a resolver.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 98 de 141
Versión 3.2
Otra forma de clasificarlo, atendiendo a las dos dimensiones de la
complejidad es:
Riesgos relativos a la tecnología (asociados al CÓMO)
Riesgos relativos al negocio (asociados al QUÉ)
A la hora de considerar el riesgo en la priorización, podríamos considerar
dos extremos:
Desarrollo dirigido por riesgo (primero el que más riesgo tiene, sin
prestar atención al valor)
Desarrollo dirigido por valor (primero el que más valor de negocio
aporta, sin prestar atención al riesgo)
Ambas aproximaciones tienen asociadas numerosos problemas. En el primer
caso se puede dar la situación de que se ejecutando un elemento que
conlleva mucho riesgo y que no aporta apenas valor de negocio, algo que
conceptualmente roza el absurdo. En el segundo caso, podemos estar
dejando a un lado una característica que tiene un valor similar a la actual,
pero cuyo riesgo aumenta con el tiempo. Ambas situaciones son
indeseables.
La forma más aconsejable de trabajar con ambas dimensiones se muestra
en la siguiente figura:
Figura 4.11: Valor - Riesgo
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 99 de 141
Versión 3.2
Primero se desarrollan los elementos que proporcionen un alto valor y
tengan un alto riesgo. Después aquellos que tienen un alto valor y poco
riesgo, dejando para el último lugar los elementos que aportan poco valor y
tienen poco riesgo.
Como regla general, el valor prevalece a la hora de priorizar, y sólo se
utiliza el riesgo para inclinar la balanza en caso de empate.
4.6.1.4 Nuevo Conocimiento
De forma iterativa e incremental, a lo largo del proyecto se irá generando
nuevo conocimiento sobre:
El producto.
El proyecto.
Estas son las dos dimensiones omnipresentes en Scrum. El producto
representa el QUÉ y el proyecto representa el CÓMO.
Veamos cómo se plantea la reducción de la incertidumbre en ambas
dimensiones siguiendo un enfoque tradicional:
Figura 4.12: Reducción de la incertidumbre - Enfoque Tradicional
(adaptación de Cohn 2006)
El enfoque tradicional intenta reducir toda la incertidumbre sobre el QUÉ se
va a desarrollar al inicio y luego reducir la incertidumbre sobre el CÓMO va
a ser desarrollado.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 100 de 141
Versión 3.2
El problema es que en un contexto de alta incertidumbre, no es posible
conocer al detalle el QUÉ al inicio. Además, los cambios estarán presentes a
lo largo de la vida del proyecto, por lo que el QUÉ se irá descubriendo y
definiendo de forma iterativa e incremental a medida que se va generando
el nuevo conocimiento sobre el producto.
Por tanto, desde un enfoque ágil, la reducción de incertidumbre se podría
representar así:
Figura 4.13: Reducción de la incertidumbre - Enfoque Ágil (adaptación de
Cohn 2006)
La gráfica ilustra cómo a medida que vamos avanzando en el proyecto, el
nuevo conocimiento generado sobre el proyecto va reduciendo la
incertidumbre de forma gradual respecto al QUÉ y respecto a CÓMO.
La pendiente representa que la dimensión del CÓMO va en función de la
dimensión del QUÉ. Lógico, es esencial saber QUÉ queremos hacer antes de
pensar en el CÓMO. Esto se verá muy claro cuando hablemos de la
planificación en cada fase.
En definitiva, es importante tener en cuenta que el nuevo conocimiento
generado hará variar los otros tres factores, tanto la percepción del valor
por el cliente, como las estimaciones de costes y la percepción del riesgo.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 101 de 141
Versión 3.2
4.6.1.5 Utilizando los cuatro factores
Una forma intuitiva de definir el ROI es el cociente valor / coste. Este
parámetro nos da un orden inicial de los elementos de la pila, situando en la
parte más alta los que tengan un ROI mayor. El resto de factores son útiles
para mover elementos hacia arriba o hacia debajo de la pila.
Imaginemos que tenemos en la pila dos elementos de prioridad media y
tenemos que decidir cuál formará parte de una entrega del producto.
Comparar el riesgo necesario o el valor que aportará el nuevo conocimiento
generado por ese elemento nos facilitaría tomar una decisión bien
fundamentada.
4.6.2 Establecer la longitud de las Fases
Generalmente, una fase suele tener una longitud entre 2 y 4 semanas. No
quiere decir esto que no se pueda dar el caso de fases más grandes o más
pequeños.
En cualquier caso, lo primero que hay que tener en cuenta es que, como en
la mayoría de las cuestiones que tratamos, no hay fórmulas mágicas para
establecer la longitud idónea, pero sí existen una serie de criterios que es
necesario tener en cuenta para tomar esta decisión:
La incertidumbre del proyecto y la necesidad y facilidad de obtener
feedback. A mayor incertidumbre, más cortas deberían de ser las
fases para obtener feedback lo antes posible y minimizar el costo de
los posibles errores.
Los costes asociados a cada fase. Hay que tener en cuenta que una
fase implica unos costes organizativos relativos a las diferentes
actividades y reuniones que se deben llevar a cabo.
Cuánto tiempo pueden permanecer las prioridades sin cambiar.
La longitud total del proyecto.
La urgencia del proyecto.
Como siempre, la inspección y la adaptación juega un papel fundamental
para que los equipos vayan reconociendo sus principales factores y qué
longitud suele ser la idónea para ellos en los diferentes contextos a los que
se vayan enfrentando.
Eso sí, es esencial que, una vez tomada la decisión respecto a la longitud de
la fase, esta longitud se mantenga a lo largo de la vida del proyecto, ya que
uno de los principios fundamentales que hacen que este marco de trabajo
sea efectivo es que provoca un ritmo sostenible de trabajo, esencial para
crear buenos hábitos y automatizar dinámicas.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 102 de 141
Versión 3.2
4.6.3 Estimar la velocidad
La velocidad es la única métrica que vamos a utilizar respecto a la
capacidad y desempeño de los Gestores de Ejecución. La velocidad en una
fase se determina por la suma de los puntos de historia de todos los
elementos de la pila que se han logrado resolver con éxito durante esa fase.
Al lo largo del proyecto será determinada en función de la velocidad
registrada en las fases anteriores. Pero al inicio del proyecto carecemos de
este histórico.
Si los Gestores de Ejecución no es la primera vez que trabajan juntos
pueden utilizar su histórico de proyectos y buscar analogías con proyectos
de similares características.
En otro caso se tendrá que hacer una predicción de la velocidad. Y
seguramente estará equivocada. Admitámoslo y contemos con ello, porque
es mejor tener una mala estimación que no tener estimación e ir a ciegas.
De todos modos, a medida que el equipo trabaje junto y se avance en el
proyecto, la precisión de la estimación de la velocidad será mayor, y la
capacidad para aumentar la velocidad a medida que se va adquiriendo
destreza en el proyecto también irá creciendo.
4.6.4 Planificar las entregas
Sabemos quiénes son los Gestores de Ejecución, tenemos la Pila del
Producto estimada y priorizada, hemos establecido la longitud del Sprint y
hemos estimado la velocidad. Por tanto, podemos estimar qué elementos de
la pila pueden ser desarrollados durante el proyecto y qué características
serán resueltas en las diferentes fases. Pero ojo, esto es la foto a día de
hoy. El conocimiento generado a lo largo del proyecto provocará que esta
ordenación de elementos varíe, en muchos casos drásticamente.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 103 de 141
Versión 3.2
4.7 Planificación de la Calidad | Orientación ISO10006
No es el ámbito del presente tratado analizar en profundidad la norma ISO
10006, pero sí poner de manifiesto la importancia de sus lineamientos
claves.
Uno de los principales corolarios que se extraen de la norma es que hay dos
aspectos en la aplicación de la calidad en los proyectos, los referidos a los
procesos y los referidos al producto. Este principio es la raíz de la norma y
le da sentido. Hemos hecho especial énfasis desde el inicio del presente
tratado en dos aspectos fundamentales, el QUÉ y el CÓMO.
En el ámbito del proyecto, el QUÉ hace referencia al producto resultante del
mismo. El CÓMO a los procesos que hacen que se llegue a ese resultado.
Ambas dimensiones implican incertidumbre en el contexto objeto de estudio
por el presente tratado y por tanto, durante el proyecto se ha de medir,
analizar y mejorar ambos aspectos.
Hemos de aprender sobre el QUÉ y hemos de aprender sobre el CÓMO. Y
aplicar este nuevo conocimiento para mejorar las dos dimensiones del
proyecto. Esto es estar plenamente orientado a la calidad como valor
supremo.
Tanto es así que planteamos dos roles que se dedican, cada uno, a una de
las dimensiones.
Así, el Gestor de Expectativas tiene como misión gestionar, aprender y
mejorar el QUÉ, y los Gestores de Ejecución tienen como misión gestionar,
aprender y mejorar el CÓMO para ejecutar cada vez mejor el QUÉ
demandado por el Gestor de Expectativas.
El Director del Proyecto gestionará los recursos, facilitará el trabajo al resto
de miembros del equipo y derribará impedimentos. Se preocupará por que
el proceso de gestión del proyecto se lleve a cabo correctamente, con
fluidez y calidad.
Con ello, lo que queremos transmitir es que la calidad es algo, a nuestro
juicio, irrenunciable. El marco de trabajo contempla su planificación, su
aseguramiento, su control y su validación de forma implícita dentro de los
procesos que lo conforman, no como algo que ha de gestionarse de forma
accesoria.
4.7.1 Condiciones de Satisfacción
Respecto a la planificación de la calidad, es importante señalar la necesidad
de comenzar definiendo qué condiciones van a determinar que el proyecto
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 104 de 141
Versión 3.2
sea un éxito o no. Normalmente se definen como una combinación de los
tres factores del triángulo de hierro:
Objetivos respecto al tiempo
Objetivos respecto al coste
Objetivos respecto a alcance
Pero ya vimos que entornos de alta incertidumbre no se pueden cerrar los
tres y esperar que se cumplan. Sobre todo, porque el alcance no se puede
definir por completo al inicio.
En lugar de ignorar este hecho, bajo un enfoque ágil se pueden cerrar dos
variables, pero debe haber flexibilidad en la otra. Por ejemplo, se pueden
plantear un conjunto de funcionalidades con un costo determinado y
plantear una fecha flexible. O fijar tiempo y costo y ser flexible con el
alcance.
Determinar con anterioridad los criterios de satisfacción es fundamental
para tener siempre sobre la mesa las reglas del juego. En función de estos
criterios se establecerá el marco legal oportuno y se evaluará el resultado
del proyecto.
No obstante, a lo largo del proceso, el equipo aprenderá a conocer dónde
está el listón de calidad del cliente, de modo que cada vez se consiga más y
mejor llegar a este listón, sin sobrepasarlo, al mínimo coste.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 105 de 141
Versión 3.2
4.8 Planificando con personas
En los proyectos de alta incertidumbre, los recursos más importantes son
las personas. El Director del Proyecto debe prestar un especial cuidado a la
hora de seleccionar al Gestor de Expectativas y a los Gestores de Ejecución.
En este entorno no sólo se necesita la excelencia técnica en sus disciplinas,
sino que además es necesario disponer un alto desarrollo de las
capacidades y habilidades llamadas “blandas”, como son: la capacidad de
trabajar en equipo, la empatía, la autocrítica, la comunicación, la
asertividad, etc.
La capacidad de aprendizaje es una de las características más valoradas en
este tipo de proyectos, puesto que su éxito se basa en la forma y rapidez en
la que se genera conocimiento y se aplica en la mejora del producto y de los
procesos que lo producen.
El Director del Proyectos tiene una gran responsabilidad para con su equipo,
y debe desarrollar y poner en prácticas múltiples facetas:
Mentor
Facilitador
Solucionador de Problemas
4.8.1 Mentor
El Director del Proyecto debe procurar que el resto del equipo adquiera las
destrezas necesarias para llevar a cabo sus responsabilidades con
profesionalidad y efectividad. Para ello actuará de mentor, guiándole en el
proceso y mostrándole el camino por el que pueden aumentar sus
capacidades y habilidades respecto al rol que desempeñan.
El Director del Proyecto debe formar al resto del equipo de forma continua,
durante todo el proceso, debe conocer las capacidades y habilidades de
cada uno y sus puntos de mejora y procurarle la capacitación necesaria
para potenciar las que tiene y adquirir otras nuevas útiles para el proyecto.
4.8.2 Facilitador
El Director del Proyecto debe actuar durante todo el proceso como un
facilitador, especialmente en las reuniones y en las interacciones entre los
miembros del equipo, de modo que siempre estén focalizadas, se cumplan
los objetivos y la comunicación no se desvíe y provoque la pérdida de
tiempo, esfuerzo y energías.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 106 de 141
Versión 3.2
El Director del Proyecto debe procurar exacerbar en el resto del equipo sus
capacidades y habilidades colaborativas para que exista una interacción
positiva entre sus miembros de modo que puedan actuar de facto como un
Sistema Adaptativo Complejo y aumenten sus posibilidades de resolver el
problema complejo en el que se basa el proyecto.
4.8.3 Solucionador de Problemas
El Director del Proyecto debe ser incansable en su afán por eliminar los
impedimentos que el equipo se vaya encontrando a lo largo del proyecto.
Se dice de él que es un líder servicial, porque actúa al servicio del equipo,
para mantenerlo focalizado y sacar el máximo rendimiento de él.
Además debe procurar que el conocimiento que se genera para la mejora
del producto y del proceso formen parte de las Lecciones Aprendidas del
equipo y que esta información, de este y otros proyectos, está disponible
para ser usada.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 107 de 141
Versión 3.2
4.9 Comunicando | El proceso
La comunicación es parte fundamental que tiene un impacto directo sobre el
rendimiento del equipo. Los costes asociados a una mala comunicación en
muchos proyectos es su espada de Damocles. Los múltiples canales
existentes y el escaso control que se ejercen sobre ellos suelen estar detrás
de estos problemas derivados de una mala comunicación.
La aparición de la figura del Gestor de Expectativas pretende, por un lado
reducir a uno el número de canales de comunicación entre los expertos en
la dimensión del QUÉ, como es el cliente y otros interesados y los expertos
en la dimensión del CÓMO, que son los Gestores de Ejecución; y por otro
lado, aumentar el ancho de banda disponible de este canal.
Es por ello que se sistematizan las reuniones entre el Gestor de
Expectativas y los Gestores de Ejecución y que se requiere la disponibilidad
del primero durante la ejecución de las diferentes fases para solventar las
dudas de los segundos.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 108 de 141
Versión 3.2
4.10 Abrazando la incertidumbre | Gestionando los riesgos
Cuando hablamos de gestión del riesgo nos referimos a reducir la
probabilidad e impacto de los eventos adversos en un proyecto. El marco de
trabajo que planteamos, debido a su carácter iterativo, implícitamente logra
que la gestión del riesgo forme parte inherente del ciclo de vida del
proyecto.
Muchos autores discuten sobre si en un ambiente ágil basado en Scrum es
necesaria la gestión de los riesgos explícita.
Los riesgos que son externos al proyecto requieren del Director del Proyecto
su identificación, análisis y planificación de la respuesta a los mismos. Pero
los riesgos internos del proyecto son gestionados de forma de forma
implícita por el propio proceso de gestión del proyecto.
Los marcos de trabajo ágiles abrazan la incertidumbre y se mueven bien por
ella, porque no pretende resolver toda la incertidumbre al principio del
proyecto. En lugar de hacer esto, prefieren producir y generar conocimiento
necesario para irla reduciendo de forma iterativa. Las reuniones claves del
marco de trabajo, como veremos más adelante, están enfocadas para
gestionar de forma implícita todos los riesgos relativos al alcance, a los
recursos, al tiempo y a la comunicación.
4.10.1 Riesgos asociados al alcance
En el marco de trabajo planteado es iterativo e incremental, donde el
alcance no está cerrado de inicio, y se revisa sistemáticamente priorizando
las características potencialmente entregables por ROI. También de forma
sistemática se revisa el producto y esta información se utiliza para revisar el
alcance y planificar la siguiente fase.
Con la figura del Gestor de Expectativas y bajo esta dinámica de trabajo se
elimina el riesgo de que el proyecto produzca un resultado que no se
adecúe a las expectativas del cliente.
Los elementos del marco de trabajo más relevantes de la gestión del riesgo,
son es el Scrum Diario y las reuniones de Retrospectiva. En el primero se
identifican los impedimentos que cada uno de los integrantes del equipo se
van encontrando y en el segundo se revisa y mejora el proyecto, para lo
que, entre otras cosas, se identifican impedimentos pasados, presentes y
futuros para mejorar el proceso, dotándole de capacidad de adaptación y de
anticipación.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 109 de 141
Versión 3.2
Capítulo 5
EJECUTANDO LA PLANIFICACIÓN
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 110 de 141
Versión 3.2
5.1 Dirección y gestión de la ejecución | Proyectos con alta
incertidumbre
Un proyecto ágil puede ser considerado como la generación rápida y fiable
de un flujo de:
Nuevas capacidades para el producto
Nuevo conocimiento para hacer que el producto sea mejor
Nuevo conocimiento para hacer que los procesos del proyecto sean
mejores
Todo ello se realiza de forma iterativa e incremental. En cada fase podemos
distinguir cuatro etapas:
Planificación: en la que se prepara el trabajo para focalizar los
esfuerzos del Equipo
Seguimiento y Control: en la que se realizan los trabajos
planificados del proyecto, midiendo y controlando su progreso
Revisión: en la que se muestran los avances en el producto final y
se valida el trabajo realizado.
Retrospectiva: en la que los Gestores de Ejecución mejoran
continuamente los procesos de gestión y ejecución obtienen lecciones
aprendidas para aplicar en las siguientes fases.
Considerar el conocimiento generado como un activo fundamental es la
clave para alcanzar un alto rendimiento en entornos de alta incertidumbre.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 111 de 141
Versión 3.2
5.2 Gestión de las expectativas del cliente
El Gestor de Expectativas tiene un gran protagonismo antes, al inicio,
durante y al final de cada fase:
Antes: debe actualizar la Pila del Producto, reuniéndose con el cliente
y el resto de interesados si es necesarios para que este artefacto
refleje las expectativas actuales del cliente.
Al inicio: forma parte activa en la planificación de cada fase, donde
él, como responsable del QUÉ y los Gestores de Ejecución, como
responsables del CÓMO, deben intercambiar conocimiento para
reducir la incertidumbre sobre el trabajo que ha de hacerse durante
la fase.
Durante: el Gestor de Expectativas debe estar disponible siempre que
los Gestores de Ejecución lo necesiten para resolver dudas (que
representan incertidumbre) y aclarar las cuestiones que ellos
necesiten.
Al final: el Gestor de Expectativas deberá validar cada una de las
características entregadas al final de la fase.
Es por ello que en este enfoque se considera que la gestión de expectativas,
como pasa como otros procesos que en la gestión de proyectos tradicional
son explícitos, es inherente al marco de trabajo.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 112 de 141
Versión 3.2
5.3 Control integrado de cambios
Los cambios no sólo son controlados, sino que son bienvenidos. Cuando se
planifica una fase, como veremos en el epígrafe siguiente, se produce un
compromiso entre el Gestor de Expectativas y los Gestores de Ejecución:
durante la fase no se admitirán cambios en el trabajo que está
comprometido para dicha fase, a cambio, se pueden hacer cuantos cambios
se deseen en el resto de la Pila del Producto (dentro del marco de acuerdo
que se haya establecido entre empresa cliente y ejecutora).
No obstante pueden aparecer cambios de ejecución inmediata o urgente. Si
su impacto en el proyecto en la fase es grande, como por ejemplo, un
cambio de normativa que haga que el trabajo planificado para la fase
carezca de sentido, habrá que suspender la fase y volver a planificar. Si es
un cambio que no tiene tal impacto pero no puede esperar a que finalice la
fase, se estimará el esfuerzo necesario para tal cambio y se colocará dentro
de la Pila de la Fase. Esto puede implicar que parte del trabajo
comprometido se quede sin ejecutar al final de la iteración.
En cualquier caso es necesario que el equipo defina bien qué es un cambio
urgente y cómo se actuará en tal caso.
Por otra parte, una de las prácticas ágiles de mayor valor, muy utilizada en
desarrollo de software, pero aplicable a muchos otros tipos de proyecto es
la integración continua. Es decir, el incremento de funcionalidad que se
entrega tras la fase es, como hemos dicho, un incremento de las
características del producto; o dicho de otro modo, es el producto integrado
con un incremento de sus características.
Esto lleva implícito que cualquier característica que se produzca durante la
fase no estará terminada hasta que no esté integrada con el resto del
producto, que no ha de perder ni desvirtuar ninguna de sus otras
características ya entregadas por la adición de la nueva.
En desarrollo de software existen sistemas de integración que permiten
comprobar continua y automáticamente que cuando se incorpora un nuevo
elemento el software sigue cumpliendo con las especificaciones.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 113 de 141
Versión 3.2
5.4 Planificación de la fase N
En contextos de alta incertidumbre es fácil perderse entre la multitud de
posibilidades que tienen este tipo de proyectos, tanto en el orden en el que
se pueden producir las diferentes características del producto como en el
modo de producirlas.
La clave está en reducir la incertidumbre de forma incremental en las dos
dimensiones de incertidumbres:
En el plano del QUÉ (know what)
En el plano del CÓMO (know how)
Tratándose de proyectos que resuelven problemas complejos, necesitamos
hacer inspección y adaptación para aprender, es decir, en el ámbito de un
proyecto complejo, aprendemos a ejecutarlo ejecutándolo. Es decir, en el
inicio no contamos con suficiente información para tomar todas las
decisiones relativas al QUÉ y al CÓMO.
Por otra parte, si queremos conseguir el alto rendimiento de los Gestores de
Ejecución necesitamos que sus esfuerzos estén focalizados, que la
incertidumbre sea mínima.
¿Cómo conseguimos focalizar nuestros esfuerzos en un contexto donde la
incertidumbre es tan alta?
Dos palabras claves:
Priorización
Comunicación
Es decir, no vamos a reducir la incertidumbre asociada a todo el proyecto,
sólo a los elementos más prioritarios de la Pila del Producto hasta que
tengamos suficiente carga de trabajo para la fase actual. Y esta labor han
de llevarla a cabo:
El Gestor de Expectativas, que es el responsable del QUÉ.
Los Gestores de Ejecución, que son los responsables del CÓMO.
5.4.1 Recopilar requisitos y determinar el horizonte de la
fase N | Reunión de planificación de la fase
Es importante que el Gestor de Expectativas acuda a esta reunión con la
Pila del Producto actualizada. Este es un trabajo previo que debe llevar a
cabo el cliente y el resto de interesados para que la pila refleje los
requisitos actuales.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 114 de 141
Versión 3.2
5.4.1.1 Objetivos
Intercambiar conocimiento entre el Gestor de Expectativas y los
Gestores de Ejecución para reducir la incertidumbre en el plano del
QUÉ y en el plano del CÓMO.
Definir el trabajo que los Gestores de Ejecución deberán llevar a cabo
durante la fase para focalizar sus esfuerzos y conseguir un alto
rendimiento.
5.4.1.2 Duración
Típicamente, una jornada de 8 horas dividida en dos partes de 4
horas cada una.
5.4.1.3 Participantes
Gestor de Expectativas: debe preparar con carácter previo la Pila
del Producto, intercambiará conocimiento con los Gestores de
Ejecución y tomará decisiones respecto a la priorización de los
elementos de la pila.
Gestores de Ejecución: deberán intercambiar conocimiento con el
Gestor de Expectativas, deberán plantear los riesgos posibles en su
ejecución, tienen la responsabilidad de estimar el esfuerzo necesario
para producir cada una de las características potencialmente
entregables, y decidirán la carga de trabajo que son capaces de
asumir durante la fase.
Director del Proyecto: deberá ejercer de facilitador, en todo
momento debe mantener el foco de la reunión, controlar los tiempos
de cada parte y facilitar la comunicación entre todos los participantes.
Adicionalmente, de forma opcional, pueden asistir otros interesados
en el proyecto, pero no pueden participar a no ser que se les
pregunte. El Director del Proyecto debe procurar que nadie rompa el
flujo de comunicación entre el Gestor de Expectativas y los Gestores
de Ejecución.
5.4.1.4 Prerrequisitos
Es fundamental que asistan tanto el Gestor de Expectativas como los
Gestores de Ejecución. Si el Gestor de Expectativas no pudiera
asistir, deberá delegar esta función en alguien de su confianza que
tendrá las mismas funciones y obligaciones que él mismo en su
ausencia, y por tanto sus decisiones serán vinculantes en el proyecto.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 115 de 141
Versión 3.2
El Director del Proyecto ha de asegurarse previamente que se
dispone de un espacio suficiente como para que los participantes
puedan interactuar de forma cómoda.
El Gestor de Expectativas debe llegar a la reunión con la Pila del
Producto priorizada.
5.4.1.5 Organización
La reunión de Planificación de la Fase consta de dos partes:
Primera Parte o Planificación del QUÉ (4 horas).
Segunda Parte o Planificación del CÓMO (4 horas).
5.4.1.5.1 Primera Parte: Planificación del QUÉ
El objetivo de esta primera parte es determinar qué características van a
ser producidas durante la fase. Es decir, determinar qué elementos de la
Pila del Producto van a conformar el incremento de valor que se entregará
al final de la fase.
El Gestor de Expectativas habrá de exponer los elementos de la Pila del
Producto, comenzando por el más prioritario. Para cada uno de ellos los
Gestores de Ejecución le harán las preguntas necesarias para comprender
realmente QUÉ se quiere producir, lo suficiente como para poder estimar el
esfuerzo necesario para hacerlo.
Por otro lado, el Gestor de Expectativas deberá comprender la complejidad
y los posibles impedimentos, riesgos e implicaciones asociados la
producción del elemento, lo cual puede hacer que tome la decisión de
cambiar la prioridad de la pila debido a esta nueva información.
Esta parte de la reunión es un acto de comunicación entre el Gestor de
Expectativas (el QUÉ) y los Gestores de Ejecución (el CÓMO) de modo que
ambas partes aporten la información necesaria para reducir la
incertidumbre hasta el punto de que sea manejable. Es una conversación en
la que se negocia en base a argumentos.
Los Gestores de Ejecución tendrán que valorar el esfuerzo que pueden
asumir durante la fase. De modo que, cuando el conjunto de elementos de
la Pila del Producto procesados cubra el cupo del esfuerzo máximo que ellos
estiman para cada fase, la primera parte de la reunión se da por concluida.
La técnica del Planning Poker es muy efectiva y divertida para dinamizar
este tipo de reuniones.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 116 de 141
Versión 3.2
El resultado de esta reunión es la selección del segmento de la Pila del
Producto que será transformado durante la fase en un incremento de valor
entregable.
5.4.1.5.2 Segunda Parte: Planificación del CÓMO
En la segunda parte de la reunión los Gestores de Ejecución tendrán que
definir, para cada elemento de la Pila del Producto las tareas necesarias
para poder desarrollarlo, con la suficiente granularidad como para que cada
tarea pueda ser resuelta por una persona en un tiempo determinado.
Los elementos de la pila que se van a producir junto con las tareas en las
que se divide cada elemento forman la Pila de la Fase, que representa el
trabajo que los Gestores de Ejecución tienen que llevar a cabo durante la
iteración.
Respecto a la estimación de las tareas, se puede seguir, entre otras, estas
estrategias:
Estimarlas
No estimarlas
Dimensionarlas de modo que todas las tareas requieran más o menos
el mismo esfuerzo. Con esta estrategia, el esfuerzo restante en la
fase es directamente proporcional al número de tareas que quedan.
Cada equipo debe encontrar la estrategia que mejor le convengan. Hay
quienes prefieren no estimarlas, porque consideran que no aporta un valor
adicional, puesto que ya se ha estimado el elemento de la pila.
Por el contrario hay quienes opinan que estimar las tareas ofrece un mayor
control sobre el proyecto y permite aplicar técnicas de gestión de tares.
Todo dependerá de la naturaleza del proyecto y de las necesidades del
equipo. En este aspecto, inspección y adaptación vuelven a ser
fundamentales.
5.4.2 Planificación de las comunicaciones en la Fase N
Los principales puntos de comunicación entre el Gestor de Expectativas y
los Gestores de Ejecución se llevan a cabo al inicio, en la Reunión de
Planificación de la Fase, y al final, en la Reunión de Revisión.
No obstante, el Gestor de Expectativa debe estar disponible durante la fase
para resolver cualquier duda que pueda surgirles a los Gestores de
Ejecución.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 117 de 141
Versión 3.2
Asimismo, durante la fase, el Gestor de Expectativa tendrá que comunicarse
con el cliente y el resto de implicados para aportarles feedback y seguir
trabajando en la captación de requisitos.
El Director del Proyecto deberá crear las condiciones idóneas y disponer de
los medios necesarios para que la comunicación entre los Gestores de
Ejecución sea fluida. Especialmente es importante cuando el equipo no
comparte localización.
Los puntos más notables de comunicación entre los Gestores de Ejecución
durante la fase son la Reunión de Sincronización Diaria y la Retrospectiva,
pero no debemos olvidar que la comunicación entre ellos debe ser
constante, porque es su interacción (véase Capítulo 1, cuando hablamos de
los Sistemas Adaptativos Complejos) donde son capaces de llegar a buenas
soluciones con un alto rendimiento.
5.4.3 Planificación de la Gestión de Riesgos en la Fase N
Como señalamos anteriormente, el Director del Proyecto deberá tener
identificados los riesgos externos al proyectos, analizados y establecido su
plan de respuesta. Respecto a los riesgos internos, serán gestionados
implícitamente en el marco de trabajo. Particularmente, como veremos, la
Reunión de Sincronización Diaria y la Retrospectiva son los elementos del
marco de trabajo que actúan directamente sobre los riesgos.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 118 de 141
Versión 3.2
5.5 Gestión de la Calidad en la Fase N
5.5.1 Calidad del Producto
En la planificación de la fase, los Gestores de Ejecución deben incluir en la
Pila de la Fase las tareas que sean necesarias para asegurar la calidad de
cada una de las características que producen y de su integración en el
producto final, para considerar que un determinado elemento de la pila está
terminado. De este modo, el aseguramiento de la calidad del entregable es
continuo.
Al final de la fase, en la reunión de Revisión, el Gestor de Expectativas
valida la calidad de las características entregadas.
5.5.2 Calidad de los Procesos
Durante la ejecución se celebran Reuniones de Sincronización Diarias para,
entre otras cosas, poner de manifiesto cuáles son los impedimentos que los
Gestores de Ejecución se van encontrando en el ejercicio de su trabajo. El
Director del Proyecto debe actuar como solucionador de problemas y
dedicarse a eliminar todas estas barreras. También llevará un registro de
impedimentos que pondrá sobre la mesa en la Reunión de Retrospectiva,
donde los Gestores de Ejecución analizarán los procesos del proyecto para
detectar puntos de mejora y solucionarlos, de modo que con el
conocimiento adquirido se mejoran para la siguiente fase y el resto del
proyecto. Estas mejoras serán registradas en un archivo de lecciones
aprendidas.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 119 de 141
Versión 3.2
5.6 Gestión de las Personas en la Fase N
La mayoría de organizaciones cuentan con múltiples proyectos y múltiples
personas dedicadas a esos proyectos. También hay proyectos que cuentan
con personas de múltiples organizaciones.
En cualquier caso estos recursos deben ser inteligentemente gestionados.
Esto implica que es posible que durante el proyecto haya incorporaciones y
salidas de personas dentro del equipo de Gestores de Ejecución. Lo
recomendable en este tipo de entornos es que estas salidas o entradas de
personas no afecten a la fase, y que se realicen antes o después, pero
nunca durante.
Eso es así por la importancia de que planifiquen el trabajo aquellos que lo
van a ejecutar. Cuando una incorporación, el Director del Proyecto debe
ejercer de mentor para acelerar en la medida de lo posible su integración en
el equipo.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 120 de 141
Versión 3.2
5.7 Control y Seguimiento
En este punto, teniendo claro el plan de trabajo que hay que seguir durante
la fase, es tiempo de trabajar en la producción de las características
elegidas para la presente iteración.
No es objeto del presente tratado entrar en cuestiones técnicas relativas al
CÓMO. Cada disciplina tiene unos conocimientos, técnicas y métodos
específicos que confieren al Equipo de la excelencia técnica necesaria. Nos
ocuparemos, como adelantamos en los capítulos introductorios, de la capa
de dirección y gestión.
5.7.1 Monitorizar y controlar los riesgos
Uno de los principios que hacen de Scrum un marco de trabajo de alto
rendimiento es su afán explícito porque los problemas, errores,
impedimentos emerjan cuanto antes, de modo que su coste sea el menor
posible y que se conviertan de facto en puntos de aprendizaje que generen
conocimiento de valor sobre el producto o sobre el proyecto.
Imaginemos un escenario donde dos miembros del Equipo están trabajando
en diferentes características del proyecto. Llamémosles María y Pablo.
Pongámonos en la situación de que María tiene un problema que le está
trayendo quebraderos de cabeza. Pablo por su parte se ha encontrado con
otro problema muy similar al de María. ¿No sería interesante que ambos lo
supieran para ayudarse mutuamente? Imaginemos que uno de los dos lo ha
logrado resolver y el otro ni se entera. ¿Cuánto retrabajo evitable se estaría
produciendo?
Es necesario que esta información fluya. Es necesario que se sincronicen los
esfuerzos para que el retrabajo sea mínimo, y todo el esfuerzo y todas las
energías se inviertan en actividades que aportan realmente valor.
Por otra parte, cuando una persona trabaja dentro de un equipo de trabajo
puede tender a pensar que los demás no trabajan o no se esfuerzan como
ella.
En cualquiera de los dos casos la clave está en la comunicación. Este es el
sentido de celebrar cada día una Reunión de Sincronización, acotada en el
tiempo y en contenido, y enfocada a transmitir la información más relevante
para comenzar la jornada, que facilita información sobre el desempeño de
cada cual así como de los impedimentos que se tienen.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 121 de 141
Versión 3.2
5.7.1.1 Reunión de Sincronización
5.7.1.1.1 Objetivos
Sincronizar los esfuerzos de los Gestores de Ejecución
Revisar el avance hacia los objetivos de la fase
Identificar impedimentos
5.7.1.1.2 Participantes
Gestores de Ejecución. Deben estar todos.
Director del Proyecto. Debe conducir la reunión y tomar nota de los
impedimentos puestos de manifiesto durante la reunión para facilitar
su resolución durante la jornada.
5.7.1.1.3 Prerrequisitos
Celebrar esta reunión en el mismo lugar y a la misma hora todos los
días, para logar instaurar correctamente el hábito.
Debe existir máxima puntualidad.
No debe exceder de los 15 minutos.
5.7.1.1.4 Organización
La dinámica es muy sencilla: cada uno de los Gestores de Ejecución
responde a tres preguntas:
¿Qué hice ayer?
¿Qué voy a hacer hoy?
¿Qué impedimentos tengo?
No es una reunión para discutir. Es una reunión para comunicar. No se
debate, no se juzga, no se interrumpe. Cuando todos los miembros del
equipo las han respondido, finaliza la reunión.
La primera consecuencia es que, tras la reunión, todos tienen consciencia
del trabajo de todos y de cada uno. Es muy humano el pensar que nosotros
somos los que más trabajamos en los proyectos y que los demás parecen
no hacer nada. Con la Reunión de Sincronización se tiene conciencia
explícita del esfuerzo, el desempeño y el compromiso de todos, aumentando
la confianza en el Equipo y favoreciendo el sentimiento de pertenencia y de
unidad.
La segunda consecuencia es que se ha compartido conocimiento importante
sobre los impedimentos. Por un lado, el Director del Proyecto tomará nota
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 122 de 141
Versión 3.2
de los impedimentos y trabajará durante la jornada para solucionarlos. Por
otro lado, impedimentos a nivel técnico son compartidos para facilitar que
interactúen entre los Gestores de Impedimentos para resolverlos. Esta labor
de comunicación es absolutamente esencial para conseguir un ritmo de
trabajo fluido y sincronizado.
5.7.1.2 Reunión de Retrospectiva
El otro punto importante de control de riesgos es la Reunión de
Retrospectiva, donde los Gestores de Ejecución ponen de manifiesto todos
los puntos de mejora en los procesos que han detectado durante la fase y
se establece un plan de acción para solucionarlos. Hablaremos sobre estas
reuniones en el presente capítulo, en la sección de Mejora Continua.
5.7.1.3 Monitorizando y controlando otros riesgos
Durante la fase, el Director del Proyecto tendrá que resolver los
impedimentos que vayan apareciendo durante la ejecución y deberá seguir
atentos a los riesgos externos del proyecto, actualizando la lista de riesgos
o los planes de contingencia si es preciso como consecuencia progreso del
proyecto y el nuevo conocimiento generado.
5.7.2 Monitorizar y controlar el trabajo
En la planificación de la fase, los Gestores de Ejecución configuran la Pila de
la Fase, artefacto que será utilizado durante la fase para gestionar el
trabajo que deben desempeñar. Para visualizar y actualizar la Pila de la
Fase, se utiliza una herramienta de gestión visual llamada Panel de Tareas.
5.7.2.1 Panel de Tareas
La Pila de la Fase, como ya se ha hablado, consta de los “n” primeros
elementos de la Pila del Producto y su descomposición en tareas. Esta
herramienta sirve para visualizar y gestionar esta información de un modo
sencillo. Consta de:
Una columna en la que se sitúan los elementos de la Pila del
Producto seleccionados para la presente fase.
Varias columnas para albergar las tareas y sus diferentes estados.
Típicamente se suelen incluir tres estados para las tareas:
o Pendiente: Esta columna alberga inicialmente las tareas en la
que se descompone cada elemento de la Pila.
o W.I.P. (work in progress) o “en progreso”: cuando una
tarea comienza a ser ejecutada, se coloca en esta columna.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 123 de 141
Versión 3.2
Algunos equipos limitan el número de tareas que se pueden
colocar aquí, tal como se hace en Kanban, para evitar que
existan demasiados frentes abiertos y forzar a que se
resuelvan los impedimentos que hacen que ese trabajo en
ejecución no se haya finalizado.
o Terminado: Este es lugar para las tareas que se han
finalizado completamente. Cuando todas las tareas de un
elemento de la Pila se han terminado y se cumplen los criterios
de satisfacción de ese elemento, se puede trasladar la ficha
que simboliza el elemento de la pila a esta columna, para
mostrar que se ha terminado su ejecución.
Figura 5.1: Diseño básico de un Panel de Tareas
Sea por medios físicos o por medios digitales, lo ideal es que el panel esté
visible en todo momento y sea sencillo interactuar con él. Algunos equipos
añaden más estados, en función de la naturaleza de su trabajo, como por
ejemplo “en pruebas”. Lo ideal es que cada equipo pruebe diferentes
configuraciones hasta encontrar el diseño que le sea más útil.
El Panel de Tareas ofrece mucha información con un solo vistazo. En el
panel de la figura vemos, cómo ya se ha entregado un elemento de la pila,
actualmente hay tres tareas en progreso y queda mucho trabajo todavía
pendiente. Pero, dada esta información, ¿el equipo va bien o va mal
respecto a lo planificado? Necesitamos una herramienta adicional para
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 124 de 141
Versión 3.2
cruzar la información de progreso con el tiempo, y esa el diagrama de
quemado (o burndown) de la fase, que explicamos en el siguiente epígrafe.
5.7.3 Controlar el cronograma | Seguimiento del
desempeño
La información del panel es rica, pero en términos de seguimiento y control,
nos falta un dato importante para llevar las riendas de la fase. Y es el
tiempo. Sería interesante cruzar la carga de trabajo terminada con el
tiempo restante para conocer el progreso real respecto al tiempo.
5.7.3.1 Diagrama de quemado o burndown
La información del panel es rica, pero en términos de seguimiento y control,
nos falta un dato importante para llevar las riendas de la fase y del
proyecto. Y es el tiempo. Sería interesante cruzar la carga de trabajo
terminada con el tiempo restante para conocer el progreso real respecto al
tiempo.
Para ello, utilizamos el diagrama de quemado o burndown. En el eje vertical
se sitúa el trabajo restante, típicamente medido en puntos de historia. En el
eje horizontal se sitúa el tiempo. Entre ambos ejes se traza una línea que
indica el progreso ideal.
Figura 5.2: Diagrama de quemado o burndown
Al final de cada jornada, se actualiza el burndown. Si la gráfica está por
encima de la línea de progreso ideal (en el ejemplo, en los cuatro primeros
días), nos indica que nos estamos retrasando respecto a lo planificado. Si la
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 125 de 141
Versión 3.2
gráfica está por debajo (en el ejemplo en el sexto día), indica que nos
estamos adelantando.
Si la distancia entre la gráfica y la línea ideal es muy acusada, y eso nos
hace prever que no vamos a entregar lo planificado durante la fase o que
vamos a finalizar el trabajo antes de tiempo, es momento de informar al
Gestor de Expectativas para aclarar las expectativas cuanto antes.
En el segundo caso, cuando se prevé tiempo de trabajo adicional, se pide
que el Gestor de Expectativas confirme la prioridad de la Pila del Producto,
para aprovechar el tiempo restante avanzando en la producción de más
características.
5.7.4 Controlar los costes
El Director del Proyecto debe mantener un estrecho control sobre los costes
de gestión del proyecto y comprender por qué aumentan o disminuyen
sobre el presupuesto aceptado. Asimismo, el Gestor de Expectativas debe
llevar a cabo su responsabilidad de priorizar las características
potencialmente entregables teniendo en cuenta los costes asociados a la
producción de cada una de estas características. Los Gestores de Ejecución
deben informar cuando el valor real del coste necesario para producir una
característica sobrepasa el estimado en tal medida que influirá en el trabajo
comprometido para la fase. De este modo se toman decisiones tempranas
de adaptación respecto a las expectativas de entrega.
5.7.5 Asegurando la calidad
A la hora de producir una característica, los Gestores de Calidad no pueden
darla por terminado hasta que no se aseguran que cumple las condiciones
de satisfacción acordadas para esa característica y que su integración con el
resto del producto es correcta y no impacta negativamente en el mismo.
5.7.6 Comunicaciones
Entre los Gestores de Ejecución debe existir el mayor ancho de banda
posible para favorecer su interacción. Los principales puntos de
comunicación entre el Gestor de Expectativas y los Gestores de Ejecución se
sitúan al principio y al final de la fase, en la Reunión de Planificación de la
Fase y en la Reunión de Revisión. No obstante, el Gestor de Expectativas
debe estar disponible durante la ejecución de la fase.
El Director del Proyecto debe asegurar la fluidez y la efectividad de estas
interacciones para reducir los costes asociados a la falta de información y
los malentendidos.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 126 de 141
Versión 3.2
5.8 Cierre de la Fase N
5.8.1 Control y cierre de la calidad
Se ha finalizado la fase y todo el esfuerzo del equipo ha cristalizado en un
entregable que supone un incremento de la funcionalidad del producto final,
representado por una serie de características que se planificaron en la
Reunión de Planificación de la Fase y que en al finalizar la misma están
terminadas.
Para validar el trabajo realizado se convoca la reunión de Revisión, donde
los Gestores de Ejecución presentan al Gestor de Expectativas el fruto de su
trabajo, para que éste compruebe que cumple las condiciones de
evaluación.
Son muy importantes estas reuniones porque permiten al equipo descubrir
dónde está el umbral de calidad aceptable del Gestor de Expectativas (y por
ende, del cliente); es decir, el límite en el que se le ofrece justo la calidad
que quiere con el mínimo coste.
En otras palabras, aquí se revisa el QUÉ, con objeto de mejorar el producto.
5.8.1.1 Objetivos
Presentar el resultado de la fase. Esto implica validar la calidad del
producto entregado verificando que se cumplen las condiciones de
satisfacción.
Obtener feedback para mejorar el producto en las siguientes fases.
5.8.1.2 Duración
Típicamente 4 horas como máximo.
5.8.1.3 Participantes
Gestor de Expectativas. Será quién valide las características
entregadas.
Gestores de Ejecución. Presentaran el su trabajo durante la fase.
Director del Proyecto. Se asegurará de que la comunicación es fluida
y de que se cumplen los objetivos marcados para la reunión en el
tiempo destinado para ello.
Otros interesados. Sus opiniones son valiosas a la hora de evaluar el
producto.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 127 de 141
Versión 3.2
5.8.1.4 Prerrequisitos
Disponer de un espacio suficiente como para que los participantes
puedan interactuar de forma cómoda y para que la muestra del
incremento de valor entregado se pueda llevar a cabo.
Todas las características presentadas en la revisión cumplen la
condición de “terminado”. Nada que no esté terminado se mostrará
en la revisión.
5.8.1.5 Organización
Es una reunión con un marcado carácter informal. Es decir, se deja a un
lado la solemnidad para que todos trabajen juntos en colaboración para
mejorar el producto y generar conocimiento aplicable al resto del proyecto.
Característica por característica, se van evaluando las condiciones de
satisfacción y se van vertiendo opiniones sobre el resultado final del trabajo.
Las características que no han pasado la revisión deberán de situarse de
nuevo en la Pila del Producto.
5.8.2 Informes de Desempeño
El Director del Proyecto debe conocer cuál es el desempeño del equipo en
cada fase y el progreso del proyecto respecto al trabajo planificado. Para
ello, se utiliza un diagrama de quemado o burndown para el proyecto.
El eje vertical mide el trabajo restante en todo el proyecto, y el eje vertical
representa las diferentes fases. Se traza una línea uniendo la cifra de
trabajo planificado inicialmente para el proyecto con el número que
representa las fases inicialmente planificadas, dando como resultado una
línea de progreso ideal.
Después de cada fase, se actualiza el diagrama. Al igual que en el diagrama
de fase, si la gráfica se sitúa por encima de la línea de progreso ideal, es
que nos estamos retrasando respecto al progreso ideal. Por el contrario, si
la gráfica se sitúa por debajo, vamos adelantados. Esta información facilita
la toma de decisiones.
5.8.3 Mejora continua | aprendiendo
Una vez hecha la revisión y antes de comenzar la siguiente fase, se celebra
una de las reuniones más importantes del proyecto: la Reunión de
Retrospectiva. Se trata, en este caso de revisar el CÓMO, con objeto de
mejorar los procesos implicados en la ejecución del proyecto. Si el
conocimiento extraído de la Revisión nos permite desarrollar cada vez un
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 128 de 141
Versión 3.2
mejor producto, el conocimiento generado en la Retrospectiva nos permite
mejorar el proceso por el que lo producimos.
La disposición con la que los Gestores de Ejecución encaran esta reunión
clave marca la utilidad y el aprovechamiento de la misma. El reconocimiento
del error, la aceptación del hecho de que todos somos vulnerables y la
voluntad de aprendizaje cobran su mayor sentido en la Retrospectiva.
5.8.3.1 Objetivos
Mejorar el proyecto consiguiendo el máximo impacto de mejora con
el mínimo esfuerzo.
5.8.3.2 Duración
Típicamente, 3 horas.
5.8.3.3 Participantes
Gestores de Ejecución: que son los responsables del CÓMO y quienes
mejor conocen el proyecto y sus procesos.
Director del Proyecto: que debe facilitar la comunicación y la
participación de todos los Gestores de Ejecución y asegurarse que se
actualiza el registro de lecciones aprendidas.
5.8.3.4 Prerrequisitos
Disponer de un espacio suficiente como para que los participantes
puedan interactuar de forma cómoda.
Debe celebrarse entre la reunión de Revisión de una fase y la reunión
de Planificación de la siguiente.
5.8.3.5 Organización
Independientemente de las técnicas utilizadas, una Retrospectiva tiene
generalmente las siguientes etapas:
Apertura
Recopilación de datos
Comprensión del problema
Establecimiento de un Plan de Acción
Cierre
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 129 de 141
Versión 3.2
5.8.3.5.1 Apertura
En esta fase, el Facilitador debe situar a los miembros del equipo de trabajo
en el contexto de la retrospectiva, procurando crear y mantener un
ambiente de participación y colaboración. Se repasan los objetivos de la
reunión, las fases de la retrospectiva y el tiempo disponible. Lo que el
Facilitador tratará en esta etapa es que todos se enganchen cuanto antes a
la dinámica de la reunión teniendo en cuenta el proceso y la limitación en
tiempo.
5.8.3.5.2 Recopilación de Datos
En esta etapa el reto principal es que los Gestores de Ejecución generen la
mayor cantidad de información sobre problemas e impedimentos
encontrados durante la fase. Hay diversas formas de llevar esta labor a
cabo, pero en cualquiera de ellas, los puntos de mejora son la materia
prima para el resto del proceso de retrospectiva. Es importante que de
forma individual y de forma colaborativa, los participantes tengan tiempo
para pensar y para opinar sobre los diferentes puntos de mejora
detectados. Para refrescar la memoria, el Director del Proyecto puede poner
sobre la mesa los impedimentos claves detectados durante las Reuniones de
Sincronización.
Al final de esta fase los Gestores de Ejecución priorizarán los puntos de
mejora para focalizar las energías, el tiempo y los recursos limitados en
resolver los más prioritarios.
5.8.3.5.3 Comprensión del Problema
Una vez se ha priorizado y decidido por tanto dónde se va a poner el foco
de la mejora, los esfuerzos se destinan a comprender bien la dimensión de
los problemas que se están tratando para intentar localizar su/s causa/s
raíces, de modo que puedan formular la mejor solución posible y evitar la
aparición de problemas derivados.
Es un proceso diagnóstico que admite la analogía con el ambiente médico.
Lo interesante no es únicamente mitigar los síntomas que se manifiestan,
sino identificar, localizar y erradicar la enfermedad que los provoca.
5.8.3.5.4 Establecimiento de un Plan de Acción
Es el momento de pensar en términos de solución. De aunar experiencia,
conocimiento y creatividad y aplicarlos a la resolución de problemas, de
forma colaborativa, con la participación de todos.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 130 de 141
Versión 3.2
Para ello, los Gestores de Expectativas habrá de proponer posibles
soluciones y seleccionar la mejor propuesta para llevarla a cabo. A partir de
ahí, tendrá que planificar cómo, quién y cuándo se van a implementar las
soluciones propuestas.
La etapa finaliza con el compromiso de todos los participantes respecto al
plan de acción elaborado.
5.8.3.5.5 Cierre
En esta última fase se repasa la reunión, los objetivos y cómo ha ido
evolucionando la sesión a medida que se han ido sucediendo las diferentes
etapas y aplicando el conocimiento generado. El Director del Proyecto debe
agradecer el esfuerzo de los miembros del equipo y felicitarles por los
objetivos logrados. Por último, es conveniente hacer una dinámica de
mejora continua de la retrospectiva, para poder mejorar también este
proceso.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 131 de 141
Versión 3.2
Capítulo 6
CIERRE DEL PROYECTO
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 132 de 141
Versión 3.2
6.1 Cierre Administrativo del proyecto y sus fases
Muchos proyectos sufren el síndrome del proyecto eterno. Continúan en el
sistema de gestión del portfolio de las empresas, consumiendo recursos,
sólo porque no se ha hecho un correcto cierre o se ha dejado morir
cuestiones abiertas.
Cerrar el proyecto implica finalizar todas las actividades de la dirección de
proyectos para completar formalmente el proyecto. Cuando el proyecto se
cierra, el Director del Proyecto deberá revisar toda la información anterior
procedente de los cierres de las fases previas para asegurarse de que todo
el trabajo del proyecto está completo y de que el proyecto ha alcanzado sus
objetivos.
Si el proyecto se ha dado por terminado antes de su culminación, se
deberán documentar y analizar las razones las acciones emprendidas.
Deberán actualizarse la información de procesos de la organización:
Los archivos del proyecto
Los documentos de cierre del proyecto o fase. Los documentos de
cierre del proyecto o fase, que consisten en la documentación formal
que indica la terminación del proyecto o fase y la transferencia de los
entregables del proyecto.
La información histórica y la de las lecciones aprendidas, para que
formen parte de la base de conocimientos de la organización para su
uso en el futuro, entre la que se incluye información sobre riesgos y
sobre técnicas y prácticas que han funcionado bien durante el
proyecto. Hemos dicho en varias ocasiones en el presente tratado
que el este tipo de proyectos genera no sólo el entregable final, sino
también conocimiento sobre el mismo y sobre los procesos implicados
que gracias a su registro pasan a formar parte de los activos de la
organización.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 133 de 141
Versión 3.2
Capítulo 7
COMPLEMENTANDO EL CONOCIMIENTO
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 134 de 141
Versión 3.2
7.1 Contratos Ágiles
Las reglas del juego en este tipo de proyectos se acuerdan libremente por
ambas partes para crear mejores condiciones posibles para finalizar con
éxito el proyecto. El contrato es un documento que refleja estas reglas del
juego.
En demasiadas ocasiones los contratos representan una competición en la
cual el objetivo de cada una de las partes es dejar en desventaja a la otra
parte, especialmente cuando las cosas van mal.
Muchas organizaciones públicas y privadas, sobre todo de tamaño
considerable, tienen condiciones manifiestamente injustas que deben
aceptarse para comenzar a trabajar con ellos. Incluso los contratos que
parten de una negociación previa no siempre intentan llegar a una situación
ganar-ganar.
Un contrato distribuye el riesgo y refleja la confianza entre las partes. ¿Qué
ocurre cuando algo sale mal? ¿Quién paga cuánto si el proyecto es más
difícil de lo esperado? ¿Quién se beneficia si el proyecto se termina antes de
lo planificado?
Usar las reglas incorrectas puede ser perjudicial para el éxito del proyecto.
Las reglas malas llevan a precios irrealistas, tiempos imposibles o
expectativas que no se cumplen.
Los juegos ganar-perder suelen ser un cáncer para el éxito del proyecto. La
calidad casi siempre sale perjudicada. Hay que pensar muy cuidadosamente
qué grado de presión es la adecuada para el proveedor.
7.1.1 Evaluación de los contratos
Hay que poner especial atención a estas cuestiones:
¿Cómo está estructurado el contrato? ¿Cuáles son las reglas básicas
para el alcance de las entregas y la factura por ingresos?
¿Cómo se reparte los Riegos y las Recompensas entre el cliente y el
proveedor?
¿Cómo se gestionan los cambios?
¿Qué modelo de relación con el cliente fomenta: competitividad
(ganar-perder), cooperación (ganar-ganar), indiferencia (no me
importa si pierdes) o dependencia (si sale bien yo gano, si no tú
pierdes)?
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 135 de 141
Versión 3.2
7.1.2 Información que debe incluirse en el contrato
La necesidad de escribir en el contrato es inversamente proporcionar a la
confianza entre el cliente y el proveedor. A mayor confianza, menos habrá
que especificar. No obstante siempre es conveniente que aparezca en el
contrato las siguientes cuestiones:
Objetivos del proyecto y de la cooperación entre las organizaciones.
Un resumen de la estructura del proyecto – marco de trabajo
procesos, roles clave y atribuciones.
Personal clave y que se necesita de estas personas.
Pagos y facturación, incluyendo las cláusulas de bonus y
penalizaciones.
Terminación normal y temprana del contrato.
"Detalles legales". Dependiendo de las leyes locales y costumbres
legales, es posible que tenga que limitarse la responsabilidad civil,
especificar la ganancia, o incluir otros textos que se necesiten
legalmente.
Determinar el alcance en el contrato lo hace inflexible. Es mejor idea
especificar cómo se va a gestionar el alcance dejar los detalles fuera.
7.1.3 Algunos enfoques contractuales
7.1.3.1 Todo el riesgo para el proveedor: “Todo cerrado”
Esta base contractual es típica en concursos públicos o licitaciones, en los
que el cliente es una corporación con un poder considerable que cierra las
reglas del juego. Aquí se fijan los tres vértices del triángulo de hierro. Este
enfoque no admite cambios. Todo el riesgo lo asume el proveedor y no hay
ningún elemento que incentive al cliente a dar por finalizado el proyecto.
7.1.3.2 Todo el riesgo para el cliente: “Tiempo y materiales”
En este enfoque el cliente paga por tiempo y materiales sin fijar un
compromiso de alcance ni tope de coste, por lo que finalizado el tiempo
contratado es posible que ni siquiera se haya generado un entregable. El
proveedor no tiene ningún incentivo para entregar cuanto antes. Todo el
riesgo lo soporta el cliente.
Es una base utilizada en proyectos de outsourcing, aunque con este
enfoque, sin ninguna modificación, puede salir más rentable emplear
personas. El desequilibrio de riesgo es tan desfavorable para el cliente que
tiene sentido si existe mucha confianza con el proveedor.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 136 de 141
Versión 3.2
7.1.3.3 Riesgo limitado para el cliente: “Tiempo y coste
cerrados”
Este es otro enfoque en el que la confianza entre cliente y proveedor es
esencial. En este caso se establece una priorización en el alcance y se
contrata un tiempo determinado con un coste fijo. Esto no quiere decir que
se vaya a entregar todo el alcance, sólo que el proveedor trabajará en él,
siguiendo la prioridad establecida, sin ningún compromiso de hasta dónde
puede llegar a desarrollar. Esta base es utilizada en proyectos ágiles, pero
requiere una gran confianza del cliente respecto al proveedor.
7.1.3.4 Riesgo limitado y decreciente para el cliente: “Tiempo y
materiales por fases”
Se trata del enfoque “tiempo y materiales” con la limitación de que la
ejecución se realiza por fases incrementales, de modo que tras finalizar
cada fase el cliente tendrá un incremento del producto con valor para el
cliente. Limita el riesgo porque, aunque no existe un compromiso respecto
al alcance que se entregará en cada fase, al menos el cliente se asegura la
entrega en el tiempo fijado. A medida que el proyecto avanza y aplica el
conocimiento generado sobre el producto y sobre los procesos, afinando las
estimaciones y entregando a tiempo, la percepción de riesgo soportado por
el cliente va decreciendo.
7.1.3.5 Riesgo limitado y compartido: “Tiempo cerrado
progresivo”
Es una variante del “todo cerrado” muy simple. Se trata de dividir el
proyecto en varias partes. Se plantea un “todo cerrado” para la primera y
se evalúan los resultados. Con lo aprendido hasta la fecha se redefine la
siguiente parte. Esto permite aplicar los conocimientos generados en el
proyecto para las sucesivas planificaciones, con mejores estimaciones
gracias al aprendizaje.
7.1.3.6 Riesgo compartido: “target cost”
Este enfoque está especialmente recomendado para los proyectos con una
ejecución incremental por fases. Para su desarrollo es necesaria una gran
colaboración entre cliente y proveedor. Básicamente se toma como base
una planificación inicial del proyecto. Al tratarse de un proyecto con alta
incertidumbre, se asume que la estimación inicial estará equivocada. Por
tanto, para poder establecer un precio objetivo se calcula el coste en tiempo
que tendría la ejecución del proyecto, sin olvidar el factor de foco (es decir,
hay que añadir tiempos de reuniones y otras actividades necesarias). A
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 137 de 141
Versión 3.2
partir de aquí se establecen tres umbrales. Un tiempo estimado objetivo, un
tiempo optimista y un tiempo pesimista. Si el proyecto finaliza entre el
umbral optimista y el tiempo objetivo, se comparten los beneficios. Si
acabara entre el tiempo objetivo y el tiempo pesimista, se comparten los
costes. Por debajo del tiempo optimista, el riesgo es del cliente. Por encima
del tiempo pesimista, el riesgo es del proveedor.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 138 de 141
Versión 3.2
7.2 Claves de la comunicación
La comunicación efectiva es uno de los principios armónicos de este marco
de trabajo. Que se produzca de manera fluida, y sobre todo, efectiva,
impacta gravemente sobre el devenir del proyecto.
Su importancia suprema hace que merece la pena que en este punto
hablemos un poco más del proceso de comunicación desde el punto de vista
de la efectividad.
Se le atribuye a Jaques Lacan la frase “toda comunicación es un
malentendido”. Y no es ajena a la verdad, ni mucho menos, porque en todo
proceso comunicativo entre personas existe pérdida de información. El
emisor IMAGINA el mensaje, luego lo EMITE, se TRANSMITE por el canal y
se RECIBE por el receptor, que lo INTERPRETA para procesarlo. Muchísimas
veces el mensaje que el emisor imagina no coincide (en muchos casos ni se
le parece) con el que el receptor interpreta.
Y esto es algo tan obvio que es obviado, aun cuando sabemos que los
problemas de comunicación son unos de los factores de fracaso más
frecuentes en los proyectos.
Vamos a esbozar el proceso comunicativo para tener en cuenta las claves
necesarias para reducir la probabilidad de malentendidos en las
comunicaciones de nuestros proyectos.
A todos nos enseñaron en la escuela que el proceso de comunicación existe
un emisor, un receptor y un canal.
Figura 7.1: Esquema de Comunicación
En primer lugar, vamos a poner el foco en el canal y luego en dos
operaciones básicas que podemos hacer sobre él.
7.2.1 El Canal y su Ancho de Banda
El ancho de banda hace referencia a la cantidad de información que
podemos transmitir sobre el canal. En función del canal que utilicemos,
tendremos un ancho de banda u otro.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 139 de 141
Versión 3.2
No es lo mismo comunicar algo por carta que hacerlo en persona.
Generalmente, aumentando el ancho de banda del canal disminuimos la
probabilidad de que existan malentendidos y se ahorra mucho esfuerzo y
tiempo para lograr la efectividad en la comunicación.
De este modo, de una comunicación por carta, escrita y asíncrona, podemos
ir subiendo el ancho de banda, pasando por el email, el chat, el teléfono, la
videoconferencia, el cara a cara. A nuestro juicio, el mayor ancho de banda
que se puede lograr en las comunicaciones entre las personas es cara a
cara con elementos visuales, porque se aúna el lenguaje verbal, gestual con
el escrito y con el figurativo.
Es por eso que en los ambientes ágiles son tan importantes las reuniones y
los elementos de gestión visual, porque siempre se intenta procurar las
mejores condiciones para la comunicación, de modo que sea lo más efectiva
posible.
7.2.2 Comprender
Para comprender hace falta llevar a cabo correctamente una actividad para
la que la mayoría de las personas apenas hemos sido entrenadas: escuchar.
Hablamos de escuchar de verdad, no sólo de poner la oreja. Hablamos de la
escucha empática.
El ser humano trabaja con patrones a la hora de percibir la realidad. Y esto
es una gran ventaja en muchas situaciones. Si vemos por primera vez un
objeto con cuatro patas, asiento y respaldo, no nos hace falta haber visto
antes ese modelo para saber que es una silla.
Esta asombrosa habilidad nos permite procesar una gran cantidad de
información al instante para poder tomar decisiones (como por ejemplo,
reconocer el peligro para oír o enfrentarse a él). Sólo tenemos que fijarnos
de forma inconsciente en una serie de claves, y en base a nuestra
experiencia anterior reconocemos el objeto o la circunstancia.
La escucha empática es tan difícil porque supone deshacernos
conscientemente de esta gran habilidad de reconocimiento de patrones para
comprender realmente el mensaje que otra persona nos transmite como si
estuviéramos en el pellejo de esa persona (de ahí lo de empática).
Covey (1989) señala cuatro trampas en las que todos solemos caer en
nuestros procesos de escucha:
Interpretación: esta es la primera de ellas. Imaginemos que una
amigo nos cuenta que ha tenido problemas con su jefe y le
contestamos: “ah, ya, no me digas más, yo también he pasado por
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 140 de 141
Versión 3.2
eso”. Hemos cortado la comunicación, no hemos hecho más esfuerzo
por comprender realmente qué le pasó. Sólo oímos que ha tenido
problemas con su jefe, esta información la pasamos por el filtro de
nuestra experiencia y nuestra mente completa la historia.
Sondeo: se produce cuando hacemos preguntas a nuestro
interlocutor no para conocer realmente los detalles de su historia,
sino para confirmar la película que hemos interpretado en nuestra
mente.
Consejo: como tenemos claro nuestra película, nos permitimos dale
a la otra persona consejo sobre cómo debería actuar en base a
nuestra experiencia (sin conocer realmente el problema). Esto es
como prescribir una receta antes de diagnosticar la enfermedad.
Evaluación: por supuesto, nos tomamos la licencia de asentir o
disentir lo que dice o hace sin haberlo comprendido realmente.
El Director del Proyecto, como facilitador tiene que poner todo su esfuerzo
para hacer que cada uno de los miembros de su equipo sepa escuchar. Esto
evitará retrabajo, malentendidos, conflictos, impedimentos y energías
desaprovechadas.
7.2.3 Ser Comprendidos
Covey (1989) cita la filosofía griega para explicar cómo procurar ser
comprendido, con tres conceptos secuenciales:
Ethos: credibilidad personal, confianza que inspiramos.
Pathos: empatía, el lado emocional.
Logos: lógica, argumentos, parte racional.
Lo cierto es que nos enseñan a elaborar buenos argumentos en nuestras
exposiciones para convencer a nuestra audiencia. Pero cada vez más los
líderes empresariales trabajan los otros dos aspectos que son la base para
influir en otras personas.
Tratado para la Dirección y Gestión Ágil de Proyectos… Pág. 141 de 141
Versión 3.2
Tratado para la Dirección y Gestión Ágil de Proyectos, en entornos de alta incertidumbre Base de conocimientos para las
certificaciones SMA, SMP y SMT
Cómo aplicar realmente toda la teoría que vamos encontrando por el mundo, cómo
mejorar la situación de nuestros proyectos, antes incluso de iniciarlos, cómo conseguir
una dinámica exitosa dentro de los diferentes ciclos en los que nos envuelve la
incertidumbre, cómo convertir el caos en orden de manera sistemática, cómo mejorar
los resultados una vez declarado el fracaso, cómo cambiar una situación en la que no es
posible conseguir los objetivos trazados por otra en la que esos objetivos tracen nuestra
dinámica hacia el éxito de nuestro proyecto.
Versión 3.2 1-6-2011