Em meio a tantas buzzwords, o mercado vai criando e disseminando conceitos, abordagens e boas práticas, ao mesmo tempo também criando e reinterpretando conceitos. As vezes termos caem no gosto da galera e suas reinterpretações acabam por dar outro sentido ou mesmo distorcendo o entendimento do que é o que.
Pretótipo – É uma representação simplista daquilo que queremos produzir, podendo se utilizar de papelão, papel, sucata, desenhado com canetões, Lego, etc. Sem entrar em detalhes, você pode testar ideias novas e inovadoras em um tempo muito curto para encontrar aquelas com maior probabilidade de sucesso. É possível imaginar pretotipar em algumas horas a ideia de um Google Lens, um Samsung dobrável, de forma simples. Tenho um post bem elucidativo em 2015 quando descobri que tinha até manifesto – https://jorgeaudy.com/2015/07/04/pretotyping-fazer-de-conta-as-vezes-e-tao-eficiente-quanto-ser/
Protótipos de baixa, média e alta – https://brasil.uxdesign.cc/hackeando-a-prototipagem-29b8abab5f01
Protótipo de baixa – No mundo físico, como um óculos ou um celular, fazer um protótipo de baixa definição é bem diferente de um pretótipo simples. Mas se a conversa é um software ou processo, os dois convergem para as mesmas técnicas, um draft, storyboard simples, uma encenação gravada ou presencial, desenho das telas, sendo uma representação visual simples com o objetivo é validar aspectos gerais, deixando para detalhar após sua validação conceitual. Previsto em oficinas de Design Thinking, produzido na escala de minutos, uma vez ajustado e aprovado, orientará um protótipo de alta definição;
Protótipo de alta – É uma representação fiel de uma parte ou do todo que queremos produzir, via de regra utilizando ferramentas ou materiais afeitos para prototipação. No mundo real remete iconicamente a protótipo de automóveis, peças únicas e fiéis ao que representam. No mundo dos softwares são o resultado de modelagens realizadas a partir de pesquisas e ideações, uma técnica colaborativa que uso para insumo é um UX Dojo, que terá depois o trabalho de designer ou UX para confecção fidedigna. Em software temos o Framer, Figma e outras ferramentas, o próprio Miro possui bibliotecas para prototipação.
POC ou Prova de conceito – https://gobacklog.com/blog/proof-of-concept/
POC (Proof of Concept) no Lean Startup – O conceito de provas de conceitos nascem com as startups, envolvendo um teste de viabilidade do produto ou serviço no mercado. Desta forma, envolve uma demonstração prática (superficial ou incompleta) para a obtenção de feedbacks, envolvendo pesquisas de campo, focus groups, mas sempre relacionadas à viabilidade da ideia ou hipóteses junto ao mercado. Pode acontecer se utilizando de pretótipos ou protótipos, o foco é a apresentação e levantamento de opiniões sobre uma ideia, produto ou serviço.
POC (Proof of Concept) em software – O conceito de POC para um projeto de software muda da busca por uma confirmação de hipóteses de mercado para a descoberta e definição de tecnologias mais eficazes e eficientes para o desenvolvimento do produto. A prova irá anteceder o desenvolvimento com o uso daquela tecnologia em questão, analisando os meios antes de iniciar o desenvolvimento propriamente dito. Assim, oportuniza explorar tecnologias emergentes e fornecer evidência de conceito, através de pesquisas com o objetivo de provar que é viável – https://www.entrepreneur.com/article/307454
MVP, MMF, MMP e produto – É um equivoco curioso hoje chamarem tudo isso de MVP, tem um post de 2018 que gosto muito: https://www.jeremyjarrell.com/mvp-validates-need/
MVP – Creio que 90% daquilo que o mercado chama de Mínimo Produto Viável, não é! MVP pressupõe um desenvolvimento parcial, incompleto, minimamente possível e necessário que permita a validação de alguns dos principais pressupostos ou hipóteses. Logo, chamar algo de MVP sem consequente espaço ou tempo para apresentação, experimentação, feedbacks, mas ao invés disso tratar-se de uma entrega de parte do produto já 100% funcional e com entrada imediata em uso NÃO é MVP, é uma release, pequena eventualmente, mas uma Release funcional. Há várias alegorias para MVP, a da fatia do bolo, a do skate, a do cortador de grama, … – https://jorgeaudy.com/2017/07/03/entender-a-essencia-de-mvp-voce-precisa/
MMF – Uma mínima funcionalidade comercializável é o menor conjunto possível de funcionalidades, que por si só, já teria valor para o mercado. Em hipótese, poderíamos lançar uma primeira versão de um software com apenas uma destas funcionalidades e mesmo assim se veria algum benefício. Previsivelmente, é mais que um MVP que é criado para validar hipóteses sem o compromisso de se ter funcionalidades operacionais, e é menos que um MMP, posto que não possui a pretenção de oferecer já um produto comercializável e que per si pretensamente atendem um conjunto de funcionalidades complementares.
MMP – Um produto mínimo comercializável é uma versão mínima do produto já pronta para o mercado, contendo um conjunto mais importante de recursos necessários de forma a permitir a prospects e clientes já conseguirem usar de fato um mix de funcionalidades que agregam valor na prática a eles. Conceitualmente, o maior beneficiado em um MVP é o seu idealizador que irá validar hipóteses de valor para seu cliente, mas de uma forma em que o cliente ainda não se beneficiará na prática. O maior beneficiado de um MMP já é o cliente, o cliente do cliente, seus usuários e operadores, posto que já entrega um grupo de funcionalidades de valor – https://www.classicinformatics.com/blog/minimum-marketable-product-after-mvp
Piloto – Um projeto piloto é um esforço temporário empreendido para testar a viabilidade de uma exclusiva solução de sistema apresentada. Um piloto tem data de início e fim previstas, com objetivo claro e definido, um conjunto de pessoas envolvida, exigindo preparação, implantação e acompanhamento do início ao fim, via de regra visando a confirmação dos benefícios esperados para um Go-No Go da própria solução, de novo piloto ajustado ou rollout (conclusão do piloto e início de uma implantação em maior escala). Não só teremos feedbacks de ideias e percepções, mas a validação na prática de uso da solução, processos e ferramentas.
Spike – É uma estratégia usada para determinar quanto trabalho será necessário para resolver ou contornar um problema de software a partir de um estudo técnico mais aprofundado de parte(s) do mesmo. Pode ser usado como uma forma de familiarizar a equipe com o software em geral ou analisar um problema específico. Uma distinção pode ser feita entre avaliar o impacto da nova tecnologia na implementação atual, outro é analisar e compreender como foi feita uma parte da solução atual e estimar o esforço necessário para tanto.
Beta – É aquela versão em estágio final de desenvolvimento, mas que é considerada aceitável para ser lançada para uma amostra pré-definida de seu público, sob inscrições ou seleção, sob um contrato com ciência de riscos e confidencialidade. É ciente que podem haver instabilidades, problemas que precisarão ser reportados, corrigidos, até que a versão comercial esteja realmente concluída com esta ajuda dos betatesters. É possível explorar esta estratégia com adesão singular das equipes de publicidade e marketing.
Release Plan – Sob um enfoque de Small Projects Philosophy, jamais voltaremos a ter novamente grandes projetos, mas grandes programas (conjunto de projetos sob coordenação) compostos por vários projetos pequenos. Chamamos Release Plan aquele planejamento de pacotes entregáveis com partes funcionais em condições de serem utilizadas pelos clientes, entretanto, é cada vez mais comum que em um planejamento de releases tenhamos também MVP e MMP prévios a uma primeira release mais funcional, assim como podemos utilizar estratégias de Betas e piloto antes de ganhar o mundo.
MODELO STARTUP QUEST
Talvez minha contribuição com o modelo “Startup Quest“ possa ajudar de alguma forma. É para ser um modelo didático, por isso está organizado da seguinte forma: A esquerda temos 6 (seis) forças motrizes, ao centro um ciclo de 4 (quatro) disciplinas, a direita uma espiral com 7 (sete) etapas evolutivas, passível de inícios, validações, reinícios, pivots e crescimento,
A essência do modelo está em uma espiral, onde a cada giro definimos a estratégia mais adequada para aquele momento, a partir do problema que queremos resolver, uma ideia ou percepção de solução, diferentes protótipos, a modelagem, MVP, MMP e produto evolutivo, …
Eu pensei muito sobre explicitar o Lean Startup, mas Steve Blank e Eric Ries não são um ciclo ou passo, são o mindset, o customer development é a base para todo o modelo, está implícito na espiral, a cada giro, a cada pivot ou evolução … Lean Startup não precisa estar explícito, é o ar que nos oxigena.
Jorge Horácio "Kotick" Audy 