archivo

Archivos diarios: enero 11, 2012

Productividad. Interesante palabra. Muy estrechamente ligada además a calidad y competitividad.

Pese a todo, olvidada, obviada y reducida a cenizas en muchas organizaciones.

Este antipatrón va sobre la productividad y viene a decir que en todo proyecto no es válida cualquier composición del equipo ni tampoco el nivel de ejecución de los trabajos es el mismo, de manera que nos encontraremos con proyectos donde el rendimiento de un miembro (o varios) del equipo (el antipatrón habla de programadores, pero entiendo que lo hace en sentido amplio, referiéndose al concepto de desarrollador, lo que lo hace extensible a todo el conjunto de personas que participan en él) es muy inferior al esperado, hasta el punto de ser su productividad neta en el proyecto negativa (se debe tener en cuenta que si se llega a ese nivel de productividad, el proyecto mejoraría con el simple hecho de prescindir de estas personas, sin necesidad de sustituirlas por otras; esto, como es lógico, hay que analizarlo en el contexto de cada proyecto: avance, complejidad, capacidad del equipo actual, plazos, etc…).

Dicho en otras palabras se genera más trabajo del que produce, principalmente por introducir una tasa de errores elevadas en el sistema, por codificar con alta deuda técnica, por provocar interrupciones frecuentes en el trabajo de los compañeros, por no asumir de manera adecuada sus responsabilidades, etc…

Quien no tiene en cuenta que esto puede ocurrir en un proyecto y no toma medidas, antes y durante su ejecución, está incurriendo en este antipatrón.

En un artículo anterior he definido el coeficiente de rozamiento o fricción como la fuerza que se ejerce en contra de nuestro avance en la consecución de los objetivos de un proyecto de desarrollo de software.

Esa fricción era el resultado de las condiciones iniciales del proyecto y de las contingencias que ocurren en el proyecto, si bien la inicial condiciona el resto del proyecto y en contadas ocasiones se producen reajustes que disminuyen su intensidad, la fricción que se va generando en el proyecto pese a que suele acumularse poco a poco, tiene sus subidas y bajadas conforme vamos encontrando obstáculos y los vamos superando.

¿Dónde interviene la agilidad como medio para luchar contra la fricción? Pues precisamente por la capacidad de respuesta a los cambios, por estar abierto a adaptar el equipo de trabajo, el proyecto, hasta incluso la forma de trabajar para poder adaptarnos a un nuevo contexto.

Además, la naturaleza evolutiva del software desarrollado mediante metodologías ágiles permite resolver determinadas contingencias en el proyecto (funcionalidades que no se terminan de definir de manera adecuada, módulos implementados que no se ajuntan a la expectativa del usuario, de manera más fluida, diseño ineficiente de determinadas clases, etc…) que otro tipo de metodologías tienen que intentar paliar de otra forma o esperar hasta que se entrega, mucho después, una versión utilizable del producto.

En cada iteración, además, iremos soltando peso de la mochila, no es lo mismo subir una cuesta con treinta kilos a la espalda que con diez.

No existe solución contra la fricción ya que la misma, sin duda, en mayor o menor intensidad aparecerá, sin embargo sí que podemos influir en su grado de acumulación a través de la manera en que nos enfrentamos a los problemas que vayan surgiendo.

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.

La fuerza de rozamiento o fricción son todas aquellas contingencias que se producen en el proyecto de desarrollo de software que se suma a un valor inicial resultado de la negociación previa a la contratación del mismo (o al decisión de su realización mediante recursos internos).

Ese valor inicial puede ser tan alto que el condicione de manera absoluta el resultado del proyecto pudiéndose llegar al punto de que en la práctica sea casi imposible llegar a buen fin sin que alguna de las variables (calidad del producto, desgaste entre stakeholders, sobrecoste, etc….) se vean afectadas (Death March Project).

Pensar que el valor inicial se va a mantener durante todo el proyecto es suponer que en el desarrollo de software no se van a producir ninguno de los factores que definen su incertidumbre inherente (cambio de prioridades, cambios en los procesos, cambio en los stakeholder, variación de la implicación de los mismos, contingencias en el equipo de proyecto, etc…) y eso es peligroso porque no te hace pensar en los posibles riesgos y gestionarlos.

Conseguir un producto que satisfaga las expectativas del usuario será el resultado de vencer esa resistencia, esa fuerza de rozamiento, esa fricción.

No es sencillo porque el desarrollo de software no lo es, pero será cuestión de asumir que esas dificultades existen y que conformen vayan llegando será necesario superarlas, venciendo la resistencia con más empuje teniendo en cuenta que el mismo no solo es resultado de un mayor esfuerzo, sino también de una buena práctica en el proyecto resultado de la cualificación del equipo que participa en él.