Técnicas de dirección de proyectos

  • Ramon G. Sedó

  • Laura Benítez García

PID_00214573
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico, químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita de los titulares del copyright.

Introducción

La gestión de proyectos es un conjunto de actividades específicas que se emplean para la administración de los mismos. Estas actividades comprenden diversos aspectos:

  • Estimación del esfuerzo necesario para el desarrollo de un proyecto.

  • Planificación de tareas y recursos.

  • Control de tareas.

  • Seguimiento del proyecto.

  • Control de las incidencias.

  • Control de cambios.

Para el desarrollo de dichas actividades, es necesaria la utilización de técnicas específicas. Las técnicas presentadas en este módulo son las más usadas en la gestión de proyectos. La mayoría de las técnicas presentadas están basadas en las descritas en MÉTRICA versión 3, metodología desarrollada por el Ministerio de Administraciones Públicas español para el proceso de planificación de sistemas de información. El resto de las prácticas están basadas en otras metodologías de la gestión de proyectos, como el Project Management Body of Knowledge (PMBOK), del Project Management Institute (PMI).

1.Estructura de descomposición del trabajo o EDT (WBS –work breakdown structure–)

La técnica en la que se basa la planificación de la mayoría de los proyectos es la técnica denominada estructura de descomposición del trabajo o EDT (1) .
A partir de la EDT, se deducen los diagramas PERT y Gantt que permiten la planificación del proyecto.
En la organización de un proyecto, esta técnica permite estructurar las actividades y sirve de lista de comprobación de las tareas que hay que realizar en el proyecto, así como de herramienta de contabilidad analítica del mismo. Si a cada tarea se le asigna su coste correspondiente, permite llevar un control contable del proyecto.

1.1.Descripción

La EDT presenta una descomposición de las actividades de un proyecto según su naturaleza. Se representa como un gráfico jerárquico, un árbol, un agrupador de actividades: desarrollo, calidad, gestión, etc.
Los grupos de actividades sirven de soporte para el seguimiento del proyecto, tanto en tiempo como en costes, y constituyen un histórico útil para proyectos futuros.
El desglose del trabajo en grupos de actividades se realiza hasta que se obtienen actividades que permitan entender el trabajo que hay que llevar a cabo y la estimación de los tiempos y los costes de la realización de dicho trabajo.
El gráfico está ordenado de menor a mayor detalle. Lo construye el equipo de proyecto y asegura que todos conozcan el trabajo requerido.

1.2.Notación

Ejemplo
76529_m4_01.gif
En este ejemplo las actividades o tareas del proyecto se agrupan en n grupos de actividades principales formadas por agrupaciones de actividades específicas.
El paquete de trabajo 1 está formado por dos paquetes de trabajo, 1.1 y 1.2, que engloban tres actividades en el caso del paquete 1.1 y dos actividades en el caso del paquete 1.2.
El paquete de trabajo 1 podría ser el de las actividades de análisis; el paquete 2, el de las actividades de diseño; el paquete 3, el de las de desarrollo, y así sucesivamente.

2.Análisis de puntos función

El análisis de puntos función es una de las técnicas más utilizadas en la estimación de la duración de proyectos para la web.
Las técnicas de estimación tienen como objetivo calcular el coste total del desarrollo de un proyecto.
La estimación del coste de los productos de software es una de las actividades más difíciles y propensas a error. Es difícil hacer una estimación exacta de coste al comienzo de un desarrollo debido al gran número de factores conocidos o esperados que determinan su complejidad y desconocidos o no esperados que van a producirse en cualquier momento, determinando la incertidumbre.
Las técnicas de estimación ayudan en esta tarea y dan como resultado un número de horas de esfuerzo, a partir de las cuales se calculará el coste correspondiente. La estimación nos aportará un número de horas aproximado que habrá que combinar con los recursos para obtener la planificación de actividades en el tiempo y establecer los hitos del proyecto.
Las técnicas de estimación más fiables se basan en el análisis de puntos función. La técnica de puntos función permite la evaluación de un sistema de información a partir de un mínimo conocimiento de las funcionalidades y las entidades que intervienen en él.
Las características más destacables de esta técnica son las siguientes:

  • es una unidad de medida empírica,

  • considera el sistema como un todo que se divide en determinadas funciones,

  • es independiente del entorno tecnológico en el que se haya de desarrollar el sistema,

  • es independiente de la metodología que vaya a ser utilizada,

  • es independiente de la experiencia y del estilo de programación y

  • es fácil de entender por el usuario.

El resultado de la aplicación de esta técnica viene dado en puntos función, que posteriormente habrán de ser pasados a días de esfuerzo, para lo que sí que deberán tenerse en cuenta la experiencia del equipo de desarrollo y el estilo de programación, la aplicación de una u otra metodología y la tecnología.
Este cálculo de días por puntos función debe basarse en la experiencia adquirida en la valoración y la realización de sistemas anteriores, de manera que, con posterioridad a la finalización de cada proyecto, se debe actualizar el valor de conversión.
Entre las técnicas de estimación basadas en el análisis de puntos función, el IFPUG 4.4 (unadjusted functional size measurement method), también conocido como la norma ISO/IEC 20926:2003 Software engineering, definido por el International Function Point Users Group y evolucionado a partir de la propuesta original de Allan Albrecht en IBM, se está convirtiendo en el estándar de facto en el cálculo de puntos función.

