Métricas mal entendidas

Vuelvo a leer a Antonio Quiros explicando su visión sobre la gestión de proyectos, en el número de Noviembre de dotNetMania, la revista de referencia en el mundo .Net en castellano. Ya comente lo poco que compartía su visión de la gestión de proyectos de software en un anterior post: ¿Nos podemos caer de maduros?. Pero no me resisto a comentar de nuevo sobre este tema.

Este més le toca a las métricas. Ya desde el propio título del artículo empiezo a disentir de la visión de la gestión de proyectos de Antonio Quiros: Métricas para la EVALUACIÓN de procesos de contrucción de software.

Que nadie piense que menosprecio el valor de la métricas. Las metricas son una arma de suma importancia para ganar información sobre los proyectos que nos permita gestionarlos mejor y reaccionar antes a los problemas.

Pero, si algo a descubierto la ingenieria del software en los últimos tiempos, es, que las métricas no sirven para evaluar. El motivo es sencillo, las personas son mucho más inteligentes que las métricas. Los proyectos son un sistema dinámico formado por personas dinámicas. Si tu estableces una métrica del estilo % eficiencia = 100 * (horas previstas / horas reales) es facil preveer como se va a mejorar esa métrica, ¡no reportando horas reales! es decir perdiendo información. Información que es valiosa sobre tu proyecto. El punto aquí no es que las métricas propuestas por Antonio Quiros sean más o menos validas, sino que para lo que no son validas, como cualquier otra, es para evaluar. Utilizar las métricas para evaluar nos puede llevar a generar una cultura de cumplimiento, en la que pongamos el proceso sobre las personas, olvidando la importancia de estas.

La métricas prescriptivas, del estilo 'la eficiencia tiene que ser mayor de x valor' se tienden a sesgar cuando se utilizan para evaluar. Y el problema es que cuando los desarrolladores sesgan las métricas el jefe de proyecto pierde valiosa información. Otro factor dañino de utilizar las métricas para evaluar, es que los desarrolladores se las apañaran para mejorar esas métricas sobre las que evaluamos, olvidando aquellos aspectos del proceso de desarrollo que no se evaluan. Y siempre hay algún aspecto que no se evalua, sea este más o menos explicito.

Bien, si las métricas no sirven para evaluar y no pueden ser prescriptivas, ¿para qué sirven?. Sirven para recopilar información sobre nuestro proyecto, que nos permita una mejor toma de decisiones. Para ello debemos analizar las métricas no de manera prescriptiva, buscando una manera de estar en cierto rangos, sino de una manera descriptiva, viendo las métricas de una manera gráfica y multidimensional, relacionando varias de ellas, por ejemplo defectos abiertos, respecto a tareas bloqueadas, para ver que hay defectos que nos están bloqueando tareas.

El problema es que esa mirada, descriptiva, multidimensional y gráfica a las métricas, no es constante, debe cambiarse de proyecto a proyecto e incluso en diferentes momentos de un mismo proyecto. Esta visión de las métricas es la que ayuda a mejorar el proceso de desarrollo, aunque, por mucho que pese a algunos gestores no sirve para evaluar el desempeño. No es tan comoda como la visión prescriptiva, pero es mucho más ágil y nos permite detectar problemas mucho antes en aspectos sobre los que no tenemos métricas explicitamente establecidas; y lo que es más importante, evitar que los desarrolladores sesguen las métricas. El acercamiento a las métricas de manera descriptiva, multidimensional y gráfica es el que propone MSF e implementa Team System. Es cierto que es dificil de llevar a cabo sin herramientas adecuadas, pero ahora esas herramientas existen: VersionOne, Team System…

Ojo, nadie piense que este sesgo de las métricas es un proceso consciente del desarrollador, es incosciente. Pero es evidente que si a mi me evaluan por tal o cual factor es ese el que voy a tratar de maximiza, aunque probablemente me olvide de otros. Sobre este tema es especialmente esclarecedor el artículo 'Larry's rules of software engineering #2: Measuring testers by test metrics doesn't'.

