A palavra sucesso se relaciona ao resultado de uma ação porém nem toda a ação gera um sucesso. Também há a dificuldade em definir “sucesso”. O desenvolvimento de software/aplicação/app é uma das ações que mais geram insucessos, e ao decorrer desse artigo pretendo responder o porquê cheguei a esta conclusão e mostrar os 7 principais motivos de insucesso neste processo.
Um boa maneira para explicar o quanto o processo de se criar um software é um insucesso é levantando números:
⦁ O primeiro que vi foi em um artigo da Sensor Tower que diz que há 3,4 milhões de aplicativos nas lojas Google Play e App Store, e que mais de 2,5 milhões deles têm menos de 1000 downloads.
⦁ Outra informação que demonstra o quão difícil é ter sucesso que apenas 1% dos criadores de software detêm mais de 80% dos downloads, já na área de games 1% das empresas faturam 95% das vendas.
O processo de desenvolver um software vai muito além de escrever códigos, é necessário ter um bom plano e requisitos bem levantados e validados.
Vamos aos 7 principais motivos de insucesso:
⦁ Não definir qual o problema a ser resolvido
O início de qualquer solução deve ser entender bem o problema. É muito comum clientes que possuem ideias inovadoras nos procurar para desenvolver-las, e se cria um laço e amor tão grande pela solução que esquece-se o real motivo para o qual foi ou vai ser desenvolvido o software.
A história (lenda) contada em uma palestra do Mário Sérgio Cortella, fala de uma empresa que fabrica pasta de dente. Esta empresa contratou dois engenheiros por três meses ao custo de R$ 8 milhões para resolver um grande problema que tinham. Durante o processo, algumas caixas de pasta de dentes eram embaladas vazias, o que fazia a empresa ter muito custo em identificar esse erro no processo. Foi implantada a solução dos engenheiros, que era uma máquina que pesava cada caixa e tinha um braço hidráulico que removia a caixa, caso estivesse vazia. Após três meses da implantação, os relatórios apresentavam bons resultados, até que foram ver que a máquina estava parada fazia dois meses. Ao perguntar para os operadores da máquina eles alegaram que se perdia muito tempo com as paradas para retirada das caixas vazias, e eles optaram em fazer uma “vaquinha” de R$80 e compraram um ventilador, que ao ser bem posicionado na esteira faziam com que as caixas vazias voassem para fora dela.
Um outro bom exemplo, que achei muito interessante de foco no problema, foi de um empresa que fabrica bicicletas. A empresa tinha prejuízos com o frete devido a avarias, 25% dos produtos chegavam danificados aos seus clientes. A empresa focou bastante no problema e pensou em objetos frágeis que não tinham esse índice alto de avarias. Foi aí então que tiveram a brilhante ideia de imprimir a imagem de televisores na caixa, somente essa ação fez reduzir em 80% o número das avarias.
A falta da definição de um grande problema a ser resolvido faz com que o software não tenha aderência por parte dos usuários, e nem sempre a melhor solução precisa ser a mais complexa.
⦁ Falta de Roadmap
O Roadmap é, de certa forma, um mapa cronológico de evolução do seu software, que visa mostrar a todos os envolvidos o que será desenvolvido e quais funcionalidades são prioridades dentro do plano.
A falta de Roadmap faz com que as mudanças de prioridades não sejam baseados em entrega de valor, porque todo esse plano deve ser alinhado com o plano de negócio.
Não ter um Roadmap impacta também na falta de entendimento das fases de um software, que além do desenvolvimento outras partes são muito importantes para o sucesso, como por exemplo: implantação, versões, atualizações, escalabilidade, etc.
⦁ Não prototipar
Antes mesmo da primeira linha de código é muito necessário definir o que vai ser desenvolvido, o prototipação é a maneira mais eficiente em transformar um ideia em exemplo do produto final (ainda muito longe de ser comercializado), mas já entendível para que os programadores não tenham dúvidas do que deverá ser feito. A Falta de um protótipo faz com seu projeto tenha muitos pontos obscuros, fazendo com que o prazo estimado seja facilmente estrapolado, aumentando consideravelmente os custos. Outro problema causado pela falta de documentação é o índice de retrabalho, já que o programador desenvolve primeiro para depois o cliente final avaliar, e a chance de não aprovação é muito alta. Não pretendo me estender muito com esse assunto, pois meu amigo Flávio Fukabori fez um artigo falando sobre esse assunto entre e veja o quanto o você irá economizar investindo em protótipo.
⦁ Mudanças de escopo
Mudança de escopo são mudanças do que deve ser desenvolvido em relação ao plano inicial, e gostaria de deixar claro que mudanças normalmente são necessárias em muito casos, como por exemplo: erros planejamento, feedback dos clientes e outros. Porém, cada mudança no software geram impactos no prazo de entrega e consequentemente no valor de software, por isso, constantes alterações no projeto antes mesmo de ele ir para produção se mostram mais como preciosismo ao invés de melhorias eficazes.
O software só pode gerar valor quando ele está em produção, então mudanças no escopo só adiam a remuneração do mesmo o que pode impactar de forma estratégica já que o mercado costuma a dar valor pra quem chega primeiro.
Ainda vale lembrar que a falta de prototipação é o maior vilão para as mudanças de escopo, então leve em consideração despender o tempo necessário para esta fase.
⦁ Medo de ir para a produção
Muito conectado com o motivo anterior, o medo de ir para produção é muito comum. Na minha opinião, existe o medo da reprovação e por isso adiamos a possibilidade disso ocorrer, o que faz perder o time-to-market que é o tempo de colocação do produto da concepção até estar disponível para venda com competitividade no mercado.
Demorando para ir para a produção, o tempo de retorno do investimento também aumenta, as linguagens de programação podem receber atualizações obrigatórias, os problemas para o qual o software foi desenvolvido podem sofrer alterações. Por isso o quanto antes ir para mercado melhor, até mesmo porque você deve melhorar seu software com o feedback dos clientes.
⦁ Somente delegar o desenvolvimento e não participar
A falta de participação do idealizador do software diz muito sobre insucesso dessa aplicação. A distância entre desenvolvedor X cliente idealizador X cliente final resulta no desenvolvimento de um software desalinhado com expectativa de cada um, e quanto mais tempo acontece para o cliente final ter contato com a aplicação maior será esse desalinhamento e menor o tempo para ajustar.
Outra reação causado por esse distanciamento é falta de Ownership (sentimento de dono) que faz gerar uma repulsão ao software por parte do cliente idealizador, aquele comentário dizendo que não foi aquilo que imaginou, não está bom e outros comentários negativos da aplicação.
O manifesto ágil é um documento bem simples que também fala sobre essa proximidade ao desenvolver software, é somente um ponto de partida estruturante.
⦁ Cliente não ser o centro/motivo do seu app
Vale lembrar que o cliente aqui é quem vai de fato utilizar a aplicação/software. E desenvolver um software sem ter o cliente como principal a motivação é de início uma proposta estranha, apesar de parecer óbvio é muito comum essa validação ocorrer somente no lançamento do app, e ainda sim, mesmo após receber diversos feedbacks negativos, existe o sentimento que o cliente não sabe o que está dizendo. O resultado dessa ação é falta de aderência ao seu app, fatídico insucesso. Os clientes são cada vez mais exigentes, e a satisfação deles deve ser nosso referencial ao desenvolver um software, para isso vale muito o contato no momento de prototipação, validar durante o desenvolvimento e acompanhamento de feedbacks pós produção. O objetivo é evoluir sua aplicação baseado nesses feedbacks, e trazer profissionais de UX (User Experience) para desenhar o fluxos com menor atrito, sistemas mais intuitivos, que fará com que seu cliente seja um promotor do seu software.
Se chegou até aqui …
Espero não te-lo desanimado em ter seu software ou solução, mas sim motivado a evitar os erros citados e ter sucesso na sua solução. O desenvolvimento de um software é uma jornada que requer muita energia e dedicação do início ao fim (bem que você vai descobrir que não tem um fim, ou não deveria ter), e um bom início para o “sucesso”, seja lá o que for para você, é começar evitando alguns erros.