No se puede medir la productividad

Tendencia positivaEs comun presenciar muchas discusiones acaloradas sobre el proceso del software, las prácticas de diseño y temas parecidos. Muchas de estas discusiones son imposibles de resolver porque la industria del software no tiene una forma de medir algunos de los elementos básicos sobre la efectividad del desarrollo de software. En particular, no existe una forma razonable para medir la productividad.

Por supuesto, la productividad es algo que se determina mirando la entrada de una actividad y su salida. Entonces para medir la productivdad del software deberíamos medir la salida del desarrollo de software - la razón por la que no podemos medir la productividad es porque no podemos medir la salida.

Claro que esto no significa que nadie intente. Una de las cosas que más me irritan son los estudios de productividad basados en las líneas de código. Para empezar, está todo el tema de las diferencias entre los lenguajes, los distintos estilos de contar líneas, y las diferencias por las convenciones de codificación. Pero incluso si usamos un estándar consistente para contar líneas en los programas de un mismo lenguaje, que está todo auto-formateado a un único estilo... incluso etnonces las líneas de código no miden la salida correctamente.

Cualquier buen desarrollador sabe que se puede codificar lo mismo con enormes variaciones en las líneas de código; de hecho un código que está bien diseñado y programado va a ser más corto porque elimina la duplicación. La programación basada en copiar-y-pegar lleva a enormes cantidades de Lineas De Código (LOC - Lines Of Code), y el diseño pobre genera duplicación.

A esta altura contar líneas de código debería ser algo obsoleto, y sin embargo todos los meses veo estudios de productividad basados en líneas de código - incluso en publicaciones de la IEEE, que se supone deberían conocer estos temas.

Ahora bien, esto no signifca que las LOC sean una medida completamente inutil, ya que sirven muy bien para sugerir el tamaño de un sistema. Puedo estar bastante seguro que un sistema con 100 KLOC es más grande que un sistema con 10 KLOC. Pero si yo escribo el sistema de 100 KLOC en un año, y José escribe el mismo sistema en 10 KLOC en este mismo tiempo, esto no signifca que yo soy más productivo. Debería concluir que nuestra productividad fue aproximadamente la misma, y que mi sistema está mucho peor diseñado.

Otro enfoque que se suele usar para medir la productividad son los Puntos de Función (FP). Les tengo algo más de simpatía, pero siguen sin convencerme. Conozco muchas historias donde el mismo sistema, contado por distintas personas, obtenía puntos que variaban por un factor de tres.

Incluso si encontrásemos una forma precisa de determinar la funcionalidad con Puntos de Función, creo que todavía estaríamos perdiendo el punto de la productividad. Podría decir que medir la funcionalidad es una forma de mirar la salida directa del desarrollo de software, pero la salida real es algo más. Asumiendo que usamos un sistema de FP preciso, si yo paso un año para entregar un sistema de 100 FP, y José pasa el mismo año en entregar un sistema de 50 FP, ¿podemos asumir que yo fui más productivo?. Diría que no. Podría resultar que de mis 100 FP sólo 30 son funcionalidad que le termina resultando útil al cliente, mientras que la funcionalidad de José es toda útil. Debería concluir que mi productividad directa es más alta, pero que la producitividad real de José es mejor.

Además hay factores internos que afectan la entrega de puntos de función. Mis 100 puntos de función podrían ser muy parecidos, y me lleva un año hacerlos porque no uso algún sistema para reutilizar código. Los 50 puntos de función de José son todos diferentes (malas noticias para él). Le resulta casi imposible reutilizar algo. Pero a pesar de que tiene que implementar 50 puntos completamente distintos, para los cuales no se puede reutilizar nada, José logra hacerlo en sólo un año.

