archivo

Archivo de la etiqueta: Planificación

Este antipatrón se produce cuando ante un problema en la planificación del proyecto, generalmente por la existencia de retrasos respecto a la consecución de determinados hitos, se convocan reuniones para intentar dar una solución al problema. En dichas reuniones participará también miembros del equipo de proyecto que al estar en las mismas tendrán que dejar su trabajo habitual, produciéndose nuevos retrasos.

Cuando se producen estos nuevos retrasos, se vuelven a realizar reuniones para analizar la situación y así sucesivamente.

Se diferencia del “Parálisis del análisis” en que este último no se centra en aspectos de planificación, sino en la realización de sucesivas iteraciones para refinar los requisitos.

También resulta conveniente diferenciarlo del antipatrón “Morir planificando” ya que este último se centra por un lado en la planificación inicial del proyecto y por otro en la falta de flexibilidad en la adaptación de esa planificación a la realidad del proyecto. Bien es cierto que también podría extenderse al propio proceso de desarrollo, pero tendría un enfoque más generalista que la gestión de plazos (que es donde se centraría el antipatrón objeto de este artículo).

Ante situaciones de incumplimiento de plazos, claro que es necesario realizar un análisis con el objeto de detectar la naturaleza del problema y poder establecer medidas correctivas, pero el mismo no se puede basar exclusivamente en una sucesión de reuniones y las buenas intenciones que por regla general se declaran en las mismas y que después se quedan en solo eso, buenas intenciones.

Planificar es una actividad que nos suele gustar a muchos: poner las piezas en el tablero, determinar una estrategia, unas reglas del juego, unos plazos en los que desarrollarse el trabajo, etc…

Además es una actividad que considero necesaria en cualquier proyecto, pero eso sí, en la justa medida de lo que sea necesario.

Cuando la planificación supera lo que el proyecto requiere nos encontraremos de lleno con este antipatrón, ya que invertiremos más esfuerzo (y tiempo) del necesario para establecer un plan que después puede ser destruido por las propias contingencias del proceso de desarrollo.

También se considera que se llega a este antipatrón cuando no se es flexible ante una planificación inicial, conservándose a lo largo del proyecto pese a que se pueda apreciar que resulta absolutamente irreal.

Tendemos a pensar que cualquier retraso en el proyecto o tarea que estemos realizando la solucionaremos realizando un sobreesfuerzo en los días previos a la entrega.

A veces, sale bien, no lo niego. Sin embargo casi siempre se producen una de estas dos circunstancias: no se llega a tiempo y se tiene que solicitar un aplazamiento o lo que se entrega tiene una calidad nefasta.

Por supuesto, que de estas dos opciones, siempre es mejor solicitar el aplazamiento, sin embargo, suele pasar en muchos casos que tras ese primer aplazamiento, viene otro, que posiblemente tampoco sea el último. Ya sea porque el retraso era considerable o bien porque se aplica el mismo principio de dejarlo todo para el final en cada nuevo intervalo de tiempo establecido.

Los retrasos provocan pérdidas, que son menos que las entregas de mala calidad, pero cuando son muy prolongados en el tiempo, las pérdidas se pueden convertir en insostenibles y lo que es más grave, probablemente la presíón por la entrega provoque que la calidad de la tarea no sea buena, lo que hace que el problema, más que problema, sea una tragedia.

La planificación en los proyectos de desarrollo de software es un asunto controvertido, ya que por un lado las fechas están para cumplirlas pero por otro si situamos a las fechas como un fin del proyecto corremos el riesgo de perder el enfoque en lo más importante, que no es otra cosa que desarrollar un sistema que satisfaga las expectativas del usuario.

Hay que tener en cuenta que dentro de esas expectativas puede situarse que el producto esté en una fecha determinada porque fuera de ese umbral el mismo pierde o deja de tener sentido.

Son factores a tener en cuenta a la hora de calibrar el grado de flexibilidad o de rigidez de una planificación.

