MVP: Como Tirar sua Ideia do

Papel
Da definição da ideia à captação de clientes,
cada passo é fundamental.

Diego Hernandes
Esse livro está à venda em http://leanpub.com/livro-mvp

Essa versão foi publicada em 2017-03-22

ISBN 978-1-63535-594-9

This is a Leanpub book. Leanpub empowers authors and

publishers with the Lean Publishing process. Lean Publishing is
the act of publishing an in-progress ebook using lightweight tools
and many iterations to get reader feedback, pivot until you have
the right book and build traction once you do.

This work is licensed under a Creative Commons

Attribution-NoDerivatives 4.0 International License
Conteúdo

Dedicatória . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Agradecimentos Especiais . . . . . . . . . . . . . . . . . . ii

Sobre o Autor . . . . . . . . . . . . . . . . . . . . . . . . . iii

Prefácio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv

Como Ler Esse Livro . . . . . . . . . . . . . . . . . . . . . v

Contribua . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

1 - MVP: Produto Minimalmente Viável . . . . . . . . . . 1

2 - Descartando Ideias . . . . . . . . . . . . . . . . . . . . . 4
2.1 - Como prever o sucesso de um projeto? . . . . . . . 6

3 - O Valor do Tempo . . . . . . . . . . . . . . . . . . . . . 8
3.1 - Não Confie na Calculadora . . . . . . . . . . . . . 8
3.2 - Afinal Quanto Vale o Tempo? . . . . . . . . . . . . 10

4 - Dividir Para Conquistar . . . . . . . . . . . . . . . . . . 11

4.1 - Síndrome do Burro do Shrek . . . . . . . . . . . . 12
4.2 - Entregue Sempre . . . . . . . . . . . . . . . . . . . 13
4.3 - Mas o Cliente Tem Pressa! . . . . . . . . . . . . . . 16
4.4 - Mantendo a Sanidade . . . . . . . . . . . . . . . . 16
CONTEÚDO

4.5 - Onde entra o Scrum Nessa Hitória? . . . . . . . . . 17

4.6 - Orçamento . . . . . . . . . . . . . . . . . . . . . . 17
 Dedicatória
Aos meus pais, por seu amor incondicional.
 Agradecimentos Especiais
CODECASTS¹
Aos meus amigos e parceiros do CODECASTS Vinicius Reis²
e Fábio Vedovelli³, por me apoiarem e ajudarem esse projeto
ser possível.

Kino Contabilidade⁴
Ao meus amigos e parceiros Felipe e Daniel, idealizadores do
projeto que uso como exemplo no presente livro.

Rafael Gomes⁵
Por me inspirar em manter o conhecimento desse livro aberto
e acessível.

Victor Rodrigues⁶
Ao meu amigo e excepcional Designer Gráfico, pela linda
obra de arte da capa desse livro.

Em construção.

¹https://codecasts.com.br
²https://github.com/vinicius73
³https://github.com/vedovelli
⁴https://sejakino.com.br
⁵https://github.com/gomex
⁶mailto:vitzz.rodrigues@gmail.com
 Sobre o Autor
Diego Hernandes é desenvolvedor web a aproximandamente 10
anos. É certificado como Zend Certified PHP Enginner⁷, e já de-
senvolveu e gerenciou diversos projetos web de missão crítica.
Atualmente, Diego divide seu tempo entre as atividades de CTO na
Kino Contabilidade Online⁸ e a producão de conteúdo no CODE-
CASTS⁹.
⁷https://www.zend.com/en/yellow-pages/ZEND026619
⁸https://sejakino.com.br
⁹https://codecasts.com.br
 Prefácio
A ser escrito.
 Como Ler Esse Livro
Esse livro está (planejadamente) dividido em 20 capítulos curtos,
onde cada um tem um tema definido, um respectivo problema e
minha experiência em como lidar com tais problemas.
Não existe órdem específica para leitura, sinta-se avontade para ler
capítulos individuais, porém, a leitura em órdem é recomenda, visto
que os capítulos estão organizados pela ordem cronológia de um
projeto.
 Contribua
