Pay per defect o elevar la conciencia creativa del acto verificador

¿Como creéis que se debe incentivar a los equipos de calidad? ¿Es posible incentivar por defecto encontrado o es contraproducente? Imaginemos una compañía que decide incentivar por objetivos, e incentiva el equipo de desarrollo por funcionalidad implementada en el menor tiempo. ¿Como incentivamos al Tester? o dicho de otra manera como sabemos quién realiza mejor labor de verificación?

Una respuesta de otro amigo:

Pues yo creo que incentivar la localización de errores está bien. Eso sí, debe haber un “juez” que decida si cada caso es digno de contabilizar o no, es decir, que tome la decisión en los casos dudosos (”es que no estaba en los requisitos escritos” … “sí, pero es algo ‘obvio’” … y cosas de ese estilo). Ah! Y añado otra cosa : igual que se incentiva la localización de errores en el testeo creo que se debería “desincentivar” cuando un Cliente localiza el error una vez lanzada la versión. Luego se hacen las cuentas de la vieja y se saca balance. Ya verías la de errores que se encuentran !!! jejeje



	¿Como creéis que se debe incentivar a los equipos de calidad? ¿Es posible incentivar por defecto encontrado o es contraproducente? Imaginemos una compañía que decide incentivar por objetivos, e incentiva el equipo de desarrollo por funcionalidad implementada en el menor tiempo. ¿Como incentivamos al Tester? o dicho de otra manera como sabemos quién realiza mejor labor de verificación? Una respuesta de otro amigo: Pues yo creo que incentivar la localización de errores está bien. Eso sí, debe haber un “juez” que decida si cada caso es digno de contabilizar o no, es decir, que tome la decisión en los casos dudosos (”es que no estaba en los requisitos escritos” … “sí, pero es algo ‘obvio’” … y cosas de ese estilo). Ah! Y añado otra cosa : igual que se incentiva la localización de errores en el testeo creo que se debería “desincentivar” cuando un Cliente localiza el error una vez lanzada la versión. Luego se hacen las cuentas de la vieja y se saca balance. Ya verías la de errores que se encuentran !!! jejeje
	El aporte de uno más: ¿Qué tal un esquema intermedio? 1) Incentivar a los desarrolladores con relación inversa al número de defectos que “les” encuentren los Testers. 2) Incentivar a los Testers con relación al número de objetos/unidades/loquesea que pasen a producción validados 3) E incentivarlos a todos con la “velocidad” del proceso completo, y con relación inversa a los defectos encontrados en producción. La “fórmula” no sería sencilla, pero puede que se lograse un resultado adecuado. ¡O que se lograse confundirles a todos! ¡¡¡¡me encanta este aporte!!!! Pero mi opinión fue la siguiente: Me resulta un poco extraña la cuestión de tener que incentivar a un Tester o grupos de Testers por tener que hacer su trabajo bien. Igual para los desarrolladores o cualquier otra persona que cumpla un rol específico dentro de la cadena productiva de software. En primer lugar considero que un plan de verificaciones y/o validaciones no puede quedar librado a la buena de un Tester, sino que debe guiar a cada uno de los involucrados en el proceso hacia los resultados esperados, también sus controles y gestiones. Si se considera la existencia de Testers en un equipo de producción de software, no debe ser sin la existencia de un responsable QA y la carga de gestión recae sobre los hombros de tal o tales personas. Lo que se puede hacer es “elevar la conciencia creativa del acto verificador” agregando capacitaciones especializadas en herramientas, conceptos avanzados, UML, patrones de calidad y demás elementos que existen para sumir al equipo de calidad en un estándar que desde el llano y como punto de partida sea muy alto. Podría agregar que es bueno tener métricas de cantidades de defectos detectados por Tester pero no podríamos dejar de mirar que tipo de defectos detecta cada uno de ellos y como es el impacto de cada uno de esos defectos detectados en los proyectos. Esto serviría para que en caso de necesitar dividir el equipo de Testing, al “mejor Tester” se le asignaría una especie de “jefatura” sobre otros que no tienen el mismo rendimiento. Dependiendo del entorno de trabajo, la suspicacia de las personas, los objetivos personales de cada integrante del equipo de Testers entre otros elementos RRHH, es bueno aplicar criterios de competencias operativas. Pero en otros casos no. Equipos enteros podrían desintegrarse por generarse ciertas incomodidades. No quiero ni hablar de como impactaría sobre nuestros productos. Entonces, pagar por defectos detectados vale para equipos de venta. Ya todos los defectos del producto fueron eliminados o se presumen eliminados y el producto de alta calidad. Ahora a generar retorno de la inversión. Me gusta mucho la idea de incentivar, pero sin generar competencias sino ambientes colaborativos (inclusive para eso estamos aquí nosotros) y cada uno en su puesto de trabajo debe elevar al máximo su conciencia de responsabilidad. Los Testers suelen encontrar fallos de severidad Invalidante o Graves a penas inician el Testing. No es mérito del Tester sino de la incompetencia de alguien en fases anteriores. No señalo a nadie, pero desde el Tester para atrás, hay muchas responsabilidades intrínsecas. Es cierto también que al principio el Tester se haría de una muy buena suma de dinero extra por la cantidad de detección de fallos y conforme avanzan los ciclos, deberá devolver dinero y hasta poner de su bolsillo por que no encontrará fallos que se sabe por métricas, están allí. Cierta oportunidad siendo Líder de Testing al finalizar uno de los proyectos postulados para certificación CMMI-4, mi equipo detectó grandes cantidades de fallos en los productos solo en los primeros ciclos, cuando había planificados 12 ciclos de pruebas. Conforme se comenzaron a resolver los fallos, previo a los ciclos subsiguientes, nuestra tasa de detección cayó significativamente para el resto de los ciclos (considerar PARETO). Esto me llevo a analizar la situación, a modificar definitivamente el modo en que manejamos los ciclos. Finalizado el proyecto que menciono, invité a mi equipo a un almuerzo y por supuesto al equipo de Desarrollo. Allí pude explicar lo que habíamos conseguido trabajando en equipo y como unos sin otros no pueden evidenciar su actividad hecha con responsabilidad. Gracias a esto pudimos mejorar nuestro proceso en forma significativa. Creo en definitiva, que brindar las herramientas adecuadas, la capacitación necesaria y sostener un ambiente colaborativo y ameno, son los mejores incentivos. Javier Santillán.