Cómo establecer KPI correctamente alineados para ingenieros y personal de control de calidad

Introducción

Me gusta configurar KPI para mis equipos de ingeniería/control de calidad. Lo uso para evaluar el rendimiento y ayudar a determinar la bonificación/aumento cada trimestre.

Este es un KPI que establecí para mis ingenieros:

  • % de tareas que pasaron el control de calidad sin errores

    • es decir, dependiendo del flujo de control de calidad (por problema o por sprint), vemos cuántos errores se informaron contra todos los problemas que completó 1. el ingeniero que arregló el problema 2. el otro ingeniero que lo revisó.
      • es decir, en un sprint dado, el ingeniero X resolvió 20 problemas, que fueron revisados ​​por el ingeniero Y. Suponiendo que el control de calidad hace su trabajo en un sprint y que el control de calidad encontró 5 errores en esos 20 problemas, las tareas pasaron el control de calidad sin porcentaje de errores es 75%

  • % de tareas que funcionaron correctamente después de la implementación La misma idea que la anterior, pero esta será tratada para el código que realmente se publica en vivo y es utilizado por los usuarios

Este es un KPI que tengo para mi personal de control de calidad:

  • número de errores encontrados por problema
    • es decir, cuantos más errores encuentre una persona de control de calidad en un problema, mejor.

Problema

Los KPI para los ingenieros y el personal de control de calidad parecen contradictorios, o dicho de otra manera: parecen un juego de suma cero. Lo que obviamente no es bueno para la moral de los empleados y causaría rivalidad/resentimiento.

¿Cómo puedo cambiar esto para que tanto los ingenieros como el personal de control de calidad tengan KPI que los hagan trabajar juntos en lugar de uno contra el otro?

actualización: un caso concreto

esto es en respuesta a la respuesta de novigt a continuación, así como en referencia a este comentario en una publicación relacionada:

¿Los probadores están involucrados antes de una compilación? ¿Es decir, están involucrados en el desarrollo de los requisitos o casos de uso o historias de usuario, revisando la documentación de diseño o participando en revisiones de código?

Pensé que la documentación adecuada y sólida de los escenarios es una gran parte de la evaluación del personal de control de calidad (tenga en cuenta que aquí estoy hablando de control de calidad no técnico que simplemente realiza pruebas de caja negra y no puede realizar pruebas automatizadas, etc.).

Acepto que una métrica que calcula el número total de errores es falsa y estoy de acuerdo con la métrica de incidentes en producción .

Permítanme explicar mi nueva métrica con un ejemplo:

ingrese la descripción de la imagen aquí

Supongamos que tengo una sola pantalla de inicio de sesión (contraseña olvidada/recuérdame, etc. no incluida por brevedad) que me gustaría construir e implementar. Usando la sintaxis de Gherkin , el ingeniero de control de calidad escribe los siguientes escenarios:

Escenario 1: El usuario de inicio de sesión de Happy Path
given ingresa el nombre de usuario/contraseña correctos. El
whenusuario hace clic en el
thenusuario de inicio de sesión y debe dirigirse al panel de control.

Escenario 2: error de inicio de sesión El
given usuario ingresa un nombre de usuario/contraseña falsos El
whenusuario hace clic en
thenel mensaje de error de inicio de sesión: Nombre de usuario/contraseña incorrectos

esta documentación se entrega a los ingenieros (junto con los diseños) en sprint one , quienes la desarrollan, la revisan, la envían de vuelta al control de calidad para que la prueben y luego se implementa en la versión 0.0.01 de la aplicación.

Una vez en producción, ocurre el siguiente error

givenel usuario ingresa el nombre de usuario/contraseña correctos
andel servidor está inactivo el whenusuario hace clic en iniciar sesión el usuario
then
esperado
debería recibir un mensaje de error: el servicio no está disponible actualmente
la
rueda giratoria gira para siempre

Estos son los KPI/métricas que capturamos para este escenario:

  • número de escenarios: 2
  • número de incidentes en producción: 1

