5 erros de gestão para entregar software medíocre

Projetos de software nascem a partir de pré-suposições e hipóteses. Existe uma dor ou problema a ser resolvido, e uma suposição sobre como o software pode resolver isso. Quando tomamos como certo uma suposição, sem fatos para comprova-lá, ela se torna uma hipótese. Ignorar as hipóteses é o primeiro passo que leva ao desenvolvimento de produtos medíocres.

O que leva um software ao sucesso, é o método de trabalho que é construído ao longo do desenvolvimento dele. É você conseguir ser eficaz, entregando a coisa certa, entregando o que o usuário precisa. É necessário um processo com foco na eficácia, não na eficiência.

Confira os cinco principais erros que te levam a criar um produto medíocre, que ninguém gosta de usar mas usa porque precisa.

1. Foco na eficiência

Eficiência é fazer certo alguma coisa, eficácia é fazer a coisa certa. Ambas são duas dimensões complementares, dois lados da mesma moeda.

Estamos em um mercado cuja forma de operar é focada primariamente na eficiência. Há o costume de tomar diversas decisões que afetam o produto antes de validar a proposta de solução para o problema de negócio e de ter certeza de estar fazendo a coisa certa. Uma empresa que eu conheci, tomou decisões de arquitetura de software e tecnologia baseadas na expectativa de obter dez mil usuários no primeiro mês, que afetaram negativamente a velocidade de entrega dos times, resultando em um produto medíocre que alcançou menos de duzentos usuários.

O maior desperdício em projetos de software é fazer certo a coisa errada. Eu já desenvolvi um aplicativo que possibilitava aos usuários contratarem seguranças armados para própria proteção. Foram três meses de projeto, o aplicativo funcionava para todas as plataformas e podia suportar mais de dez mil usuários simultâneos. Porém, ele não resolvia nenhuma dor do usuário. Os usuários estavam satisfeitos utilizando o Whatsapp para isso, não precisavam de um aplicativo. Ou seja, foi feito certo, a coisa errada, devido a uma hipótese não validada.

Há um enorme desafio em educar as pessoas envolvidas em projeto de software. O cliente, em muitos casos, é a parte mais difícil. Isso porque ele usa como exemplo um software que ele operou por muito tempo ou o software do concorrente. Sua referência são as funcionalidades desses softwares. Isso o leva a crer que suas suposições são fatos confirmados e a menosprezar a importância de validar hipóteses.

Àqueles que seguem o caminho da eficácia, acabam sendo premiados. Certa vez fui contratado para melhorar o ecommerce que rodava em Wordpress. O site já estava há 1 ano no ar e, tinha um número de vendas extremamente baixo e ainda assim apresenta instabilidade frequentemente. Após ouvir as dores da empresa, entendi que a solução atual estava longe de ser a melhor. Descobrimos que os clientes preferiam comprar via telefone e usavam o site como catálogo de produtos. A solução criada foi gerar um site estático sempre que havia alteração ou cadastro de novos produtos pelo ERP da empresa. Com isso os clientes ficaram muito satisfeitos com um site bem rápido, o custo da infra estrutura reduziu em 95% e nunca mais houve indisponibilidade do site. Esse produto foi essencial para aumentar o valuation da empresa, que foi comprada pelo concorrente cinco anos depois.

O que o cliente quer é diferente do que ele precisa. O objetivo do projeto deve ser entregar o software que o cliente precisa.

2. Foco no problema

O cliente não quer seu software, quer o problema dele resolvido. Geralmente o que o cliente quer não é o que ele pede. Raramente ele sabe do que precisa. Para descobrir o que o cliente precisa, é necessário entender o problema para saber se a solução proposta será eficaz. Você não deve se comprometer com um escopo que não está associado à nenhum problema concreto. Muita coisa passa despercebida quando estamos concentrados em entregar só o que prometemos.

O desafio é ajudar o cliente a entender o que precisa. Quando ele exige que você faça o que ele quer, ele está te direcionando para uma solução antes mesmo que você tenha dominado o entendimento do problema. Ele está te colocando no papel de um mero implementador da solução criada por ele, desperdiçando o seu potencial como solucionador de problemas.

Como um mero implementador, você será avaliado pela sua capacidade de entregar mais funcionalidades, de forma mais rápida ou mais barata. A métrica de sucesso passa a ser a satisfação do cliente com o cumprimento dos prazos, deixando a felicidade dos usuários em segundo plano.

Quando você não corresponde as expectativas de entrega em relação ao prazo, o cliente trata como custo e não como investimento. Ele entra em um estado de ansiedade e nervosismo, pressionando o time à trabalhar mais. Isso apenas intensifica o problema e cria uma distração do time em relação a qualidade do que está sendo entregue. Nesse momento, nasce o caos.

