¿Cómo afectar las prioridades de los errores a los desarrolladores y tratarlos en consecuencia?

Generalmente tienes dos ejes para errores: gravedad y frecuencia.

Obviamente, algo grave y frecuente es de la más alta prioridad. Sin embargo, algo que es serio pero que ocurre raramente debe ser pesado aproximadamente al mismo tiempo que algo que no es serio pero que sucede a menudo. Por lo tanto, suponiendo que califique la gravedad del 1 al 3 y la frecuencia del 1 al 3, los tipos de errores que probablemente debería corregir son aquellos que cruzan la diagonal definida por la gravedad 1, la frecuencia 3 y la gravedad 3, la frecuencia 1.

Un error de bloqueo o un error que podría crear un daño potencial a la información del cliente siempre sería una gravedad 3. De manera similar, un error con la gravedad 1 probablemente no será detectado por el usuario o tendrá una prioridad baja. Si no está seguro aquí, 2 es probablemente un número seguro para asignar.

Un error que el usuario ve cada vez que se inicia el programa tendrá una frecuencia de 3. Un error con la frecuencia 1 será algo que sucederá rara vez, en todo caso. Nuevamente, si no está seguro, 2 es probablemente un número seguro para asignar.

Es mayormente subjetivo sobre lo que constituye un error con la gravedad 3 o un error con la frecuencia 3, pero usa tu sentido común. Un error con gravedad 1, frecuencia 2 es quizás una etiqueta mal escrita. Un error con gravedad 2, frecuencia 1, podría ser un manejo adecuado de errores cuando la conexión de la base de datos no funciona.

Nuevamente, esto es solo una idea aproximada, pero la idea es enfatizar en lo que debería ser el enfoque para la corrección de errores como una especie de clasificación. Claramente, no es posible eliminar todos los errores, bloqueando o de otro modo, aunque al menos con esta metodología, puede decir con seguridad que los errores no son demasiado apremiantes ni demasiado frecuentes. Si solo solucionó errores que están bloqueando errores, los errores de alta frecuencia se ignorarán y los usuarios notarán que no solucionó estos errores.

Además, por conveniencia, puede que prefiera proporcionar grados de letras para la gravedad o la frecuencia, por lo que puede decir que un error es un error B3, y está claro tanto la gravedad como la frecuencia.

¡Buena suerte!

Esto realmente se reduce a lo que consideras más importante. ¿El error P2 o la nueva característica?

Por lo general, un sistema ágil de administración de proyectos incluirá algún tipo de reunión de priorización donde las tareas se ordenan por prioridad y se trabajan en ese orden.

Los desarrolladores no pueden elegir las tareas en las que trabajan. Ese es el trabajo del gerente de proyecto. Quién debe asegurarse de que el proyecto tenga el mayor número posible de características importantes incluidas antes de que se agote el presupuesto.

Eso es realmente lo más importante. Reglas simples como "arreglar al menos 1 P2 a la semana" realmente no ayudan a este objetivo.

Es un ciclo bastante común para un software acumular errores no críticos hasta que algo da, luego ocurre un gran evento y muchos de ellos se solucionan a la vez; tal vez dedicando un sprint o dos a solo correcciones de errores antes de una gran nueva versión, o porque el software es EOL y ha sobrevivido a la gran cantidad de errores.

Así que estás en buena compañía si tus desarrolladores simplemente los dejan pasar. Por supuesto, puede hacer malabarismos con las "reglas" como mencionó ("si no está trabajando en una nueva función, debe trabajar en al menos un P2 por semana"), pero eso probablemente lo hará impopular.

  

Mi pregunta es cómo hacer que la gente se encargue de los errores, sin imponer una agenda estricta y sin embargo, para que se resuelva.

En cambio, sugeriría cambiar un poco la mentalidad general y hacer que los errores se parezcan más a las características en el sentido de que son ciudadanos de primera clase en su acumulación. Sí, las nuevas características son geniales; Sí, la administración y las ventas tiran muy duro de las nuevas características. Pero tener una aplicación estable y que funcione bien en lugar de una enorme pila de errores desordenados también es importante.

No le digas a tus desarrolladores que deben hacer un trabajo que no les gusta; Pero intenta cambiar el ambiente para que les guste trabajar en los errores. Trate de inculcar un sentido de orgullo en una aplicación libre de errores. Haga que sea más divertido (sic) trabajar en un error permitiéndoles específicamente que corrijan la razón subyacente que hizo que ese error se manifestara (es decir, no solo soluciones rápidas / trucos), si existe alguno. Extraer una estructura de clase rota y reemplazarla con algo más adecuado puede ser muy entretenido para los desarrolladores. Si tiene alguna pieza central rota que regularmente hace que los errores se manifiesten en otra parte, arregle la pieza central.

La forma en que alcances tu objetivo depende en gran medida de tu propio carácter y el de tus equipos. No trates de engañarlos para que consigas lo que quieres, pero mantén discusiones abiertas, trata de lograr un efecto de igual a igual, déjalos idear un proceso de trabajo, y así sucesivamente.