Esse livro é livre, você pode ler, vender, basicamente fazer qualquer
coisa com ele.
A licença completa se encontra na contra capa e na página do livro.
Caso esse livro lhe seja útil, você pode ajudar o mesmo de duas
formas:

Fazendo uma Doação

Para doar, basta comprar novamente o livro na página da
Leanpup, selecionando o valor que deseja doar.

Revisando e contribuindo com melhorias no texto

Sim, você pode acessar diretamente os fontes desse livro e en-
viar pull requests de melhorias, no Github: https://github.com/hernandev/mvp
como-tirar-sua-ideia-do-papel¹⁰

¹⁰https://github.com/hernandev/mvp-como-tirar-sua-ideia-do-papel
 Introdução
Desde meus primeiros pequenos projetos de software, sempre tive
alguma dificuldade em gerenciar recursos, tempo, e de fazer previ-
sões acertadas sobre um projeto.
Com o tempo, as demandas de projetos (cada vez maiores) me
fizeram aprender, da maneira árdua, aquilo que era fundamental
colocar em prática. Ou seja, tive a oportunidade de provar empiri-
camente muitas das teorias sobre desenvolvimento de software.
Esse livro nasce do meu profundo desejo de compartilhar minhas
técnicas e soluções com você, desenvolvedor, e assim, talvez ajudá-
lo a tomar decisões de projeto mais acertadas.
Como você pode ver no título do livro, vamos falar de MVP. Não
se preocupe se a sigla não quer dizer nada pra você ainda, acredite,
em breve ela irá.
Ao longo dos capítulos, irei apresentar alguns conceitos, que serão
descritos como relatos de projetos nos quais eu participei.
Esteja você desenvolvedor, com uma ideia para um nova Startup ou
tenha sido contratado para desenvolver uma, esse livro busca lhe
dar dicas valiosas de como evitar os mais comuns erros de projeto,
que podem levar seu projeto ao fracasso.
Você talvez já tenha se encontrado em um dos cenários a seguir:

• Uma ideia que nunca sai do papel por falta de planejamento

adequado.
• Um contrato desperdiçado, por conta da insegurança em
entregar um projeto de grande porte em tempo hábil.
• Um projeto de médio ou grande porte indo por água a baixo,
sem se quer que você entenda o motivo.
Introdução viii

• Um cliente/investidor completamente insatisfeito com o re-

sultado, que até saiu dentro do prazo, mas atende as expecta-
tivas.

Eu preciso ser sincero, já estive em todas as posições acima e sei o

quão frustrante é.
Esse livro tenta atacar os pontos que levam a esses cenários acon-
tecerem.
Boa Leitura!
 1 - MVP: Produto
Minimalmente Viável
Antes de falarmos sobre ideias mais complexas e práticas, precisa-
mos dar um passo atrás e falar sobre o básico.
Se você nunca viu o termo MVP na vida, é uma honra para mim,
apresentá-lo. MVP é uma sigla para minimum viable product.
Podemos traduzir para o bom português como produto minimal-
mente viável.
O que isso quer dizer? Não é algo complexo. Imagine a sua grande
ideia de aplicativo, o quão mínimo ele pode ser desenvolvido para
que você possa colocar a ideia no ar, conseguir clientes e validar a
ideia do projeto?
Vamos detalhar um pouco mais. Um software de sucesso não tem
absolutamente nada haver com a qualidade da UX, ou mesmo
do quão imteroperavel e testado seu código está. Um software de
sucesso é aquele tem usuários.
Qualidade interna do produto é muito importante, mas não tão
importante quando a validação da ideia.
Se você está lendo esse livro, acredito que tenha interesse em
participar de projetos de grande porte. Imagine o primeiro dia
do projeto, a ideia lhe foi apresentada e você e sua equipe estão
levantando requisitos. Esse ponto é extretamente crucial ao projeto.
Ele é crucial não por quê você precisa detalhar ao máximo tudo
aquilo que deve ser desenvolvido. Justamente pelo contrário, é a
etapa onde você define aquilo que necessita ficar de fora.
Você deve estar pensando que estou louco, mas pare um pouco pra
refletir sobre isso. Dizer não é muito mais importante do que dizer
1 - MVP: Produto Minimalmente Viável 2

sim. Se você incluir muitas funcionalidades na primeira versão, vai

ter meses ou anos de desenvolvimento sem chegar a atender sequer
1 usuário.
Ao invéz disso, por que não listar tudo que a aplicação pode ser ao
invéz do que ela precisa ser?
Vamos lá, se você separar todas as ideias para essa aplicação,
provavelmente será uma lista sem fim, que custa muito caro para
ser desenvolvida.
Se você quer usar seu tempo livre pra desenvolver, irá desanimar
facilmente diante de um roadmap tão gigante.
Você precisa vender a si mesmo (e ao seu cliente/investidor, caso
tenha um), que a aplicação deve fazer menos, muito menos.
Você talvez pense que essa ideia vai completamente na contramão
do senso comum. Uma aplicação completa tem mais chances de
atender melhor o usuário correto?
Não e Sim! Uma aplicação cheia de funcionalidades atende sim,
melhor um usuário na maioria das vezes, porem a forma de se
chegar a uma aplicacão grande não é planejar e desenvolver tudo,
e depois “cuspir” o resultado pro usuário.
Boas ideias evoluem, e uma boa ideia de software, que resolve os
problemas reais, evolui com feedback, e não com arquitetura.
Nesse livro, vamos falar inúmeras vezes do último grande projeto
em que participei, a Kino Contablidade¹¹. Nesse projeto seguimos
fielmente essa ideia de MVP, removemos muitas funcionalidades da
versão inicial, e a medida que o projeto foi sendo concluido, remo-
vemos ainda mais. A primeira versõa estável é aproximadamente
20% do planejado na primeira reunião, e sua primeira reação pode
ser acreditar que isso foi um fracasso.
Mais uma vez, é justamente ao contrário. Esses 20% prontos, nos
possibilitaram colher os primeiros clientes, que com suas neces-
¹¹https://sejakino.com.br
1 - MVP: Produto Minimalmente Viável 3

sidades do mundo real, nos forneceram feedback necessário para

repensar completamente os 80% restantes.

• MVP é sobre os 20%.

• MVP é sobre evoluir os 20% baseado em feedback.
• MVP é sobre validar uma ideia o quão antes possível, e assim
evitar trabalho desnecessário.
• MVP é sobre entregar antes.

Se ainda não está convencido, durante o restante do livro essas

ideias serão melhores ilustradas.
 2 - Descartando Ideias
Acho que nesse ponto, já consegui explicar com clareza o público
alvo desse livro. Basicamente, ele é voltado para desenvolvedores,
que precisam gerenciar um grande projeto próprio ou de terceiros.
Seja qual for seu caso, esse captítulo se aplica a você. Existem duas
regras antes mesmo de orçar um projeto que devem ser seguidas,
na verdade são duas perguntas:

O quão eu acredito no potencial desse projeto?

O quão realista é minha crença sobre o potencial

desse projeto?

Só inicie um projeto, seu ou de terceiros, após refletir com entu-

siamo sobre a primeira pergunta, e refletir duas vezes mais, com
cautela e pés no chão sobre a segunda.
Se você não acredita num projeto, nunca terá forças para finalizá-
lo. É necessário ter convicção para sentir entusiasmo e motivação.
Ideias surreais não irão te motivar por muito tempo. Levar um
projeto meses ou anos a fio, só é possível quando você acredita nele.
Essa parte pode até parecer um pouco empreendorismo de palco,
mas eu provarei o contrário, ao te explicar o que pode dar errado.
Desse ponto adiante, irei me referir a quem encomenda o projeto
como product owner (vide scrum).
O product owner pode ser tanto você, idealizador de um projeto
próprio, ou ainda o cara te contratando para desenvolver o projeto
dele.
Agora que estabalecemos o product owner, podemos lidar com as
situações onde ele lhe culpe pelo fracasso do projeto.
2 - Descartando Ideias 5

