archivo

Archivo de la etiqueta: proyecto de desarrollo de sofware

¿Por qué hacer retrospectivas? A veces es necesario pararse a analizar si las decisiones, estrategias y comportamientos que se han adoptado están produciendo los resultados esperados, así como para analizar qué problemáticas y riesgos tenemos en el proyecto con el objeto de establecer una serie de medidas que permitan la mejora continua.

La vorágine de los proyectos nos llevan a tener un ritmo frenético de manera que, a veces, pararnos a analizar qué está pasando, nos puede hacer pensar que estamos perdiendo el tiempo, cuando justamente es al contrario porque la pérdida de tiempo, de esfuerzo y de dinero se produce precisamente por continuar políticas, estrategias o prácticas que no producen buenos resultados.

Se trata por tanto de adquirir conocimiento a través de la experiencia y con la objetividad (y subjetividad) de los resultados que estamos obteniendo. Una idea que teóricamente es muy buena en la práctica no tiene por qué proporcionar los resultados esperados en el contexto en el que estamos trabajando y a partir de ahí, si tenemos capacidad de autocrítica y de asumir nuestros errores, llegaremos a varias conclusiones interesantes: tener siempre en cuenta el contexto a la hora de tomar una decisión y de adoptar una determinada estrategia, que la idea en cuestión puede seguir siendo válida pero no resulta adecuada en estos momentos en el proyecto (y puede que también en otros proyectos con unas variables parecidas al nuestro) y, que por tanto, es necesario buscar otras soluciones.

Asunto muy controvertido. Por un lado se encuentra el hecho de tener a las personas el mayor porcentaje posible de su tiempo asignado a tareas facturables y por otro la certeza de que una persona que tiene su cabeza en muchos proyectos tiene su enfoque dividido y eso afecta a su rendimiento.

Estar en un 20% en un proyecto, un 5% en otro, un 50% en otro, un 10% en otro y un 15% en otro, no es ninguna exageración, incluso puedo quedarme hasta corto. Quien se haya encontrado o se encuentre en esta situación o quien dependa de personas que se encuentran en la misma sabrán lo que eso significa: el porcentaje final en cada proyecto será probablemente superior al asignado (lo que implicará overtime) y con un rendimiento en términos generales probablemente inferior al porcentaje final (y en consecuencia también inferior al asignado oficialmente).

Y eso si intentas equilibrar tu esfuerzo, si por las circunstancias terminas dedicando más esfuerzo a uno de esos proyectos que a los otros, vistes uno pero dejas sin nada al resto.

Cada cual sabe cuáles son sus límites pero en ningún caso se llegará a infinito y cuando son tantos los proyectos a los que estás asignado y menor es el porcentaje que puedes dedicar a los mismos más te estarás acercando al mismo.

Es complicado alcanzar el equilibrio entre ocupación máxima a nivel de facturación y asignación óptima a proyectos para que la productividad no se vea resentida (o muy poco resentida) pero el hecho de que sea difícil no quiere decir que no deba ser un objetivo.

Mary Poppendieck y Tom Poppendieck realizan la siguiente reflexión sobre este tema (traducción libre): “La asignación de personas a múltiples proyectos es una fuente de pérdidas. Cada vez que los desarrolladores de software cambian entre tareas, se pierde un tiempo significativo en volver a alinear los pensamientos y entrar en el flujo de la nueva tarea”.

Considero muy importante que las decisiones que se toman en un proyecto de desarrollo de software queden por escrito y que cuenten con la aprobación de las distintas partes afectadas por las mismas. De igual importancia que lo anterior es revisar todo lo que queda por escrito porque de igual forma que lo puedes utilizar en un futuro para exponer un determinado punto de vista también puede ser utilizado en contra tuya.

