Cabe um MVP para este cenário?

Olá!

A pergunta abaixo surgiu de um participante do Webinar de Introdução ao conceito de MVP ocorrido no dia 06/02 as 20:01 (horário de Brasília).

A partir de agora, queremos aproveitar os insights, discussões e comentários gerados durante os Webinars ou minicursos online, ao vivo e gratuitos, e com isso criar posts ou outros conteúdos. Chamamos isto de Insights do Webinar.

A cada Webinar ou minicurso estamos compartilhando conhecimentos e práticas que aplicamos em nosso dia a dia, ensinando, aprendendo, ampliando networking, buscando a melhoria contínua através dos feedbacks e promovendo reflexões.

Resumo deste post:

  • Falar sobre M.V.P. (Minimum Viable Product)
  • Introduzir os conceitos da abordagem Inception to Go
  • Falar da importância da efetiva participação do usuário final e do time técnico nos processos  de Inceptions
  • Dica de livro sobre o tema M.V.P. 

Vou editar a pergunta para preservar a identidade do participante, mas foi algo mais ou menos assim:

“Existe um projeto, que foi implementado há 3 anos , e agora ele ganhou um novo direcionamento. Os resultados até o momento não foram nada satisfatórios. Vou encabeçar este projeto, que no meu entendimento está começando do zero. Cabe um MVP?”

Vamos a definição de MVP no site da Endeavor

“É um conjunto de testes primários feitos para validar a viabilidade do negócio. São diversas experimentações práticas que serão desenvolvidas levando o produto a um seleto grupo de clientes… mas não é o produto final! Estamos falando em um produto com o mínimo de recursos possíveis, desde que (em sua totalidade) estes mantenham sua função de solução ao problema para o qual foi criado (não vale ser apenas funcionalidades soltas: juntas, elas devem configurar um produto, ainda que em forma de protótipo!). O empreendedor vai oferecer o mínimo de funcionalidades para conhecer na prática a reação do mercado, a compreensão do cliente sobre seu produto e se ele — de fato — soluciona o problema do consumidor.”

Quando falamos em M.V.P.(Produto Mínimo Viável), estamos falando em validar hipóteses junto a um publico o mais breve possível, para gerar aprendizado.

Vamos levantar alguns pontos baseados nos questionamentos da pergunta:

O projeto foi implementado há 3 anos…

Os resultados não estão nada satisfatórios…

Começando do zero…

O que aconteceu nestes três anos?

O projeto foi colocado em produção? Me parece que sim.

Resultados nada satisfatórios, para quem? Para todos?

Me chama a atenção o começar do zero.

Cabe um MVP se você quiser testar hipóteses, aprender com o público e melhorar o produto o mais breve possível para evitar que ocorram os mesmos problemas relacionados ao produto (construído há 3 anos atrás). Está resolvendo a dor do usuário?

Quer saber mais sobre M.V.P.? Veja abaixo nossas dicas de livros.

DicadeLivrosInceptionToGo

 

 

Aproveite e veja também este artigo sobre MVP no blog da Nubank

Agora, poderia caber um redesenho do produto, realizado diretamente com o usuário final. Questionando por exemplo:

  • Quais os principais problemas do produto atual?
  • O que esta faltando de funcionalidade?
  • Quais as partes positivas?
  • O que poderia ser melhorado?
  • Como está a experiencia do usuário?
  • As funcionalidades contribuem para os objetivos do negócio?
  • E a performance do produto?
  • O que pensam  partes interessadas  sobre o produto?

Este redesenho também vai gerar um pacote de trabalho contendo as funcionalidades a serem evoluídas, corrigidas ou criadas/recriadas.  Eu gosto desta opção de redesenho neste cenário.

Se você vai construir do zero, ou redesenhar um produto, ou evoluir, eu sempre recomendo a participação de dois personagens protagonistas: usuário final e desenvolvedor(ou líder técnico e/ou arquiteto ). Isto sem contar a participação desde o inicio da área de UX/UI.

Eu já vi muitas vezes estes atores, não participarem de Inceptions, muito mais do que eu gostaria. Ignorar estas participações normalmente acarretam diversos problemas como:

  • Entregar o produto que o usuário final não precisa/não quer
  • Brutal diferença entre as estimativas no momento de definir o MVP, ou pacote de trabalho em relação ao início do trabalho de desenvolvimento
  • Equipe de desenvolvimento completamente deslocada em relação aos objetivos do produto
  • Áreas de negócios frustradas com prazos intermináveis
  • Reclamações constantes por parte dos usuários
  • Inúmeras dificuldades técnicas que surgem durante o desenvolvimento, deixando a equipe técnica sobrecarregada
  • Problemas de escopo, custos e prazos

Mas e a participação dos demais atores? Como:

  • Product Owners
  • Scrum Masters
  • Clientes
  • Gerentes de projeto
  • Arquitetos de softwares
  • Profissionais de UX
  • Partes interessadas
  • Área de governança
  • Segurança da informação
  • Testes/QA
  • DBA
  • Infraestrutura

E se você é um dos profissionais acima mencionados, recomendamos que saiba mais sobre Inception to Go e participe das Inceptions.

Inception to Go, é uma abordagem para definir um conjunto de funcionalidades mínimas,  com a participação efetiva do usuário final e do desenvolvedor, visando iniciar a construção o mais breve possível destas funcionalidades, que poderiam ser aplicadas em:

  • Produtos novos – (Definição de MVP)
  • Redesenho de produtos – Definição do conjunto de funcionalidades a serem corrigidas, melhoradas ou criadas, com objetivo de reestruturar um produto sobre a ótica de performance, usabilidade, redesenho de processos, novas tecnologias, etc.
  • Demandas evolutivas – Evolução de um produto existente, visando manutenção, demandas legais ou correção.

Inception to Go, é conjunto de atividades altamente colaborativas, realizado em 2 ou 3 dias consecutivos, com muito foco e práticas para:

  1. Entender o problema sob a ótica do cliente e do usuário final
  2. Identificar as personas envolvidas e como são impactadas
  3. Indagar sobre a interação dos sonhos que resolveria o problema na ótica do usuário final
  4. Identificarmos  as funcionalidades mínimas e ideais
  5. Ouvir o desenvolvedor/liderança técnica envolvida diretamente no produto para elencar riscos, pontos de atenção, sugestões, etc. Você vai deixar de fora da Inception o profissional que vai construir o produto?
  6. Promover alinhamento (de expectativas)
  7. Definir a funcionalidade core, que causará o maior impacto no produto, além de detalhar utilizando conceitos de prototipação rápida e design centrado no usuário
  8. Discutir a criação de uma POC (se necessário)
  9. Realizar checkpoints com DEV, Usuário final e UX para identificação de pontos de atenção
  10. Montar uma timeline listando os possíveis incrementos de produto das 2 ou 3 próximas  sprints
  11. Minimizar riscos de enormes divergências entre as estimativas durante a Inception, e o momento da construção
  12. Permitir que o time de desenvolvimento tenha insumos, para iniciar a construção o mais breve possível (de 2 a 5 dias após a Inception to Go)
  13. Estimar o esforço necessário para construir o produto

Alguns benefícios do Inception to Go:

  1. Com a participação efetiva do usuário final como cocriador, ficará mais objetivo construir uma solução para o problema certo, pensando por exemplo em aspectos de usabilidade desde o início
  2. Com a participação do desenvolvedor desde o início da Inception, reduzimos drasticamente as ocorrências provenientes de surpresas técnicas que seriam possivelmente apontadas durante a construção
  3. Ao discutirmos profundamente a funcionalidade core, descobrimos cenários, regras, exceções e fluxos alternativos que tardiamente identificados poderiam comprometer o custo, escopo e prazo, ou ainda a experiência do usuário. Além deste ponto, aumentamos o conhecimento sobre o tamanho de cada funcionalidade, contribuindo para estimativas mais realistas
  4. Alinhado as boas práticas de cocriação, filosofia Lean, experimentação e agilidade

Você ainda tem dúvidas se a abordagem Inception to Go é para você?

Inception_to_Go_Workshop_Fevereiro_2020_v03_Inception_to_go_para_voce

Inception_to_Go_Workshop_Fevereiro_2020_v03-inspiradas

Inception_to_Go_Workshop_Fevereiro_2020_v03-caracteristicas

Inception_to_Go_Workshop_Fevereiro_2020_v03-estrutura

Veja como foi o Workshop  100% gratuito sobre Inception to Go, que foi realizado no dia 01/02 em Sampa na EveryMind

Não importa se você precisa de um MVP para um produto novo, ou um pacote de trabalho para evolução ou redesenho de produtos digitais (softwares) existentes, Inception to Go é uma boa escolha para construir produtos digitais centrado nas reais necessidades dos seus clientes, com a participação efetiva do usuário final e direta do time de desenvolvimento. Chega de entregar produtos que seus usuários não querem utilizar.

Quer saber mais?

Vamos bater um papo, tomar um café e discutir seu cenário, envie um e-mail para contato@agilenow.com.br

#Inception to Go

Softwares, impactam vidas

Fernandes Lima

Cocriador da Inception to Go

 

 

 

 

 

 

Quantas Sprints para construir um M.V.P.?

Olá!

Vamos contextualizar primeiro.

M.V.P. (Minimum Viable Product) – produto mínimo viável, ou seja uma versão muito enxuta do seu produto que entrega valor para o seu cliente, e permite aprendizados, validar o mercado, o público ou ainda viabilidade técnica.

O conceito M.V.P. foi popularizado no Livro Startup Enxuta do Eric Ries, a ideia consiste trabalhar com poucos recursos, e buscar validar ou não a hipótese do MVP.

MVP não é:

  • Produto ruim
  • Protótipo
  • Foco na parte técnica

Vamos imaginar o seguinte exemplo:

Pense que você quer aplicativo para unir cuidadores de idosos e famílias que tenham idosos, e demandem um cuidador. Este seria o objetivo do seu produto completo, que teria inúmeras funcionalidades para cuidar de toda a jornada do cuidador, do contratante, da plataforma e assim por diante.

A ideia do MVP, seria construir algo muito simples, de valor para ambos os públicos e proporcionar alto aprendizado com períodos curtos de tempo.

O MVP neste caso poderia ser:

  • Uma pesquisa(por exemplo no Google forms) em grupos de Whatsapp perguntando se você contrataria este serviço?
  • Uma Landing page para você se oferecer como cuidador com seus dados de contato, ou a  família, e alguém fazendo o contato entre as pontas.
  • Um vídeo no Youtube explicando como funcionaria o serviço

Acho que ficou claro o que é M.V.P, senão veja os links abaixo no final deste post.

E Sprint, neste caso estamos falado das Sprints do Scrum, que é um período de tempo(de 1 a 4 semanas), onde o Time Scrum trabalha para realizar uma entrega de valor para o cliente. Na sprint, o time faz planejamento, inspeções diárias e trabalho árduo, até acabar o período de tempo acordado para o tamanho da Sprint.

No final deste post colocaremos alguns links para que você possa estudar sobre o Scrum.

Agora, voltando ao tema do post.

Vamos imaginar que nosso aplicativo ligando cuidadores de idosos a famílias tivesse as seguintes funcionalidades – produto “completo”:

  1. Pesquisar cuidadores
  2. Pesquisar famílias
  3. Match cuidador X Família
  4. Perfil do cuidador
  5. Perfil da família
  6. Agendamento da primeira visita
  7. Fechamento de contrato
  8. Envio de documentação do cuidador
  9. Avaliação da documentação do cuidador
  10. Aprovação do cuidador
  11. Reprovação do cuidador
  12. Avaliação do cuidador por parte da fámilia
  13. Avaliação da família por parte do cuidador
  14. Ranking dos melhores cuidadores
  15. Ranking dos melhores famílias

Estas seriam as funcionalidades do produto “completo”, e M.V.P, seria as funcionalidades abaixo:

  1. Pesquisar cuidadores
  2. Pesquisar famílias
  3. Match cuidador X Família

MVpCuidadorFamilia

Então neste caso, estamos escolhendo as 3(três) funcionalidades que vão compor o nosso MVP. Imagine que nosso time desenvolvimento estimou que para desenvolver este MVP, seriam necessários 5 sprints de 2 semanas cada.

Então neste caso, nosso MVP seria construído em 10 semanas. Logo, um MVP  pode consumir várias sprints. E este é o cenário mais comum.

Desta forma, quanto mais funcionalidades, mais recursos exigirá.

Vamos pensar Lean, este é o desafio!

Alguns links

O que é um MVP?

Sprint: O coração do Scrum

Audiobook(português) do Scrum Guide 2017 do André Gomes

Dica de livro: Lean Inception

Dica de livro: Comece sua Startup Enxuta

MVPQuantasSprints

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Conceber e entregar software como antigamente

Olá!

Em pleno domingão, temperatura agradável em Londrina/PR, ao baixar a edição do dia 11/08/2019 no Estadão Digital, seleciono alguns conteúdos e um me chama muito a atenção:

Seguro, despachante, aluguel e desmanche já são feitos por celular

A matéria do estadão fala de mobilidade urbana e a onda de startups com foco no setor automotivo.

“Se não assistimos televisão como antigamente, não usamos banco como antigamente, não nos deslocamos pela cidade como antigamente, precisamos questionar também outras relações de negócios ainda engessadas”, ressalta Ricardo Bernandes, presidente da Onsurance

Lendo o texto integralmente, a gente identifica umas opções bem diferentes e com foco na dor do cliente.

Diante disto, pensei, Por quê a gente ainda esta fazendo software como antigamente?

Explico.

Ainda perdemos uma infinidade de tempo tentando detalhar todo o escopo de um projeto de software, todas as possibilidades, exceções e fluxos.

Perdendo tempo, em identificar e/ou mitigar todos os riscos.

Muitas vezes, ignorando as REAIS necessidades do usuário final.

Perdendo tempo, construindo o produto errado.

Processos de construção morosos!

Eu gosto muito das seguintes práticas:

  1. Identificar a dor a ser resolvida – Lean Startup
  2. Envolvimento do usuário final como co criador
  3. Time de negócios e técnico trabalhando juntos
  4. Ter uma visão macro da dor a ser resolvida
  5. Participação ativa da área de negócios na priorização e detalhamento
  6. Uso de prototipação como ferramenta de comunicação ágil entre todos
  7. Iniciar a construção por uma pequena parte
  8. Entregas incrementais com ciclo curto, aliada a muito feedback e colaboração na veia

Já pensou se nossos projetos de softwares, pudessem adotar as práticas acima?

Parece simples, né?

#prototipandorequisitos

dinossauroAntigamente

 

 

 

 

Softwares, impactam vidas!

Olá!

Incrível, como somos dependentes dos softwares, e como estes, tornaram-se assunto de boteco, happy hour e do dia a dia entre pessoas comuns, e não somente profissionais da área de Tecnologia. As pessoas podem comentar sobre o seu dia de trabalho, e quando percebemos, tem uma pontinha de software ali… Pode ser uma visão meio nerd? Talvez! #UmDiaQueroSerNerd

Trechos de um bate papo, ocorrido entre eu(Fernandes) e a uma motorista do Uber .

“Eles poderiam liberar logo a funcionalidade, pois nos ajudaria muito em nosso trabalho”

Por quê acha isso?

“Eu saberia desde quando o usuário está na plataforma”

Verdade…

“Hoje, eu configurei a forma de pagamento mais restrita, quero medir o volume de corridas”.

Não sabia que isto era possível. Este recurso é novo?

“Não, faz tempo, eu utilizo muito quando trabalho até mais tarde”

Realmente, é muito mais que uma simples funcionalidade, é sim, uma proteção extra para sua integridade física

“Eu, só fico com medo quando tem atualização do aplicativo, percebi que algumas coisas podem mudar ou PARAR de funcionar. Isto complica nossa vida”

Software, funcionalidades, requisitos, deixaram de ser papo de T.I., projeto e área de negócios…

Softwares, impactam vidas!

Quando a gente entender isto, iremos nos preocupar VERDADEIRAMENTE com as entregas.

Seu projeto também é assim!

#VidaRealAlemDoPostIt

#FernandesLima

#PrototipandoRequisitos

Insights X Mars InSight – Trabalho diário e duro

Olá!

No dia 26/11/2018 as 17:52:59(horário de Brasília – um minuto antes do previsto) a sonda da NASA, Mars InSight pousou em Marte. É um grande feito para a ciência, e para a humanidade. Ela foi lançada em Maio/2018, percorreu 482 milhões de quilômetros até o seu pouso.

O resultado vem com a caminhada, e no caso da Mars InSight, um trecho de 482 milhões de quilômetros. E tem gente que deseja resultados rápidos.

“Fernandes, eu não sou astronauta”

“Eu trabalho com projetos, então isto não tem a menor relevância”

Explico.

O que vou abordar é sobre trabalho duro e diário para atingir resultados. Isto esta relacionado com projetos?

Lendo as matérias sobre a sonda Mars InSight, fiquei pensando:

  • Quanto trabalho duro(diário) foi realizado desde quando eles tiverem o primeiro insight?
  • Quantas horas de estudos? Pesquisas? Simulações ? Testes?
  • Quantos aprendizados surgiram durante esta jornada?
  • Quantas vezes a equipes envolvidas falharam?
  • Quantas vezes pensaram em desistir?
  • Quantas vezes tiveram que buscar mais conhecimento?
  • Quantas vezes tiveram que reunir para discutir problemas específicos?
  • Quantas vezes discutiram?

Não sei quantas, mas imagino que foram inúmeras.

Depois do “insight”, vem muito trabalho duro, diário, comunicação e colaboração.

E os resultados? Podem vir.

Não importa se teve um “insight” ou “Mars InSight”, o que faz a diferença é trabalhar duro, interagir, discutir(respeitosamente) e aprender com todos.

Depois do insight vem o bom e velho trabalho diário.

E este bom e velho trabalho, pode ficar ainda mais interessante quando interagimos colaborativamente com as pessoas. Mindset colaborativo.

Vamos continuar nossa caminhada!

Parabéns a equipe da NASA e a todos os envolvidos!

Que a nova hospede de Marte, consiga atingir todos os seus resultados nesta longa jornada!

Veja um pouco mais sobre este grande feito 

#boratrabalharduro

#boracompartilhar

#borainteragir

insight pousando nasa

 

 

Por quê compartilhar ?

Olá!

Porque podemos contribuir com o aprendizado de outras pessoas(e o nosso próprio), times e empresas! Esta explicação deveria ser suficiente.

Tentarei explicar melhor…

Vamos imaginar que eu(Fernandes) esteja num grupo de Whatsapp sobre produtividade, e que alguém compartilhe uma dica sobre: “como organizar melhor suas tarefas”.

Diante deste conteúdo compartilhado, eu posso tomar algumas ações(legítimas, todas elas):

  1. Ignorar (nada contra)
  2. No mínimo ler e descartar, pois isto não serve para mim e ninguém (nada contra)
  3. No mínimo ler, não serve para mim, mas pode servir para outro e compartilho (nada contra)
  4. Ler, refletir, pesquisar mais sobre o tema, promover discussões(respeitosas) e compartilhar com outras pessoas.

Penso da seguinte forma, se isto pode me ajudar, então também poderá ajudar outras pessoas. Simples assim!

Agora, caso não tenha valor(no meu modesto entendimento), eu não compartilho.

Muitas vezes é algo (extremamente) simples, mas o importante é contribuir e gerar aprendizado. Quem sabe este pequeno compartilhamento pode fazer a diferença.

E isto não tem nada a ver com ser bom samaritano – estou bem longe disto.

No meu ponto de vista, esta mais ligado ao fato de: ao compartilhar, novas ideias, discussões, compartilhamento, aplicações e aprendizados podem surgir, com isto potencializamos o conteúdo para todos.

Compartilhar o quê?

Eu costumo compartilhar, os itens abaixo:

  • Dicas de livros
  • Dicas sobre eventos pagos e gratuitos
  • Artigos/posts
  • Vídeos/podcasts
  • Frases inspiradoras
  • Cursos pagos e gratuitos
  • Workshops pagos e gratuitos
  • Meetups pagos e gratuitos

“Compartilhar é a nova maneira de aprender”. Sinceramente, não me lembro  quem disse esta frase.

Compartilhar para contribuir!

Para mim faz todo o sentido, até porque vivemos na era da economia compartilhada, ou não?

Este é apenas o meu ponto de vista!

boracompartilhar

 

 

Usuário final ganhando desconto para testar o produto – Isto ecziste?

Olá!

O Uber vai descontinuar o Uberpool e para substituir, lançará o Uber Juntos… Até aqui, tudo bem, mas a empresa, resolveu oferecer descontos para os usuários(passageiros) testarem(na vida real) a nova modalidade.

Qual foi a última vez que você ofereceu desconto para os seus usuários ? Lembra?  rs..rs

O ponto central para mim, é a empresa colocar o passageiro(usuário final do aplicativo) para testar o produto em condições reais e como incentivo ainda oferecer o desconto.

Além do desconto em si, que acaba chamando a atenção, o fato de envolver desta forma  o usuário final, acho fantástico. Não tem como saber, qual foi o envolvimento do usuário final na fase de concepção, ideação e a liberação dos primeiros releases desta funcionalidade.

“A companhia ainda ressalta que nos primeiros três meses, como incentivo para que os usuários testem o produto, as viagens terão valor até 50% inferior”

Quanto mais envolvermos o usuário final com o nosso produto, maior serão os ganhos, tais como:

  • Benefícios para o produto
  • Aprendizados sobre nosso usuário
  • Pontos a serem evoluídos
  • Interações do usuário com o produto em condições reais – vida real
  • Aumento do engajamento
  • Promoção da marca (se tudo der certo)

Esta ação merece ou não merece nossa atenção e no mínimo uma reflexão – novo tempos, meu amigo

#foconousuáriofinal

#mindsetcolaborativo

#leanstartup

UberUsuarioFinalAprovado