Liderazgo / Dirección de proyectos

Existen ciertos comportamientos de la condición humana que pueden alterar inevitablemente los tiempos y el propio desarrollo de las tareas de un proyecto. Navegando me encontré con este post de Diseño Social en el que he hallado algo de ciencia con la que acompañar mi exposición.

Primer error al repartir las tareas: ¿cómo identificar correctamente los individuos a los que encomendar la ejecución de determinadas tareas de un proyecto?

El efecto Dunning-Kruger dice que los individuos con escasa habilidad o conocimientos sufren de un sentimiento de superioridad ilusorio, considerándose más inteligentes que otras personas más preparadas, midiendo incorrectamente su habilidad por encima de lo real, por el contrario, los individuos altamente cualificados tienden a subestimar su competencia relativa, asumiendo erróneamente que las tareas que son fáciles para ellos también son fáciles para otros.

Dunning-Kruger: los individuos con escasas habilidades sufren de un sentimiento de superioridad ilusorio, por el contrario, los individuos altamente cualificados tienden a asumir que las tareas que son fáciles para ellos también son fáciles para otros.

Como director de proyectos, al repartir las tareas, seguramente alinearas los requerimientos con las habilidades de cada individuo pero ten cuidado, podrías estar afectado tanto por la primera parte del efecto Dunning-Kruger como de la segunda.

Por la primera porque podrías encomendar trabajos a la persona que da la sensación que es la que más sabe sobre algo porque así lo aparenta. Y por la segunda porque podrías pensar que si para ti es una tarea fácil también lo va a ser para los demás.

La solución no es otra que conocer muy bien al equipo, saber de lo que es capaz cada uno de sus integrantes y fomentar por todos los medios la compartición de conocimientos entre ellos.

Segundo error al establecer los tiempos: ¿por qué las tareas de un proyecto siempre toman como mínimo el máximo del tiempo disponible para hacerlas? (Aún y habiendo hecho bien el enunciado anterior)

Tal como dispone la Ley de Parkinson “el trabajo se expande hasta llenar el tiempo disponible para que se termine”. Para muchos, cuando más tiempo se tenga para hacer algo, más divagará la mente y más problemas serán planteados.

Parkinson: el trabajo se expande hasta llenar el tiempo disponible para que se termine.

Podríamos añadir otra ley del mismo Parkinson que dice que “el tiempo dedicado a cualquier tema de la agenda es inversamente proporcional a su importancia”, lo que viene a avalar la teoría que cuando más tiempo se tenga para hacer algo, más divagará la mente, y en cambio no se dedicará, proporcionalmente, el tiempo necesario a los temas importantes.

El recurso para corregir este problema es acortar los tiempos asignados para el desarrollo de las tareas sencillas adelantando su fecha de vencimiento, de esta forma, si acaba sobrando, podrá reasignarse a las tareas complicadas o importantes.

Tercer error en la ejecución de las tareas: ¿por qué algunas de las tareas se hacen mal y hay que repetirlas? (Con lo que se va a requerir más tiempo del disponible)

En el libro Gödel, Escher, Bach: un eterno y grácil bucle, Douglas Hofstadter, enuncia una ley que ha adquirido cierta popularidad en ambientes de programación: la Ley de Hofstadter. Dicha ley dice que “hacer algo te va a llevar más tiempo de lo que piensas, incluso si tienes en cuenta la ley de Hofstadter”.

Hofstadter: hacer algo te va a llevar más tiempo de lo que piensas, incluso si tienes en cuenta la ley de Hofstadter.

De forma general, la gente va a tratar de eludir las tareas menos atractivas y empezará siempre por las más interesantes, dejando inevitablemente menos tiempo al resto de tareas que podrían haber sido catalogadas como críticas. Además, en cuanto a su realización, pondrá mayor atención en lo que sabe que va a ser inspeccionado, no en lo que tu esperas que lo haga.

Por lo tanto, al analizar la lista de tareas pendientes individualmente hay que establecer el orden de ejecución y catalogarlas por importancia.

Conclusión

Resumiendo, estos son los puntos importantes en relación con la lista de tareas de un proyecto:

  1. Establecer apropiadamente el grado de complejidad o importancia.
  2. Dividir tareas complejas grandes en otras más pequeñas, si es posible.
  3. Acortar los tiempos de las tareas sencillas y guardarlo para reasignar.
  4. Alinear requisitos de las tareas con habilidades y conocimientos individuales.
  5. Fijar el orden de ejecución.

