Alguns de vocês já devem ter visto e respondido a nossa pesquisa para entender as dificuldades que as startups encontram com a engenharia de software. Hoje então vamos mostrar alguns resultados que obtivemos com esta pesquisa! E se você ainda não respondeu, nos ajude acessando a pesquisa aqui.

Sempre ouvimos que o sucesso de uma startup está diretamente ligada ao plano de negócios e aceitação de mercado. Muitas vezes esquecemos de outros fatores que também podem afetá-la diretamente tais como: falta de experiência da equipe, qualidade do produto, velocidade de desenvolvimento, dificuldade na inserção de novos requisitos no projeto, dentre outros.  Por isso hoje vamos mostrar alguns dados obtidos com a pesquisa que estamos realizando. Essa é uma pesquisa informal e foi respondida por startups do Brasil inteiro.

Pesquisa-adicionar-funcionalidade-nova-startup-2

 

Ao perguntarmos: “Ao adicionar uma funcionalidade nova ao software, qual o grau de dificuldade encontrado?”, com as respostas é possível perceber que mais de 50% (63%) respondeu dificuldade 3 e 4! Ou seja, eles encontram uma certa dificuldade em alterar o software desenvolvido, em fazê-lo crescer aumentando seu escopo. Tomando por base que a maioria das Startups começa com um MVP (não sabe o que é MVP? Veja no nosso Dicionário de Startups), imagina que em cada ciclo de desenvolvimento a dificuldade encontrada pode ser 3 ou 4. Tomando por base que o Lean Startup foi criado para evitar o desperdício do tempo, o quão “lean” será esse desenvolvimento? Quanto tempo e código serão desperdiçados? E o “time-to-market” como fica? Além disso, será que o software deve ser todo re-feito para absorver uma nova funcionalidade?

Outro dado da pesquisa que dá suporte ao que falamos anteriormente é em relação a quantas versões são lançadas até que o software esteja estável o suficiente para liberação para o cliente. Esse dado é complicado de ser analisado separadamente já que ele está diretamente ligado a quantidade de bugs encontrados após o release de uma versão. Mas de qualquer forma é importante ressaltar que 44% disse liberar de 3 a 5 versões, e 26% mais do que 5 versões. Ou seja, 70% trabalham no mínimo em 3 versões de software até liberá-la para o cliente. O motivo de ser difícil analisar este dado isoladamente deve-se ao fato de algumas startups alegarem ter apenas 1 versão de software  e não é possível identificarmos com este dado a quantidade de bugs que são liberados com esta única versão. Estimamos que no mínimo 2 versões devem ser trabalhadas antes de liberá-la para o cliente, já que no mínimo é necessário realizar uma bateria de testes normais e outra de testes de regressão (em breve falaremos mais sobre os tipos de testes).

 

Pesquisa-versoes-software-startup

Por fim, vamos falar de prazos e impacto nos clientes:

  prazo-impacto-desenvolvimento-de-software-cliente-startup

É possível perceber na figura acima que ao falarmos de prazo e impacto, apenas 23% controlam os prazos e que são cumpridos de acordo com o planejado. Do restante, 31% não trabalha com eles e 46% atrasam um ou mais dias. Muitas pessoas pensam que startups não precisam trabalhar com prazos já que estão descobrindo uma oportunidade de mercado, porém muitas vezes essa oportunidade está numa janela de tempo e que se desperdiçada também pode ser um fator para o insucesso de uma startup.

Por exemplo, com a copa e as olimpíadas vindo para o Brasil muitos enxergaram oportunidades de negócios, mas nem todos conseguiram ficar prontos para aproveitá-la. Vide exemplo do HelloUniverse que se trata de “um serviço eletrônico com tradutores de várias línguas à disposição, numa central para qual basta ligar e pedir ajuda de  alguém para traduzir qualquer coisa'”, cujo o lançamento foi apenas 2 semanas após o início da copa (veja mais detalhes  aqui). Eles perderam uma oportunidade de lançar o produto antes da copa e já ter adeptos do mundo inteiro, agora resta somente esperar as olimpíadas.

E, ao falar de impacto no cliente, quando falamos de “early adopters” (veja também no nosso dicionário) fica mais fácil controlar o impacto dos problemas encontrados no produto. Porém, quando pensamos em escala como medir esse impacto? Como saber se um cliente deixou de usar a sua ferramenta por causa das dificuldades encontradas ao utilizá-la podendo ser por bugs pequenos ou até problemas de UX (também no dicionário)? Quantos aplicativos você mesmo já não baixou e deixou de utilizá-lo devido a dificuldade  ou por te deixarem na mão? De qualquer forma, 43% das startups que responderam a pesquisa disseram que possuem um impacto alto ou extremo, além de 9% que não fazem nem ideia e 6% que marcaram “outros”. Como controlar esse impacto? Como medí-lo e entender como ele pode ser reduzido? Além disso, quando falamos em sistemas embarcados esses números podem aumentar consideravelmente, principalmente em relação ao prejuízo gerado a uma startup.

Para essas e todas as perguntas feitas neste post existem boas práticas de engenharia de software que resolvem os problemas aqui listados. Práticas desenvolvidas baseadas em experiências do passado por um desenvolvimento desorganizado, será que estamos vivendo um ciclo vicioso?

E o seu processo? Será que ele é realmente Lean?

Lembrem-se sempre que Lean e Agile não são sinônimos de bagunça e desorganização. E se você quer melhorar a forma de desenvolver na sua startup, continue acompanhando os nossos posts que daremos muitas dicas de como aplicar práticas de forma que não engesse o seu desenvolvimento e que ele continue ágil e ainda mais lean!

Veja todas as respostas da pesquisa em: Processo de desenvolvimento em Startups


E você, o que pensa sobre o assunto? Gostou do artigo? Compartilhe conosco sua opinião. Não gostou? Acha que podemos melhorar? Então nos ajude a aprimorar nosso trabalho.

Siga o Startup Sorocaba no Facebook e cadastre-se para receber nossa newsletter e para ser informado sobre todas as novidades.

Compartilhe: