archivo

Archivos Mensuales: julio 2012

La siguiente cita de Tom DeMarco me ha hecho reflexionar: “La razón real para el uso de la presión y trabajar más horas puede que sea para que cada uno se sienta mejor cuando el proyecto está fallando”.

Puede que una razón sea esa pero ni mucho menos es lo que ocurre en todos los casos en los que se trabaja bajo presión o hay overtime incluso en períodos largos de tiempo (sobre todo en Death March Projects).

¿Por qué me ha hecho reflexionar? Pues porque cuando todo va mal un mecanismo de autodefensa que se suele utilizar es precisamente dar la apariencia de cumplir: “el proyecto va mal, pero no será por mi porque no paro de echar horas al proyecto”.

¿Dónde está la frontera entre la apariencia de cumplir y la necesidad real de un proyecto?

Es complicado, lo mismo estás echando más horas al proyecto no por el mero hecho cumplir sino porque tienes alguna motivación para hacerlo pero, ¿cuándo deja ser una motivación real y pasa a ser otra cosa? A veces será fácil diferenciar una cosa de la otra, en otras ocasiones la frontera será más difusa.

Anuncios

El día a día parece indicarnos que el objetivo es ejecutar trabajo y cuando la mentalidad de toda una organización es esa se entra en una espiral peligrosa en la que solo importa terminar tareas, bien, mal o regular y si no se consiguen finalizar dentro de unos parámetros presupuestarios adecuados darlas por terminadas estén como estén o con una terminación lejos de la expectativas planteadas.

En nuestro sector esa forma de actuar se encuentra muy extendida y como no podía ser de otra forma ha contribuido al desprestigio que tiene nuestra profesión.

La ejecución de un trabajo o de una tarea solo es significativa si cumple las expectativas que se tenía depositada en ella en detalles incluso que el propio cliente desconoce o no valora de manera adecuada en primera instancia como por ejemplo que el sistema además de cumplir las especificaciones del usuario y proporcionarle una buena experiencia de uso sea fácilmente mantenible (no todas las personas para las que se desarrolla software tienen en cuenta ese factor), pasa sin incidencias significativas a producción, se respeta la garantía con unos tiempos de respuesta adecuados, etc…

Estos detalles marcan la diferencia y crean relaciones duraderas con los clientes y crean una imagen positiva de la organización. Es cierto que es complicado mantener un determinado nivel pero no por ello debe dejar de ser un objetivo llegar a él y superarlo.

Todo lo anterior queda resumido en la siguiente cita de Ken Schwaber: “La calidad no es una variable basada en proyectos, sino un activo corporativo”.

Y lo es pese a que le hayas dado muchas vueltas con él a cada uno de los requisitos y se haya consensuado una solución.

Esto es así porque el usuario trabaja con imágenes abstractas de lo que va a ser el producto final y porque pasado un tiempo (en ocasiones horas) no recordará con exactitud detalles en los requisitos. A esto le podemos añadir el descubrimiento de nuevos matices ya sea por un análisis más meditado por parte del usuario (o porque terceros le hayan hecho ver aspectos en las funcionalidades que tienen que cambiar) y por la propia evolución en las prioridades por parte del área usuaria que haga no solo que ahora sean más importante unas funcionalidades que otras, sino nuevos cambios en las especificaciones.

Y estas circunstancias suceden desde el momento siguiente al cerrar una especificación hasta prácticamente el minuto antes de la entrega.

Es cierto que el área usuaria debe ser responsable de los requisitos que ha dado pero tenemos que entender también que por mucha atención que le hayan dedicado, esos cambios van a suceder.

Como esos cambios son inherentes al propio proceso de desarrollo y a la existencia de usuarios la solución pasa porque los mismos sean realizados cuando tengamos versiones del software en funcionamiento ya que no es lo mismo opinar sobre algo tangible que hacerlo sobre elementos abstractos.

Es cierto que es más costoso hacer cambios en el software que cambios sobre las especificaciones recogidas en un documento o en una herramienta CASE pero por mucho que nos esforcemos en intentar que esos cambios se hagan en el análisis siempre vendrán cambios después.

Desde mi punto de vista el enfoque debe ser iterativo incremental, realizándose cada iteración con intención, con ciclos lo más cortos posibles en función de la naturaleza del sistema a desarrollar y su contexto.

Un enfoque iterativo incremental puede ser llevado a cabo de distintas maneras, si tiene una fase de análisis previa no se tiene por qué renunciar a estudiar bien las especificaciones con el usuario, no se trata de dejarlo todo para el feedback. Si en cada iteración se hace el ciclo completo no se debe renunciar a que la especificación de la historia de usuario o del caso de uso sea la mejor posible.

Las organizaciones necesitan líderes. El ideal es que cada persona en la organización tenga esa capacidad de liderazgo (líderes crean líderes) pero la realidad está lejos de ese objetivo conforme la organización crece de tamaño y si no existe en la misma una cultura que tienda a crear líderes (lo normal es el ordeno y mando).

Los líderes no se limitan a dar instrucciones. Un líder es mucho más que eso porque lo que hacen es marcar un camino y cuentan con la suficiente credibilidad como para que otras personas lo sigan porque entienden que realmente es lo mejor para la organización y para ellos. Un líder se pone al frente en el campo de batalla, en este caso, de la meta que se marca y no se queda agazapado esperando a que los suyos la libren. Y si el equipo cae, el cae con ellos. El líder no se esconde sino que da la cara.