2.1.IFPUG 4.4

Ha sido definido por sus creadores como el "método estándar para medir el desarrollo de software desde el punto de vista del usuario".
El método se basa principalmente en la identificación de los componentes del sistema informático en términos de transacciones y grupos de datos lógicos que son relevantes para el usuario en su negocio. A cada uno de estos componentes, les asigna un número de puntos por función basándose en el tipo de componente y su complejidad. El sumatorio de esto nos da los puntos de función sin ajustar. El ajuste es un paso final basado en las características generales de todo el sistema informático que se contabiliza.

3.Program Evaluation & Review Technique (PERT)

El objetivo del PERT (2) es establecer las dependencias entre las distintas tareas del proyecto para saber de qué manera han de encadenarse dichas tareas en la planificación. Estas dependencias o prelaciones se establecen a partir de las precedentes.

3.1.Descripción

El método PERT parte de la descomposición del proyecto en una serie de obras parciales o actividades, entendiendo por actividad la ejecución de una tarea que exige para su realización la utilización de recursos tales como recursos humanos, software y hardware...
Después del concepto de actividad, el método PERT establece el concepto de suceso. Un suceso es un acontecimiento, un punto en el tiempo, una fecha en el calendario. El suceso no consume recursos; sólo indica el principio o el fin de una actividad o de un conjunto de actividades.

3.2.Notación

Para representar las diferentes actividades en las que se descompone un proyecto, así como sus sucesos correspondientes, se utiliza una estructura de grafo. Los arcos del grafo representan las actividades y los vértices, los sucesos.
Así, el vértice 1 del diagrama que aparece a continuación indica el suceso inicio de la actividad A y el vértice 2, el suceso fin de dicha actividad. El arco que une los vértices 1 y 2 representa la propia realización de la actividad.
76529_m4_02.gif
Por otra parte, como se ha dicho, un suceso puede representar el principio o el fin de un conjunto de actividades. En efecto, en la figura siguiente el vértice 1 representa el suceso inicio de las actividades A, B y C.
76529_m4_03.gif
Y en la figura que aparece a continuación, el vértice 4 representa el suceso fin de las actividades A, B y C.
76529_m4_04.gif
Una vez descompuesto el proyecto en actividades, la fase siguiente del método PERT consiste en establecer las prelaciones existentes entre las diferentes actividades. Estas prelaciones indican el orden en el que deben ejecutarse dichas actividades. El caso más sencillo son las prelaciones lineales, que se presentan cuando, para poder iniciar una actividad, es necesario que haya finalizado previamente una única actividad (la precedente).
Observando la figura siguiente, se aprecia que para poder iniciar la actividad B es necesario que haya finalizado la actividad A. Es decir, el vértice 2 representa el suceso fin de la actividad A y, a la vez, el suceso comienzo de la actividad B.
76529_m4_05.gif
A continuación, estudiaremos el caso de las prelaciones que originan una convergencia. En el diagrama siguiente se representa este caso. Para poder iniciar la actividad D es necesario que se hayan finalizado las actividades A, B y C. Es decir, el vértice 4 representa el suceso fin de las actividades A, B y C y, a la vez, el suceso comienzo de la actividad D.
76529_m4_06.gif
El caso opuesto al anterior es el de las prelaciones que originan una divergencia, representado en el diagrama que aparece a continuación. En este caso, para poder iniciar las actividades B, C y D es necesario que se haya finalizado previamente la actividad A.
76529_m4_07.gif
Consideremos ahora las prelaciones siguientes: la actividad A es anterior a las actividades B, C y D, y dichas actividades (B, C y D) son anteriores a la actividad E. Una forma de reflejarlas es la que viene representada en el diagrama siguiente. En él se muestran las prelaciones anteriores correctamente. Pero esta representación puede resultar confusa, ya que las actividades B, C y D tienen el mismo origen y el mismo destino.
76529_m4_08.gif
Para resolver este problema, se puede recurrir a las actividades ficticias, como se muestra en el diagrama siguiente, en el que se distinguen perfectamente las actividades B, C y D, ya que las tres actividades, aun naciendo en el mismo vértice, mueren en vértices distintos.
76529_m4_09.gif

3.3.Ejemplo

Mediante el ejemplo siguiente, se puede realizar la construcción del diagrama PERT de un proyecto completo. Para ello, debe comenzarse por introducir los conceptos de suceso inicio del proyecto y de suceso fin del proyecto.
Se entiende por suceso inicio del proyecto aquel que, representando el comienzo de una o varias actividades, no representa, sin embargo, el fin de ninguna. Por el contrario, el suceso fin del proyecto es aquel que, representando el fin de una o varias actividades, no representa, sin embargo, el comienzo de ninguna otra actividad. A este suceso se le reconoce en el grafo, puesto que está representado por el único vértice al que llegan, pero del que no salen, arcos.
A continuación, se va a construir el grafo PERT de un proyecto cuyas actividades y las prelaciones existentes entre ellas son las siguientes:

  • A precede a C, D y E.

  • B precede a C.

  • C precede a K.

  • D precede a F y G.

  • E precede a J.

  • F precede a I.

  • G precede a H.

  • H, I y J preceden a L.

  • K precede a M.

  • L precede a P.

  • M precede a N.

  • N y P preceden a Q.

  • Q precede a R.

Para construir el grafo PERT, el primer paso debe ser recoger de una manera sistematizada la información contenida en el anterior conjunto de prelaciones. Para ello, existen básicamente dos procedimientos: la matriz de encadenamientos y el cuadro de prelaciones.
La matriz de encadenamientos consiste en una matriz cuadrada cuya dimensión es igual al número de actividades en las que se ha descompuesto el proyecto. Cuando un elemento de dicha matriz aparece marcado con una X, ello indica que para poder iniciar la actividad que corresponde a la fila que cruza ese elemento, es necesario que se haya finalizado previamente la actividad que corresponde a la columna que cruza dicho elemento.
 
Actividades precedentes
A
B
C
D
E
F
G
H
I
J
K
L
M
N
P
Q
R

A

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

B

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

C

X

X

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

D

X

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

E

X

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

F

 

 

 

X

 

 

 

 

 

 

 

 

 

 

 

 

 

G

 

 

 

X

 

 

 

 

 

 

 

 

 

 

 

 

 

H

 

 

 

 

 

 

X

 

 

 

 

 

 

 

 

 

 

I

 

 

 

 

 

X

 

 

 

 

 

 

 

 

 

 

 

J

 

 

 

 

X

 

 

 

 

 

 

 

 

 

 

 

 

K

 

 

X

 

 

 

 

 

 

 

 

 

 

 

 

 

 

L

 

 

 

 

 

 

 

X

X

X

 

 

 

 

 

 

 

M

 

 

 

 

 

 

 

 

 

 

X

 

 

 

 

 

 

N

 

 

 

 

 

 

 

 

 

 

 

 

X

 

 

 

 

P

 

 

 

 

 

 

 

 

 

 

 

X

 

 

 

 

 

Q

 

 

 

 

 

 

 

 

 

 

 

 

 

X

X

 

 

R

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

X

 
Es interesante observar que aquellas filas de la matriz en las que no aparece ninguna X indican las actividades que no tienen ningún precedente. Se trata de aquellas actividades cuyo suceso inicial coincide con el suceso inicio del proyecto (actividades A y B). Por otra parte, aquellas columnas en las que no aparece ninguna X indican las actividades que no tienen ninguna actividad siguiente, es decir, aquellas actividades cuyo suceso final coincide con el suceso fin del proyecto (actividad R).
El cuadro de prelaciones está formado por dos columnas. En la primera columna están representadas todas las actividades en las que se ha descompuesto el proyecto. En la segunda columna figuran las actividades precedentes de su homóloga en la primera columna. Con los datos del ejemplo se elabora el cuadro de prelaciones, que es el siguiente:
Actividad
Precendente

A

 

B

 

C

A, B

D

A

E

A

F

D

G

D

H

G

I

F

J

E

K

C

L

H, I, J

M

K

N

M

P

L

Q

N, P

R

Q
La actividad o actividades inicio del proyecto se reconocen en el cuadro de prelaciones por no tener ninguna actividad precedente (actividades A y B). La actividad o actividades fin del proyecto se reconocen por no aparecer en la segunda columna de dicho cuadro (actividad R).
A partir de la matriz de encadenamientos o del cuadro de prelaciones, se construye fácilmente el grafo PERT correspondiente. Para los datos del ejemplo, el grafo PERT está representado en el diagrama siguiente.
76529_m4_10.gif

4.Método del camino crítico

El método del camino crítico está formado por una serie de tareas que se deben completar a tiempo para que un proyecto finalice conforme a la programación.

4.1.Descripción

La mayoría de las tareas de un proyecto presentan un cierto tiempo de demora (holgura) y, por lo tanto, se pueden retrasar ligeramente sin afectar a la fecha de fin del proyecto. Las tareas que no se pueden retrasar sin que se modifique la fecha de fin del proyecto se denominan tareas críticas.
Para calcular la holgura de las tareas, el método del camino crítico calcula todas las fechas de inicio y finalización teóricas tempranas y tardías para todas las actividades de la red sin considerar limitaciones de recursos.
Las fechas tempranas indican la primera fecha en la que se puede iniciar o finalizar una tarea en función de sus relaciones de precedencia o en función de restricciones temporales. Las fechas tardías indican la última fecha en la que se puede iniciar o finalizar una tarea en función de estas mismas relaciones y restricciones.
La holgura se determinará realizando un análisis de recorrido hacia delante y un análisis de recorrido hacia atrás.
Las fechas de inicio y finalización tempranas y tardías resultantes indican los períodos dentro de los cuales debería programarse la actividad.
Las tareas que forman parte del denominado camino crítico son las tareas sin holgura, las tareas críticas, cuya modificación para resolver sobreasignaciones u otros problemas de la programación afectarán a la fecha de fin del proyecto.
En un proyecto el camino crítico es el recorrido de mayor duración y puede no ser único, es decir, en un mismo proyecto podemos tener más de un camino crítico.

4.2.Ejemplo

Una empresa desea desarrollar un nuevo sitio web para su portal de empleados. Las tareas descritas para realizar este desarrollo y sus duraciones son las siguientes:
Tarea
Después de
Duración de la tarea

A

-

7 días

B

A

3 días

C

D

2 días

D

A

4 días

E

B

2 días

F

C

2 días

G

D

6 días

H

E-F

1 día

I

G

