Vale a pena investir em sua startup?

Hoje nós vamos falar sobre uma maneira de saber se o projeto da sua startup é viável do ponto de vista tecnológico.

Antes de tudo, quero falar sobre o livro que baseei um pouco para este post. Ele se chama As Leis Fundamentais do Projeto de Software. Caso queira comprá-lo, veja este link.

É um livro bem curto, cerca de 100 páginas, mas mostra um conteúdo conceitual muito bom. Ele não te ensina a programar, mas a se tornar um programador melhor, vale muito a leitura. 

Então, bora lá.

A tecnologia é muitas vezes o fator que define se uma startup vai ou não sobreviver.

Já vi alguns projetos que morreram simplesmente por não aplicarem a tecnologia adequada e em tempo hábil. Então algo tão importante como a tecnologia deve ter um tratamento especial pelos fundadores ou responsáveis pelo projeto. E o termo tecnologia a que me refiro é a aplicação em si, seu desenvolvimento, a linguagem de programação utilizada, a implementação do código e a performance que ele terá, tanto na entrega quanto na manutenção.

Nos tempos atuais, sua importância se acentuou ainda mais. Pois várias empresas tiveram que se redescobrir ou até mesmo se reinventar tecnologicamente  .

O mundo todo passou a ter trabalhos remotos. E esse é um dos motivos para a digitalização de serviços estar tão em alta, e a previsão é de que esse cenário se mantenha por um bom tempo e a demanda por profissionais aumente cada vez mais.

A tecnologia é uma parte essencial, como já sabemos, e ela vai estar presente cada vez mais na vida das pessoas. Por isso, hoje nós vamos discutir  sobre como descobrir se o projeto de uma Startup é viável pela perspectiva da tecnologia.

 Tudo se resolve com essa fórmula:

Não se assustem, pois é uma fórmula simples de ser compreendida.

O que ela quer dizer é que a desejabilidade (ou a viabilidade) do  projeto, representada pela letra D é calculada como os valores que ela vai entregar – que são Va e Vf somados – divididos pelo esforço necessário – representado por Ei e Em – para implementá-la.

Um exemplo bem simples para você entender: Imagine que vamos desenvolver um algoritmo para prever com 99% de certeza o valor de fechamento de uma criptomoeda no dia posterior. 

O valor que esse algoritmo entregaria seria enorme e quem tiver mão dele ficaria milionário rapidamente. 

Mas e para criar esse algoritmo? Já te digo que é praticamente impossível. 

Criptomoedas têm seu valor baseado em vários fatores, dentre eles o sentimento humano, como medo, motivação e entusiasmo. Valores imprevisíveis até então. Portanto o esforço para criar este algoritmo é atualmente inalcançável. Algumas análises que temos hoje são baseadas em especulações sobre cenários a longo prazo. Nada garantido.

Enfim, como exemplo, a desejabilidade vai a zero, pois entrega bastante valor, mas tem um custo, ou esforço, também muito alto. Por vezes o esforço é impensável por nem dispormos de tecnologia suficiente para entregar o produto ao mercado, e por isso acaba sendo um projeto com alto valor, mas com um custo impeditivo. Simples assim.

Valores do projeto

Sobre os valores no numerador (parte de cima) da equação, eles podem se dividir em dois:

• Valor a curto prazo (Va), que é aquele entregue de imediato;
• E o valor a longo prazo (Vf), que ela visa entregar no futuro.

Mas não vamos focar neles, pois pertencem a startup. E portanto são responsabilidade da ideia em si.

E o foco de hoje fica no denominador da equação.

Esforços para o projeto

Os esforços, que estão embaixo da divisão, também se dividem em dois. São eles a implementação e manutenção.

Mas por que precisamos separar estes dois valores? Vocês vão entender o porquê…

O esforço de implementação é aquele necessário para criar o seu projeto do zero para tirá-lo do papel, enquanto o esforço de manutenção é o quanto custa para esse projeto ser mantido no ar.

Aqui na Operar, trabalhamos nesses dois fatores. A implementação e manutenção.

Então como que a gente faz para aumentar a desejabilidade de um projeto? Diminuindo os dois esforços aos menores possível!

E para isso, temos dois conceitos chaves: MVP e entrega contínua.

Voltando pra equação. Se você diminui os esforços, automaticamente aumenta a viabilidade do projeto. Isso é matemática. E para diminuir os esforços, são duas estratégias diferentes. O esforço de implementação, diminuímos adotando um MVP ao invés de um projeto completo.

MVP vem do inglês “minimum viable product”, ou em traduzido fica “produto mínimo viável”.

Em resumo é você diminuir a sua ideia ao mínimo que ela precisa para resolver o problema. Tem a ver com o Princípio de Pareto, ou também conhecido como regra 20/80.

Pareto foi um sociólogo e economista que criou este princípio ao afirmar que 80% da riqueza estão concentrados em 20% da população, e esta proporção se estende a várias outras coisas. O mesmo para o MVP.

Buscamos os 20% do projeto que representam os 80% do resultado esperado. Estes 20-80 são apenas simbólicos, não precisam ser medidos à risca, principalmente quando seu projeto lida com coisas intangíveis (que são difíceis de serem medidos).

Então, para o MVP, pegamos a funcionalidade mais importante da sua aplicação e investimos todo o esforço nela. Isso é um MVP.

É importante mencionar também que por mais que você queira um projeto completo e robusto, pela fórmula podemos ver que a implementação é menos relevante a viabilidade do que a manutenção. Se o projeto tende a ser de longo prazo, o esforço de implementação tende a ser menos relevante com o passar do tempo.

Digamos que você tenha o esforço (ou custo) de implementação  de R$ 10.000,00 e que seu esforço de manutenção fosse R$1.000,00 mensais. Com 10 meses, o custo de manutenção se equipara ao custo de implementação.

Com o passar do tempo esse custo (de implementação) vai ficando para trás, quase esquecido, e a grande maioria dos projetos, para não dizer todos, tem um prazo indeterminado.

Isso porque quando você idealiza alguma solução, você quer que ela seja duradoura, que funcione por muito, muito tempo.  Quanto mais tempo ficar no mercado, melhor para a sociedade, e para você, e o esforço de manutenção tem maior impacto a longo prazo. 

Já ouviu dizerem que para uma empresa é mais importante o seu “reagir” do que o “agir”? Isso é bem verdade. Todo projeto muda com o passar do tempo. Ou muda, ou morre. Portanto, a manutenção é mais importante pois dentro dela estão as alterações da aplicação.

Ah, e para ficar claro, quando me refiro a “manutenção” em si, não quero dizer apenas o ato de “consertar” algo quebrado. 

Manutenção vem da idéia de manter o projeto. E com isso se incluem qualquer alteração, adição e/ou exclusão de funcionalidades. Já que chegamos a conclusão de que o esforço de manutenção é o mais importante, como podemos reduzi-lo?

Primeiro, não adianta termos um projeto que seja barato para criar, mas caríssimo pra manter. Você compraria um carro, por R$ 10.000,00, sabendo que teria que desembolsar R$ 3.000,00 mensais só para mantê-lo andando?

Não né, ninguém compraria… ou espero que não.

Com software é a mesma coisa. Não adianta uma implementação baixa, se para manter a aplicação rodando você tenha que gastar horrores.

Existem 4 pontos essenciais em software que reduzem o esforço de manutenção, são eles:

• Documentação;
• Versionamento;
• Arquitetura de código;
• Testes.

Documentação

Documentação é o manual de instruções da sua aplicação. Serve tanto para quem vai usar (operação ou usuário final), quanto para quem vai trabalhar no projeto. A integração de uma nova pessoa na equipe, por mais experiente e expert que ela seja, vai levar um tempo. 

Para entender toda a aplicação, o código por trás dela, precisa conhecer todo o funcionamento, as regras e a estrutura adotada, e para diminuir esse tempo, uma documentação bem feita ajuda muito.

Até mesmo para quem criou todo ou boa parte do código. Ao voltar no projeto meses depois, pode ter esquecido o que e como fez. E com certeza, a documentação salva um tempo precioso.

Versionamento

Como dito antes, todo projeto de software muda com o tempo. Isso é um fato.

Se ao invés de guardarmos todas alterações do código da aplicação em uma pasta, com nomes do tipo aplicacao_versao_final, versao_final2, versao_final_agora_vai…

Como uma melhor opção, e se mantivermos todas essas versões em um repositório, de forma automática, acopladas historicamente e acessível a quantos computadores precisarmos?

