Essas árvores são curvas. Pinheiros que normalmente são perpendiculares, mas que em alguma parte da Polônia, por um capricho da natureza, cresceram curvos, todos eles para o norte.

O que isso tem a ver com ciclo de software em startups? Para mim, muita coisa, mas primeiro preciso visitar o conceito distorcido de startup…

A startup company or startup is a company, a partnership or temporary organization designed to search for a repeatable and scalable business model.[1] These companies, generally newly created, are in a phase of development and research for markets. The term became popular internationally during the dot-com bubble when a great number of dot-com companies were founded. (Wikipedia)

O principal de uma startup é ser escalável, ou seja, crescer, de preferência muito rápido, e através de um modelo repetível.

Uma empresa que dependa de algo (produto ou serviço) único e em esgotamento (ou raro) não é uma startup  –  uma empresa que venda joias de meteoritos (é aerolitos!) por exemplo  –  e tampouco é uma startup a empresa cujo produto ou serviço é de interesse de uma comunidade restrita, como uma produtora de Hakari (vídeo).

Não é a área de negócios da empresa que define se ela é uma startup  –  um e-commerce não torna a empresa uma startup -  mas seu modelo de negócio (vídeo).

Então, se observadas essas características, não vejo muito como fugir do ciclo financeiro clássico das startups. Você precisa descobrir como será seu produto, como irá oferecê-lo ao mercado, como vai cobrar por ele…

… e por fim, isso implica o ciclo de vida de softwares em startups.

Toda startup tem ao menos dois problemas em comum: baixo financiamento e insegurança sobre a reação do mercado (disrupção?!).

No que tange ao software, eu experimentei duas maneiras de desenvolvimento: aquela em que o software é feito de maneira acelerada, com o intuito de provar mais rapidamente o conceito e a viabilidade do serviço ou produto perante futuros investidores, e aquela em que o produto ou serviço é criado com direção técnica mais refinada, buscando um processo em que cada iteração agrega um novo valor cuja interação com o ecossistema de software existente cria resultados maiores quando visto num todo.

Ao contrário do que parece, acredito que os dois modelos não são mutuamente excludentes, mas cada uma tem seu tempo.

Quando você idealiza algo que pode se tornar um produto ou serviço, o que você faz? Começa pelo planejamento ou pela ação? Seria errado criar um blog para falar do serviço, apresentar um preço e desenvolver a ideia ali mesmo tornando-a mais madura e, principalmente, tirá-la do mundo das ideias, criando possibilidades reais de vendas… de ter clientes?

Isso é a primeira fase. A fase em que mais importante que ter o melhor produto do mundo é ter o produto, sair do mundo das ideias e mergulhar nas possibilidades para poder corrigir logo de início o que claramente não funciona.

Aqui surgem dois caminhos: no primeiro, o CEO investe no desenvolvimento de um software (desde o CORE até as características de negócio) para a primeira fase e, no outro, ele utiliza de todos os meios para que seja possível focar somente nos itens de valor.

No primeiro caso, surge um software assustador, a little monster que, apesar de entregar o valor (ou não) a que se propõe, será o futuro responsável pela maior conta da empresa (precisa de mais hardware, mais programadores, um bom RH, mais red bull e lenços de papel…). O CEO e o CTO sempre se perguntarão

“Por que demora tanto para alterar o footer?” .

Infelizmente, mais de uma vez, eu vi profissionais de TI que se tornaram CEOs pregando no mundo de negócios os mesmos valores que tinham como desenvolvedores. Para um desenvolvedor, principalmente aqueles que respiram desenvolvimento de software, cogitar fazer um software “ nas coxas” é uma heresia comparável a recitar a tabuada do 5 fazendo beicinho, usando as mãos para mostrar os números, no meio de uma festa de piscina cheia de mulheres fazendo topless, enquanto passam as melhores cenas de Monty Python num telão gigante e o Hulk faz discotecagem com bandas fodásticas até que começa a tocar “Iron Man” e o próprio chega voando, tira a armadura que se transforma numa maleta, pega ela e diz “Toma pra você, eu fiz outra”.