• Projeto demorou muito tempo para ficar pronto e perdeu a

oportunidade de mercado
• Projeto ficou pronto a tempo, mas não atrai nenhum cliente.
• Projeto ficou extretamente legal, mas não tem nenhum po-
tencial de monetização.

Como vimos anteriormente, o MVP soluciona o problema do tempo,

já que menos recursos podem ficar prontos para o mercado mais
rapidamente.
Se uma MVP fracassar, o tempo e dinheiro investidos serão muito
menores.
Porem, antes mesmo de levar o MVP a produção, você precisa
acreditar no projeto.
E é agora que chegamos no grande ponto desse capítulo: Saiba dizer
não.
É preciso recusar o projeto. Se é uma proposta para desenvolver para
terceiros, e você não quiser ser grosso, diga que não tem tempo para
assumir tal projeto no momento.
Se quiser ser sincero, diga ao cliente o por quê você não acredita que
esse projeto possa dar certo. Pode ser uma boa hora para ajustar a
ideia para algo mais realista.
Então, vou repetir novamente: Nunca inicie um projeto do qual
não acredite!. Um cliente insatisfeito é muito pior do que um cliente
não atendido.
Se o projeto for seu, não perca tempo com ideias que tem pouca
chance de darem certo. A menos é claro, que queira jogar tempo e
dinheiro fora.
2 - Descartando Ideias 6

2.1 - Como prever o sucesso de um

projeto?

Sim, mesmo que você acredite numa ideia, você ainda precisa
de um pouco mais de realismo antes de decidir ir em frente, eu
prometo atualizar referencias nessa seção, pois não vou conseguir
me lembrar de todos os autores que dizem exatamente o que vou
dizer agora.

Uma startup só irá ter sucesso quando ela resolve

problemas reais, quando ela facilita a vida de al-
guem

Geralmente essa frase vem relacionada com aquela velha história de

como ficar rico. Você vai ver muita baboseira sobre enriquecimento
mas a única coisa que realmente dá pra extrair dessa literatura é que,
de fato, é praticamente impossível ter sucesso sem impacto social.
Quando digo impacto social, não quero dizer que todas as novas
ideias devem ser voltadas a solucionar a fome na áfrica. Na verdade,
basta que sua ideia torna a vida de um grupo de pessoas melhor.
Na Kino, a ideia era muito, muito simples, e foi o que me fez aceitar e
entrar de cara no projeto. Não oferecemos serviços de contabilidade,
oferecemos a desburocratização para empreededores e profissionais
autônomos.
Mesmo que nosso escopo de clientes seja limitado, existem milhões
de prestadores de serviços, completamente perdidos com toda a
burocracia de manter uma empresa em dia com suas obrigaçes
legais.
A Kino nasceu da ideia de que, essas pessoas precisam desses
serviços, e nós, precisamos oferecer os mesmos com a mesma
praticidade com que se pede uma pizza no iFood ou uma corrida
no Uber.
2 - Descartando Ideias 7

Apresentei um pouco da viso geral inicial da Kino, pra lhe ilustrar

na vida real como filtrar ideias que dão certo, você precisa ter um
público alvo mínimo, e seu produto / serviço deve fazer a diferença
na vida dessas pessoas.
Lembre-se: Você quer que as pessoas gastem dinheiro com seus
serviços, você no vai conseguir isso até que o valor real seja claro,
evidente ao cliente. Só é possivel fazer isso causando impacto.
Quando falo sobre o tema acima, não chego nem a empregar o termo
disruptivo, empresas realmente disruptivas são raras. Estou falando
de, fazer alguma diferença na vida dos usuários. Essa diferença pode
ser mínima, mas não tão pequena ao ponto de ser ignorada.
Esse capítulo é de certa forma um pouco abstrato. Tentarei incluir
outros exemplos ao longo dos próximos capítulos para que essas
ideias sejam um pouco melhor exploradas.
 3 - O Valor do Tempo
Um dos erros mais cometidos por desenvolvedores e equipes é er-
rarem miseravelmente a estimativa de tempo (e consequentemente,
o orçamento) de um projeto.
Esse capítulo é uma introdução a orçamentos, e mesmo que você es-
teja para desenvolver um projeto próprio, sugiro que siga o mesmo
com ainda mais vigor do que aqueles que irão desenvolver para
terceiros. Você vai investir algum dinheiro, mas principalmente
muito tempo da sua vida em cima de um projeto. Nada mais justo
que uma ponderada estimativa para entender o quo viável sua ideia
é.

3.1 - Não Confie na Calculadora

Você talvez já deve ter pensado, em algum projeto, da forma que

vou descrever a seguir:
Você tem esse projeto em mãos para desenvolver, estima, devido
a análise de complexidade que irá gastar, sozinho, 400 horas de
desenvolvimento.
Com esses fatos em mãos, chega a conclusão de que, trabalhando
uma média de 8 horas diárias (essa era a quantidade de horas
que você fazia na sua velha firma né? o que pode dar errado?)
durante, em média 21 dias úteis por mês, irá conseguir entregar 168
horas/mês e concluirá o projeto em aproximadamente 2,4 meses.
Você inda pode pensar que alguma coisa pode dar errado, e chegar
a conclusão que sozinho, irá terminar, com folga, em 3 meses.
Veja bem, são 168 horas mês, mas como tem 3 mêses pode fazer 133
horas, com folga e terminar no prazo, de 3 mêses.
3 - O Valor do Tempo 9

Quando você faz a conta na calculadora (não faça orçamentos

de cabeça, você pode se dar muito mal) a conta fecha de forma
estupenda.
Na realidade, as coisas mudam drasticamente.
Vamos atacar todos os problemas de abordagems como essa, pra que
você entenda melhor que nunca deve fazer orçamentos / estimativas
de forma tão simplista.
O primeiro ponto é que nenhum programador (pelo menos no que
eu conheça) consegue manter um bom rendimento por mais de 4
ou 5 horas em um dia. Somos humanos, dependemos de uma mente
afiada para entregar um trabalho de qualidade.
Você pode até trabalhar, por 14 horas em um dia, mas estará
causando mais problemas do que solucionando. É necessário mudar,
no mínimo de projeto para que você consiga manter um rendimento
maior do que esse.
Antes que refute completamente esse ponto, dizendo que você pode
fazer CRUD’s o dia todo, por 14 horas seguidas com o mesmo
rendimento, lembre-se, você poderia ter usado o primeiro dia pra
abrastrair as operações e trabalhado apenas 1 hora por dia, nos dias
sequentes tendo 10 vezes mais rendimento.
Boas ideias surgem de uma mente descansada. É praticamente
impossível pensar claramente quando se está esgotado.
Se você anda trabalhando o dia todo, você está de alguma forma
trabalhando errado. Ou talvez você seja um grande gênio ao qual
eu ainda não tenha tido o prazer de conhecer.
Se você atualizar a conta inicial agora, com esse fato em mãos, irá
perceber que de fato, irá trabalhar cerca de 90 horas à 100 horas mês,
no máximo, sem desperdiçar tempo.
Aquele projeto de 3 mêses com folga, acabou de se tornar um projeto
de 4 mêses, sem folga, e você já se comprometeu com a estimativa.
3 - O Valor do Tempo 10

Se você percebeu o problema nos primeiros dias de trabalho, tudo

bem, quebre o combinado e volte atrás, seja sincero e renegocie. O
grande problema é quando você só percebe a burrada que fez mêses
após o início do projeto.
A deadline vai se aproximando e você vai se desesperando (pelo
menos se for como eu, que ligo e muito pra isso, você também deve
ligar). A pressão não ajuda em nada, ela tira seu foco e o trabalhar
nesse projeto irá parecer um inferno pessoal.
Mas calma, estamos longe de terminar…
Não contabilizamos ainda os dias que sua internet pode cair, e
outros problemas pessoais podem entrar no caminho da conclusão
do projeto.
Não contabilizamos ainda, todo o feedback que as pessoas envolvi-
das demoram dias pra te dar.
Não contabilizamos ainda, que você pode ter errado e feito em
estimar as 400 horas iniciais.

3.2 - Afinal Quanto Vale o Tempo?

Essa é grande pergunta da humanidade, desde a revolução in-

dustrial, e provavelmente antes disso também. Apenas especifique
horas para chegar a um valor, horas devem ser uma estimativa. Não
o elo de um contrato.
Use estimativas em horas como um meio, não um fim.
No próximo capítulo, apresentarei de forma prática, uma forma
alternativa de se calcular estimativas.
 4 - Dividir Para Conquistar
Você talvez já tenha ouvido essa frase em inúmeros locais. Ela se
refere a, ganhar controle por fragmentar as maiores concentrações
de poder, de modo que o mesmo não se mantenha indivualmente.
Apesar de eu ter usado a frase, e ela se encaixar bem como título do
capítulo, não é exatamente disso que irei falar aqui.
Lembra aquele projeto de 400 horas? Como traçar um plano de
trabalho que irá se manter, sem sugar todas suas energias, sem te
fazer cair os cabelos, nem decepcionar ninguém (principalmente, a
você mesmo)?
De modo simples, o que funcionou pra mim, de forma explêndida e
foi novamente comprovado durante o desenvolvimento do MVP da
Kino¹², é tratar o desenvolvimento como vários pequenos projetos.
Vamos chamar esse pequenos projetos de etapas. Vamos fazer pois
é exatamente o que eles são.
Ao invéz de te dar a teoria, vamos falar sobre isso na prática.
Quando primeiramente, eu o Vinicius Reis¹³ analisamos o escopo
do projeto da Kino, tinhamos em mente algo em torno de 800 horas
brutas de desenvolvimento.
Lembre se que eu falei no capítulo anterior, use horas somente como
um meio, não como elo.
Levantamos o escopo inicial do projeto, tudo aquilo que precisava
ser desenvolvido.
Esse escopo, como disse no inicio do livro, foi negociado para ser
reduzido drasticamente, até chegarmos a um escopo de MVP.
¹²https://sejakino.com.br
¹³https://github.com/vinicius73
4 - Dividir Para Conquistar 12

Como desenvolvedor, que precisa botar comida na mesa (mesmo

que as vezes figurativamente), talvez pense negociar um contrato
pra baixo, é algo ruim, visto que irá trabalhar menos, e consecuti-
vamente, receber menos.
É comum pensar assim, porem nada poderia estar mais longe da
realidade. É melhor entregar bem, um escopo menor, e depois
disso, com todos satisfeitos, negociar novamente a continuidade do
projeto e funcionalidades adicionais.
O rumo desse projeto tomou mudanças drásticas, que você irá
acompanhar ao longo desse livro, mas por enquanto, vamos nos
ater aos primeiros dias. Eles são extremamente fundamentais.
O escopo inicial chegamos a 6 mêses de desenvolvimento, até o MVP
da Kino estar concluido, e assim poderíamos iniciar outro estágio,
de funcionlidades adicionais.
Como eu havia dito, a nossa estimativa era de 800 horas, ao longo
de 6 mêses, para 2 desenvolvedores. Uma média de 133 horas por
mês, o que resultam em 66 horas pra cada desenvolvedor.
Como chegamos a conclusão de 6 mêses? Simples, dividimos o
projeto em 6 etapas, 6 pequenos projetos onde todos os envolvidos,
ao final de cada mês, poderiam testar, aprovar e dar seguimento ao
projeto.
Mas calma, vamos entrar em detalhes, mas antes, vou lhe apresentar
um problema de grandes projetos.

