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

  

Le pregunté a algunos colegas sobre lo que esto puede estar pasando, y   mencionó que si un error no tiene ese nivel de prioridad es   muy raro que el error llame la atención del desarrollador, lo que de hecho hace   sentido

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

Y dado que todavía tienes la misma cantidad de errores que enfrentar, y la misma cantidad de horas de trabajo para hacerlo, se sigue que se usará alguna otra heurística, posiblemente la nula: "primero llegado, primer 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 asignaron suficientes recursos a la corrección de errores (hay algunas políticas como " No hay nuevas funciones hasta los errores están solucionados "que pueden ayudar allí. Joel aprueba ; comprender los límites y las consecuencias es un < a href="https://softwareengineering.stackexchange.com/questions/198696/keeping-agile-with-zero-bug-defect-policy"> decisión empresarial ).

En un proyecto en el que trabajé, los errores entrantes se acumularon en un "búfer sin prioridad" y todos los lunes revisaríamos la lista de errores, estimaríamos la dificultad (una estimación muy aproximada; la mayoría de las veces solo agregamos "Promedio ") y ordenarlos por tiempo disponible. Esto tendió a eliminar la lista de bugs aburridos, poco interesantes o pensados para ser duros; para compensar eso, los supervisores y el marketing tenían una cierta cantidad de créditos por semana que podían gastar para eliminar la prioridad de los errores favoritos, y se les reembolsaron los errores no resueltos (esto establece un límite en cuanto a la cantidad de errores que un desarrollador puede demorar). .

También fue posible fusionar, cancelar y dividir errores; Recuerdo un módulo que fue tan imperfectamente imperfecto que hundimos unos veinte o treinta informes de errores en una sola "reescritura de esto desde cero", que luego se dividió en "establecer claramente las entradas y salidas de lo miserable", "escribir pruebas para asegurar que las entradas y salidas coincidan con las especificaciones ", y así sucesivamente. El último elemento fue "imprimir el código antiguo en papel reciclado, sacarlo en el césped y prenderlo al fuego" (También hicimos eso. Recuerdo lo bien que se sintió. Nos turnamos en el elogio; fue bastante hilarante. ).

Después de un poco de regateo, tuvimos la lista de tareas pendientes de la semana, que se dividió en "haré", "podría hacer" y "no puedo" que fueron eliminadas hasta la próxima semana. Aquí es donde entró en juego el regateo adicional: tuvimos que decir cincuenta horas para asignar errores, y estábamos 95% seguros de solucionar los primeros veinte. La gerencia quería que se solucionara un error número veintiuno y no le quedaban créditos; luego, ofreceríamos cambiar ese error por uno en la lista "Lo haré", o alguien diría "Sácame del subequipo 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, realmente, pero se creía que esto (al menos entre los desarrolladores) era una buena señal.

Algunos patrones negativos adicionales que aparecieron fueron el "Deseo de Pensar" por parte de los gerentes ("Usted declaró que el error 57212 requiere ocho horas. Eso es inaceptable. Es cuatro") y el "Depuración por Fiat" ("Hacer lo que quieras, pero estos cuarenta errores deben solucionarse antes de la gran demostración de la próxima semana. No puedes tener más tiempo, no puedes tener más personas "). También el Síndrome de Boxer ("Trabajaré más duro"), que funcionó muy bien por un corto tiempo , pero generalmente llevó a un desarrollador a volverse loco o irse a pastos más verdes.

Si tiene este problema donde los usuarios asignan errores de prioridad cada vez mayores, 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 pasar por cada error recién informado y restablecer su prioridad a un nivel razonable.

Después de un tiempo, los 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, tendrán que ponerse en contacto con alguien para que lo golpee, lo que requerirá cierta justificación. Este solo hecho 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 deba embarcarse en un resumen de corrección de errores para eliminar el retraso. Esto les mostrará a los usuarios que sus errores se solucionarán sin necesidad de que sean marcados como super-super-super-dooper -realmente-no-honestos-esta-vez-importantes.

RENUNCIA DE RESPONSABILIDAD: Aún no tengo experiencia con los chanchullos de prioridad de errores informados por los usuarios. Sé que la pregunta hace 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 errores. Si cada usuario puede asignar directamente una prioridad a su error, informarán casi automáticamente su problema como de alta prioridad.

Usted podría hacer que la prioridad de error la tenga que configurar un administrador o un drone de helpdesk, pero esto podría llevar a favoritismo e ingeniería social, donde un cliente obtiene una prioridad artificialmente mayor debido a su estado o porque saben cómo elaborar. Sus mensajes para hacerlos parecer más importantes. También es mucho más laborioso.

Hay un punto 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. Esencialmente, 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 un resultado incorrecto cuando hago algo.
5. El programa tarda demasiado en hacer algo.
6. El programa tiene un defecto gráfico que no afecta la funcionalidad.
7. El programa tiene un defecto que no encaja en ninguna de las categorías anteriores.

Para dar ejemplos:

1. Mi iPhone se bloquea cuando recibo un mensaje que contiene símbolos hebreos.
2. La pantalla de bloqueo de mi Android se gira de tal manera que la mitad de ella se sale de la pantalla.
3. Algunas veces, mi teléfono con Android no acepta mi código de pantalla de bloqueo, 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. Su aplicación tiene un error de ortografía.
7. Encontré un defecto de seguridad en su programa y me gustaría reportarlo.

Como puede ver, cada uno de estos errores tiene un grado de severidad diferente, y las categorías están ordenadas aproximadamente en función de esta severidad. Luego, puede asignar a cada error una prioridad 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 les obliga básicamente a mentir sobre el error.

Los usuarios aún podrían ingresar sus errores en la categoría incorrecta, por supuesto. Lo primero que debes 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 entenderán y dejarán de reportar errores. Algunos usuarios pueden continuar proporcionando información incorrecta. Cuando eso suceda, envíe a esos usuarios un suave recordatorio por correo de que la información precisa es importante y no abusar del sistema. Si continúan falsificando registros, les da una advertencia de que están abusando deliberadamente del sistema y el abuso continuo dará lugar a que sus errores se asignen automáticamente a una categoría inferior. Si persisten, puedes ajustar su multiplicador de errores.

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

Como ha dicho la gente, esta es la razón por la que las personas que informan 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 administración superior). Entonces, alguien más arriba dice "trabaja en esta aplicación, corrige esta , hazlo mejor haciendo esto ", y el equipo llega a Decida cómo hacerlo, porque son los que cuentan con la experiencia técnica necesaria para evaluar la mejor manera de lograr lo que la administración quiere.

Las personas que informan de los errores deberían asignar niveles de impacto o gravedad , que tienen un alcance definido. Puede llamar a la gente fácilmente para que no se adhieran a los niveles de severidad acordados, porque tiene evidencia material para esos niveles. Por ejemplo:

1. Pérdida completa de funcionalidad
2. Pérdida parcial de funcionalidad
3. Reducción generalizada de la eficacia
4. Reducción localizada en efectividad
5. Molestia u obstáculo (existe una solución)
6. cosmética
7. En realidad, nadie se dio cuenta, se encontró durante una prueba exploratoria poco clara

Para comenzar, puedes usar estos niveles como un instrumento contundente para señalar que una desalineación de un texto de título no es un error de Nivel 1 porque no inutiliza 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 corregirlo haciendo clic derecho en el cuadro de texto varias veces, o un nivel 4 porque está desacelerando a todos en Contabilidad para que procesen menos formularios por hora.

Una vez que tenga información útil, mensurable sobre qué tan grave es el error para su organización , la asignación de prioridad se hace evidente. Cualquier cosa que actualmente 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: esta tarea 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 configura mi estado de error en prioridad alta.

Esto llevará a niveles de prioridad cada vez mayores. Veo que ya has ido más allá de la prioridad alta a la prioridad muy alta. Lo que vendrá a continuación son:

1. Super alta prioridad
2. ultra alta prioridad
3. Muy alta prioridad ultra alta.
4. Very Super Ultra Mega High Priority.

