Tenemos un proceso de error que se está trabajando actualmente.
Tenemos 3 niveles de error:
- Error P1: errores que impiden que los usuarios trabajen. Deben resolverse en el acto.
- Error P2: errores que afectan pero los usuarios pueden trabajar
- Error P3: errores que no afectan y donde los usuarios pueden trabajar.
P1 es obligatorio y debe tratarse en el acto. Pero para P2 y P3, juzgamos caso por caso.
Con los 3 niveles que tenemos, el equipo tiene la tendencia de trabajar en nuevos desarrollos más urgentes solicitados por los clientes, en lugar de tratar con P2 y P3, que es casi como no urgente.
Las preguntas son las siguientes:
¿Debo agregar otro nivel de prioridad, como tener un P4?
¿Debería asignarles objetivos para tratar con tickets no urgentes como en esta semana, cuando no asigne una tarea de codificación, debe tratar al menos 1 P2?
Actualmente, no tenemos objetivos como los que mencioné anteriormente, pero mi preocupación es que darles tales objetivos puede ser brutal. Lo que es seguro es que necesito hablar con ellos sobre los objetivos, al equipo le gusta participar en la discusión, especialmente cuando estamos estableciendo objetivos.
Actualizar:
Me propusieron esta pregunta en términos de similitud. Sin embargo, no es similar, en absoluto.
Mi pregunta es cómo hacer que las personas se ocupen de los errores, sin imponer una agenda estricta y sin que se resuelva. Entonces no, la pregunta implícita no me ayuda. Aún así, gracias.
fuente
.release().Respuestas:
Generalmente tiene 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 de la misma manera que algo que no es serio pero sucede a menudo. Entonces, suponiendo que califique la gravedad de 1 a 3 y la frecuencia de 1 a 3, los tipos de errores que probablemente deba 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. Del mismo modo, un error con la gravedad 1 probablemente no sea notado por el usuario o tenga baja prioridad. 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 rara vez ocurre. Nuevamente, si no está seguro, 2 es probablemente un número seguro para asignar.
Es principalmente subjetivo sobre lo que constituye un error con gravedad 3 o un error con frecuencia 3, pero usa tu sentido común. Un error con la gravedad 1, la frecuencia 2 es quizás una etiqueta mal escrita. Un error con gravedad 2, frecuencia 1, podría ser un manejo de errores adecuado cuando la conexión de la base de datos está inactiva.
Nuevamente, esta es solo una idea aproximada, pero la idea es dar énfasis a lo que debería ser el foco para la corrección de errores como una especie de triaje. Claramente, no es posible eliminar todos los errores, bloqueos o de otra manera, aunque al menos con esta metodología, puede decir con seguridad que los errores no son demasiado apremiantes ni demasiado frecuentes. Si errores que están bloqueando los errores exclusivamente fijo, a continuación, se tendrán en cuenta los errores de alta frecuencia y los usuarios van a notar que no se soluciona estos insectos.
Además, por conveniencia, es posible que prefiera proporcionar calificaciones 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!
fuente
Esto realmente se reduce a lo que consideras más importante. ¿El error P2 o la nueva característica?
Por lo general, un sistema de gestión de proyectos ágil 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 del proyecto. Quién debe asegurarse de que el proyecto tenga la mayor cantidad 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 por semana" realmente no ayudan a este objetivo.
fuente
Es un ciclo bastante común para un software acumular errores no críticos hasta que algo cede, luego ocurre un gran evento y muchos de ellos se arreglan a la vez; tal vez dedicando un sprint o dos a solo correcciones de errores antes de una nueva versión grande, o porque el software es EOL y ha sobrevivido a los errores de montón.
Entonces, estás en buena compañía si tus desarrolladores simplemente los dejan pasar. Por supuesto, puedes hacer malabares con las "reglas" como mencionaste ("si no estás trabajando en una nueva función, debes trabajar en al menos un P2 por semana"), pero eso probablemente te hará impopular.
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 cartera de pedidos. Sí, las nuevas funciones son geniales; Sí, la gerencia y las ventas aprovechan mucho las nuevas funciones. Pero también es importante tener una aplicación estable y que funcione bien en lugar de una gran cantidad de errores desordenados.
No le digas a tus desarrolladores que deben hacer un trabajo que no les gusta; pero trata de cambiar la atmósfera para que les guste trabajar en los errores. Intenta infundir orgullo en una aplicación sin errores. Haga que sea más divertido (sic) trabajar en un error permitiéndoles específicamente corregir la razón subyacente que hizo que ese error se manifieste (es decir, no solo soluciones rápidas / hacks), si hay 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 otro lugar, repare la pieza central.
La forma en que alcances tu objetivo depende en gran medida de tu propio personaje y el de tus equipos: no trates de engañarlos para lograr lo que quieres lograr, sino que tengas discusiones abiertas, trata de lograr un efecto de pares, deja que se les ocurra un proceso de trabajo propio, y así sucesivamente.
fuente