las métricas como una instantánea no dan una imagen completa, así que continuemos:

así que en el sprint dos , el personal de control de calidad actualiza la documentación con el escenario 3:

escenario 3: manejar el inicio de sesión cuando el servidor está inactivo el
given usuario ingresa el nombre de usuario/contraseña correctos
andel servidor está inactivo el
whenusuario hace clic en iniciar sesión el
thenusuario debería recibir un mensaje de error: el servicio no está disponible actualmente

los ingenieros corrigen ese error y lo implementan en la versión 0.0.02 , en la versión ocurre este error:

givenel usuario ingresa el nombre de usuario/contraseña correctos
andel usuario no está conectado a Internet el whenusuario hace clic en iniciar sesión el usuario
then
esperado
debería recibir un mensaje de error: el usuario está desconectado
real
una rueda gira para siempre

Estos son los KPI/métricas que capturamos para este escenario:

  • número de escenarios: 3

  • número de incidentes en producción: 1

  • tasa de incremento de escenarios: 33%

  • tasa de disminución de incidentes en producción: 0%

por lo que usamos los dos últimos KPI (aumento de escenarios y disminución de incidentes en producción) juntos para evaluar el desempeño de una persona de QA. La evaluación final debe usar ambos KPI (además de otras métricas que se pueden discutir en otro lugar) para evaluar a un ingeniero. De esta manera, aumentar los escenarios de casos inútiles por sí solo no será positivo por sí solo, y también un aumento en los incidentes en producción sin un aumento correspondiente en los escenarios debería ser una señal de alerta para el ingeniero. Sé que también se puede lograr esto mediante pruebas unitarias integrales que tengan una cobertura de código superior al 95 %, etc., pero supongamos que aún no hemos llegado a ese punto.

¿Hay algún problema con esto?

"Una vez en producción, ocurre el siguiente error" Esto no es un error . Un error es una desviación de la especificación. Esto nunca estuvo en la especificación para empezar. Etiquetar esto como un error hará que sus ingenieros se sientan muy descontentos. Un error es un error que cometí como ingeniero, algo que no funciona según las especificaciones. Algo que no está en la especificación es una solicitud de función y nunca se debe reclamar contra nadie más que el que escribe las especificaciones.
@nvoigt bastante justo, no lo llamaré un error, lo llamaré error de especificación ... y entonces un KPI para el personal de control de calidad (nuevamente, no ingenieros) es la cantidad de errores de especificación por sprint... ¿funciona?
¿Quién juzga que el control de calidad debería haber especificado eso? Y si esa persona sabe lo que debería haberse especificado, ¿por qué no lo hizo en primer lugar en lugar de dejar que los pobres chicos de control de calidad adivinaran?
Es trabajo del control de calidad asegurarse de que la documentación cubra todos los casos de usuario posibles. Esto no significa que todos esos casos de uso se implementarán en la versión 0.0.01, pero al menos necesitamos saber que existen (se pueden hacer en una versión posterior según el modelo lean). Además, esto no es un todo o nada. No estoy diciendo que si ocurre una falta de especificación , el control de calidad será golpeado en el estacionamiento. Estoy diciendo que estas son métricas que podemos usar como complemento en su evaluación...
.. Es decir cuando evalúo a un empleado miro varias cosas, incluyendo sus KPI's. ¿Está haciendo una declaración absoluta de que todas las métricas/KPI son malas? Déjame tratar de ver las cosas más desde tu perspectiva. Suponiendo que tiene trabajadores del conocimiento que le reportan, ¿cómo evalúa su desempeño (sin ninguna métrica)? ¿Y cómo puede respaldar esa evaluación? ¿Cómo se puede escalar ese proceso?
Bueno, si su control de calidad escribe sus especificaciones, espero que les pague muy bien, porque eso está muy por encima del nivel de pago del trabajo normal de control de calidad. Sería el trabajo de un analista de negocios o propietario de un producto, dependiendo de qué tan ágil quiera ser. De todos modos, no, no tengo KPI y solo puedo juzgar en función de mi comprensión de la parte técnica más mi intuición. No digo que sea genial. Simplemente supera las métricas que he visto hasta ahora. Me encantaría tener KPI transparentes, pero los trabajadores del conocimiento pueden jugar fácilmente con todo lo que sé. Al final, lo que cuenta es la entrega de un producto libre de errores.
.. pero sabemos que un producto libre de errores no existe en la vida real?
de todos modos... ya me diste mucho en qué pensar... tengo que leer algunos libros e investigar un poco más, definitivamente no me siento tan fuerte con todo esto como lo hice... gracias por toda tu información :)
De nada. Me gusta el hecho de que lo pienses. Hay demasiadas personas por ahí que no lo hacen (y he visto sus métricas...).
Pregunta rápida @nvoigt: ¿qué piensa de la idea de usar métricas para mejorar los procesos en la organización en lugar de castigar/recompensar a las personas? Es decir, mejora de procesos basada en datos

