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

• E-mail

• 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

– E-mail

– 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.