¿Debería pagarse dinero como motivación para los probadores y desarrolladores para detectar y producir errores?

Leí una idea para aumentar la productividad en una empresa. Fue así:

Tener un cierto fondo, eso será un bono. Digamos $100,000. Por cada error tangible encontrado, a los probadores se les paga entre $5 y $15. Lo que quede al final del mes/año va a los desarrolladores.

Parece una idea bastante maravillosa en teoría, aunque no estoy seguro de qué tan bien funcionará en la práctica. La consecuencia obvia de esto es que promueve el antagonismo entre Devs y testers. El negocio de los bichos se convierte en un juego de suma cero.

¿Es el antagonismo algo malo? ¿Cómo afectará a la productividad y, lo que es más importante, a la organización? La experiencia personal será muy apreciada.

(Me estremezco cuando leo esquemas "motivacionales" como este).

Quizás el autor de esta idea defina "productividad" de manera diferente a como lo haría yo.

El objetivo de la mayoría de las empresas que producen software es ganar dinero y quizás maximizar la cantidad de dinero que ganan. El objetivo de un sistema de recompensas por errores es menos claro y ciertamente no tiene nada que ver con la productividad. Se gastaría mucho tiempo tratando de obtener dinero de bonificación, y poco tiempo tratando de enviar el software (que es la forma en que la empresa gana dinero).

Imagine una empresa que tiene un desarrollador y un probador.

Si usted fuera el desarrollador, su estrategia óptima sería retener todo el software del probador hasta que no quedara ningún error, o hasta que no hubiera tiempo en el cronograma para que el probador encontrara alguno.

Trabajé en una empresa que recompensaba a los desarrolladores con elogios, en lugar de dinero, y esa fue exactamente la estrategia utilizada por un desarrollador. Las compilaciones se enviaban al control de calidad cada 2 semanas. Y cada dos viernes, teníamos una reunión de todo el equipo en la que se anunciaba el recuento de errores en la compilación actual. Si un desarrollador alguna vez tuvo cero errores, ese desarrollador fue señalado y elogiado por hacer un gran trabajo.

Un desarrollador decidió jugar con el sistema. Mantendría la construcción (siempre con excusas razonables) hasta justo antes de la reunión semanal. Luego lanzó la compilación, se ejecutó el informe de conteo de errores y, "por arte de magia", tuvo un conteo de cero errores justo a tiempo para la reunión.

Si bien era una buena desarrolladora, su código no era mejor que el de la mayoría. Su inteligencia estaba en manipular el sistema a su favor.

Actualmente trabajo en una tienda que castiga a los desarrolladores por la cantidad de errores atribuidos a su trabajo durante un proyecto. Se espera que "mejoren" su recuento de errores con respecto al año anterior. Esto es parte de sus MBO y parte de lo que se incluye en su pago de bonificación anual.

Como era de esperar, han tardado mucho en producir la primera compilación comprobable para el control de calidad. Y pidieron que el control de calidad pasara mucho tiempo probando en el entorno de desarrollo (donde no se pueden escribir informes de errores). Se les ha dado todas las oportunidades para producir menos errores en el sistema de informes y, por lo tanto, para maximizar su bonificación.

El gerente de productos incluso decidió cambiar muchos informes de errores a "solicitudes de mejora" para no afectar a los MBO de los desarrolladores. Su argumento fue "bueno, los desarrolladores no han desarrollado completamente esa función, por lo que la mejorarán cuando tengan tiempo".

Si me pagaran "por el error", podría encontrar un montón de errores con bastante facilidad, sin importar cuán bueno sea el desarrollador. (He estado haciendo este trabajo durante casi 30 años). Me centraría inicialmente en la fruta madura y me saltearía cualquier cosa que consumiera mucho tiempo. Mis informes de errores serían mínimos y no muy útiles, básicamente lo que fuera necesario para ingresar el informe de errores en el sistema y obtener el dinero.

El resultado sería una gran cantidad de informes de errores superficiales que eran "lo suficientemente tangibles" y el software inevitablemente se quedaría con algunos errores críticos importantes. No puedo imaginar que el sistema se envíe alguna vez.

Los desarrolladores centrarían todo su tiempo y atención en el nuevo código. No habría absolutamente ningún beneficio financiero en corregir los errores que ya se encontraron. Y se les daría un incentivo para producir lanzamientos diminutos e insignificantes. Si producen un lanzamiento que contiene solo una línea de código perfecto, ¡obtienen un bono de $ 100k! ¿Por qué agregar características complicadas?

Ambos equipos discutirían con vehemencia sobre todos y cada uno de los informes de errores y si realmente se trataba de un error "tangible" o no. (Ese es un término agradable y confuso. Me encantaría escuchar a un equipo tratar de definirlo de manera concreta). Este tipo de argumentos no preparan el escenario para nada que yo llame productividad.

Y ni los evaluadores ni los desarrolladores dedicarían tiempo a nada más. Sin reuniones, sin documentación, sin atención al cliente, sin ayudar a otros, sin preparación para el envío. Oye, si fuera importante, habría dinero en efectivo adjunto, ¿verdad?

Y esta última parte es significativa. Para los trabajadores del conocimiento, a menudo otorgar bonificaciones en efectivo a tareas que intrínsecamente sienten que son importantes es un gran desincentivo. Si desea una mayor comprensión de los tipos de disfunciones que pueden surgir de este tipo de sistemas de incentivos, le recomiendo que lea Medición y gestión del desempeño en las organizaciones de Robert D. Austin.

En resumen, esta es una idea terrible.

La mayoría de las buenas compañías de software reconocen la locura de tal plan y tratan de mantenerse alejadas de este tipo de sistema. La mayoría de las empresas de software entienden que lanzar software sin errores no es un objetivo realista y que es más importante lanzar el software de manera oportuna.

Parece una idea espantosa. Aquí hay algunas cosas que sucederán, además de que sus desarrolladores y evaluadores comiencen a odiarse entre sí y a usted mismo por presentar esto:

• Todo el mundo se centrará en la fruta madura. Esto significa que el control de calidad comenzará a informar todo tipo de cosas que en realidad están bien, pero que podrían interpretarse como "defectuosas" con la esperanza de que se les pague, mientras que Devs centrará todo su trabajo en asegurarse de que no haya errores obvios y mucho menos en hacer seguro que no hay errores estructurales complejos.
• Algunas personas se juntarán y un desarrollador introducirá intencionalmente una tonelada de errores, luego lo enviará a un control de calidad específico para "encontrarlos" y luego dividirá el dinero.
• Algunos de tus empleados se sentirán insultados porque piensas que solo valoran su trabajo si reciben una bonificación por ello. Probablemente trabajarán menos y producirán más basura debido a esto.
• La comunicación entre los miembros del equipo se romperá debido al aumento del antagonismo. Ahora es realmente una ventaja para los desarrolladores no ayudar a QA a hacer mejor su trabajo, porque cualquier error que pasa desapercibido en producción significa que se les paga más.
• Los desarrolladores no se agradarán entre sí, porque cada error que un desarrollador presente les costará dinero a todos.

Esto está justo fuera de mi cabeza. Nunca intentes motivar a los programadores y QAs con dinero, solo resulta terrible. Sus trabajos se basan en una motivación intrínseca.

Además, eche un vistazo a esta charla TED animada sobre el impulso y la motivación, ya que explica mucho mejor por qué cualquier configuración que involucre motivar a las personas inteligentes con dinero fallará terriblemente:

https://www.youtube.com/watch?v=u6XAPnuFjJc

Esto tiene tanto sentido como tener la tripulación de un barco dividida en equipos, los que hacen la propulsión y los que navegan, compiten en una carrera entre ellos, en el mismo barco.

Me niego a tener una relación antagónica con mis probadores. los valoro Me hacen un mejor programador.

También respeto la creatividad que les exige su trabajo. Por eso creo que el dinero es el motivador equivocado aquí. Los estudios han demostrado que, a menos que un trabajo sea prácticamente sin sentido, los incentivos en efectivo en realidad, de manera medible, ralentizan a las personas.

El trabajo creativo no está mejor motivado por el dinero. Sus mejores motivadores son:

autonomía: el deseo de dirigir nuestras propias vidas
dominio: la urgencia de mejorar o desarrollar habilidades
y propósitos: la necesidad de hacer lo que hacemos por razones más grandes que nosotros mismos

Así es, las opciones, las oportunidades para mejorar y el trabajo en equipo funcionarían mejor que el dinero.

El control de calidad es un trabajo creativo. La tarea realmente es pensar en lo que los desarrolladores no pensaron. Esta es la razón por la que el control de calidad debe automatizarse. Una vez que se piensa en una prueba, no debe "realizarse" una y otra vez como una obra de Broadway. Debe automatizarse para que el control de calidad pueda dejar de pensar en ello y pensar en la siguiente prueba. El control de calidad debe estar lleno de sus desarrolladores más talentosos. Porque están tratando de pensar mejor que su otro equipo de desarrolladores.

Algunos no lo creen. Algunos piensan en el control de calidad como un basurero para los desarrolladores menos talentosos. Si has estado haciendo eso, tus prioridades están al revés. Desafíe a sus mejores desarrolladores para que modernicen sus pruebas y asegúrese de que la gente sepa que QA es donde usted pone lo mejor.

Si ese dinero todavía está haciendo un agujero en su bolsillo, utilícelo en capacitación o, si es necesario, en paquetes de indemnización.

Aquí no hacemos trabajos sin sentido.

Tener un cierto fondo, eso será un bono. Digamos $100,000. Por cada error tangible encontrado, a los probadores se les paga entre $5 y $15. Lo que quede al final del mes/año va a los desarrolladores.

Esto es horrible. Por todas las razones en las otras respuestas y por el hecho de que no pasa esta prueba muy simple:

• ¿Qué sucede si todos sus empleados son excelentes y no se encuentran errores?

  La producción funciona perfectamente y todo el dinero se destinará a DEVS.

• ¿Qué pasa si todos tus empleados son basura?

  La producción se quemó hasta los cimientos debido a los errores, pero bueno, a quién le importa, el dinero irá a los DEVS.

Incluso si el dinero fuera un motivador en nuestro negocio, esto estaría terriblemente mal.

Tome el dinero y contrate a alguien que sea realmente bueno escribiendo especificaciones y planificando proyectos con plazos manejables. Tanto DEV como QA estarán mucho más felices de lo que cualquier dinero podría hacerlos.

Puede que sea apócrifo, pero me dieron un ejemplo similar en la década de 1980 cuando cubrí la "Ley de las consecuencias no deseadas" como parte de un curso de BPR.

El ejemplo se refería a una línea de producción de fábrica donde el departamento de control de calidad estaba incentivado por la cantidad de rechazos que hacían. El departamento de producción fue incentivado de manera similar según la cantidad de rechazos que produjeron.

El efecto neto fue que el control de calidad rechazó más productos que antes y la producción tardó más en producir artículos "perfectos", por lo que la producción general disminuyó mientras que los costos aumentaron debido a los pagos de incentivos. La calidad no se vio afectada.

Funciona mal. No lo he visto con desarrolladores y probadores. Pero el departamento de justicia de Nueva Zelanda en un momento recompensó a los guardias de detención periódica por cada detenido que violaron. Pasó de una infracción en una mala semana, a que algunos detenidos recibieran 6 infracciones en un día y terminaran en prisión por ello. Finalmente, un alcaide resultó herido.

Dudo que llegue tan lejos ya que no es la misma cantidad y gente menos volátil (creo), pero genera mala sangre entre los grupos que ya están en desacuerdo debido a sus roles.

Otras respuestas ya han dicho suficientemente que su idea es mala TM. Así que no repetiré más eso, y en su lugar mencionaré lo que necesitarías cambiar para mejorar la idea.

Está tratando de adjuntar dinero a lo que en última instancia es un número en un papel. Ese número no generará dinero. Para empeorar las cosas, el número que desea usar es en su mayoría aleatorio: un producto que nunca tuvo errores de repente tiene 50, todos ellos errores tipográficos en la documentación. Un error que altera el color de resaltado de 200 elementos se convierte en 200 errores. Tan pronto como le pides a algunas personas que hagan que el número suba mágicamente, ese número es un número imaginario completamente inútil. Y además de todo, desperdiciarás decenas de miles de dólares en salarios con reuniones absolutamente inútiles donde la gente discute qué es y qué no es un error.

