O que falta para seu projeto tech alcançar os verdadeiros resultados?

Por Matheus Danemberg *

Você sabe o que faz muitos projetos de desenvolvimento de software darem errado? Eu consigo imaginar alguns pontos e gostaria de compartilhar com vocês. No total, são 5 tópicos que acredito serem os principais motivos de não conseguirmos ter o resultado esperado.

1. Focar só em esforço e produção

Dentro do ciclo de produção do software , existem algumas etapas que devem ser seguidas. Você prioriza o que será feito, olha a dor que quer atacar e pensa o que deve executar para resolver esse problema. Programar, de fato, é uma das últimas etapas do ciclo.

Para finalizar, é necessário pegar o resultado que foi gerado desse esforço e entregar para o usuário final, certo?  Mas, se você prestar bem atenção, o que realmente foi entregue ao usuário é apenas o que foi produzido, ou seja, o output. Para se pensar em uma conclusão, ainda existem três pontos que precisam ser realizados por ele:

1. Encontrar
2. Aprender
3. Usar.

Só neste último momento que vamos começar a gerar o resultado esperado: o outcome.

É por isso que produzir features não é o resultado que devemos buscar, mas o meio para chegar lá. Ele é alcançado somente quando o usuário aprende a usar o software e agrega valor àquilo quando começa a usá-lo. Antes disso, você está apenas produzindo coisas. O verdadeiro ciclo, portanto, deveria ser esse: você prioriza, coloca esforço para fazer, entrega para o usuário, ele vai atrás, entende como funciona, usa, gera resultado e repete.  Por isso, o grande objetivo de um time de software não deve ser só produzir features, mas, além disso, gerar valor para o usuário.

Longo ciclo para percepção de valor

O próximo ponto que, para mim, está diretamente ligado ao primeiro, são os longos ciclos para a percepção do valor. Desenvolver, testar e produzir são etapas que podem ser feitas em até uma semana. Mas, para que o usuário entenda, acesse e use o produto leva um período maior do que esse.

Portanto, existe uma certa janela de tempo para ser possível enxergar os benefícios do que foi produzido – um erro muito comum que percebo entre os líderes. Alguns deixam esse ciclo inicial, de gerar um output, maior do que ele deveria ser. É fácil produzir funcionalidades e código, mas não é tão simples assim fazer com que isso vire um resultado.

Para tanto, vai depender se o seu produto está bem alinhado com o que o usuário espera e aguardar o tempo que for preciso para que ele consiga encontrar, entender e utilizar o software. Só aí que você vai começar a gerar algum tipo de resultado.

Criar muitas funcionalidades invés de gerar valor

Evoluindo nessa mesma linha de diferenças entre output, outcome e impact, o terceiro ponto é uma dor muito grande em relação às lideranças do desenvolvimento. Invés de gerenciar um time que gera valor, essa equipe passa a ficar mais focada apenas em criar features.

Se pensarmos em atacar um problema a partir de quais funcionalidades temos que ter para resolvê-lo, ou seja, sem olhar para o usuário e para as necessidades dele, não estamos atacando o problema real. Para fazer algo com mais sentido e impacto, pense: “Qual é a versão do meu produto que posso construir e que vai entregar o máximo de valor possível?”. Assim, você estará trazendo a funcionalidade, mas também vai precisar que os benefícios e os valores sejam considerados antes mesmo de iniciar a produção. Em outras palavras, isso é o MVP (Minimum Viable Product). Você só saberá se gerou o valor se perceber os benefícios dele. Então, a melhor versão em um processo de desenvolvimento de software é pensar nesse equilíbrio entre: geração de valor, benefícios percebidos pelo usuário e funcionalidades.

Desalinhamento entre Stakeholders

O quarto ponto, que pode fazer muita coisa dar errado, é o desalinhamento entre os stakeholders. Ter as prioridades e o formato de trabalho definidos e não alinhar esses pontos é um erro grave, que, mesmo que não intencional, pode gerar um sério problema.

O processo de desenvolvimento de software acaba se desconectando entre os envolvidos e isso pode ficar confuso. Muitas vezes, no planejamento anual, já foram discutidas todas as estimativas daquele ano, como: O que vai ser produzido? Como será a caminhada? Então, o processo é acompanhado por um comitê ou um conselho para entender se o trabalho está on track nos planos do ano.

No final, essa desconexão gera uma grande cobrança, pois, quando os stakeholders estão desconectados com o que está acontecendo no processo, essa cobrança acaba sendo incoerente. Isso porque o que é cobrado nesse momento é o output e como tá o desenvolvimento, quantas features já foram avançadas, etc.  Para além da quantidade de features entregues, é preciso olhar para os resultados ou o impacto do sistema.

Medo da incerteza

Por último, o quinto problema é o que considero como principal: o medo da incerteza. Um software bem produzido, que realmente vai entregar o valor adequado para o usuário, é incerto no curto prazo. Para construir a percepção da certeza, precisamos que ele seja iniciado para ser desenvolvido com o tempo. Caso contrário, vamos estar inserindo as features que a gente acredita que deva estar no software, não o que o usuário realmente precisa. Nós temos que estar continuamente descobrindo o que faz sentido para o usuário, e trazer isso para a priorização de desenvolvimento.

O medo da incerteza faz com que a gente tente gerar uma previsibilidade, criar uma falsa sensação de segurança, e até se comprometer com prazos, o que gera projetos de softwares mal sucedidos. Por isso, é preciso abraçarmos essa incerteza, além de ter uma forte base cultural e estrutural. A cultura certa precisa ser um ambiente que tenha segurança, confiança, que dê autonomia para a equipe, que todos os stakeholders abracem a incerteza e gostem de aprender com esse processo.

* Matheus Danemberg é fundador e CEO danav9

Siga a Bússola nas redes: Instagram | Linkedin | Twitter | Facebook | Youtube

Veja também

B2Mamy avança, impactando mais de 100 mil mães e mulheres brasileiras

Construindo um ecossistema empreendedor tecnológico para o futuro do Brasil

Sistemas legados são a maior preocupação do setor financeiro