El poder medir la productividad de los desarrollares es algo complicado dentro de la industria del software. Dado que todo lo que hace una desarrollador es intangible surgen dudas como: ¿El desarrollador esta haciendo lo suficiente dentro y fuera del reloj?, ¿Cómo se debe de medir su productividad? En este artículo comentare algunas dificultades de la medición de la productividad de los desarrolladores y así mismo algunas formas de hacerlo de manera correcta.
En el ámbito del desarrollo de software, como en cualquier otro campo, muchas personas piensan en la productividad en términos de insumos y productos. Dicho esto un desarrollador que trabaja de tiempo completo (40 horas a la semana) gana en promedio de $110,140 dólares al año en los Estados Unidos. Las horas y el salario son insumos visibles y cuantificables. Pero el desarrollador se encarga de crear aplicaciones, implementaciones, correcciones, documentación de forma recurrente. Estos son los resultados que ellos producen. Entonces si esos son los resultados que producen, para aumentar su productividad debería de ser tan simple como pedirles que trabajen mas horas o pagarles un salario más alto. Pero esto es una forma errónea de pensar. Ni los desarrolladores ni el software funcionan así.
Los problemas de medición de inicio
Las “Horas trabajadas” es una de las diferentes métricas falsas utilizadas como estadística para el rendimiento de la productividad. Si una empresa no evita intencionalmente hacerlo, tarde o temprano se convertirá en un entorno de solo horas. Comúnmente las horas de trabajo se consideran como no negociables, y estar presente en la oficina o conectado a una plataforma se ve como prueba de que alguien esta trabajando. Entonces siguiendo esta regla una persona que sale temprano del trabajo es mal vista y es sinónimo de improductividad y una que trabaja hasta altas horas de la noche y fines de semana es vista como una persona de alto rendimiento. Y con forme pasa el tiempo, el lugar de trabajo se convierte en un lugar donde todos trabajan, pero no se hace nada.
Sí damos por echo que todo trabajo es “trabajo positivo”, es decir que todo trabajo representa un progreso hacia una meta, entonces nos equivocamos. Los desarrolladores que han trabajado estando agotados, distraídos o enfermos tienden a estar familiarizados con el concepto de “trabajo negativo” es decir: trabajo mal hecho que debe deshacerse o corregirse mas tarde, incrementando así en lugar de disminuir la cantidad de trabajo restante. El desarrollo de software es un trabajo complejo, abstracto, atento y por tal motivo, susceptible al estado metal del desarrollador. Esta forma de trabajo negativo tarde o temprano se convierte en agotamiento, depresión, ansiedad, un ambiente de trabajo tóxico, entre otras cosas, que pueden reducir de manera considerable la productividad, ya que todo el trabajo que se realice será trabajo negativo por días e incluso semanas.
Por otra parte, un entrono de solo por horas no es el peor de los casos. Supongamos que dos desarrolladores trabajan el mismo numero de horas, hay una medida clara que son iguales. Pero qué pasa si uno de ellos escribe mal un código, a final de cuentas si el trabajo se mide por horas aun y este mal el código esta ocupando su tiempo. Así que la métrica por horas de trabajo se vuelve inútil, e incluso va contra la productividad en muchos aspectos.
Los problemas de medición del resultado
Aquí encontramos otras malas métricas dentro del desarrollo de software. Algunas personas piensan que la salida del trabajo del desarrollo de software son lineas de código o confirmaciones de control de versiones. Una linea de código que no soluciona un problema es peor que ninguna linea de código. De modo que medir la productividad de un desarrollador por cuantas lineas de código construye, es como medir cuantos ladrillos se agregan para construir un muro, siendo secundario al valor real.
Otra forma de una mala métrica es midiendo la productividad por errores corregidos y/o tareas completadas. Si el objetivo es corregir un mayor número de errores, los desarrolladores pueden escribir intencionalmente software con errores y luego escribir una gran cantidad de correcciones. Por otro lado si el objetivo es enviar características, ellos pueden escribirlas de forma rápida y mal hecha, resultando un software lento y que apenas funcional, ademas si el objetivo es es terminar todas las tareas, el equipo puede caer en la política de elegir las tareas más fáciles.
Medición de la productividad al nivel correcto
La medición de la productividad individual difícilmente se puede medir más allá de “este desarrollado contribuye” o “este desarrollador no contribuye”, de modo que para medir la productividad de los desarrolladores es necesario medirla por equipo, por que ellos no trabajan de forma solitaria, sino que el resultado de su trabajo de cada miembro del equipo es una función de la producción de trabajo de sus demás compañeros de equipo. Las interdependencias y matices del trabajo individual son demasiado complejas par ser medidas por un agente externo. Supongamos que un desarrollador no logre mucho por su cuenta, pero este se puede encargar de probar cuidadosamente una aplicación, limpiando y mejorando el código que sus compañeros crean, por lo tanto su productividad es muy compleja de medir, e inclusive pareciera que no logra mucho, pero su efecto en la productividad del equipo es exponencial. Por razones como esta, es mejor dejar que los contribuyentes individuales midan en sí mismos y entre sí.
Por otra parte, el rendimiento del equipo, es mucho más visible. Y tal vez la mejor manera de comprobarlo seria preguntar, ¿Produce constantemente este equipo software útil en una escala de tiempo de semanas a meses?, si la respuesta es sí, entonces el equipo es productivo y si la respuesta es no, se le debería estar preguntado averiguando a ese equipo el por qué no. Dicho esto, la mayor de equipos improductivos quieren ser productivos, y la mayoría de los equipos productivos quieren ser ma productivos.
La productividad del equipo se puede medir a escala organizaciones con observaciones simples y generales. Y dado que los miembros del equipo suelen ser muy consistentes de las contribuciones de los demás (ya sean medibles o no), cualquier falla considerable en la productividad individual se puede descubrir mediante buenos hábitos organizativos, como: recopilación regular de comentarios honestos y anónimos, entrevistas frecuentes uno a uno entre los gerentes y sus informes directos y también animando a cada miembro del equipo a asumir responsabilidad de sus logros y de sus fracasos.
Debido a que dentro del desarrollo de software depende de personas en lugar de gráficos y datos, es un hecho que el desarrollo de software se trata más de personas que de lineas de código. Las herramientas de seguimiento de la productividad y los programas de incentivos nunca tendrá un impacto tan grande como una cultura positiva de trabajo dentro de de una empresa. Y cuando la rendición de cuentas y la buena comunicación se incorporen a este tipo de cultura, la productividad se hará rápidamente visible para las personas mas capaces de utilizar estas postura.
Muchas organizaciones utilizan la velocidad como su métrica preferida para la productividad del equipo, y cuando se hace bien, esto puede ser una herramienta útil para comprender el proceso de desarrollo de software. La velocidad es una medida agregada de las tareas completadas por un equipo a lo largo del tiempo, por lo regular tomando en cuenta las propias estimaciones de los desarrolladores de la complejidad de cada tarea. Respondiendo preguntas como ¿Cuánto trabajo puede hacer este equipo en las próximas semanas? Siendo la respuesta de referencias tanto como lo hicieron en las ultimas dos semanas y la velocidad es el contexto de esa afirmación. El comprender la velocidad de un equipo, departamento o empresa puede ser primordial a medida que priorizan la creación de características, establece expectativas con los clientes y planifica el futuro de sus productos.
No existe una medida útil que opere a un detalle muy especifico que “tareas multiplicadas por complejidad”. El medir confirmaciones, horas dedicadas al desarrollo de software, lineas de código, como lo hacen algunas herramientas, no es más que útil a escala de equipo y no de forma particular.
Si bien es cierto que obtienes lo que mides, se debe de medir solo lo que realmente quiere, ya sea solo una característica o un modulo completo en una aplicación, y siempre con el objetivo de crear software útil nada más.
