Caso práctico priorización FM

10
Definición del Producto 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.

Transcript of Caso práctico priorización FM

Page 1: Caso práctico priorización FM

Definición del ProductoEl 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.

Page 2: Caso práctico priorización FM

FuncionalidadesLas 8 funcionalidades principales consisten en: Como usuario quiero:1. Funcionalidad (Multiplataforma) desde cualquier plataforma fija

o móvil: Apple, MS, Android, etc2. Adquisición de los datos del local (carta, menú, precio, oferta,

etc).3. Presentación geográfica/virtual (tipo ArroundMe)4. Pasarela de pago5. Interacción con local (camarero)6. Pantallas fáciles y amigables7. Quiero poder modificar o eliminar el pedido8. Quiero que el pedido se anote en la agenda y me avise con

tiempo (configurable)

Page 3: Caso práctico priorización FM

Priorización MoSCoWComo 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.

Page 4: Caso práctico priorización FM

Coste/FuncionalidadComo equipo desarrollador, asigno los costes de cada funcionalidad:

CosteFuncionalidad multiplataforma 5Adquisición datos local 3Pasarela de pago 1Interacción con local 2Cambio/eliminación de pedido 2Pantalla amigable 4

Nota: 5 implica mayor coste

Page 5: Caso práctico priorización FM

Riesgo/HistoriaComo equipo desarrollador, asigno los riesgos de cada funcionalidad:

RiesgoFuncionalidad multiplataforma 5Adquisición datos local 1Pasarela de pago 1Interacción con local 2Cambio/eliminación de pedido 2Pantalla amigable 2

Nota: 5 implica mayor riesgo

Page 6: Caso práctico priorización FM

Valor/FuncionalidadComo usuario, asigno el valor de cada funcionalidad:

ValorFuncionalidad multiplataforma 5Adquisición datos local 4Pasarela de pago 3Interacción con local 2Cambio/eliminación de pedido 3Pantalla amigable 2

Nota: 5 implica mayor valor para el cliente

Page 7: Caso práctico priorización FM

Scoring: Peso/Coste/riesgoConsidero 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.

Page 8: Caso práctico priorización FM

Scoring: Aplic/Coste/Riesgo

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

Page 9: Caso práctico priorización FM

El resultado pasa por la implementación de las distintas funcionalidades en el orden siguiente:

Funcionalidad multiplataformaPasarela de pago

Cambio/eliminación de pedidoInteracción con local

Adquisición datos localPantalla amigable

Todas estas funcionalidades pueden ser implementadas de forma independiente, así que no hay ninguna restricción en cuanto al orden priorizado.

Priorización

Page 10: Caso práctico priorización FM

La lista una vez priorizada ya se ha mostrado en la anterior slide y es la siguiente:

Funcionalidad multiplataformaPasarela de pago

Cambio/eliminación de pedidoInteracción con local

Adquisición datos localPantalla amigable

Lista Priorizada