project management - manager - ¿Cómo se maneja un gran backlog de producto?

scrum master (9)

Tenemos una gran acumulación de cosas que debemos hacer en nuestro software, en muchas categorías diferentes, por ejemplo:

Nuevas áreas problemáticas para nuestros productos para resolver
Nueva funcionalidad que respalda las áreas problemáticas existentes
Nueva funcionalidad solicitada por nuestros usuarios existentes
Mejoras de usabilidad y "look"
Actualizaciones arquitectónicas al back-end
Corrección de errores

Administrar todos estos de una manera sensata es un trabajo que recae en la Gestión de productos, pero es complicado por muchas razones. En primer lugar, tenemos varios sistemas diferentes que contienen las diferentes cosas (documentos de requisitos del mercado en archivos, errores en una base de datos de errores, requisitos del cliente en nuestro sistema de mesa de ayuda, lista de deseos de ingeniería en nuestra intranet, etc.). Y, en segundo lugar, muchos de los artículos son de un tamaño, alcance, complejidad y, por supuesto, muy distintos, lo que significa que elegir no es tan simple como ordenar una lista por prioridad.

Como ahora somos bastante grandes, tenemos un producto complejo y muchos clientes, las soluciones básicas (una hoja de cálculo, un documento de Google, una lista de tareas para el campamento base) simplemente no son suficientes para lidiar con esto. Necesitamos una forma de agrupar las cosas de varias maneras, priorizarlas de forma continua, dejar en claro lo que estamos haciendo y lo que está por venir, sin que esto requiera todo el tiempo de alguien solo para administrar alguna herramienta.

¿Cómo se maneja esto de una manera que permite a la empresa hacer siempre lo que es más valioso para los clientes existentes, ayuda a obtener otros nuevos y mantiene la integridad del software en su sano juicio?

Tenga en cuenta que esto es diferente del lado del desarrollo, que creo que hemos bajado bastante bien. Desarrollamos todo de manera ágil e iterativa, y una vez que se ha elegido algo para el diseño y la implementación, podemos hacerlo. ¡Es la parte en la que necesitamos saber qué hacer más difícil!

¿Has encontrado un método o una herramienta que funcione? Si es así, por favor comparte! (Y si también quieres saber la respuesta, puntúa la pregunta para que quede visible :)

Adición: Por supuesto, es bueno solucionar todos los errores primero, pero en un sistema real que realmente está instalado en las máquinas de los clientes, eso no siempre es práctico. Por ejemplo, podemos tener un error que ocurre muy raramente y que tomaría una gran cantidad de tiempo y un trastorno arquitectónico para solucionarlo, podríamos dejarlo por un tiempo. O podríamos tener un error donde alguien piensa que algo es difícil de usar, y creemos que solucionarlo debería esperar a una mayor renovación de esa área. Entonces, hay muchas razones por las que no solo las solucionamos de inmediato, sino que las mantenemos abiertas para que no las olvidemos. Además, es la priorización de los no bichos la más difícil; solo imagina que no tenemos ninguno :)

Como ya estás haciendo las cosas de manera ágil, puedes tomar prestadas algunas ideas de XP:

ponga todas sus historias en una gran pila de fichas (o alguna herramienta similar)
ahora los desarrolladores deben calcular cuán grandes o pequeñas son esas historias (aquí los desarrolladores tienen la última palabra)
y permita que el cliente (o su representante, como gerente de producto similar) ordene esas historias por su valor comercial (aquí el cliente tiene la última palabra)
y si los desarrolladores piensan que hay algo técnico que es más importante (como corregir esos molestos errores), deben comunicarlo al cliente (persona de negocios) y hacer que el cliente ascienda esa prioridad (el cliente aún tiene la última palabra)
selecciona tantas historias para la siguiente iteración como la velocidad de tu equipo lo permita

De esta manera:

hay una única cola de tareas, ordenada por necesidades comerciales
los clientes obtienen el mejor rendimiento por su inversión
el valor empresarial impulsa el desarrollo, no la tecnología o los frikis
los desarrolladores pueden decir qué tan difíciles son las cosas para implementar
si no hay ROI , la tarea se queda cerca de la parte inferior de esa pila

Para obtener más información, vea Planning Extreme Programming por Kent Bech y Martin Fowler . Lo dicen mucho mejor de lo que puedo hacer.

Creo que tienes que ubicarlos a todos en un solo lugar para que se pueda priorizar. Tener que reunir varias fuentes diferentes hace que esto sea prácticamente imposible. Una vez que tienes eso, entonces alguien / un grupo tiene que clasificar cada error, función solicitada y desarrollo deseado.