En muchas ocasiones a la hora de revisar acuerdos, las actas nos deparan sorpresas y si la hemos aprobado sin revisarla adecuadamente nos estamos arriesgando a encontrarnos posteriormente con ciertos matices que no reflejaron la realidad exacta de lo que se habló en su momento, lo cual puede traer consigo problemas al proyecto. No repasarse las actas es algo demasiado común, se considera algo prescindible, pero puedo asegurar que no lo es.

En desarrollos donde hay problemas entre cliente y proveedor la existencia de que los acuerdos queden por escrito resulta fundamental porque de lo contrario el débil estará siempre a expensas del más fuerte (también lo estará con la documentación por delante, pero por lo menos le permite jugar unas cartas que de otra manera no tendría a su disposición).

Edward Nash Yourdon popularizó este término en su libro “Death March: The Complete Software Developer’s Guide to Surviving ‘Mission Impossible’ Projects”.

¿Qué es un Death March Project? Según Yourdon todo aquel proyecto en donde algunas de las variables necesarias para el éxito del proyecto exceden un porcentaje importante la norma (el mismo Yourdon comenta que no hay una fórmula, ya que son muchos las factores que pueden intervenir en un proyecto de desarrollo de software, si bien considera que fluctuaciones de un 10% sobre las métricas normales que debería tener el proyecto no debería ocasionar un trastorno sensible en el mismo).

Algunas situaciones que pueden dar lugar a Death March Projects las tenemos por ejemplo con un proyecto que se intenta hacer en la mitad del tiempo necesario para desarrollarlo o con un presupuesto que es la mitad del necesario para llevarlo a cabo.

Lo peor de todo es que generalmente un valor inadecuado de estos parámetros tiende a arrastrar a otros por lo que el problema se multiplica.

A veces, una mala estimación del alcance del proyecto o unos cambios en las especificaciones pueden provocar esta situación, sin embargo, en la mayoría de las ocasiones donde existe un Death March Project, se sabe prácticamente desde que se está planificando que es imposible cumplir los objetivos.

Es más, de los casos anteriores, desde que se hace una oferta a un cliente se sabe que no se va a cumplir, dejando el problema a los que después se van a encargar del proyecto.

Es absolutamente necesario que cada uno de los hitos de un proyecto esté asociado a una fecha. Sin referencias el proyecto tendrá muchas posibilidades no solo de ser nefasto en lo económico sino de que los diversos entregables sean de escasa calidad (al no existir referencias, al final se pondrá una por parte del cliente cuando éste empiece a impacientarse que será además muy difícil de cumplir ya que el proyecto no habrá avanzado acorde a como debería haber ido, entre otras cosas, además porque se habrá cometido el error de no informar al cliente de cómo van las cosas).

Hay veces donde las fechas de los diferentes hitos (sobre todo, la entrega final del producto) no se pueden aplazar, pero en la mayoría de los casos sí que se pueden mover. La flexibilidad en las fechas de entrega si se utiliza de manera arbitraria producirá malos resultados, es decir, los equipos de desarrollo tendrán la impresión de que como nunca pasa nada y disminuirán su productividad, es decir, estaríamos en una situación similar a la ausencia de fechas.

Si se tiene que mover una entrega que sea por causas justificadas, como por ejemplo, que realmente el esfuerzo estimado no sea acorde con el que se requiere, modificaciones en los requisitos, cambios en el equipo de proyecto acordados entre cliente y proveedor, etc… y siempre poniendo un nuevo plazo que sea asumible por las dos partes y a la altura de lo que realmente le falta al hito (de equivocarnos la poner el nuevo plazo es mejor siempre que sea un poco por encima que por debajo). El nuevo plazo podrá ser reajustado de nuevo si hay causas que lo justifiquen y así sucesivamente.

Nunca hay que tener miedo de proponerle al cliente un aplazamiento. La mayoría lo entenderán si se les avisa con tiempo y se les justifica, ya que siempre será mejor tener un retraso razonable (salvo que la fecha de entrega sea inamovible por algún motivo) que recibir una entrega de peor calidad, ya que al final provocará problemas en el producto y en consecuencia mayores costes para el cliente y el proveedor.