5 días
El grafo PERT del proyecto es el siguiente:
76529_m4_11.gif
Los posibles caminos para llegar del nodo 1 al nodo 8 son los siguientes:

  • A-D-G-I = 7 + 4 + 6 + 5 = 22 días

  • A-D-C-F-H = 7 + 4 + 2 + 2 + 1 = 16 días

  • A-B-E-H = 7 + 3 + 2 + 1 = 13 días

Así pues, tenemos que el camino crítico es el formado por las tareas A, D, G e I.
76529_m4_12.gif
Si pintamos las tareas dentro de un cronograma obtenemos lo siguiente:

A

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

B

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

C

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

D

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

E

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

F

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

G

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

H

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22
Las tareas B, C, E, F y H de este proyecto muestran cierta holgura, puesto que pueden presentar algunas modificaciones temporales sin afectar a la fecha de finalización del proyecto. En cambio, cualquier modificación en la duración de las tareas A, D, G e I influirían directamente en la alteración de la fecha de fin de proyecto.

5.El diagrama de Gantt

El diagrama de Gantt o cronograma tiene como objetivo la representación del plan de trabajo, mostrando las tareas que se han de realizar, el momento de su comienzo y su terminación y la forma en la que las distintas tareas están encadenadas entre sí.

5.1.Descripción

El gráfico de Gantt es la forma habitual de presentar el plan de ejecución de un proyecto. Recoge en las filas la relación de actividades que hay que realizar y en las columnas, la escala de tiempos que se manejan, mientras que la duración y la situación en el tiempo de cada actividad se representan mediante una línea dibujada en el lugar correspondiente.

5.2.Notación

  • Es un modelo realizado sobre ejes de coordenadas, donde las tareas se sitúan sobre el eje de ordenadas (y) y los tiempos, sobre el de abscisas (x).

  • Cada actividad se representa con una barra limitada por las fechas previstas de comienzo y fin.

  • Las actividades se agrupan en fases y pueden descomponerse en tareas.

  • Cada actividad debe tener recursos asociados.

  • Los hitos son un tipo de actividad que no representa trabajo ni tiene recursos asociados.

  • Las actividades se pueden encadenar por dos motivos:

Pueden realizarse actividades en paralelo siempre que no tengan dependencia funcional u orgánica.

5.3.Ejemplo

El diagrama siguiente es un ejemplo típico de un diagrama de Gantt, en el que aparecen fases, actividades, tareas e hitos.
76529_m4_13.gif
Para que un diagrama de Gantt sea realista y fiable, debe ir acompañado de un gráfico que refleje la actividad de los técnicos (histograma de recursos) que componen el equipo del proyecto.

6.Técnicas de asignación de recursos

La asignación de recursos es una tarea fundamental en la planificación, ya que hay que considerar aspectos técnicos de cada recurso, como su disponibilidad, su capacidad de trabajo, sus impedimentos horarios, etc.
Es fundamental que los trabajos se descompongan hasta la unidad mínima de tratamiento, es decir, descomponer el proyecto en fases, las fases en actividades y las actividades en tareas, asignando una tarea a un recurso. No debe caerse en el error de asignar una actividad a varios recursos. De no hacerse así, es muy difícil considerar la plena ocupación de todos los recursos, y se pueden dar situaciones anómalas, como es tener un recurso una ocupación muy baja y otro una ocupación excesiva. Conviene que la planificación esté perfectamente depurada, pues de lo contrario se producen los problemas siguientes:

  • Se dilata innecesariamente el plazo de entrega,

  • se retiene sin trabajo a un número considerable de usuarios que podrían trabajar en otro proyecto y

  • se encarece considerablemente el coste del proyecto, ya que se tienen asignados unos recursos "que no trabajan" todo el tiempo.

Por ello, es necesario tener en consideración los aspectos siguientes a la hora de asignar recursos:

  • Cuantificar necesidades y fechas de incorporación de recursos.

  • Obtener un patrón que marque los límites del proyecto.

  • Considerar la capacidad, los conocimientos y la experiencia de cada recurso.

  • Considerar la complejidad, el tamaño y los requerimientos técnicos de cada tarea.

  • Asignar tareas sencillas a recursos con poca experiencia. Si se asignan tareas sencillas a recursos con mucha experiencia, se los estará infrautilizando.

  • Asignar tareas complejas a recursos con mucha experiencia. Si las tareas complejas le son asignadas a recursos con poca experiencia, perderán mucho tiempo preguntando a sus compañeros y, lo que es más grave, harán perder mucho tiempo al resto del equipo.

  • Construir el histograma de recursos para poder ver la coherencia de las asignaciones.

  • Tratar de asignar una tarea a un único recurso, descomponiendo cuanto sea necesario.

  • Vigilar que no haya vacíos en el histograma.

6.1.Patrón de límites

La técnica de patrón de límites tiene como objetivo establecer los límites de recursos aproximados. Para ello, una vez conocidos la estimación, el esfuerzo total y el plazo de entrega, hay que llevar a cabo las operaciones siguientes:

  • Establecer el esfuerzo en meses (con decimales).

  • Deducir la parte correspondiente a diseño, en la que se deciden los contenidos, los servicios y las funcionalidades, ya que es una fase con un tipo de actividades diferentes al resto.

  • Establecer la duración en meses (con decimales). Normalmente este dato se conocerá por el compromiso adquirido.

  • Deducir la duración correspondiente al análisis de actividades del proyecto.

  • Considerar que todo proyecto tiene tres situaciones claramente diferenciadas:

  • Seguidamente, distribuir los recursos:

