Casi todos los errores reportados son de alta prioridad [cerrado]

He notado un patrón mientras trabajaba en varios proyectos de software: la gran mayoría de los errores reportados tenían una prioridad alta / muy alta. Pregunté a algunos colegas por qué puede estar sucediendo esto, y mencionaron que si un error no tiene ese nivel de prioridad, es muy raro que el Bug atraiga la atención del desarrollador, lo que tiene sentido.

Entonces, quería saber si este problema es común o si tuve mala suerte. Hice una búsqueda rápida en Google y descubrí que algunos equipos implementan las pautas de Informe de errores o tienen un equipo separado de "Clasificación de errores". Si ha enfrentado y resuelto este problema, ¿cuál fue el enfoque que funcionó para usted?

Esta pregunta es específicamente sobre el problema de "Inflación de prioridad": si se enfrenta al escenario y qué medidas resultan efectivas contra este problema.

Pregunté a algunos colegas sobre lo que podría estar sucediendo, y mencionaron que si un error no tiene ese nivel de prioridad, es muy raro que el Bug atraiga la atención del desarrollador, lo que tiene sentido.

En realidad, si me preguntas no lo hace. Cuantos más (usados) niveles de prioridad, más información tiene. Si efectivamente solo tiene una prioridad, eso es lo mismo que no tener ninguna prioridad.

Y dado que todavía tiene la misma cantidad de errores que abordar, y la misma cantidad de horas hombre para hacerlo, se deduce que se utilizará alguna otra heurística, posiblemente la nula: "primero llegado, primero servido". Y ahora tiene una métrica de prioridad de error, excepto que es la hora de llegada y ya no está bajo su control.

Puede ser un síntoma de que no se asignan suficientes recursos para la corrección de errores (existen algunas políticas como " No hay nuevas características hasta que se solucionen los errores " que pueden ayudar. Joel lo aprueba ; comprender los límites y las consecuencias es una decisión comercial ).

En un proyecto en el que trabajé, los errores entrantes se acumularon en un "búfer sin prioridad" y todos los lunes revisábamos la lista de errores, estimábamos la dificultad (una estimación muy aproximada; la mayoría de las veces simplemente colocamos, "Promedio") y ordenarlos por tiempo disponible. Esto tiende a derribar la lista de errores aburridos, poco interesantes o pensados ​​para ser difíciles; Para compensar eso, los supervisores y el departamento de marketing tenían un cierto número de créditos por semana que podían gastar para superar la prioridad de los errores favoritos, y se les reembolsaba los errores no resueltos (esto establece un límite sobre cuánto podría retrasarse un error despreciado por el desarrollador) .

También fue posible fusionar, cancelar y dividir errores; Recuerdo un módulo que tenía un defecto tan irremediable que hundimos unos veinte o treinta informes de errores en un solo "reescribir esto desde cero", que luego se dividió en "indicar claramente las entradas y salidas del miserable", "escribir pruebas para garantizar que las entradas y salidas coincidan con la especificación ", y así sucesivamente. El último elemento fue "imprimir el código antiguo en papel reciclado, sacarlo al césped y prenderle fuego" (también lo hicimos. Recuerdo lo bien que se sintió. Nos turnamos para el elogio; fue muy gracioso )

Después de algunos regateos, tuvimos la lista de tareas de la semana, que se dividió en "hacer", "podría hacer" y "no puedo hacer" que se incluyeron en la próxima semana. Aquí es donde entraban algunos regateos adicionales: teníamos unas cincuenta horas para asignar a los errores, y estábamos 95% seguros de arreglar los primeros veinte. La gerencia quería que se corrigiera un error número veintiuno y no le quedaban créditos; luego ofreceríamos intercambiar ese error con uno en la lista "Lo haré", o alguien diría "Sácame del equipo secundario de FooBazFeature por un par de días y lo haré", o diríamos "Necesitamos más mano de obra".

El sistema no satisfizo a nadie, en realidad, pero se creía que esto (al menos entre los desarrolladores) era una buena señal.

Algunos patrones negativos adicionales que aparecieron fueron el "Pensamiento ilusorio" por parte de los gerentes ("Usted dijo que el error 57212 requiere ocho horas. Eso es inaceptable. Que sea cuatro") y el "Depurar por Fiat" ("Haga lo que quiera pero estos cuarenta errores deben corregirse antes de la gran demostración de la próxima semana. No se puede tener más tiempo, no se puede tener más gente "). También el Síndrome de Boxer ("Trabajaré más duro"), que tendió a funcionar muy bien por un corto tiempo , pero usualmente llevó a un desarrollador a enloquecer o partir hacia pastos más verdes.

Si tiene este problema en el que los usuarios asignan errores de prioridad cada vez mayor, entonces la única solución realista es un mecanismo de clasificación. Todos los errores se informan con la prioridad que deseen, pero algún administrador deficiente tendrá que revisar cada error recientemente informado y restablecer su prioridad a un nivel razonable.

Después de un tiempo, sus usuarios recibirán el mensaje o puede cambiar el sistema de informes para que cada error tenga una prioridad predeterminada. Si quieren que se intensifique, deberán contactar a alguien para que lo golpee, lo que requerirá alguna justificación. Este hecho solo hará que el usuario deje sin escalar el 99% de todos los errores.

Obviamente, tiene más errores de los que puede procesar, por lo que tal vez necesite embarcarse en un resumen de corrección de errores para eliminar el retraso. Esto mostrará a los usuarios que sus errores se solucionarán sin necesidad de que se marquen como super-super-dooper-realmente-no-honest-this-important-this-time.

DESCARGO DE RESPONSABILIDAD: Todavía no he tenido experiencia con travesuras de prioridad de errores informadas por los usuarios. Sé que la pregunta pide esto, pero podría ayudar tener la perspectiva de un extraño.

Su problema no es que tenga demasiados errores de alta prioridad. Su problema es que tiene demasiadas personas que tienen control directo sobre la prioridad de los errores. Si cada usuario puede asignar directamente una prioridad a su error, informará casi automáticamente su problema como de alta prioridad.

Podría hacerlo de modo que la prioridad de errores deba ser configurada por un gerente o un dron de servicio de asistencia, pero esto podría conducir al favoritismo y la ingeniería social, donde un cliente obtiene una prioridad artificialmente mayor debido a su estado o porque saben cómo elaborar sus mensajes. haz que parezcan más importantes. También es mucho más laborioso.

Hay un término medio, donde los usuarios tienen cierto control sobre la prioridad, pero de una manera que hace que sea más difícil explotar el sistema. Básicamente, obliga a sus usuarios a usar una plantilla para informar errores. Primero seleccionan una categoría:

1. El programa se vuelve inutilizable o se bloquea cuando hago algo.
2. El programa tiene un defecto gráfico que afecta la funcionalidad.
3. El programa no me permite hacer algo que debería poder hacer.
   El programa me permite hacer algo que no debería poder hacer.
4. El programa da el resultado incorrecto cuando hago algo.
5. El programa lleva demasiado tiempo para hacer algo.
6. El programa tiene un defecto gráfico que no afecta la funcionalidad.
7. El programa tiene un defecto que no cabe en una de las categorías anteriores.

Para dar ejemplos:

1. Mi iPhone se bloquea cuando recibo un mensaje que contiene símbolos hebreos.
2. Mi pantalla de bloqueo de Android gira de tal manera que la mitad cae de la pantalla.
3. Mi teléfono Android a veces no acepta mi código de bloqueo de pantalla, aunque ingresé el código correcto.
4. Cuando intento navegar a PhoneHub.net, mi teléfono me redirige a un sitio para adultos.
5. Cuando abro la aplicación de Facebook, tarda un minuto en abrirse, incluso en conexiones rápidas y sin otras aplicaciones ejecutándose.
6. Tu aplicación tiene un error ortográfico.
7. Encontré un defecto de seguridad en su programa y me gustaría informarlo.

Como puede ver, cada uno de estos errores tiene un grado de gravedad diferente, y las categorías se ordenan aproximadamente según esta gravedad. A continuación, puede asignar una prioridad a cada error según la categoría, quién lo informa y las palabras clave que aparecen en la descripción. Los errores en la categoría 7 deben tener su prioridad asignada manualmente.

