archivo

Archivos diarios: noviembre 2, 2011

Salvo que seamos nuestros propios jefes, nuestro trabajo está muy condicionado por las decisiones de otros y por sus cambios de rumbo.

Nuestra productividad consiste en sacar el mayor trabajo adelante posible por unidad de tiempo con calidad, sin embargo, la calidad yo la entiendo asociada a la eficiencia y si las instrucciones que nos han dado han dado lugar a unos resultados que no sirven, hemos tirado esfuerzo, talento y ganas.

La productividad personal es una cosa, es cierto, y la productividad dentro del contexto de la organización, otra, sin embargo siendo cosas distintas no pueden vivir por separado, si con tus proyectos o tus tareas tu organización o tu departamento no ganan, tu no ganas. Alguien podrá valorar lo que has hecho pero tendrá que ser alguien que haya estado cerca de ti y probablemente su valoración esté condicionada por los resultados.

¿Y que decir de los cambios de rumbo?, ¿cuántas veces se dejan de lado tareas importantes para atender otras de dudosa utilidad?, ¿cuánto afecta a nuestra productividad todos esos cambios de contexto?, ¿cuánto afecta a nuestra productividad sentir que nos quitan de las tareas que realmente impactan sobre nuestra responsabilidad y nos ponen con otras que serán prioritarias (o no) para otros?.

Este juego es de patrones y marineros.

Barry Boehm es una buena referencia a la hora de considerar como adecuados determinados indicadores obtenidos en sus investigaciones y proyectos, no en vano siempre ha sido considerado como una de las referencias en el campo de la ingeniería del software, metodologías de desarrollo, estimación de costes y obtención y determinación de métricas relacionadas con el proceso de desarrollo.

Independientemente del indicador que cita Boehm y que indicaré al final de artículo, la propia experiencia nos dice que el coste de corrección de un error se dispara conforme nos alejamos del momento en que se ha producido. Esto es así porque un error arrastra tras de sí otros trabajos que correctos o no, se verán alterados por la corrección del mismo. Por ejemplo, una mala especificación de un requisito que llega a producción tendrá repercusión en el producto final, pero también su corrección requerirá un esfuerzo considerable por los diferentes artefactos que se tienen que modificar o incluso rehacer.

La aparición de los modelos de testing en V o de testing en W son una respuesta posible ante esos problemas, como también lo son la aplicación de otras técnicas en el proceso de construcción, como por ejemplo pruebas unitarias, integración continua, etc…

No solo afectó esta circunstancia a la aparición de modelos o técnicas de testing, sino que las metodologías de una u otra manera quedan impregnadas por la necesidad de detectar y corregir cuanto antes los errores (de hecho el propio testing en V no es más que una variante del ciclo de vida clásico o en cascada) como por ejemplo podemos ver en RUP o por la propia dinámica de desarrollo siguiendo metodologías ágiles.

Sobre la detección tardía de errores y sus implicaciones en los costes de un proyecto, Barry Boehm comenta lo siguiente (en relación a errores en etapas muy tempranas en el desarrollo, como lo son la obtención de especificaciones o requisitos): “Corrige los errores de especificación cuanto antes. Corregirlos después, costará: un 500% más en la etapa de diseño, un 1000% en la etapa de codificación, un 2000% en la etapa de testing unitario y un 20000% más en la entrega”.