En mi opinión el principal problema de las métricas que propone Antonio Quiros es que todas son subceptibles de ser sesgadas del mismo modo: trabajando horas de las que no informas. No voy a ser mal pensado y deducir que esto es precisamente lo que tratan de buscar estas métricas (y muchas otras propuestas con anterioridad). Con esta simple acción, trabajar más horas de las oficiales, mejoras todas las métricas que propone en su árticulo, y a medio plazo ¡destrozas a tu equipo de desarrollo!. Espero que en los proyectos en los que se aplican esas métricas vayan acompañadas de una clara política de ferreo control de excesos de horarios, pero, conociendo esa industria me temo que no sea así. Las métricas propuestas en el artículo caen en el error, ya descrito hace 15 años en Peopleware, de realizar el llamado 'spanish management', nombre que tiene su origen la gestión realizada por los conquistadores sobre los recusos de las tierras Americanas. Básicamente consiste en mejorar la productividad no mediante mejores prácticas sino mediante mayor utilización de recursos, práctica solo sostenible a corto plazo.

Por último me sorprende ver en el artículo métricas que hacen referencia a líneas de código. ¿Sabe Antonio Quiros cuantas lineas de código se generan en un IDE moderno con solo arrastrar un botón? (Se que lo sabe). ¿Cómo se comparan esas líneas con las necesarias para escribir una capa de acceso a datos empresarial? En los tiempos que corren la línea base se debe establecer en puntos función. Y los puntos función solo sirventras un largo proceso de ajuste por tipo de proyecto y organización. Tambien hecho de menos algunas de las métricas clasicas, por ejemplo las relativas a bugs, a cambios en los requisitos, a retrabajo, etc… realmente centradas en el desarrollo de software y no en la gestión mal entendida de recursos.

Para cerrar un poco de humor relacionado con el tema de los datos:

