Asignación de prioridades

Por Mitch Lacey. Propietario de Mitch Lacey & Associates, Inc., una empresa de consultoría especializada en adopciones y mejoras de Agile y Scrum.

Enero de 2012

En este artículo, Mitch Lacey habla sobre tres métodos que han resultado ser muy beneficiosos para muchos equipos ágiles: el modelo de Kano de satisfacción del cliente, una serie de juegos de innovación de Luke Hohmann y el modelo de ponderación relativa de Karl Weiger. Cualquiera de ellos puede ayudarle a pasar de una valoración aproximada de las prioridades del trabajo pendiente a una ordenación precisa que pondere correctamente los riesgos, la importancia y la satisfacción del cliente.

Se aplica a

Application Lifecycle Management; Team Foundation Server

En este artículo:

• Introducción

• Modelo de Kano de satisfacción del cliente

• Juegos de innovación

  • Podar el árbol del producto

  • Comprar una característica

• Ponderación relativa – Karl Wiegers

• Conclusión

Para que su equipo de Agile funcione de forma eficaz es preciso que ordene los elementos de trabajo pendiente de un producto según su prioridad, y después reevaluar estas prioridades a medida que progresa el proyecto. A todos los trabajos pendientes de un producto se les debe asignar una prioridad según su valor empresarial y su riesgo. Este orden de prioridades permite al equipo centrarse en las características que tienen más probabilidades de contar para el éxito de su producto. Ordenar el trabajo pendiente de forma apropiada no solo redunda en la satisfacción del equipo y el cliente, sino que se acaba notando en el balance final de la empresa. Para obtener más información sobre trabajos pendientes, vea Crear y administrar el trabajo pendiente, Crear el trabajo pendiente y Repasar y estimar el trabajo pendiente.

Al ordenar y establecer prioridades del trabajo pendiente, debe tener en cuenta muchos factores y ser capaz de justificar sus decisiones. Cuando se aborda la lista de trabajos pendientes de un nuevo producto, el proceso puede parecer abrumador. Por fortuna, no es necesario ordenar perfectamente desde el principio todos los elementos de trabajo pendiente. En Estimación describo una técnica denominada "The Big Wall", que es una forma eficaz de estimar rápidamente el trabajo pendiente de un producto y colaborar con las partes interesadas para llegar a una clasificación de prioridades aproximada.

Esta clasificación aproximada es un buen punto de partida y podría bastar para sus circunstancias. En algunos casos, sin embargo, es necesario refinar estas prioridades u organizar el trabajo pendiente de una manera más científica. Existen muchas técnicas para hacerlo. En este artículo trato tres métodos que han resultado muy ventajosos para muchos equipos de Agile: el modelo de Kano de satisfacción del cliente, una serie de juegos de innovación de Luke Hohmann y el modelo de ponderación relativa de Karl Wiegers. Cualquiera de ellos puede ayudarle a pasar de una valoración aproximada de las prioridades del trabajo pendiente a una ordenación precisa que pondere correctamente los riesgos, la importancia y la satisfacción del cliente.

Modelo de Kano de satisfacción del cliente

El modelo de Kano de satisfacción del cliente fue desarrollado en la década de 1980 por el profesor Noriaki Kano, de la Universidad Rika de Tokio. El modelo proporciona un sencillo esquema de clasificación que distingue entre atributos básicos o esenciales y diferenciadores. El modelo se basa en cuestionarios y es una manera eficaz de visualizar las características del producto y estimular el debate en el equipo de diseño.

En el método Kano se realiza una serie de preguntas de dos formas distintas: funcional y disfuncional. Por ejemplo, digamos que preguntamos a los clientes por un sistema de navegación GPS para automóvil. En primer lugar, realizamos la pregunta funcional:

• ¿Qué le parecería que este automóvil tuviera un sistema de navegación GPS?

Limitamos las respuestas a las siguientes:

• Me gustaría que fuera así

• Esperaba que fuera así

• Soy neutral

• Puedo vivir con ello

• No me gusta así

Para este ejemplo, supongamos que nuestros clientes ficticios responden “Me gustaría que fuera así”.

A continuación, realizamos la pregunta en su forma disfuncional:

• ¿Qué le parecería que este automóvil no tuviera un sistema de navegación GPS?