Tenga en cuenta que esto puede suceder de forma totalmente automática, y debe dejar que esto suceda automáticamente; De hecho, la automatización es la clave aquí. Los usuarios son propensos a sobreestimar su propia importancia para el negocio, por lo que no ven un problema al informar sus errores como una prioridad más alta de lo que deberían. están menos inclinados a colocar deliberadamente su error en una categoría diferente, porque eso requiere que básicamente mientan sobre el error.

Los usuarios aún pueden ingresar sus errores en la categoría incorrecta, por supuesto. Lo primero que debe hacer es, desde la versión 1.0, mostrar un mensaje amigable que aliente a los usuarios a proporcionar información precisa sobre el error para ayudar a los desarrolladores a encontrarlo y solucionarlo más rápido. La mayoría de los usuarios comprenderán y dejarán de informar errores erróneos. Algunos usuarios aún pueden continuar proporcionando información incorrecta. Cuando eso suceda, envíe a esos usuarios un recordatorio amable por correo electrónico de que la información precisa es importante y, por favor, no abusen del sistema. Si continúan falsificando registros, les advierte que están abusando deliberadamente del sistema y que el abuso continuo dará como resultado que a sus errores se les asigne automáticamente una categoría inferior. Si persisten, puede ajustar su multiplicador de errores.

Puede ver partes de este sistema en situaciones de soporte de alto rendimiento: compañías tecnológicas gigantes como Microsoft, Facebook, Google, compañías de juegos con muchos usuarios como Valve y Blizzard, ciertos gobiernos, ... Aunque no estoy seguro del funcionamiento detrás de escena, observa que su sistema de soporte orientado al usuario tiene una interfaz similar a la que sugiero aquí, con un sistema de categoría estricto.

Como la gente ha dicho, esta es la razón por la cual las personas que reportan errores no pueden asignar prioridad. Su equipo de desarrollo debe tener el control de su propia asignación de tareas (dentro del alcance establecido por la alta gerencia). Así, alguien más arriba dice "trabajar en esta aplicación, fijar esta característica, hacen que sea mejor en hacer esto ", y el equipo tiene que decidir cómo hacer eso, porque son los que tienen los conocimientos técnicos necesarios para evaluar cómo mejor para lograr lo que la gerencia quiere.

Las personas que informan los errores deben asignar niveles de impacto o gravedad , que tienen un alcance definido. Puede llamar fácilmente a las personas por no apegarse a los niveles de severidad acordados, porque tiene evidencia material de esos niveles. Por ejemplo:

1. Pérdida completa de funcionalidad.
2. Pérdida parcial de funcionalidad.
3. Reducción generalizada de la efectividad.
4. Reducción localizada de efectividad
5. Molestia u obstáculo (existe una solución alternativa)
6. Cosmético
7. Nadie se dio cuenta realmente, fue encontrado durante una oscura prueba exploratoria

Para comenzar, puede usar estos niveles como un instrumento contundente para señalar que una desalineación de algún texto del título no es un error de Nivel 1 porque no deja inutilizable toda la aplicación. Una vez que tengan la idea, puede hacerlo más detallado y comenzar a debatir si la falla en la actualización de este cuadro de texto es un Nivel 5 porque puede solucionarlo haciendo clic derecho en el cuadro de texto varias veces, o un Nivel 4 porque está ralentizando a todos en Contabilidad para que obtengan menos formularios procesados ​​por hora.

Una vez que tenga información útil y medible sobre qué tan grave es el error para su organización , la asignación de prioridad se vuelve obvia. Lo que sea que esté causando el mayor problema para la organización (pérdida de ganancias, daños a la imagen pública, infelicidad de los empleados, lo que sea) será de alta prioridad, y usted trabajará desde allí.

Va un poco así:

Mgr: ¿en qué estás trabajando? Dev: estas tareas de baja prioridad Mgr: ¿no deberías estar trabajando en tareas de alta prioridad?

Cliente: ¿cuándo se solucionará mi error? Dev: es de baja prioridad tenemos tareas de alta prioridad. Cliente: oh, bueno, entonces establezco mi estado de error en alta prioridad.

Esto conducirá a niveles de prioridad cada vez mayores. Veo que ya has pasado de alta prioridad a muy alta prioridad. Los siguientes serán:

1. Súper alta prioridad
2. Prioridad ultra alta
3. Muy Súper Ultra Alta Prioridad.
4. Muy Súper Ultra Mega Alta Prioridad.

etcétera etcétera.

Sí, este es un proceso normal. Siempre y cuando no haya ningún costo involucrado en la asignación de prioridad, y la persona que llama tiene influencia, por supuesto que tratarán de resolver su problema de la manera más rápida y establecer la prioridad más alta.

Básicamente hay 2 formas de contrarrestar esto:

1. Quite el control del cliente con respecto a los niveles de prioridad.
2. Asigne un costo al cliente para niveles de prioridad elevados.

Se pueden agregar niveles de prioridad cada vez mayores al sistema, especialmente si es Jira. Dar a las nuevas altas prioridades cada vez más tontas, pero los nombres terribles pueden aumentar el impacto del efecto Hawthorne en la calidad de las elecciones prioritarias hechas por todas las partes. Si la prioridad más alta tiene un nombre realmente extravagante, el efecto podría ser permanente. Finalmente, cuando alguien elige una prioridad, tiene que sopesar las consecuencias sociales de elegir la prioridad del "error de la muerte" en lugar de obtener la debida atención. Por lo tanto, la máxima prioridad está reservada de facto para algo que le sucedió al CTO en casa frente a sus invitados u otros incidentes de visibilidad equivalente.

Introducir un costo para apoyar las solicitudes. Solo puede permitir que un usuario informe X número de elementos de alta prioridad en un período de tiempo determinado, Y número de elementos de prioridad media y Z de baja prioridad.

Por supuesto, eso también significa que el equipo de desarrollo y la gerencia tendrán que garantizar que una cierta cantidad de estos se solucionará: todos los elementos de alta prioridad, la mayoría de los elementos de prioridad media y (tal vez) algunos de los elementos de baja prioridad dentro de un determinado período de tiempo.

Pero si esto va a funcionar, la gerencia tendrá que aceptarlo, de lo contrario, todo el ejercicio es una pérdida de tiempo.

Al final del día, sin embargo, su situación particular parece ser un síntoma del problema de que su administración no está asignando suficientes recursos para lidiar con problemas de soporte. Si los problemas se trataran de manera oportuna, entonces no creo que esto esté sucediendo.

Algo así se implementó en la primera empresa para la que trabajé, ya que el proceso de soporte fue disfuncional y condujo a una situación en la que si todo es una emergencia, nada lo es. En nuestro caso, después de controlar la situación interna, el nuevo gerente de desarrollo de software puso un límite a la cantidad de problemas de alta prioridad que un cliente podría presentar dependiendo de cuánto pagaran en contratos de soporte. Si sobrepasaron el límite, recaudaron más efectivo o el problema de soporte se redujo en prioridad.

Esto sucede con mucha frecuencia en grandes corporaciones donde la TI se considera auxiliar y / o se subcontrata. Los empresarios no entienden el software y no les importa, lo único que les importa es que "su" error se haya solucionado ayer, independientemente de lo poco crítico que sea. No se dan cuenta, o les importa, que hay otros cien usuarios que también están presentando errores, y un equipo de quizás 5 desarrolladores disponibles para arreglar las cosas.

Esto se ve exacerbado por la mala gestión, especialmente los gerentes que no son de TI que no pueden decir "no" o que simplemente dejan que la gente de negocios establezca la prioridad de los errores. (En cualquier caso, dicho gerente no está haciendo su trabajo). La mayoría de los gerentes priorizarán el error sobre el que fueron contactados por última vez porque "es urgente"; El resultado neto es que los desarrolladores terminan saltando de un error a otro, por lo que solucionar un solo error lleva más tiempo (cambio de contexto), y al final del día, todos están descontentos. "Cuando cada error es un error de alta prioridad, ningún error es de alta prioridad".

