¿Cuáles son algunas técnicas para calcular la prioridad de errores o solicitudes de características para un producto de software?

Primero, responda algunas preguntas sobre cualquier error:

¿Qué tan malo es para cada usuario afectado (gravedad)? Probablemente podría llegar a 10 niveles de gravedad diferentes con un 10 que significa que está exponiendo la tarjeta de crédito o SSN del usuario públicamente, un 5 que significa que un usuario tiene que usar una solución alternativa para completar una tarea, y un 1 que significa que usó un Semi-color incorrectamente.
¿A cuántos usuarios afecta (frecuencia)? Intente medir el número absoluto de clientes a los que afectará este error diariamente / semanalmente, y luego mostrarlo como un% de todos los usuarios.

Su priorización inicial puede ser simplemente una función de estas dos respuestas. Cuando llegue el momento de asignar recursos para solucionarlos, tendrá que tener en cuenta otros factores:

Costo de arreglar. En igualdad de condiciones, un error que es fácil de solucionar se debe solucionar antes que un error que requiere más trabajo para solucionarlo.
Riesgo. Cada vez que un ingeniero toca una función, existe el riesgo de que presente otros problemas. Tenga en cuenta este riesgo cuando le pide a un ingeniero que realice docenas de pequeñas correcciones de errores justo antes de un lanzamiento público, una demostración clave o un período de uso pico.
Área de funciones. Si tiene ingenieros que ya están trabajando en un área determinada (p. Ej., Archivo, servicio), es eficiente que solucionen otros errores en esa área al mismo tiempo. El costo marginal para hacer y probar cada una de esas correcciones de errores adicionales es bajo.
Característica / Prioridad del producto. Un error en una versión anterior de un producto o uno que pronto será desaprobado debe tener una prioridad inferior (o no solucionarse en absoluto) frente a un error en la versión más reciente de un producto.

Errores deGestión de productosingeniería de softwaresoftware

¿Por qué la mayoría de los trabajos de ingeniería remota de software usan lenguajes de programación diferentes a los trabajos de oficina estándar?

¿Por qué deberíamos escribir un plan de prueba para pruebas de software?

¿Cuáles son las mejores referencias en línea / libros para algoritmos relacionados con DICOM?

Cómo configurar un entorno Golang para un corredor compartido de GitLab CI

¿Es más difícil obtener y entrevistar para una pasantía en Twitter que en Google?

¿Cuál es la mejor API de chat de marca blanca?

CUESTIONES PRIORITARIAS

Personalmente, no soy fanático de las prioridades “altas”, “medias” o “bajas”. Para mí, las prioridades son relativas .

Priorizamos por orden cronológico en nuestra cartera de pedidos. Cuando arrastro una tarea a la parte superior, significa que tiene la máxima prioridad. La tarea en la parte inferior tiene menos prioridad.

¿Por qué es eso mejor que la asignación manual de prioridades “altas”, “medias” y “bajas”?

Naturalmente degradas las tareas . Digamos que tiene dos tareas marcadas como importantes en su cartera de pedidos. Ahora agregas un tercero importante. Estás terminando con 3 tareas importantes, que literalmente no te proporcionan información. Su equipo de desarrollo no puede implementarlos más rápido que si fueran de baja prioridad. Si prioriza por orden, naturalmente admite que si decide poner la nueva tarea en primer lugar, las otras deben ser menos importantes.

No tiene que escribir pautas complejas sobre cómo priorizar los problemas con “alto”, “medio” o “bajo”. Simplemente se concentra en su objetivo principal y, al agregar problemas, los compara con los existentes y decide dónde colocarlos en el orden.
Ahorras mucho tiempo. Este es solo un beneficio secundario, pero reordenar las tareas se realiza mucho más rápido que asignarles una prioridad diferente en la mayoría de los rastreadores de problemas.

Tenga en cuenta que hay rastreadores de problemas que no le permiten ordenar sus tareas. Sin embargo, todos los Kanban / Agile / SCRUM te permiten hacer eso. Algunos ejemplos son: JIRA, Pivotal Tracker, Trello, DoneDone, sprint.ly y muchos más.

Hay otra técnica de priorización utilizada en el desarrollo ágil que también utilizamos combinada con la priorización por orden: MoSCoW. Esencialmente establece expectativas sobre lo que puede esperar que se entregue dentro de un sprint. Puede leer más sobre esto aquí: Priorice los problemas como un profesional – Desarrollando productos web

ERRORES PRIORIZANTES

Como los errores están fuera de ciclo, creo que tiene sentido tener un conjunto de reglas para calcular su prioridad. Aquí está el mío:

Bloqueador : los usuarios no pueden lograr su objetivo principal, y no hay una solución (obvia) para ellos (por ejemplo, no poder encontrar amigos en Facebook).
Crítico : los usuarios solo pueden lograr su objetivo principal mediante el uso de algún tipo de solución alternativa (por ejemplo, no poder encontrar un amigo de Facebook en la lista de amigos, pero poder buscarlos).
Mayor : una cantidad significativa de usuarios se sienten incómodos al lograr su objetivo principal (por ejemplo, la búsqueda de amigos en Facebook es de repente terriblemente lenta, pero funciona).
Menor : los usuarios no pueden lograr objetivos secundarios (por ejemplo, el botón de empuje desaparece en el perfil de Facebook).
Trivial : cosas cosméticas (por ejemplo, el botón de empuje en Facebook usa la fuente incorrecta).