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.

Comentarios

  1. El concepto de "testing orientado al resultado" es interesante, puesto que de alguna manera es equivalente al principio de "entregar software" de los métodos ágiles, pero aplicado al testing.

    ¿Y qué tal aplicaría aquí una división del tipo de error, fácilmente interpretable por el equipo de testing, y que tenga impacto sobre el producto final? Por ejemplo:

    Error de Estética - 0,5 PT
    Error de Interacción con la UI - 1 PT
    Error de Lógica de Negocio - 3 PT
    Etc.

    ResponderBorrar
  2. La duda que tengo es sobre el comentario de "fácilmente intepretable". Es muy común encontrar disparidad de criterios a la hora de clasificar errores según criticidades o tipos. Además, para hacer esto "más justo" no solo deberíamos tener en mente al equipo de testing sino a los desarrolladores y a los usuarios.

    Igualmente, es una idea que vale la pena explorar.

    ResponderBorrar
  3. Interesante post, K. Lo leí por Maxi que te hace propaganda. Yo creo que en muchos casos lo ideal es una combinación de las dos cosas... por ejemplo pagando sueldos por input y bonos por output o algo así. El output además debería ser el que determine promociones y aumentos. Si no, los testers se ponen de acuerdo con los desarrolladores y en dos meses te funden :-), como en el chiste de Dilbert.

    ResponderBorrar
  4. Si dos sectores se ponen de acuerdo... siempre te funden. Principio de control distribuido. K, MBA, explicale.
    Yo pagaría x combinación. La parte variable "objetivo negativo" por cantidad de errores que se te pasaron. Te los cuenta soporte a producción, son los clientes de testing. Si se te pasa 1, te pago 99%. Comentario obvio: al que le encontraron 100 errores no tiene motivación. Respuesta. Rajalo cuando llegue a 50. Y vos revisá tu recruiting!
    Y... a veces, a los vendedores se les paga también por entrevista. No sólo por venta. A los testers les pagaría una parte menor, del variable, por test ejecutado.
    Y laburar sólo por un variable?!?!?! Empiecen... si yo no llego arranquen nomás.
    Gracias K por escribir.

    ResponderBorrar
  5. Efectivamente, Maxi es uno de mis "punteros" propagandísticos! Gracias Maxi.

    Lo que proponés, Santiago, es lo que usualmente se hace. Sueldos x input + Premios/Bonus x output.

    Igualmente, ojo. Output no siempre es Resultado.

    La cuestión es definir resultado. Y resultado debería depender de la calidad y de la calidad.

    Una opción es hacer lo que dice Patito (Patito da la cara! Desenmascarate :-). Pagar el output contra resultado negativo. De hecho esa es una muy buena forma de definir el trabajo de un equipo de testing. Estableces un coeficiente entre errores detectados en Testing y errores detectados en Producción (coeficiente = errores en testing / (errores en testing + errores en producción). Repito esta es una muy buena forma de evaluar AL EQUIPO. No lo veo para individuos.

    Sigo pensando ...

    ResponderBorrar
  6. Doy la cara Patito es Martín Balzamo, con quien cuando eras joven escribías papers de testing!
    Una vuelta más: Los planes de test son muchos más parecidos al software que los errores. Un plan de test se guarda, se versiona, se puede planear el día de su liberación, se usa para tener un criterio de finalización (todos los casos ejecutados). Es ingenieril. Los errores... son magia, suerte. Se festeja cuando uno encuentra uno. A mi me gustaría que me paguen por plan, que los planes sean mi sueldo. Los errores encontrados mi premio. Los errores que se me pasaron mi castigo. Cuando seas mi jefe, tenelo en cuenta.

    ResponderBorrar

Publicar un comentario

Muchas gracias por comentar. Por favor deja tu nombre y/o email, los comentarios son mucho más valiosos cuando se sabe quien los hace.

Entradas más populares de este blog

10 definiciones de calidad

¿Qué es time and material?

Teoría Económica y Outsourcing