Arquivo PDF: 2018 1 Estrutura do TCC – ARTIGO CIENTÍFICO – Leonardo Matsumota
RESUMO
Este trabalho aborda a aplicação das técnicas Lean Inception, Lean UX e Agile (Scrum) para criar um modelo de experimentação enxuto e contínuo afim de validar hipóteses de produtos no mercado. As principais fases da Lean Inception são: escrever a visão do produto, o produto é/não é/faz/não faz, descrever as personas, features, revisão técnica e de negócio, exibir as jornadas de usuário, priorizar as features e construir o MVP Canvas. Com a determinação dos MVPs – features para o sistema de admissão de candidatos, o desenvolvimento do sistema dar-se-á com o uso do Scrum (framework ágil), trabalhando com ciclos adaptativos de forma iterativa e incremental. Este planejamento e inspeção frequentes visam reduzir as incertezas e riscos do projeto, devido a adequação de escopo e frequente validação das entregas. Por fim, utilizamos a Lean UX (user experience) como guia para o processo de experiência do usuário, ajustando o sistema de acordo com o aprendizado obtido com as técnicas Vision, Framing, and Outcomes; Collaborative Design, etc.
Palavras-chave: MVP. Métodos Ágeis. UX. Lean Inception. Design Thinking.
ABSTRACT
This paper approach the use of Lean Inception, Lean UX and Agile (Scrum) to create a lean and continuous experimentation model to validate product hypotheses in the market. The main phases of Lean Inception are: writing the product vision, the product is / is / does / does not, describe the personas, features, technical and business review, display user journeys, prioritize the features and build the MVP Canvas. With the determination of the MVPs – features for the candidate in admission system, the development of the system will be through the use of Scrum (agile framework), working with adaptive cycles in an iterative and incremental way. This frequent planning and inspection is intended to reduce project uncertainties and risks, due to the suitability of scope and frequent validation of deliveries. Finally, we use the Lean UX (user experience) as a guide to the user experience process, adjusting the system according to the learning achieved with the techniques Vision, Framing, and Outcomes; Collaborative Design, etc.
Keywords: MVP. Agile. UX. Lean Inception. Design Thinking.
INTRODUÇÃO
Com a evolução tecnológica acelerada e a transformação digital nos negócios, os usuários encontram cada vez mais opções de produtos disponíveis e ferramentas que auxiliam na hora da compra, como por exemplo, a avaliação de outros usuários.
Porém, com menos tempo e fidelidade às marcas, os usuários deparam com um alto volume de conteúdo na web, que precisam de relevância para conquistá-los e assim propiciar uma boa experiência ao longo da jornada de compra naquela plataforma. É necessário mostrar o seu valor para o consumidor!
E para isso, as empresas precisam compreender melhor seus pensamentos e atitudes, conectando-se a seus valores. A horizontalização auxilia neste aprendizado sobre o consumo, pois os usuários fornecem informações para a empresa, criando uma relação com os produtos e os serviços que adquire.
O Marketing 4.0 destaca a humanização da marca, o marketing de conteúdo, a experiência omnichannel e a estratégia dos 5 A’s – estratégia de exposição da empresa, desde a atenção até a advocacia da marca (KOTLER, Philip). Veja o modelo proposto na Figura 1.