16 comentarios sobre “Métricas mal entendidas”

  1. Ojalá hubiese más jefes de proyecto con las ideas tan claras como tú, y la preocupación constante por el bienestar del equipo. Seguramente a esta industria le irían las cosas mucho mejor.

  2. A colación de lo que dices Marco, durante esta semana me ha estado bombardeando una parte muy pequeña de una interesantísima conversación con Rodrigo en el Code Camp pasado, dónde discutíamos acerca de como denominar al personal informático… “recursos” vs “personas”… y es que comúnmente se habla de recursos, pero deberían salirnos a todos sarpullidos cuando se habla de recursos, ya que los recursos son un PC, un Software, un teclado,… pero… ¿una persona es un recurso?.

    Estaba por poner en mi blog algo sobre este tema, pero ya que has hecho tu comentario, como venía muy bien… he decidido poner esta pequeña línea aquí. 🙂

  3. Por suerte, en la mayoría de las empresas se evitan este tipo de discusiones acerca de las métricas más adecuadas… sencillamente, ¡porque no se mide nada! 🙂 Me temo que el “medir bien” es la segunda derivada. De todas formas, en este caso, menos mal que es mejor no medir, que medir mal. La pura incompetencia y desidia acabará salvando al mundo de los cortos de miras. ¿A que es genial?

  4. Por fin !! Desde que leí el artículo estaba esperándolo.

    Estoy de acuerdo con Gorka en que lo habitual es no tener ningún tipo de métrica, al menos formal.

    Tb un comentario sobre “El motivo es sencillo, las personas son mucho más inteligentes que las métricas”. Bueno, en esta industria tenemos de todo 🙂

  5. El problema con las métricas siempre a sido el mismo: son dificiles de recolectar. Por eso durante años las únicas métricas que se ha usado con cierto exito a sido las relaciondas con los defectos.

    En algunos proyectos se usaban más métricas, pero nunca las suficientes para poder obtener esa visión “descriptiva, multidimensional y gráfica” de la que hablo en el post, porque el esfuerzo de recolección de datos era excesivo e impedía la agilidad.

    Sin agilidad en la recolección de datos las métricas pierden valor: ¿de qué sirve enterarse a toro pasado de que los requisitos el més pasado cambiaron mucho?

    Esto gracias a herramientas como Team System o VersionOne esta cambiando. Podemos recolectar mucha información sin añadir excesiva carga burocrática a nuestro equipo de desarrollo.

  6. Completamente de acuerdo, hace tiempo que vengo siguiendo los articulos de “opinión” de Quiros, y la verdad es que no se como cogerlos… en la mayoria de los proyectos que he trabajado ha habido un jefe de proyecto con ideas “reveladoras” que media todo y te juzgaba por ello, y el resultado era el que dice Rodrigo. Sin embargo, en los ultimos años ha existido un Jefe de Proyecto que utilizaba las metricas para determinar las acciones y decisiones del proyecto, sin evaluar, simplemente para mejorar el tiempo de respuesta. Y es el unico en toda mi vida como desarrollador que he visto entregar un proyecto a tiempo, con la funcionalidad especificada, sin echar ni una hora de mas y donde los desarrolladores estaban 120% contentos (tb dependia mucho de las metodologías agile y de que ejecutaba sus tareas de jefe de proyecto: aislar al desarrollador del cliente)

    Y por cierto, lo de que el equipo se destruye a medio plazo no creo que sea del todo cierto… pienso que se destruye mas bien a corto, cortisimo plazo…

  7. Creo que el problema viene cuando a un cliente le tienes que dar una estimación del tiempo que vas a invertir en la realización de un proyecto.
    Te puedes basar en la experiencia, o en proyectos pasados, pero creo que no viene mal alguna ayuda digamos “científica” que permita orientarte, como la estimación según puntos de función (o cualquier otra herramienta). Y está claro que el resultado, es eso, simplemente una estimación.
    Pero es que nosotros, al igual que ocurre en todas las profesiones, debemos ser capaces de dar un presupuesto estimativo a un cliente.

  8. Hola aderojas,

    Creo que métricas y estimación son dos temas diferentes. Evidentemente es muy útil guardar un hístorico de nuestras estimaciones que den soporte a nuevas estimaciones. Pero lo realmente interesante e importante es ir refinando nuestro proces de estimación mediante el ajueste continuo del mismo.

    Hace poco he publicado un post sobre estimación (http://geeks.ms/blogs/rcorral/archive/2006/11/01/Estimando-_2800_no-practicando-la-brujer_ED00_a_2900_.aspx) y pronto publicaré algún otro sobre este interesante tema.

  9. Estoy de acuerdo que las personas somos mas que recursos, sobre todo en este negocio.
    Una de las primeras métricas que escuche – y que aun existe – es la cantidad de lineas que escribe un desarrollador, yo prefiero que no tenga que escribir tantas lineas de acceso a datos y utilice un componente ya probado, y por el contrario centre ese esfuerzo a la lógica del negocio, que es de ese negocio y que no se repite para otro.

    Coincido con que muchas veces no existen métricas, ni conciencia empresarial de las personas que venden los proyectos. Un preventa que habia en la empresa siempre decia “Esto… dos meses”. Ni estimación ni brujería, caradurismo en estado puro. Vender una falsa ilusión.

    En casi ningun proyecto que trabaje existe una reunion post morten, se deshace el equipo, cada uno a clientes diferentes a repetir la misma historia. Parece que esta prohibido evaluar el proceso “Hemos cobrado ¿que mas quieres?” y se acabo el análisis del proyecto.

    Por ultimo, hay muchos MCAD y otros emule CAD. Gente que no ha abierto el Visual Studio, sino el emule y se bajo los exámenes. No digo que sea algo propio de las personas, sino aveces forzado por la empresa “Te pagamos la certificación para poder ser proveedor de tal cliente”. Pero bueno, después de todo, las certificaciones son otra forma de medir a las empresas.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *