Rafael Motta de Carvalho
A metodologia Lean Startup para negocios
digitais: Um estudo de caso
Monografia apresentada ao curso de gra-duacao em Ciencia da Computacao da Uni-versidade Estadual do Norte FluminenseDarcy Ribeiro como requisito para obtencaodo tıtulo de Bacharel em Ciencia da Com-putacao.
Orientadora:
Profª. Drª. Annabell del Real Tamariz
Universidade Estadual do Norte Fluminense Darcy RibeiroLaboratorio de Ciencias Matematicas
Campos dos Goytacazes - RJ
2016
Rafael Motta de Carvalho
A metodologia Lean Startup para negocios digitais:Um estudo de caso
Monografia apresentada junto ao Cursode Ciencia da Computacao, da Univer-sidade Estadual do Norte FluminenseDarcy Ribeiro – Campos / RJ, comorequisito para obtencao do tıtulo deBacharel em Ciencia da Computacao.Orientadora: Profª. Drª. Annabell delReal Tamariz.
COMISSAO EXAMINADORA
Profª. Drª. Annabell del Real TamarizOrientadora - Universidade Estadual do
Norte Fluminense Darcy Ribeiro
“Eu nao falhei, encontrei 10 mil solucoes que nao davam certo.”
Thomas Edison
“O insucesso e apenas uma oportunidade pra recomecar de novo com mais inteligencia.”
Henry Ford
“Se as coisas nao estao dando errado, voce nao esta inovando o suficiente.”
Elon Musk
“Nao importa o quao forte possa bater, mas sim o quanto pode levar golpes e continuar
em frente.”
Rocky Balboa
1
AGRADECIMENTOS
Aos meus pais por me educarem desde sempre com incansavel dedicacao e paciencia,
e tambem por me ensinarem que “excessos trazem retrocessos” e que “quem com porco
se mistura, farelo come”.
Aos meus irmaos de sangue Rodrigo e Thiago por serem otimas referencias na formacao
de minha personalidade, assim como os irmaos Luan, Bruno e Betinho, os quais de alguma
forma sempre estarao presentes na minha vida.
A minha namorada Marianna, pela incrıvel sabedoria emocional, sempre equilibrando
compreensao, incentivos e crıticas pra me ajudar com questoes pessoais, profissionais e
academicas.
Aos amigos, e eternos socios, Max, Hugo e Eduardo por participarem tao ativamente
na minha formacao profissional.
A professora Annabell, pela amizade, ensinamentos e pelo papel de mae na maior
parte da minha vida academica.
Ao professor Rivera pela dedicacao na criacao do curso de Ciencia da Computacao da
UENF.
A todos os colaboradores que fizeram e fazem parte da Algorich pelo companheirismo,
dedicacao e respeito.
2
Resumo
Esse trabalho apresenta uma aplicacao dos conceitos do Lean Startup em um empreen-dimento de tecnologia chamado GoPages, que oferece uma solucao para desenvolvimentode sites simples de forma automatizada, baseada em conteudos publicos em redes sociais.
Para que o estudo fosse viabilizado, o autor fez um levantamento das informacoesobtidas desde a idealizacao, passando pela construcao do software em si, ate o momentoem que este tomou uma forma diferente da inicial, deixando de ser um produto oferecidoaos clientes. Foram feitas analises do desenvolvimento do negocio com uma otica doautor, que teve participacao direta em sua elaboracao utilizando-se dos conceitos de LeanStartup de forma nao enviesada por este trabalho.
O primeiro passo foi a etapa de descoberta do cliente, na qual o primeiro modelodo negocio foi definido pelos socios. Seguido pelo levantamento de hipoteses e entao aconstrucao de um menor produto viavel, que apresenta as principais propostas da empresapara o mercado. Esse produto foi planejado, construıdo e colocado a disposicao de clientesreais, oferecendo a equipe aprendizados sobre as verdadeiras necessidades do mercado,mantendo um custo de operacao extremamente baixo.
O resultado apresentado e a analise detalhada da aplicacao da metodologia, extraıdasde um modelo de negocios que teve hipoteses validadas e outras refutadas por intencoesreais de compra e utilizacao do produto.
3
Abstract
This paper presents an application of Lean Startup concepts in a technology projectcalled GoPages, which offers a solution for automated simplistic website development,using public content in social networks.
In order to make the study feasible, the author describe information obtained fromthe idealization through the construction of the software itself, until it took a differentform from the initial, being no longer a product offered to customers. Analyzes of thedevelopment of the business with an optic of the author were made, that had directparticipation in its elaboration using the concepts of Lean Startup in a way not skewedby this work.
The first step was the customer discovery, which the first business model was definedby the company partners. Then, followed by the hypothesis survey and the construction ofa minimum viable product, which presents the company’s main proposals for the market.The product was designed, built and offered to real customers, providing learning aboutthe true needs of the market while maintaining an extremely low operating cost.
The results presented is the detailed analysis of the methodology application, extrac-ted from a business model that had validated and refuted hypotheses by real intentionsof purchase and use.
4
Sumario
Resumo 2
Abstract 3
Lista de Figuras 6
1 Introducao 7
1.1 Objetivos e justificativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Organizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Lean startup 12
2.1 Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.2 Desperdıcio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.3 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Fundamentacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Lean manufacturing . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Design thinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.3 Desenvolvimento do cliente . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.4 Agile development . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.4.1 Programacao Extrema . . . . . . . . . . . . . . . . . . . . 20
2.2.4.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5
2.3 Tecnicas propostas pela metodologia Lean Startup . . . . . . . . . . . . . 26
2.3.1 O ciclo Construir-medir-aprender . . . . . . . . . . . . . . . . . . . 26
2.3.2 Menor produto viavel . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.2.1 Qualidade de um MVP . . . . . . . . . . . . . . . . . . . . 29
2.3.3 Implantacao contınua . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.4 Testes A/B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.5 Pivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3 Estudo de caso 39
3.1 Objeto de estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2 Aplicacao das tecnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.1 O ciclo Construir-medir-aprender . . . . . . . . . . . . . . . . . . . 43
3.2.1.1 Levantamento de hipoteses . . . . . . . . . . . . . . . . . 45
3.2.2 Menor produto viavel . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.3 Pivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4 Conclusoes 53
4.1 Aspectos positivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Aspectos negativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Referencias 57
6
Lista de Figuras
1 Ciclo de gestao de um projeto SCRUM . . . . . . . . . . . . . . . . . . . . 26
2 Ciclo construir-medir-aprender . . . . . . . . . . . . . . . . . . . . . . . . . 27
3 Menor produto viavel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 A piramide de desenvolvimento de um MVP . . . . . . . . . . . . . . . . . 31
5 Comparacao do ciclo de desenvolvimento sem e com implantacao contınua 32
6 Comparacao entre integracao contınua, entrega contınua e implantacao
contınua. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7 Pagina principal do GoPages . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8 Trecho de site gerado pelo MVP do GoPages . . . . . . . . . . . . . . . . . 49
9 Trecho de site gerado pelo GoPages apos pivo . . . . . . . . . . . . . . . . 52
7
1 Introducao
O sucesso de empresas como Google, Facebook e WhatsApp motivou, e continua moti-
vando, muitos empreendedores a criarem seus proprios negocios digitais sedentos pelos
mesmos resultados. Alem disso, a crescente facilidade de acesso a internet, a reducao dos
custos com infraestrutura e o grande crescimento de tecnologias de codigo aberto criou um
ambiente fertil para o surgimento de empresas deste perfil. Essa combinacao de fatores
contribuiu para reacelerar o mercado de investimentos para um nicho que havia reduzido
devido as consequencias da chamada Bolha da internet no inıcio dos anos 2000.
Esse cenario propiciou o surgimento de um grande numero de startups de negocios
digitais avidas pelo sucesso, capazes de criar software de qualidade e muitas vezes acom-
panhadas de grandes investidores. Entretanto, de acordo com o Startup Genome Report
(MARMER, 2011) cerca de 90% das startups quebram apos poucos anos de operacao. Isso
mostrou que pra muitos empreendedores o desafio nao e saber se seu produto pode ser
desenvolvido, mas se ele e vendavel para um publico que garanta sua sustentabilidade
economica.
Diversas tecnicas tradicionais de administracao de empresas sao difundidas e utilizadas
para tracar estrategias economicas e aumentar suas chances de sobrevida. Defende-se
que um planejamento bem detalhado, uma estrategia solida e uma pesquisa de mercado
completa provavelmente irao levar uma empresa ao sucesso. Num ambiente de mercado
relativamente estatico como o de industrias texteis, alimentıcias ou o mercado de varejo
fısico, esse tipo de planejamento tradicional e factıvel e preciso. Sob essas condicoes, e
inquestionavel a alta chance de sucesso de empresas que seguem a rigor as metodologias tao
aperfeicoadas durante decadas de estudos por engenheiros de producao e administradores.
Entretanto, os conceitos tradicionais de administracao muitas vezes encontram bar-
reiras ao serem aplicados no desenvolvimento de startups. A primeira grande diferenca
entre um negocio comum e uma startup e seu ambiente de extrema incerteza do mer-
cado. E comum que seus produtos sejam completamente inovadores, tao inovadores a
8
ponto de tornar qualquer previsao do comportamento dos clientes uma verdadeira loteria.
Outro fator e que o meio digital do qual fazem parte, por estar em constante mudanca,
eleva ainda mais esse grau de imprevisibilidade. Em poucos meses e possıvel surgir um
concorrente que entrega o mesmo valor utilizando uma tecnologia totalmente nova.
Segundo Ries (2011), um grande erro dos empreendedores e tracar um plano de
negocios excessivamente detalhado e baseado no desconhecido. Um exemplo que en-
dossa seu argumento e o plano de negocios feito pela Starmedia, de aproximadamente 300
paginas, com um estudo do mercado, estatısticas, projecoes e estimativas de receitas e
custos (VIEIRA, 2003). Apenas tres anos depois, a empresa que chegou a ser avaliada em
R$ 38 bilhoes veio a falencia.
Maurya (2012) segue a mesma linha de raciocınio que Ries, afirmando que em um
plano de negocios de uma startup assumem-se muitas hipoteses como fatos, os quais
escreve-lo em um estagio inicial de validacao de mercado e desperdıcio e ao faze-lo o
empreendedor estara utilizando de “saltos de fe”. Ou seja, tomando decisoes com base
em crencas ao inves de hipoteses validadas.
Por outro lado, Ries aponta que o extremo oposto, ou seja, a ausencia de qualquer
tipo de metodo para o planejamento de uma startup como um outro erro tradicional
dos empreendedores. Essa postura costuma ser tomada apos observarem que a adminis-
tracao tradicional nao traz resultados satisfatorios, confiando suas decisoes em intuicao e
informacoes superficiais.
1.1 Objetivos e justificativas
O objetivo deste trabalho e levantar informacoes qualitativas da aplicacao da metodolo-
gia Lean Startup atraves de um estudo de caso. Nos ultimos anos, diversas startups vem
adotando a metodologia Lean Startup por preencher justamente a lacuna entre os dois ex-
tremos ja citados: a ausencia e o excesso de planejamento. Para ser funcional mesmo num
ambiente de extrema incerteza, essa metodologia preza pelo aprendizado constante, indu-
zindo um comportamento de grande adaptabilidade pelos envolvidos no projeto. Portanto,
segundo Ries, uma startup pode ser fatorada em um conjunto de hipoteses que devem ser
validadas, ou refutadas, para confirmar se existe mercado para o produto ou servico que
ela pretende oferecer. Cada ciclo de validacao de hipotese e denominado ciclo de feedback
e e composto pelos passos “construir-medir-aprender”. Do ponto de vista da computacao,
essa tecnica se assemelha a prototipacao abordada na engenharia de software.
9
Os entusiastas dessa metodologia defendem que essa abordagem traz uma significativa
reducao de custos para o empreendedor, afinal, se uma hipotese vir a ser refutada de
forma agil, muito recurso pode ser poupado se as solucoes nelas baseadas sequer forem
implementadas. Lean Startup e um metodo empırico que propoe a reducao de desperdıcio
e validacao de hipoteses de negocio atraves de feedbacks rapidos com o cliente, aplicando
o metodo cientıfico ao ambiente de extrema incerteza que e a criacao de um novo negocio
digital (LINHARES, 2012).
Lean Startup em si nao cria inovacao, somente restringe desperdıcio, se o produto nao
for bom, ele vai continuar ruim. Isso deixa claro que o maior proposito e o provavel sucesso
dessa metodologia se deve a economia que traz para os empreendedores e investidores. A
inovacao seria no maximo facilitada devido a um direcionamento mais preciso de recursos
(GITAHY, 2011).
Portanto, para cumprir o objetivo deste trabalho, serao apresentadas as praticas pro-
postas na metodologia bem como a contextualizacao do conceito de startup e de des-
perdıcio em negocios deste tipo. Para nortear a discussao, sera utilizada como objeto
de estudo uma startup criada pelo prorio autor deste trabalho em sua empresa, com a
participacao de seus colaboradores. Em paralelo, espera-se que o referencial bibliografico
levantado sirva de referencia para profissionais e academicos que desejam propor o uso de
tecnicas de administracao mais eficientes para startups.
1.2 Metodologia
Neste trabalho utilizaremos o metodo de pesquisa conhecido como Estudo de Caso. E um
metodo qualitativo que consiste, geralmente, em uma forma de aprofundar uma unidade
individual que serve para responder questionamentos os quais o pesquisador nao tem
muito controle sobre o fenomeno estudado, e que tambem contribui para compreendermos
melhor os fenomenos individuais, os processos organizacionais e polıticos da sociedade.
Yin (2003) afirma que o fator predominante para a escolha da estrategia de estudo de
caso em contraposicao ao uso de experimentos, levantamentos de dados, pesquisa historica,
entre outros, e a consideracao da forma de questao da pesquisa, do controle exigido sobre
eventos comportamentais e do foco sobre acontecimentos contemporaneos ou nao.
No metodo do estudo de caso a pergunta de pesquisa deve estar focada em “como” e
“por que”, questoes que levam a analise da evolucao de um fenomeno ao longo do tempo
e para as quais a contagem de incidencias, por exemplo, pode nao trazer respostas.
10
E uma ferramenta utilizada para que possamos entender a forma e os motivos que
levaram a determinada decisao. Conforme Yin (2003), o estudo de caso e uma estrategia
de pesquisa que compreende um metodo que abrange tudo em abordagens especificas de
coletas e analise de dados.
Este metodo e util quando o fenomeno a ser estudado e amplo e complexo e nao pode
ser estudado fora do contexto onde ocorre naturalmente. Ele e um estudo empırico que
busca determinar ou testar uma teoria. A tendencia do estudo de caso e tentar esclarecer
decisoes a serem tomadas. Ele investiga um fenomeno contemporaneo partindo do seu
contexto real, utilizando de multiplas fontes de evidencias. Os estudos de caso podem ser:
• Exploratorios: quando se quer encontrar informacoes preliminares sobre o assunto
estudado. Para estudos de casos explanatorios, uma boa abordagem e quando se
utiliza de consideracoes rivais, em que existam diferentes perspectivas, aumentando
as chances de que o estudo seja um modelo exemplar.
• Descritivos: cujo objetivo e descrever o estudo de caso.
• Analıticos: quando se quer questionar ou produzir novas teorias que irao problema-
tizar o seu objeto, construir ou desenvolver novas teorias que irao ser confrontadas
com as teorias que ja existiam, proporcionando avancos do conhecimento.
Segundo Gil (1991), esse tipo de trabalho busca “proporcionar maior familiaridade
com o problema, com vistas a torna-lo mais explıcito”. Portanto, como o conceito de
Lean Startup e relativamente recente, este projeto cumpre um bom papel ao contribuir
para uma documentacao academica a seu respeito. Yin (2003) explica que a pesquisa
exploratoria e utilizada quando as questoes de pesquisa sao essencialmente do tipo “O
que” e “Como”, o que vai ao encontro do fato de que esse trabalho responde as questoes
“O que e Lean Startup?” e “Como o Lean Startup e eficaz para negocios digitais”,
corroborando para escolha desta forma do metodo.
E preciso que se tenha diferentes visoes teoricas acerca do assunto estudado, pois serao
a base para orientar as discussoes sobre determinado fenomeno constituem a orientacao
para discussoes sobre a aceitacao ou nao das alternativas encontradas. Por isso serao
confrontadas as praticas do Lean Startup com as tradicionais no campo da Engenharia de
Software, Engenharia de Producao e Administracao.
O estudo de caso busca investigar e tratar uma situacao especıfica, procurando en-
contrar as caracterısticas e o que ha de essencial nela. Esse estudo pode ajudar na busca
11
de novas teorias e questoes que servirao como base para futuras investigacoes.
1.3 Organizacao
Os capıtulos desta pesquisa ficaram distribuıdos da seguinte forma:
• Capıtulo 1: Nos introduz ao tema da pesquisa, abordando o objetivo e a justificativa
para tal, bem como o motivo do seu uso e o que se pode colher ao aplica-lo. Tambem
apresenta a metodologia de pesquisa utilizada.
• Capıtulo 2: Descreve o que se entende sobre Lean Startup e como essa metodologia
surgiu. Expoe em detalhes a sua estrutura e os principais conceitos utilizados para
seu desenvolvimento e aplicacao. Demonstra tambem as tecnicas elaboradas pelo
criador do metodo e os procedimentos para sua execucao.
• Capıtulo 3: Relata a jornada de aplicacao do metodo, fazendo um paralelo entre o
que a metodologia propoe e o que foi empregado em cada etapa do estudo de caso,
juntamente com as tecnicas utilizadas.
• Capıtulo 4: Conclui-se a pesquisa, oferecendo uma reflexao sobra a aplicacao da
metodologia Lean Startup, decompondo os resultados obtidos na aplicacao de forma
a evidenciar o que foi aproveitado e o que foi adaptado.
12
2 Lean startup
O livro Lean Startup foi lancado por Eric Ries em 2011, e sua traducao para o portugues
foi A Startup Enxuta. Sua concepcao teve inıcio em seu blog, lancado em 2008, cujo
objetivo era reunir as experiencias de sucesso e fracasso que ele acumulou durante anos e
com isso auxiliar outras startups que buscavam trilhar seu proprio caminho para o sucesso.
O que comecou apenas como um relato de experiencias ganhou teor academico ao
decorrer dos anos, principalmente devido a inspiracao em diversos conceitos ja difundidos
e aplicados de desenvolvimento de software, desenvolvimento de produto e engenharia de
producao. Alguns desses conceitos sao:
• Lean manufacturing
• Design thinking
• Customer development
• Agile development
Usando-se de sua experiencia e das metodologias abordadas nesses conceitos, Ries as
adapta a realidade das startups e propoe um modo de agir e pensar para os empreendedores
construirem produtos sustentaveis, o que se traduz na elaboracao de diversas tecnicas, que
serao detalhadas a posteriori, com o objetivo de:
• Aumentar a precisao no levantamento de requisitos
• Eliminar praticas de desperdıcio
• Aumentar a producao de valor durante a fase de desenvolvimento do produto
• Maximizar o aprendizado fornecido pelo feedback do consumidor
• Tornar o feedback do consumidor uma parte fundamental para o levantamento de
requisitos do produto
13
Dito isso, fica evidente que o aprendizado durante a concepcao do produto e o meio
que Ries sugere para atingir seus objetivos. Analisando de uma maneira rasa, essa e uma
estrategia em reacao a comum imprevisibilidade do mercado o qual startups pertencem.
A fim de investigar mais aprofundadamente a decisao de Ries ao tracar esses objetivos,
neste capıtulo serao contextualizadas cada uma de suas fontes de inspiracao, bem como
seus termos e fundamentos teoricos.
2.1 Terminologia
2.1.1 Startup
Com a bolha da internet e consequentemente o surgimento de diversas empresas, o conceito
de startup foi difundido e quase sempre associado a uma empresa nova, embrionaria
ou ate mesmo em fase de concepcao. O fato de serem jovens ou por vezes apenas um
projeto de empresa fazem elas serem vistas como uma verdadeira fonte de riscos. Startups
normalmente sao bastante inovadoras, em muitos casos oferecendo solucoes nunca antes
experimentadas pelos clientes. Se por um lado isso cria um ambiente de extrema incerteza,
por outro lado, em caso de sucesso, os riscos dos investidores sao recompensados com um
alto retorno financeiro.
Uma definicao exata pra startup ainda encontra divergencias. Segundo o SEBRAE
(2012), elas podem ser definidas como:
“Uma empresa nova, ate mesmo embrionaria ou ainda em fase de consti-
tuicao, que conta com projetos promissores, ligados a pesquisa, investigacao e
desenvolvimento de ideias inovadoras” - SEBRAE (2012)
Entretanto, na literatura, os principais autores sobre o tema resumem essas carac-
terısticas das startups em diferentes definicoes. Duas das mais aceitas sao:
“Uma organizacao projetada para buscar por um modelo de negocios repetıvel
e escalavel” - SEBRAE (2012)
“Uma startup e uma instituicao humana projetada para criar novos produtos
e servicos sob condicoes de extrema incerteza” - Ries (2011)
14
Ao usar o termo “escalavel”, Blank se refere a empresas que podem crescer de forma
rapida e consistente sem alterar seu modelo de negocios, de uma maneira em que o cres-
cimento nao seja diretamente proporcional ao custo de operacao. E quando ele fala sobre
“repetıvel”, se refere a empresas que oferecem o mesmo produto de forma virtualmente
ilimitada.
E importante destacar que essas definicoes nao restrigem uma startup a uma empresa
nova ou pequena. Alem disso, contrariando o senso comum, os conceitos de startup se
aplicam a uma empresa que nao tem base tecnologica. Se o produto da empresa for
inovador e ela for projetada pra enfrentar situacoes de extrema incerteza, grande risco e
tiver alto potencial de escala, ela certamente sera vista como uma startup. SILVA (2012)
corrobora com essa afirmacao ao dizer que nem toda startup e exatamente uma empresa
digital, nao obstante o ambiente digital favoreca a criacao de startups devido ao baixo
custo originado pela evolucao tecnologica.
Para o presente trabalho sera utilizada a definicao de Linhares (2012), o qual combina
as de Blank (2008) e Ries (2011):
“Uma organizacao que busca um modelo de negocios repetıvel e escalavel em
um ambiente de extrema incerteza.” - Linhares (2012)
2.1.2 Desperdıcio
De forma simples e direta, desperdıcio e tudo aquilo que nao entrega valor ao cliente.
Mas como o termo e muito presente neste trabalho e por ser extremamente generico,
faz-se necessario limitar o contexto que e utilizado. Alem disso, se tratando de um dos
principais elementos da filosofia Lean, e de grande importancia clarificar o que exatamente
esta sendo mencionado quando se refere a software.
Mary Poppendieck (2003) fizeram um paralelo entre os 7 desperdıcios catalogados pelo
modelo Toyota de fabricacao de carros e os desperdıcios no mundo do desenvolvimento de
software. Apesar de se tratar de areas um tanto distantes, a adaptacao deles e bastante
precisa:
2.1.3 Feedback
Em sua essencia, a startup e uma catalisadora que transforma ideias em produtos. A
medida que os clientes interagem com os produtos, geram feedback e dados. Segundo
15
Tabela 1: Os 7 desperdıcios de acordo com o Lean Thinking
Da manufatura Do desenvolvimento de software• Defeitos • Defeitos• Excesso de producao • Funcionalidades extras• Transporte • Troca de tarefas• Estoque • Desenvolvimento parcialmente completo• Movimento • Buscas por informacoes• Excesso de processamento • Processo desnecessario• Tempo de espera • Tempo de espera
Ries (2011) “O feedback e tanto qualitativo (por exemplo, o que gostam ou nao) como
quantitativo (por exemplo, quantas pessoas utilizam o produto e consideram que ele tem
valor)”. Portanto, o feedback e a voz que ira transmitir a percepcao do cliente e se o seu
produto caminha na direcao esperada ou nao.
Os produtos que uma startup desenvolve sao experimentos; a aprendizagem sobre
como desenvolver uma empresa sustentavel e o resultado desses experimentos. Para as
startups, tais informacoes sao muito importantes, pois podem influenciar e reformular o
proximo conjunto de ideias.
2.2 Fundamentacao
Como ja mencionado, a metodologia Lean Startup teve sua concepcao baseada em diver-
sos conceitos desenvolvidos sem uma relacao direta com startups, mas na visao de Ries
tornaram-se referencias essenciais para um empreendedor de sucesso.
Neste trabalho, pretende-se abordar cada uma das principais referencias utilizadas no
livro Lean Startup. Com isso serao apresentadas as ideias que conceberam a metodologia
e como seu autor trouxe benefıcios para a realidade das startups.
2.2.1 Lean manufacturing
Traduzıvel como Manufatura enxuta, o Lean manufacturing e uma filosofia de gestao de
producao com origem na industria automobilıstica, mais especificamente nas fabricas da
multinacional japonesa Toyota. Por esse motivo, essa filosofia tambem e chamada de
Sistema Toyota de producao. O desenvolvedor foi o executivo Taiichi Ohno no perıodo
de recontrucao da industria japonesa apos a segunda guerra mundial. Mas foi atraves
do livro “A Mentalidade Enxuta nas Empresas Lean Thinking: Elimine o Desperdıcio e
16
Crie Riqueza”, escrito por James P. Womack e Daniel T. Jones em 2004 que o termo foi
popularizado.
Segundo Jones e Womack (2004), os pontos chaves do Lean manufacturing sao:
• Qualidade total imediata: Os defeitos dos produtos desenvolvidos devem ser identi-
ficados e corrigidos durante a sua producao. Essa atitude reduziria a complexidade
envolvida no reparo e evitaria que o erro que levou ao defeito seja repetido.
• Minimizar o desperdıcio: Eliminar, ou no mınimo reduzir, as atividades ou especi-
ficacoes dos produtos que consomem recursos que nao entregam valor para o cliente
final. Esse ponto chave esta diretamente relacionado ao conceito de “7 desperdıcios”
1.
• Melhoria contınua: Defende-se que este este ponto chave deve estar presente ao longo
de toda a organizacao. Cada agente envolvido na producao deve estar focado em
reduzir custos, aumentar a produtividade e melhorar a qualidade constantemente.
As informacoes devem ser compartilhadas para que as mudancas nos processos e
nos projetos sejam realizadas continuamente.
• Producao Just in Time: E um sistema de administracao da producao que deter-
mina que nada deve ser produzido, transportado ou comprado antes da hora exata.
Pode ser aplicado em qualquer organizacao, para reduzir estoques e os custos de-
correntes. O conceito desse sistema esta relacionado ao de producao por demanda,
onde primeiramente vende-se o produto para depois comprar a materia prima e
posteriormente fabrica-lo ou monta-lo.
Desenvolvimentos posteriores do Lean manufacturing geraram o conceito de Lean
Thinking, uma linha de pensamento baseada nos mesmos princıpios, mas aplicados a
atividades diferentes da manufatura. Um exemplo oportuno das areas influenciadas foi
a de desenvolvimento de software a partir do final dos anos 90, sob a abordagem do
desenvolvimento agil 2, baseados no Manifesto Agil (BECK, 2001).
1Os “7 desperdıcios” sao definidos na literatura de gestao de empresas como: super-producao, tempode espera, transporte, excesso de processamento, inventario, movimento e defeitos
2O desenvolvimento agil, tal como qualquer metodologia de software, providencia uma estrutura con-ceitual para reger projetos de engenharia de software.
17
2.2.2 Design thinking
Design thinking e um conjunto de metodos e processos voltados para a abordagem de
questoes como a aquisicao de informacoes, analise de conhecimento e propostas de solucoes.
Tem sido cada vez mais adotado pelas organizacoes, desde industria ate o comercio
eletronico. O design como disciplina tem por objetivo maximo promover bem-estar na
vida das pessoas. No entanto, e a maneira como o designer percebe as coisas e age
sobre elas que chamou a atencao de gestores, abrindo novos caminhos para a inovacao
empresarial.
Segundo Vianna (2011) para identificar os reais problemas e soluciona-los de maneira
mais efetiva, e preciso aborda-los sob diversas perspectivas e angulos. Assim, o designer
deve priorizar o trabalho colaborativo entre equipes multidisciplinares, que trazem olha-
res diversificados e oferecem interpretacoes variadas sobre a questao e, assim, solucoes
inovadoras.
No mais, como o nome ja diz, o Design thinking se refere a maneira do designer
de pensar, que utiliza um tipo de raciocınio pouco convencional no meio empresarial, o
pensamento abdutivo3. Nesse tipo de pensamento, busca-se formular questionamentos
atraves da apreensao ou compreensao dos fenomenos, ou seja, sao formuladas perguntas
a serem respondidas a partir das informacoes coletadas durante a observacao do universo
que permeia o problema.
Para Vianna (2011), a essencia do conceito de Design thinking como uma evolucao
do tradicional processo de design e colocada nos seguintes topicos:
• Imersao preliminar: Essa etapa comeca com um processo de reenquadramento no
qual a equipe de projeto reune-se com os profissionais da empresa contratante, seja
em entrevistas individuais ou em dinamicas coletivas, para olhar o problema sob
outras perspectivas e definir as fronteiras do projeto. Alem disso, a equipe de
projeto costuma realizar uma pesquisa exploratoria em campo para ouvir sobre o
tema de forma a criar um entendimento inicial dos usuarios e atores envolvidos.
• Imersao em profundidade: A ideia e identificar comportamentos extremos e mapear
seus padroes e necessidades latentes. A pesquisa e qualitativa e nao pretende esgotar
o conhecimento sobre segmentos de consumo e comportamento, mas ao levantar
oportunidades de perfis extremos, permite que solucoes especıficas sejam criadas.
3Logica filosofica o qual se usa experiencias e conhecimentos para levantar hipoteses de solucao paraum problema.
18
Para tal, os membros da equipe de projeto vao ao encontro do cliente do produto
ou servico em questao, para observar ou interagir com ele no contexto de uso de
forma a aproximar-se de seus pontos de vista e descobrir nao so o que falam, mas
tambem o que fazem e como se sentem.
• Analise e sıntese: Os dados coletados na fase de imersao, organizados em cartoes
de introspeccoes, devem ser submetidos a uma fase de analise e sıntese, de forma a
serem organizadas e criar padroes identificaveis, dentro de uma logica que permita
a compreensao do problema em questao.
• Ideacao: E a fase onde o perfil de um publico alvo e definido, daqueles que serao
“servidos” pelas solucoes criadas, a partir de ideias inovadoras para um tema do
projeto em questao. Para tal, utiliza-se como insumo a sıntese criada a partir das
fases anteriores.
• Prototipacao: E o momento que ideias abstratas ganham conteudo formal e material,
de forma a representar a realidade capturada e propiciar a validacao de todo o
conteudo aprendido.
2.2.3 Desenvolvimento do cliente
Do termo em ingles Customer development, esta e, essencialmente, uma metodologia
para a startup encontrar o alinhamento ideal entre problema e solucao. Isso implica
numa identificacao clara do problema do cliente e uma proposta de solucao que realmente
resolva esses problemas. Esse alinhamento e o que os empreendedores denominam de
Product/Market Fit.
Este e um processo iterativo que parte da premissa de que os fatos estao fora do
ambiente de desenvolvimento. Dentro deste ambiente existem apenas hipoteses, o qual
devem ser validadas o quanto antes.
O criador da metodologia, Steve Blank, no livro “The Four Steps to the Epiphany”,
segmenta o modelo em 4 passos, que devem ser aplicados com rigor nos objetivos, mas
com flexibilidade nos metodos, de acordo com o tipo de negocio da startup.
• Descoberta de cliente: Testes das hipoteses de mercado e entendimento dos pro-
blemas dos clientes pelos fundadores, checando se o produto proposto atende essas
necessidades de forma satisfatoria. Busca responder a questao: “os clientes querem
o seu produto?”
19
• Validacao de cliente: Validacao do processo de vendas e distribuicao do produto,
onde se desenvolve um modelo de negocio replicavel e escalavel. Busca responder a
questao: “os clientes efetivamente pagam pelo seu produto?”
• Criacao de cliente: Criacao de demanda para escalar as areas de marketing e vendas.
E a etapa onde e feito o lancamento de marketing.
• Construcao de negocio: Criacao e pratica de processos para selar o fim da transicao
de uma organizacao focada no aprendizado para uma focada na execucao. E a fase
onde a empresa tem o desafio de crescer e chegar ao publico mainstream.
Observa-se que esses 4 passos podem dividir uma startup em duas fases de visoes muito
diferentes. A primeira, de aprendizado, seria composta Customer discovery e Customer
validation. A segunda, de execucao, composta pelos demais passos.
2.2.4 Agile development
Surgida em 2001 a partir de uma reuniao de dezessete especialistas mundialmente reco-
nhecidos na area de desenvolvimento de software, agile development foi uma formalizacao
de um conjunto de metodos especıficos que vinham surgindo na area. Eles decidiram
usar o termo Agilismo para descrever essa nova geracao de metodos, que passou a ser
amplamente utilizado desde entao.
Durante o surgimento dessa metodologia foi redigido o Manifesto Agil (BECK, 2001),
descrevendo um conjunto de princıpios e valores que sugerem a eliminacao dos processos
e documentos que nao trazem valor ao cliente ou ao projeto, sendo entao considerados
desnecessarios. Alem disso, sugerem processos simplificados e organizados de codificacao
com foco em qualidade e maior aproximacao com o cliente ao decorrer do projeto, trazendo
respostas rapidas as comuns mudancas dos requisitos de um software.
Portanto, em suma, Agile development e um conjunto de processos, metodologias e
princıpios de desenvolvimento de software que tem o objetivo de minimizar riscos durante
um projeto, tais como:
• Desperdıcio de tempo
• Gastos que superam o orcamento
• Consumo de tempo que supera o cronograma
20
• funcionalidades que nao resolvem os problemas dos usuarios
• Baixa qualidade dos sistemas desenvolvidos
• Cancelamento do projeto por escassez de recursos
Essa metodologia sugere uma divisao do projeto em curtos perıodos, chamados de
iteracao, os quais levam tipicamente de uma a quatro semanas. Cada iteracao passa
por todas as etapas tradicionais do desenvolvimento de software: planejamento, analise
de requisitos, projeto, codificacao, teste e documentacao. Cada iteracao esta focada em
adicionar um novo conjuto significativo de funcionalidade, sendo o suficiente para implan-
tar uma nova versao funcional do software. Finalizada a iteracao, a equipe responsavel
reavalia as prioridades do projeto e assim e feito um novo planejamento, alterando a
especificacao do projeto com base no feedback obtido.
E importante destacar que, assim como o Lean Startup, o Agile development teve bas-
tante influencia do Lean Thinking e Lean Manufacturing, o que explica essa mesma visao
de pequenos ciclos e aprendizado contınuo, alem da busca por eliminacao de desperdıcios,
obsessao com qualidade e melhoria contınua de processos.
Desde seu surgimento, os metodos ageis vem numa crescente de aceitacao dos profis-
sionais e academicos da area. Uma amostra dessa aceitacao e a propria influencia dessa
metodologia para o Lean startup, que por sua vez tambem esta sendo cada vez mais uti-
lizado. Desse legado, um princıpio que merece destaque e a proximidade com o cliente,
visto que Lean startup tem mais enfoque no levantamento de requisitos, na leitura de
feedback e analise de viabilidade do projeto do que em praticas de codificacao de software
em si.
As metodologias tradicionais de desenvolvimento de software sugerem uma abordagem
sistematica e sequencial, que comeca com a especificacao dos requisitos pelo cliente e
progride ao longo do planejamento, modelagem, construcao, e implantacao, culminando
na manutencao progressiva do software acabado (PRESSMAN, 2006).
2.2.4.1 Programacao Extrema
Do ingles “Extreme Programming” e normalmente referenciada pela sigla “XP”, este
conceito e fruto de um processo de evolucao e juncao de bons princıpios e praticas de
desenvolvimento de software, que hoje e a mais conhecida das abordagens para desenvol-
vimento de software que obedecem aos princıpios do Manifesto Agil.
21
Um marco importante em seu processo de criacao deu-se em 1996, ano em que Kent
Beck comecou a trabalhar no desenvolvimento de um grande sistema de folha de pa-
gamento, chamado Chrysler Comprehensive Compensation (Sistema de Compensacao
Abrangente da Chrysler), ou C3. Apesar do longo processo de criacao e evolucao dos
princıpios e praticas usados da XP, foi durante o desenvolvimento do C3 que Kent Beck
pela primeira vez os reuniu e aplicou de forma harmonica e coesa num grande projeto.
Alem disso, foi durante este projeto que tanto a metodologia quanto as praticas iniciais
foram batizadas com os nomes atuais (TELES, 2004).
Um dos princıpios do XP e a concentracao de esforcos da equipe de desenvolvimento
em atividades que geram resultados rapidamente na forma de software intensamente tes-
tado e alinhado as necessidades de seus usuarios. Alem disso, simplifica e organiza o
trabalho combinando tecnicas comprovadamente eficazes e eliminando atividades redun-
dantes. Por fim, reduz o risco dos projetos desenvolvendo software de forma iterativa e
reavaliando permanentemente as prioridades dos usuarios (TELES, 2004).
O desenvolvimento tradicional de software tem como premissa o determinismo e sao
caracterizados por uma grande quantidade de atividades e artefatos que buscam proteger
o software contra mudancas, o que faz pouco ou nenhum sentido, visto que os projetos
devem se adaptar a tais mudancas ao inves de evita-las (TELES, 2004). Na contramao
deste pensamento, XP tem como premissa a certeza de que durante o desenvolvimento do
software muitas mudancas ocorrerao. Segundo Beck (2004), XP e uma metodologia leve,
voltada para times de qualquer tamanho, focada no desenvolvimento de software e que se
adapta bem em face a requisitos vagos e que mudam rapidamente.
O XP sugere diversos valores, princıpios e praticas que conduzem a equipe de desen-
volvimento a ficar apta a atender essas inevitaveis mudancas quando necessario, alem de
prepara-la para diversas outras situacoes. Destacando-se, em face ao tema deste trabalho,
os itens listados:
Valores:
• Feedback : E basicamente um retorno de informacoes dos requisitos fornecidas pelo
cliente. O XP sugere que tambem exista um feedback da equipe de desenvolvi-
mento para o cliente, apresentando informacoes como estimativas, riscos tecnicos e
alternativas de design, assim ele podera reavaliar as prioridades, por exemplo.
• Comunicacao: Defende-se a interacao direta entre as pessoas de modo a diminuir
as falhas de comunicacao e evitar retrabalhos desnecessarios. Para que isso seja
22
possıvel, e preciso aproximar ao maximo todas as pessoas que formam a equipe do
projeto, inclusive e sobretudo o cliente (TELES, 2004). Alem disso, para que o valor
feedback exista em um projeto de software, e necessario que a comunicacao esteja
presente de forma muito intensa (BECK, 2004).
• Simplicidade: A simplicidade nos ensina a implementar apenas aquilo que e sufi-
ciente para atender as necessidades atuais do cliente. Nao se deve tentar prever o
futuro, pois raramente se obtera exito nas previsoes (TELES, 2004). Uma pesquisa
com 350 empresas e 8.000 projetos de software, revelou que nas grandes companhias
americanas, mesmo entre os poucos (9%) projetos entregues dentro do prazo e do
orcamento, somente 42% dos requisitos definidos inicialmente sao encontrados no
produto final (GROUP, 1994).
Princıpios:
• Economia: E um erro esquecer-se do lado economico do desenvolvimento e preocupar-
se somente com o “Sucesso tecnico” (BECK, 2004). O cliente investe em software
com a expectativa de que este gere valor comercial. O XP reconhece esta premissa
e suas praticas sao organizadas para antecipar receitas e adiar despesas (TELES,
2004).
• Melhoria: Em desenvolvimento de software nao existe a solucao perfeita, por este
motivo a XP nao se preocupa em construir softwares perfeitos. O objetivo da XP
e a melhoria contınua, que se traduz na grande preocupacao em aperfeicoar cada
vez mais o design, os processos, as historias 4 e todos os outros aspectos ligados a
qualidade (BECK, 2004).
• Oportunidade: Um acontecimento no projeto pode ser uma crise ou uma oportuni-
dade dependendo apenas de como a equipe reage. Quando enxergamos problemas
como oportunidades de aprendizado e mudanca, podemos adotar atitudes mais pro-
veitosas para todos os envolvidos (TELES, 2004).
• Falha: Se a falha gerar conhecimento, ela nao pode ser considerada um desperdıcio,
pois conhecimento e algo muito valioso e algumas vezes difıcil de conseguir. As falhas
contribuem para a validacao de hipoteses, permitindo decisoes mais embasadas em
um projeto de software.
4No contexto da Programacao Extrema, “historia” e um texto ou paragrafo escrito pelo usuario a fimde definir suas necessidades de forma resumida e objetiva.
23
• Qualidade: Existe uma crenca de que alta qualidade resulta em gastos mais eleva-
dos. Nao ha duvidas de que a qualidade tem um preco, mas a falta dela tem um
preco ainda maior (TELES, 2004). Maior qualidade significa menos defeitos e re-
trabalho, menos aborrecimentos e maior seguranca para clientes e desenvolvedores,
maior confianca, menos ansiedade, maior motivacao, maior efetividade, maior pro-
dutividade e maiores lucros, entre outras coisas. Ou seja, maior qualidade significa
gerar maior valor de forma mais simples e eficientes, e com menos custos (TELES,
2004).
• Pequenos passos: E normal um desenvolvedor sentir frustracao, medo, ansiedade e
confusao ao se deparar com um erro no software apos um grande passo em que foram
implementandas varias funcionalidades de uma vez. Ao dar pequenos passos por
vez, o desenvolvedor eleva seu domınio sobre qualquer eventual problema. Mudancas
importantes feitas em um unico passo sao perigosas. A execucao do trabalho em
passos pequenos diminui muito este risco (BECK, 2004).
Praticas:
• Historias: Sao breves descricoes de tarefas a serem executadas pela equipe XP.
Devem estar sempre visıveis para os clientes e preferencialmente escritas por eles
mesmos, a fim de iniciar um dialogo sobre a tarefa, levantando questoes que influen-
ciam na estimativa de tempo de execucao. Em posse da estimativa, cabe ao cliente
priorizar as historias.
• Ciclo semanal: Numa iteracao, representada por um ciclo semanal, algumas historias
escolhidas pelo cliente sao implementadas e testadas completamente. Terminado o
ciclo, o cliente tem a oportunidade de utilizar e avaliar o que foi produzido (TELES,
2004). Seguindo essa pratica, o cliente alem de receber valor muito mais rapida-
mente, tem a oportunidade de, ao interagir com o valor gerado, verificar continua-
mente se o caminho seguido e realmente o desejado (BECK, 2004).
• Ciclo trimestral: No inicio de cada trimestre reune-se toda a equipe, incluindo
clientes e demais envolvidos, para avaliar o projeto, seu progresso e seu alinhamento
com as metas principais. O objetivo e conseguir identificar gargalos; iniciar reparos;
definir o tema ou os temas para o trimestre; estimar quais historias, de uma forma
geral, gerarao o valor necessario aos temas escolhidos para o trimestre.
24
• Integracao contınua: Consiste em integrar o trabalho diversas vezes ao dia, assegu-
rando atraves dos testes principalmente, que a base de codigo permaneca consistente
ao final de cada integracao
• Design incremental: Qualquer caracterıstica que possa ser implementada para dar
apoio a funcionalidades futuras so e codificada de fato se e quando tal funcionalidade
fore priorizada para uma iteracao futura. Assim, busca-se concentrar os esforcos da
equipe naquilo que se tem certeza absoluta de que sera necessario hoje, por ja ter
sido priorizado pelo cliente para a iteracao corrente. Aquilo que poderia ser util
no futuro, deixamos para resolver no futuro, quando houver certeza da necessidade.
(TELES, 2004).
• Envolvimento real do cliente: Essa pratica sugere que os usuarios finais sejam en-
volvidos diretamente no processo de desenvolvimento. O ideal e que, ao longo do
desenvolvimento, alguns dos usuarios finais utilizem as funcionalidades ja imple-
mentadas. Assim, e possıvel perceber se o que esta sendo pedido pelos requerentes
realmente reflete as necessidades dos usuarios finais (TELES, 2004).
• Codigo e testes: O desenvolvimento agil de software defende uma boa aceitacao do
projeto a mudancas, portanto um codigo que garanta facil deteccao de erros a cada
mudanca e essencial. Em termos gerais, equipes XP acreditam que “a unica forma
de se mover rapidamente e com confianca e tendo uma rede de testes, tanto de
unidade, quanto de aceitacao” (JEFFRIES; ANDERSON, 2001). Clientes pagam pelo
que o sistema faz hoje e pelas funcionalidades que a equipe acrescentar ao sistema
amanha. Quaisquer artefatos que contribuam para estas duas fontes de valor sao
valiosos. Qualquer outra coisa e desperdıcio (BECK, 2004).
Em secoes posteriores sera possıvel observar que os valores, princıpios e praticas lis-
tados acima tem muita relacao com as propostas da Lean startup, tornando XP uma das
suas maiores influencias. Ainda assim, alguns itens foram omitidos por nao terem uma
relacao direta com o tema deste trabalho, apesar de serem muito importantes para XP em
si, tais como coragem, respeito, diversidade, reflexao, desenvolvimento orientado a testes
e contrato de escopo negociavel.
2.2.4.2 Scrum
Scrum e uma metodologia agil voltada para o gerenciamento de projetos, diferentemente
de XP que e direcionada exclusivamente para desenvolvimento de software em si. Apesar
25
disso, e extramente comum ambos serem utilizados em conjundo no desenvolvimento de
projetos de software.
Jeff Sutherland documentou, concebeu e implantou o Scrum na empresa Easel Cor-
poration 5, em 1993, incorporando estilos de gerenciamento observados originalmente por
Takeuchi e Nonaka, que foram os primeiros a utilizar o termo e implementa-lo nas fabricas
de automoveis da Toyota. Em 1996, Ken Schwaber formalizou a definicao de Scrum e
ajudou a implanta-lo no gerenciamento de projetos de software ao redor do mundo. O
Scrum tem sido adotado por gestores que buscam garantir a obtencao do melhor produto
possıvel e por engenheiros que buscam garantir que farao seu trabalho da melhor forma
possıvel, sendo usado em milhares de projetos por todo o mundo A. Beedle e Schwaber
(2002).
O Scrum nao dita um processo rıgido e especıfico de etapas no desenvolvimento de
software, mas define princıpios e praticas de gestao que devem ser adotadas para garantir
o sucesso de um projeto. E uma evolucao na forma de pensar e desenvolver projetos, man-
tendo o foco sempre no relacionamento entre os principais envolvidos no desenvolvimento
de software: o desenvolvedor, o gestor e o cliente. E um modo de pensar no qual coloca
a Tecnologia da Informacao com visibilidade de apoiadora, viabilizadora e aliada no pro-
jeto de um produto. As analises de estudos de caso como os apresentados por Kniberg
(2007), Qumer e Henderson-Sellers (2008) e Cheng (2009) mostram que a utilizacao de um
metodo bem definido para implantacao das praticas do Scrum pode aumentar a agilidade
no desenvolvimento e trazer um maior retorno do investimento realizado no projeto em
menos tempo.
O Scrum tem o processo de desenvolvimento do projeto baseado em iteracoes com
duracao entre duas e seis semanas, chamadas de Sprints. O primeira etapa dentro do
Sprint e a reuniao de planejamento (Sprint Planning), onde o time (Scrum Team), em
conjunto com o cliente (Product Owner) define o que sera implementado na iteracao, sendo
responsabilidade do cliente realizar a priorizacao do trabalho a ser feito. A proxima
etapa e a de execucao, onde o time detalha as tarefas necessarias para implementar o
que foi solicitado pelo cliente e posteriormente inicia sua execucao. Durante o Sprint o
time realiza reunioes diarias (Daily Meeting) breves, com aproximadamente 15 minutos,
para averiguar o acompanhamento do progresso do desenvolvimento, usando para isto o
BurnDown Chart, que e um grafico usado para o acompanhamento das tarefas a realizar,
em andamento e ja realizadas.
5Easel Corporation foi uma empresa de desenvolvimento de software fundada nos anos 80 e vendidapara a VMark em meados dos anos 90
26
Ao final do Sprint e realizada uma reuniao para a validacao da entrega (Sprint Re-
view), onde o cliente e quem mais tiver interesse no produto pode verificar se o objetivo
definidor especificamente naquele Sprint foi atingido. Logo apos, e realizada apenas pelo
Scrum Team uma reuniao (Sprint Retrospective) onde e avaliado sob a perspectiva de
processo, time ou produto, quais foram os acertos e os erros com o objetivo de melhorar o
processo de trabalho. Esse ciclo de gestao e desenvolvimento pode ser representado com
a figura 1.
Figura 1: Ciclo de gestao de um projeto SCRUM
Fonte: A. Beedle e Schwaber (2002)
2.3 Tecnicas propostas pela metodologia Lean Star-
tup
2.3.1 O ciclo Construir-medir-aprender
A atividade fundamental de uma startup e transformar ideias em produtos, medir como
os clientes reagem, e, entao, aprender se e o caso de pivotar 6 ou perseverar. Todos os
processos de startup bem-sucedidos devem ser voltados a acelerar esse ciclo de feedback,
6Termo derivado do ingles “to pivot” e designa uma mudanca radical no rumo do negocio
27
que esta no centro da metodologia Lean startup (RIES, 2011).
Muitas pessoas possuem formacao profissional que enfatiza apenas um elemento desse
ciclo de feedback. Para os engenheiros, e aprender a construir coisas, como um algoritmo
por exemplo, com o maximo de eficiencia. Alguns gerentes sao especialistas em formulacao
de estrategias e aprendizagem no quadro branco. Por outro lado, muitos empreendedores
concentram energia em ter a melhor ideia de produto, ter o produto inicial mais bem
projetado ou entao sao obcecados por dados e metricas. A verdade e que nenhuma
dessas atividades isoladamente e de grande importancia. Em vez disso, o ideal e unir
cada elemento e concentrar a energia na minimizacao do tempo total gasto nesse ciclo de
feedback, e essa e a essencia da direcao de uma startup (RIES, 2011).
Figura 2: Ciclo construir-medir-aprender
Fonte: Ries (2011)
Lembremos que, embora Ries (2011) descreva o ciclo de feedback como construir-
medir-aprender nesta ordem pois as atividades ocorrem nesta sequencia, o planejamento
funciona na ordem inversa. Ele sugere equacionar o que precisamos aprender e, entao, tra-
balhar de tras para a frente para observar que produto funcionara como experimento para
obtermos aquela aprendizagem. Portanto, nao e o cliente, mas nossa hipotese acerca do
cliente que puxa o trabalho do desenvolvimento do produto e de outras funcoes. Qualquer
outro trabalho e desperdıcio.
28
2.3.2 Menor produto viavel
Do termo em ingles “Minimum Viable Product” e normalmente refereciado pela sigla
“MVP”, este conceito remete aquela versao do produto que permite uma volta completa
do ciclo construir-medir-aprender, com o mınimo de esforco e o menor tempo de desen-
volvimento. O menor produto viavel carece de diversos recursos que podem se provar
necessarios em certo ponto do projeto. Apesar de parecer simplorio, a elaboracao deste
requer sobretudo bom senso, afinal cada projeto tem seu conjunto de caracterısticas que
o torna mınimo e viavel ao mesmo tempo. O empreendedor deve conseguir fazer com que
seja possıvel medir o impacto do seu produto. Por exemplo, nao e adequado construir
um prototipo que seja avaliado por engenheiros e designers apenas em funcao da sua
qualidade interna. Tambem e preciso coloca-lo diante dos possıveis clientes para avaliar
a reacao deles, o que muitas vezes inclui a venda de um prototipo mesmo que ele esteja
longe de ser o objetivo final do projeto.
A figura 3 ilustra a construcao de um MVP da maneira correta, ou seja, com a entrega
gradual de valor visando menor esforco possıvel. A ideia e que seja feito apenas o que e
necessario para percorrer o ciclo construir-medir-aprender.
Figura 3: Menor produto viavel
Fonte: Faber (2015)
29
Um MVP pode tomar diversas formas. Pode ser, por exemplo, um software com
um conjunto reduzido de funcionalidades, um blog com conteudo sobre o produto que
pretende-se lancar, ou mesmo um vıdeo apresentando o que pretende-se construir. O que
define se o produto e de fato um MVP e a possibilidade de percorrer cada item do ciclo
construir-medir-aprender, nao seu tamanho ou mecanica de funcionamento.
Um vıdeo ou blog como produto podem parecer, e sao, muito atıpicos, principalmente
para um programador ansioso por implementar suas ideias. Mas observe que e possıvel
a) construir, mesmo que apenas como ideia, funcionalidades de um software; b) medir a
repercursao deste atraves dos comentarios de um vıdeo ou quantidade de acessos de uma
publicacao num blog; e c) e possıvel aprender, mesmo que pouco, se vale a pena investir
recursos na expectativa criada a respeito de certas funcionalidades. Isso completa o ciclo
com um investimento, em geral, incrivelmente baixo.
Um exemplo de sucesso com um MVP em forma de vıdeo foi o da Dropbox, empresa
do Vale do Silıcio que oferece uma ferramenta de compartilhamento de arquivos de uti-
lizacao muito facil. Em paralelo com suas iniciativas de desenvolvimento do produto, os
fundadores quiseram o feedback dos clientes sobre o que de fato tinha importancia para
eles. Em particular, a Dropbox precisava testar sua pergunta associada a um ato de fe:
“se conseguıssemos proporcionar ao cliente uma experiencia superior ao que estao acos-
tumados, as pessoas testariam nosso produto?” Eles acreditavam – com razao, revelou-se
– que a sincronizacao de arquivos era um problema que a maioria das pessoas nao sabia
que tinha. Assim que voce vivencia a solucao em vıdeo, nao e capaz de imaginar como
conseguiu viver sem isso ate entao.
Como e possıvel imaginar, um MVP como esse nao e o mais comum e na maioria dos
casos ira fornecer um aprendizado limitado sobre um produto, mas ilustra bem qual o
objetivo principal da tecnica proposta pelo autor da metodologia: aprender.
2.3.2.1 Qualidade de um MVP
Certamente havera questionamentos sobre a qualidade de um MVP por parte de inves-
tidores, engenheiros e gestores de projeto. Um pouco alem disso Eric Ries concorda que
as vezes, os MVPs sao percebidos como de baixa qualidade pelos proprios clientes. Mas
segundo ele, em caso afirmativo, devemos usar isso como uma oportunidade de descobrir
os atributos com os quais os clientes se preocupam. Isso e infinitamente melhor do que a
mera especulacao ou formulacao de estrategias no quadro branco, pois fornece uma base
empırica solida sobre a qual desenvolver os futuros produtos (RIES, 2011). Em suma,
30
mesmo um MVP de “baixa qualidade” pode atuar a servico do desenvolvimento de um
produto de alta qualidade.
Ainda assim, o conceito de MVP e um desafio as nocoes tradicionais de qualidade.
Os processos modernos de producao se baseiam na alta qualidade como maneira de im-
pulsionar a eficiencia. Funcionam usando a afirmacao de W. Edwards Deming: o cliente
e a parte mais importante do processo de producao. Significa que devemos concentrar
a energia exclusivamente na producao de resultados que o cliente percebe como dotados
de valor. A maioria das filosofias modernas empresariais e de engenharia concentra-se
na producao de experiencias de alta qualidade para os clientes como princıpio basico; e
o fundamento das praticas Seis Sigma7, da manufatura enxuta, do design thinking, da
Programacao Extrema e do movimento de software craftsmanship8.
Um grande porem, segundo Ries, e que essas discussoes de qualidade pressupoem que
a empresa ja conhece os atributos do produto que o cliente valorizara, e ele afirma que
essa e uma suposicao arriscada numa startup. Muitas vezes, nao se sabe sequer quem e o
cliente. Portanto, para as startups, Ries e enfatico:
“Se nao sabemos quem e o cliente, nao sabemos o que e qualidade.” - Ries
(2011)
Tomando como exemplo o IMVU, jogo criado pelo mesmo autor da metodologia Lean
Startup. E um mundo virtual com enfase numa experiencia que segue os mesmos passos do
Second Life, com uma vasta quantidade de bens virtuais criados e vendidos pelos proprios
jogadores. Em 2011, seu faturamento anual chegou a 50 milhoes de dolares.
Nos primeiros dias do MVP do IMVU, os avatares dos jogadores ficavam parados em
um lugar. Os desenvolvedores optaram por postergar a ardua tarefa de criar a tecnologia
que permitisse com que os estes passeassem pelo ambiente virtual. Nao quiseram lancar
uma versao de baixa qualidade desse recurso, portanto, optaram por apresentar avatares
estaticos. Afinal o padrao e que os avatares em 3D devem se mover de modo fluido
enquanto caminham, evitar obstaculos no caminho e seguir um itinerario inteligente ate
o seu destino. O feedback dos clientes foi muito consistente: eles queriam a capacidade de
mover seus avatares pelo ambiente.
7Conjunto de praticas originalmente desenvolvidas pela Motorola para melhorar sistematicamente osprocessos ao eliminar defeitos. Um defeito e definido como a nao conformidade de um produto ou servicocom suas especificacoes.
8Uma abordagem ao desenvolvimento de software que enfatiza as habilidades de codificacao dosproprios desenvolvedores de software.
31
Mas antes de se comprometerem com essa custosa solucao, decidiram tentar outra
versao do MVP. Utilizaram um truque o qual, inicialmente, eles nao se orgulharam. Na
nova versao o cliente podia clicar no lugar para onde ele queria que seu avatar se deslocasse
e entao seria teletransportado para la instantaneamente. Nao havia nem mesmo recursos
graficos ou efeitos sonoros. Para a surpresa da propria equipe de desenvolvimento, o
feedback dos clientes foi muito positiva. Apesar de nunca fazerem perguntas diretas sobre
os recursos, os jogadores mencionaram a funcionalidade de teletransporte entre as 3 coisas
que mais gostavam no jogo.
Essa experiencia corrobora com a afirmacao categorica de Eric Ries sobre saber o
que, de fato, e qualidade. O metodo da startup enxuta nao e contrario a construcao
de produtos de alta qualidade, desde que estejam a servico do objetivo de conquistar
clientes. Mas deve-se estar dispostos a por de lado padroes profissionais tradicionais para
comecar o processo de aprendizagem validada o mais breve possıvel, respeitando limites
da negligencia ou indisciplina.
Uma boa representacao da maneira ideal de construir um MVP esta ilustrada na figura
4, onde se destaca a entrega concomitante de 6 valores: Funcionalidade, confiabilidade,
usabilidade, conveniencia, agradabildiade e significado.
Figura 4: A piramide de desenvolvimento de um MVP
Fonte: Pagan (2015)
32
2.3.3 Implantacao contınua
Vindo do termo em ingles Continuos deployment, esta e uma abordagem que permite
que softwares sejam atualizados com uma frequencia maior, de uma maneira mais agil.
Naturalmente faz com que seja possıvel entregar mudancas para o cliente com uma ve-
locidade maior, diminuindo o ciclo ”contruir-medir-aprender”. Na startup IMVU, o time
de desenvolvimento realizava ate cinquenta mudancas por dia, e isto foi fundamental para
o sucesso da startup, pois o feedback dos clientes era rapido, e possıvel perceber o que
agregava valor e o que poderia ser dispensado. A figura 5 mostra uma comparacao en-
tre o ciclo de mudanca de uma aplicacao com implantacao contınua e sem implantacao
contınua.
Figura 5: Comparacao do ciclo de desenvolvimento sem e com implantacao contınua
Entretanto, essa e uma pratica um tanto questionavel por muitos desenvolvedores,
merecendo um aprofundamento deste topico. O debate inicia-se na ideia de entregar
software recem desenvolvido para o cliente, remetendo a falta de qualidade, indo na
contra-mao dos processos tradicionais de validacao ja difundidos de Quality Assurance.
Na defensiva a esta otica, segundo os defensores da implantacao contınua, a pratica
nao e simploria como soa. Na verdade nem e uma antıtese as praticas de validacao
minuciosas de codigo, muito pelo contrario, e a aplicacao destes processos de forma au-
tomatizada. Para tornar isso possıvel, a startup precisa de um alto grau de automacao
33
em sua infraestrutura de deploy e uma boa engenharia de software. O que e bastante
acessıvel utilizando-se de codigo open source.
A ideia e que toda modificacao deva gerar um sistema com potencial imediato de
lancamento, coberto por testes que certifiquem sua completude, corretude e integridade.
Todos os desenvolvedores devem integrar suas alteracoes na mesma base de codigo, e
devem se certificar de que essas alteracoes nunca quebrem os testes. Evidencia-se que alem
de um conjunto proprio de ferramentas para automacao, sao necessarias boas praticas de
desenvolvimento. E uma maneira de gerar qualidade na concepcao de cada linha de
codigo, nao em morosos ciclos de homologacao.
Dentre as diversas tecnicas utilizadas em implantacao contınua, sao de especial inte-
resse:
• Gerenciamento de configuracao: Controle de versionamento (codigo; testes; scripts
para banco de dados, build e deploy ; documentacao; bibliotecas; arquivos de con-
figuracao da aplicacao, das ferramentas, dos ambientes; informacoes de rede, etc.);
Gerenciamento de dependencias, configuracao de software e ambientes
• Integracao contınua: Suıte de testes automatizados; Praticas de versionamento
(check in periodico na base de codigo, ciclos curtos, testes e acoes em caso de falha
no release, rollback etc.);
• Desenvolvimento orientado a testes, refactoring, pair programming e demais tecnicas
de Programacao Extrema;
• Estrategias de teste:
– Utilizacao de metricas para tempo de execucao dos testes automatizados;
– Utilizacao de metricas para cobertura de testes, defeitos, performance, etc.
– Aceitacao funcional: verifica se o sistema funciona do ponto de vista funcional
e fornece valor para o usuario, conforme criterios de aceitacao
– Aceitacao nao funcional: verifica os requisitos nao funcionais (performance,
capacidade, seguranca, tolerancia a falhas etc.) e e o ultimo estagio antes do
deploy
– Implantacao: processo automatizado para implantar o software nos diversos
ambientes disponıveis, havendo um foco especial em efetivamente liberar o
software para producao visando a tempo zero de desligamento do servidor
34
A implantacao contınua por vezes e mal interpretada e confundida com outras simi-
lares, que sao na verdade parcelas de todo o processo. Sendo elas, a ja citada integracao
contınua (continuous integration) na fundamentacao sobre XP e a entrega contınua (con-
tinuous delivery). Uma boa visualizacao das diferencas esta ilustrada na figura 6:
Figura 6: Comparacao entre integracao contınua, entrega contınua e implantacaocontınua.
• Integracao contınua: Automatizacao ate a etapa de integracao de codigo
• Entrega contınua: Automatizacao ate a etapa de versionamento do software num
ambiente de homologacao
• Implantacao contınua: Automatizacao inclusive da entrega para o ambiente de
producao.
2.3.4 Testes A/B
Teste A/B e um metodo de teste de design atraves do qual comparam-se elementos
aleatorios com duas variantes, A e B, em que estes sao o controle e o tratamento de
uma experiencia controlada, com o objetivo de melhorar a percentagem de aprovacao.
Uma experiencia de teste A/B envolve versoes diferentes de um produto oferecidas
aos clientes ao mesmo tempo. Observando-se as mudancas no comportamento entre os
grupos de clientes, e possıvel fazer inferencias acerca do impacto de diversas variacoes.
Essa tecnica foi criada por anunciantes de mala-direta. Por exemplo, considerando uma
empresa que envia aos clientes um catalogo de compras de produtos. Ao testar o material
grafico do catalogo, pode-se enviar uma nova versao dele para 50% dos clientes e enviar
o antigo para os outros 50%. Para assegurar um resultado cientıfico, os dois catalogos
conteriam produtos identicos; a unica diferenca seriam as mudancas do material grafico.
A fim de descobrir se o novo projeto grafico era eficaz, tudo o que teria de ser feito era
35
monitorar os numeros das vendas para os dois grupos de clientes. Embora, muitas vezes,
o teste A/B seja considerado uma pratica especıfica de marketing (ou ainda especıfica do
marketing direto), as startups incorporam esse teste diretamente ao desenvolvimento de
produto.
Com frequencia, o teste A/B revela coisas surpreendentes. Por exemplo, diversos
recursos que tornam o produto melhor aos olhos dos engenheiros e designers nao causam
impacto no comportamento do cliente, na Grockit9 esse foi o caso. Embora trabalhar com
testes comparativos pareca ser mais difıcil porque requer contabilidade e metrica extras
para acompanhar cada variacao, quase sempre economiza muito tempo a longo prazo, ao
eliminar trabalho que nao tem importancia para os clientes.
O teste A/B tambem ajuda as equipes a refinar o entendimento do que os clientes
querem ou nao. Constantemente, a equipe da Grockit adicionava novas maneiras de os
clientes interagirem entre si, na expectativa de que tais ferramentas de comunicacao social
aumentassem o valor do produto. Nessas iniciativas, estava implıcita a crenca de que os
clientes desejavam mais comunicacao durante os estudos. Quando o teste A/B revelou
que os recursos extras nao mudavam o comportamento dos clientes, isso pos em duvida
essa crenca.
O questionamento inspirou a equipe a buscar um entendimento mais profundo do que
os clientes queriam de fato. Ela fez um brainstorm10 de novas ideias para experimentos
de produtos que talvez provocassem mais impacto. Na realidade, muitas dessas ideias nao
eram novas. So haviam sido ignoradas, pois a empresa estava concentrada no desenvol-
vimento de ferramentas sociais. Em consequencia, a Grockit testou um modo de estudo
individual intensivo, completo com missoes e nıveis semelhantes a jogos, para que os alu-
nos pudessem ter a possibilidade de estudar sozinhos ou com os outros. Sem a disciplina
do teste A/B, a empresa talvez nao tivesse tido essa compreensao. De fato, ao longo
do tempo, por meio de dezenas de testes, ficou claro que a chave para o compromisso
dos alunos era a oferta de uma combinacao de recursos sociais e individuais. Os alunos
preferiam ter uma alternativa de como estudar.
9Grockit e um site que oferece uma plataforma gameficada para realizacao de preparatorios para testesde admissao em escolas norte americanas.
10Uma dinamica de grupo que e usada em varias empresas como uma tecnica para resolver proble-mas especıficos, para desenvolver novas ideias ou projetos, para juntar informacao e para estimular opensamento criativo.
36
2.3.5 Pivo
Este e um termo derivado do ingles to pivot e designa uma mudanca radical no rumo do
negocio ou projeto. Tem sido bastante usada pela comunidade empreendedora do Vale
do Silıcio nos ultimos anos, e os brasileiros costumam usar “pivotar” na traducao livre
para o portugues. O significado de pivo para uma startup, apesar de simples de explicar,
e uma tatica de negocios importante que pode definir se o projeto ira morrer ou crescer.
Ao termino do ciclo construir-medir-aprender, encara-se a questao mais difıcil enfren-
tada por qualquer empreendedor: pivotar a estrategia original ou perseverar. Se descobrir
que uma das hipoteses e falsa, sera o momento de realizar uma mudanca importante, rumo
a uma nova hipotese estrategica. O metodo da startup enxuta cria empresas eficazes em
termos de capital, pois permite as startups reconhecer mais cedo que e o momento de
pivotar, gerando menos desperdıcio de tempo e dinheiro.
Se a empresa estiver fazendo um bom progresso na direcao do ideal, isso significa
que esta aprendendo de forma apropriada e utilizando aquela aprendizagem de maneira
efetiva. Nesse caso, faz sentido continuar. Caso contrario, a equipe gerencial deve acabar
concluindo que sua estrategia de produto corrente e imperfeita e requer uma mudanca
importante. Quando uma empresa pivota, esta comeca o processo de novo, estabelecendo
uma nova base e, em seguida, ajustando o projeto a partir dali. O sinal de um pivo
bem-sucedido e que essas atividades de ajuste sao mais produtivas apos o pivo do que
antes.
A decisao de pivotar requer uma mentalidade lucida e objetiva. Devera levar em
consideracao o ato de pivotar sempre que voce notar uma eficacia decrescente dos expe-
rimentos com o produto e a sensacao generalizada de que o desenvolvimento do produto
deve ser mais produtivo. A decisao de pivotar e difıcil, em termos emocionais, para qual-
quer startup, e tem de ser abordada de maneira estruturada. Uma maneira de mitigar
esse desafio e programar a reuniao com antecedencia. Todas as startups deveriam ter
uma reuniao regular acerca de pivotar ou perseverar. Segundo Ries (2011),“menos do que
algumas semanas entre as reunioes e muito frequente e mais do que alguns meses e muito
infrequente. No entanto, cada startup precisa encontrar o proprio ritmo. Cada reuniao
sobre pivotar ou perseverar requer a participacao das equipes tanto de desenvolvimento
de produto como de lideranca comercial”.
Toda vez que a empresa pivota, nao tem que comecar do zero. E certo que grande
parte do produto geralmente tem de ser descartado entre os pivos. Pior, o produto que
37
fica e classificado como produto legado, que nao e mais apropriado para os objetivos da
empresa. Como e geralmente o caso, o esforco necessario para reutilizar um produto
legado significa trabalho extra. A contraposicao a essas forcas sao as licoes aprendidas de
maneira atraves de cada marco. Com isso, acelera-se o processo de MVP porque se passa
a aprender pontos crıticas a respeito de clientes, mercado e estrategia. E um cenario de
bastante trabalho a ser feito, mas nao e comecar do zero.
Ha exemplos famosos e muito bem sucedidos de empresas que pivotaram, dois exem-
plos muito utilizados sao:
• Paypal: comecou como uma empresa de troca de dinheiro virtual entre dispositi-
vos handheld 11. Com o tempo, os fundadores perceberam que seu servico estava
mesmo nos micropagamentos e na troca de dinheiro via web, se adaptando ao mer-
cado de forma primorosa, seguindo o aumento repentino de usuarios e servicos que
exploravam de forma pioneira o pagamento via web.
• Flickr: empreendedores que estavam construindo um RPG multi-usuario na inter-
net um dia se convenceram que o mercado de RPGs online estava saturado. Nesse
momento, aproveitaram a funcionalidade que tinham projetado para trocar imagens
entre jogadores e montaram o Flickr - que veio a se tornar um servico de comparti-
lhamento de fotos famoso em todo o mundo.
De acordo com a metodologia proposta por Eric Ries, existem dez tipos de pivos. Sao
eles:
• 1. Pivo Zoom-in: transformar o que antes era apenas uma parte do seu produto ou
servico em todo o seu produto ou servico.
• 2. Pivo Zoom-Out : e o movimento contrario do primeiro item, ou seja, transformar
todo o seu produto em uma funcionalidade ou parte de algo novo que ira suprir a
necessidade do mercado.
• 3. Pivo de segmento de cliente: trata-se de adaptar o seu produto ao publico-alvo
correto.
• 4. Pivo de necessidade do cliente: adaptar seu produto as reais necessidades dos
clientes.
11Antiga plataforma utilizada pelo Palm
38
• 5. Pivo de plataforma: mudar o seu servico de plataforma — o que antes foi
pensado como um site, por exemplo, pode funcionar melhor como um aplicativo
para dispositivos moveis.
• 6. Pivo de arquitetura de negocio: e fazer com que o que era pensado como um
negocio B2B, ou seja, para empresas, seja agora voltado para o consumidor final e
vice-versa.
• 7. Pivo de captura de valor: modificar o seu sistema de captacao de renda ou de
monetizacao do seu negocio.
• 8. Pivo Engine of growth: buscar alternativas para a divulgacao do seu produto
— as vezes, um produto que foi visto como algo viral, que ira gerar divulgacao
espontanea atraves dos consumidores, precisa de outro metodo de marketing, como
propagandas.
• 9. Pivo de canal: e a mudanca de logıstica de entrega do seu produto.
• 10. Pivo de tecnologia: buscar uma nova tecnologia que ira tornar o seu negocio
mais competitivo.
39
3 Estudo de caso
O estudo de caso deste trabalho e um site chamado GoPages, desenvolvido na Algorich,
empresa deste autor com participacao direta no desenvolvimento do software e no de-
senvolvimento do produto. A escolha deste projeto foi baseada num conjunto de fatores
que pudessem expor a aplicabilidade da metodologia Lean Startup em um negocio com
grande limitacao de recursos, de forma fidedigna e precisa as suas principais propostas,
sendo estes fatores:
• Enquadramento do projeto com a definicao de startup
• Comprometimento com a aplicacao da metodologia Lean Startup
• Acesso aos resultados obtidos durante o desenvolvimento
• Participacao direta nas decisoes do projeto
• Vivencia na aplicacao das praticas propostas pela metodologia
• Posse dos relatos e metricas de feedback dos clientes
• Acesso preciso aos dados de recursos investidos no projeto
• Possibilidade de comparar os resultados do projeto com a startup TheGrid.io, de
proposito muito similar
O objetivo ao analisar este estudo de caso nao e verificar o sucesso da startup em si,
mas a influencia da aplicacao da metodologia durante a execucao do produto, sobretudo na
reducao de desperdıcios. Neste caso o conceito de produto nao remete a apenas o software
construıdo, mas a todo o conjunto de atividades relacionadas ao seu desenlvolvimento,
englobando inclusive estrategias de marketing, estudos de mercardo, organizacao e gestao
dos recursos humanos e financeiros.
40
E um ponto de vista que analisa os fatores arredores ao software, mas que influenciam
diretamente no levantamento de requisitos, de uma maneira nao tao comum na Engenharia
de Software no meio academico, porem muito discutida no mercado.
Reitera-se, portanto, que o objetivo-mor deste estudo de caso e por a prova a me-
todologia, de forma cetica e imparcial, levantando se ha relevancia desta que justifique
um teor academico em suas praticas. Nao se restringindo, mas focando nas validacao das
seguintes promessas:
• Aumentar a precisao no levantamento de requisitos
• Eliminar praticas de desperdıcio
• Aumentar a producao de valor durante a fase de desenvolvimento do produto
• Maximizar o aprendizado fornecido pelo feedback do consumidor
• Tornar o feedback do consumidor uma parte fundamental para o levantamento de
requisitos do produto
41
3.1 Objeto de estudo
A proposta do site GoPages e ser uma plataforma para criacao de sites responsivos e
simples, em poucos segundos e de forma automatizada. Os dados sao obtidos via API
de perfis sociais (Facebook, LinkedIn, Instagram, etc), e sua atualizacao e automatica
mediante alteracoes nestas plataformas.
Figura 7: Pagina principal do GoPages
42
A idealizacao deste projeto teve origem em fatores do mercado:
• Sites passaram a ser uma especie de cartao de visita online para pequenas empresas
• Em 2014 a grande maioria dos acessos da web eram via smartphones, com isso
muitas empresas precisavam de um novo site responsivo
• O Wix, plataforma web para desenvolvimento de sites, ja fazia sucesso mundial.
Mostrando grande demanda no mercado, sobretudo microempreendedores.
Um fator que estimulou pequenos ajustes na idealizacao do projeto foi que, apos o
inıcio do desenvolvimento do GoPages, seus colaboradores acamaram por descobrir um
startup no mercado com proposito bastante semelhante: TheGrid.io. Eles arrecadaram
mais de 5 milhoes de dolares em 10 meses apenas com pre-venda numa agressiva campanha
de marketing (WILLIAMS, 2015). Tudo que haviam apresentado ao publico era um vıdeo
com a promessa de utilizacao de inteligencia artificial para criacao automatica dos sites.
Este projeto claramente seguiu princıpios equivalentes aos do Lean Startup, tendo um
vıdeo como seu primeiro MVP, portanto sera colocado em comparacao com o GoPages
neste estudo de caso, assim como um relato de suas estrategias ao longo do tempo.
A plataforma Wix, por outro lado, tinha proposta mais conservadora, mas ainda de
grande dificuldade de execucao: um criador de sites com interface bastante amigavel e
facil para leigos, ter muitos templates e funcionalidades que nao exigem conhecimento
tecnico do usuario. Eles cumpriram a proposta com grande exito, vendendo por um baixo
custo e se tornando o lıder do mercado.
Ainda assim, conforme pesquisas feitas para a elaboracao do GoPages, havia uma
grande parcela dos potenciais clientes do Wix, sobretudo pequenos negocios, que nao o
utilizavam por nao dispor de um profissional de sua empresa com tempo para manusea-
lo. A automatizacao parecia ser a unica opcao pra essa parcela, dando inıcio a primeira
hipotese que o GoPages deveria validar.
O projeto teve inıcio em dezembro de 2014 e foi pivotado 1 ano depois. Deixou de
ser um produto e passou a ser utilizado como uma ferramenta de uso interno da empresa
deste autor. Financeiramente a startup teve um saldo positivo em termos de caixa antes
do pivo, porem insignificante. Na pratica, o maior saldo desta empreitada foi o fato de ter
se mostrado um investimento infrutıfero com o formato inicial de maneira relativamente
rapida e com baixo investimento.
43
3.2 Aplicacao das tecnicas
3.2.1 O ciclo Construir-medir-aprender
No desenvolvimento do GoPages havia um grande desafio tecnico: a implementacao dos
algoritmos que buscariam o conteudo dos sites. Do ponto de vista de software, era o
ponto central da ferramenta e sem isso nao haveria produto. E impossıvel uma equipe de
desenvolvedores nao ficar intrigada com este desafio, se perdendo nos detalhes de como
alcancar este objetivo. Mas a verdade e que, por mais importante que pudesse parecer,
um esforco em busca de “como fazer?” seria inutil se nao houvesse um “por que fazer?”,
erro muito comum por desenvolvedores que entram no mundo do empreendedorismo.
Seguindo a risca a tecnica contruir-medir-aprender, o correto e conter este ımpeto
de desenvolvedor e concentrar esforcos naquilo que permitisse gerar um feedback rapido
do mercado. O planejamento seria entao na seguinte ordem: a) Levantar hipoteses; b)
Definir metricas; c) Contruir o que fosse necessario pra validar as hipoteses;
Foram levantadas uma serie de itens a validar. Sera apresentado neste trabalho uma
relacao de hipoteses criadas, suas justificativas e o aprendizado obtido na validacao de
cada uma delas. Mas antes de lista-las, e importante relatar fatos sobre o processo pra
analisar a aplicabilidade da metodologia Lean Startup.
Acreditou-se durante o levantamento de hipoteses que uma levava a outras, criando
uma especie de prioridades a serem validadas, o que e perfeitamente razoavel de se pensar.
Entretanto houve uma interpretacao um tanto ingenua desta afirmacao, sobretudo apos
ser comparada com a aparente estrategia do TheGrid. Como exemplo, foi considerada a
seguinte dependencia:
Hipotese inicial:
“Existe uma parcela dos possıveis clientes que so pagarao por um produto que
crie sites automaticamente.”
A qual supostamente dependeria da validacao da seguinte:
“E possıvel oferecer um produto que crie sites de forma autonoma com os
recursos disponıveis.”
Sendo que a segunda sequer envolvia do cliente. O pensamento foi: “Nao importa
se as pessoas querem, se nao for possıvel implementar estamos fadados ao fracasso.”.
44
Talvez tenha havido uma supervalorizacao da pratica sugerida, fazendo com que os em-
preendedores achassem que deveria validar todo tipo de hipotese. Observando de maneira
pratica, houve uma persistencia de seus idealizadores em descobrir como deveria ser feito,
prevalecendo contra o pensamento correto de descobrir se, de fato, deveria ser feito algo.
Averiguando a estrategia do TheGrid de fazer uma campanha baseada em um vıdeo
com pre-venda, observou-se a possibilidade de captar tantos recursos financeiros que vi-
abilizariam a validacao da hipotese supostamente derivada da primeira. Eles obtiveram
50 mil pre-vendas por $96 (WILLIAMS, 2015), antes mesmo do lancamento de uma versao
beta, que demorou 10 meses pra ser liberado pra 100 usuarios apenas. Analisando de uma
maneira rasa, e incomparavelmente um estrategia mais inteligente e serve como uma boa
referencia. Afinal, se a campanha de marketing refutasse a hipotese de que as pessoas
estaria dispostas a contratar um produto neste formato, nao haveria porque investir re-
cursos na solucao. Esta e uma suposicao de onde se tira alguma licao por ser um caminho
alternativo ao tomado pelo GoPages, mas e correto afirmar que na realidade ha diversos
outros fatores os quais nao e possıvel levantar informacoes. Nao e possıvel saber, por
exemplo, quanto recurso foi necessario para a campanha do TheGrid, bem como quais
estrategias foram executadas antes desta sem que tenham publicado.
De todo modo, voltando para a realidade do GoPages e com a conviccao da equipe
na epoca, o primeiro ciclo contruir-medir-aprender foi razoavelmente pequeno e livre de
riscos. Limitou-se a fonte de conteudo a ser buscado e o volume de informacoes obtidos
para a funcionalidade de criacao automatizada do site, sendo estes os passos percorridos:
• Construir: Um algoritmo capaz de obter dados exclusivamente do Facebook
• Medir: O tempo para obtencao dos dados e a frequencia que eles poderiam ser
atualizados automaticamente
• Aprender: As limitacoes tecnicas da funcionalidade basica do produto
Por fim o ciclo foi percorrido com sucesso. Com 2 semanas de trabalho em meio
expediente de 2 desenvolvedores chegou-se a um algoritmo capaz de obter as informacoes
em 20 segundos, respeitando os limites de requisicoes impostos pela API do Facebook
e atualizando os dados sempre que fosse atualizados na plataforma. As informacoes de
perfis das empresas eram:
• Descricao
45
• Horario de funcionamento
• Telefone
• Local
E evidente que eram informacoes simplorias, mas eram suficientes pra criar uma
especie de cartao de visitas online para os usuarios. Haviam muitos desafios pela frente,
sobretudo da aderencia dos usuarios a um site simplesmente com essas informacoes.
Fazendo valer o objetivo deste trabalho e analisando a aplicacao da metodologia neste
estudo de caso, conclui-se que a o levantamento de hipoteses e algo mais complexo do
que pode parecer. Nao existirao apenas validacoes com os clientes, pelo contrario, serao
comum as validacoes internas. Isso nao e previsto de maneira clara por Ries (2011),
criando uma situacao em que os desenvolvedores nao tenham uma clareza se estao seguindo
a rigor as praticas sugeridas. E um gap observado por este estudo que espera-se contribuir
de alguma forma para formalizacao de melhorias futuras.
3.2.1.1 Levantamento de hipoteses
“E possıvel oferecer um produto que crie sites de forma autonoma com os
recursos disponıveis.”
Como ja foi dito, esta hipotese foi validada e o aprendizado foi de que seria algo
trabalhoso. Com isso a equipe decidiu integrar apenas com o Facebook para gerar o sites
automaticamente.
“Existe uma parcela dos possıveis clientes que so pagarao por um produto que
crie sites automaticamente.”
Essa hipotese foi validada com base num relatorio feito por um dos colaboradores o
qual ele abordou 357 possıveis clientes. Dentre os clientes que mostraram interesse, suas
respostas para a pergunta “Por que voce ainda nao tem um site?”, foram, em maioria,
relacionadas com a falta de habilidade ou de tempo para utilizar um construtor de sites.
Portanto o fato de terem ficarado interessados na proposta do GoPages e resistentes as
solucoes ja existentes foi interpretado pela equipe como um sinal de a automatizacao era
46
um fator determinante para sua escolha. O aprendizado foi de que o diferencial era valioso,
nos dando respaldo futuramente pra exaltar essa funcionalidade com maior evidencia do
que a possibilidade de fazer alguma customizacao no site.
“Nao haverao muitas rejeicoes pelo fato de ter integracao apenas com o Face-
book.”
Houveram questionamentos sobre integracao com outras redes, principalmente Ins-
tagram. Mas nao tiveram muitos casos em que isso fosse fosse determinante. Durante
uma rodada de contatos em que o publico alvo seriam profissionais de musica, a inte-
gracao com o servico SoundCloud1 foi colocada como condicao por 5 possıveis clientes,
mas este numero nao foi considerado grande o suficiente para justifica mudancas no rumo
do projeto. Portanto a hipotese foi considerada validada.
“E necessario implementar um editor de layout para os usuarios adequarem
ao seu gosto.”
Este e um item que foi validado, mas houveram pontos de vista divergentes na equipe.
Pra validar a hipotese foi feita uma pergunta direta aos clientes via contatos telefonicos
ou por e-mail: “E necessaria alguma ferramenta pra edicao do layout?”. A esmagadora
maioria dizia que sim, mas para parte da equipe a validacao nao teve um bom metodo,
de forma que mesmo tendo a resposta positiva dos clientes isso nao mostrava o que eles
realmente precisavam. Por fim foi feito um editor, que caiu em desuso apos o pivo.
“Serao necessarios mais do que 3 temas pra desperatar interesse dos clientes.”
Quando foi apresentada uma versao do site aos clientes que tinha dois temas dis-
ponıveis, uma pergunta recorrente foi: “So tem esses dois temas?”, portanto isso nao foi
uma hipotese difıcil de validar. Mas por se tratar de algo que consumia grandes recursos
da equipe, foi decidido gerar apenas mais um tema bem elaborado visualmente antes de
ser investido mais tempo de trabalho dos colaboradores. Os questionamentos dos possıveis
clientes abordados persistiram, validando esta hipotese.
“Sem a possibilidade de uma pre-visualizacao do site o interesse do publico
sera muito baixo.”
1Uma plataforma online de publicacao de audio utilizada por profissionais de musica sediado emBerlim, Alemanha, fundado por Alexander Ljung e Eric Wahlforss em Agosto de 2007.
47
Inicialmente o GoPages nao tinha a funcionalidade de pre-visualizacao do site do cli-
ente, entao durante o processo de venda eram apresentados sites de clientes atuais como
portifolio. Mas, possivelmente por se tratar de uma ideia inovadora, os clientes estavam
muito ceticos. A fim de validar essa hipotese, a equipe decidiu gerar os sites manual-
mente antes dos clientes a serem abordados. A reacao dos clientes, segundo o profissional
responsavel pela venda, era extremamente mais receptiva. Validando a hipotese e con-
vencendo a equipe a desenvolver esta funcionalidade.
“Os usuarios serao capazes de configurar o domınio de seu site sem a neces-
sidade de uma equipe de suporte.”
Pra validar essa hipotese foi decidido criar uma pequena pagina explicando como o
usuario deveria proceder com o registro do domınio no servico chamado Registro.br2.
Ainda assim houve muita dificuldade dos clientes, refutando esta hipotese. Foi decidido
entao que este seria um servico de suporte opcional na contratacao de uma licenca do
GoPages, alem de uma reformulacao da pagina de ajuda.
“Num prazo de 6 meses desde o lancamento da primeira versao, sera possıvel
ter maior receita com a venda de licencas do GoPages do que a venda de
servicos de desenvolvimento de sites na Algorich.”
Essa foi a hipotese mais importante deste estudo de caso, por ter sido responsavel
pelo pivo efetuado pela equipe. Apos 6 meses, os numeros mostraram que foi refutada. O
aprendizado e decisao tomada pela equipe serao discutidos posteriormente neste trabalho.
3.2.2 Menor produto viavel
Este e um item crucial pra analise deste estudo de caso. Primeiro por ser o assunto mais
discutido dentre as praticas indicadas pela metodologia, segundo que ha uma grande
oportunidade de comparar de forma direta com o MVP projetado pela startup TheGrid.
Na concepcao do GoPages foram levantadas algumas possibilidades de escopo do me-
nor produto viavel. De forma macro, as discussoes se baseavam em:
2Desde 1995, o Registro.br cuida do registro de nomes de domınios, da administracao e da publicacaodo DNS (Sistema de Nome de Domınios) para o domınio ”.br”, alem dos servicos de distribuicao emanutencao de enderecos Internet.
48
• Quais APIs de redes sociais integrar para a elaboracao automatizada do conteudo
dos sites
• Quantidade mınima aceitavel de layouts para o usuario optar durante a criacao do
site
• Incluir ou nao a possibilidade do usuario ter conteudo customizavel
• Permitir ou nao ao usuario personalizar detalhes visuais de seu site gerado
• Implementar ou nao um meio automatizado de contratacao e pagamento da licenca
de uso
• Oferecer ferramentas para analises estatısticas de acesso
Pra definir o escopo de algo que fosse o suficiente pra percorrer o ciclo construir-medir-
aprender, foi necessario focar no que era necessario aprender. Ou seja, quais hipoteses
deveriam ser validadas primeiro. Como ja foi dito neste trabalho, nao e o cliente, mas
nossa hipotese acerca do cliente que puxa o trabalho do desenvolvimento do produto e de
outras funcoes.
A partir das hipoteses levantadas e ja apresentadas neste trabalho, o MVP que foi
apresentado a um cliente com intuito efetivo de vendas teve as seguintes caracterısticas:
• Nao existia um site do GoPages
• A geracao dos sites automatica, mas iniciada com um processo manual da equipe
• Integracao apenas com o Facebook para capturar as informacoes do site:
– Nome da empresa
– Descricao
– Missao
– Horario de funcionamento
– Telefone
– Local
• O site gerado tinha as seguintes paginas:
49
– Principal: com descricao, horario de funcionamento e telefone
– Sobre: com descricao completa, missao e o endereco
– Contato: com telefone, e-mail, um formulario para envio de contato e um mapa
do local
• A configuracao do domınio era feita de forma manual pela equipe do GoPages
• O pagamento nao era feito atraves da plataforma
Esse escopo era pequeno, porem entregava valores o suficiente pra dar inıcio aos
contatos com possıveis clientes e validar novas hipoteses. O GoPages naquele momento
tinha baixıssimo potencial de escala, principalmente por depender de muitos processos
manuais durante a venda, Mas exigiu pouco investimento dos socios, certamente muito
menos do que a equipe do The Grid investiu, por exemplo.
Sendo assim, um exemplo de site gerado pelo MVP do GoPages esta ilustrado pela
figura 8:
Figura 8: Trecho de site gerado pelo MVP do GoPages
50
3.2.3 Pivo
Regularmente os socios da Algorich, juntamente com os envolvidos no desenvolvimento
do GoPages, discutiam a respeito da continuidade do projeto com a proposta inicial.
E comum que sejam feitos diversos pequenos pivos durante a vida de uma startup que
segue a metodologia discutida neste trabalho, mas no caso do GoPages foi apenas um ate
entao. Antes de detalhar o novo produto que se formou, sera discutido como foi feito esse
processo pelos empreendedores.
A cada ciclo construir-medir-aprender houve de fato um aprendizado, mas por vezes
nao havia conclusao o suficiente para levar a alguma mudanca drastica na concepcao do
projeto. A maioria das hipoteses eram validadas, o que nao e exatamente uma boa metrica
por indicar um possıvel enviesamento na sua elaboracao, mas dava confianca a equipe de
que estavam no caminho certo. Portanto as discussoes sobre pivo eram breves e unanimes:
nao havia porque pivotar.
E verdade que, caso os empreendedores dispusessem de maior volume de recursos seria
possıvel ousar mais nas hipoteses, abrindo oportunidades pra mudar o produto, pivotar
e encontrar seu lugar no mercado de forma agil. Evidencia-se portanto algo que nao e
tao claro nesta pratica proposta por Eric Ries: Pivotar pode ser caro pra uma empresa
muito pequena, mesmo que a longo prazo traga grande economias. O receio de encarar
grandes mudancas e uma escassez de recursos pode gerar impacto pessimista nas raızes
da aplicacao do Lean Startup, formando um efeito em cadeia que torna a tecnica de Pivo
uma realidade questionavel pra algumas empresas.
De todo modo, mesmo que de forma tardia e apos uma serie de hipoteses validadas,
a equipe do GoPages se deparou com uma hipotese derradeira:
“Num prazo de 6 meses desde o lancamento da primeira versao, sera possıvel
ter maior receita com a venda de licencas do GoPages do que a venda de
servicos de desenvolvimento de sites na Algorich.”
Se tratando de uma empresa focada em prestacao de servicos, sem investimento e
dependendo de receita constante, foi necessario levantar esta hipotese, mesmo que levando
em conta fatores externos ao GoPages em si. Mas uma importante decisao estrategica foi
tomada a seu favor: Toda negociacao em que um cliente solicitasse a Algorich um site que
pudesse se enquadrar, mesmo que parcialmente, com a proposta do GoPages, este seria
oferecido antes de um orcamento tradicional de site personalizado.
51
Passado o prazo estipulado, com 33 licencas do GoPages vendidas, sendo 19 anuais
e 14 semestrais, totalizando aproximadamente R$10.651,20 de receita. Comparado com
aproximadamente R$19.000 em receitas de prestacao de servicos de desenvolvimento de
sites, o projeto chegou a uma importante hipotese invalidada e os motivos da recusa dos
clientes pelo produto foram os mais variados. Por vezes o site exigia que o conteudo
deveria ser personalizavel, outras vezes os temas desenvolvidos nao se aplicavam e haviam
aqueles tambem que nao tinham um perfil da empresa no Facebook.
A difıcil, porem lucida e objetiva decisao de pivotar veio da necessidade da entrega
rapida de um site para um cliente que ficaria satisfeito com o layout gerado pelo GoPages,
porem precisava de paginas com conteudo editavel. Um dos envolvidos no projeto teve
a ideia de vender o tradicional servico de desenvolvimento de site personalizado, porem
utilizando o GoPages como base. Formava-se uma nova hipotese:
“E possıvel utilizar o GoPages como ferramenta interna da Algorich para
geracao de sites, agregando funcionalidades que se fizerem necessarias e gas-
tando menos tempo que com as ferramentas atuais”
A integracao com o Facebook passaria a ser vendido como um atributo que traria mais
valor para o servico ja prestado de desenvolvimento de sites e gastaria menos recursos da
empresa. O primeiro ciclo deste novo MVP foi um sucesso: em duas semanas o cliente
recebeu um site com as especificacoes desejadas pagando o mesmo valor que pagaria pelo
desenvolvimento recorrente da empresa, que era aproximadamente 8 vezes maior que uma
anuidade do produto. A grande diferenca e que o GoPages deixaria de ser um produto,
se tornando algo transparente e embutido no servico prestado. Este caso mostrou que um
pivo pode fazer um produto deixar de existir sem o empreendedor recomecar do zero.
Por fim, a ferramenta estava sendo util pra gerar sites simples, porem na medida da
necessidade do cliente, sendo responsıvel e com um visual agradavel, se tornando uma
especie de site de segunda linha da Algorich para clientes que tivesse um orcamento
limitado.
Este pivo se enquadra como “Pivo Zoom-out”, segundo a classificacao sugerida por
Eric Ries. Ou seja, todo o produto passou a ser parte de algo novo, que seria uma mo-
dalidade diferenciada de servico oferecido pela empresa Algorich. Um otimo exemplo
de pivo de um negocio que se enquadraria nessa mesma classificacao e o proprio Face-
book. Inicialmente, ainda quando se chamava Facemash, a proposta era apenas exibir
duas fotos as quais o usuario poderia “curtir” uma delas. Hoje isso se tornou apenas
52
uma funcionalidade inserida em um proposito muito maior, que e o compartilhamento de
conteudo.
Um exemplo de site gerado pela ferramenta GoPages apos o pivo esta ilustrado a
figura 9:
Figura 9: Trecho de site gerado pelo GoPages apos pivo
53
4 Conclusoes
Este estudo de caso nao foi exaustivo, havendo espaco para trabalhos semelhantes que
levantem mais informacoes relevantes que nao puderam ser observadas. Mas o grande
diferencial foi a possibilidade de analisar o Lean Startup de maneira fiel a metodologia de
trabalho escolhida, ou seja: foi feito um estudo empırico da aplicacao da metodologia no
contexto onde ocorre naturalmente, nao havendo um enviesamento em funcao da pesquisa.
Dito isso, com base na observacao e vicencia deste autor, a metodologia se mostrou
valida e eficaz ao que se propoe. Mas a maneira que esta sendo difundida na internet
abre precendentes para uma interpretacao ingenua e super otimista. E errado pensar que
existe uma receita para o sucesso o qual basta seguir um passo a passo. Lean Startup
mostrou ter dois pilares: a reducao de desperdıcios e o aprendizado constante, apenas
isso. Todos os benefıcios aqui citados, e outros pulverizados pela rede mundial de com-
putadores, podem ser derivados das consequencias do exito destas duas propostas. O que
nao necessariamente levara ao sucesso, mas nao havera grandes perdas em caso de falha.
4.1 Aspectos positivos
Os resultados deste estudo de caso indicaram uma real reducao dos custos desnecessarios
no desenvolvimento de um negocio digital. A mentalidade de nao desenvolver antes de
apresentar solucoes para o mercado evitou, por exemplo, que a equipe investisse tempo
em algoritmos para integracao do GoPages com plataformas sociais como Instagram e
LinkedIn. Um contraponto a essa conclusao e que tal atitude poderia ter sido tomada
independente dos empreendedores terem seguido a metodologia ou nao, mas o intuito
aqui e partir do pressuposto que a equipe nao tenha experiencias anteriores que possam
interferir no experimento. Em 2011, por exemplo, a mesma equipe envolvida no GoPages
tentava emplacar outra startup chamada MeuEvento.com, uma plataforma para venda
de inscricoes online em eventos academicos e empresariais. Este projeto contou com
nada menos que 6 meses de investimento de aproximadamente 12h diarias de trabalho
54
antes mesmo de ser apresentada qualquer versao para o cliente. Grande foco estava em
funcionalidades de um layout personalizavel para a pagina gerada pela plataforma. Apos o
lancamento, em 3 meses de venda, uma decepcionante metrica: nenhum cliente optara por
fazer qualquer tipo de personalizacao do layout. Foi um grande custo de desenvolvimento
desperdicado, mesmo que tenha sido de profissionais em fase academica no seu inıcio de
carreira. Entao pior que isso foi o grande custo de oportunidade, pois cresciam no mercado
concorrentes como o Eventick e principalmente a globalizacao do EventBrite. Portanto,
este relato mostra que num cenario de pouca experiencia profissional uma boa teoria como
as discutidas neste trabalho se mostram bastante produtivas.
Como dito por Eric Ries, um grande erro dos empreededores e tentar tracar um plano
de negocios excessivamente detalhado e baseado no desconhecido. Em startups, o desco-
nhecimento do mercado e algo ainda mais comum devido ao alto nıvel de inovacao. Isso
leva muitos empreendedores ao erro de abrirem mao de um plano de negocios por ficarem
desacreditados pelo excesso de incertezas, sendo este inclusive um fato no desenvolvimento
do MeuEvento.com. Portanto, um aspecto positivo do Lean Startup e um adequamento
a natureza das startups e principalmente de seus empreendedores.
Outro fator de destaque positivo e que a metodologia vem sendo utilizada por gran-
des empresas de sucesso, como Spotify, Dropbox, PayPal e Zappos. Isso faz com que a
metodologia esteja em evidencia, gerando bastante discussao a seu respeito e uma con-
tribuicao direta destas grandes intituicao ao adapta-la as suas realidades ou divulgarem
suas experiencias.
Por fim, o maior aspecto positivo observado e a contribuicao academica da meto-
dologia para profissionais de TI. Muitas vezes, como no objeto de estudo de caso deste
trabalho, os empreendedores liderando as startups sao profissionais formados em Ciencia
da Computacao, Sistema de informacao e afins, carecendo de uma bagagem teorica para
desenvolvimento de negocios tao abordadas na Engenharia de Producao, por exemplo.
O surgimento desta metodologia e reflexo do hiato que ha no meio academico entre
codificacao e especificacao de negocios que envolvem software. E uma reacao espontanea
do mercado a visao de que sao mundos distantes, como se o programador que participa do
desenvolvimento devesse aprender apenas tecnicas de como codificar, nao o que codificar.
55
4.2 Aspectos negativos
O primeiro ponto a se destacar como negativo e a sensacao de se estar diante de um hype1.
Hoje em dia e comum que algumas teorias sejam distorcidas em funcao da maneira que
sao veiculadas na internet e eventos, sobretudo quando o assunto e empreendedorismo. As
proprias metodologias viram produto num mundo especulativo onde o empreendedorismo
de palco faz sucesso. Com o decorrer do tempo sera possıvel ler melhor se o Lean Startup
esta a seguir este rumo, mas o risco em si e um aspecto negativo.
Foi observado tambem que a aplicacao dessa metodologia nao e tao simples quanto
na teoria. Empresas muito pequenas nao podem se dar ao luxo de mudancas constantes,
premissa basica do Lean Startup. Por mais que nao seja um problema da metodologia em
si, mas sim do fato de algumas empresas terem apenas uma unica “bala de prata”, isso
instiga o questionamento se a metodologia e satisfatoriamente compatıvel com negocios
neste cenario. Vale ressaltar que nao foi evidenciado que a metodologia traga prejuızos ao
empreendimento, mas por vezes parece ser indiferente, abrindo uma lacuna para trabalhos
futuros que tragam melhorias as praticas aqui apresentadas. Uma analise quantitativa
poderia, neste caso, trazer dados para uma discussao detalhada. Ate porque pivotar nao
e um requerimento da metodologia, ha apenas diretrizes, conforme foram fundamentadas
neste trabalho, de como agir caso se faca necessario um pivo.
Por ultimo, um aspecto negativo que obviamente nao e em funcao da metodologia,
mas contribui para uma discussao etica que tem acontecido no mundo do software: o vo-
lume de Vaporwares que tem surgido. Vaporware (ou em ingles britanico: “Vapourware”)
e um software ou hardware que e anunciado por um desenvolvedor muito antes do seu
lancamento, mas que nunca chega a entrar em producao, tenha ou nao seu ciclo de de-
senvolvimento sido postergado.
E exatamente o que parece ter acontecido com o TheGrid, que foi, de certa maneira,
aplaudido neste trabalho. Eles postergaram o lancamento diversas vezes antes de ter um
beta restrito a poucos usuarios. Como dito, isso nao acontece em funcao da metodologia,
longe disso, e um fenomeno muito anterior a isso. Mas anunciar o que se pretende vender
antes de fato construir e algo que Eric Ries prega por trazer aprendizado, mas isso pode
levar empreendedores a ir longe demais, como no exemplo apresentado.
1Hype e a promocao extrema de uma pessoa, ideia ou produto sobre o qual todos falam e comentam.Geralmente e algo passageiro, como o assunto da moda. A palavra deriva de hiperbole, figura de linguagemque representa o exagero de algo ou uma estrategia para enfatizar alguma coisa.
56
4.3 Trabalhos futuros
A metodologia de trabalho cientıfico utilizada trouxe uma visao qualitativa do tema.
Com diversos casos de sucesso e insucesso de sua aplicacao espalhados pelo mundo, ja
e possıvel levantar dados quantitativos. Assim poderiam ser levantados numeros que
questionem numa visao mais cientıfica as tecnicas abordadas. Afinal, tomando como
exemplo uma pesquisa elaborada na regiao de Porto Alegre, no Rio Grande do Sul, 40%
das startups utilizam apenas Lean Startup, 20% utilizam tanto Lean Startup como Design
Thinking, 20% nao utilizam nenhuma metodologia, 10% utilizam metodologia propria, 5%
utilizam apenas Design Thinking e outros 5% nao utilizam nenhuma por nao conhecer as
metodologias existentes (MORAES, 2013).
Outra possibilidade de trabalho futuro, que pode ser um tanto cara, mas muito en-
riquecedora, e a criacao de um experimento controlado da aplicacao do Lean Startup.
Ou seja, a criacao de uma empresa com o proposito de seu estudo, nao necessariamente
motivadas pelo mercado.
Por ultimo, com o intuito de gerar mais dados comparativos do Lean Startup com
um modelo de criacao de negocios tradicional, sugere-se uma exploracao de forma mais
detalhada como o segundo se aplica, ao contexto de startups, dando continuidade as
afirmacoes feitas por Blank, sobretudo apos uma possıvel adaptacao da academia nas areas
de administracao e Engenharia de producao ao cenario atual do mercardo de startups.
57
Referencias
A. BEEDLE, M.; SCHWABER, K. Agile Software Development with Scrum. [S.l.]:Prentice Hall, 2002. ISBN 0130676349.
BECK, K. Programacao extrema (XP) explicada: Acolha as mudancas. [S.l.]: Bookman,2004.
BECK, K. et al. Manifesto for Agile Software Development. 2001. Disponıvel em:<http://agilemanifesto.org>. Acesso em: 02/08/2011.
BLANK, S. The Customer Development Methodology. Apresentacaono Roundtable on Entrepreneurship education. 2008. Disponıvel em:<http://www.slideshare.net/venturehacks/customer-development-methodology-presentation>.
CHENG, T. Controlling and monitoring agile software development in three dutchproduct software companie. 2009.
FABER, M. MVP dilemma: fat vs. lean, lovable vs. laughable? 2015. Disponıvel em:<http://sparksolutions.co/2015/12/mvp-dilemma-fat-vs-lean-lovable-vs-laughable/>.
GIL, A. C. Como elaborar projetos de pesquisa. Sao Paulo: Atlas, 1991.
GITAHY, Y. Como funciona o conceito de Lean Startup? 2011. Disponıvel em:<http://exame.abril.com.br/pme/dicas-de-especialista/noticias/como-funciona-o-conceito-de-lean-startup>.
GROUP, T. S. The CHAOS Report. [S.l.], 1994.
JEFFRIES, R.; ANDERSON, A. Chet. Extreme Programming. Boston: [s.n.], 2001.
JONES, D.; WOMACK, J. P. A mentalidade enxuta nas empresas : elimine o desperdıcioe crie riqueza. [S.l.]: Editora Campus, 2004.
KNIBERG, H. Scrum and XP from the Trenches : How we do scrum. [S.l.]: InfoQ, 2007.
LINHARES, M. C. UtilizaCAo da metodologia lean startup para criaCAo de umastartup: Analise do e-commerce maisfloresbh. Belo Horizonte, 2012.
MARMER, M. et al. Startup genome report. Startup Genome Report, 2011.
MARY POPPENDIECK, T. P. Lean Software Development: An Agile Toolkit. [S.l.:s.n.], 2003.
MAURYA, A. Running Lean: Iterate from plan a to a plan tha works. [S.l.]: O’Reilly,2012.
58
MORAES, V. G. C. Marcelo Rogoski de. Metodologias aplicadas em startups inovadorasno desenvolvimento de projetos de sucesso. XXIII Seminario nacional de parquestecnologicos, 2013.
PAGAN, B. Lean Startup MVP: How To Make Meaningful Products. 2015. Disponıvel em:<https://brianpagan.net/2015/lean-startup-mvp-how-to-make-meaningful-products/>.
PRESSMAN, R. S. Engenharia de software. [S.l.]: McGraw-Hill, 2006.
QUMER, A.; HENDERSON-SELLERS, B. A framework to support the evaluation,adoption and improvement of agile methods in practice. 2008.
RIES, E. The lean startup: how today’s entrepreneurs use continuous innovation tocreate radically successful businesses. Harvard: [s.n.], 2011.
SEBRAE, P. O que e uma empresa startup? 2012. Disponıvel em:<https://www.sebrae.com.br/sites/PortalSebrae/sebraeaz/o-que-e-uma-startup,616913074c0a3410VgnVCM1000003b74010aRCRD>.
SILVA, J. P. P. A. A necessidade de planejamento estrategico para startups do mercadode internet. Sao Paulo, 2012.
TELES, V. M. Extreme Programming : Aprenda como encantar seus usuariosdesenvolvendo software com agilidade e alta qualidade. Sao Paulo: Novatec, 2004.
VIANNA, M. Design Thinking: inovacao em negocios. [S.l.]: MJV, 2011.
VIEIRA, E. Os bastidores da Internet no Brasil : As historias de sucesso e de fracassoque marcaram a web brasileira. Sao Paulo: Manole, 2003.
WILLIAMS, O. This is what The Grid’s ‘AI’ website builder looks like. 2015. Disponıvelem: <http://thenextweb.com/dd/2015/07/31/this-is-what-the-grids-ai-website-builder-looks-like/>.
YIN, R. K. Estudo de Caso: Planejamento e Metodos. Porto Alegre: Bookman, 2003.
Top Related