Engenharia de Software Moderna

​

Artigos Didáticos - Parte I

​

Processos & Requisitos

​

​

1

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides

Temas dos artigos

1. Squads
2. Shape Up
3. MVPs
4. Product Discovery
5. Design Thinking e Jobs to be Done

​

2

Engenharia de Software Moderna

​

Organizando Times de Desenvolvimento de Software em Squads

​

Prof. Marco Tulio Valente

​

https://engsoftmoderna.info/artigos/squads.html

3

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides

Times Ágeis ou Squads

• Pequenos (entre um time de basquete e de futebol)

​

4

Squads

• Multidisciplinares
• Autônomos
• Auto-organizáveis
• Mínimo de dependências para outros times
• Responsabilidade fim-a-fim por uma missão específica ("mini-startups")
• Estruturas permanentes

5

Questões pendentes

• Quais os tipos possíveis de times?
• Como escalar esses times?

6

Nosso foco: squads de desenvolvimento de software. Ou seja, squads de infraestrutura, marketing, vendas, RH estão fora do nosso foco.

​

Problema #1: Tipos de Squads

​

7

Tipo principal de squad

​

• Squads de produto (90% dos squads)
• Clientes de tais squad são usuários finais do sistema

​

8

Exemplo: squads de produto em um sistema de comércio eletrônico

​

• Squad de Catálogo
• Squad de Pesquisa de Produtos
• Squad de Recomendação de Produtos
• Squad de Checkout
• Squad de Pagamento
• Squad de Entrega
• etc

9

Outros tipos de squads (~10%)

• Squads responsáveis por componentes
• Squads responsáveis por plataformas
• Squads facilitadores de boas práticas
• Squads responsáveis por objetivos de negócio

​

​

10

Clientes são

squads de produto

Como você classificaria esse squad?

Druid is a real-time analytics database designed for fast slice and dice analytics on large datasets

https://blog.twitter.com/engineering/en_us/topics/infrastructure/2022/powering-real-time-data-analytics-with-druid-at-twitter

Como você classificaria esse squad?

​

The Twitter experimentation tool, Duck Duck Goose (DDG for short), was first created in 2010.

https://blog.twitter.com/engineering/en_us/a/2015/twitter-experimentation-technical-overview

Carga Cognitiva

• Carga cognitiva: “preocupações dos times”
• Logo, podemos pensar que existem dois grupos de times:
• Times de Produto
• Times cuja finalidade é diminuir a carga cognitiva dos times de produto, isto é: componentes, plataformas, consultoria, etc.

​

13

​

Problema #2: Como escalar esses times?

​

14

Modelo Spotify (2012)

• Framework para escalar times ágeis
• Framework ⇒ não precisa ser adotado “by the book”
• Escalar ⇒ organização com centenas de devs
• Popularizado por dois vídeos:
• https://youtu.be/Yvfz4HGtoPc
• https://youtu.be/vOt4BbWLWQw

​

15

16

Modelo Matricial

• Estruturas verticais: squads e tribos
• Estruturas horizontais: chapters e guildas
• Ou seja, todo dev tem dois líderes:
• Líder da tribo: foco no negócio
• Líder do chapter: foco na parte técnica e na carreira

​

17

Tribo

• Conjunto de squads que:
• Trabalham na mesma parte do produto
• Ou que atendem a uma mesma persona
• No máximo: ~100 membros
• Em empresas muito grandes:
• Alianças ou unidades de negócio: conjuntos de tribos

​

18

Exemplo: tribos de um banco digital

• Cartão de crédito
• Conta bancária
• Pagamentos
• Investimentos
• Seguros
• etc

​

19

Chapter

• Grupos de profissionais de uma mesma tribo e com as mesmas competências
• Exemplo: frontend, backend, mobile, UX designers,etc

​

20

Guildas

• Grupos de pessoas com interesses comuns
• Exemplo: métodos ágeis
• Estruturas informais, participação voluntária, etc
• Membros podem ser de tribos diferentes

​

21

Fonte: Spotify guilds: how to succeed with knowledge sharing in large-scale agile organizations, IEEE Software, 2019.

​

Pergunta/Discussão

​

Por que as empresas valorizam tanto esses modelos de organização de times?

​

23

Lei de Conway (1968)

• Arquitetura de software espelha a arquitetura da organização

​

​

24

squad

squad

squad

squad

squad

squad

squad

squad

squad

squad

squad

squad

micro

serviço

micro

serviço

micro

serviço

micro

serviço

micro

serviço

micro

serviço

micro

serviço

micro

serviço

micro

serviço

micro

serviço

micro

serviço

micro

serviço

​

Exercícios

​

25

• Qual a principal semelhança entre squads de plataformas e squads facilitadores de boas práticas? E também qual é a diferença principal entre esses squads?
• Suponha uma organização que organiza seus squads em componentes arquiteturais. Ou seja, ela possui squads que implementam componentes front-end e outros squads que implementam componentes back-end. Discorra sobre o principal problema desse tipo de organização de squads.
• Descreva uma desvantagem do Modelo Spotify.
• Suponha uma empresa de entrega de comida online. Descreva pelo menos três tribos que essa empresa poderia usar para organizar seus squads. Basta descrever o objetivo de cada tribo.

26

Engenharia de Software Moderna

​

Shape Up: Uma Possível Alternativa a Scrum?

​

Prof. Marco Tulio Valente

​

https://engsoftmoderna.info/artigos/shape-up.html

27

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides

Motivação

• Scrum e XP: propostos na década de 90
• Kanban: proposto em meados de 2000
• Pergunta: existe algum método mais novo?

​

28

Processo de desenvolvimento da Basecamp (2019)

29

https://basecamp.com/shapeup

Duas tracks (em paralelo)

1. Track de shaping
2. Track de desenvolvimento: ciclos + cool down

30

Track de Shaping

31

Track de Shaping

• Track de especificação de requisitos
• Objetivo: produzir um conjunto de pitches
• Pitch: especificação leve de requisitos e design

32

Pitches: Solução de meio termo

• Mais detalhados do que histórias de usuários
• Menos detalhados que especificações tradicionais de requisitos

33

Observação

• Em Shape Up, pitch não tem nada a ver com pitch de vendas ou "elevator pitch"

34

Estrutura de um Pitch

• Descrição do problema
• Esboço da solução (sketches ou protótipos de telas)
• No go’s (o que não precisa ser implementado)
• Rabbit holes (especificação de certos detalhes para evitar que o time fique perdido ou perca tempo)

35

Exemplos de Pitches

36

Exemplo de Pitch

Exemplos de No Go’s

Exemplos de Rabbit Holes

Shaping (cont.)

• Quem são os "shapers"?
• Gerentes sêniores de produto
• No caso da Basecamp: 4 pessoas
• Escrita de forma assíncrona (trilha paralela de shaping)
• Reunião final para decidir os pitches do próximo ciclo
• Um dos membros é o decisor (tem a palavra final)

41

42

Shaping

Desenvolvimento

Ciclo

Cool

Down

Ciclo

Cool

Down

Ciclo

Cool

Down

pitches

pitches

reunião

reunião

Ciclo

Cool

Down

Ciclo

Cool

Down

Ciclo

Cool

Down

Ciclo

Cool

Down

Ciclo

Cool

Down

Ciclo

Cool

Down

3 times

Track de Desenvolvimento

43

Track de Desenvolvimento: ciclos + cool down

Shaping

Desenvolvimento

Ciclo

Cool

Down

Ciclo

Cool

Down

Ciclo

Cool

Down

pitch

pitch

reunião

reunião

Ciclos

• Duração: 6 semanas
• Mais longos do que sprints de Scrum
• Mas podem existir ciclos de duas semanas

45

Times

• Menores que os times ágeis normais
• 2 devs + 1 designer
• Autonomia:
• Implementar pitches
• Definir horários de trabalho, reuniões, daily, etc

46

Basecamp está reduzindo o tamanho de seus times

47

Over the past few years, the number of people who work here has continued to grow, but we've downsized our product teams from three to two. At 37signals, both Basecamp and HEY are built by multiple teams of two using our Shape Up process. No feature takes more than 6 weeks to build, and each feature is assigned a maximum of two people: one designer and one programmer. And in more than a few cases, it may just be one person.

https://world.hey.com/jason/just-the-two-of-us-afb2f54e

Cool Down

• Duração: 2 semanas
• Tempo para os devs "respirarem"
• Corrigir bugs, refatorar, pagar dívida técnica, estudar

48

Shape Up: Resumo

• Ideias interessantes:
• Pitches: mais detalhados do que histórias de usuários
• Track de shaping: liderada por um time de experts
• Cool down
• Ideias ainda não totalmente comprovadas:
• Times pequenos ou muito pequenos
• Pode valer a pena experimentar algumas dessas ideias

​

49

​

Exercícios

​

50

1. Qual a diferença entre a fase de shaping e o planejamento do sprint (sprint planning) em Scrum?

​

2. Qual a principal característica que torna Shape Up um método adequado para times remotos?

​

3. Pense em um pitch para um problema ou sistema. Descreva brevemente um “no-go” ou um “rabbit hole” (você escolhe) que deveria ser documentado neste pitch.

Engenharia de Software Moderna

​

O que é – e também o que não é – um MVP?

​

Prof. Marco Tulio Valente

​

https://engsoftmoderna.info/artigos/mvp.html

52

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides

Conceito de MVPs: tremendo sucesso!

53

Lançado em 2011

MVP

• MVP = experimento para testar uma ideia
• Hipótese:
• Minha ideia tem valor? Ela é útil?
• Os clientes vão usá-la? Vão pagar por ela?
• Objetivo de um MVP: descobrir se sua hipótese é verdadeira, de forma rápida e com o menor custo

​

54

Contexto de incerteza

• MVP é indicado para contextos de incerteza
• Não temos certeza se nossa ideia é viável
• Logo, ela pode falhar, mas que seja então:
• Uma falha rápida
• Uma falha com um prejuízo pequeno

​

55

Alguns Tipos de MVP

1. Landing page
2. Mágico de Oz
3. Concierge
4. Simple App

​

​

​

56

(1) MVP Landing Page

• Validação bem inicial, apenas para capturar “leads”
• Tipo muito simples e menos poderoso de MVP

​

57

https://buffer.com/resources/idea-to-paying-customers-in-7-weeks-how-we-did-it/

Exemplo

(2) MVP Mágico de Oz

• Backend manual (mas cliente não sabe disso)
• Exemplo: EasyTaxi

​

​

59

(3) MVP Concierge

• Atendimento todo manual
• Sem nenhuma automação, nem no front, nem no backend
• Você se apresenta para o cliente e se oferece para resolver o problema dele
• Exemplo: sistema de caronas para alunos da UFMG
• Primeiro MVP: processo manual via grupos do WhatsApp

​

​

​

60

Exemplo de MVP Concierge: Airbnb

• Fundadores começaram alugando três colchões infláveis no próprio apartamento onde moravam em San Francisco
• Aproveitaram uma conferência que ia ocorrer na cidade para atrair os hóspedes
• Cuidaram de receber os hóspedes, pagamento, etc

​

​

​

61

(4) MVP do tipo “Simple App”

• Exemplos anteriores não envolvem um sistema com frontend e backend
• Porém, nada impede que você tenha um MVP com:
• Um frontend simples
• Um backend simples

62

MVP “Simple App”

• Exemplo: Meta’s Threads (concorrente do Twitter)

​

63