Sobre este aspecto Tom DeMarco y Tim Lister tienen la siguiente opinión (traducción libre): “Si no se cumple con la fecha de cumplimiento de un hito, la planificación estaba equivocada. No importa por qué no se ha cumplido con la fecha, ya que el propósito de establecer un calendario es planificar, no establecer objetivos”.

Se trata de una reflexión un tanto controvertida ya que habrá muchos que estéis de acuerdo y otros tantos que no. Y probablemente todos tengáis razón, ya que la importancia la define el proyecto y las expectativas del usuario y eso variará en cada caso.

Trabajamos en muchas ocasiones bajo planificaciones imposibles ya sea porque desde el principio la batalla estaba perdida o porque el propio devenir del proyecto ha dado lugar a situaciones que han provocado que la planificación inicial ya no sirva y quienes tienen poder de decisión no han querido o podido cambiarla.

Es decir, se puede partir de situaciones de alto riesgo de que no se cumpla la planificación o que estas situaciones sean sobrevenidas por contingencias en el proceso de desarrollo.

Debemos tener en cuenta que los proyectos presentan esa incertidumbre y que antes de que nos demos cuenta lo que parecía que estaba controlado, deja de estarlo. En esos momentos es cuando nos acordamos de los días de trabajo perdidos, ya sea por tareas que eran prescindibles, por decisiones equivocadas, porque tuvimos un mal día o porque se cayeron los servidores. Da igual la causa, los recordaremos.

En general es una mala política dejar los esfuerzos para el final, en el desarrollo de software es nefasto, por eso es fundamental mantener una regularidad en la productividad del equipo de trabajo e ir cumpliendo en lo posible los hitos establecidos.

Y es que los días perdidos no vuelven, ya lo dicen Tom DeMarco y Tim Lister en la siguiente reflexión: “Hay millones de maneras de perder un día de trabajo pero ninguna que te lo devuelva”.

Y es que los datos del Cutter Consortium son escalofriantes:

– El 62% de los proyectos superan la planificación inicial en más de un 50%.
– El 64% cuesta más del 50% de lo presupuestado.
– El 70% tenía errores críticos tras su lanzamiento.

¿Puede aguantar nuestra industria estos datos? Hasta ahora muchas empresas de desarrollo han ganado mucho dinero con este caos a la misma vez que nuestra profesión se ha desprestigiado.

El manifiesto ágil fue un acto de rebeldía ante esta situación y fue, en mi opinión, el punto de inflexión hacia otro escenario. La aportación de Barry Boehm, muchos años antes, con la publicación de su libro “Software Engineering Economics” asociando conceptos asociados a la economía al desarrollo de software, también me parece decisiva.

Pese a esto, se tardará todavía mucho tiempo en superar la crisis del software porque supone un cambio absoluto en la cultura de los desarrolladores y de las empresas.

Las prisas están reñidas con la calidad. Las tareas tienen un tiempo para llevarse a cabo, es cierto que no todo el mundo tarda lo mismo en hacerlas y que no todos les dan el mismo acabado, pero también lo es que esto no hace más que definir un umbral de tiempo para la realización de las mismas.

De ahí la importancia de planificar un proyecto de la mejor manera posible, de detectar desviaciones, de poner solución a las contingencias y de intentar adelantarse a problemas que puedan ocurrir.

Las prisas no solo afectan al resultado final sino a la propia productividad. Las prisas bloquean y hay que tener en cuenta que trabajar bajo presión y bajo la urgencia son cosas distintas.

Es mejor incumplir una planificación de manera controlada (salvo que el producto tenga que estar inexcusablemente en una fecha determinada, algo que por otra parte sucede en muy contadas ocasiones) que intentar cumplirla pase lo que pase, ya que al final, muy probablemente no se consiga un resultado satisfactorio y las posteriores correcciones requerirán un mayor esfuerzo.

Cuando se habla de prisas, urgencias, no viene mal recordar el algoritmo de planificación de Wexelblat.