E eles estão certos. Isso não se faz!

Então, qual o certo na primeira fase de uma startup? Onde provar a viabilidade e aprimorar a ideia é o mais importante.

Use frameworks de negócios como Magento, para e-commerce, ou WordPress (com templates que atendam à sua necessidade) e software as a service para atender a requisitos técnicos. Evite desenvolver o core da aplicação e foque nos valores de negócio como uma página de checkout que promova uma maior conversão, uma seleção de produtos matadora, endomarketing, aftermarketing, foque em engajamento de qualidade, refinamento constante do serviço/produto e PDCA.

PDCA Dude, please! Se você não medir, não tem como melhorar. Se você não souber o estado atual de algo, não tem como saber se a alteração que você fez na expectativa de melhorar teve um resultado positivo ou negativo.

“Se você medir, Eles virão!”

(sobre resultados)

A melhor coisa sobre métricas permanentes das coisas mais importantes para seu negócio é que com toda essa informação você tem licença para seguir seu instinto, porque agora ele tem bases.

Essa primeira fase a que me refiro vai durar um tempo. É provável que a empresa cometa erros e, principalmente, mude tudo que havia planejado no inicio.

Vai descobrir que aquela funcionalidade super excitante não é relevante pra ninguém. Que ter várias opções para o produto não vale a pena. Que a cobrança precisa ser recorrente. Que o público-alvo correto é o grupo de jovens adultos, e não os adolescentes como se acreditava. Enfim, serão tantas mudanças e algumas delas tão radicais que se houvesse sido criado um software desde o início ele teria se tornado um grande macarrão de adaptações, até que em algum momento surgisse o personagem do qual eu mais tenho medo, o cara do…

“Temos que reescrever tudo do zero!”

Nunca dê ouvidos a esse cara. Reescrever uma aplicação do zero nunca é algo benéfico para os negócios. Do ponto de vista de desenvolvimento de software, pode parecer fazer sentido por um momento, mas basta olhar mais algumas vezes para ver que também não faz sentido. Por quê? Simples.

Até que uma startup encontre o melhor modelo de negócios, ela vai mudar muitas vezes, e todas essas mudanças terão impacto no software (uma das poucas certezas que você pode ter) e, se você reescrever o software inteiro todas as vezes, vai acabar com 10 versões de um software que não atendem aos requisitos atuais de negócio e que não adicionam conhecimento algum ao time de desenvolvimento, porque o repositório master do projeto no git agora se chama VERSAO-11, e a única coisa que ele herdou foi o README.md (que ninguém vai ler) e ninguém vai olhar os repositórios antigos porque não funcionam (databases apagados, hosts inexistentes e bla bla bla wiskas sache).

De fato, a realidade pede uma outra frase: “ Precisamos reescrever essa parte”. Isso é valido. O problema é a definição de parte. Se você escreveu um software monolítico, parte significa todo o software. Se você escreve um software componentizado, bem-vindo ao cenário feliz!

O produto e o modelo de negócios são válidos. E agora?

Agora nós continuamos num próximo artigo. Enquanto isso, você pode ir lendo

Revisando os itens principais:

• Startups mudam várias vezes até descobrir o modelo de negócio ideal.
• A única certeza é de que o software vai mudar com as alterações de negócio.
• Foque o desenvolvimento nos valores de negócio enquanto estiver validando o modelo de negócio e produto.
• Métricas são a única maneira de saber se você está melhorando ou piorando enquanto muda.
• Nunca reescreva o software do início. Ataque os problemas de arquitetura e código através de refactoring.

Ahh… as árvores tortas, você achou que eu me esqueci delas né?! Apesar de serem tortas na base, você notou que todas elas se tornam retas a uma certa altura? Pois é.

Eis a conexão: Todo software precisa amadurecer junto com a empresa, inclusive sendo uma base de suporte para suas mudanças. Ele tem de estar pronto para se adaptar. Essa é uma das principais características de um software bem escrito, ser capaz de se adaptar às mudanças que surgem até que a área de negócios encontre um caminho estável para um patamar de crescimento (e depois o ciclo se inicie novamente).

Continuamos na próxima…