No por mucho que este tema se comente, y haya sido comentado durante la historia de la informática, parece ser suficiente, a tenor de lo poco que parece haber calado en ciertos tipos de gestores, generalmente profesionales no informáticos, etc.: no puedes medir la productividad de un programador. Sé que es una puñeta, pero, por ahora… no sabemos hacerlo.
Comenzando por lo básico, productividad es la relación entre la entrada de una actividad y su salida. Si en mi exprimidor de frutas meto 5 manzanas y saca 5 litros de zumo su productividad es 5 litros por cada 5 manzanas. Si otro exprimidor saca 10 litros por cada 5 manzanas, será el doble de productivo que el anterior.
Para medir la productividad tienes que medir la salida de una actividad. Para medir la productividad de un desarrollo tienes que medir la salida del desarrollo de software, pero… no podemos medir la salida de un desarrollo (o aún no sabemos cómo).
Medir la productividad con líneas de código
Aún hoy hay quien se empeña en medir la productividad de esta manera… la entrada son requisitos y la salida líneas de código.
Decenas de expertos en ingeniería software han tratado lo erróneo de esta suposición, Fowler, tratando el tema de la productividad también habló de ello, el sentido común también habló de ello, en este mismo blog, hace un año, alertamos una vez más de los problemas de medir líneas de código.
Para un mismo requisito de entrada, Pepe puede hacerlo en 100 líneas de código y Manolo en 1000. Aparentemente, Manolo sería más productivo… pero no. De hecho, Manolo puede haber creado 900 líneas de código innecesarias, incluso con código duplicado, que luego nos tocará mantener, a más líneas de código innecesarias más costes innecesarios.
Es como si en el caso del exprimidor, tuviésemos los 10 litros de zumo hechos por Manolo pero una gran parte de esos litros está en mal estado, pero no sabemos exactamente cuánto. Si, efectivamente, son 10 litros Manolo frente a los 5 de Pepe… pero los 10 litros de Manolo están envenenados.
Ya comentamos por aquí que además el esfuerzo de mantenimiento crece exponencial según crecen de manera lineal el numero de líneas de código.
Tampoco podemos asumir, aunque suene raro, el efecto contrario: a menos líneas de código más productividad. Ya que puede que entonces Pepe se haya dejado por el camino los mínimos de un buen diseño, unos mínimos para la mantenibilidad futura, etc.
Si premio productividad medida en líneas de código puedo estar cavando, y pagando, mi propia tumba.
Y conocer exactamente cuantas líneas de código deberían ser las idealmente necesarias para programar un requisito es, por ahora, algo imposible de calcular (o al menos, de calcular en un tiempo razonable y sin tener que juntar a un montón de expertos que seguro no se pondrían de acuerdo)
Medir la productividad en número de requisitos desarrollados
Después de lo anterior, hay a quien se le pasa por la cabeza medir productividad en función de requisitos completados. Pepe termina 3 requisitos en una semana y Manolo 5… pues Manolo es más productivo que Pepe, pero no.
No, porque… ¿y si resulta que los 3 requisitos que le tocaron al pobre Pepe eran mucho mas difíciles de hacer que los de Manolo? No sería justo, para Pepe, claro.
Esta manera tampoco nos vale, lo que nos lleva a la siguiente….
Medir la productividad con Puntos Historia, Puntos Función, etc.
Hay otra vía para muchos a la hora de medir la productividad. Conscientes de los problemas de las líneas de código y de contar número de requisitos, hay quien defiende que la productividad puede medirse en función de la complejidad de los requisitos desarrollados.
Resumiendo, aun a riesgo de obviar detalles, en este caso estamos hablando de utilizar métricas como los Puntos Historia (te dejo este post), los Puntos Función, etc., que tratan, cada de ellas desde diferentes caminos y métodos, de medir el “tamaño de un requisito”, “lo grande que es”, “lo complejo que es hacerlo”, etc. A número mayor, “más grande”, o “más complejo”, o “más incierto o riesgoso”, es hacer ese requiso.
Esta aproximación en algo más cercana pero tampoco es concluyente.
Pepe podría terminar 5 puntos de complejidad y Manolo 10, pero al final ambos han tenido que programarlos, y de nuevo, Manolo podría haberlos programado rematadisimanente mal, dejándonos otra vez, el “veneno en el zumo”.
Esto nos podría llevar a pensar, liando más la cosa, en entrar en un mundo aun si cabe más complejo… determinar qué es que algo se ha codificado bien, para así cruzar este dato con el anterior. Pero esto nos llevaría al testing, a las inspecciones, etc. Pero, además, el testing lo suele hacer otra persona, no Manolo, con lo cual meteríamos otra variable, lo bien que ha comprobado el tester lo bien hecho que estaba el desarrollo, y si encima contamos con que el número de pruebas necesarias para estar seguros 100% “tiende a infinito” (recuerda el post de La sociedad debería saber que es imposible asegurar que una aplicación software no va a fallar), y al final solo hacemos un muestreo, muestreo que depende del “olfato del Tester”…. Ufff, mal camino este.
Es más, incluso el pobre Pepe podría haber sólo programado requisitos por valor a 5 puntos de complejidad por culpa de Manolo, ya que Manolo dejó un montón de código basura, malos diseños, inconsistencias en la herramienta de control de versiones, dependencias y acoplamientos, etc., que afectaron a Pepe.
Y tampoco resolvemos el problema de las actividades no directamente relacionadas con desarrollo, ¿Y si Pepe no hizo más porque le cargaron un bug de algo que alguien implementó hace tiempo? ¿Cómo metemos esto en el modelo? ¿Y las tareas tipo optimizar una consulta de BBDD?
Los “peros” en este punto son muchos como para poder acabar con un modelo preciso de cálculo de productividad.
Una posible solución
Una aproximación, que no busca la exactitud, es lo que suele hacerse en proyectos ágiles.
Asumimos que no hay manera de saber exactamente cuánto trabajo idealmente debería haber completado alguien o el equipo y nos conformamos con medir de alguna manera, normalmente con puntos historia (como vimos antes, midiendo la complejidad del trabajo) al final de un periodo de tiempo (o Sprint) el trabajo de todo el equipo.
Una vez medido, cotejado normalmente con algunas prácticas de calidad de producto (Testing), nos centramos en si ese número sube, o baja, en los siguientes periodos de tiempo.
Concluyendo y tirando del sentido común….
Ciertamente, las medidas de productividad en desarrollo son así, demasiados vagas, inciertas e incluso peligrosas (como vimos con las líneas de código… pueden tener efectos incluso destructivos).
Pero, aunque matemáticamente no podamos calcular la productividad, no quiere decir que no exista, porque muchas veces sí intuimos que Pepe en más productivo que Manolo. Muchas veces lo llamamos, es mejor programador, es más bueno, sabe más, es más rápido… pero no podemos ponerle un número.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Estimado Javier:
Coincido en que no es posible medir la productividad de un programador, lo que se puede medir es el conocimiento que el programador tiene sobre el lenguaje y las herramientas de programación.
En cuanto a los programas y sistemas tengo la costumbre de decir a mis alumnos, que todos los programas funcionan, lo que sucede es que algunos no cumplen con todas las especificaciones con las que deberían cumplir, es decir no hacen bien las cosas para lo cual fueron concebidos y construidos.
Imagina una página Web, en la que todo funciona correctamente, se conecta se presenta,y todos los botones hacen la función que les corresponde pero el sistema no presenta la fecha en el formato solicitado por el usuario, decimos que no funciona, si funciona pero no cumple las especificaciones, así de sencillo.
Te envío un cordial saludo desde México D.F.
Ing. Mario Rodríguez Manzanera
Profesor de la Maestría de Ingeniería y
Ciencias de la Computación
IIMAS UNAM
Es el día a día. Creo que el enfoque está mal planteado. Se pone esfuerzo en tratar de medir lo que sale del proceso y poco esfuerzo en definir y medir las magnitudes que entran.
Creo que confundes medir la productividad con la incompetencia del gestor medio español. Si algunos cobran lo que cobran como programador es por algo muy tangible. Un buen programador vale mas que 3 malos y 3 malos valen mas que 6 malos, eso es mesurable.
Eso que mencionas Raul también es relativo. He visto en mi experiencia buenos programadores siendo menos remunerados que otros que no están en su mismo nivel.
Mi propuesta:
Considerando que no es un inútil, la productividad sería inversamente proporcional al número de bugs o cambios que reciben sus historias de usuario, funcionalidades, tareas o días de trabajo (como sea que lo mide su equipo).
Interesante post.
Hay también una herramienta para el IDE Visual Studio de Microsoft, se llama CodeAlike y tiene como fin medir la productividad del desarrollador (Cuanto tiempo se pasó escribiendo código, cuanto tiempo estuvo inactivo en el IDE, cuánto se pasó depurando el sistema y compilándolo, incluso el tiempo en que estuvo fuera del programa) plasmándola en gráficos historiales. Es una herramienta muy interesante, les dejo el link por si a alguno le interesa.
https://codealike.com/
Saludos!
En el caso que menciona Mario Rodríguez M., de que se puede medir el conocimiento del programador, Manolo puede saber mucho y Pepe lo mismo con el conocimiento que tiene, ¿vamos a darle mas puntos a Manolo solo porque tiene mayor conocimiento?, no me parece eficaz para medir la productividad.
Con respecto al numero de bugs ya lo comentaron, en el articulo implica pasar por la fase de testing, y ahí agregas a otra persona que afecta el resultado y otras razones mas por las que no es muy eficaz, ademas uno puede terminar rápido un sistema con algunos Bugs pero puede que a ti te importe entregar rápido y la calidad puede sacrificarse a veces, porque el cliente no recuerda porque te retrasaste, solo recuerda que te retrasaste.
Medir con el IDE como mencionan también puede ser engañoso, Manolo pudo teclear mas mientras que Pepe pudo quebrarse la cabeza para crear una linea que resuma las 900 lineas de manolo. Es como medir las lineas de código, poco eficaz.
La medición de un programador es realmente muy difícil y compleja. En mi caso para medir utilizo el problema a solucionar o desarrollar, en vista que allí se puede parametrizar un poco mejor. Es como las frutas que metes en el procesador, si son frutas grandes, medianas, chicas etc. De allí es que se debe definir el problema y analizar que hacer y ver si es complejo, si se puede utilizar código ya existente, el tiempo que puede llevar la codificación, testing, corrección de errores etc. Un ejemplo: se necesita agregar la captura del datos EMAIL al archivo cliente.
El cambio de pantalla es fácil, validación fácil, testing fácil tiempo 4 días. Si se llega al objetivo con los cambios que se solicito y en tiempo el programador es bueno.
La productividad de un programador es bastante diferente si la comparamos con la de otro empleado de la oficina. Esta es más compleja ya que requiere el uso de más programas, y de más concentración, por lo tanto su productividad se verá reflejada de manera diferente. Puede que sus horas productivas sean menores, sin embargo, seguramente su eficiencia será mucho mayor. Medir la productividad tiene bastante importancia en una empresa, ya que te permite recompensar a los empleados que se esfuerzan, y solucionar problemas en los campos que la actividad productiva es menor.
Debido a la complejidad del proceso de creación de software, considero que aún no se puede contar con una escala 100 por ciento efectiva hablando de la medición de la productividad de un programador. Son varios los factores que deben tomarse en cuenta para decir que alguien es o no productivo o qué tanto lo es.
Aunque no dudo que con el tiempo surja una escala que englobe todos o al menos los aspectos clave que reflejan la productividad de un programador, llevará tiempo para que los expertos en el tema se pongan de acuerdo para lograrlo.
Mientras eso sucede, se pueden utilizar algunas herramientas como «Codealike», o alguna manera para estimar la productividad, como los puntos historia.
Coincido en que no es posible medir la productividad de un programador, se puede medir con mayor facilidad el conocimiento que el programador tiene sobre los lenguajes de programación que el domina.
sobre los programas y sistemas que son utilizados para el desenvolvimiento de los programadores, siento que son efectivos siempre y cuando cumpla con las necesidades del programador y ayude y haga mas fácil el desarrollo del software.
muy interesante..creo que la productividad no se puede medir, por que algunos manejan sus programas con diferentes codigos pero puede ser igual de compresible ambos, el codalike tiene como objetivo medir el tiempo que te llevas en programar q paginas visitaste, pero eso depende de la capacidad de cada persona y que tanto se este enfocando en la tarea
muy interesante..creo que la productividad no se puede medir, por que algunos manejan sus programas con diferentes codigos pero puede ser igual de compresible ambos, el codalike tiene como objetivo medir el tiempo que te llevas en programar q paginas visitaste, pero eso depende de la capacidad de cada persona y que tanto se este enfocando en la tarea
Es muy difícil medir la productividad de un programador esto depende mucho de la complejidad del software que se desea realizar de las herramientas que utilice para el desarrollo del mismo y muy importante aún, del conocimiento y/o experiencias que el individuo posea.
Puede que con el tiempo se empleen estándares para medir la productividad de un programador basado en conocimiento y experiencia, hay algunas herramientas que tienen un objetivo parecido como es el caso de codealike que puede dar un estimado de la productividad del desarrollador.
Como opinión creo que en cuanto a los diferentes programas y sistemas todos tienen sus pro y sus contra, todos cumplen con las especificaciones para un buen trabajo por otra parte lo que se puede medir de un programador es la capacidad, eficacia y productividad de si mismo, que tanto conocimiento tiene respecto a los lenguajes y herramientas de programador.
Personalmente no pienso que la productividad de un programador se pueda medir, por ejemplo…
Esta midiendo por conocimientos, pero en un punto Manolo, tiene conocimiento, pero no tanto, y Pepe si…
Puede que Manolo con otro conocimiento que maneje pueda hacer lo mismo en ese momento pero con un conocimiento diferentes, eso le afectaría en esta medición pero en la productividad podría quedar mejor situado…
Para poder medir, como lo mencionó tendría que haber algún tipo de consenso entre expertos en la materia, el cual sería demasiado tardado y conllevaría a que muchos estuvieran en contra en algunos puntos en específico, lo que nos devolvería el mismo, tema, no se podría medir la productividad…
Podemos medir cuanto tiempo pasa el programador, valga la redundancia, programando, como lo dijeron mas arriba,c con «Codealike» pero simplemente te mostraría el tiempo que dedicaste al proyecto que estás programando, más no te daría un registro o dato específico de tu productividad, ya que para eso debería seguir algunas escalas para poder compararlas y obtener un promedio, el cual actualmente no existe.
Medir la productividad de un programador no es tarea fácil, en si se basa mucho en la experiencia y los lenguajes que se conozcan,
pero también depende del tipo de proyecto a realizar. por ejemplo, un recién egresado en el área, con los conocimientos previos no tendría la misma experiencia de alguien que lleva años, con lo cual la entrega de un proyecto seria mas tardada, con lo que se podría establecer que
el experto es más productivo basándose en la experiencia más sin embargo, el novato puede adquirir este conocimiento en poco tiempo con lo
que lograría ser más eficiente, eficaz y competitivo al grado se ser tan buen programador como el que ya tiene tiempo. Ambos pueden ser productivos solo seria el tiempo de entrega lo que determinaría su eficiencia, en si hay herramientas que miden el tiempo que se pasa alguien programando más no que mida el conocimiento.
Hay diferentes formas de programar, distintos entornos de programación donde se puede desarrollar el código de distintas manera, cada entorno ofrece un distinto tipo, y características que están incluidas. Medir la productividad de un programador es un tema complejo, por que la productividad se puede tener de la manera corta y larga, la programación tiene mucha estructura de código, la cual puede simplificarse de manera corta como larga y compleja, a veces un código para un programa que tiene muchas funciones, puede tener 1000 líneas de código de programación, pero si se puede hacer mas simple en 100, y da el mismo resultado, ¿La productividad de el programador es la misma? claro, por que se está dando el mismo resultado, hacer correr el programa deseado.
Estoy totalmente de acuerdo en que medir la productividad es algo totalmente complejo, ya que los programadores poseen distintas formas y estilos de hacerlo como se comenta hay quienes utilizan demasiadas lineas de código cuando simplemente puedes simplificarlo a solo unas cuantas lineas y el resultado seguirá siendo el mismo.
También debemos de tomar en cuenta los lenguajes de programación en los que se esta realizando dicha actividad, pero en resumen es un tarea muy difícil medir la productividad pero no dudo que en un futuro no muy lejano lleguen a existir reglas para realizar esta función basándose principalmente en la eficacia y tiempo para realizar los programas requeridos.
Es muy sencillo… Horas facturables a cliente / Horas-silla = rendimiento del técnico. (Ironic Mode on)
Si al interior de una empresa se puede saber quien es mejor desarrollador que otro, por sus conocimientos, habilidades, innovación, competencias, recursividad, experiencia, entre otros, es porque sí es posible medirlos… a veces lo que se valora es la pasión, el compromiso y el empeño por solucionar… no siempre se mide las líneas de código.
El desarrollo de software desde mi punto de vista, que quizá para muchos suene demasiado «romántico» , es un arte en el que una persona o un grupo de personas a través del máximo aprovechamiento de su capacidad de abstracción, su pensamiento lógico, sus habilidades matemáticas, su mente abierta, su creatividad, y su sentido común, logran dar solución a una necesidad que se les plantea.
Siendo así, la medición de un proceso de tal naturaleza se vuelve todo un reto.
Finalmente lo que se busca es que se satisfagan las necesidades o requerimientos de los usuarios, y que ellos, mas que nadie, estén satisfechos con la solución que se les entregó. Es como en la pintura, el valor de una obra se la da el gusto o placer que le cause al observador.
Pero entendiendo que esto es un negocio y se debe buscar la mejor relación costo-beneficio, la medición que yo sugeriría sería con la combinación de dos factores: la satisfacción del usuario y la productividad . A cada uno de estos factores asignarles un peso, según la valoración de cada negocio, y obtener una calificación ponderada.
La productividad se daría no por la medición en un evento, sino el promedio en un lapso de tiempo, de varios proyectos o desarrollos para cada uno de los cuales se tendría por una parte el grado de complejidad, digamos bajo, medio, alto; y por otra se estimaría inicialmente el tiempo para su desarrollo. Una vez terminado el desarrollo, se mediría si el tiempo destinado real (sumándole el tiempo destinado a corregir bugs) cayo dentro del tiempo estimado, obteniendo así una calificación de productividad que se iría acumulado para la obtención de la calificación ponderada antes mencionada.
Esa sería la idea general. Algo importante sería el peso que se asigne a los factores de Satisfacción y de Productividad. Personalmente pienso que el primero de ellos debiere tener un mayor valor.
Saludos cordiales.