Respuestas (1)

Así que en este momento, como ingeniero, tomo una sola tarea, la reflexiono durante 4 semanas, me aseguro de que no contenga ningún error y soy el mejor trabajador que haya tenido. A pesar de que me tomó 4 semanas entregar una tarea tan simple.

Por otro lado, está el control de calidad, que depende enormemente de que se le asigne un ingeniero de mierda. Cuanto más malo sea el ingeniero, más recompensas obtendrá el control de calidad. ¿Qué pasa si tengo que probar un producto de un buen Ingeniero? ¿Me pondrán en un plan de mejora del rendimiento por no encontrar suficientes errores?

Sus métricas son arbitrarias y menos que útiles. Su gente no son drones trabajadores, usan su inteligencia para hacer su trabajo. Por lo tanto, no los insulte con métricas que puedan manipularse fácilmente.

Al menos empezar por lo que realmente importa: las incidencias en producción . Errores que escaparon tanto a los ingenieros como al control de calidad. Intente minimizarlos y verá que los ingenieros y el control de calidad son en realidad un equipo que trabaja con el mismo objetivo final.

Sin embargo, es discutible si vale la pena tener métricas para los trabajadores de inteligencia. Nadie ha encontrado los correctos todavía y los incorrectos pueden resultar contraproducentes fácilmente. Si basa algo en sus KPI (como elogios o salarios), prepárese para que las personas sean lo suficientemente inteligentes como para burlarse de usted en cualquiera de ellos. Entonces estás atrapado con personas que hicieron su trabajo, pero se ven promedio en las métricas y personas que jugaron con el sistema en lugar de hacer un buen trabajo, pero se ven geniales en tu sistema.

Su punto está bien entendido acerca de que el kpi inicial no es útil, actualicé mi pregunta con una métrica diferente que espero aborde sus puntos. Por favor echa un vistazo. Además: es discutible si vale la pena tener métricas para los trabajadores de inteligencia. Nadie ha encontrado los correctos todavía. ¿Puede mencionar una investigación o estadística (o incluso algún artículo de opinión) que respalde ese punto?
@abbood No, no puedo respaldar algo que no existe. Nunca he visto KPI que funcionaran bien para los trabajadores del conocimiento, ni he oído hablar de ellos. Si encuentras algunos, házmelo saber, estaría feliz de tenerlos.
@abbood Joel tiene (tenía, pero no estoy al tanto de los cambios) una perspectiva similar sobre los KPI para los trabajadores del conocimiento .
@nvoigt ¿Cómo evalúa BA la solución usando KPI? En realidad, tengo pocas recomendaciones sobre aspectos tecnológicos y operativos comerciales y trato de evaluar la solución, pero realmente me cuesta identificar el KPI. ¿Puede darme al menos 2-3 KPI para que eso comience o darme una idea de cómo debería ser el KPI, por favor?
Cómo establecer KPI correctamente alineados para ingenieros y personal de control de calidad
RespuestasAquíPolítica de privacidad1y, 0v