He estado en esta situación y, en general, la única forma de escapar es salir. Las pautas de informe de errores siempre se ignoran porque los usuarios no dan como ** t. Intentar introducir una clasificación de errores será resistido o implementado y luego ignorado la próxima vez que un usuario llame a su gerente para quejarse de "su" error.

Básicamente, si los desarrolladores no tienen control de la prioridad , ya has perdido.

Como empresa, desea resolver los problemas con la mayor relación importancia / costo. Los usuarios deciden la importancia, la ingeniería decide el costo. Si los usuarios asignan la misma importancia a todos los errores, el costo solo es importante.

En términos prácticos, esto significa que define la prioridad como importancia / costo, y no permite que los usuarios o desarrolladores establezcan esa prioridad directamente. Ninguno de los lados tiene la imagen completa.

Si los usuarios deciden calificar todos los problemas de igual importancia, está bien, pero significa que la ingeniería (costo) decide lo que se hace. Explíqueles que la importancia es la única forma en que pueden influir (pero no decidir) la prioridad.

Algunos factores ...

• A menudo, la persona que informa el error no conoce el panorama general y no puede decidir qué tan importante es el error.
• A menudo, los errores de baja prioridad nunca se clasifican o consideran, por lo tanto, es mejor dar una prioridad que sea demasiado alta y dejar que la persona que realiza el triaje la reduzca.
• Como desarrollador, a menudo he mirado el informe de errores y descubrí que hay un problema de alta prioridad detrás del error, pero al gerente de producto que realiza la clasificación no le importa el error.

Por lo tanto, creo que uno o dos desarrolladores experimentados deben analizar RÁPIDAMENTE todos los informes de errores, agregando sus pensamientos al informe de errores, luego el error debe ser solucionado. Esperar que la persona que encuentra el error pueda establecer una prioridad útil en el momento en que lo encuentra, es pedir demasiado.

Es muy posible que todos los errores mencionados sean de alta prioridad. He estado en proyectos que no cuentan con fondos suficientes o con una especificación insuficiente, y cuando comenzaron las pruebas de control de calidad y los usuarios simplemente dejaron de informar sobre elementos de baja prioridad, porque sabían que los errores de ortografía o fallas en la usabilidad eran una pérdida de tiempo si la funcionalidad principal del proyecto estaba completamente manguera. Si su sistema de equipaje automatizado está chocando los carros y destruyendo el equipaje , ¿a quién le importa si la fuente en las etiquetas es 2pt demasiado pequeña?

En una situación como esta, el proyecto está fallando. Si sospecha que esto es incluso una posibilidad, necesita una comunicación sincera con las personas que informan los defectos para descubrirlo. Si las personas están inflando informes de errores, las otras respuestas ayudarán. Si los errores son tan malos como se informa, entonces debe tomar medidas extremas .

La mayoría ya se ha dicho, pero destilaría la lista del "zoológico de insectos" a algo un poco menos granular:

R: El error detiene al usuario en seco en sus pistas, da un resultado incorrecto, generalmente hace que el sistema / característica / función sea inutilizable. Ese es un error de "alta prioridad".

B: todo lo demás. Estos son errores "negociables".

Los errores negociables se enmarcan en una variedad de inquietudes (que pondría en su propio orden particular):

1: Errores que afectan la seguridad;

2: Errores que afectan la usabilidad (idoneidad para el propósito previsto);

3: Errores que impactan la estética;

4: Errores que afectan el rendimiento (¿quizás un subconjunto de usabilidad?);

5: Errores que ofenden su sensibilidad como programador profesional;

6: Errores que disminuyen la CONFIANZA DEL USUARIO;

Así que ese es el mundo utópico en el que ninguno de nosotros vive realmente. Suspiro Para completar mi respuesta a la pregunta formulada por el OP, en toda la industria del software, es completamente común que los esfuerzos de desarrollo estén en un estado en el que cada error sea una prioridad. one-super-banger-special. Y sabes lo que dicen sobre "especial": cuando todos son especiales, nadie es especial.

