¿Cómo decidir qué características deberían estar en MVP? [cerrado]

Utilizo la priorización de MoSCoW con los clientes (debe, debería, podría, no) y construyo desarrollos en torno a eso. Si el cliente cancela el lanzamiento si la función 'X' no se entregó, o si no hay una solución alternativa, entonces la función 'X' es imprescindible.

Por lo tanto, el MVP se define por la lista de 'Obligaciones' en la priorización.

Para reducir el desperdicio y construir un MVP eficiente, desea atacar el resultado que más valoran. Algo tan importante pero que aún no están satisfechos con la solución actual. Así es como filtra lo que importa y lo que no antes de asignar más recursos para construir realmente la cosa. No tiene sentido resolver / probar algo con lo que ya están satisfechos o algo que sienten que no es importante. No quiere perder su tiempo, presupuesto y recursos.

Ejemplo.

Supongamos que desea resolver un trabajo de "Obtener un viaje a mi destino"

1. Hable con la gente y dibuje el modelo de valor del cliente para mapear su proceso actual.
2. Hable con la gente, analice y defina la unidad de medida específica que valoran.

3. Realice una encuesta/entrevista y pida a las personas que califiquen cada unidad de medida por importancia y satisfacción usando una escala del 1 al 5. (1 significa nada importante/satisfecho mientras que 5 es totalmente importante/satisfecho).
4. Use el algoritmo de oportunidad para descubrir el resultado más importante pero aún no están satisfechos.

**

Oportunidad = importancia + max (Importancia-Satisfacción,0)

**

Resultado:

¿Cómo leer este resultado?

Para el resultado #1, el 90% de los entrevistados calificaron con 4 o 5 la importancia del resultado y solo el 40% de ellos están satisfechos (calificados con 4 o 5) con la solución actual. Resultando en un puntaje de oportunidad de 14.0. De lo contrario, para el resultado n. ° 2, lo ven como algo que no es realmente importante pero que en realidad ya está bien atendido con la solución actual. No querrás concentrarte en el n.° 2 por ahora. En cuanto al #3, tiene el puntaje de oportunidad más alto. Significa que "Minimizar la posibilidad de que mi viaje llegue a un lugar equivocado" es muy importante para ellos, pero no están realmente satisfechos con la solución actual. Esta es su oportunidad; por lo tanto, debe incluir una solución en su MVP. Podrías tener cientos de resultados, esta técnica te ayuda a priorizarlos.

La forma más sencilla de determinar el conjunto de funciones de un MVP es preguntarse sobre CADA función: "¿Se requiere esto para proporcionar la cantidad mínima de valor al usuario final?". Todo el concepto de MVP es sacar algo lo más rápido posible para comenzar a validar sus hipótesis aprendiendo con datos de usuarios reales. Por lo tanto, solo debe incluir la MAYOR cantidad mínima de cosas que se requieren para validar esas hipótesis. Cualquier cosa adicional que incluya retrasará la cantidad de tiempo que lleva probar o refutar sus hipótesis y, por lo tanto, podría ser una pérdida de tiempo.

Si está tratando de tomar una decisión sobre las funciones de MVP y aún no sabe qué hipótesis generales está tratando de probar o refutar con su MVP, entonces ya está condenado a elegir el conjunto de funciones de MVP según la opinión personal, el consenso y quien sea. tiene la voz más alta. Por lo tanto, debe asegurarse de comenzar con una idea clara de cuáles son los objetivos de aprendizaje del MVP antes de poder hacer cualquier otra cosa.

Es difícil ser riguroso con las decisiones de MVP, especialmente con los clientes y las partes interesadas que casi siempre van a estar del lado de "sí, eso es necesario", pero es la mejor manera de asegurarse de aprovechar al máximo su tiempo y el de sus ingenieros en el a largo plazo mediante la creación de productos que se basen en la realidad en lugar de basarse en las suposiciones de la realidad que usted y su equipo tienen.

En general, la forma de determinar un MVP sería sentarse con el Cliente y elaborar una lista de requisitos. Una vez que se recopila la lista, es mejor clasificarlos según la prioridad.

Hay muchos métodos para hacer esto, asignando números (1-10, 1-100), MOSCÚ, Fibonacci, etc. Depende del cliente lo que prefiera.

Luego examinaría los requisitos de máxima prioridad y determinaría sus dependencias, y luego partiría de ahí.

Una pregunta bastante complicada dado que MVP depende de lo que a los usuarios les guste o no en un producto que aún no existe. Estamos jugando con el futuro, es decir, no tenemos datos duros en este momento en los que basar nuestra decisión.

En ese caso, podríamos investigar estudios de casos del pasado, más cercanos a sus intenciones de propuesta de valor. Digamos que buscas un MVP para un auto volador. Debe preguntarse: ¿qué desarrollos de productos similares hemos visto en el pasado en términos de público objetivo, industria, precio proyectado, posicionamiento, supuesta curva de adopción de innovación, etc.?

Una vez que se te ocurran algunas sugerencias, puedes comenzar a pensar en ellas "en el tiempo": si tuvieras que desarrollarlas en el tiempo (con tu conocimiento actual sobre ellas), ¿qué eliminarías para llegar a lo básico? etapa de un MVP?

Tales especulaciones no le darían una respuesta directa, pero podrían inspirar su creatividad sobre el tema.

Aparte de eso, esfuércese por hacer que su MVP sea lo más flexible posible para modificarlo. Esto le permitiría responder a los comentarios del mercado. Tenga en cuenta que esto es contrario a la intuición: generalmente por MVP entendemos una versión simplificada (que también significa la más barata) y no la más flexible (que puede ser bastante costosa).