Como consecuencia de ello, se obtiene el gráfico que aparece a continuación y que servirá para establecer los límites de la asignación de recursos.
76529_m4_14.gif

6.2.Histograma de recursos

El histograma de recursos es un gráfico sobre unos ejes de coordenadas, de manera que los recursos se colocan sobre el eje de las ordenadas y el tiempo, sobre el eje de las abscisas.
A medida que se incorporan recursos al proyecto, el gráfico aumenta y, al contrario, disminuye cuando son desasignados.
Ejemplo gráfico de un histograma de recursos
Ejemplo gráfico de un histograma de recursos

6.3.Planificación de actividades y recursos

Para realizar adecuadamente la planificación, es necesario observar lo siguiente:

  • Deben construirse paralelamente el diagrama de Gantt y el histograma de recursos.

  • Han de realizarse los encadenamientos funcionales a partir del PERT.

  • Los recursos deben asignarse:

  • Ha de considerarse el máximo de recursos que proporciona el patrón de límites para llevar a cabo el histograma de recursos.

  • El histograma de recursos deberá reflejar con exactitud los recursos utilizados en el diagrama de Gantt.

A continuación, podemos ver gráficamente cómo han de realizarse la planificación de actividades y la de recursos.
76529_m4_16.gif

7.Diagrama de Pareto

El diagrama de Pareto es una herramienta de representación gráfica que identifica los problemas más importantes en función de su frecuencia de ocurrencia o coste (dinero, tiempo...) y que permite establecer las prioridades de intervención. En definitiva, es un tipo de distribución de frecuencias que se basa en el principio de Pareto, a menudo denominado regla 80/20, que indica que el 80% de los problemas son originados por un 20% de las causas. Este principio ayuda a separar los errores críticos, que normalmente suelen ser pocos, de los muchos errores no críticos o triviales.
El diagrama de Pareto comunica de forma clara y evidente el resultado del análisis de comparación y priorización de los problemas más importantes.
La construcción del diagrama de Pareto consta de las etapas siguientes:
1) Decidir cómo clasificar los datos. Se pueden clasificar por tipo de defecto (forma muy usual de hacerlo), por máquina, por fase del proceso, por turno, etc.
2) Determinar el tiempo de recogida de los datos. Este tiempo de recogida puede hacerse en términos de horas, días, semanas o meses.
3) Obtener los datos y ordenarlos. En esta fase se debe preparar la hoja de recogida de datos.
4) Dibujar los ejes de coordenadas. Se colocan, en el eje vertical, la escala de medida de las frecuencias o el coste y, en el eje horizontal, las causas en orden decreciente de la unidad de medida.
5) Dibujar el diagrama. Es la representación gráfica de los datos recogidos en la hoja.
6) Construir una línea de frecuencia acumulada.
7) Hacer el análisis de Pareto. El diagrama pone de relieve los problemas más importantes sobre los que será necesario actuar.
Ejemplo
En este ejemplo de diagrama de Pareto, vemos que el 80% de los errores están causados por errores de tipo E, B y C.
Tabla de Pareto
Tipo de error
Número de errores
% del total
% acumulado del total

E

124

38,0

38,0

B

83

25,5

63,5

C

55

16,9

80,4

F

28

8,6

89,0

D

18

5,5

94,5

A

8

2,5

96,9

G

5

1,5

98,5

H

5

1,5

100

Total

326

100

 
Diagrama de Pareto
Diagrama de Pareto
Los diagramas de Pareto permiten identificar los mayores problemas y generar nuevos diagramas de Pareto individuales para ellos.
Si se emprenden acciones correctoras, debemos dibujar los diagramas de Pareto antes y después con objeto de comprobar los resultados alcanzados.
Por otro lado, siempre resulta muy útil realizar el análisis observando el coste de los defectos en términos monetarios, sobre todo si se pretenden reducir los costes de la no calidad. Para ello, construimos el diagrama de Pareto en términos de coste de eliminación de cada uno de los defectos o en términos de pérdidas económicas que suponen cada uno de los defectos. Esta forma de proceder nos permite conocer si la identificación y la eliminación de los problemas o defectos posibilita que alcancemos enormes beneficios o, al menos, que no incurramos en grandes pérdidas. En ocasiones, una cantidad pequeña de defectos provoca grandes pérdidas mientras que, por el contrario, una gran cantidad de defectos puede provocar pérdidas bastante reducidas.
La utilización de esta herramienta presenta las ventajas siguientes:

  • Permite observar los resultados de las acciones de mejora implantadas al comparar dos diagramas del mismo fenómeno en momentos distintos de tiempo.

  • Es una herramienta polivalente y fácilmente aplicable, no sólo en el control de la calidad, sino en cualquier ámbito.

  • Utilizada en presentaciones y reuniones, aumenta la eficacia y la rapidez de la comunicación, ya que permite identificar rápidamente y a simple vista el problema más grave.

8.Diagrama de causa/efecto