Básicamente, este problema se basa en el problema de descentralizar la priorización. Siempre debe haber un número impar de personas con la capacidad de priorizar la carga de trabajo de un equipo, y 3 es demasiado. Para que 1 persona sea responsable de la eficacia del triaje. Y debe ser un gerente / analista, en consulta con un líder / arquitecto de desarrollo. Y el proceso es bastante simple, y también se puede aplicar a solicitudes de características. ¿Cuál es el costo de hacer el desarrollo? ¿Cuál es el valor del resultado esperado para el negocio? La salida de esa función es la prioridad asignada.

Por supuesto, cada usuario quiere que su problema se solucione primero. Y tan pronto como lo permitas, el caos. No tienes una priorización válida. Necesita que esto lo haga una SOLA persona con autoridad (que consulte con otros cuando sea necesario), que tenga VISIBILIDAD en TODOS los problemas y necesidades comerciales, y que sea lo suficientemente competente como para reunir el asesoramiento de negocios y expertos de TI necesarios y, por lo tanto, generar estimaciones razonablemente precisas de las métricas. encima.

A riesgo de afirmar lo obvio, voy a suponer que no hay un software de seguimiento de errores que establezca los errores con alta prioridad de forma predeterminada (o que se haya configurado en esta configuración).

Me temo que, en ausencia de controles, este es el escenario predeterminado para que varios equipos, clientes, etc. informen. Si se abusa del status quo, entonces algún tipo de proceso de clasificación definitivamente está en orden.

Una victoria rápida que he visto funcionar muy bien en el pasado es que P1 (errores de alta prioridad) generan una gran cantidad de alertas de administración. Si el sistema ha sido maltratado, se derriba inmediatamente. O si es realmente urgente, una llamada en conferencia o una reunión física suceden para abordar el problema lo antes posible.

Asumo aquí que estás hablando de todos los errores, no solo de los del desarrollo inicial. Si normalmente eres un arma de desarrollo de campo verde para contratar, entonces ciertamente no es inusual que la mayoría de los errores sean de alta prioridad después de la versión alfa inicial.

No puede simplemente tener una prioridad y esperar que todo funcione mágicamente. A veces las personas se dan cuenta por su cuenta, pero no siempre.

Para asignar prioridades correctamente, debe haber una definición de lo que constituye exactamente cada prioridad. Estos criterios deben ser objetivos, para evitar el favoritismo de errores y la priorización política. Si no se siguen los criterios objetivos, debe hacer que el equipo lo siga.

Realmente no hay forma de evitar esto: si no puede tener criterios objetivos de qué error va a dónde, y si la gente se niega voluntariamente a cumplir con estos criterios, entonces es posible que no tenga prioridades asignadas por el remitente, ya sea prescindiendo de prioridades o un tercero asigna prioridad como otros sugirieron. Los datos de crowdsourcing solo funcionan si los remitentes son cooperativos y no sabotean activamente la recopilación de datos.

Si surge la dificultad de no poder crear criterios objetivos, puede usar criterios relativos:

• Tener una cola simple de todos los errores. Los usuarios pueden insertar errores en cualquier parte de la cola. Solo deben insertar en una posición determinada si consideran que su error es más importante que todo lo que está debajo. Los solucionadores de errores comienzan desde la parte superior de la cola.
• Suponiendo que ya tiene un conjunto de errores bien clasificados, dígales a todos que la condición para priorizar un error Xes que debe ser más importante que todos los errores prioritarios X-1.
• Informe a los remitentes que en ningún momento la cantidad de errores con prioridad puede Xexceder la cantidad de errores con prioridad X-1.

Pero parece que su problema no es la definición, sino la creencia entre los remitentes de que los errores de baja prioridad no se solucionan. Presumiblemente, no puedes persuadirlos de otra manera, ya que (por lo que dices) su creencia se basa de hecho. Entonces, ¿por qué les haces enviar estos errores? Termina siendo nada más que trabajo ocupado. Podría, por ejemplo, después de que se haya alcanzado un cierto número de errores activos, decirles a todos que no se molesten en hacer informes a menos que sientan que encontraron algo más importante que la mayoría de los errores pendientes. Por supuesto, esta es solo la solución de la cola con un límite superior en la longitud de la cola.