La excelencia en métricas: evitando el mundo al revés

¿Se gestionan adecuadamente las métricas de calidad, de productividad, así como otras métricas estratégicas huyendo del concepto “Photoshop de números”? ¿Se diferencia entre métricas de producto y de proyecto, y se es consciente de lo vital que es la combinación y la convivencia entre ambas? ¿Es el esfuerzo planificado o la calidad esperada en diferentes KPIs coherente con la que debería de ser?

A lo largo de este artículo exploramos cómo las métricas correctamente gestionadas, además de evidenciar que se cumplen una serie de indicadores formales requeridos, deben de proporcionar fiabilidad, sinceridad, confianza, conclusiones, benchmarking, visión histórica, actual y proyección futura. Ello se deberá de traducir en oportunidades de mejora para aportar el mayor valor añadido a los clientes y a sus productos, materializado en proyectos. Internamente, un alto nivel de excelencia en métricas aportará un sinfín de beneficios: benchmarking, valores de referencia con diferentes ejes, refinamiento del proceso de estimación, una mejora continua, información estratégica desde nivel proyecto a nivel CIO, predicciones de tipo “what if”,… Un factor clave, además de la sinceridad anteriormente mencionada, será huir de falsos (y con frecuencia utilizados) denominadores común que pueden contribuir en considerar lo más mediocre como lo mejor a todos los niveles, para evitar el mundo al revés.

Un producto de software, con independencia de cómo se contrate (fixed price o time & material) o de cómo se gestione desde el punto de vista de la metodología (Agile, Waterfall, Prince2, etc.), tendrá un coste concreto, un tamaño, diferentes indicadores de calidad y unas características concretas que ayudarán a determinar, por ejemplo, si el coste se adecua al producto recibido.

Es esencial distinguir claramente los conceptos “producto” y “proyecto”, recordando que el objetivo de un proyecto es crear un producto, servicio o resultado. Aunque la diferencia entre ambos conceptos es clara, bajo la perspectiva de métricas puede no ser tan evidente; una misma métrica o indicador puede asociarse a diferentes significados, aplicada a ambos términos. El tamaño de un proyecto puede ser visto, por ejemplo, como la duración (tiempo) o las horas del proyecto (esfuerzo), o la calidad puede considerarse en función de cómo el proyecto ha sido gestionado y si se han cumplido o no una serie de indicadores. El tamaño o la calidad del producto (creado en un proyecto) son conceptos totalmente diferentes, muy alejados de la perspectiva del proyecto.

Proyectos, Productos y Métricas

Podremos almacenar y gestionar docenas de métricas de proyectos, pero métricas de proyectos sin métricas de productos proporcionan indicadores aislados, perdiendo la información más estratégica. Podremos determinar que el esfuerzo invertido ha sido coherente con la estimación del proyecto, que el proyecto ha finalizado incluso antes de la fecha prevista y un largo etcétera de indicadores alcanzados: que el proyecto responde a una serie de reglas e indicadores preestablecidos, aunque no mucho más.

Pero si añadimos una serie de cuestiones aparentemente sencillas, los resultados pueden ser totalmente diferentes: ¿es el esfuerzo planificado o la calidad esperada y acordada coherente con la que debería de ser? ¿Tienen consistencia los diferentes KPIs gestionados, y proporcionan fiabilidad, realidad y conclusiones?

Es necesario sobrepasar la perspectiva de proyecto y tener puesta la mirada en una visión que proporcione sentido común a las métricas e indicadores de proyectos, con una serie de conclusiones estratégicas a nivel de CIO, con una proyección a nivel de compañía (internamente), y con una proyección a nivel de mercado (externamente). Estos diferentes niveles combinados proporcionarán sorprendentes oportunidades de mejora, resultados y conclusiones: en proyectos, en productos, en aspectos financieros, en indicadores de competitividad a nivel de compañía y en una anticipación de estrategias.

Podemos gestionar una gran cantidad de indicadores y KPIs, pero es necesario preguntarnos una serie de cuestiones esenciales: a pesar de que gestionamos docenas de métricas, ¿estamos midiendo de forma realista la productividad, la calidad, y el coste del producto, entre otras? ¿Podemos comparar los resultados con otros proyectos desarrollados en diferentes tecnologías, utilizando diferentes herramientas de desarrollo, metodologías o bajo diferentes tipos de contratos, y descubrir las razones de por qué unos son mejores que los otros? ¿Podemos comparar, utilizando métodos estándares reconocidos, nuestra compañía con otras a nivel de país, sector funcional de actividad, o mundialmente?

Para contestar correctamente a estas preguntas será necesario tener en cuenta una serie de detalles. El primero de ellos es que la información debe de ser realista, y los números almacenados deben de ser correctos. A menudo, el hecho de premiar (o penalizar) equipos o personas, o la creación y distribución interna de rankings puede conllevar cierta ingeniería de números. Una especie de “Photoshop de números” como cuando se realiza una fotografía a alguien y posteriormente esta es retocada porque a la persona no le gustan los ojos, el pelo u otros aspectos. Si los números no son los reales cualquier métrica derivada y las conclusiones serán erróneas y no tendrán sentido alguno; simplemente espectaculares pero no realistas cuadros de mando, presentaciones y atractivos gráficos cuyo contenido posiblemente esté muy alejado de la realidad.

