Abrace a incerteza: o que falta para um projeto tech alcançar os verdadeiros resultados?

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

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. É por aí que se inicia. Programar ele, 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. Ainda existem três coisas que precisam ser realizadas por ele para se pensar em uma conclusão, que são: 1) encontrar 2) aprender 3) usar. Só neste último momento que vamos começar a gerar o resultado esperado, ou seja, 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.

Pense comigo: se você entregar dez features e ninguém chegar a usar nenhuma delas, você teve algum resultado? Não! A tecnologia não é para ser só produzida, ela também precisa ser utilizada. Portanto, só quando alguém realmente usa o seu produto é que você vai enxergar o impacto e o valor que ele gera. 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.

Infelizmente, o que se vê no dia a dia é o oposto. As pessoas priorizam muito mais o esforço e valorizam o output, mas se esquecem do outcome e do impacto gerado pelo produto. 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. Se você focar muito no esforço, não vai conseguir chegar na fase de entregar algo que realmente seja valioso e útil 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. Porém, esse é um erro muito comum que eu 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 seu 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 a gente pensar 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, você não estará atacando o problema real. Se você se pergunta, por exemplo, o que seria legal de fazer, ou o que você acha que deve fazer, você acaba desenvolvendo apenas uma série de funcionalidades. O valor e os benefícios acabam não sendo o seu foco principal.

Uma outra abordagem que a gente pode ter na hora de desenvolver um produto é se perguntar qual é o mínimo de funcionalidades necessárias para gerar um valor. Ainda assim, você está partindo das funções e deixando o valor de lado. Basicamente, é pensar como o primeiro ponto levantado aqui: foco em esforço e produção. Eu entendo, afinal, é confortável pensar dessa forma. É onde temos mais controle.

Porém, se você quer fazer algo com mais sentido e impacto, pense: “Qual é a versão do meu produto que eu 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.

Portanto, essa é uma visão mais equilibrada para o desenvolvimento do seu produto. Inicialmente, ele não vai ter tantas features, benefícios e nem muito valor, mas será uma versão harmoniosa que conseguirá capturar o verdadeiro valor que for necessário dos usuários.

Em outras palavras, isso é o MVP (Minimum Viable Product). Você só saberá se gerou o valor se perceber os benefícios dele. Você consegue isso analisando o impacto que gerou, e perceberá que não precisava ter tantas funcionalidades já prontas. É necessário apenas validar se a proposta de valor pensada inicialmente é realmente útil para o usuário.

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. Infelizmente, ainda vejo isso acontecendo bastante. Mesmo que não intencional, isso 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.

Mas, geralmente, essa parte fica num nível mais estratégico e não passa para a realidade do desenvolvimento. No final, o que rola mesmo é 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.

Essa desconexão do que está acontecendo no dia a dia com quem está avaliando o andamento gera uma dor que faz o projeto não dar certo. As pessoas envolvidas, portanto, deixam de acreditar nele. Se eu chego no trimestre e vou medir o desempenho desse time de software pela quantidade de features que ele entregou, eu vou estar medindo só o output. Sem olhar para os resultados ou o impacto do sistema, a avaliação está levando em consideração critérios falhos.

Medo da incerteza

Por último, o quinto problema é o que eu considero o principal de todos eles: 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, a gente precisa que ele seja iniciado para ser desenvolvido com o tempo. Não podemos, no dia zero, ter certeza do que ele vai ser nos próximos 6 meses. 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.

O que o ágil traz como alternativa é ter dois caminhos no processo acontecendo ao mesmo tempo. O de descoberta e o de desenvolvimento. 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. No entanto, é isso que gera projetos de softwares mal sucedidos. Se a gente não abraçar essa incerteza, a gente vai estar construindo um software que descobre pouco e que entrega para o usuário o que a gente acha que é o certo e não o que ele vê valor e quer usar.

Para mudar essa realidade e começar a implementar o verdadeiro valor no desenvolvimento de um produto, é preciso ter uma forte base cultural e estrutural. Se a cultura não estiver alinhada para desenvolver softwares que façam sentido, não tem estrutura que gere o resultado certo.

Por isso, a cultura certa precisa ser um ambiente que tenha segurança, confiança, que dê autonomia para o time, que todos os stakeholders abracem a incerteza e gostem de aprender com esse processo. Não ter isso como base dificulta tudo. A gente pode entregar muito valor com uma estratégia coerente, com base cultural e com o incentivo certo do time.

Mini bio Matheus Danemberg*:

Matheus Danemberg é fundador da nav9. Gaúcho de Pelotas, Matheus sempre teve o conhecimento no centro de sua criação. Com veia empreendedora, ele tem uma história de superação e, após falir quatro vezes, fundou uma empresa de sucesso: a nav9.

Sobre a nav9:

A nav9 é uma tech solving partner criada para impulsionar o crescimento dos negócios. Unindo gestão ágil, design e engenharia de software, a empresa entende e resolve três principais problemas: foco, contexto e velocidade. Com uma metodologia exclusiva, a nav9 auxilia companhias a entender o contexto e a vivenciar a experiência no ambiente digital, sendo parceira para guiá-las ao cenário ideal da entrega, organizar os processos ágeis e materializar os produtos com capacidade máxima de resolução, agilidade e escalabilidade. Acesse o site da empresa e saiba mais.