Definindo sucesso em projetos de software

Vou começar este post fazendo uma pergunta: Como você define sucesso em um projeto de software? Se você respondeu entregar tudo o que o cliente pediu dentro do prazo e custo estimados, você está errado e vou explicar porque.

Triângulo impossível

Triângulo impossível

Não podemos ser tão ingênuos ao ponto de imaginar que um projeto de software, possa ser plenamente medido e é esse mesmo o termo que usam no início do trabalho, que tudo será entregue dentro do prazo e com o custo inicial. Se pensarmos assim estamos tentando fechar o que chamamos no meio ágil de “Triângulo Impossível“. Se você pensa assim está tentando unir os lado desse triângulo. Quem aqui já não esteve num projeto que demorou mais do que o estimado ou então que custou mais do que o previsto? Fechar prazo, escopo e custo é a evidência que estamos trabalhando em um projeto deste tipo. E o que dizer então daqueles projetos de 12 meses que o CIO pergunta como está e todos os meses está tudo bem, até o 11° mês que está tudo atrasado.

É inconcebível achar que podemos prever tudo o que ocorrerá dentro do projeto, pois sempre tem aquele colaborador(palavra da moda para funcionário) que tem um imprevisto, por um motivo ou outro tem de se ausentar do trabalho. E o que dizer daquela funcionalidade que ficamos mais de meses desenvolvendo e de um dia para o outro muda completamente. A verdade é que não podemos prever nada além do horizonte que podemos visualizar, é como a previsão do tempo. Hoje você pode imaginar, sem muita precisão como estará o tempo amanhã mas e daqui a 3 meses? O Standish Group em seu Chaos Report, demonstra que os projetos de software tem falhado mais do que tem sido considerado sucesso. Vale a pensa salientar que:

Sucesso: Projeto entregue dentro do prazo, custo e com o escopo previamente estimado.

Falho: Projeto que não foi efetivamente entregue, é aquele que sequer foi colocado em produção.

Desafiado: Aquele que teve alguma das 3 premissas alterada, ou até mesmo em muitos casos todas as 3 alteradas, escopo, prazo ou custo. O gráfico a seguir mostra a evolução dos casos desse estudo ao longo dos anos:

Gráfico de sucesso dos projetos de TI

Analisando os dados acima chegamos a conclusão que nós, TI em geral mais falhamos do que entregamos nossos produtos, essa é a minha visão, já que pouco mais de 30% dos projetos atingiram o almejado “sucesso”. Algumas pessoas dirão que com alguns desvios entregamos mais do que falhamos, se somados os desafiados, mas isso é balela.

A verdade é que se nós fossemos uma empresa que faz automóveis, a cada 3 carros, um não entregaríamos e outro ainda entregaríamos faltando uma roda, ou o motor, ou quem sabe duas vezes mais caro do que a estimativa inicial. Em projetos ágeis assumimos que não é possível prever tudo o que irá ocorrer durante todo o projeto. Assim focamos na entrega de funcionalidade de alto valor agregado e não olhamos um horizonte que não podemos visualizar. Estimativas em projetos ágeis existem sim, mas esse assunto irei tratar em outro post.

O que quero mostrar aqui é que se a sua visão de sucesso estiver atrelada ao triângulo impossível você deve já rever seus conceitos. Assuma que é necessário mudar a forma como você enxerga o seu cliente, o negócio dele e sua real capacidade de entregar software de valor agregado.

Para mim sucesso em software é negócio atendido, cliente feliz e satisfeito. As vezes não entregar tudo, mas sim o que meu cliente precisa o deixará feliz e isso significa novas oportunidades de negócio. Lembro das inúmeras solicitações de mudança que existiam antes de implantarmos Scrum aqui na empresa, e vejo hoje alterações de escopo cada vez mais raras.  Hoje assumo que nossa capacidade de entrega varia muito, e que justamente por isso devemos ser transparentes com nossos clientes, mostrando à eles nossa real capacidade e não gerando falsas expectativas e portanto futuras decepções.

Se você estiver interessado em começar a pensar ágil a Infoq disponibiliza o download do livro “Scrum e XP direto das Trincheiras“, considerado por muitos a melhor leitura para iniciar o processo de mudança de postura ágil.

10 pensamentos sobre “Definindo sucesso em projetos de software

  1. Oi Miguel, gostei no post. O que vc chama de “Triangulo Impossível”, é uma trade-off, que na maioria das vezes se manifesta durante o projeto.
    Na comparação da entrega (ou projeto) de software com automóveis, é preciso tomar cuidado, pois, os tipos de processos distintos. Desenvolvimento de Software é um processo empírico e produzir automóveis é um processo definido.

    • OI Rildo, concordo contigo quanto a analogia sobre a entrega e automóveis, pois não somos uma linha de montagem, mas sim um trabalho criativo, o que torna nosso produto ainda mais difícil de ser mensurado, Assim como é injusto comparar com construção civil ou com uma plataforma de petróleo. Usei esse termo inspirado em uma conversa com o Giovanni Bassi ha alguns meses atrás, e gosto dele apenas para alertar que se não tomarmos cuidado com nosso trabalho podemos ser taxado, ou talvez já sejamos como irresponsáveis ou incompetentes.

      Abraços

  2. Muito bom, só complementar que às vezes as empresas acham que tão trabalhando de forma ágil mas não executa direito o que deve ser feito e o projeto com continuar na estatística de problema de prazo e custo.

    • Existem correntes no agile que dizem que muitas empresas estão fazendo mini waterfalls com Scrum. Isso fere o manifesto ágil, no final é tudo scrum flácido, ou o chamado “ScrumBut”. Isso é muito ruim porque a imagem que passa é que a agilidade é instalável como são os software, o que não é verdade, é mais como uma cultura.
      []’s

  3. Pingback: Estimativa em projetos ágeis. « Blog do Miguel Carlos

Deixar mensagem para Helio Cancelar resposta