El diagrama Ishikawa o diagrama de causa/efecto se utiliza para recoger de manera gráfica todas las posibles causas de un problema o identificar los aspectos necesarios para alcanzar un determinado objetivo (efecto).
El uso de este diagrama, de gran impacto visual, muestra las interrelaciones entre un efecto y sus posibles causas de forma ordenada, clara, concisa y de un solo vistazo, permitiendo una mejor comprensión del efecto en estudio, incluso en situaciones muy complejas, puesto que centra la atención de todos los componentes del grupo de forma estructurada y sistemática.
Por su aspecto, también se denomina diagrama de espina de pescado (fishbone).
Fuente: Wikipedia Commons. Autor: VARGUX
Fuente: Wikipedia Commons. Autor: VARGUX
Para desarrollar el diagrama de causa/efecto se deben seguir los pasos siguientes:
1) Definir y determinar claramente el problema o efecto que va a ser analizado. El problema es algo que generalmente queremos mejorar o controlar. Deberá ser específico y concreto: incumplimiento con las fechas de instalación, cantidades inexactas en la facturación, errores técnicos, etc.
2) Identificar los factores o causas que originan el efecto. Ello se hace mediante una tormenta de ideas (brainstorming) a partir de la cual se clasifican estas causas según su categoría o naturaleza. Para clasificar las causas encontradas, a menudo se utilizan como referencia las categorías de las cuatro emes, definidas por Ishikawa: mano de obra, maquinaria, materiales y métodos. Estas categorías son los rótulos de las espinas.
3) Representación del diagrama. Una vez enumeradas todas las causas, debemos ir colocándolas en el diagrama agrupando las que sean de naturaleza similar.
4) Análisis de las relaciones de causa/efecto que derivan de la construcción del diagrama. Una vez identificadas las causas, debemos identificar las "causas más probables", puesto que no todas las causas que aparecen durante la tormenta de ideas están estrechamente relacionadas con el problema.
Entre otras aplicaciones, este diagrama puede utilizarse para conocer y afrontar las causas de los defectos, las anomalías o las reclamaciones; reducir costes; obtener mejoras en los procesos; mejorar la calidad de los productos, los servicios y las instalaciones, y establecer procedimientos normalizados (tanto operativos como de control).
A pesar de la aparente sencillez de esta herramienta, su aplicación presenta una serie de ventajas como las siguientes:

  • proporciona una metodología racional para la resolución de problemas,

  • permite sistematizar las posibles causas de un problema y

  • favorece el trabajo en equipo posibilitando que los trabajadores planteen de forma creativa sus opiniones y que la comunicación sea clara y eficaz.

Esta técnica de identificación de las posibles causas de un problema no aporta soluciones. El diagrama ayuda a pasar de opiniones a teorías comprobables, pero sólo la recopilación de datos sobre las causas más probables aportará información de cuál es la solución que se ha de tomar para resolver el efecto o problema.
Ejemplo de diagrama de espina de pescado para ''clientes insatisfechos''
76529_m4_19.gif

9.Gestión clásica de proyectos y nuevas maneras de plantearse la gestión de proyectos

La gestión de proyectos es un conjunto de actividades específicas que se usan para administrar el proyecto.
Este módulo trata de la gestión de proyectos desde un punto de vista clásico, pero hay enfoques y planteamientos nuevos que intentan evitar los errores más habituales que se cometen en la gestión de proyectos: las metodologías ágiles.
Hay que recordar que los productos multimedia, en general, son proyectos complejos. Aplicado al entorno del desarrollo de productos multimedia, podemos decir que un proyecto es complejo cuando tanto la tecnología que hay que utilizar para resolver un problema, como los conocimientos sobre los requisitos del proyecto no son conocidos de una manera clara al principio del proceso.
Los requisitos tienden a ser complejos con mucha facilidad. De hecho, podemos hablar de requisitos simples si:

  • El cliente los puede capturar todos y transmitirlos al desarrollador, y este es capaz de entenderlos completamente.

  • No existen varias partes interesadas en el proyecto con intereses divergentes.

  • El cliente sabe exactamente lo que necesita.

Como se puede suponer, esto difícilmente es alcanzable. Además, debemos tener en cuenta que los productos multimedia son desarrollados por personas que trabajan en equipo. Si las personas ya somos complejas desde el punto de vista individual, esta complejidad se incrementa cuando trabajamos en equipo.
En las metodologías tradicionales, también llamadas predictivas, se ha intentado luchar contra esta complejidad de manera que tanto los requisitos como la tecnología –los dos aspectos inherentes al desarrollo de productos multimedia– desaparecieran de la ecuación, y que dieran como resultado fases muy grandes de toma de requisitos, análisis largos de estos requisitos y contratos demasiados cerrados y restrictivos.
A pesar de los esfuerzos efectuados, es difícil luchar contra la complejidad de los productos multimedia y estas aproximaciones no han logrado que se hicieran mejores proyectos, sino que hubiera proyectos con problemas.
Teniendo esto presente, en el 2001 diecisiete ingenieros de alto nivel en el campo del desarrollo de software se reunieron en Utah para explorar y compartir cuál consideraban que debía ser el futuro del desarrollo de un producto multimedia. Dentro del grupo se encontraban muchos de los proponentes de metodologías emergentes en aquel momento, como Scrum, Extreme Programming, Crystal, Feature Driven Development y otros. Juntos coincidieron en el nombre para su movimiento: agile (ágil).
En esta reunión los integrantes constituyeron la Agile Alliance (Alianza ágil), y escribieron el Manifiesto for agile software development (popularmente, The agile manifiesto; en castellano, Manifiesto ágil), un conjunto de estamentos que han servido como una declaración de valores y principios que deben seguir las metodologías ágiles:

  • Personas e interacciones por encima de procesos y herramientas.

  • Software que funciona por encima de documentación exhaustiva.

  • Colaboración con el cliente por encima de negociación de contratos.

  • Respuesta al cambio por encima del seguimiento de una planificación.

