Productividad

Que es la productividad?

Uno de los mayores problemas a la hora de hablar de productividad es definirla en términos útiles y que sean fácilmente entendidos y compartidos por todos. Todavía es posible encontrar gente que la expresa y la entiende como líneas de código sobre unidades de tiempo invertidas aún cuando carezca de toda lógica. Esto ocurre porque para calcularla se utiliza la fórmula clásica de productividad:

productividad = unidades / recursos

En la cual interviene el concepto de unidades producidas, pero ¿qué es una unidad de software? Muchos consideran que el tamaño del software puede medirse mediante líneas de código (LOC) y tienen sus buenas razones, difícilmente una aplicación de 10.000 LOCs pueda ser mayor a una de 500.000 LOCs. Pero esta unidad únicamente sirve a efectos comparativos a niveles macro como el que acabamos de ilustrar y no nos dicen demasiado cuando bajamos a escalas mucho menores. Por ejemplo, si para programar una cierta funcionalidad, un equipo requiere 1.000 LOCs y 100 horas/hombre y otro equipo requiere 7.000 LOCs y 100 horas hombre, ¿podríamos afirmar que el segundo equipo fue siete veces más productivo que el primero? ¡Por supuesto que no! Ambos equipos construyeron una misma solución en un mismo tiempo, pero tampoco podríamos afirmar que son igualmente productivos ya que las 7.000 LOCs son muchas veces más difíciles de mantener que la 1.000 del otro equipo.

La ecuación tradicional de productividad nos habla acerca del costo de desarrollar una pieza de código para implementar una cierta funcionalidad pero nada dice acerca de los costos futuros de mantenimiento de las mismas, y en software, el mayor costo está relacionado al mantenimiento de las aplicaciones. Entonces, necesitamos agregar la calidad a la ecuación para tener un panorama más realista y económicamente acertado. De no hacerlo, y si consideramos el tamaño del software en función del número de líneas de código que se necesitaron para escribirlo, caeremos en la trampa de creer que el segundo equipo fue realmente 7 veces más productivo que el primero.

Lucas Ontivero

Sin categoría

3 thoughts on “Productividad

  1. Completamente de acuerdo!!! Yo creo además que la única métrica válida para medir la productividad y mejorarla, es la velocidad (realizado/estimado) o espacio/tiempo 😉
    Pero no cabe duda que si no implicas la calidad los resultados pueden ser desastrosos. Pero mi opinión es que la calidad debe ser algo transversal y no aplicable a la fórmula, como por ejemplo cobertura de código/pruebas, LOC por procedimiento/complejidad ciclomática, cometarios/LOC, … hay muchas mas

  2. Exiten métodos bastante válidos (aunque no son una verdad universal). Si realizas una estimación mediante la técnica de Puntos Función, te saca X puntos / función. Después puedes calcular las horas tardadas para realizar esos puntos función, y ahí tienes la productividad.

  3. MMmmmm…
    Para mi la calidad está fuera de la ecuación, puesto que es irrenunciable. Si se entrega s/w de baja calidad, eso automáticamente bajará la productividad puesto que se va a tener que invertir en mejoras/parches continuadamente: La productividad debe medirse a lo largo de todo el ciclo de vida, no solo durante el desarrollo inicial. Y muchas veces este es el problema principal: pensar solo en el TAC (Total Acquisiton Cost) en lugar de tener en cuenta todo el ciclo de vida y por lo tanto el ROI.

    Por otro lado, no termino de creer en métricas como LOCs y similares: al final lo que importa es lo que se entrega al cliente. Ya puedes tener 4000 millones de LOCs, que si no le solucionas las necesidades al cliente, si no le puedes dar nada, no has sido productivo… por más fáciles de mantener que sean esas líneas. En mi opinión es más productivo quien más problemas le solucione al cliente (o sea, quien implemente más funcionalidades del sistema).

    Un saludo!

Deja un comentario

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