Isso existe, e o mais famoso tipo de versionamento se chama Git., mas não vou me estender sobre suas funcionalidades. Existem centenas de comandos e isso é assunto para outro momento.

Mas em resumo, com ele você guarda todas as mudanças feitas no código, tem toda a evolução histórica registrada, pode manter o código integrado em todas as máquinas e o melhor, consegue separar desenvolvimento de produção. 

Sem um serviço de versionamento, a dificuldade em evoluir com o código aumenta o dobro, no mínimo.

Padrão ou arquitetura de software

Sobre arquitetura de software, existem diferentes maneiras de se desenvolver uma aplicação. DDD, Clean Architecture, Arquitetura de Microsserviços, dentre várias outras que podem ser aplicadas em conjunto.

Não digo que existe uma que é a melhor. Mas é importante que o código tenha consistência.

O que isso quer dizer? Que ele siga o mesmo padrão em todo o código.

Por que isso importa? Para quem vai ler e entender seu código, se ele estiver seguindo um jeito único, fica muito mais fácil para ler e entender. 

Com isso, consequentemente diminui o tempo de ambientação e o esforço de manutenção.

Testes

Bem, chegamos aos testes. Por último e não menos importante. Também não quero me estender demais, pois é um tema muito abrangente e levaríamos o dia todo.

Testar é essencial. Só isso. E os testes podem ser feitos de duas formas: manual e automática.

Testes automatizados entregam uma proteção à falhas (não isenção, que fique claro) muito maior e por um custo muito menor. E testes também são fortes aliados aos três itens que citei anteriormente. 

Criar cenários controlados, com resultados esperados para o código são maneiras eficientes de garantir que sua aplicação está sendo feita da forma esperada. Existem vários tipos de testes.

Para quem quiser saber mais. Busque pelo termo TDD, ou “Test Driven Development”, ou “Desenvolvimento guiado por testes”. 

É uma mudança de paradigma para o caminho comum do desenvolvedor.

Exemplo de aplicação de um MVP e manutenção

Bom, para exemplificar, vou falar sobre um cenário. Não tem a ver com software, mas se ajusta muito bem ao que falamos.

Eu quero montar uma cafeteria, e nessa cafeteria tem duas coisas que eu quero implantar para ela se destacar no mercado.

Uma delas é ter no mínimo 15 tipos diferentes de café. Outro destaque é um atendimento bilingue. Além da nossa língua, quem trabalha na cafeteria consegue atender em dois idiomas.

Bacana não?

Ah, e explicando melhor o cenário atual da hipotética cafeteria. Eu já tenho um fornecedor que pode me vender os 15 tipos que eu preciso. Isso define o contexto do meu projeto.

Agora vamos pensar no MVP.

Então, para extraí-lo, precisamos pensar duas coisas. Quais funcionalidades da cafeteria eu consigo implantar e qual o custo?

• Ponto 1. Já tenho fornecedor, logo, não tenho custo para buscar ou pesquisar quem vai me fornecer a matéria-prima;
• Ponto 2. Eu devo investir em um curso de idiomas para as pessoas que trabalham comigo ou contratar quem já fale inglês (ou qualquer outra língua)

Se eu for pagar um curso, teria um custo enorme de imediato. Se for contratar alguém, sai mais barato.

Então, de forma simples. Meu primeiro MVP fica assim:

• Uma pessoa bilíngue no atendimento;
• Os mais variados tipos de café.

Pronto. Essa é a minha implementação.

Depois de um período para validar, vamos analisar o seguinte:

• Teve procura por atendimento em outro idioma?
• Quais tipos de café foram mais procurados? Algum teve venda irrelevante?

Percebam que são informações que posso medir, e ir fazendo a manutenção do meu produto, ou no caso, da minha cafeteria. E com software é bem parecido. Com uma vantagem a mais que é poder automatizar várias dessas medidas.

Aproveitando o momento, uma frase do Peter Drucker: “Se você não pode medir, você não pode gerenciar”

Espero que você tenha gostado. Se gostou do conteúdo, curta, compartilhe e fique alerta aos novos conteúdos que irei divulgar para ensinar mais sobre desenvolvimento.

Se estiver precisando de uma solução para o desenvolvimento da sua startup, chegou ao lugar certo. Entre em contato!