Figura 1 – 5A’s
Fonte: http://www.sebraemercados.com.br/marketing-4-0-oportunidades-e-tendencias-kotler-2017/
Outro ponto é adotar um modelo extremamente dinâmico para criar produtos e validar hipóteses no mercado, como os testes A/B por exemplo. Também viabilizar o time-to-market, trabalhando com entregas contínuas e criando MVPs (Minimum Viable Product) para validar as principais premissas do negócio.
Entre as principais vantagens do MVP:
- Reduzir riscos de mercado, pois os investimentos vão de acordo com a aceitação dos usuários
- Validação de hipóteses
- Experimentação e aprendizado
- Geração de valor acelerada
- Avaliar a escalabilidade do produto
O modelo Build-Measure-Learn Feedback Loop é uma efetiva abordagem para desenvolvimento de startup, melhorando continuamente a criação de produtos, serviços e ideias com ótimo custo-benefício (RIES, Eric).
A figura 2 demonstra o ciclo de criação e teste de hipóteses, começando pequeno para clientes potenciais, medindo suas reações e aprendendo com os resultados. O objetivo é evoluir o produto para entregar exatamente o valor esperado para o cliente.
Figura 2 – Build-Measure-Learn Feedback Loop
Fonte: http://theleanstartup.com/principles
E como ter uma abordagem criativa para criação de produtos? O Design Thinking busca de forma colaborativa (pessoas colocadas no centro do desenvolvimento do produto) encontrar soluções inovadoras para os problemas. O foco é em necessidades do mercado, e não em pressuposições estatísticas.
A abordagem Double Diamond no DT auxilia a compreender os clientes e seus problemas, utilizando dois diferentes tipos de pensamento:
- Divergente: pensamento amplo, considerando qualquer ideia.
- Convergente: pensamento estreito, identificando e focando em um ou dois dos principais problemas e soluções.
Figura 3 – The Double Diamond
Fonte: https://medium.com/seek-blog/
Boa parte das soluções em plataformas digitais consideram o desenvolvimento de software para construir o produto ou estruturar o suporte do negócio. Operar em nível avançado com práticas DevOps habilita o processo de entrega contínua de valor aos usuários e mantém os ambientes de produção mais estáveis, provendo credibilidade a marca.
Já a governança destes projetos com métodos ágeis, enfatiza a criação de times disciplinados focados em maximizar o valor para o cliente. O modelo ágil difere do tradicional por trabalhar com processos empíricos, realizando uma pequena quantidade de trabalho para adquirir experiência (iteração). Utiliza-se ciclos adaptativos de forma iterativa e incremental.
O processo empírico planeja frequentemente e JIT (just in time). Há inspeção frequente dos resultados. O planejamento tradicional usa técnicas para determinar prazo e custo no início do projeto, porém em um sistema adaptativo complexo, conforme o cone da incerteza (figura 4), quanto mais cedo, maiores são as incertezas.
Figura 4 – Cone da Incerteza
Fonte: https://agilemomentum.files.wordpress.com/
1 Validação de hipóteses
Lean Inception
A Lean Inception é utilizada para os times que precisam desenvolver iterativamente um MVP, escolhendo as funcionalidades que tenham valor aos usuários, com base em premissas obtidas em testes. É uma técnica que corrobora o entendimento do que é preciso para criar um produto de sucesso (CAROLI, 2017).
Não substitui sessões de ideação, pesquisa de clientes, revisão de arquitetura ou análise de competitividade. Aplicável a grandes projetos, trabalha orientada a Lean, com iterações e testes, descobrindo funcionalidades que tenham valor aos usuários. Em pequenas organizações, como startups, utilize para validar ideias com MVPs e evoluir para um produto de software.
1.1.1 Write the product vision
Esta atividade auxilia a definir colaborativamente a visão do produto, que é a essência do valor de negócio do produto e a mensagem convincente aos usuários.
- Escreva o template de visão do produto em um quadro branco ou flipchart para que o time veja facilmente.
- Divida o time em grupos menores e peça que todos preencham os slots disponíveis.
- Junte o resultado de cada grupo e consolide as informações.
O roteiro de criação da visão do produto:
For [final client],
whose [problem that needs to be solved],
the [name of the product]
is a [product category]
that [key-benefits, reason to buy it].
Different from [competition alternative],
our product [key-difference].
Figura 5 – Product Vision
1.1.2 The product is – Is not – Does – Does not
Explicar o produto descrevendo o que ele não é facilita a exploração e entendimento do que será criado. Esta atividade ajuda a explicar o produto, formando um consenso sobre o produto faz e o que ele não faz.
- Divida o flipchart em quatro áreas: Is / Is not / Does / Does not.
- Escreva o nome do produto acima dos quadrantes
- Incentive os participantes a descreverem o produto com post-its nas áreas correspondentes.
- Leia e agrupe anotações similares.
Figura 6 – The product is – is not – does – does not
1.1.3 Describe the Personas
A persona representa o usuário no sistema, descrevendo seu papel e necessidades. Nosso propósito é criar uma representação realística do usuário, ajudando a descrever as funcionalidades do ponto de vista de quem terá interação com o produto final.
- Divida o time em pares ou trios. Entregue um template de personas para cada grupo.
- Peça que cada grupo crie uma persona, utilizando o template como referência.
- Cada grupo apresenta suas personas para o time inteiro.
- Divida novamente o time em diferentes grupos e repita os passos acima.
É importante realizar esta atividade em grupo, repetindo quantas vezes necessário. Se há a criação de muitas personas, podemos combinar e priorizá-las. Os stakeholders que conhecem os objetivos do projeto devem participar ativamente de tudo isso, auxiliando o time a identificar as personas e revisando suas descrições.
Figura 7 – Describe the persona A
Figura 8 – Describe the persona B
1.1.4 Discover the Features
Descreve a interação do usuário com o produto (da forma mais simples possível) ou algumas ações que o produto deve realizar.
- Colocar os objetivos do produto como títulos de coluna em um feature canvas único. Priorizar os objetivos da esquerda para a direita, de cima para baixo.
- Colocar as personas como títulos de linhas, priorizando de cima para baixo.
- Todos devem sugerir funcionalidades e colocá-las nas discussões. Utilize as personas e os objetivos para guiarem a discussão. A principal questão é: “o que o produto precisa fazer para que esta persona alcance seu objetivo”.
Figura 9 – Discover the features
* embora o canvas pareça uma matriz, não necessariamente teremos uma funcionalidade para cada combinação de objetivo e persona. Podemos ter várias funcionalidades para uma persona atingir um objetivo específico. Também ter personas que não precisam de uma funcionalidade para um determinado objetivo.
1.1.5. Technical and Business Review
É feita uma avaliação das features em termos de esforço, valor e incerteza. Utilizaremos o canvas que desenvolvemos durante a sessão Discover the Features. Para o esforço e valor do negócio, anotamos as features utilizando marcações na escala de um, dois ou três.
Figura 10 – Effort and business value
Fonte: https://martinfowler.com/articles/lean-inception/tech-and-business-review.html

