En la gestión empresarial, especialmente en el ámbito del desarrollo de software, los incentivos están diseñados para motivar a los empleados a alcanzar sus metas con mayor eficiencia y productividad. Sin embargo, todo incentivo mal formulado tendrá efectos indeseados, fomentando un comportamiento no buscado en los miembros de la plantilla.
El economista Gary Becker ganó el Premio Nobel de su disciplina en 1992, gracias a la afirmación de que las personas responden a incentivos (bueno, y a toda la investigación que hizo en torno a la misma, claro). El delito no se explicaba, según Becker, por la irracionalidad, enfermedad mental o mera influencia social: los delincuentes eran meros actores racionales reaccionando ante los incentivos disponibles.
Este fenómeno ha sido recientemente resumido de manera concisa y humorística en un tuit viral por el desarrollador Santiago L. Valdarrama, que expone por qué intentar recompensar el trabajo de los programadores basándose en métricas superficiales suele conducir al fracaso.
Valdarrama expone su caso a modo de fábula en el que una misma empresa va pasando por todos y cada uno de los errores posibles en este campo. Eso no suele ocurrir, claro, pero sí es fácil encontrar ejemplos de empresas que caen en uno u otro de ellos.
Imagen con la que Valdarrama ilustraba su tuit.
Primer error: centrarse en los bugs
Todo comienza con una medida aparentemente lógica: "Paguemos más a aquellos que solucionen más bugs".
Este es un enfoque directo, que parece premiar a los desarrolladores más diligentes. Sin embargo, tal como señala el autor del tuit, esta estrategia puede volverse rápidamente en contra de la empresa...
...pues al premiar sólo la cantidad de bugs resueltos, sin tener en cuenta el origen de los mismos, algunos desarrolladores podrían verse tentados a introducir fallos intencionales en el código, con la expectativa de corregirlos posteriormente y obtener la consiguiente recompensa.
Así, el sistema, en lugar de mejorar la calidad del software, incentiva la generación deliberada de errores.
"Me voy a escribirme un nuevo monovolumen", así retrataba Scott Adams la política de 'pago por bug solventado' en "Dilbert".
Un caso famoso
En realidad, la tentación de que el desarrollador genere los propios bugs que luego tendrá que solucionar está siempre presente, incluso cuando no hay de por medio una política explícita de incentivos.
Hace un tiempo os hablamos del caso de David A. Tinley, un desarrollador de software de 62 años que trabajaba para Siemens en Pensilvania... y que programó fallos (mediante el uso de 'bombas lógicas') en el sistema de hojas de cálculo que la empresa utilizaba para gestionar pedidos de equipos electrónicos, asegurándose de ser el único capaz de "repararlos" y facturar por ello,
Cuando surgían los problemas, Siemens recurría a Tinley para solucionarlos, y él sencillamente reiniciaba un contador en el código, garantizando así futuros errores y su propia recontratación. Este fraude le permitió mantenerse en su puesto entre 2014 y 2016, hasta que, en mayo de ese año, Siemens exigió su contraseña debido a una emergencia mientras Tinley estaba fuera de vacaciones.
Al acceder al código, la empresa descubrió el engaño. Y, finalmente, Tinley fue condenado a seis meses de prisión y a pagar una multa de 7.500 dólares.
Segundo error: centrarse en las "nuevas características"
La siguiente (mala) idea de los directivos de la fábula fue la siguiente: "Pagaremos más a aquellos que desarrollen más características nuevas".
A primera vista, esto podría sonar como un incentivo más razonable que el anterior: al fin y al cabo, nuevas características aportan valor al producto. No obstante, en la práctica, sin un criterio claro sobre qué constituye o no una "nueva característica", algunos desarrolladores pueden reinterpretar tareas menores como grandes avances.
Así, una pequeña modificación de interfaz o un ajuste trivial podría presentarse como una "innovación", mientras que los proyectos más complejos y cruciales —que requieren tiempo, esfuerzo y planificación— quedan relegados.
El ejemplo de Google
Aunque, según cómo gestione sus proyectos la compañía, esto puede tener otro efecto diferente: que las nuevas funciones sean, efectivamente, relevantes... pero que nadie solvente tenga ningún interés en darles mantenimiento.
Ya os hablamos hace un tiempo de las críticas internas que ha experimentado Google por lo que sus desarrolladores llamaban el 'ciclo LPA' (de 'Lanzamiento, Promoción, Abandono'), que provocan que la progresión profesional en Google se basa, ante todo, en la participación en lanzamientos (o, a lo sumo, en "revisiones importantes")... pero que "a nadie le asciendan por 'mantener' o 'arreglar algo roto'".
"Todos los ingenieros experimentados y ambiciosos abandonan el proyecto inmediatamente después del lanzamiento [...] y se van a un nuevo proyecto / equipo donde pueden obtener más créditos para la promoción. Las personas que permanecen son aquellas que no se pueden transferir fácilmente a otros equipos, es decir, ingenieros inexpertos o sencillamente mediocres".
Tercer error: medir por número de líneas de código
Ante la frustración de que se estaban incentivando tareas insignificantes, surge otra solución problemática: "Pagaremos más a quienes escriban más código".
Aquí, el razonamiento es interpretar que a mayor cantidad de código, mayor trabajo y productividad. Sin embargo, la realidad es más compleja. Al priorizar la cantidad sobre la calidad, los desarrolladores pueden empezar a llenar sus proyectos con código redundante, líneas en blanco o comentarios innecesarios. El código, en lugar de volverse más eficiente, se vuelve más voluminoso y difícil de mantener, lo que a largo plazo genera una sobrecarga en el sistema y un deterioro de la calidad del producto.
Cuarto error: ¿qué mejor métrica que el número de commits?
Desesperados por encontrar un método justo de compensación, los directivos deciden recompensar a los desarrolladores según el número de 'commits' realizados en GitHub, el repositorio de código más utilizado en la industria. Aquí, nuevamente, el problema no tarda en emerger.
Los programadores empiezan a fraccionar su trabajo en pequeñas porciones, realizando commits tras cada pequeña acción: "una línea de código, un commit". El resultado es un flujo interminable de pequeños cambios que no reflejan un progreso real, pero que logran inflar las estadísticas de productividad.
Quinto y último error: a la m* las métricas, recurramos a las reseñas
Finalmente, después de una serie de fracasos, la empresa opta por una solución que parece más difícil de corromper: "Pagaremos más según las revisiones de pares" (es decir, de las opiniones de los colegas del empleado). Esta idea busca fomentar un ambiente de colaboración, donde los compañeros evalúan el desempeño de cada desarrollador.
No obstante, en muchas empresas, este tipo de estrategias abre la puerta a la política interna... ¡Imagínate pensar que la política es difícil de corromper! Por supuesto, el favoritismo y las luchas de poder dejan rápidamente a un lado a la calidad del código, mientras que la habilidad para tejer alianzas estratégicas y evitar críticas se convierte en el verdadero indicador de éxito.
La base del problema
La moraleja de la historia es que la búsqueda de métricas cuantificables y fáciles de aplicar es un sueño imposible, porque se basa normalmente en pasar por alto la complejidad inherente al trabajo de los desarrolladores de software: el código no es una simple serie de tareas que se pueden medir por número o velocidad.
Imagen | Marcos Merino mediante IA
Ver 1 comentarios