Vamos falar novamente sobre MVP, produtos de usabilidade mínima

4. Vamos falar novamente sobre MVP, produtos de usabilidade mínima

O conceito básico de MVP foi mencionado no blog anterior, e este estudo de curso acabou de mencionar sobre MVP, então vamos resumir como usar o pensamento MVP no trabalho.
Alguns princípios para usar rapidamente o MVP:

- Deduza a lógica com antecedência, não verifique cegamente
- Verifique o longboard, não o shortboard
- Soluções criativas de baixo custo

O outro lado do MVP

1. Alguns princípios de uso rápido do MVP

1.1 Deduza a lógica com antecedência, não verifique cegamente

Antes de projetar um produto mínimo utilizável, você deve pensar claramente sobre os problemas que deseja verificar, quais itens de dados coletar, os possíveis resultados desses itens de dados e as conclusões representadas por diferentes resultados.

Semelhante ao TDD (Test Driven Development) na engenharia de software , primeiro liste os resultados que você deseja e, em seguida, inverta o design, para não tornar a lógica do design confusa ou perder o gerenciamento de dados e desperdiçar recursos.

1.2 Verifique a prancha longa, não a prancha curta

Corte as pranchas curtas o máximo possível e coloque recursos nas pranchas longas

Tente se concentrar na experiência central e diferenciada.
Por exemplo, a primeira versão do 12306 era um MVP e toda a experiência do produto era muito ruim, mas o longboard ainda refletia totalmente: ele tem votos.

Nesta época, basicamente, várias formas de produtos foram pensadas ou implementadas. Para se firmar no mercado, não contamos com uma pontuação média maior, mas em atingir dez vezes o plano existente em uma única dimensão. bom. Portanto, é mais importante ser um MVP para verificar esse longboard, do que fazer uma tentativa medíocre sem cometer erros.

1.3 Soluções criativas de baixo custo

Ao projetar um produto mínimo utilizável, precisamos criar soluções criativas de baixo custo para verificar as proposições mais críticas.

1.3.1 Substituindo o sistema por humanos

Na verdade, não há necessidade de estar tão bem preparado antes de ir para a estrada.Em muitos casos, você pode usar a força humana para resistir primeiro ao teste. Se o serviço for realmente confiável, será tarde demais para iterar rapidamente e usar recursos sistemáticos para resolver problemas.

1.3.2 Usando sistemas de terceiros

A infraestrutura de Internet de hoje é muito maior do que naquela época, de SaaS a PaaS, de serviços em nuvem a criação de sites, comércio eletrônico, pagamento e pequenos programas. Portanto, para nós, o limite para a construção de um MVP está ficando cada vez menor Você deve usar serviços de terceiros o máximo possível para verificar rapidamente suas ideias.

1.3.3 Use regras para restringir a cena

Suponha que planejamos investir recursos na criação de robôs inteligentes de atendimento ao cliente e agora queremos verificar se os usuários podem aceitar o diálogo com as máquinas para resolver problemas. Antes que haja algoritmos e dados de compreensão de linguagem natural, podemos simplificar a dificuldade de implementação de fornecer diálogo ao restringir a cena. Por exemplo, podemos definir condições. Quando o usuário abrir a página de detalhes do pedido em até três dias após a confirmação do recebimento, é muito provável que o produto seja devolvido. Nesse momento, aparecerá uma entrada para consulta de devolução. Após clicar em, ele entrará no processo de atendimento ao cliente da máquina. Esse processo só pode ter a capacidade de resolver o problema de retorno e pode até ser concluído com um simples par de controle de qualidade, e os requisitos para dificuldade de implementação serão bastante reduzidos.

2. O outro lado do MVP

O MVP não é a única metodologia correta, e muitas pessoas discordam do pensamento MVP e Lean.

Existem muitos modelos de produtos que requerem um certo volume e complexidade para completar a verificação. O MVP só pode verificar se as suposições em alguns links são verdadeiras no máximo. Não aposte todos os seus tesouros em um MVP. Especialmente para produtos com campos relativamente maduros, a sobreposição de detalhes da experiência do produto pode constituir a competitividade central e pode ser difícil construí-la no MVP.

3. Resumo

Combinado com um produto em que tenho trabalhado recentemente, é um produto para usuários B-end. O ponto bom é que o sistema de terceiros é razoavelmente usado para desenvolver rapidamente nossos produtos. O ponto ruim é que o negócio é muito complicado , e o MVP construído é difícil de verificação, o ciclo de desenvolvimento do produto é muito longo, seriamente fora de contato com o desenvolvimento da indústria.

Livros recomendados:
1. Lean Startup
2. Toyota Production System

Acho que você gosta

Origin blog.csdn.net/koudan567/article/details/102831039
Recomendado
Clasificación