etc. etc.

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

Hay básicamente 2 formas de contrarrestar esto:

1. Quita el control al cliente con respecto a los niveles de prioridad.
2. Asocie un costo al cliente para niveles de prioridad elevados.

Uno puede agregar niveles de prioridad más altos y más altos al sistema, especialmente si es Jira. Dar a los nuevos altos niveles de prioridad cada vez más tontos, pero los nombres nefastos pueden aumentar el efecto de Hawthorne en la calidad de las opciones de prioridad hechas por todas las partes . Si la prioridad más alta tiene un nombre realmente extravagante, el efecto podría ser permanente. Eventualmente, cuando alguien elige una prioridad, tiene que sopesar las consecuencias sociales de elegir la prioridad "error de la muerte" en vez de obtener la atención debida. Por lo tanto, la prioridad más alta está reservada de facto para algo que le sucedió al CTO en su casa frente a sus invitados u otros incidentes de visibilidad equivalente.

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

Por supuesto, eso también significa que el equipo de desarrollo y la administración tendrán que garantizar que un cierto número de estos serán de hecho fijos: 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 administración tendrá que comprarlo, de lo contrario, todo el ejercicio es una pérdida de tiempo.

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

Algo como esto se implementó en la primera empresa en 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 es. En nuestro caso, después de controlar la situación interna, el nuevo gerente de desarrollo de software puso un límite estricto a la cantidad de problemas de alta prioridad que un cliente podría presentar, dependiendo de cuánto pagaron en contratos de soporte. Si superaron el límite, o bien tosieron más dinero o el problema de soporte se redujo en prioridad.

Esto sucede muy a menudo en grandes corporaciones donde se considera que la TI es auxiliar y / o se subcontrata. La gente de negocios no entiende el software y no les importa, todo lo que les importa es que "su" error se corrige ayer, independientemente de lo no crítico que sea. No se dan cuenta, o les importa, que hay otros cien usuarios que también presentan errores, y un equipo de tal vez 5 desarrolladores disponibles para arreglar las cosas.

Esto se ve agravado por una administración deficiente, especialmente los gerentes que no son de TI que no pueden decir "no" o que simplemente permiten que la gente de negocios establezca la prioridad de errores. (En cualquier caso, dicho gerente no está haciendo su trabajo). La mayoría de los gerentes priorizarán el error por el que fueron contactados por última vez porque "es urgente"; El resultado final es que los desarrolladores terminan saltando de error en error, por lo que corregir 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 una s ** t. Se intentará resistir el intento de introducir la clasificación de errores, o se implementará y luego se ignorará la próxima vez que un usuario llame a su administrador para quejarse de "su" error.

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

Como compañía, usted quiere resolver los problemas con la mayor proporción de costo / importancia. Los usuarios deciden importancia, la ingeniería decide el costo. Si los usuarios asignan la misma importancia a todos los errores, entonces el costo solo importa.

Hablando 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 temas de igual importancia, está bien, pero eso 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 del error no conoce el panorama general y no puede decidir la importancia del error.
• A menudo, los errores de prioridad baja nunca se evalúan ni se consideran, por lo tanto, es mejor dar una prioridad demasiado alta y dejar que la persona que realiza la clasificación disminuya.
• 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 todos los informes de errores deben ser revisados RÁPIDAMENTE por uno o dos desarrolladores con experiencia, agregando sus pensamientos al informe de errores, luego el error debe ser evaluado. Exigir que la persona que encuentra el error para poder establecer una prioridad útil en el momento en que lo encuentra, es solo pedir demasiado.

Es muy posible que todos los errores mencionados sean de alta prioridad. He estado en proyectos que no contaban con fondos suficientes ni con suficientes especificaciones, y cuando comenzaron las pruebas, el control de calidad y los usuarios simplemente dejaron de informar sobre los elementos de baja prioridad, porque sabían que los errores ortográficos o las fallas en la facilidad de uso eran una pérdida de tiempo si la funcionalidad principal del proyecto Fue completamente espigado. Si su sistema de equipaje automatizado está juntando carros y destruyendo 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 una posibilidad, necesita un corazón a corazón con las personas que informan los defectos para averiguarlo. Si la gente está inflando informes de errores, entonces las otras respuestas ayudarán. Si los errores son tan malos como se informó, entonces debe tomar medidas extremas .