Los valores ágiles parecen simples y obvios la primera vez que se producen, y continúan sin modificarse desde el día en que los fundadores de la Alianza ágil los publicaron como parte del Manifiesto ágil.
Los principios ágiles pueden ser considerados como una elaboración más detallada –o la aplicación práctica– de los valores ágiles que hemos enumerado anteriormente; forman la otra parte del Manifiesto ágil.
Estos doce puntos son los principios sobre los que se basa el desarrollo de software ágil, una buena práctica en los equipos que desarrollan por medio de metodologías ágiles, excepto la de revisar periódicamente la lista de principios para asegurarse de que se continúan siguiendo.
Principios del Manifiesto ágil
1) Nuestra prioridad principal es satisfacer al cliente mediante la entrega inicial y continua de software evaluable.
2) Son bienvenidos los cambios en los requisitos, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio como una ventaja competitiva del cliente.
3) Hay que liberar software a menudo, desde unas cuantas semanas hasta unos cuantos meses, con preferencia por la escala más corta.
4) La gente de negocios y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto.
5) Construimos los proyectos en torno a personas motivadas. Les ofrecemos el entorno y el apoyo que necesitan, y confiamos en que hagan el trabajo.
6) El método más eficiente y efectivo para compartir información con el equipo de desarrollo son las conversaciones cara a cara.
7) El software que funciona es la principal medida de progreso.
8) Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, los desarrolladores y los usuarios deben ser capaces de mantener el ritmo indefinidamente.
9) La atención continua a la excelencia técnica y al buen diseño mejoran agile.
10) La simplicidad –el arte de maximizar el trabajo no hecho– es esencial.
11) Las arquitecturas, los requisitos y los mejores diseños emergen de equipos autoorganizados.
12) En intervalos regulares, el equipo reflexiona sobre la manera de ser más efectivo y, en consecuencia, afina y ajusta el contexto.
Podéis encontrar el Manifiesto ágil, en la redacción original, en la siguiente dirección de internet: http://agilemanifesto.org.
Dentro del ámbito de la gestión ágil de proyectos hay que destacar dos conceptos: SCRUM y Kanban.

9.1.Scrum. La conceptualización del producto. El día a día en un proyecto ágil

Scrum es un marco de trabajo para definir procesos que se caracteriza porque es ligero y fácil de entender.
Scrum no define un proceso concreto, sino que proporciona las herramientas para que cada equipo personalice el marco de trabajo y encuentre el proceso más adecuado a sus circunstancias.
Esta característica hace que Scrum sea apropiado para situaciones complejas, en la que es difícil predecir lo que pasará en el futuro y en las que, por lo tanto, será necesaria una gran capacidad de adaptación, como en el caso del desarrollo de productos multimedia.
Scrum es un método empírico y, por lo tanto, se basa en gestionar el proceso de desarrollo a partir de la experiencia (observación) y no por medio de predicciones. La consecuencia principal de esto es que las decisiones se toman teniendo en cuenta hechos conocidos, en vez de hechos hipotéticos.
Con Scrum estableceremos igualmente una predicción inicial pero durante la ejecución del proyecto nos iremos cuestionando, de una manera regular, la corrección de la predicción y la ajustaremos (por ejemplo, adaptaremos el calendario o modificaremos el conjunto de funcionalidades) para que se adecue a la realidad.
Cómo funciona Scrum
1) El product backlog
Un proyecto de Scrum es impulsado por una visión de producto elaborada por el propietario del producto, y se expresa en la pila de producto. El product backlog es una lista priorizada de lo que se requiere, por orden de valor para el cliente o negocio, con los elementos de más valor en la parte superior de la lista. El product backlog evoluciona durante la vida útil del proyecto, y los elementos se añaden, se quitan o son revaluados continuamente.
El equipo Scrum se compone de tres roles de Scrum:

  • El propietario del producto. Analiza las entradas de lo que debe ser el producto y lo traduce en una visión de producto.

  • El equipo. Desarrolla el producto previsto por el propietario del producto.

  • El Scrum máster. Tiene todo lo que se necesita para que el equipo Scrum logre el éxito. Esto pasa por eliminar los obstáculos de organización, facilitar las reuniones y actuar como un guardián para que nadie obstaculice el trabajo del equipo.

