¿Cómo se gestiona una gran cartera de productos?[cerrado]

Question

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

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

Gestionar todo esto de manera sensata es un trabajo que recae en la Gestión de Producto, pero es complicado por muchas razones.En primer lugar, tenemos varios sistemas diferentes que contienen las diferentes cosas (documento de requisitos del mercado en archivos, errores en una base de datos de errores, requisitos del cliente en nuestro sistema de soporte técnico, lista de deseos de ingeniería en nuestra intranet, etc.).Y en segundo lugar, muchos de los elementos son de tamaño, alcance, complejidad y, por supuesto, valor tremendamente diferentes, lo que significa que elegir no es tan simple como simplemente ordenar una lista por prioridad.

Debido a que 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 pendientes de base) simplemente no son suficientes para lidiar con esto.Necesitamos una manera de agrupar las cosas de varias maneras, priorizarlas de manera continua, dejar claro lo que estamos haciendo y lo que está por venir, sin que esto requiera todo el tiempo de alguien para simplemente administrar alguna herramienta.

¿Cómo se gestiona esto de manera que permita a la empresa hacer siempre lo que es más valioso para los clientes existentes, ayudar a conseguir otros nuevos y mantener el software en su sano juicio?

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

¿Has encontrado un método o una herramienta que funcione?Si es así, ¡compártelo!(Y si también quieres saber la respuesta, califica la pregunta para que permanezca visible :)

Apéndice: Por supuesto, es bueno corregir 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, es posible que tengamos un error que ocurre muy raramente y que requeriría una gran cantidad de tiempo y cambios arquitectónicos para solucionarlo; podríamos dejarlo por un tiempo.O podríamos tener un error en el que alguien piensa que algo es difícil de usar y pensamos que para solucionarlo deberíamos esperar a una renovación más grande de esa área.Entonces, hay muchas razones por las que no los solucionamos todos de inmediato, sino que los mantenemos abiertos para que no nos olvidemos.Además, lo más difícil es priorizar los que no son errores;Imagínense que no tenemos ninguno :)

Answer 1

Gestionar un gran trabajo pendiente de forma agresiva casi siempre es un desperdicio.Cuando llegas al centro de una pila de prioridades, la mayoría de las veces las cosas han cambiado.Recomendaría adoptar algo como lo que Corey Ladas llama filtro de prioridad:

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

Básicamente, tiene algunos depósitos 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 espacios vacíos 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 para que esto funcione es dimensionar correctamente las tareas.Solo aplicamos esta priorización a historias de usuarios.Las historias de usuario suelen ser significativamente más pequeñas que "crear un sitio comunitario".Consideraría que el sitio de la comunidad es un poco épico o incluso un proyecto.Sería necesario dividirlo en partes significativamente más pequeñas para poder priorizarlo.

Dicho esto, todavía puede resultar complicado crear historias de tamaño similar.A veces simplemente no puedes, así que lo comunicas durante tus decisiones de planificación.

Con respecto a mover wibbles dos píxeles, muchas de estas cosas que son fáciles se pueden hacer de forma "gratuita".Sólo tienes que tener cuidado de equilibrarlos y hacerlos solo si están muy cerca de ser gratuitos y en realidad son algo importantes.

Tratamos los errores de manera similar.Los errores obtienen una de tres categorías: Ahora, Pronto o Eventualmente.Arreglamos los errores de Ahora y Pronto lo más rápido que podemos, con la única diferencia de cuando publicamos las correcciones.Al final, los errores no se solucionan a menos que los desarrolladores se aburran y no tengan nada que hacer o de alguna manera se conviertan en una mayor prioridad.

Answer 2

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

Solucione los problemas que mantienen alejados a los clientes rápidamente y agregue más funciones para que los clientes sigan viniendo.Rechace los problemas que sólo afectan a un pequeño número de personas, a menos que sean muy fáciles de solucionar.

Answer 3

Una técnica sencilla consiste en utilizar una matriz de priorización.

Ejemplos:

• http://erc.msh.org/quality/pstools/psprior2.cfm

• http://it.toolbox.com/blogs/enterprise-solutions/sample-project-prioritization-matrix-23381

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

Answer 4

Creo que hay que reunirlos todos en un solo lugar para poder priorizarlos.Tener que cotejar varias fuentes diferentes hace que esto sea prácticamente imposible.Una vez que tenga eso, alguien/un grupo debe clasificar cada error, característica 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

Answer 5

Primero debes corregir todos los errores y solo después pensar en agregarle nuevas funciones.

Answer 6

Todo esto podría rastrearse mediante un buen sistema de seguimiento de errores que tenga las siguientes características:

• Capacidad para marcar elementos de trabajo como errores o solicitudes de mejora
• Campo de categoría para la región de responsabilidad a la que pertenece el elemento de trabajo (UI, back-end, etc.)
• Campo # de versión para cuando está programada la realización de la corrección o característica
• Campo de estado (en progreso, completado, verificado, etc.)
• Campo de prioridad

Answer 7

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

• poner todo tus historias en una gran pila de fichas (o alguna herramienta similar)
• ahora los desarrolladores deben estimar qué tan grandes o pequeñas son esas historias (aquí los desarrolladores tienen la última palabra)
• y permita que el cliente (o su representante, como el gerente de producto) ordene esas historias según 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 comunicárselo al cliente (persona de negocios) y hacer que el cliente aumente esa prioridad (el cliente aún tiene la última palabra).
• seleccione tantas historias para la próxima iteración como lo permita la velocidad de su equipo

Por aquí:

• Hay una única cola de tareas, ordenada según las necesidades del negocio.
• los clientes obtienen el mejor retorno de su inversión
• El valor empresarial impulsa el desarrollo, no la tecnología ni los geeks.
• los desarrolladores pueden decir lo difícil que es implementar las cosas
• si no hay retorno de la inversión, la tarea permanece cerca del final de esa pila

Para más información, ver Planificación de programación extrema por Kent Bech y Martín Fowler.Lo dicen mucho mejor que yo.

Answer 8

No estoy seguro de si la herramienta es tan crítica como el proceso.He visto equipos tener mucho éxito utilizando algo tan simple como fichas y pizarras blancas para gestionar proyectos bastante grandes.Una cosa que recomendaría al priorizar es asegurarse de tener una lista completa de estos elementos.De esta manera puedes sopesar la prioridad de solucionar un problema vs.una nueva característica, etc.

Answer 9

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

En nuestra tienda se le llama Administrador de versiones y determina el siguiente perímetro funcional que se enviará a producción.
Entonces hay un Administrador de congelación quién realmente sabe sobre códigos, archivos y errores (generalmente es uno de los programadores), y hará cumplir las opciones del administrador de versiones y monitoreará las fusiones necesarias para tener algo que probar y luego publicar.

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