├── cover-github.jpg ├── manuscript ├── 0-1-dedicatoria.md ├── 0-2-agradecimentos.md ├── 0-3-autor.md ├── 0-4-prefacio.md ├── 0-5-como-ler.md ├── 0-6-contribua.md ├── 0-7-intro.md ├── 1-1-mvp.md ├── 1-2-descartando-ideias.md ├── 1-3-o-valor-do-tempo.md ├── 1-4-dividir-para-conquistar.md └── Book.txt └── readme.md /cover-github.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hernandev/mvp-como-tirar-sua-ideia-do-papel/6c93ce12341a9777bfd6434a0c600393550f2b81/cover-github.jpg -------------------------------------------------------------------------------- /manuscript/0-1-dedicatoria.md: -------------------------------------------------------------------------------- 1 | {frontmatter} 2 | 3 | # Dedicatória 4 | 5 | > Aos meus pais, por seu amor incondicional. -------------------------------------------------------------------------------- /manuscript/0-2-agradecimentos.md: -------------------------------------------------------------------------------- 1 | # Agradecimentos Especiais 2 | 3 | [CODECASTS](https://codecasts.com.br) 4 | : Aos meus amigos e parceiros do CODECASTS **[Vinicius Reis](https://github.com/vinicius73)** e **[Fábio Vedovelli](https://github.com/vedovelli)**, por me apoiarem e ajudarem para que este projeto fosse possível. 5 | 6 | [Kino Contabilidade](https://sejakino.com.br) 7 | : Aos meus amigos e parceiros Felipe e Daniel, idealizadores do projeto que uso como exemplo no presente livro. 8 | 9 | [Rafael Gomes](https://github.com/gomex) 10 | : Por me inspirar em manter o conhecimento deste livro aberto e acessível. 11 | 12 | [Victor Rodrigues](mailto:vitzz.rodrigues@gmail.com) 13 | : Ao meu amigo e excepcional Designer Gráfico, pela linda obra de arte da capa deste livro. 14 | 15 | 16 | 17 | > _Em construção._ -------------------------------------------------------------------------------- /manuscript/0-3-autor.md: -------------------------------------------------------------------------------- 1 | # Sobre o Autor 2 | 3 | Diego Hernandes é desenvolvedor web aproximadamente há 10 anos. 4 | É certificado como [Zend Certified PHP Enginner](https://www.zend.com/en/yellow-pages/ZEND026619), e já desenvolveu e gerenciou diversos projetos web de missão crítica. 5 | 6 | Atualmente, Diego divide seu tempo entre as atividades de CTO 7 | na [Kino Contabilidade Online](https://sejakino.com.br) e à produção de conteúdo no [CODECASTS](https://codecasts.com.br). 8 | -------------------------------------------------------------------------------- /manuscript/0-4-prefacio.md: -------------------------------------------------------------------------------- 1 | # Prefácio 2 | 3 | > _A ser escrito._ -------------------------------------------------------------------------------- /manuscript/0-5-como-ler.md: -------------------------------------------------------------------------------- 1 | # Como Ler Este Livro 2 | 3 | Este livro está (planejadamente) dividido em 20 capítulos curtos, 4 | onde cada um tem um tema definido, um respectivo problema e minha experiência em como lidar com tal problema. 5 | 6 | Não existe ordem específica para leitura, sinta-se à vontade para ler capítulos individuais, porém, a leitura em ordem é recomendada, visto que os capítulos estão organizados pela ordem cronológia de um projeto. 7 | -------------------------------------------------------------------------------- /manuscript/0-6-contribua.md: -------------------------------------------------------------------------------- 1 | # Contribua 2 | 3 | Este livro é livre. Você pode ler, vender ou, basicamente, fazer qualquer coisa com ele. 4 | 5 | A licença completa se encontra na contra capa e na página do livro. 6 | 7 | Caso este livro lhe seja útil, você pode ajudar o mesmo de duas formas: 8 | 9 | Fazendo uma Doação 10 | : Para doar, basta comprar novamente o livro na página da Leanpup, selecionando o valor que deseja doar. 11 | 12 | Revisando e contribuindo com melhorias no texto 13 | : Sim, você pode acessar diretamente os fontes deste livro e enviar pull requests de melhorias no Github: 14 | [https://github.com/hernandev/mvp-como-tirar-sua-ideia-do-papel](https://github.com/hernandev/mvp-como-tirar-sua-ideia-do-papel) -------------------------------------------------------------------------------- /manuscript/0-7-intro.md: -------------------------------------------------------------------------------- 1 | # Introdução 2 | 3 | Desde meus primeiros pequenos projetos de software, sempre tive alguma 4 | dificuldade em gerenciar recursos, tempo e de fazer previsões acertadas 5 | sobre um projeto. 6 | 7 | Com o tempo, as demandas de projetos (cada vez maiores) me fizeram aprender, 8 | da maneira árdua, aquilo que era fundamental colocar em prática. Ou seja, 9 | tive a oportunidade de provar empiricamente muitas das teorias sobre 10 | desenvolvimento de software. 11 | 12 | Este livro nasce do meu profundo desejo de compartilhar minhas técnicas e 13 | soluções com você, desenvolvedor, e assim, talvez ajudá-lo a tomar 14 | decisões de projeto mais acertadas. 15 | 16 | Como você pode ver no título do livro, vamos falar de MVP. Não se preocupe 17 | se a sigla quer dizer nada pra você ainda, acredite, em breve ela irá. 18 | 19 | Ao longo dos capítulos, irei apresentar alguns conceitos que serão 20 | descritos como relatos de projetos nos quais eu participei. 21 | 22 | Esteja você desenvolvendo uma ideia para uma nova Startup ou tenha sido 23 | contratado para desenvolver uma, este livro busca lhe dar dicas valiosas 24 | de como evitar os erros mais comuns que podem levar seu projeto ao 25 | fracasso. 26 | 27 | Você talvez já tenha se encontrado em um dos cenários a seguir: 28 | 29 | - Uma ideia que nunca sai do papel por falta de planejamento adequado. 30 | - Um contrato desperdiçado, por conta da insegurança em entregar um projeto de grande porte em tempo hábil. 31 | - Um projeto de médio ou grande porte indo por água a baixo, sem se quer que você entenda o motivo. 32 | - Um cliente/investidor completamente insatisfeito com o resultado, que até saiu dentro do prazo, mas não atende às expectativas. 33 | 34 | Eu preciso ser sincero, já estive em todas as posições acima e sei 35 | o quão frustrante é. 36 | 37 | Esse livro tenta atacar os pontos que levam a esses cenários acontecerem. 38 | 39 | Boa Leitura! 40 | -------------------------------------------------------------------------------- /manuscript/1-1-mvp.md: -------------------------------------------------------------------------------- 1 | {mainmatter} 2 | 3 | # 1 - MVP: Produto Minimalmente Viável 4 | 5 | Antes de falarmos sobre ideias mais complexas e práticas, precisamos dar um passo atrás e falar sobre o básico. 6 | 7 | Se você nunca viu o termo MVP na vida, é uma honra para mim, apresentá-lo. MVP é uma sigla para **minimum viable product**. 8 | Podemos traduzir para o bom português como **produto minimalmente viável**. 9 | 10 | 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 11 | para que você possa colocar a ideia no ar, conseguir clientes e validar a ideia do projeto? 12 | 13 | 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 14 | imteroperavel e testado seu código está. Um software de sucesso é aquele tem usuários. 15 | 16 | Qualidade interna do produto é muito importante, mas não tão importante quando a validação da ideia. 17 | 18 | Se você está lendo esse livro, acredito que tenha interesse em participar de projetos de grande porte. Imagine o primeiro dia 19 | do projeto, a ideia lhe foi apresentada e você e sua equipe estão levantando requisitos. Esse ponto é extretamente crucial ao projeto. 20 | 21 | Ele é crucial não por quê você precisa detalhar ao máximo tudo aquilo que deve ser desenvolvido. Justamente pelo contrário, é a etapa 22 | onde você define aquilo que necessita ficar de fora. 23 | 24 | Você deve estar pensando que estou louco, mas pare um pouco pra refletir sobre isso. Dizer não é muito mais importante do que 25 | dizer sim. Se você incluir muitas funcionalidades na primeira versão, vai ter meses ou anos de desenvolvimento sem chegar 26 | a atender sequer 1 usuário. 27 | 28 | Ao invéz disso, por que não listar tudo que a aplicação **pode ser** ao invéz do que ela precisa ser? 29 | 30 | Vamos lá, se você separar todas as ideias para essa aplicação, provavelmente será uma lista sem fim, que custa muito caro 31 | para ser desenvolvida. 32 | 33 | Se você quer usar seu tempo livre pra desenvolver, irá desanimar facilmente diante de um roadmap tão gigante. 34 | 35 | Você precisa vender a si mesmo (e ao seu cliente/investidor, caso tenha um), que a aplicação deve fazer menos, muito menos. 36 | 37 | Você talvez pense que essa ideia vai completamente na contramão do senso comum. Uma aplicação completa tem mais chances de atender 38 | melhor o usuário correto? 39 | 40 | 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 41 | aplicacão grande não é planejar e desenvolver tudo, e depois "cuspir" o resultado pro usuário. 42 | 43 | Boas ideias evoluem, e uma boa ideia de software, que resolve os problemas reais, evolui com feedback, e não com arquitetura. 44 | 45 | Nesse livro, vamos falar inúmeras vezes do último grande projeto em que participei, a **[Kino Contablidade](https://sejakino.com.br)**. 46 | Nesse projeto seguimos fielmente essa ideia de MVP, removemos muitas funcionalidades da versão inicial, e a medida que o projeto foi sendo 47 | concluido, removemos ainda mais. 48 | A primeira versõa estável é aproximadamente 20% do planejado na primeira reunião, e sua primeira reação pode ser acreditar que isso 49 | foi um fracasso. 50 | 51 | Mais uma vez, é justamente ao contrário. Esses 20% prontos, nos possibilitaram colher os primeiros clientes, que com suas necessidades do 52 | mundo real, nos forneceram feedback necessário para repensar completamente os 80% restantes. 53 | 54 | - MVP é sobre os 20%. 55 | - MVP é sobre evoluir os 20% baseado em feedback. 56 | - MVP é sobre validar uma ideia o quão antes possível, e assim evitar trabalho desnecessário. 57 | - MVP é sobre entregar antes. 58 | 59 | Se ainda não está convencido, durante o restante do livro essas ideias serão melhores ilustradas. 60 | -------------------------------------------------------------------------------- /manuscript/1-2-descartando-ideias.md: -------------------------------------------------------------------------------- 1 | # 2 - Descartando Ideias 2 | 3 | Acho que nesse ponto, já consegui explicar com clareza o público alvo desse livro. 4 | Basicamente, ele é voltado para desenvolvedores, que precisam gerenciar 5 | um grande projeto próprio ou de terceiros. 6 | 7 | Seja qual for seu caso, esse captítulo se aplica a você. Existem duas regras antes mesmo de orçar um projeto 8 | que devem ser seguidas, na verdade são duas perguntas: 9 | 10 | > ***O quão eu acredito no potencial desse projeto?*** 11 | 12 | > ***O quão realista é minha crença sobre o potencial desse projeto?*** 13 | 14 | Só inicie um projeto, seu ou de terceiros, após refletir com entusiamo sobre a primeira pergunta, 15 | e refletir duas vezes mais, com cautela e pés no chão sobre a segunda. 16 | 17 | Se você não acredita num projeto, nunca terá forças para finalizá-lo. É necessário ter convicção para 18 | sentir entusiasmo e motivação. Ideias surreais não irão te motivar por muito tempo. Levar um projeto meses 19 | ou anos a fio, só é possível quando você acredita nele. 20 | 21 | Essa parte pode até parecer um pouco empreendorismo de palco, 22 | mas eu provarei o contrário, ao te explicar o que pode dar errado. 23 | 24 | Desse ponto adiante, irei me referir a quem encomenda o projeto como *product owner* (vide scrum). 25 | 26 | O *product owner* pode ser tanto você, idealizador de um projeto próprio, ou ainda o cara te contratando para desenvolver o projeto dele. 27 | 28 | Agora que estabalecemos o *product owner*, podemos lidar com as situações onde ele lhe culpe pelo fracasso do projeto. 29 | 30 | - Projeto demorou muito tempo para ficar pronto e perdeu a oportunidade de mercado 31 | - Projeto ficou pronto a tempo, mas não atrai nenhum cliente. 32 | - Projeto ficou extretamente legal, mas não tem nenhum potencial de monetização. 33 | 34 | Como vimos anteriormente, o MVP soluciona o problema do tempo, já que menos 35 | recursos podem ficar prontos para o mercado mais rapidamente. 36 | 37 | Se uma MVP fracassar, o tempo e dinheiro investidos serão muito menores. 38 | 39 | Porem, antes mesmo de levar o MVP a produção, você precisa acreditar no projeto. 40 | 41 | E é agora que chegamos no grande ponto desse capítulo: **Saiba dizer não**. 42 | 43 | É preciso recusar o projeto. Se é uma proposta para desenvolver para terceiros, e você não quiser ser grosso, 44 | diga que não tem tempo para assumir tal projeto no momento. 45 | 46 | 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 47 | para ajustar a ideia para algo mais realista. 48 | 49 | Então, vou repetir novamente: **Nunca inicie um projeto do qual não acredite!**. Um cliente insatisfeito é muito 50 | pior do que um cliente não atendido. 51 | 52 | Se o projeto for seu, não perca tempo com ideias que tem pouca chance de darem certo. A menos é claro, 53 | que queira jogar tempo e dinheiro fora. 54 | 55 | ## 2.1 - Como prever o sucesso de um projeto? 56 | 57 | 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. 58 | 59 | > **Uma startup só irá ter sucesso quando ela resolve problemas reais, quando ela facilita a vida de alguem** 60 | 61 | 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. 62 | 63 | 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. 64 | 65 | Na Kino, a ideia era muito, muito simples, e foi o que me fez aceitar e entrar de cara no projeto. 66 | Não oferecemos serviços de contabilidade, oferecemos a desburocratização para empreededores e profissionais autônomos. 67 | 68 | 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. 69 | 70 | 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. 71 | 72 | Apresentei um pouco da visão 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. 73 | 74 | Lembre-se: Você quer que as pessoas gastem dinheiro com seus serviços, você não vai conseguir isso até que o valor real seja claro, evidente ao cliente. Só é possivel fazer isso causando impacto. 75 | 76 | 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. 77 | 78 | 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. 79 | -------------------------------------------------------------------------------- /manuscript/1-3-o-valor-do-tempo.md: -------------------------------------------------------------------------------- 1 | # 3 - O Valor do Tempo 2 | 3 | Um dos erros mais cometidos por desenvolvedores e equipes é errarem miseravelmente a estimativa de tempo (e consequentemente, o orçamento) de um projeto. 4 | 5 | Esse capítulo é uma introdução a orçamentos, e mesmo que você esteja 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 quão viável sua ideia é. 6 | 7 | ## 3.1 - Não Confie na Calculadora 8 | 9 | Você talvez já deve ter pensado, em algum projeto, da forma que vou descrever a seguir: 10 | 11 | Você tem esse projeto em mãos para desenvolver, estima, devido a análise de complexidade que irá gastar, sozinho, 400 horas de desenvolvimento. 12 | 13 | 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. 14 | 15 | Você inda pode pensar que alguma coisa pode dar errado, e chegar a conclusão que sozinho, irá terminar, com folga, em 3 meses. 16 | 17 | 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. 18 | 19 | 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. 20 | 21 | Na realidade, as coisas mudam drasticamente. 22 | 23 | Vamos atacar todos os problemas de abordagens como essa, pra que você entenda melhor que nunca deve fazer orçamentos / estimativas de forma tão simplista. 24 | 25 | 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. 26 | 27 | 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. 28 | 29 | 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. 30 | 31 | Boas ideias surgem de uma mente descansada. É praticamente impossível pensar claramente quando se está esgotado. 32 | 33 | 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. 34 | 35 | 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. 36 | 37 | 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. 38 | 39 | 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. 40 | 41 | 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. 42 | 43 | Mas calma, estamos longe de terminar... 44 | 45 | Não contabilizamos ainda os dias que sua internet pode cair, e outros problemas pessoais que podem entrar no caminho da conclusão do projeto. 46 | 47 | Não contabilizamos ainda, todo o feedback que as pessoas envolvidas demoram dias pra te dar. 48 | 49 | Não contabilizamos ainda, que você pode ter errado e feio em estimar as 400 horas iniciais. 50 | 51 | ## 3.2 - Afinal Quanto Vale o Tempo? 52 | 53 | Essa é a grande pergunta da humanidade, desde a revolução industrial, 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. 54 | 55 | Use estimativas em horas como um meio, não um fim. 56 | 57 | No próximo capítulo, apresentarei de forma prática, uma forma alternativa de se calcular estimativas. 58 | -------------------------------------------------------------------------------- /manuscript/1-4-dividir-para-conquistar.md: -------------------------------------------------------------------------------- 1 | # 4 - Dividir Para Conquistar 2 | 3 | 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. 4 | 5 | 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. 6 | 7 | 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)? 8 | 9 | De modo simples, o que funcionou pra mim, de forma explêndida e foi novamente comprovado durante o desenvolvimento do MVP da [Kino](https://sejakino.com.br), é tratar o desenvolvimento como vários pequenos projetos. 10 | 11 | Vamos chamar esses pequenos projetos de **etapas**. Vamos fazer pois é exatamente o que eles são. 12 | 13 | Ao invéz de te dar a teoria, vamos falar sobre isso na prática. 14 | 15 | Quando primeiramente, eu e o [Vinicius Reis](https://github.com/vinicius73) analisamos o escopo do projeto da Kino, tínhamos em mente algo em torno de 800 horas brutas de desenvolvimento. 16 | 17 | Lembre se que eu falei no capítulo anterior, use horas somente como um meio, não como elo. 18 | 19 | Levantamos o escopo inicial do projeto, tudo aquilo que precisava ser desenvolvido. 20 | 21 | Esse escopo, como disse no inicio do livro, foi negociado para ser reduzido drasticamente, até chegarmos a um escopo de MVP. 22 | 23 | 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 consecutivamente, receber menos. 24 | 25 | É 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. 26 | 27 | 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. 28 | 29 | O escopo inicial chegamos a 6 meses de desenvolvimento, até o MVP da Kino estar concluido, e assim poderíamos iniciar outro estágio, de funcionlidades adicionais. 30 | 31 | Como eu havia dito, a nossa estimativa era de 800 horas, ao longo de 6 meses, para 2 desenvolvedores. Uma média de 133 horas por mês, o que resultam em 66 horas pra cada desenvolvedor. 32 | 33 | Como chegamos a conclusão de 6 meses? 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. 34 | 35 | Mas calma, vamos entrar em detalhes, mas antes, vou lhe apresentar um problema de grandes projetos. 36 | 37 | ## 4.1 - Síndrome do Burro do Shrek 38 | 39 | Mesmo o título sendo meio brega, essa seção é importante. Se durante os 6 meses 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. 40 | 41 | 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. 42 | 43 | ## 4.2 - Entregue Sempre 44 | 45 | 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. 46 | 47 | O que estou me referindo aqui não é exatamente sobre sprints, é sobre uma unidade um pouco mais relaxada, que está acima da sprint. 48 | 49 | Dividimos o escopo de trabalho da seguinte maneira: 50 | 51 | - Criar uma lista de tudo a ser feito. 52 | - Classificar as tarefas por ordem de dependência (por exemplo, Auth vem antes de ACL, etc) 53 | - Dividir o trabalho em unidades de 3 semanas, que vamos chamar de etapa. 54 | - Reservar uma semana pra ajustes a cada etapa. 55 | 56 | Dessa forma, você faz com que o trabalho dite o cronograma, e não o contrário. 57 | 58 | Recuperei aqui do email, o planejamento que fizemos para a Kino, assim você tem uma versão palpável do que estou falando: 59 | 60 | **Primeira Etapa** 61 | 62 | - Desenvolvimento de Interfaces do Sistemas 63 | - Desenvolvimento do esqueleto das distintas áreas do sistema 64 | - (1 item reduzido). 65 | 66 | **Segunda Etapa** 67 | 68 | - Controle de Contas a pagar 69 | - (2 items reduzidos). 70 | 71 | **Terceira Etapa** 72 | 73 | - Assinaturas Recorrentes 74 | - (3 items reduzidos). 75 | 76 | **Quarta Etapa** 77 | 78 | - Integração NFSe PBH. 79 | - (2 items reduzidos). 80 | 81 | **Quinta Etapa** 82 | 83 | - Sistema de Notificações. 84 | - (5 items reduzidos). 85 | 86 | **Etapa Final** 87 | 88 | - Ajustes, Bugs e Melhorias 89 | 90 | Veja que a quantidade de items por etapa varia, pois cada item tinha uma estimativa diferente de trabalho. Mas tínhamos estimado com segurança, que era possível desenvolver os items de cada etapa durante 3 semanas. 91 | 92 | 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. 93 | 94 | Essa é uma forma de não criar o atrito do Burro do Shrek, nós sabíamos exatamente o tempo que tínhamos 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. 95 | 96 | Encerrada uma etapa, tínhamos uma parte do sistema, pronta, testada, e as energias renovadas pra iniciar a próxima. 97 | 98 | O ciclo se repete, se você ler esse capítulo com calma, perceberá que é algo realmente simples de se pôr em prática, mas alguns cuidados devem ser tomados. 99 | 100 | - O product owner precisa entender, antes de qualquer contrato o modelo a ser seguido. 101 | - Assim como qualquer política, não é possível implementar sem empenho e responsabilidade entre as partes. 102 | 103 | 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. 104 | 105 | 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. 106 | 107 | 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 meses de desenvolvimento, e uma etapa de melhorias. 108 | 109 | ## 4.3 - Mas o Cliente Tem Pressa! 110 | 111 | Não, o cliente não tem pressa, ele somente pensa que tem. 112 | 113 | Cabe ao desenvolvedor, explicar minimamente ao proponente, que "a mona lisa não foi pintada em 10 minutos". Para que se haja um mínimo de qualidade, é necessário tempo. 114 | 115 | 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. 116 | 117 | Você pode até expremer 800 horas de desenvolvimento em 2 meses. Mas não irá conseguir concluir nem a metade do escopo. 118 | 119 | Com a correria começa a falha de comunicação, os erros constantes, e principalmente o retrabalho. 120 | 121 | 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. 122 | 123 | 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. 124 | 125 | Se o cliente exige a urgência, deixe passar. 126 | 127 | Se você quer lançar seu produto/startup que tem um software complexo em 2 meses, não o faça. 128 | 129 | Simplesmente pelo fato de que, é impossível fazer com qualidade. 130 | 131 | ## 4.4 - Mantendo a Sanidade 132 | 133 | 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 pessoais. 134 | 135 | Vai poder ainda, dar manutenção naquele projeto de um cliente antigo, ir a uma conferência, quem sabe pegar um freela rápido entre ou durante as etapas. 136 | 137 | 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). 138 | 139 | ## 4.5 - Onde entra o Scrum Nessa Hitória? 140 | 141 | 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. 142 | 143 | Dessa forma, cada etapa terá 4 sprints. 144 | 145 | Você pode fazer isso, no primeiro dia de uma etapa, olhar as funcionalidades a serem desenvolvidas e quebrá-las em tarefas. 146 | 147 | Dessa forma você tem um controle refinado do progresso da etapa, e consecutivamente do projeto. 148 | 149 | A parte interessante é que, você não precisa criar 1000 entradas no backlog de tudo que tem que ser desenvolvido durante o projeto, você pode, simplesmente, criar o backlog especificamente para a etapa. 150 | 151 | 152 | ## 4.6 - Orçamento 153 | 154 | Esse ponto é importante, e eu talvez quebre essa seção em um capítulo a parte. 155 | 156 | 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. 157 | 158 | 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. 159 | -------------------------------------------------------------------------------- /manuscript/Book.txt: -------------------------------------------------------------------------------- 1 | 0-2-agradecimentos.md 2 | 0-3-autor.md 3 | 0-4-prefacio.md 4 | 0-5-como-ler.md 5 | 0-6-contribua.md 6 | 0-7-intro.md 7 | 1-1-mvp.md 8 | 1-2-descartando-ideias.md 9 | 1-3-o-valor-do-tempo.md 10 | 1-4-dividir-para-conquistar.md 11 | -------------------------------------------------------------------------------- /readme.md: -------------------------------------------------------------------------------- 1 | # MPV: Como tirar sua ideia do papel 2 | Da definição da ideia à captação de clientes, cada passo é fundamental. 3 | 4 |
5 | 6 | Creative Commons License 7 | 8 |
9 | Esse trabalho é licenciado com Creative Commons Attribution-NoDerivatives 4.0 International License. 10 |
11 | 12 | ### Sobre o Livro 13 | Um guia prático de como tirar seu projeto de software do papel. Nesse livro o autor conta sua experiência gerenciando projetos de software e dá dicas de como evitar problemas que podem afundar o seu projeto. 14 | 15 | Nesse livro, conto minha experiência sobre o desenvolvimento de softwares de médio a grande porte. 16 | 17 | Esteja você querendo dar vida a uma nova startup, sendo contratado para desenvolver um projeto para alguma esse livro é para você. 18 | 19 | Nele, eu relato os grandes desafios que encontrei ao longo dos anos como desenvolvedor, conto como aprendi de forma árdua sobre a importância da tomada de decisões e como toda essa experiência foi utilizada em meu último grande projeto. 20 | 21 | Não inicie seu próximo projeto ou aceite seu próximo contrato sem antes de ler esse livro. 22 | 23 | ### Livro na Leanpub 24 | Esse livro é publicado na Leanpub, de forma incremental, nesse link: 25 | [https://leanpub.com/livro-mvp](https://leanpub.com/livro-mvp) 26 | 27 | O livro é gratuito e aberto, porém você poderá optar por fazer uma doação na hora de adquirir o mesmo. 28 | 29 | 30 | ### Capa 31 | ![Capa Livro](https://raw.githubusercontent.com/hernandev/mvp-como-tirar-sua-ideia-do-papel/master/cover-github.jpg) --------------------------------------------------------------------------------