Tras almacenar la información correctamente, con honestidad e integridad a todos los niveles, una actividad fascinante será analizar el “Por qué” y el “Cómo” para ser más competitivos y crear un mejor producto y/o servicio al cliente ¿Por qué una serie de productos tienen una menor productividad que otros? ¿Cómo es nuestra calidad comparada internamente y externamente con indicadores estándares? ¿Cómo pueden nuestros clientes obtener el mejor valor añadido de nuestra empresa? ¿Qué sucedería si…? ¿Por qué? Estas preguntas y contestaciones son claves para mejorar, para ir hacia niveles más maduros de estimación, para medir las mejoras, retornos de inversión, y para disponer de estratégicos cuadros de mando a niveles de CIO.

Común denominador incorrecto: el mundo al revés

Resulta curioso que, a menudo, en la industria del software no siempre se mide el tamaño del producto, e incluso demasiadas veces este se asocia de forma errónea al coste del mismo o al esfuerzo invertido en el desarrollo del proyecto. He aquí la disociación entre proyecto y producto: un proyecto de 5000 horas puede crear un producto más pequeño que otro proyecto de 3500 horas, incluso con el mismo nivel de calidad. Esta es una de las razones por las que el tamaño del producto se convierte en algo esencial; sin ese dato, la métrica de calidad, por ejemplo, únicamente proporcionará el número de defectos (a pesar de que el concepto defecto puede ser un tanto frágil). Si tomamos como tamaño del producto el tamaño del proyecto (horas, por ejemplo), todas las posteriores conclusiones podrán ser erróneas. Es más, los peores proyectos (aquellos que para crear una funcionalidad dada con el mismo nivel de calidad necesitan más tiempo) serán los mejores desde el punto de vista de calidad porque el esfuerzo será mayor. No es lo mismo tomar como base que un proyecto de 5000 horas tiene 25 defectos, que decir que el proyecto de 3500 horas (ambos técnicamente son el mismo, pero el primero es menos eficiente) tiene 25 defectos. En parte es algo así como el mundo al revés.

Otras veces el tamaño del producto será asociado, de forma incorrecta, a las líneas de código (LOC; Lines Of Code) del mismo. A mayor número de líneas de código, en algunas ocasiones innecesarias, el proyecto aparentemente será más productivo o incluso la calidad será mejor, como en el caso de confundir tamaño de producto con tamaño de proyecto, beneficiando de forma injusta a aquellos que han creado un producto con 700K líneas de código frente a aquellos que han creado el mismo producto, con el mismo nivel de calidad, rendimiento y seguridad con 300K líneas de código. De nuevo, no es lo mismo 10 defectos en 700.000 líneas de código (LOC) que 10 defectos en 300.000; el primer proyecto será aparentemente mejor, pero el producto desde el punto de vista de funcionalidades para el cliente será el mismo. Obviamente, esta misma lógica será aplicada cuando el tamaño es asociado al número de programas, número de procesos, número de personas involucradas en el proyecto, duración del proyecto, etc. Es, de nuevo, el mundo al revés.

Hablando del concepto LOC (Lines Of Code), puede sonar un tanto increíble, pero no existe un estándar oficial sobre cómo contar una línea de código: líneas físicas, con o sin comentarios (algunas veces los comentarios proporcionan ayuda, en cambio otras simplemente son código obsoleto que nunca se eliminó), sentencias, programación estructurada frente a no estructurada, código embebido, etc. Dependiendo del criterio utilizado para contar una línea de código (a menudo el criterio puede ser simplemente aquel que más beneficie una situación dada u otras métricas derivadas), las diferencias pueden ser muy altas y los resultados completamente diferentes. Podríamos escribir docenas de artículos y estudios sobre este fascinante asunto.

Alto nivel de confianza y fiabilidad

Un punto esencial es medir el tamaño del producto utilizando métodos estándares reconocidos que proporcionen una perspectiva mundial y un alto nivel de credibilidad y confianza, internamente y en las relaciones entre proveedores y clientes. Diferentes personas acreditadas y con el adecuado conocimiento llegarán al mismo número contando el tamaño de un producto de IT, midiendo el producto en base a las funcionalidades que el producto proporciona, y no en base al precio pagado, al esfuerzo requerido para su construcción, al código físico software creado, al número de programas, a la metodología o al tipo de contrato, entre otros.

Con este mágico número medido tendremos el verdadero común denominador que será la base de otras métricas (e incluso algunas métricas derivadas deberán de ser refinadas, añadiendo otros ejes tales como criticidad de la aplicación o tecnología utilizada, para comparar realmente lo mismo).

El tamaño funcional puede ser obtenido utilizando diferentes métodos, pero el tamaño funcional IFPUG es el más consolidado y utilizado mundialmente (junto con Cosmic y NESMA, ambos derivados de IFPUG años atrás), reconocido ISO, y un punto a su favor, adicionalmente de tener la mayor comunidad mundial, es que debido a ser el método más utilizado existen un gran número de indicadores estándares, benchmarking y referencias que proporcionan delimitadores a todos los niveles. El concepto tamaño funcional es requerido en los contratos software llevados a cabo por gobiernos de países tales como Brasil, Italia, Japón, Malasia o Corea del Sur, y es ampliamente utilizado por grandes organizaciones de todo el mundo.

GreenCoding

Con GreenCoding el desarrollo de software se convierte en parte integrante de tu programa de sostenibilidad

Más información