Si desea adjuntar bonificaciones u otras recompensas a los números en un papel, estos números deben vincularse directamente con el dinero real ganado por la empresa; un ejemplo común es la bonificación vinculada a las ganancias en una empresa comercial.

Como se ha sugerido en los comentarios de 'magdalenas' bajo su pregunta, algunas formas de gamificación pueden funcionar. ¿Qué tal asignar un trofeo al 'Mejor error' encontrado durante un período determinado, asignado por votos de ambos equipos juntos ?

En un entorno de desarrollo saludable, hay un 'asombro' compartido entre evaluadores y desarrolladores sobre las personas (generalmente los evaluadores) que encuentran esos molestos errores que solo pueden reproducirse bajo ciertas condiciones, sobre ese error intermitente que lo ha estado molestando durante meses, sobre algo muy simple que un desarrollador pasó por alto, etc. ^*

El trofeo debe ser algo muy simple, porque no se trata de su valor intrínseco: un cartelito, un pastelito, una barra de chocolate.

^{* Ese último ejemplo no se trata de encontrar un error, sino de causar un error. En ese caso el premio significa burla amistosa. Necesitas una cultura para eso donde tus colegas reconozcan que todos cometemos errores.}

Creo que el resultado sería perjudicial. Está en contra de las prácticas de sentido común tanto de desarrollo como de prueba.
Cero errores encontrados no significa que el software sea bueno. Podría ser demasiado complejo probarlo o el control de calidad podría omitir algunas pruebas. Incluso si no se encontraron errores, el extenso proceso de prueba y la gran calidad del código no significan que el producto sea bueno. Si los requisitos se desordenaron, el software puede ser terrible para el cliente.

Jugar contra ese sistema podría ser extremadamente fácil.
Para desarrolladores: compilaciones tardías. Para probadores: concentración en errores triviales.
Con compilaciones tardías, las pruebas tempranas son imposibles. ¿Poco tiempo para probar y gratificar por la cantidad de errores? Los probadores se concentran en errores triviales, como etiquetas mal escritas o algunos casos no críticos.
Si quieres saber si el producto es bueno, solo pregúntale a tu cliente.

Larga historia corta. Los desarrolladores y evaluadores están trabajando en el mismo barco: su empresa.

Es fácil criticar a los desarrolladores por un error que producen, pero es difícil recompensarlos por errores que no han producido.

Si el error llegó a la versión final y el cliente lo informó, ¿a quién culpar? ¿Desarrollador por escribir el error o probador por no detectarlo?

Esto provoca la tensión entre desarrolladores y probadores por defecto. Su idea pone tensión adicional entre los dos. Realmente no quieres eso.

Si tiene un espacio de trabajo amigable y desea recompensar a la detección de errores, divida el presupuesto entre todos de manera justa, haga una lista de desarrolladores y, por cada error, el desarrollador deberá pagar $ 1 al banco. Organiza la fiesta de Navidad y usa el banco para recompensar a todo el equipo. Asegúrate de que sea más divertido que la recompensa/castigo y que nadie se lo tome (demasiado) en serio. Premie tanto a los "peores" como a los "mejores" entre los desarrolladores y evaluadores.

Honestamente, el incentivo, en el mejor de los casos, parece inútil y, en el peor, dañino. Si tiene un equipo de control de calidad dedicado, ya ha reservado fondos para encontrar errores, ya que será una gran parte de su descripción de trabajo. No habrá mucho antagonismo adicional entre los dos, ya que habrá más hacia la política en sí. Si realmente está preocupado por el problema tanto como para tirar dinero a sus empleados actuales con condiciones, sería mejor contratar a alguien donde lo necesite, ya sea en control de calidad o desarrollo.

Donde esto podría salir realmente mal es en el lado del desarrollador es que verá una caída en los lanzamientos por temor a que se les pague menos debido a nuevos errores y en el lado del control de calidad podría ver fases de revisión mucho más largas debido a que los probadores quieren algo pago extra. No digo que esto vaya a suceder, solo que es una posibilidad.

Nadie quiere errores en su producto final, pero sucederán. Como gerente, hay formas mucho mejores de asegurarse de que existan menos errores en el código, como tener objetivos y cronogramas realistas y permitir la facilitación para un mejor desarrollo, como revisiones de código.