3. Foco no prazo

Um software é um organismo evoluindo em direção ao amadurecimento. Ele nunca está concluído. Ele está em constante mudança até que seja abandonado. A mudança começa a partir da identificação de uma dor, depois do entendimento dela, em seguida a criação de uma proposta de solução e por fim a validação dela. Não há como ter certeza qual o tempo exato que essa iteração vai levar. Quando o cliente pergunta qual o prazo de alguma coisa, qualquer resposta é apenas uma hipótese.

É o tempo que define a solução, e não o contrário. É preciso sair do modelo onde uma data é extraída do que precisa ser feito, para um modelo onde é feito algo levando em consideração a restrição de tempo.

O tempo que importa é o tempo da entrega de valor, e não o tempo que demora para implementar uma funcionalidade. O que o cliente realmente quer saber na maioria das vezes é quanto tempo ele vai levar pra receber, não quanto tempo demora para implementar. O tempo de entrega é a soma do tempo de implementação mais o tempo gasto parado com impedimentos. Previsibilidade é um mito.

Quando se olha para o histórico de atividades concluídas, identificamos alguns pontos em comum com o que precisamos fazer agora, e usamos da lógica para chegar a uma estimativa de quanto tempo levaremos para isso, com adição de uma folga para contemplar imprevistos. Estimativas não passam de hipóteses com alta probabilidade.

É um grande risco para o negócio considerar estimativas como certezas. Imprevistos ou mudanças surgem no decorrer do tempo, levando o time a se preocupar com a quantidade de coisas entregues e não com a qualidade delas.

4. Pessoas erradas

Os times são formados antes de terem o entendimento completo dos problemas a serem resolvidos. É levado em conta a quantidade de pessoas disponíveis no momento, a senioridade delas e o orçamento disponível. Isso leva ao equívoco de adicionar profissionais excelentes, mas pessoas erradas, para resolver os problemas.

A busca pela eficácia demanda que você não se comprometa de imediato com uma opção, mas que você valide as hipóteses o mais rápido possível. Devemos ser céticos em relação à solução escolhida, pois o caminho escolhido pode estar errado. Precisamos montar um time multidisciplinar com pessoas que tenham as habilidades certas para executar o trabalho e agir em torno do problema que precisa ser resolvido. Nos concentrar em buscar por competências específicas não em preencher cargos e funções no projeto.

As pessoas certas serão capazes de criar propostas para dar a melhor solução possível dentro das restrições existentes. Sem as pessoas certas, todas as necessidades são transformadas em funcionalidades a serem desenvolvidas no software. O resultado final de qualquer esforço é muito mais em função de quem faz o trabalho do que de como o trabalho é feito.

5. Contrato de Escopo Fechado

Um contrato de Escopo Fechado determina qual a solução que precisa ser construída dentro de um determinado prazo. É uma tentativa de eliminar os riscos oriundos da falta de confiança na relação entre cliente e fornecedor. O software se torna parte do contrato, junto com os recursos financeiros alocados para desenvolve-lo. Essa tentativa ameaça significantemente a chance do projeto dar certo.

Não há como prever antes do desenvolvimento começar, quais serão as melhores escolhas a serem seguidas. Apenas durante o desenvolvimento, validando hipóteses e colhendo feedback dos usuários sobre o que foi entregue, que podemos nos orientar sobre qual caminho seguir.

Na busca da eficácia, devemos trabalhar com Escopo Aberto. Nessa abordagem, quem vai desenvolver a solução se compromete em planejar junto com o cliente entregas semanais ou quinzenais de software funcionando de acordo com sua necessidade.

Um projeto de software com Escopo Fechado elimina o processo de busca pela solução, e o substitui por um processo de implementação de uma solução previamente definida, resultando em produtos medíocres.

Conclusão

A falta de foco na eficácia é a raiz de todo mal em desenvolvimento de software. Perde-se muito tempo discutindo sobre como fazer alguma coisa sem saber se é a coisa certa a ser feita. Há três perguntas que eu sempre faço antes de implementar alguma coisa:

1. Qual a dor existente no momento que isso resolve?
2. Essa é a solução mais simples nesse momento?
3. Como posso validar e colher feedback para ter certeza de que fiz a coisa certa?

É impressionante como essas perguntas já me salvaram muitas vezes. =)
Eu apontei os principais problemas, mas não apresentei nenhuma proposta de solução. Assim como foi apresentado, esse texto é apenas para validar se as pessoas enxergam e concordam com esses problemas. Se eu tiver um feedback positivo, vou escrever sobre como melhorar seu processo de desenvolvimento de software.

Não deixe de conferir esse conteúdo também: https://github.com/gustavohenrique/guia-para-times-tecnicos