4.1 - Síndrome do Burro do Shrek

Mesmo o título sendo meio brega, essa seção é importante. Se

durante os 6 mêses de desenvolvimento, fossemos marcar reuniões e
mandar emails esporádicos sobre o progresso, a ansiedade e falta de
comunicação pode se tornar um fator decisivo ao sucesso do projeto.
4 - Dividir Para Conquistar 13

O cliente vai ficar igual ao Burro do Shrek, perguntando se “já

chegamos” todo dia no Skype, no telefone. Isso gera um desgaste
enorme para ambas as partes.

4.2 - Entregue Sempre

Se você conhece um pouco de scrum, deve estar acostumado com o

termo “Sprint”, uma pequena unidade de tempo, medida em dias
ou semanas, onde um conjunto de tarefas é determinado, e ao
final desse período, o “product-owner” sabe que alguma coisa será
entregue.
O que estou me referindo aqui não é exatamente sobre sprints, é
sobre uma unidade um pouco mais relaxada, que está acima da
sprint.
Dividimos o escopo de trabalho da seguinte maneira:

• Criar uma lista de tudo a ser feito.

• Classificar as tarefas por ordem de dependência (por exem-
plo, Auth vem antes de ACL, etc)
• Dividir o trabalho em unidades de 3 semanas, que vamos
chamar de etapa.
• Reservar uma semana pra ajustes a cada etapa.

Dessa forma, você faz com que o trabalho dite o cronograma, e não
o contrário.
Recuperei aqui do email, o planejamento que fizemos para a Kino,
assim você tem uma versão palpável do que estou falando:
Primeira Etapa

• Desenvolvimento de Interfaces do Sistemas

• Desenvolvimento do esqueleto das distintas áreas do sistema
4 - Dividir Para Conquistar 14

• (1 item reduzido).

Segunda Etapa

• Controle de Contas a pagar

• (2 items reduzidos).

Terceira Etapa

• Assinaturas Recorrentes
• (3 items reduzidos).

Quarta Etapa

• Integração NFSe PBH.

• (2 items reduzidos).

Quinta Etapa

• Sistema de Notificações.
• (5 items reduzidos).

Etapa Final

• Ajustes, Bugs e Melhorias

Veja que a quantidade de items por etapa varia, pois cada item
tinha uma estimativa diferente de trabalho. Mas tinhamos estimado
com segurança, que era possível desenvolver os items de cada etapa
durante 3 semanas.
4 - Dividir Para Conquistar 15

Feito isso, o product owner sabia exatamente, que ao final de 3

semanas, iriamos testar juntos o que foi desenvolvido, e durante
a quarta semana, iriamos fazer correções e ajustes.
Essa é uma forma de não criar o atrito do Burro do Shrek, nós
sabíamos exatamente o tempo que tinhamos pra desenvolver um
escopo limitado. O product owner sabe exatamente quando irá
testar o sistema e dar feedback, e as correções mais urgentes não
iriam ser deixadas para depois.
Encerrada uma etapa, tinhamos uma parte do sistema, pronta,
testada, e as energias renovadas pra iniciar a próxima.
O ciclo se repete, se você ler esse capítulo com calma, perceberá que
é algo realmente simples de se por em prática, mas alguns cuidados
devem ser tomados.

• O product owner precisa entender, antes de qualquer contrato

o modelo a ser seguido.
• Assim como qualquer política, não é possível implementar
sem empenho e responsabilidade entre as partes.

Ainda não disse sobre a etapa final, de ajustes. Mesmo seguindo

essa metodologia, problemas irão aparecer fora do escopo da etapa,
um bug de uma funcionalidade da primeira etapa pode aparecer
somente durante o decorrer da terceira.
Tudo Bem! Existe um momento, ao final onde tudo é retestado, e as
3 semanas da etapa ficam exclusivamente para fechar pontas soltas.
Retestar e assegurar a qualidade do MVP.
Lembra sobre os 6 meses? Basicamente, estipulamos que, o escopo
completo (que havia sido reduzido) poderia ser concluido em 5 itera-
çes de 3 semanas. Como cada iteração tem 1 semana adicional para
correções, chegamos a 1 etapa por mês. 5 mêses de desenvolvimento,
e uma etapa de melhorias.
4 - Dividir Para Conquistar 16

4.3 - Mas o Cliente Tem Pressa!

Não, o cliente não tem pressa, ele somente pensa que tem.
Cabe ao desenvolvedor, explicar minimamente ao proponente, que
“a mona lisa não foi pintada em 10 minutos”. Para que se aja um
mínimo de qualidade, é necessário tempo.
Quando digo tempo, me refiro ao tempo do capítulo anterior, e
não a horas de desenvolvimento. Existem todos os fatores citados
anteriormente a serem levados em conta.
Você pode até expremer 800 horas de desenvolvimento em 2 meses.
Mas não irá conseguir concluir nem a metade do escopo.
Com a correria começa a falha de comunicação, os erros constantes,
e principalmente o retrabalho.
O espaço entre as atividades, o prazo prolongado pra se pensar e
testar software é o que possibilitou o desenvolvimento da Kino se
dar dentro desse espaço de tempo.
Se tivéssemos atacado com unhas e dentes o projeto, pra terminá-
lo em 2 meses, o projeto teria falhado e você provavelmente não
estaria lendo esse livro agora.
Se o cliente exige a urgência, deixe passar.
Se você quer lançar seu produto/startup que tem um software
complexo em 2 meses, não o faça.
Simplesmente pelo fato de que, é impossível fazer com qualidade.

4.4 - Mantendo a Sanidade

Sabe quando falamos dos problemas pessoais? Basicamente, nesse

modelo, você fica livre para tê-los. O projeto, estruturado dessa
forma vai suportar alguns dias de folga, você vai ter tempo livro
pra passar com sua família e resolver seus problemas pessoas.
4 - Dividir Para Conquistar 17

Vai poder ainda, dar manutenção naquele projeto de um cliente

antigo, ir ao uma conferência, quem sabe pegar um freela rápido
entre ou durante as etapas.
Estruturando seus projetos dessa forma, você garante que o projeto
não irá sugar suas forças. Você pode inclusive, o fazer de forma
paralela com outras atividades que demandam igualmente tempo
(inclusive seu trampo CLT, se tiver coragem).

4.5 - Onde entra o Scrum Nessa Hitória?

Lembra que falamos sobre sprints certo? Você não precisa usar
scrum por completo (apesar de eu gostar muito). Se você optar por
usar, deixo como dica definir cada semana de uma etapa em sprints.
Dessa forma, cada etapa terá 4 sprints.
Você pode fazer isso, no primeiro dia de uma etapa, olhar as
funcionalidades a serem desenvolvidas e quebrá-las em tarefas.
Dessa forma você tem um controle refinado do progresso da etapa,
e consecutivamente do projeto.
A parte interessante é que, você não precisa criar 1000 entradas no
backlog de tudo que tem que ser desenvolvido durante o proejto,
você pode, simplesmente, criar o backlog específicamente para a
etapa.

4.6 - Orçamento

Esse ponto é importante, e eu talvez quebre essa seção em um

capítulo a parte.
Como agora você tem exatamente um framework para trabalhar seu
projeto, sabe com relativa precisão quando ele será terminado, tem
uma base muito mais realista de como cobrar pelos seus serviços.
4 - Dividir Para Conquistar 18

Você pode definir um valor por etapa, e então aplicar esse valor ao
número de etapas necessárias, incluindo a etapa de ajustes finais.