Caso práctico de priorización

1. El produto PideMe es una APP utilizable desde cualquier plataforma capaz de presentar
en pantalla los bares, cafeterías y restaurantes más cercanos. Una vez seleccionado el
negocio, el usuario accede a la carta de servicios, disponiendo de los precios y siendo
sencilla la forma de realizar un pedido. Una vez realizado el pedido, se enlaza con una
plataforma de pago. Una vez realizado el pago, se genera un ticket y cuando el pedido
está listo, se envía un mensaje al cliente (usuario) para que se acerque a recogerlo.
Esto ahorrará muchas esperas en las colas de bares, cafeterías y restaurantes y agilizará
la labor del camarero. Podemos encargar las copas del próximo bar, cuando aún no
hemos salido del último y lo mismo con una comida, cena, etc. Este ahorro de tiempo es
especialmente interesante para los negocios. Se podrá seleccionar también una hora
deseada de recogida, pudiendo de este modo reservar no solo la mesa sino el menú,
copas, etc. De este modo también se evita agotamiento del producto por haberse agotado
con el cliente anterior. Pueden realizarse pedidos cíclicos (ej: Si todos los viernes a las
10:30 me tomo mi gintonic de bombay en el Bogart). De esta forma, además el local se
evita pérdidas de tiempo y problemas con caja, cambios, etc.

2. Las 8 funcionalidades principales consisten en: Como usuario quiero:
1. Funcionalidad (Multiplataforma) desde cualquier plataforma fija o
móvil: Apple, MS, Android, etc
2. Adquisición de los datos del local (carta, menú, precio, oferta, etc).
3. Presentación geográfica/virtual (tipo ArroundMe)
4. Pasarela de pago
5. Interacción con local (camarero)
6. Pantallas fáciles y amigables
7. Quiero poder modificar o eliminar el pedido
8. Quiero que el pedido se anote en la agenda y me avise con tiempo
(configurable)

3. Como usuario, discrimino:
M- Must have: Funcionalidad multiplataforma, Adquisición datos
local.
S- Should have: Interacción con local, Pasarela de pago.
C- Could have: Cambio/eliminación de pedido, Pantalla amigable.
W- Won’t have: Enlace agenda/recordatorio, Presentación geográfica.
Las dos últimas historias serán ahora eliminadas.

4. Como equipo desarrollador, asigno los costes de cada funcionalidad:
Coste
Funcionalidad multiplataforma 5
Adquisición datos local 3
Pasarela de pago 1
Interacción con local 2
Cambio/eliminación de pedido 2
Pantalla amigable 4
Nota: 5 implica mayor coste

5. Como equipo desarrollador, asigno los riesgos de cada funcionalidad:
Riesgo
Funcionalidad multiplataforma 5
Adquisición datos local 1
Pasarela de pago 1
Interacción con local 2
Cambio/eliminación de pedido 2
Pantalla amigable 2
Nota: 5 implica mayor riesgo

6. Como usuario, asigno el valor de cada funcionalidad:
Valor
Funcionalidad multiplataforma 5
Adquisición datos local 4
Pasarela de pago 3
Interacción con local 2
Cambio/eliminación de pedido 3
Pantalla amigable 2
Nota: 5 implica mayor valor para el cliente

7. Considero que en el tipo de aplicación a desarrollar el coste conlleva
un peso de 0,4, el riesgo de 0,2 y el valor para el cliente 0,4
Nota: Me permito incluir también el valor para el cliente que puede
venir de encuestas, etc.

8. Funcionalidad Coste Impl. Riesgo Valor Cliente V. final Prioridad
Peso 0,40 0,35 0,25
Multiplataforma 5-5=0 5 5 3,0 1
Adq. Local 5-3=2 1 4 2,15 5
Pasarela Pagos 5-1=4 1 3 2,70 2
Interacción Local 5-2=3 2 2 2,40 4
Modif. Pedido 5-2=3 2 3 2,65 3
Amigable 5-4=1 2 2 1,60 6

9. El resultado pasa por la implementación de las distintas
funcionalidades en el orden siguiente:
Funcionalidad multiplataforma
Pasarela de pago
Cambio/eliminación de pedido
Interacción con local
Adquisición datos local
Pantalla amigable
Todas estas funcionalidades pueden ser implementadas de forma
independiente, así que no hay ninguna restricción en cuanto al orden
priorizado.

10. La lista una vez priorizada ya se ha mostrado en la anterior slide y
es la siguiente:
Funcionalidad multiplataforma
Pasarela de pago
Cambio/eliminación de pedido
Interacción con local
Adquisición datos local
Pantalla amigable