Por Matheus Danemberg, fundador e CEO da nav9.
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.
