Business

A armadilha da previsibilidade – Parte II

Por: , julho 21, 2014

No primeiro artigo desta série, vimos por que tentar definir a priori todas as características de um projeto de desenvolvimento de software é impossível e indesejado.
Vamos analisar agora um pouco quais são as consequências desta “busca”, tanto para o projeto em si, quanto para a cultura e o ambiente de trabalho dos grupos envolvidos nestes projetos.
Analisando os projetos em si, podemos perceber as seguintes questões:

  • A busca da previsibilidade acaba gerando grandes desperdícios, em vários pontos do processo. Desde a adição de risco em vários pontos do processo (afinal as pessoas sabem que serão medidas por “acertarem as previsões”, e a única forma de aumentar a chance de acerto é considerar altas margens de risco); os controles e documentações inseridos no processo apenas para tentar garantir a previsibilidade; diversos requisitos não importantes que acabam sendo solicitados pelas áreas de negócio (pois estas não vão poder “mudar de ideia depois”); a tendência de criar softwares que atendam a diversos possíveis cenários, mesmo sem saber se eles precisarão ser considerados ou não. E a tudo isto devemos somar os problemas gerados pelos frequentes estouros de orçamento e prazo, que apesar de todos os desperdícios citados (e também por causa deles) continuam acontecendo.
  • A busca pela previsibilidade, e a avaliação das pessoas baseadas nela, faz com que o foco das equipes de projeto se concentre nela. O mais importante não passa a ser atingir um objetivo de negócio, mas sim “anteder a um prazo”, ou “fazer o escopo combinado e ficar dentro do orçamento”. Todas as oportunidades de aprendizado que a execução do projeto traz ficam em segundo plano, e são na maior parte das vezes vistas como “problemas” a serem evitados. Mesmo quando se percebe que o caminho que o projeto está tomando não vai trazer os resultados de negócio esperado, o foco continua no plano original.
  • Outra grave questão costuma ser a penalização da qualidade do sistema. Com o engessamento do escopo, prazo e custo, a única margem de manobra que sobra para a equipe tentar contornar qualquer contratempo é sacrificar a qualidade do sistema. Mas isso acaba se tornando uma bomba-relógio, pois a perda de qualidade vai cobrar seu preço, tornando as manutenções e evoluções do sistema muito mais caras no futuro.
  • E finalmente o conflito entre os vários envolvidos no projeto torna-se inevitável. Seja envolvendo um desenvolvedor que vai ser “punido” por um problema que ele não tinha como prever, outro que vai ser “premiado” por pura sorte, um stakeholder que descobre “tarde de mais” que o sistema precisa considerar uma situação não especificada ou ainda um gerente que simplesmente tenta com todas as forças tornar o “imprevisível” previsível. E com a degradação do clima, certamente cai também a produtividade do time, e principalmente sua capacidade de pensar soluções inovadoras para os problemas do projeto.

Mas infelizmente os problemas não param por aí. Uma consequência ao meu ver muito mais séria é o impacto do problema na cultura da empresa.
A busca impossível pela previsibilidade acaba rapidamente se transformando em uma busca de culpados pelos problemas dos projetos, o que gera uma tendência nas pessoas de se preocuparem mais em se proteger do que em efetivamente buscar melhorias e aprendizados. A melhor estratégia pessoal vira o padrão de se embutir risco em tudo, de se buscar definir compromissos em escopos cada vez menores (que possam depender “só de mim” ou do “meu time”), mesmo que estes compromissos não representem valor nenhum para a empresa.
Quem nunca ouviu frases como “eu fiz a minha parte”, “quem definiu o prazo não fui eu” ou “eu disse que não ia dar certo”? Estas colocações mostram o ambiente extremamente nocivo que a visão atual cria, e que só geram prejuízos aos projeto e às empresas. A busca da criação de um grupo coeso para o projeto, onde todos tenham o mesmo objetivo e trabalhem de forma integrada para atingí-lo (afinal não era essa a meta ao se criar uma equipe de projeto?) se perde completamente pelos mecanismos de defesa criados para tentar atingir a previsibilidade.

A saída do labirinto

