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

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.

agile debugging issue-tracking

— Andy K
fuente

Posible duplicado de ¿Cómo puedo convencer a la gerencia para que se ocupe de la deuda técnica?

— mosquito

generalmente el nivel de prioridad no es tan útil como el orden de prioridad ... "error X" es más importante que "error Y". si agrega p4 eventualmente querrá p5 y p3.5

— sudo rm -rf slash

Si tiene tantos errores P1 que todos sus desarrolladores siempre están ocupados reparándolos en lugar de trabajar en P2 / P3, está haciendo algo muy mal. No agregue más funciones por un tiempo. Concéntrese en profundizar y solucionar los problemas arquitectónicos (o de personal) que casi con seguridad causan muchos de estos errores. Si está codificando en C ++, por ejemplo, asegúrese de estar utilizando RAII en todos los lugares que pueda, para que no se olvide de hacerlo manualmente .release().

— Financia la demanda de Mónica el

¿Cuál es tu objetivo? ¿Desea que los desarrolladores trabajen más en la corrección de errores y menos en las nuevas funciones? Edite su pregunta para aclarar. Además, describa cómo los desarrolladores actualmente reciben o toman el trabajo. ¿Qué se usa para decidir en qué se trabaja?

— sleske

función, error, cambio como lo llames, el software no hace lo que necesita. La única diferencia entre un error y una característica es quién lo paga.

— mattnz

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!

— Neil
fuente

En realidad, solo hay una métrica para los errores: ROI: cuánto costará arreglar en comparación con cuánto pierde la compañía por no solucionarlo. Compare eso con las características. Por supuesto, cómo calcular esa métrica implica la gravedad, la frecuencia, etc.

— corsiKa

@corsiKa, sí, el ROI es una métrica compuesta: "retorno" e "inversión". Y para los errores, el retorno puede modelarse como un compuesto de "gravedad" y "frecuencia".

— Paul Draper

@corsiKa, ese tipo de análisis egoísta a sangre fría de las decisiones de calidad es en realidad extremadamente irresponsable. Es la misma lógica que lleva a las compañías farmacéuticas a eludir las leyes de pruebas de eficacia si pueden "salirse con la suya" o mantener medicamentos rentables en el mercado a pesar de la gravedad y la frecuencia de los efectos adversos. Es la misma irresonibilidad que conduce a vastas redes de bots compuestas de enrutadores de consumidores inseguros y dispositivos "inteligentes", porque el fabricante no podía ver ningún valor en dólares con buena seguridad. La gravedad y la frecuencia son MUCHO mejores métricas que el "impacto final".

— Comodín el

@Wildcard Soy literalmente comunista, así que estoy 100% de acuerdo contigo en que son mejores. Eso no cambia el hecho de que así es como se manejan las compañías de software, y ir contra esa corriente, a menos que usted maneje la compañía, lo ahogará. Aunque vale la pena señalar, no es egoísta. Es de una sola porción, pero ese soltero no es el yo, es la compañía. Solo, tirando eso por ahí.

— corsiKa

@Wildcard y corsiKa, la compañía no es grande y no podemos darnos el lujo de decir "oh, vamos a perder dinero, entonces hagamos algo, de lo contrario vamos a mantenerlo quieto". Sin embargo, en el gran esquema de las cosas, no creo que el enfoque que mencionó sea sostenible a largo plazo. Gente: los clientes están lejos de ser estúpidos. Las compañías que han estado predicando ese tipo de evangelio, Sun, por nombrar uno ya no están aquí. He estado trabajando en la administración de cuentas el tiempo suficiente para que el dinero no se gane de esa manera. Para cualquiera, si usted trabaja para una empresa donde la empresa carece de lealtad 1 / n

— Andy K

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.

— Ewan
fuente

El problema con la asignación de prioridades es que, sea cual sea la granularidad de cubeta que elija, siempre terminará con más de una por cubeta. Debe poner las cosas en orden, no solo decir "¡todo esto es PRIORIDAD SUPERIOR!"

— Ewan

@Ewan También existe la posibilidad de una inflación prioritaria en la que su segmento más alto tiene más problemas de los que puede esperar abordar, y se inventan nuevos niveles de prioridades fuera del sistema de seguimiento de errores. He escuchado a personas hablar de P menos 2 problemas.

— kasperd

Decir que los desarrolladores no pueden elegir las tareas en las que trabajan dañará su productividad. Si un desarrollador está bloqueado en el problema de mayor prioridad en el que estaba trabajando, es mejor si puede trabajar en otro problema mientras tanto que no hacer nada mientras su primer problema está bloqueado en algo. Además, los problemas que no perjudican a los usuarios pero que perjudican la productividad del desarrollador a menudo no se priorizan tan alto como deberían. Finalmente, decirles a los desarrolladores que no tienen permitido tomar sus propias decisiones es una forma segura de destruir la motivación.

— kasperd

@kasperd Creo que la mayoría de los desarrolladores aceptan que son empleados, así como súper genios técnicos, y que su empleador decide qué tareas deben hacerse primero. Obviamente, si uno está bloqueado, pasaría al siguiente más importante, pero no se saltará 10 tareas importantes para trabajar en la genial.

— Ewan

Descubrí que si el trabajo se completa o se bloquea, en lugar de arrastrar otra tarea de desarrollo al sprint (hacer scrum), un error debería tener prioridad. MS dio a todos los errores la más alta prioridad sobre cualquier tarea de desarrollo cuando trabajaba en Windows 2000: descubrieron que era la mejor manera de producir software sin errores (una de las razones por las que 2000 era realmente querido) como si no lo hicieran. , los errores tenderían a desaparecer, ya que generalmente había un nuevo desarrollo en el que trabajar.

— Baldrickk

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.

Mi pregunta es cómo hacer que las personas se ocupen de los errores, sin imponer una agenda estricta y sin 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 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.

— AnoE
fuente