Además, en cuanto al efecto Dunning-Kruger, y de acuerdo con el post de Diseño Social mencionado al principio, se trata de comprender que probablemente es un tema de formación:

  1. El consejo es apostar por la formación continua y de calidad para mejorar el conocimiento del capital humano y la capacidad para reconocer las carencias propias que tenemos que solucionar.
  2. Si pueden ser entrenados para mejorar sustancialmente su propio nivel de habilidad, estos individuos pueden reconocer y aceptar su falta de habilidades previa.
  3. Hay que formar al individuo tanto para que pueda entender el problema como para que se dé cuenta de verdad de que antes no lo entendía.

 

Anuncios

Medir el muro construido (avance del proyecto)

En los proyectos informáticos es indispensable medir los metros de muro construidos, como decía un colega. Pero es obvio que al no poder medir algo físico, la subjetividad será el valor predominante: Para el programador está 90% acabado pero para el cliente apenas supera el 60%.

Desde mi punto de vista, el grado de avance es uno de los valores más importantes en la gestión de proyectos, ya que de él se deriva el KPI Desvío previsto. Su valor determina si vamos a ser capaces de terminar dentro del presupuesto y se mide calculando el diferencial entre el avance y el ejecutado en un momento dado.

% Desvío previsto = % Avance – % Ejecución

Por ejemplo, siguiendo con el enunciado del primer párrafo, y tomando como correcto el criterio sobre el grado de avance el del cliente, en un proyecto de 100 horas presupuestadas, hay 90 ejecutadas y un grado de avance del 60%. El presupuesto restante es de 10 horas pero quedan 40 por hacer, lo que significa un déficit previsto de 30 horas, un -30% de desvío previsto según la fórmula propuesta, 60% – 90%.

Por lo tanto, es importante certificar el grado de avance bastante a menudo porque en un momento determinado el % de desvío previsto se puede poner en negativo y cuando antes se detecte, antes se podrá gestionar.

KPIdesvioprevisto

En el ejemplo, en la semana 7 se lleva un 55% ejecutado pero con un grado de avance certificado del 50%, con lo que el % de desvío previsto ha empezado a ser negativo. Alarma importante para los responsables del proyecto que deberán empezar a gestionar las correcciones a aplicar.

¿Cómo certificar el grado de avance en proyectos informáticos?

La medición de “los metros de muro construidos” sólo es posible comparando los requisitos previamente aceptados con los realmente construidos, con lo que, cuanto menos conceptuales y más detallados sean, mejor se podrá realizar la comparación confrontándolos uno a uno. En la toma de requisitos hay que bajar a un nivel de detalle suficiente que permita inventariar, chequear y validar cada requisito construido y posteriormente aceptado por el cliente.

Por ejemplo, si el requisito es -construir un proceso que asistirá al usuario para que a partir de los datos registrados pueda liquidarlos entre sí- se debe construir una lista a partir de las respuestas a las siguientes preguntas de ejemplo:

  • ¿Deben aplicarse filtros a los datos al abrir la pantalla? ¿Cuáles?
  • ¿Se permite que el usuario deje liquidaciones sin terminar?
  • Y en ese caso, ¿las puede recuperar un usuario distinto?
  • ¿Qué criterios se han de cumplir para que una liquidación se pueda realizar?
  • ¿Es necesario que las liquidaciones pasen a un histórico?
  • ¿La pantalla debe mostrar registros ya liquidados?
  • ¿La pantalla debe mostrar registros en proceso de liquidación de otros usuarios?
  • Y en ese caso, ¿hay que establecer estados o códigos de colores?
  • ¿Una liquidación se puede deshacer?
  • Y en ese caso, ¿debe cumplir algún criterio para que se pueda?
  • Y en ese caso, ¿se borra del histórico o se añade una marca?
  • ¿Qué pasa con los registros no liquidados? ¿Tienen caducidad?
  • Y en ese caso, ¿qué se debe hacer con ellos?

En los proyectos informáticos en ocasiones ocurre que se lleva un 20% ejecutado y un avance del 80% pero para terminar se deba invertir más del 80%. Es la famosa norma de que el 20% final del proyecto nos va a tomar más del 80% del tiempo.

La cuestión principal es determinar el grade de avance lo más ajustado posible a la realidad. Medir lo construido, como si fuera un muro.

Creo que esta situación se produce por la falta de una lista de requisitos más o menos exhaustiva, ya que es en el 20% final cuando la persona que verifica y valida echa en falta esos pequeños detalles que hace que el desarrollo sea plenamente funcional y debido a ello se produzca la diferencia de criterios, pues para el programador el desarrollo hace lo que se pidió (liquidar entre sí datos registrados) pero para el cliente no es funcional (no hay históricos, no se pueden deshacer en caso de error, etc.).