La mayoría ya se ha dicho, pero me gustaría resumir la lista de "insectos zoológicos" en algo menos granular:

A: El error detiene al usuario muerto en sus pistas, da una salida incorrecta, generalmente hace que el sistema / característica / función sea inutilizable. Es un error de "alta prioridad".

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

Los errores NEGOCIABLES se encuentran bajo una variedad de inquietudes (que pondría en su propio orden particular):

1: Errores que afectan la seguridad;

2: Errores que afectan la usabilidad (aptitud 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 tu 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 realmente vivimos. suspiro Para completar mi respuesta a la pregunta planteada del OP, en toda la industria del software, es absolutamente común que los esfuerzos de desarrollo estén en un estado en el que cada error individual es una prioridad-uno-super-banger-especial. Y sabes lo que dicen sobre "especial": cuando todos son especiales, nadie es especial.

Básicamente, este problema está enraizado en el problema de descentralizar la priorización. Siempre debe haber un número impar de personas con capacidad para priorizar la carga de trabajo de un equipo, y 3 son demasiadas. Por lo que 1 persona es responsable de efectivamente -triage. Y debe ser un gerente / analista, en consulta con un desarrollador / arquitecto. Y el proceso es bastante simple, y puede aplicarse también a las 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 permitas eso, caos. No tienes una priorización válida. Debe hacer esto por una SOLA persona con autoridad (consultar con otros cuando sea necesario), que tenga VISIBILIDAD en TODOS los problemas y necesidades del negocio, y lo suficientemente competente como para reunir el asesoramiento de expertos de TI y negocios requeridos y, por lo tanto, generar estimaciones razonablemente precisas de las métricas arriba.

A riesgo de indicar lo obvio, voy a suponer que no hay ningún software de seguimiento de errores que establezca los errores como de alta prioridad como predeterminado (o se haya establecido en esta configuración).

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

Una rápida victoria que he visto que funciona muy bien en el pasado es que P1 (errores de máxima prioridad) genera una gran cantidad de alertas de administración. Si el sistema ha sido objeto de abusos, se cae inmediatamente. O si es realmente urgente, una llamada de conferencia o una reunión física sucede para abordar el problema lo antes posible.

Supongo que aquí estás hablando de todos 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 puedes tener una prioridad y esperar que todo funcione de manera mágica. A veces las personas lo descubren por su cuenta, pero no siempre.

Para asignar correctamente las prioridades, debe haber una definición de exactamente qué constituye 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 para el error, y si las personas se niegan a cumplir con estos criterios, es posible que no tenga prioridades asignadas por el remitente, ya sea sin prioridades , o haga que un tercero asigne prioridad como otros sugirieron. Los datos de colaboración múltiple 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 lugar de la cola. Solo deben insertarse 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 tienes un conjunto de errores bien clasificados, dile a todos que la condición para poner un error en la prioridad X es que debe ser más importante que todos los errores en la prioridad X-1 .
• Indique a los remitentes que en ningún momento el número de errores con prioridad X puede exceder el número de errores con prioridad X-1 .

Pero parece que su problema no es la definición, pero la creencia entre los remitentes de que los errores de baja prioridad no se solucionan. Es de suponer que no puede convencerlos de lo contrario, ya que (por lo que dice) su creencia se basa en el hecho. Entonces, ¿por qué les haces enviar estos errores? Termina siendo nada más que trabajo ocupado. Por ejemplo, después de que se haya alcanzado un cierto número de errores activos, podría decirle a todos que no se molesten en hacer informes a menos que sientan que encontraron algo más importante que los errores más destacados de la mayoría . Por supuesto, esta es solo la solución de cola con un límite superior en la longitud de la cola.