Las cosas por las que podrías priorizar son:

Valor agregado al producto
Importancia para los clientes, tanto existentes como potenciales
Escala de la tarea

La clave es la categorización y la priorización agresivas.

Solucione los problemas que mantienen a los clientes alejados rápidamente y agregue más características para mantener a los clientes a la vanguardia. Rechace los problemas que solo afectan a un pequeño número de personas, a menos que sean muy fáciles de solucionar.

Más allá de cualquier herramienta y proceso, debería haber ... algunas personas;)

En nuestra tienda, se lo llama Administrador de versiones y determina el siguiente perímetro funcional para enviar a producción.
Luego hay un Freeze Manager que realmente conoce el código, los archivos y los errores (generalmente es uno de los programadores), aplicará las opciones del administrador de versiones y supervisará las fusiones necesarias para tener algo que probar y luego lanzar. .

Entre ellos dos, se puede establecer una priorización, tanto a nivel alto (solicitudes funcionales) como de bajo nivel (errores y problemas técnicos)

No estoy seguro de si la herramienta es tan crítica como el proceso. He visto que los equipos tienen mucho éxito usando algo tan simple como fichas y pizarras blancas para administrar proyectos bastante grandes. Una cosa que recomendaría en la priorización es asegurarse de tener una lista completa de estos elementos juntos. De esta forma, puede sopesar la prioridad de solucionar un problema frente a una nueva característica, etc.

Primero debe arreglar todos los errores y luego solo pensar en agregarle nuevas funciones.

Todo esto podría ser rastreado por un buen sistema de seguimiento de errores que tiene las siguientes características:

Posibilidad de marcar elementos de trabajo como errores o solicitudes de mejoras
Campo de categoría para la región de responsabilidad que corresponde al elemento de trabajo (UI, back-end, etc.)
Versión # campo para cuando el arreglo o la función está programada para ser hecha
Campo de estado (en progreso, completado, verificado, etc.)
Campo de prioridad

Una técnica simple es usar una matriz de priorización.

Ejemplos:

También son útiles los cuadrantes de priorización (dos dimensiones: Importancia, Urgencia) que Covey propone: http://www.dkeener.com/keenstuff/priority.html . Centrarse en lo importante y urgente, luego lo importante y no urgente. Las cosas no importantes ... bueno ... si alguien quiere hacer eso en sus horas libres :-). Una variante de los cuadrantes Covey que he usado es con las dimensiones de Importancia y Facilidad. La facilidad es una buena forma de priorizar las tareas dentro de un cuadrante Covey.

Administrar una gran cantidad de pedidos de manera agresiva casi siempre es un desperdicio. En el momento en que llegas al centro de una pila priorizada, las cosas cambian más de las veces. Recomiendo adoptar algo como lo que Corey Ladas llama un filtro de prioridad:

http://leansoftwareengineering.com/2008/08/19/priority-filter/

Esencialmente, tiene algunos cubos de tamaño creciente y prioridad decreciente. Permite que las partes interesadas los llenen, pero los obliga a ignorar el resto de las historias hasta que haya vacantes en los cubos. Muy simple pero muy efectivo.

Editar: Allan preguntó qué hacer si las tareas son de diferentes tamaños. Básicamente, una gran parte de hacer que este trabajo sea correcto es dimensionar sus tareas. Solo aplicamos esta priorización a las historias de los usuarios. Las historias de los usuarios suelen ser significativamente más pequeñas que "crear un sitio de la comunidad". Consideraría que el sitio de la comunidad mordió una épica o incluso un proyecto. Tendría que dividirse en bits significativamente más pequeños para ser priorizados.

Dicho esto, todavía puede ser un desafío hacer historias de un tamaño similar. A veces simplemente no puede, por lo que se comunican durante sus decisiones de planificación.

En lo que respecta al movimiento, se mueven dos píxeles, muchas de estas cosas que son fáciles se pueden hacer por "gratis". Solo tienes que tener cuidado de equilibrar estos y solo hacerlos si están realmente cerca de ser libres y en realidad son algo importantes.

Tratamos errores de manera similar. Los errores obtienen una de tres categorías, ahora, pronto o eventualmente. Solucionamos los errores de Ahora y Pronto lo más rápido posible, con la única diferencia cuando publicamos las correcciones. Eventualmente los errores no se arreglan a menos que los desarrolladores se aburran y no tengan nada que hacer o de alguna manera se vuelvan de mayor prioridad.