Pero todo esto ignora el hecho de que incluso la funcionalidad útil no es la medición real. A medida que aprendo logro producir 30 FP útiles de funcionalidad, y José sólo logra hacer 15. Pero alguien se da cuenta que los 15 FP de José generan ganancias por $10 millones para el cliente, mientras que mi trabajo sólo logra ganacias por $5 millones. Nuevamente podría concluir que la productividad real de José es más alta porque logró entregar más valor de negocio - y recordemos que cualquier medición real de productividad en el desarrollo de software tiene que estar basada en el valor de negocio entregado.

Todo esto nos lleva a la tasa de éxitos. Podría decir que un proyecto exitoso es aquel que entrega más valor de negocio que el costo del proyecto. Veamos: si José y yo hacemos cinco proyectos cada uno, y yo tengo éxito en cuatro y José en uno, ¿finalmente hice un mejor trabajo que José? No necesariamente. Si mis cuatro proyectos exitosos generan $1 millón de ganancias cada uno, pero el único proyecto exitoso de José genera $10 millones más que el costo de todos sus proyectos combinados, entonces José es quien debería ser felicitado.

Hay quienes dicen "si no lo podés medir, no lo podés gestionar". Esto es esquivar responsabilidades. Los negocios gestionan cosas que no pueden medir todo el tiempo. ¿Cómo se mide la productividad de un estudio de abogados, de un departamento de marketing, de una institución educacional? No se puede - y sin embargo hay que gestionarlas igual.

Si es dificil medir la productividad de un equipo, más dificil es medir la contribución de cada individuo del equipo. Podemos tener una idea aproximada de la salida del equipo mirando cuántas funcionalidades pueden entregar en una iteración. Es una idea cruda, pero nos puede servir para ver si el equipo se está acelerando, o si es más productivo que otro. Pero la contribución individual es mucho más dificil de medir. Aunque algunas personas sean responsables de implementar ciertas características, otros pueden jugar el rol de apoyo - ayudando a otros a implementar sus características. Su contribución hace que aumente la productividad de todo el equipo - pero es dificil lograr saber la salida individual a menos que seamos un desarrollador en ese equipo.

Y si todo esto no era lo suficientemente complicado, el Economist (septiembre 13-19, 2003) publicó un artículo sobre las tendencias en la productividad. Parece ser que los economistas ahora están viendo aumentos en la productividad debido a inversiones en computadoras que hicieron en los años 90. El punto es que las mejoras aparecen mucho después de la inversión: "La inversión en computadoras no se traduce en un aumento automático en la productividad; las organizaciones necesitan reorganizar sus prácticas de negocio también". Esta misma demora ocurrió con la invención de la electricidad.

Así que no sólo es dificil medir el valor de negocio, sino que también hay una demora en el tiempo. Entonces no podemos medir la productividad de un equipo hasta pasados varios años de la entrega del software que construyeron.

Podemos ver porqué medir la productividad es tan seductor. De lograrlo podríamos medir al software de una manera mucho más facil y objetiva que en la actualidad. Pero las falsas mediciones sólo empeoran las cosas. Esta es un área en donde creo que debemos admitir nuestra ignorancia.