Eso es un líder de verdad, lo demás son mensajeros sin un mensaje porque el que tengan se difumina en el momento en que el líder no se implica y se echa a un lado (un mensaje solo tiene fuerza si el que lo da es consecuente con él, lo demás son palabras vacías), dejando que sean otros los que tiren del carro, los cuales en ausencia de liderazgo se terminan perdiendo en su día a día, salvo que entre ellos salga un líder que se encargue de tirar del carro.

En una cultura no orientada al liderazgo, los falsos líderes tenderán a empequeñecer y a convertir en testimoniales a los líderes naturales que puedan salir de los equipos de trabajo porque saben que la puerta de salida la tienen más cerca conforme estas personas vayan creciendo en la organización y vayan ganando credibilidad.

Que el software se deteriora conforme se va evolucionando es un hecho a partir del momento en que el sistema tiene implementadas el conjunto de funcionalidades que el usuario realmente necesita (el problema de esto es que casi siempre resulta complicado saber cuándo se llega a este punto y que incluso llegando a él habrá funcionalidades adicionales a las estrictamente necesarias que también se habrán implementado).

Este deterioro es aplicable a nivel funcional (se implementarán nuevas funcionalidades muchas de las cuales serán innecesarias, lo que hará más complejo el uso del sistema, introducirá nuevos errores y provocará probablemente efectos colaterales) y técnico (antipatrones ancla de barco y lava seca, incremento de la complejidad, etc…).

Hablo en términos generales, ya que incluso en estos casos es posible mejorar el sistema en ambos aspectos.

Ahora bien, me parece muy interesante poneros la siguiente reflexión de Dave Thomas, ya que la deuda técnica es una resistencia que tiene el software pero de cara a su evolución y en ese sentido es importante tenerla en cuenta, no obstante la deuda técnica no actúa si el software está en reposo (eso de que no actúa también es relativo ya que un sistema con una deuda técnica alta es serio candidato a dar muchos problemas) si vemos dicho concepto desde el punto de vista de la mantenibilidad: “La métrica del coste del cambio empieza a correr cuando tomas una decisión. Si no tomas una decisión, entonces no hay nada que cambiar y la curva contínúa plana”.

Por tanto, la degradación no debería considerarse función del tiempo sino de la evolución. Sin embargo se asocia generalmente con el tiempo y tiene una cierta lógica ya que la evolución es consecuencia de actuaciones que se realizan en el sistema conforme avanza el tiempo.

Dentro del ámbito de un equipo de proyecto los rumores relacionados con aspectos profesionales, en las relaciones entre las personas del equipo, en las relaciones con el resto de stakeholders, en las relaciones con el resto de la organización, etc… debe ser el menor posible porque es un elemento de distracción evitable, genera malos entendidos e incluso según la naturaleza del rumor puede afectar a la motivación o a la estabilidad de miembros del equipo.

Dentro del ámbito del proyecto también debe cuidarse este aspecto entre todas las partes que intervienen, por los mismos motivos que los que acabo de exponer pero haciendo especial énfasis en los malos entendidos.

En el ámbito de un departamento o de una organización también debería minimizarse la existencia de rumores, si bien resulta mucho más complicado conforme el tamaño y complejidad de la misma y el número de empleados crece.

Ken Schwaber considera que “Donde hay rumores, no hay una buena comunicación” y yo creo que efectivamente así es ya que en este tipo de contextos la información solo fluye entre una serie de personas que después queriendo o sin querer la filtran completa o sesgada a otras personas dentro o fuera de la organización y a partir de ahí el mensaje queda distorsionado.

El desarrollo de software es algo muy complicado como para añadirle elementos de resistencia adicionales que pueden ser perfectamente evitados a través de una política o estrategia de comunicación adecuada dentro del equipo de proyecto y con los stakeholders.

La respuesta puede parecer evidente pero, ¿a qué conocéis muchos casos en los que precisamente parece que el objetivo es satisfacer un proceso?.

¿Por qué se llega a esa situación? Por el convencimiento de que a través del proceso es cómo se obtienen productos de calidad.

Si esto fuera así el desarrollo de software no tendría historia, no tendría la complejidad que tiene y la inmensa mayoría de los proyectos terminarían con éxito.

El proceso puede ayudar a armonizar los desarrollos dentro de una organización, lo cual puede ser interesante siempre y cuando se determinen líneas a seguir de alto nivel y siempre al servicio del proyecto. También puede ser interesante para establecer un background en la realización de los proyectos pero de igual forma que en el caso anterior siempre que se vea como un instrumento que determina ciertas pautas y que ofrece flexibilidad para poder ser adaptado al proyecto en el que estamos trabajando y que puedan existir excepciones si estuviera justificado.

El objetivo es el producto, siempre el producto, pero no con una visión del mismo como una entidad única tras la cual no hay nada más, eso es un error ya que en la organización habrá otros sistemas de información, habrá otras soluciones sobre las que sera necesario o conveniente integrarse y que si no se tienen en cuenta provocará duplicación de funcionalidades, problemas a la hora de integrar datos, fragmentación de soluciones, etc…