Nuestros clientes ficticios pueden elegir cualquiera de las respuestas. Sin embargo, la respuesta puede ser, y generalmente es, distinta. En este ejemplo, supongamos que nuestros clientes ficticios respondieron "Esperaba que fuera así" a la pregunta disfuncional.

Al hacer esto en un proyecto real, podemos realizar estas preguntas opuestas a varios grupos de clientes, es decir, a distintos conjuntos de personas que representan funciones distintas en la organización del cliente. Podría tener un grupo de marketing, un grupo de contabilidad, un grupo de fabricación, etc. Para explicar el modelo, sin embargo, imaginemos que solo realizamos una pregunta a un solo grupo de clientes. Después de procesar el par de respuestas (la respuesta a la pregunta funcional y a la disfuncional), se asigna el resultado a una cuadrícula, como se muestra en la tabla 1.

Tabla 1: Asignación de Kano

Recuerde que, en el ejemplo, nuestros clientes ficticios respondieron Me gustaría que fuera así a la pregunta funcional y Esperaba que fuera así a la pregunta disfuncional. Si asignamos las respuestas a la tabla, vemos que la intersección de los dos atributos es una E, como indica el cuadro amarillo resaltado. Veamos qué significa eso para nuestro trabajo pendiente ordenado por prioridades.

• E = Excitadores. Se trata de características que el cliente no esperaba y que realmente diferencian un producto de sus competidores. Son difíciles de identificar, especialmente al principio, porque puede ser difícil dar con preguntas que susciten características excitantes. Por este motivo, los excitadores tienden a aparecer y ganar importancia a medida que el proyecto progresa y se empiezan a recibir comentarios de los clientes.

  • Los clientes obtienen gran satisfacción de estas características y están dispuestos a pagar un precio elevado por tenerlas. Por ejemplo, el iPod de Apple encantó a sus clientes con su capacidad intuitiva de girar automáticamente los contenidos según la orientación de la pantalla. Sin embargo, la ausencia de esta característica no hubiera reducido su satisfacción, dado que el cliente no contaba con ella.

  • En nuestro ejemplo, la navegación GPS sería una característica interesante. Estudiar esta característica, al menos hasta el punto de recibir comentarios de los clientes, debería ser una prioridad relativamente alta.

• B = Base. Estas características deben estar en el producto. Son indispensable y de alta prioridad.

  • Con independencia de lo bien que se ejecuten estos atributos básicos, el cliente permanecerá neutral respecto al producto. Un procesador de textos, por ejemplo, debe disponer de las funciones “crear documento” y “guardar documento”. Sin ellas, el producto no es viable.

  • Si hubiéramos preguntado a nuestro grupo de clientes por los cinturones de seguridad, la mayoría respondería que esperan que un automóvil los incluya, y que lo contrario no les gustaría. Si asignamos estas dos respuestas a la cuadrícula, vemos que los cinturones de seguridad son una base (B), una característica imprescindible.

• L = Lineal. Las características lineales, también conocidas como requisitos de rendimiento, se correlacionan directamente con la satisfacción del cliente. Quedan justo por debajo de las características básicas en prioridad, pero se debe valorar su costo.

  • Un aumento en la funcionalidad o la calidad de ejecución incrementa la satisfacción del cliente. Una reducción de funcionalidad disminuye la satisfacción.

  • El precio del producto suele estar relacionado con estos atributos.

• I = Indiferente. Estas características son menos importantes para el cliente y, por tanto, deberían serlo también para el producto. Probablemente generen poco o ningún valor para el negocio.

La tabla 1 muestra también los resultados Q y R.

• Q: Cuestionable. La pregunta probablemente es incorrecta o la respuesta es sospechosa.

• R: Inversa. No se puede computar la combinación de respuestas. Tomemos el sistema de navegación GPS: si alguien responde que es una función que se espera ya incluida pero también que le gustaría que no estuviera, es una respuesta R.

Si se da un par de respuestas Q o R, es preciso investigar con más detalle las preguntas o las respuestas.

Juegos de innovación

Los juegos de innovación son herramientas que ayudan a desarrollar una investigación de mercado primaria. Con estas herramientas, los clientes juegan a “juegos” que tienen como objetivo generar comentarios y opiniones sobre un producto o servicio. Luke Hohmann creó doce de estos juegos y los describe en su libro Innovation Games, que es fundamental en cualquier biblioteca. Mis dos juegos favoritos para establecer las prioridades de trabajos pendientes son Podar el árbol del producto y Comprar una característica, que Luke describe en este extracto de libro (usado con permiso):

Podar el árbol del producto

Los jardineros podan para controlar el crecimiento de los árboles. En ocasiones, la poda se realiza con arte y obtenemos arbustos con forma de animal o figuras abstractas interesantes. La mayoría de las veces, la poda tiene como objetivo un árbol equilibrado que produzca fruta de alta calidad. No se trata de “cortar”, sino de “dar forma”. Use esta metáfora para ayudar a crear un producto que satisfaga a los clientes.

El juego

Empiece por dibujar un árbol de gran tamaño en una pizarra o papel de croquis, o imprima a tamaño póster una imagen de un árbol. Las ramas gruesas representan áreas principales de funcionalidad del sistema. El borde del árbol, sus ramificaciones más exteriores, representan las características disponibles en la versión actual. Escriba posibles características nuevas en varias tarjetas. Lo ideal sería que tuvieran forma de hoja. Pida a los clientes que coloquen las funciones deseadas en el árbol para definir la siguiente fase de su crecimiento. ¿Es el resultado un árbol que crece de forma equilibrada? ¿Se concentra la mayor parte del crecimiento en una única rama, tal vez una característica básica del producto? ¿Cobra fuerzas un aspecto poco utilizado del árbol? Sabemos que las raíces de un árbol (la infraestructura de soporte y atención al cliente) deben extenderse al menos tanto como la copa. ¿El suyo es así?

Árbol de producto – Hohmann

¿Por qué funciona?

Usted y sus clientes saben que las características varían en importancia y que tendemos a dedicar nuestros esfuerzos a las características más importantes, aquellas que ofrecen un mayor valor a los clientes. Lamentablemente, esto significa que a veces dedicamos muy poco esfuerzo a características necesarias para completar el producto. El juego Podar el árbol del producto permite a los clientes contemplar el conjunto de características que conforman el producto y opinar en el proceso de toma de decisiones.

Comprar una característica

¿Qué características llevan a los clientes a comprar un producto? ¿Cuáles logran que los clientes se actualicen? ¿Qué característica los dejan tan satisfechos que ignorarán o tolerarán otras que hubieran querido ver corregidas o eliminadas?

Los planeadores de producto debaten interminablemente estas y otras cuestiones. Elegir el conjunto adecuado de características a agregar en una nueva versión suele representar la diferencia entre un fallo a corto plazo y un éxito duradero. Lamentablemente, demasiados planeadores toman esta decisión sin involucrar a aquellos a los que más se afecta: los clientes. El juego Comprar una característica mejora la calidad de la decisión pidiendo a los clientes que ayuden a tomarla.

Comprar una característica – Sterne

El juego

Cree una lista de características potenciales y asigne un precio a cada una. Al igual que en un producto real, el precio puede basarse en los costos de desarrollo, el valor para el cliente o cualquier otra cosa. Aunque el precio puede ser el costo real que se piensa cobrar por la característica, normalmente no es necesario. Los clientes utilizan dinero del juego que usted les proporciona para comprar aquellas características que desean ver en la próxima versión del producto. Asegúrese de que algunas características tengan un precio demasiado alto como para que nadie pueda comprarlas por su cuenta. Anime a los clientes a crear fondos comunes para comprar características especialmente importantes o caras. Esto promoverá negociaciones sobre qué características son las más importantes.

Este juego funciona mejor con grupos de entre cuatro y siete clientes, de modo que se promuevan más oportunidades para negociar y crear fondos comunes. A diferencia del juego Embalaje del producto, este se basa en una lista de características que seguramente ya estén incluidas en su plan de desarrollo.

¿Por qué funciona?

Los planeadores de producto caen a menudo en el error de pensar que los clientes tienen prioridades claramente definidas acerca de los productos. Algunos sí. La mayoría no. Cuando se les presenta un conjunto de opciones, muchos clientes dicen simplemente “las quiero todas” y le dejan a usted la responsabilidad de asignar prioridades a sus peticiones. Por otra parte, los directores de producto suelen recopilar información sobre prioridades de características al trabajar codo a codo con los clientes, y en el proceso, y tal vez sin darse cuenta, acaban determinando ellos mismos las prioridades. Al involucrar a los clientes como un grupo y proporcionarles recursos limitados, se les da la oportunidad de asignar como grupo la prioridad de sus deseos. Pero no es ahí donde está la magia. La magia está en la estructura de las conversaciones, ya que los clientes negocian entre ellos qué características desean. Es esta negociación la que profundiza su comprensión de lo que realmente quieren los clientes.

Ponderación relativa – Karl Wiegers

Otro método excelente de asignación de prioridades es el de Ponderación relativa, introducido por Karl Wiegers en 1999. Este método no solo proporciona un mecanismo para asignar prioridades a los requisitos según los comentarios y opiniones de los usuarios, sino que también incluye el juicio experto del equipo. Como el método de Kano y los juegos de innovación, la Ponderación relativa permite al propietario del producto valorar mejor qué características implementar y en qué orden.

El primer paso es asignar un peso al beneficio relativo de cada característica. El beneficio es la ventaja que el usuario tiene por disponer de la característica en el producto final. A continuación, se asigna la penalización relativa. La penalización es la desventaja para el usuario por no disponer de la característica en el producto final. (La ponderación de beneficios y penalizaciones consigue lo mismo que el formato de preguntas funcional/disfuncional del método Kano.) Los pesos son números arbitrarios que representan la valoración que su empresa hace de las ventajas y riesgos de cada característica. Es un proceso similar al que emplea un profesor para determinar el peso de los deberes, la asistencia, los trabajos y los exámenes en la nota final, algo que varía de un profesor a otro. Si decide que los beneficios compensan las penalizaciones, asígneles un peso mayor, en la relación que estime conveniente. Si decide que las penalizaciones superan a los beneficios, ajuste la ponderación en consecuencia. En el ejemplo de la tabla 2, asignamos al beneficio un peso relativo de 2 y a la penalización un peso relativo de 1, lo que significa que el beneficio será un elemento más importante a la hora de determinar la prioridad final.

Del mismo modo, ponderamos el porcentaje de costo y el porcentaje de riesgo. En el ejemplo siguiente, el riesgo no era una preocupación importante del proyecto, así que al porcentaje de costo se le asignó un peso de 1 y al porcentaje de riesgo un peso de 0,5. (Tenga en cuenta que, aunque los beneficios y penalizaciones se ponderan antes de calcular el porcentaje de valores, el costo y el riesgo se ponderan como porcentajes). En el caso de un proyecto de alto riesgo, podría asignar un peso mayor al riesgo que al costo.

Establecidos los pesos, solicitamos a los usuarios que valoren el beneficio relativo y la penalización relativa de cada característica. La escala empleada para la ponderación puede ser cualquiera (Wiegers recomienda 1-9), siempre que sea consistente. El beneficio relativo es el valor que ofrece la característica; la penalización relativa, el impacto negativo potencial de no incorporar la característica.

Por ejemplo, supongamos que una posible característica es “Hacer que el widget cumpla la normativa Sarbanes-Oxley”. El beneficio relativo para el usuario es prácticamente nulo, pero la penalización relativa para el negocio es grande: no hacerlo podría dejar a la empresa fuera del negocio. Así las cosas, podríamos asignar una puntuación de 1 o 2 al beneficio relativo y un 8 o 9 a la penalización relativa.

En el siguiente ejemplo, los usuarios ponderaron con un 5 el beneficio relativo de la característica “Consultar el estado de un pedido de proveedor”. A la penalización relativa le asignaron un 3. Para obtener el valor total de la característica, multiplicamos ambos números por sus pesos relativos y los sumamos:

(Benefit * Weight) + (Penalty * Weight) = Total Value

(5 *2) + (3*1) = 13

En este caso, el valor total de la característica es de 13 puntos.

Una vez tenemos el valor relativo total y el porcentaje del valor de las características, dejamos a un lado a los usuarios para consultar al equipo. Pedimos al equipo que estime el costo relativo de implementar cada característica, utilizando para ello la misma escala. Karl Wiegers lo explica así: “Los desarrolladores ponderan los costos en función de factores como su complejidad, la cantidad de trabajo requerido en la interfaz de usuario, la posibilidad de reutilizar diseños o código ya existente y el volumen necesario de pruebas y documentación.”

Después de estimar el costo relativo, estimamos el riesgo relativo. Una vez más, Wiegers explica: “Los desarrolladores estiman el grado relativo de riesgos técnicos o de otra naturaleza asociados a cada característica, en una escala del 1 al 9. Una estimación de 1 significa que es algo que se puede programar con los ojos cerrados, mientras que un 9 expresa serias dudas sobre la viabilidad, la disponibilidad de personal con la experiencia necesaria o el uso de herramientas y tecnologías desconocidas o poco probadas. La hoja de cálculo calcula el porcentaje de riesgo total correspondiente a cada característica.”

Después de anotar los valores de beneficio, penalización, costo y riesgo relativos, sumamos cada columna. Con estos totales calculamos los porcentajes.

• Porcentaje del valor total: se divide cada suma de beneficio relativo y penalización relativa entre la suma total de la columna. En el ejemplo siguiente, sería 13 / 154 = 8%.

• Porcentaje del costo relativo: se divide cada valor de costo relativo entre la suma total de la columna. En el ejemplo siguiente, sería 2 / 42 = 4,8%.

• Porcentaje de riesgo relativo: se divide cada valor de riesgo relativo entre la suma total de la columna. En el ejemplo siguiente, sería 1 / 33 = 3%.

• Prioridad: se divide cada porcentaje del valor entre (porcentaje del costo * peso del costo) + (porcentaje del riesgo * peso del riesgo). En el siguiente ejemplo, sería 8,4% / ((4,8% * 1) + (3% * 0,5)). El resultado es el valor de prioridad (1,345).

Después de obtener los valores de prioridad, los ordenamos en orden descendente, de modo que los elementos prioritarios queden arriba. Será necesario recalcular las prioridades cada vez que se agreguen elementos a la lista de trabajo pendiente o se reciba más información.

La hoja final tiene este aspecto:

Este método de trabajo le permite entender mejor los intervalos apropiados para el equipo y las partes interesadas. También ayuda a centrar las discusiones, ya que puede ser difícil ponderar objetivamente los beneficios, penalizaciones, costos y riesgos de cada característica.

Wiegers explica cómo lograr que el modelo coincida lo máximo posible con su realidad:

"Calibre el modelo según sus necesidades, utilizando para ello un conjunto de requisitos o características ya completados de un producto previo. Ajuste los factores de ponderación hasta que las prioridades calculadas coincidan con su evaluación a posteriori de la importancia real de los requisitos en el conjunto de prueba. Este modelo también puede ayudarle a alcanzar soluciones de compromiso al evaluar posibles características nuevas. Utilice el modelo para estimar la prioridad de las nuevas características y compárelas con las ya existentes, de modo que pueda determinar una secuencia de implementación apropiada. Cualquier operación que lleve el orden de prioridades de características de un terreno político a otro objetivo y analítico mejorará la capacidad del proyecto para ofrecer funciones importantes en el orden más adecuado.”

Karl Wiegers ha escrito dos libros que profundizan en la ponderación relativa: Software Requirements, Second Edition y More About Software Requirements: Thorny Issues and Practical Advice.

Tanto si usa alguno de estos métodos como si prefiere otra técnica, recuerde que el trabajo pendiente de un producto es un ente vivo. No se puede asignar prioridades una vez y luego olvidarse. Una lista de trabajo pendiente apropiada requiere mantenimiento. Para que el proyecto discurra correctamente, deberá reevaluar constantemente los comentarios de los clientes, su importancia para el proyecto y el efecto de las nuevas informaciones sobre los trabajos pendientes. Debe esforzarse por mantener a las partes interesadas y los clientes implicados a lo largo de todo el proyecto. Además, debe recordar que la estimación de un elemento es esencial para determinar su prioridad. No permita que sus listas de trabajo pendiente queden obsoletas o mueran por inactividad. Invierta tiempo y esfuerzo en mantener sus listas actualizadas con la información más reciente. Apreciará los resultados no solo en el producto final, sino también en su cuenta de resultados.

Vea también

Conceptos

Colaboración (Profundizar más) [redirigido]

Colaborar [redirigido]

Comentarios de interés de la solicitud y el proceso mediante Team Web access

Realizar un seguimiento del trabajo y administrar el flujo de trabajo [redirigido]

1. Requisitos de Agile Software, Dean Leffingwell, Addison Wesley

   “Attractive Quality and Must-be Quality”, Noriaki Kano, Quality JSQC, Vol. 14, n.º 2, octubre de 1984. El artículo original de Kano.

2. First Things First: Prioritizing Requirements, por Karl E. Wiegers