Mas existem alternativas a estes modelos, e muitas empresas já estão se beneficiando de projetos mais bem sucedidos. A maior questão, porém, é que eles exigem uma mudança na forma como enxergamos os projetos – um exemplo da tão falada “mudança de paradigma”.
Se entendemos que os projetos de software não são “previsíveis” na concepção tradicional da palavra, como podemos gerí-los?
A primeira conclusão é que os projetos vão precisar lidar com situações não previstas, e portanto precisarão mudar ao longo de sua execução.
E se os projetos vão precisar de flexibilidade para mudar, uma boa forma de prover isto é dar mais autonomia para o projeto. Um impacto disso é na forma como definimos as equipes de projetos, pois elas precisarão ser compostas por pessoas de várias áreas, que tragam as várias visões necessárias para se atingir o sucesso. O conceito de “equipes de TI” separadas de “grupos de operação” e “times de marketing” deve ser substituído por uma equipe realmente multidisciplinar, auto-organizada e responsável pelo resultado final do projeto. Uma boa notícia nesta área é que estas estruturas estão muito mais alinhadas com modernas visões de motivação das pessoas, que mostram que todos nós buscamos autonomia, propósito e melhoria contínua.
Outro impacto claro é que a forma de acompanhar os projetos precisa evoluir. Não faz sentido a direção de uma empresa avaliar um projeto pela sua adequação a um escopo pré-definido, ou o cumprimento de um orçamento. É necessário se definir objetivos de negócio claros para os projetos, de forma a dar direção e ao mesmo tempo liberdade de ação para a equipe poder tratar as situações que vão acontecer durante sua execução. E o acompanhamento precisará ser feito sobre esses objetivos de negócio. Periodicamente a direção da empresa deverá discutir com a equipe do projeto os resultados que estão sendo obtidos, os aprendizados, e avaliar se devem ser feitos ajustes no projeto. Esta mudança pode trazer também um grande benefício para a direção das empresas, pois finalmente vai permitir que ela foque nos desafios estratégicos da companhia.
Para tratar a questão do orçamento do projeto, várias das ferramentas utilizadas atualmente (como cáculos de ROI e valor presente) podem ser adaptadas para se basearem nos resultados de negócio esperados, o que na verdade vai traduzir de forma muito mais precisa sua intenção original. Outras técnicas que tem se tornado comum no ambiente de start-ups podem ser mais adequadas em cenários de maior incerteza, como a definição de burn-rate. O importante novamente é não perder de vista os objetivos de negócio, e lembrar que a equipe vai precisar de liberdade de ação no projeto. E que a avaliação de se o projeto “vale a pena” não poderá ser feita em um único momento no início do mesmo, mas vai ter que ser revisitada sempre que ocorrer um novo aprendizado significativo.
Para poder gerar o maior valor para o negócio dentro deste contexto, a própria estratégia de execução vai precisar ser ajustada. Os projetos deverão ser planejados de forma a minimizar os riscos, procurando validar rapidamente e com o menor custo possível as hipóteses que se apresentem – técnica muito utilizada também nas empresas que usam o modelo de lean startups. Outro direcionador deve ser a entrega rápida de valor de negócio, com versões incrementais do sistema sendo colocadas em produção, que melhora o retorno sobre o investimento. Estas duas táticas também aceleram o aprendizado da equipe, o que vai viabilizar melhores decisões no futuro.
Quando a empresa faz a análise de seu conjunto de projetos, vai perceber que na verdade estas técnicas tem o potencial de reduzir seu risco global e aumentar o retorno consolidado do seu portfólio. E, ao empregar uma visão dinâmica a este sistema, volta a trazer para a direção a capacidade de gerir de forma mais efetiva os recursos da empresa, podendo reorientar os projetos e os investimentos baseado no aprendizado e no retorno que forem obtidos.
A mudança de mentalidade necessária para repensar estes conceitos não é simples, porém já está na hora de percebermos que os frequentes problemas que todas as empresas enfrentam em seus projetos de software são derivados das nossas falhas em entender as reais complexidades envolvidas, e não em eventuais erros das equipes. E os ganhos que o novo enfoque podem trazer são exatamente o que as empresas precisam no atual cenário competitivo.
 
Este artigo apareceu originalmente na CIO magazine.
 

  • Receba nosso conteúdo em primeira mão.