Figura 11 – Technical and business review
Classificamos a feature considerando aspectos técnicos de desenvolvimento (technical certainty) e aceitação do negócio (business agreement). Combinamos as duas classificações de acordo com o nível de incerteza: vermelho (alto), amarelo (médio) e verde (baixo). Se a feature estiver na parte inferior esquerda da tabela, marque com um “X”, pois não é aplicável ao MVP.
Figura 12 – Business Agreement x Technical Certainty
Fonte: https://martinfowler.com/articles/lean-inception/tech-and-business-review.html
Figura 13 – Business Agreement x Technical Certainty (Admission)
1.1.6 Show the User Journeys
Descreve a sequência de passos que o usuário percorre para atingir seu objetivo. Algum destes passos representam pontos de contato com o produto, demonstrando como o usuário interage com ele. O time levanta questões e alternativas sobre os desejos dos usuários e capacidades do produto.
- Selecione a persona
- Identifique um objetivo para esta persona.
- Escreva em post-it e coloque no topo à esquerda do
- Defina o ponto de partida e coloque em post-it no canvas. Questões de apoio: Como a persona começa seu dia? O que desperta a vontade de atingir seus objetivos?
- Descreva cada passo em sequência no post-it e coloque no canvas. Continue planejando os passos até a persona atingir seu objetivo.
Figura 14 –User journey
1.1.7 Display Features in Journeys
Neste ponto temos uma lista de features que o produto deve ter, e as jornadas do usuário indicam como serão as interações com o produto. Integraremos então as duas perspectivas. Coloque as principais jornadas e features visíveis e lado a lado. Faça cada jornada, e para cada etapa, registre as features de que precisa.
Figura 15 – Features in journey
Algumas jornadas estão faltando features: para isso, criamos cartões de feature, marcando o esforço, valor e incerteza. Algumas features não estão mapeadas na jornada: devemos desafiá-las, realmente precisamos se não participam das jornadas de nossos usuários?
1.1.8 Sequence the Features
Agora temos condições de trabalhar no primeiro MVP e nas iterações seguintes. Fazemos isso, definindo a Features Sequencer.
- Crie a Features Sequencer template (geralmente um flipchart com linhas numeradas)
- Explique as regras da Features Sequencer *
- Lembre todos do objetivo da atividade: definir a sequência de entrega das features do produto. O objetivo do MVP é aprender a cada iteração construindo um MVP que permitirá testar se o business case é efetivo.
- Todos devem colocar feature cards no sequencer, movendo eles enquanto exploramos as opções, até chegarmos a um acordo.
- O resultado mostra as features para cada iteração do MVP.
* as regras são: uma linha contém no máximo três features; uma linha não pode ter mais de uma feature com cartão vermelho (alta incerteza); cada linha deve ter ao menos um cartão verde (baixa incerteza); a contagem do esforço não pode adicionar mais que 5 Es; a contagem do valor deve somar pelo menos 4 $.
Figura 16 – Sequence the features
1.1.9 Build the MVP Canvas
Agora temos todo o conhecimento para construir o artefato final (MVP canvas) em cada iteração do MVP que definimos em Sequence the Features. O princípio é design centrado no usuário, considerando usuários e suas jornadas. Devemos trabalhar em ações que melhorem ou simplifiquem suas vidas e desenvolvendo hipóteses que podem testar o MVP.
- Visão do MVP: o que estamos tentando aprender?
- Declaração de resultado: o que acreditamos que este MVP irá alcançar? O que esperamos aprender?
- Métrica para validação de hipóteses de negócio: como você sabe quando pivotar e quando perseverar? O que determina sucesso ou falha? Quais dados devemos coletar?
- Personas e Plataformas: identificamos um grupo menor de personas que estaremos focando nesta iteração.
- Jornadas: revisão dos resultados de Show the User Journeys e Display Features in Journey.
- Features: relacionar as features para o MVP.
- Custos e prazos: em relação as features do MVP.
Figura 17 – MVP I
Figura 18 – MVP II
2 UX (USER EXPERIENCE)
Utilizamos o Lean UX (user experience) como guia para o processo de experiência do usuário. Trata-se de uma evolução do design do produto, com intensa colaboração e cross-functional. O shared understanding é o engajamento contínuo do time para falar sobre o que funciona (não apenas documentos e features), obtendo feedbacks do mercado. Devemos mensurar o que funciona, aprender e ajustar.
Em geral, Lean UX aborda três frentes:
- Facilita o entendimento como uma mudança de processo para designers
- É um mindset que nos permite abordar o trabalho de novas formas
- Também é um pensamento sobre gerenciamento de software
Entre os princípios do Lean UX estão:
- Cross-Functional Teams: várias disciplinas envolvidas na criação do produto.
- Small, dedicated, colocated: manter os times pequenos (até 10 pessoas) dedicados a um projeto para melhorar a comunicação, foco e ambiente de trabalho.
- Progress = Outcomes, not Output: features e serviços são outputs; atingir os objetivos de negócio são outcomes.
- Problem–Focused Teams: atribuição de um time, que ao invés de trabalhar em features, ficará dedicado a resolução do problema. Desperta o senso de ownership.
- Small Batch Size: mantém o inventário baixo e de alta qualidade. Evita um grande inventário de ideias não testadas e não implementadas.
- Continuous Discovery: processo contínuo de engajamento do usuário durante o processo de design e desenvolvimento.
- GOOB – The new user-centricity: “getting out of the building” significa que as respostas devem ser buscadas fora do escritório, em marketplace, por exemplo.
- Shared understanding: conhecimento evoluído (do coletivo) sobre o ambiente, produto e usuários.
- Anti-pattern: Rockstars, Gurus and Ninjas: Lean UX defende a mentalidade baseada em time. Evite perfis que possam afastar a colaboração.
- Externalizing your work: utilize quadros, lembretes, etc. para manter um ambiente propício a ideias e inspiração de outras pessoas.
- Making over analysis: há mais valor em criar a primeira versão de uma ideia do que dedicar metade de um dia debatendo em reuniões.
- Learning over Growth: foco em aprendizado primeiro; escalar em segundo.
- Permission to fail: para encontrar a solução do negócio, o time precisa experimentar ideias. Muitas destas ideias irão falhar, por isso crie a cultura da experimentação.
- Getting out of the deliverables business: documentos não resolvem o problema do usuário, bons produtos sim. O time deve estar focado em trabalhar nas features com maior impacto para os usuários, medindo a reação do mercado em relação a qualidade do produto.
A área de Vision, Framing, and Outcomes descreve como mudamos radicalmente a forma de trabalho, tendo como objetivo a criação de outcomes, e não somente entregáveis. Para isso, algumas ferramentas são utilizadas na confirmação da hipótese, tais como Business Assumptions Worksheet, Hypotheses (utilização do roteiro para confirmação da hipótese), Subhypotheses (quebra da hipótese em partes menores), Outcomes, Personas (uso da Proto-Personas e Persona Format para moldar quem estará utilizando) e Features.
O Collaborative Design aborda o processo de design com técnicas familiares, mas com ênfase no trabalho colaborativo. O objetivo inicial é a velocidade, priorizando o aprendizado e o uso do MVP como ferramenta chave. Entre as principais técnicas estão: Design Studio (coloca o time cross-functional para trabalhar juntos e visualizar potenciais soluções para o problema) e Style Guides (accessible, continually improved e actionable).
Em MVPs and Experiments, os experimentos são utilizados para validar hipóteses no mercado e criar produtos baseado no aprendizado. E assim trabalhar na criação do MVP com ou sem protótipos. Com protótipos, existe o low-fidelity para expor ao time o senso de como o produto deve funcionar. Já mid and high-fidelity possuem mais detalhes e testam designs em nível de interação, visual e conteúdo similar a experiência do produto final.
Por fim, o Feedback and Research trabalha com inputs dos usuários (contínuos feedbacks) que contribuem para o processo de design, incorporando a iterações de produtos. As principais técnicas são: pesquisa contínua (Continuous Discovery) e colaborativa (Collaborative Discovery), artefatos de teste (Sketches), incorporar a opinião do usuário no ciclo Lean UX (static wireframes, mockups, prototypes), uso de testes A/B e reconciliar feedback de diferentes fontes.
3 GERENCIAMENTO ÁGIL
Embora o Lean UX tenha uma recomendação de integração com o Agile, vamos trabalhar com as práticas do framework ágil Scrum para execução do backlog e validação dos produtos que serão desenvolvidos com base nas técnicas citadas anteriormente. O Scrum é fundamentado no empirismo, empregando uma abordagem iterativa e incremental para melhorar a previsibilidade e controle de riscos.
Teremos quatro eventos formais para inspeção e adaptação da Sprint: Planning, daily, review e retrospective. O time será composto do time de desenvolvimento, Product Owner (PO) e Scrum Master (SM). O PO é o responsável por gerenciar o backlog do produto, enquanto o SM é um servo-líder para o time e o time de desenvolvimento realiza o trabalho de entregar uma versão usável do produto (incremento).
A Sprint é um time-boxed de dez dias úteis (em nosso caso) de trabalho para entregar a versão incremental potencialmente utilizável do produto. A Sprint Planning é a reunião colaborativa, que define o backlog a ser feito na Sprint. A Daily possui apenas 15 minutos e serve como inspeção do trabalho desde o dia anterior e o trabalho a ser feito até a próxima Daily.
A Review, executada no final da Sprint, promove a colaboração para identificar ajustes no backlog do produto. E a Retrospective inspeciona o próprio time e cria um plano de melhorias a serem aplicadas na próxima Sprint.
Sendo assim, o backlog do produto relaciona tudo que o produto deve ter, os itens selecionados para a Sprint junto ao plano para entregar o incremento do produto e atingir o objetivo da Sprint são chamados de backlog da Sprint. Por fim, o incremento representa todos os itens completados nas Sprints.
As práticas como burndown e burnup são representações usadas para prever o progresso. Embora muito úteis, não substituem a importância do empirismo e das reuniões mencionadas que contribuem para a inspeção e adaptação do projeto.
4 CONSIDERAÇÕES FINAIS
A competitividade no mercado digital propõe inúmeros desafios as empresas que precisam adotar um modelo dinâmico de criação produtos, entregando valor ao usuário e uma boa experiência nesta jornada de compra. Neste estudo, avaliamos as técnicas Lean Inception, Lean UX e Agile (Scrum), com o propósito de criar MVPs (Produto Mínimo Viável) e validar hipóteses no mercado. A experimentação e o aprendizado serviram como direcionadores de investimentos no negócio.
As três técnicas em conjunto contribuíram para criar um modelo de experimentação enxuto e contínuo, trabalhando desde a concepção do produto Admission (sistema de captação de candidatos para converter em matriculas) até a implementação de novas funcionalidades em produção. Escrevemos então a visão do produto, o que ele é e o que ele não é, as personas, jornadas, features e priorizamos de acordo com o valor para o negócio e dificuldade técnica.
Considerando a UX (experiência do usuário) e os feedbacks como imprescindíveis para aprender e ajustar a criação, mudança ou adequação de produtos. O gerenciamento ágil efetiva o time-to-market e o produto idealizado é executado em Sprints (time box de 2 semanas), conforme priorização do backlog. O backlog possui as atividades necessárias para desenvolvimento do produto acordado nas sessões. As reuniões diárias (dailys), retrospectiva, review e a demo são utilizadas para inspecionar o progresso do desenvolvimento e ajustes necessários.
REFERÊNCIAS
CAROLI, Paulo. Direto ao ponto: criando produtos de forma enxuta, 2015.
Design Thinking: ferramenta de inovação para empreendedores. Disponível em: <https://endeavor.org.br/tecnologia/design-thinking-inovacao/>. Acesso em: 19 jun. 2018.
Design Thinking 101 – The Double Diamond Approach. Disponível em: <https://medium.com/seek-blog/design-thinking-101-the-double-diamond-approach-ii-4c0ce62f64c7>. Acesso em: 19 jun. 2018.
GOTHELF, Jeff; SEIDEN, Josh; Lean UX: Applying Lean Principles to Improve User Experience.
Lean Inception. Disponível em: <https://martinfowler.com/articles/lean-inception/>. Acesso em: 07 mai. 2018.
Marketing 4.0: do Tradicional ao Digital, passo a passo. Disponível em: <https://novaescolademarketing.com.br/marketing/marketing-4-0/>. Acesso em: 13 mai. 2018.
Marketing 4.0 – Oportunidades e Tendências. Kotler 2017. Disponível em: <http://www.sebraemercados.com.br/marketing-4-0-oportunidades-e-tendencias-kotler-2017/>. Acesso em: 15 mai. 2018.
Metodologias Ágeis. Disponível em: <https://agilemomentum.wordpress.com/>. Acesso em: 25 jun. 2018.
MVP: entenda as principais vantagens ao utilizá-lo. Disponível em: <http://blog.justdigital.com.br/mvp-entenda-as-principais-vantagens-ao-utiliza-lo/>. Acesso em 23 mai. 2018.
MVP: guia completo do Produto Viável Mínimo. Disponível em: <https://saiadolugar.com.br/mvp/>. Acesso em: 24 mai. 2018.
MVP: O que é e como fazer o produto mínimo viável? Disponível em: <https://conteudo.startse.com.br/para-startups/isabella/mvp-produto-minimo-viavel/>. Acesso em 24 mai. 2018.
RIES, Eric. Lean Startup. Crown Publishing Group, 2011.
Scrum.org. Disponível em: <https://www.scrum.org/>. Acesso em: 02 jul. 2018.
The Differences: Lean Startup vs Agile Methodology. Disponível em: <https://cabforward.com/the-differences-between-lean-startup-and-agile-methodology/>. Acesso em: 14 jun. 2018.
The Lean Startup. Disponível em <http://theleanstartup.com/principles>. Acesso em 11 jun. 2018.
UX Canvas. Disponível em: <https://ucdc.therectangles.com/#why>. Acesso em: 22 mai. 2018.