2) El sprint
Scrum estructura el desarrollo de productos en ciclos de trabajo llamados sprints, repeticiones de trabajo que normalmente duran entre una y cuatro semanas. Los sprints tienen una duración determinada; nunca se extienden más allá de la fecha fijada al principio, independientemente de que el trabajo planificado por el sprint se haya completado o no.
3) Planificación del sprint
A comienzos de cada sprint, se lleva a cabo la reunión de planificación del sprint. El propietario del producto y el equipo Scrum (con la facilitación del Scrum máster) revisan la pila de producto y discuten los objetivos y el contexto de las historias de usuario, mientras que el equipo Scrum selecciona los elementos de la pila de producto que se comprometen a hacer para el final del sprint, partiendo de la parte superior de la pila de producto, donde se hallan los elementos de priorización más alta.
Cada elemento seleccionado en la pila de producto se descompone después en una serie de tareas individuales. La lista de tareas se registra en un documento llamado sprint backlog.
4) Reunión diaria de Scrum
Una vez que ha empezado el sprint, el equipo Scrum se dedica a otra de las prácticas principales de Scrum: la reunión diaria de Scrum, o daily stand-up en la denominación original en inglés. Se trata de un encuentro breve (de quince minutos, como máximo) que se lleva a cabo cada día de trabajo a una hora determinada. Todos los miembros del equipo asisten a él. En esta reunión se presenta la información necesaria para inspeccionar el avance desde el día anterior. Esta información puede dar como resultado una replanificación y debates sobre la funcionalidad después del daily stand-up.
5) Revisión del sprint y retrospectiva
Una vez finalizado el sprint, se lleva a cabo la reunión de revisión de este, en la que el equipo Scrum y las partes interesadas inspeccionan lo que se ha hecho durante el sprint y lo discuten. En esta reunión, están presentes el propietario del producto, los miembros del equipo y el Scrum máster, además de los clientes, gente de negocios, expertos, ejecutivos y cualquier otra persona interesada.
Después de la revisión del sprint, el equipo se reúne para la retrospectiva del sprint, una oportunidad para que el equipo discuta lo que ha funcionado bien durante el sprint y lo que no funciona, y se pongan de acuerdo en los cambios que hay que intentar hacer en el sprint siguiente para ser más productivos.
76529_m4_20.gif

9.2.Kanban como sistema de gestión del trabajo en curso

Derivado de la combinación de las dos palabras japonesas Kan, que significa ‘visual’, y Ban, que significa ‘tarjeta’, nace el término Kanban, con el que se denomina una metodología de producción u organización del trabajo que se basa en señales visuales para gestionar el esfuerzo y la dedicación de nuestro equipo de producción. Kanban permite al gestor del equipo de producción multimedia identificar aglomeraciones en la producción, mejorar el tiempo de servicio de tareas y optimizar la calidad en el proceso de producción.
Kanban es un sistema de gestión en el que se produce exactamente la cantidad de trabajo que el sistema es capaz de asumir.
Kanban es un sistema de gestión del trabajo en curso (WIP (3) ), que sirve principalmente para asegurar una producción continuada y sin sobrecargas en el equipo de producción multimedia y en el que se produce exactamente la cantidad de trabajo que el sistema es capaz de asumir. También es un sistema de trabajo justo a tiempo (just in time), que permite evitar excedentes innecesarios de stock, lo que en la gestión de proyectos multimedia equivale a una inversión innecesaria de tiempo y esfuerzo en aquello que no necesitaremos (o, simplemente, es menos prioritario) y así no se sobrecargará al equipo.
Kanban es una aproximación a la gestión del cambio organizativo. No es un proceso de desarrollo de productos multimedia o de gestión de proyectos. También es una aproximación a la introducción de cambios en el ciclo de vida de desarrollo de productos multimedia o metodología de gestión de proyectos ya existente. Con Kanban se empieza con cualquier cosa que esté en curso en la gestión del equipo de producción, no hay que empezar de cero en la organización de una empresa para adoptar este sistema.
En la gestión del trabajo en curso con Kanban, se busca un concepto clave: limitar el trabajo en curso. Está demostrado que si se gestiona mucho trabajo en curso a la vez, los índices de calidad disminuyen drásticamente. En la producción de proyectos multimedia, aumentar el trabajo en curso implica incrementar la cantidad de errores que tendrá este proyecto multimedia, a consecuencia de la poca concentración que los desarrolladores podrán dedicar a las tareas.
Limitar el trabajo en curso implica un aumento considerable de la calidad del software desarrollado en la producción de un proyecto multimedia.
Limitar el trabajo en curso mediante la gestión del trabajo con Kanban también tiene otra consecuencia importante, y es que disminuimos el tiempo de servicio de una tarea desde que entra en el sistema hasta que sale de él. Reduciendo la cantidad de trabajo en curso, conseguimos que el enfoque en cada una de las tareas sea mayor y el conjunto del tiempo dedicado a todas sea inferior al utilizado si se asumen todas al mismo tiempo.
Por lo tanto, podemos decir que Kanban, por medio de una disciplina estricta de limitar la cantidad de trabajo que el equipo lleva a cabo a la vez, nos devuelve unos índices de calidad más altos y un tiempo de servicio bastante más bajo.
Un panel Kanban típico se implementaría tal como se muestra en la imagen siguiente:
76529_m4_21.gif

Bibliografía

Bataller, Alfons (2010). La gestió de projectes. Barcelona: Editorial UOC.
Durán Rubio, S. E. (2003). "Puntos por función. Una métrica estándar para establecer el tamaño del software". Boletín de Política Informática (n.° 6). México: Ed. Instituto Nacional de Estadística y Geografía de México.
Krug, Steve (2006). No me hagas pensar: una aproximación a la usabilidad en la web Madrid: Pearson Educación.
Ministerio de Administraciones Públicas. Metodología MÉTRICA versión 3.
Nielsen, Jakob (2000). Usabilidad: diseño de sitios web Madrid: Prentice Hall.
Nielsen, Jakob (2000). Usabilidad: [prioridad en el diseño web = (prioritizing web usability)] Madrid: Anaya Multimedia.
Nielsen, Jakob (2000). Técnicas de eyetracking para usabilidad web Madrid: Anaya Multimedia.
Pereña Brand, J. (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.
Usability guidelines. Cambridge, MA: Information Services and Technology. Disponible en: http://ist.mit.edu/services/consulting/usability/guidelines