[14/09/2018] Muchas veces el interés no es solo evaluar si un equipo es productivo, sino ¿cuánto más productivo el equipo necesita ser? ¿cómo es el desempeño en comparación con otros en el mercado?
Organizaciones que desarrollan o contratan el desarrollo de software, deberían tener como uno de sus objetivos alcanzar niveles máximos de productividad en los equipos movilizados en estas iniciativas.
Para este fin, hay importantes reflexiones que deben ser hechas por los ejecutivos responsables por la gestión del desarrollo en estas organizaciones: conocer y evaluar diferentes alternativas para garantizar que aquellos equipos sean productivos, y tener estrategias de cómo mejorar el desempeño del grupo para alcanzar mayores niveles de eficiencia y cualidad.
¿Qué significa que un equipo de software sea productivo? La respuesta: ¡Es un equipo que produce resultados! Esta respuesta parece demasiado simple, como la respuesta clásica "42” de Deep Thought en el libro The Hitchhiker's Guide to the Galaxy al ser cuestionado sobre la respuesta a la pregunta sobre la vida, el universo, y todo lo más. Por esto, podemos explorar esta pregunta un poco más antes de llegar a una conclusión.
El término software se refiere a una variedad de diferentes productos que tienen naturalezas diferentes, como programas de computador, scripts de configuración, especificaciones de interfaz con el usuario, documentos de requerimientos, planos de diseño y arquitectura, casos de prueba, entre otras representaciones del software. Por esto, al realizar la planeación y la evaluación de la productividad, es necesario establecer un panorama más amplio y completo a fin de evaluar de manera consistente cuan productivo es un equipo cuando es comparado a una escala de referencia.
La escala de referencia es una parte necesaria de este panorama. Hay actividades de mantenimiento en que el resultado de su realización no está asociado a la producción de algo nuevo o al perfeccionamiento de algo existente. En estos casos, el resultado está asociado al mantenimiento de niveles de servicio ofrecidos por el producto de software en producción.
En caso de que la administración escoja por una escala de referencia basada en una perspectiva de negocio, en lugar de una perspectiva técnica, que requiere muchos más detalles sobre el proyecto y la implementación del software, problemas relativos a estos ítems ya resueltos y refinados en un nivel que permite su comprensión detallada, entonces la elección apropiada es la funcionalidad entregada o impactada por un proyecto.
Para actividades de mantenimiento de software, esto también es posible en determinados casos y la funcionalidad en el alcance de esa actividad de mantenimiento serían las funcionalidades añadidas, excluidas, modificadas o probadas por el proyecto asociado.
Productividad como un atributo de proceso
El concepto de medir la productividad de un equipo es, de hecho, una simplificación. En realidad, el interés más amplio de la administración es evaluar el desempeño de un proceso productivo (en el caso, un proceso de software). Por lo tanto, no se deben mezclar datos relativos a la medición de actividades de sustentación, como las descritas anteriormente con un proyecto de desarrollo para un nuevo sistema.
Cada proceso productivo de software tiene factores de costo únicos, y las producciones derivadas de estos factores de costo siguen una distribución de probabilidad específica. Por ejemplo, los procesos de desarrollo de una nueva aplicación y el mantenimiento en una aplicación existente son diferentes.
En un escenario como éste se podría comparar este tipo de proceso al método estándar de desarrollo y concluir que representa, por ejemplo, el 70% del esfuerzo que demandaría un nuevo desarrollo. De ahí, si el alcance impactado se mide como 100 PF; se considera para evaluación del desempeño en ese proceso una producción equivalente a 70 PF.
Ventajas de usar APF en la medición de productividad
Es importante indicar que Análisis de Puntos de Función (APF), técnica que produce unidades representativas de medición del tamaño funcional, es un método con un alto nivel de madurez, cuenta con el mayor número de profesionales cualificados en su aplicación, y posee una amplia gama de organizaciones que la utilizan. No hay otro método en el mercado que se compare a ella en estos tres puntos destacados.
Está también el Grupo Internacional de Usuarios de Punto de Función (IFPUG), organización responsable por su mantenimiento y evolución desde 1986.
El uso de medición funcional utiliza como entrada diferentes representaciones de los requerimientos funcionales -relacionados a las tareas y servicios del usuario- como se define en la segregación de roles y responsabilidades por la estructura organizacional; como los organizados por el flujo operacional, que describe los procesos de negocio. Son informaciones disponibles tempranas cuando un desarrollo en contraste con las decisiones de implementación del proyecto tomadas mucho más adelante en comparación.
Si algún otro método de medición que considera aspectos internos o técnicos fuera usado, entonces no sería posible para el cliente auditar los resultados presentados por el equipo de desarrollo. Esto por si solo ya es una razón lo suficientemente grande para desalentar su utilización para fines de evaluación de la productividad.
Usar una métrica funcional equilibra las diferentes tendencias en acción cuando se planea y evalúa la productividad. Hay una tendencia, natural, por parte del equipo de desarrollo, para inflar el uso de recursos, mientras que el cliente tiene una tendencia a imponer presión en el sentido opuesto para aumentar la producción. Sin una métrica funcional como el APF, no hay referencia con un significado común para todos los involucrados.
CIO, Perú