En testing de software lo que importa es el resultado

No resulta novedoso decir que la forma en que una empresa decida remunerar a sus empleados tendrá un importante impacto en el tipo de personas que querrán trabajar en ella y en los resultados que producirán.

En el libro Personnel Economics de Edward Lazear se distinguen dos formas de remunerar: pagar por el "input" y pagar por el "output". Pagar por el input usualmente significa establecer un salario por unidad de tiempo (días, semanas, meses). Pagar por el output significa pagar por los resultados producidos, por ejemplo por la cantidad de piezas.

La discusión sobre qué forma adoptará la empresa es relevante puesto que el pago por el output o pago por resultados (como también se lo conoce) tiene una ventaja interesante: induce a los empleados más ineficientes a dejar la empresa. En el libro citado es posible encontrar una explicación detallada de esta afirmación pero pensándolo un momento y siguiendo nuestra intuición, la afirmación es razonable. Si soy un empleado ineficiente y, mi producción no alcanza para generar una retribución mayor a la que ganaría en otra empresa que paga por el input, lo lógico sería irme a esa otra empresa.

Un factor importante a la hora de decidir qué forma de remuneración emplear, dice Lazear, es el costo de medición. En muchos casos es difícil (o muy costoso) "medir" el resultado del trabajo. En esos casos se termina pagando por el input que es más fácil de comprobar (lo único que tiene que hacer el empleador es mirar si el empleado está o no está sentado en su escritorio). Pero pagar por el input tiene sus problemas también puesto que genera problemas de selección adversa (los empleados más eficientes no encuentran incentivos para permanecer y se van, dejándonos en manos de los menos eficientes).

Hay puestos en los que es más fácil implementar esquemas de pago por "output" - por ejemplo un área de ventas -, en otros puestos es más difícil. En el caso de un tester de software, cuyo trabajo es realizar pruebas sobre un determinado software y luego reportar los errores que encuentra, pagar por resultados suele ser traducido como pagar por cantidad de errores.

El problema es que encontrar muchos errores o ejecutar muchas pruebas no es sinónimo de hacer un buen trabajo o de lograr resultados. Como Larry Osterman explica en este post, la calidad de los errores encontrados generalmente es más importante que la cantidad. Si pagamos a los testers por la cantidad de errores, se orientarán a producir cantidad dejando de lado la calidad de lo producido.

Dicho todo esto, sigue siendo mejor establecer un esquema de remuneración que pague por el output y no por el input. El gran desafío está en encontrar formas de medición de costo razonable que nos permitan distinguir los buenos resultados de los malos.