Resumo e entendimento do livro para que eu (ou alguém) possa consultar.
Versão em inglês do livro: Download
Versão em português do livro:Download
A ideia do livro em geral é trazer a tona novas formas de pensar durante o desenvolvimento de um software, passando por planejamento, testes, ideias, bugs, erros, investidores... Quebrando alguns paradigmas e tradições do mercado e introduzindo conceitos para lhe guiar durante a criação de seu software milionário 🤑. Construa e lance, rápido!
O "mantra" mais citado no livro é "lance rápido!" e isso quer dizer que você precisa parar de polir seu software pefeito para algo que talvez nem exista. Lance e deixe que os usuários digam o que querem e como querem. Obviamente você não irá lançar um software mal feito e muito menos adicionar tudo que os usuários pedirem, mas esse ponto serve para você iniciar logo e experimentar.
Durante o livro o autor cita diversos posts (muitos offline :c) e indicações de livros que deixarei linkados no fim deste artigo:
Desenvolva softwares que resolvam algum problema no seu cotidiano, comece simples e vá evoluindo. Talvez 1 pessoa ou 10 tenham o mesmo problema e você possa ajudá-los e quem sabe 10.000 pessoas tenham o mesmo problema que você achou que era apenas seu. Assim nascem as "ideias do milênio", soluções para problemas diários.
Faça um software menor que todos os do mercado, comece com menos funcionalidades mas faça-as de maneira excelente. Assim você terá um software conciso e robusto atendendo exatamente o que você precisa. Deixe de lado a ideia de antigos softwares que parecem cabines de avião cheios de funções e botões que na maioria das vezes nem são utilizados.
Inicialmente evite ao máximo captar dinheiro de terceiros, isso irá gerar uma responsabilidade grande, aumentar as burocracias e diluir o fluxo de desenvolvimento. Se o seu software conseguir "se pagar" então você está no caminho certo, caso contrário... O dinheiro injetado irá esconder essa visão. Você poderá recomeçar sem a pressão dos investidores.
Foque em entregar seu software dentro do prazo e orçamento combinado, caso analise que algo precisa ser ajustado, ajuste, mas nunca altere o prazo e orçamento. Esses limites irão cortar os itens "supérfluos" por hora em seu sistema. Restrições e limites vão forçar você a pensar e encontrar maneiras criativas de resolver seus problemas e desafios.
Caso o software que tenha escolhido desenvolver resolva um problema de seu cotidiano encontre nele uma "paixão" para que desenvolva ele com um motivo além do dinheiro. Se a sua aplicação não o excita, algo está errado. As pessoas irão perceber isso em sua versão final.
Mantenha-se pequeno o máximo de tempo que puder. Equipes menores resultam em simplicidade, fácil adaptação, mudanças rápidas, comunicação concisa, soluções instatâneas. Mover um objeto com massa grande da muito mas trabalho do que mover um objeto com massa pequena. Então se precisar mudar algo em seu projeto ou ajustar a direção de seu negócio será muito mais fácil com uma equipe enxuta.
A mudança é onde pequenas equipes se diferenciam de grandes corporações, utilize essa vantagem ao seu favor. Adicionar um novo recurso com uma equipe pequena pode pode levar 1 dia, enquanto em uma grande corporação a mesma funcionalidade pode levar meses para ser implementada.
Uma outra vantagem muito boa de equipes pequenas é a proximidade que você consegue ter com o seu usuário, pode tratá-los como se fossem amigos (e são) enquanto evolui o software para eles.
Defina e faça os pontos importantes de sua aplicação, detalhes são importantes mas no começo aquele botão pixel perfect não será o divisor de águas de seu sucesso. O sucesso pode estar nos detalhes, mas além do sucesso você encontrará reuniões, desacordos, atrasos e neste momento inicial o ideal é evitá-los. Há tempo suficiente para ser perfeccionista, apenas faça isso mais tarde.
Outro ponto que muitos acabam se prendendo no começo é com problemas que ainda não tem. Realmente é a hora de pensar como sustentar um servidor com 10.000 usuários simultâneos? Precisa realmente de uma equipe com 12 programadores? Deixe esses problemas para quando eles forem reais e talvez eles nem se tornem realidade. Apenas faça.
Encontre seu nicho de mercado e foque nele, se tentar agradar todo mundo não irá agradar ninguém.
E por fim faça o seu software ter opinião, coloque e tire funcionalidades com determinação e princípios, assim você mantém uma constância e não tende a fazer qualquer coisa que lhe pedem. Aprenda a dizer "não", e caso algo seja solicitado várias vezes analise.
Continua...
The Pragmatic Programmer