Basado en Can not measure productiviy, por Martin Fowler.
Compartir
  • cbalvarez

    No podría estar más de acuerdo.<br /><br />Las líneas de código sirven para medir el tamaño de un sistema si dejamos todas las demás variables fijas: casi diría que sirven para comparar tamaños de softwares hechos por el mismo equipo si es que el equipo no estaba aprendiendo mientras hacía uno de los sistemas a comparar. Nada más.<br /><br />Y ahora, una pequeña catarsis: el \'valor del negocio\' me parece un concepto que no puede ser cuantificado en absoluto. No sabemos como hacerlo: contar los casos de uso y hacer esos puntos de caso de uso o de función no es más que hacer lo que hacen lo que economistas: poner números y formulas matemáticas en algo que ignoramos a ver si la formalidad magicamente aparece. Salvo, claro, que definamos \'valor de negocio\' como \'incremento en los beneficios económicos\', pero ahí es bastante complicado evitar la falacia de atribución (me va mejor porque instalé el GRAN-ERP-QUE-TODO-LO-MANEJA?? o me va mejor porque estoy en el medio de un ciclo de crecimiento económico mundial?)<br /><br />Parafraseando no me acuerdo a quien (la frase original es sobre la inteligencia) \"no puedo definir que hace a una persona productiva, pero lo reconozco cuando lo veo\"

  • acandal

    Si dos equipos crean un sistema con las mismas funcionalidades, en el mismo tiempo y digamos que con similares cantidades de LOC y de FP, podemos afirmar que su productividad es la misma?<br /><br />¿Qué pasaría si luego de que el sistema pasa un tiempo \"generando grandes ganancias\" se requiere hacer alguna modificación en alguno de sus componentes? Mucho o poco tiempo despues, cuando esto pueda suceder, los equipos podrían tardar tiempos muy diferentes en realizar el cambio, según la calidad que tenga su versión del sistema. <br />Suponiendo que uno de los equipos hizo un buen diseño teniendo en cuenta principios de mantenibilidad, escalabilidad, etc, seguramente insuma menos tiempo en las modificaciones. De esta manera, se evidencia que este equipo fue más productivo que el otro. (aclaración: digo \"más productivo\" pero no puedo decir cuánto más productivo)

  • Evgeni

    Con realimentación del sistema se podría medir la productividad.

  • Invitado

    Estoy de acuerdo en que es complicado medir la productividad de los equipos de desarrollo, pero creo que hay algunos temas a tener cuenta que muchas veces se olvidan: cómo trabajan los miembros del equipo, qué herramientas usan, cómo fragmentan su tiempo, cuánto tiempo dedican a interrupciones que bajan su concentración, que normas cumplen… En mi opinión, si controlas esa parte y tienes la garantía de que el equipo trabaja concentrado, motivado y enfocado, ya puedes completar la medición de la productividad junto a otros valores. En nuestro equipo de desarrollo, los empleados usan workmeter.com para analizar sus pautas de trabajo y ver si sus niveles de concentración y enfoque son buenos: el manager y el desarrollador ganan transparencia y ven rápidamente los puntos de mejora para conseguir una forma de trabajar productiva. Desde luego, también hace falta estrategia técnica, dirección… pero os aseguro que cubrir esta parte para nosotros ha supuesto una mejora en todos los aspectos

  • Invitado

    [quote name="gustavo.d"]… En nuestro equipo de desarrollo, los empleados usan workmeter.com para analizar sus pautas de trabajo y ver si sus niveles de concentración y enfoque son buenos: …<br />… pero os aseguro que cubrir esta parte para nosotros ha supuesto una mejora en todos los aspectos[/quote]<br /><br />¿En que empresas trabajas, en workmeter.com por casualidad?... :-*

  • Hola buenas, soy trabajador de una importante empresa de informática. No estoy de acuerdo con lo dicho en la noticia ya que en mi empresa sí que medimos la productividad. Gracias a el programa Trabajator medimos la productividad basada en el tecleo de todos los trabajadores de la empresa. Espero que os sea de ayuda. Gracias.

Deja tus comentarios

Post comment as a guest

0

El nuevo Dos Ideas.

Nuevo logo, nuevo buscador, nueva portada, podcast mensual... ¡y muchas novedades más!

Más novedades en Dos Ideas

Los Comentarios.

manny
muy interesante todo los que se escribió aquí.
Alejandro Cortes
"Si hubiera que definir la arquitectura en pocas palabras, se diría que es la ponderadora creación d...
alex
hey no me dieron el resultado que esperaba xD
JSP
Hola, soy nuevo en esto de java y no consigo hacer funcionar los ejemplos. ¿Podrías poner el código...
silvia
Muy bueno Gracias por compartirlo! exelente!

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw