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

 

 

 

 

 

 

Workshop Inception to Go na Everymind – 01/02(sábado) – 09:00 as 18:00

Olá!

Era dia primeiro de fevereiro de 2020, mais um sábado …

Estávamos nós, (Alexandre, Emerson e eu) na EveryMind em Sampa para ministrar o workshop Inception to Go  mão na massa.

Vou fazer um parênteses aqui – 100% recomendaria para um amigo o workshop (informação atualizada em 06/02/2020 as 10:00 – após o fechamento da avaliação – média geral do treinamento: 9.26 ) – veja os depoimentos abaixo, e tire suas conclusões

Iniciamos com a apresentação das pessoas, tínhamos um verdadeiro caldeirão de cargos/papéis:

  • Scrum Masters e Agile coachs
  • Analistas de requisitos
  • Analista funcional
  • Gerentes de projetos
  • Analistas de negócios
  • Analistas de testes/QA

Somente para citar alguns exemplos. Imaginem as experiências destas pessoas com projetos e/ou produtos?

Realizada as apresentações, começamos a explicar a abordagem em si. Inception to Go, é uma abordagem para definir o MVP de produto digital (software) em conjunto com a funcionalidade principal, através da participação efetiva de dois atores importantes: Usuário final e o desenvolvedor. Estes atores, permitem que ao final da Inception to Go, tenhamos insumos para iniciar a construção o mais breve possível (de 2 a 5 dias após o termino da itoGo)

Abordagem explicada em poucos slides, partimos direto para a prática.

Fizemos uma dinâmica onde cada grupo, faria a fase de preparação da Inception to Go (que pode ser realizada online na vida real):

  • Definir o problema a ser resolvido
  • Pessoas chaves que participarão da Inception to Go
  • Logística/Regras
  • Artefatos a serem entregues após a Inception to Go

Cada dinâmica, mais atividades, discussões, networking e entusiasmo.

Quando nós percebemos, tinha acabado o período da manhã.

Partimos para almoço, retornando as 13:30.

Voltamos a tarde com a corda toda – mais dinâmicas em grupo:

  1. Product Vision Board
  2. Interação dos sonhos
  3. M.V.P.
  4. Funcionalidade core
  5. Etapas/protótipos
  6. Checkpoints
  7. P.O.C.
  8. Estamos prontos

Encerramos por volta das 18:15/18:20.

Para nós instrutores, foi motivo de muita alegria, aprendizado, compartilhamento e ótimas histórias da vida real.


Veja alguns depoimentos:

“Sabe aquele treinamento que quando você termina você se sente confiante e preparado para executar? Esse é um deles.
É tudo o que precisamos.
Sermos capaz de reproduzir em nosso dia a dia algo eficiente e eficaz.
Fico feliz em ter participado desse encontro.”

Selma Rodrigues – SM Coach DevOps

“A dinâmica do curso permite aprender fazendo atividades, o que faz a turma ficar muito envolvida e ‘acesa’, o tempo todo. E permite a troca de experience entre o grupo. “

Rogério Ilton Arita – Scrum Master

“Inception to Go! É a forma muito prática e objetiva de se fazer uma Inception e tirar o seu produto do papel e ou cabeça. Recomendo a todos a participar deste curso, sem dúvida muito exclarecedor e cheio de ferramentas para lhe auxiliar em seu dia a dia.”

Marcelo Gomes Ferreira – Analista de testes QA

“Sensacional pode aprender e nos fazer repensar um pouco mais sobre as etapas iniciais do projeto, muito bom mesmo, é vida real !”

Andreia Regina Paulini – Analista funcional Salesforce

“O Workshop é muito interessante e aborda o tema da Inception enfatizando a importância das duas pontas tão impactadas no resultado de uma Inception, mas tão esquecidas ou menosprezadas nesta etapa do processo de desenvolvimento, que são os desenvolvedores e usuários finais. Super recomendo o Workshop e outros conteúdos deste time incrível!”

Debora Bronzoni Aguiar – Analista de Negócios Líder

“Gostei muito da segurança/conhecimento que os palestrantes demonstram em relação às práticas da inception, e da disponibilidade em ajudar e tirar dúvidas de aplicação dessas práticas, nos mais diversos cenários”.

Sergio Roberto Xavier dos Santos Junior – Scrum Master

“Acredito que a prática proposta com o Inception To go é mais uma ferramenta voltada à colaboração e integração das equipes. É uma ferramenta que permeia o todo da cadeia de concepção de um produto criando um senso comum de pertencimento e entendimento de esforço x expectativa que proporciona ambientes favoráveis.”

Cesar Augusto Tomaz – Scrum Master

“Treinamento excelente e com muitas atividades práticas, o que facilita o entendimento e aplicação no dia a dia.”

Ricardo Batista Miluzzi – Agile Coach

“Treinamento muito legal, descontraído e produtivo. A equipe está de parabéns”

Diógenes Antônio – Gerente de Projetos

“Gostei da técnica, e com certeza irei aplicar na próxima oportunidade “

Margarete Bispo dos Santos Silva – Scrum Master


Muito obrigado a todos.

Agradecemos a EveryMind por ter gentilmente cedido o espaço, o coffee break e permitir que pessoas de fora da organização participassem.

Ao Ricardo Miluzzi por toda organização, comprometimento, parceria e ações.

Ao Marcelo Gomes, por ter doado dois livros físicos para sorteio  – Jornada Ágil e Digital

Devido a todo este apoio, foi possível realizar este workshop presencial 100% gratuito.

#InceptionToGo

Softwares, impactam vidas

Inception_to_Go_Imagem

Algumas fotos do Workshop de Inception to Go – 01/02(sábado) – 09:00 as 18:00 – SP – Escritório da EveryMind

AwMONs7QxOWZAY98

Hx53G1eAlT5ROgRwoLU0Z8awRR2EXvL3Wj_9z8cLwpw6ffTS

 

 

 

 

 

 

 

Inception to Go – Uma abordagem centrada no usuário e no desenvolvedor

Olá!

Vamos falar de projetos.

Projetos de softwares. Até parece assunto dos profissionais de Tecnologia da Informação, gestão de projetos, governança e outros, mas não é, é um tema que impacta diretamente as pessoas no cotidiano. Duvida?

Em nosso dia a dia utilizamos dezenas de aplicativos, para as mais variadas finalidades: pedir comida, deslocar, pagar contas, etc.

Mas e se, você fizesse parte de um time de uma empresa, no papel de Product Owner, analista de negócios, desenvolvedor, gerente de projeto e outros correlatos, como mapearia as reais necessidades dos seus clientes?

Os clientes podem ser internos (áreas de negócios) ou externos, isto não importa.

O que realmente importa é construir(rapidamente) software de acordo com as reais necessidades deste cliente, e gerar impacto no cotidiano do seu cliente, ou seja, a partir de uma demanda, você vai discutir colaborativamente, o que é o produto digital, qual o impacto, quem são as personas, definir o MVP e a funcionalidade core, tudo isto “dentro” da Inception to Go (que normalmente tem duração de 2 ou 3 dias).  Foco extremo!

Você esta fazendo isso?

E se eu te falar que Inception to Go, é uma abordagem para definir produtos digitais (softwares) considerando dois personagens centrais: O usuário final e o desenvolvedor. Mas sem esquecer dos objetivos de negócio.

Nada mais justo do que considerar relevante, quem vai utilizar o produto no dia a dia (usuário final) e o desenvolvedor que irá construir. E o Product Owner, onde entra nesta história? Simples, trabalha lado a lado com usuário final e desenvolvedor.

Pareceu confuso?

Então baixe este material e saiba mais sobre Inception to Go

Se o seu cliente é importante, então você vai levar em consideração o usuário final e o desenvolvedor.

Ao acessar nosso material inicial, entenda:

  • O que é Inception to Go?
  • Qual aplicação?
  • Quais benefícios?
  • Visão macro

Inception to Go

Softwares, impactam vidas.

Inception_to_Go_Imagem

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5 motivos para fazer uma P.O.C.

Olá!

P.O.C. – Proof Of Concept(Prova de Conceito) é um experimento que realizamos a fim de testar um cenário técnico, processos e viabilidade de uma tecnologia. Saiba mais neste link

Imagine que você recebeu do seu cliente, uma demanda de software, onde envolve a utilização de uma API de pagamentos, e seu time de desenvolvimento nunca trabalhou com esta tecnologia, então seria o cenário perfeito para fazer uma P.O.C. para aprender na prática sobre a API de pagamentos.

Ou seja, a P.O.C. é um experimento que produz muito aprendizado, com ciclo curto e atrelado a resolver algum desafio de negócio (de escopo muito mais amplo)

Vamos ver abaixo, 5(cinco) motivos para fazer uma P.O.C. (em minha opinião).

1.Hardware dedicado envolvido

catracas

Vamos imaginar que seu time de desenvolvimento precisa construir um software para uma academia, e neste local precisa de uma catraca, que deveria ser controlada por seu software e seu time nunca trabalhou com este tipo de catraca. Este é um ótimo cenário, pois envolve um hardware dedicado(a catraca, no caso).

Desta forma ao fazer a P.O.C. para aprender sobre a catraca, ele estaria ganhando experiência com o equipamento e com isso a construção do software para academia, ficaria mais previsível(no tocante a catraca, pelo menos)

Alguns tipos de hardwares dedicados, no quais eu faço P.O.C.

  • Painéis de senha
  • Impressoras fiscais
  • Coletores de dados
  • Máquinas industriais
  • Sensores/IoT
  • Catracas

2.Viabilidade técnica com muitos caminhos

Desenvolvimento Mobile

Você precisa resolver um problema da área de negócios, e existem diversas tecnologias concorrentes.

E se você tivesse que construir um Aplicativo Mobile, que tivesse como premissa acesso ao GPS, câmera e Bluetooth para realizar suas funções primárias. E seus times apontassem várias soluções(caminhos) técnicas, por exemplo:

  • RAD Studio
  • Android Studio
  • Xamarin
  • OutSystems

Veja neste cenário, 4 ferramentas que poderiam atender as premissas, então Qual escolher?

Uma P.O.C. poderia ajudar nesta escolha.


3.Integrações entre sistemas

integracoes

E se fosse necessário integrar o ERP da sua empresa a uma solução de terceiros, e esta integração fosse via “troca de arquivos” textos, por exemplo – arquivo CSV (sim, isto ainda existe – e ninguém te conta)

A P.O.C. seria uma ótima forma de realizar a integração, para sentir o nível de dificuldades, validar o layout, testar performance e etc.


4.Primeiro contato com a tecnologia

primeirocontato

Em sua empresa, você utilizam tecnologia de banco de dados relacional, por exemplo: SQL Server, Oracle ou MySQL, e surge a necessidade de utilizar um banco de dados noSQL, como o MongoDB.

Ou seja, seria o primeiro contato do seu time com a tecnologia noSQL, através do MongoDB.

Eu faria uma P.O.C.


5.Clarear requisitos

luz

Quando o seu cliente não entende muito bem o que ele deseja, e quando o time também tem dúvidas técnicas sobre algum ponto do projeto/produto.

Neste cenário, eu gosto de fazer um brainstorm para obter um entendimento mínimo do problema(sob a ótica de negócio), e se o time tiver alguma dúvida técnica, ou sobre performance, ou sobre o comportamento, eu faria a P.O.C.

Até a próxima

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

 

 

 

Ingredientes para prototipagem de requisitos de softwares

Olá!

A prototipagem ou prototipação de requisitos de softwares tem a finalidade de obter grande quantidade de informações sobre um problema, permitindo uma coleta de requisitos muito ágil e fluída. Possibilitando ao usuário final atuar como cocriador.

Diante do desafio de coletar requisitos de softwares, utilizar abordagens colaborativas e construção incremental de partes do produto, permite um melhor resultado devido a dois fatores:

  1. Participação do usuário final
  2. Utilização de ciclos curtos de feedback para correção e ajustes, contribuindo com a construção de produtos com foco nas REAIS necessidades dos clientes e/ou usuários

Antes de propor um sessão de prototipagem para coletar requisitos, sugiro alguns ingredientes básicos:

  1. Entendimento do problema a ser resolvido
  2. Quais os resultados esperados
  3. Definição do time multidisciplinar
  4. Escolha de uma funcionalidade chave que resolverá o problema de forma plena
  5. Definição de agenda para realizar a sessão
  6. Apoio de um sponsor

Dependendo do cenário, mais ingredientes poderiam ser necessários, mas vamos começar com estes.

1. Entendimento do problema a ser resolvido

Como assim o problema a ser resolvido? Explico.

Um desafio de negócio que hoje causa impacto negativo no processo atual, ou que poderia ser evoluído ou criado.

Vamos citar alguns exemplos:

  • Um novo processo de aviso de férias para facilitar a vida do RH, colaborador e gestor
  • Um relatório gerencial para área de compras visando apresentar as maiores compras por departamento e economia realizada
  • Uma tela de pedido de venda simplificada para ser utilizado por representantes na visita a clientes
  • Um aplicativo ou portal que permita acompanhar os custos dos projetos através de diversos indicadores para área de PMO

Todos estes problemas acima, precisarão da criação ou evolução de softwares com foco em melhoria de processo, automatização, redução de custos ou outros pontos.

Entender o problema e como as pessoas são impactadas é o primeiro passo.


2. Quais os resultados esperados

Tendo em vista que já sei qual o problema a ser resolvido, fica muito mais fácil estabelecer os resultados esperados.

Supondo que o nosso problema fosse:

Um novo processo de aviso de férias para facilitar a vida do RH, colaborador e gestor

  • Processo muito manual e sujeito a erros
  • Envio de planilhas entre os envolvidos
  • Falta de controle eficiente

Resultados Esperados:

  • Automação do processo e eliminação de erros
  • Visibilidade do processo para todos os envolvidos
  • Diminuição do custo operação para gestão do processo de férias

3. Definição do time multidisciplinar

Consiste num time que se complementa e as diferenças de visões contribuem para um produto mais aderente as reais necessidades

Apesar de ser um time, “Um por todos e todos por um” tenho dois perfis bem distintos: Técnico e de negócios

Técnico: Programadores, arquitetos, DBAs, Profissionais de UX/UI, Lider Técnico e testador

Negócios: Cliente, usuário final, gestores, Product Owner, analista de requisitos/negócios e partes interessadas.

O foco deste time deve ser a entrega do produto em ciclos curtos, muita comunicação e colaboração. Parece até ser fácil!

Acrescente um facilitador, e escolha um dos presentes para ser o escrivão da sessão de prototipagem, para registro e documentação dos requisitos discutidos.


4. Escolha de uma funcionalidade chave que resolverá o problema de forma plena

Imagine um produto contendo inúmeras funcionalidades, porém tem uma (ou conjunto delas) que é chave, aquela que “resolve a dor do cliente”

Vamos pensar no Uber, qual seria esta funcionalidade matadora?

Solicitar corrida.

Ok, alguns estão bravos comigo porque chamei de funcionalidade, e não de tema ou épico. Mas se realmente você esta preocupado com a terminologia utilizada, você não entendeu nada do que estou falando.

Chame do que você quiser: Épico, tema, macro funcionalidade, funcionalidade…

O importante é entender o conceito.Ok?

Escolhida a funcionalidade chave.

Em nosso exemplo do problema das férias do RH, vamos chamar a funcionalidade chave de: Solicitação de férias através do colaborador


5. Definição de agenda para realizar a sessão

Avise antecipadamente(normalmente utilizo uma semana de prazo) todos os envolvidos.

Informe:

  • tema
  • data
  • horário
  • duração da sessão em horas, deixe claro os intervalos
  • regras para interrupções/uso de smartphone/internet
  • local
  • nome da sala
  • fone/email/whatsapp para contato rápido

E dois dias antes do sessão, envie um lembrete a todos. Invista na comunicação intensa de seus projetos!


6. Apoio de um sponsor

Conselho básico, muitas vezes esquecido.

Proximidade com este sponsor, venda a ideia pra ele, forme uma parceria no sentido mais amplo da palavra.

Que este sponsor seja politicamente forte, afinal nem tudo se resume a utilização de abordagens ou lindos post-its coloridos, precisamos de resultados reais e mensuráveis!

O apoio deste sponsor é fundamental para iniciação do projeto, e durante a caminhada, os possíveis problemas que surgirão.

Mantenha um dialogo constante e franco.

Ao final da sessão de prototipagem, devemos ter um entendimento claro sobre a funcionalidade e o alinhamento entre todos os envolvidos.


Dica Extra

Não adianta nada utilizar todas estas dicas, e não construir o produto de forma incremental o mais breve possível com uso intenso de feedback.

#boraprototipar

#foconousuariofinal

#prototipandorequisitos

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

Design Features – Detalhando funcionalidades de forma colaborativa

Olá!

Quantas vezes você já presenciou um cenário, onde uma “pequena funcionalidade”, acaba se transformando em um conjunto enorme de funcionalidade? Esta situação é muito comum, e normalmente algo muito simples, parece inclinado a ganhar musculatura de forma desordenada!

Claramente, isto não ocorre de maneira proposital. Simplesmente, quando iniciam o aprofundamento das discussões, começam a aparecer as ramificações, fruto de diferentes atores envolvidos

Acredito que eu tenho visto este novela, diversas vezes! Bem que eu poderia ter contado.

Pensando um pouco nisso, resolvemos unir alguns artefatos que utilizamos no dia a dia para identificar e detalhar Features de forma ágil, leve e colaborativa.

Desta união surgiu o roteiro passo a passo: Design Features – Detalhando funcionalidades de forma colaborativa.

Este roteiro normalmente, tem duração máxima de 7(sete) horas úteis e com extremo foco, um time de entrega: Product Owner, Lider técnico, usuário final(ou representante) e facilitador.

Antes de iniciar uma sessão de Design Features, você precisa ter muito claramente entre todos os participantes, qual deve ser a funcionalidade alvo.

Além de pensar nos participantes, existe uma agenda prévia que precisa ser cumprida, com o intuito de facilitar a logistica, alinhamento, reforçar a importância do foco extremo, comprometimento e disposição física e mental dos envolvidos. Imagina algum destes participantes, apenas comparecer, sem a devida energia para produzir, poderia comprometer o resultado.

Vamos pensar em um exemplo que esta em nosso dia a dia:

Download de series do Netflix:

Veja quantas ações e ramificações tem envolvidas:

  1. Além do Download em si
  2. Cancelar download
  3. Expirar download
  4. Renovar Download
  5. Meus downloads
  6. Lista de downloads em andamento
  7. Assistir episodio que esteja baixado
  8. Próximo episodio baixado
  9. Limpar lista de downloads
  10. Validar download

Algumas macro atividades de uma sessão de Design Features:

  • Alinhamento
  • Mapa das funcionalidades
  • Canvas Feature
  • Prototipação
  • Checklist

Imagine uma ferramenta, que propicia alto grau de alinhamento entre: Product Owner, Desenvolvedor e/ou Lider Técnico e usuário final(ou representante)!

Design Features, é mais uma ferramenta do movimento “Prototipando requisitos”

Em breve estaremos falando mais sobre este assunto!

#boraprototipar

#prototipandorequisitos

#FernandesLima

Desafios na coleta de requisitos de softwares

Olá! Quanto tempo hein!

Realizamos algumas pesquisas para entender melhor quais seriam os desafios na coleta de requisitos de softwares.

Fizemos uma pergunta aberta-> Quais são seus maiores desafios na coleta de requisitos de softwares?

Após receber dezenas de respostas, listamos abaixo sem nenhuma classificação:

1.Extrair as (REAIS) necessidades do cliente

2.Disponibilidade dos envolvidos

3.Obter detalhes importantes

4.Definir o que é essencial

5.Alinhamento

6.Identificação de stakeholders relevantes

7.Comprometimento dos envolvidos

8.Prazos insuficientes

9.Estabelecer um bom fluxo de coleta e organização

10.Detalhamento incompleto

11.Falta de objetivos claros

12.Falta de priorização

13.Dificuldade de comunicação

14.Excesso de demandas

15.Equipe insuficiente

16.Ambiente Multiprojeto

E você, quais dos desafios acima você tem enfrentado?

Desafios na coleta de requisitos de softwares