• Sem versão Web
• Sem hashtags
• Sem trending topics
• Sem DMs
• Sem timeline cronológica
• Sem edição de posts

Julho 2023

Algumas perguntas sobre MVPs

​

​

64

Preciso me preocupar com qualidade de código?

65

Preciso me preocupar com qualidade de código?

• Normalmente, ainda não.
• Ou seja, ainda não é o momento de ser preocupar com:
• Testes automatizados
• Integração contínua
• Padrões de projeto
• Refatorações

​

66

Quanto tempo leva para construir um 1o MVP?

67

Quanto tempo leva para construir um 1o MVP?

• Depende e varia muito…
• Mas tem que ser rápido
• Uma semana ou 10 dias
• Duas semanas, no máximo

​

68

Usuários têm que pagar para usar o MVP?

69

Usuários têm que pagar para usar o MVP?

• Sim, é importante exigir “comprometimento” dos usuários
• Maior elogio de um cliente: “informar o cartão de crédito”

​

70

MVP é apenas para startups?

71

MVP é apenas para startups?

• Não, MVPs é para testar ideias cuja viabilidade não é clara
• Exemplo:
• UFMG pode estar enfrentando um problema X
• Para resolvê-lo, pensamos em construir um sistema Y
• Porém, não temos certeza de que Y vai dar certo

​

72

Duas confusões que são comuns

​

​

73

1. MVP ≠ 1a versão de um produto

74

MVP é um experimento (logo, pode falhar)

• Ou seja:
• Se existe um mercado certo
• Se o cliente já te contratou e vai te pagar
• Se você tem competência para desenvolver
• Se o cliente sabe muito bem o que quer
• Logo, não existe risco e não precisamos de MVP
• Se já sabemos que vai dar certo, não é um experimento

​

75

(2) Definição do termo pivô

​

• Um ciclo de validação de um MVP pode ter 4 resultados:
• MVP → falhou, vamos desistir
• MVP → sucesso, “Product Market Fit”
• MVP → MVP + pequenos ajustes para um novo ciclo
• MVP → MVP + grandes ajustes para um novo ciclo

76

Pivô

MVP1

MVP2

MVP3

MVP4

pivô

Validação

Market Fit

Produto

MVP1

MVP2

MVP3

pivô

Validação

Market Fit

Desistimos!

Comparação com pivô em basquete

Pivô ≠ restart

80

Tipos comuns de pivôs

• Zoom-in (uma feature específica vira um produto)
• Segmento de clientes
• Aplicação para Plataforma
• Tecnologia

81

Zoom-in: Flickr

• Início: "online massive multiplayer role-playing game"
• Feature para jogadores compartilharem fotos fez muito sucesso e virou o Flickr
• Fickr: sistema para hospedagem e compartilhamento de fotos

​

82

Zoom-in: Slack

• Caso parecido com o do Flick
• Slack é um aplicativo de mensagens usado por empresas
• Também "saiu" de um jogo de RPG online

​

​

83

Segmento de Clientes: Twitch

• Objetivo: transmissões ao vivo (streaming)
• Público inicial: amplo (justin.tv)
• Depois: gamers (twitch.tv)

84

Aplicação para Plataforma: Shopify

• De: uma loja online para alugar produtos para esquiar
• Para: uma plataforma para hospedar lojas online

85

Tecnologia: Android

• De: sistema operacional para câmaras
• Para: sistema operacional para celulares

86

​

Exercícios

​

87

1. Nos seus primeiros dez anos de vida, a Netflix era uma empresa que entregava DVDs fisicamente pelo correio, já tendo nessa época centenas de milhares de assinantes. Então, em 2007, a empresa migrou para o serviço de streaming, tal qual usamos hoje. Você classificaria essa mudança como um pivô? Sim ou não? Justifique sua resposta.

​

2. Suponha que você planeja abrir uma empresa para entrega de comida pela Internet, em BH, e pretende, portanto, concorrer com empresas estabelecidas e conhecidas do ramo. A criação de um MVP seria recomendada nesse contexto? Sim ou Não? Justifique sua resposta.

​

3. Descreva um tipo de domínio (ou aplicação) para o qual é mais difícil e desafiador criar um MVP. Justifique sua resposta.

Engenharia de Software Moderna

​

Product Discovery: Uma Breve Introdução

​

Prof. Marco Tulio Valente

​

https://engsoftmoderna.info/artigos/product-discovery.html

89

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides

Perguntas não respondidas por Scrum (clássico)?

• Como escalar os times?
• Uma resposta: Modelo Spotify
• Como começar quando o risco é alto?
• Uma resposta: MVPs
• Como gerenciar o fluxo de demandas de features?
• Uma resposta: atividades de product discovery

​

90

Dois tipos de empresas de software

• Projeto
• Produto

​

91

Empresas de projeto

• Consultorias, agências, fábricas de software
• Trabalham para um cliente, com um contrato
• Cliente normalmente sabe o que quer…
• Desenvolvem sistemas internos de tais clientes
• Desenvolvimento tem início, meio e fim
• Workshops de inception, histórias de usuários, etc
• Cenário típico das décadas de 1990 e 2000

​

92

Empresas de produto

• Empresas dirigidas por software e que nasceram digitais
• Principal produto: um software
• Desenvolvimento perpétuo: nunca termina…
• Ficaram populares nos últimos 10-20 anos

​

93

Requisitos vs Hipóteses

Requisitos

• Funcionalidades obrigatórias
• Cliente tem certeza de que o sistema deverá ter essa funcionalidade
• Faz mais sentido em projetos de software
• Atividade: especificação de requisitos
• Responsável: analista de requisitos (Waterfall) ou PO (Scrum)

​

95

Hipóteses

• Muitas vezes, o cliente não sabe o que quer
• Mais comum em empresas de produto (milhões de clientes)
• Nestes casos, o termo requisito não faz muito sentido
• Por isso, costuma-se usar o termo hipótese
• Hipótese: achamos que o sistema deveria ter essa funcionalidade, mas não temos certeza
• Atividade: Product Discovery
• Responsável: Product Manager (PM)

96

Product Discovery

• Atividades realizadas com o objetivo de descobrir o que de fato deve ser implementado.
• Dada uma hipótese, descobrir se ela é:
• Verdadeira ⇒ vai para o backlog do produto
• Falsa ⇒ descartada e não perdemos mais tempo

97

Product Discovery

• Objetivo: validar hipóteses
• Como?
• Entrevistas com usuários
• Protótipos: figma, papel, navegáveis
• Sessões de validação com usuários
• Até MVPs (no caso de funcionalidades maiores)

​

98

Comparando com Waterfall e Scrum

• Waterfall: analista de requisitos levanta completamente e inicialmente o que os clientes querem
• Scrum: PO define e prioriza as histórias; fica disponível para explicá-las verbalmente durante o sprint
• Discovery:
• Não temos mais tanta certeza (“requisitos”)
• Mas temos hipóteses, que precisam ser validadas

99

Problemas evitados com Product Discovery

• Times e PO perderem o controle do backlog
• Sistemas lotados de features, de pouco valor e uso

100

Figura meramente

ilustrativa

Como “plugar” Product Discovery em Scrum e Kanban

Dual Track Scrum

Discovery

Delivery

histórias de usuários

backlog do sprint

tempo

​

Backlog do

Produto

​

Negócio

Clientes

sprint

funcionalidades

Ideias, problemas, hipóteses

Upstream

Kanban

Trabalho sendo preparado

Downstream

Kanban

​

Trabalho em andamento

Backlog

Quadro do upstream

Quadro do downstream

Recomendações de Leitura

104

​

Exercícios

​

105

1. Além de ter sido feita com a mãe do entrevistador, qual o principal problema com a seguinte entrevista? (próxima página)

​

2. Descreva quatro perguntas mais importantes que o entrevistador deveria ter feito na entrevista anterior.

​

Son: Mom, mom, I have an idea for a business — can I run it by you?

Mom: Of course, dear.

Son: You like your iPad, right? You use it a lot?

Mom: Yes.

Son: So would you ever buy an app which was like a cookbook for your iPad?

Mom: Hmmm.

Son: And it only costs $40 — that’s cheaper than those hardcovers on your shelf.

Mom: Well...

Son: And you can share recipes with your friends, and there’s an iPhone app which is your shopping list. And videos of that celebrity chef you love.

Mom: Oh, well yes honey, that sounds amazing. And you’re right, $40 is a good deal. Will it have pictures of the recipes?

Son: Yes, definitely. Thanks mom — love you!

​

Fonte: The Mom Test: How to talk to customers & learn if your business is a good idea

Boas Práticas para Entrevistas (fonte: Deploy Empathy)

• Deixe o entrevistado falar a maior parte do tempo (90%)
• Use um tom de voz gentil e amigável
• Use pausas, para forçar o entrevistado a falar
• O expert é o entrevistado
• Não interrompa e nunca corrija o entrevistado
• Use palavras e termos simples

108

Boas Práticas para Entrevistas

• Peça clarificações, mesmo quando não precisar
• Use mirroring e sumários. Exemplo:
1. Entrevistado: "Hoje foi um dia cansativo, tive 10 reuniões."
2. Entrevistador: "Puxa, muito cansativo ter 10 reuniões!"

109

Boas Práticas para Entrevistas

• Não explique suas intenções e nunca fique na defensiva
• Pergunte sobre comportamentos, hábitos e gastos atuais ou passados.

110

Número e duração das entrevistas (fonte: Deploy Empathy)

• Número de entrevistas: 5
• Ou então: pare, quando começarem a se repetir
• Duração:
• 15 a 30 minutos
• Dependendo do problema: 1 hora

111

Engenharia de Software Moderna

​

Design Thinking: Principais Conceitos e Atividades

​

Prof. Marco Tulio Valente

​

https://engsoftmoderna.info/artigos/design-thinking.html

112

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides

Motivação

• Temos um problema complexo e desafiador
• Não temos uma ideia de como resolvê-lo…
• Não temos ideia de um possível MVP
• Pode ser que a solução não inclua software

113

Exemplos de Problemas

• Universidade: como aumentar a participação dos alunos nas aulas online?
• Editora: como aumentar o faturamento?
• Hospital: como melhorar o atendimento dos pacientes?
• Hotel: como aumentar a ocupação nos finais de semana?

114

Design Thinking

• Abordagem muito conhecida para solução de problemas
• Não apenas por meio de software
• Inspirada em técnicas usadas por designers (desde 1960)
• Promessa: gerar soluções criativas e inovadoras
• Condução sempre por equipes multidisciplinares

115

Principais Atividades

• Inspiração
• Ideação
• Implementação

116

Inspiração

• Antes de mais nada é importante entender o problema
• Como?
• Visitar os locais
• Entrevistar usuários
• Observar usuários (estudos etnográficos)
• No limite, se passar por um usuário

117

Inspiração: algumas técnicas

• Observar e conversar com usuários extremos
• Reframing: reformular o problema

​

118

Reframing

https://hbr.org/2017/01/are-you-solving-the-right-problems

Reframing

https://hbr.org/2017/01/are-you-solving-the-right-problems

Reframing

https://hbr.org/2017/01/are-you-solving-the-right-problems

Ideação

• Atividade de geração e teste de ideias
• Pensamento divergente e convergente

​

122

Ideação: Prototipação

• Protótipos (mesmo que de baixa fidelidade)
• Storyboards

​

123

Exemplo de Protótipo: Cozinhas do McDonalds

• Na década de 40, antes de criar o McDonalds, os fundadores da empresa fizeram várias experiências com plantas de cozinha desenhadas com giz em uma quadra de tênis.

124

Fonte: The Founder movie, https://www.youtube.com/watch?v=F-7cjdtrQ9Y

Implementação

• Após decidir por um protótipo “vencedor”, parte-se para a sua implementação

​

125

Comentário Final

• Design Thinking é um processo aberto e criativo
• Atividades não são sequenciais:
• Pode-se voltar para uma atividade anterior
• Repetir o ciclo
• Atividades não tem duração pré-estabelecida
• Equipe não tem tamanho e participantes pré-estabelecidos

126

Design Sprint

​

https://engsoftmoderna.info/cap3.html#construindo-o-primeiro-mvp

127

Design Sprint

• “Design Thinking” com regras mais claras
• Time-box: uma semana (2a a 6a feira)
• Equipe: multidisciplinar
• 7 pessoas
• Incluindo um tomador de decisões e um facilitador

128

2016

Design Sprint

129

https://www.thesprintbook.com/the-design-sprint

Convergir Divergir Convergir

(objetivo) (soluções) (solução)

Engenharia de Software Moderna

​

Jobs to be Done (JTBD) Aplicado a Produtos de Software

​

Prof. Marco Tulio Valente

​

https://engsoftmoderna.info/artigos/jobs-to-be-done.html

130

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides

Jobs to be Done (JTBD)

• Teoria que explica porque clientes compram um produto
• Clayton Christensen e colegas (2005)

131

JTBD: Ideia Central

• Contratação não é explicada pelas funcionalidades de um produto ou software
• Mas pelos “trabalhos” (jobs) que clientes precisam realizar
• “Trabalhos”: demandas, necessidades, anseios, etc

132

Perguntas importantes em JTBD

• Por que os clientes contratam nossos produtos?
• Em quais circunstâncias?
• Quais os problemas eles querem resolver?
• Qual o progresso eles querem alcançar?

​

133

Exemplo: Milk-shakes matinais

• McDonalds vendiam muitos milk-shakes no início da manhã
• Entrevistas ⇒ clientes trabalhavam em outra cidade
• “Contratavam” os milk-shakes para o seguinte “trabalho”: tornar a viagem menos tediosa
• Como evoluir o produto milk-shake?
• Drive-through, suporte para viagem, etc.

​

134

Exemplo: iPod (2001)

135

job to be done

​

Resumo Visual

​

​

136

137

Problema

Complexo

Não-estruturado

Negócio

Dinâmico

138

Problema

Solução

Design Thinking

139

Problema

Solução

Design Thinking

Inspiração:

• Entrevista e observação de usuários
• Se passar por um usuário
• Reframing
• Atenção aos usuários extremos

​

Ideação:

• Pensamento Divergente
• Pensamento Convergente
• Prototipação e Testes

Relação entre DT e Discovery

140

141

Problema

Solução

Design Thinking

Discovery

Delivery

Backlog

sprints

sprints

sprints

sprints

…

Relação entre DT e MVPs

142

143

Problema

Design Thinking

Solução

144

Problema

Design Thinking

Solução

MVP

Solução

145

Problema

Design Thinking

Solução

MVP

Solução

Discovery

Relação entre DT e JTBD

146

147

​

Cliente

(no centro)

​

solução 1

solução 2

solução 3

solução n

Design Thinking

148

Cliente

(no centro)

Jobs to Be Done

solução

melhora um aspecto concreto da jornada do cliente

Trabalhos que o cliente realiza no seu dia a dia

​

Exercícios

​

149

1. Pense em um problema que possa se beneficiar do uso de Design Thinking:

1. Descreva brevemente esse problema.
1. Descreva três soluções para o mesmo.
2. Escolha uma solução para ser prototipada. Como seria esse protótipo? Quem iria testá-lo?

​

​