A maioria dos projetos atrasa, estoura o orçamento e ainda fica aquém do esperado. Em geral damos um jeitinho de contornar essas situações, mas sempre há um preço a ser pago: trabalhar até mais tarde, diminuir a qualidade, perder a reputação e a confiança do cliente.
Existem diversas fontes de problemas que afetam um projeto de software, desde a negociação até a entrega. Porém, acredito que a maior contribuição para o constante fracasso do planejamento é oriunda de uma negação interior, lá no fundo, do fato de que…
Não podemos ter tudo
O grande desejo de todo administrador é produzir com o mínimo de recursos, no menor tempo possível, o produto com maior valor e qualidade do mercado. Mas não é assim que as coisas funcionam. Algo deve ser sacrificado.
Irei enfatizar essa verdade, de que não podemos ter tudo, com algumas analogias corriqueiras, pois é um paradigma para todas as esferas da vida. Quando usamos ingredientes baratos e de baixa qualidade em nossa alimentação, aliviamos o bolso mas a saúde vai de mal a pior. Se economizamos no material de construção, logo teremos goteiras e infiltrações. Se contratamos o buffet mais “econômico” para o casamento, os convidados irão, no mínimo, sair reclamando de fome e, no pior caso, acabar no hospital com intoxicação alimentar. Quando aplicarmos esse princípio conscientemente em nosso trabalho teremos menos dificuldades em entender nossos fracassos.
Se montarmos uma equipe somente com programadores juniors, podemos esperar qualidade? Se temos desenvolvedores experientes, mas o tempo é escasso, podemos esperar que todas as funcionalidades sejam entregues?
Perceba que, no contexto de um projeto de software, existem elementos que funcionam como variáveis de uma equação, gerando consequentes restrições. Se mexemos em uma delas, todas as demais são afetadas. Como abstraímos e representamos esse conceito?
O triângulo de ferro
O Triângulo de Ferro 1
O “triângulo de ferro” (iron triangle), “triângulo do projeto”, “triângulo das compensações”, “triângulo das restrições” ou ainda “restrições triplas” é uma representação do relacionamento entre as principais variáveis de um projeto: recursos, tempo e escopo. Existe ainda um quarto elemento, ou quarta dimensão, que alguns autores acrescentam: a qualidade. Esta seria resultante das decisões tomadas em relação às demais variáveis.
Através do triângulo de ferro conseguimos visualizar certas consequências do *trade-off *das escolhas e restrições de um projeto. Em suma, o que a figura nos ensina é: todos os aspectos do projeto estão interligados. Não é possível alterar um deles sem afetar os demais. Recursos, tempo, escopo e qualidade possuem uma relação implícita.
Na prática: Quer mais qualidade? Aumente os recursos ou o tempo! Quer aumentar o escopo? Aumente o tempo ou os recursos! E assim vai…
Porque nós, desenvolvedores, deveríamos nos preocupar com isso?
Todo gerente de projetos deveria conhecer o triângulo de cor e salteado. Porém, o ideal é que todos os envolvidos em um projeto tenham um grau de consciência dessas restrições. Digo isso porque, falando especificamente da área de TI, a equipe de desenvolvimento sofre uma série de pressões do cliente e da gerência no decorrer do projeto e torna-se essencial equilibrar essas variáveis, reconhecendo aquilo que está dentro das possibilidades e tomando a decisão adequada. Os clientes sempre querem que entreguemos mais funcionalidades, com mais qualidade e mais rapidamente, mas com os mesmo ou até menos recursos. Quando a gerência não trata disso, a corrente arrebenta no elo mais fraco, isto é, os desenvolvedores “pagam” pelos diversos erros em todos os níveis do projeto tendo que fazer inúmeras horas extras.
Em minha experiência, o melhor remédio para o trabalho em excesso é a prevenção. Uma coisa é colaborar para o sucesso do seu empregador, outra é aceitar tudo o que lhe é imposto. Nós, desenvolvedores, devemos aprender a analisar a situação e, ao detectarmos problemas no projeto, negociarmos de antemão. Isso significa que, se sua empresa está prometendo o que você sabe que ela não pode cumprir, é melhor deixar isso claro desde o início para os responsáveis. Não estou dizendo para você desafiá-los ou confrontá-los rudemente, mas sim tentar expor de modo gentil e firme seu ponto de vista. Se eles derem ouvidos, ótimo, de outra forma, ao menos eles perceberão que você é um profissional sério e sabe o que está fazendo.
Entendendo as variáveis do projeto
Recursos
Embora o termo “recurso” seja ofensivo para alguns quando se trata de pessoas, ele é adequado quando falamos do investimento em um projeto. Esse investimento se traduz na contratação ou alocação da equipe, nos equipamentos necessários, espaço físico e outros itens. Embora, devido ao overhead, a quantidade de recursos não seja tão proporcional à produtividade, ainda assim podemos afirmar que, no geral, quanto mais recursos maior é a produtividade.
Tempo
Geralmente existe uma data limite definida pelo negócio, devido à uma janela de oportunidade, onde o software deve ser entregue.
Escopo
Quais funcionalidades serão entregues? Nem todos os requisitos e funcionalidades possuem a mesma prioridade. Num processo iterativo de desenvolvimento, deve-se definir junto ao pessoal de negócios quais funcionalidades trazem mais valor. Nem sempre é possível fazer tudo.
Qualidade
A qualidade é uma quarta dimensão entre as variáveis do projeto, a qual é influenciada pelas demais restrições. Como qualidade não é algo objetivamente mensurável, não há como fixar um valor para essa variável. Entretanto, se existe um padrão mínimo de qualidade para o projeto, devemos ajustar as demais variáveis de modo a atingir esse objetivo.
Conjugando as restrições
A fim de planejar, o gerente do projeto deve considerar as restrições, fixar as variáveis críticas e então estimar as demais. De forma incoerente, alguns tentam fixar todas elas, o que sempre resultará nas falhas descritas no início deste artigo. Quantas e quais variáveis são fixas, depende do projeto e do modelo de desenvolvimento adotado.
Variando o escopo e fixando os recursos e o tempo
Se temos uma equipe e um prazo fixos, então devemos estimar quais funcionalidades poderemos entregar de acordo com a produtividade da equipe dentro do tempo disponível.
Variando os recursos e fixando o tempo e o escopo
Temos um conjunto de funcionalidades a serem implementadas até uma data limite. Podemos então estimar o esforço necessário para completar a tarefa dentro do esperado. Quantas horas e quantos desenvolvedores serão necessários para completar as tarefas?
Variando o tempo e fixando o escopo e os recursos
Contamos com N desenvolvedores para entregar X funcionalidades. Com isso, estimamos em quanto tempo concluiremos o projeto.
Variando a qualidade
O projeto está atrasado. Não há tempo, nem como obter ajuda porque não há mais pessoas com conhecimento do projeto e ninguém quer negociar com o cliente uma entrega parcial, já que o relacionamento com ele está desgastado há meses. Então todos aceleram o passo. Testes? Para quê? As horas extras vão ajudar a pagar aquela fatura do cartão, não é? Será possível fixar tempo, escopo e recursos?
Então, na noite de sexta-feira, todos limpam o suor do rosto e suspiram de aliviados. A release já está no cliente. De alma lavada vão para o seu merecido descanso, pensando em como ultrapassaram as expectativas. Até a segunda de manhã, quando o cliente liga muito bravo devido à quantidade absurda de erros. Parabéns, foi entregue um produto no prazo, no orçamento e completo, mas que não funciona. Um software de péssima qualidade que demandará mais tempo de manutenção que desenvolvimento!
Você conhece algum caso onde o sistema foi enviado ao cliente sem passar por testes porque os desenvolvedores só concluíram o que foi prometido em cima da hora?
A qualidade é influenciada de diversas formas, sendo os principais fatores relacionados às pessoas envolvidas, tais como: equipe inexperiente ou desmotivada, pressão para concluir o projeto, dificuldades de comunicação.
O que vale mais para você?
Variáveis fixas e estimadas conforme o tipo de plano 2
A gestão “tradicional” de TI geralmente foca no plano. Por “tradicional”, entenda aquilo que temos feito vez após vez nos últimos anos de forma irrefletida. Planeja-se a implementação sequencial das funcionalidades de acordo com a quantidade de recursos e o tempo disponíveis. “Vamos começar pelos cadastros mais simples, para ir pegando o jeito, depois avançamos para as regras de negócio mais complexas”, é algo comum de ouvir, uma tendência natural que se percebe.
Em contrapartida, processos modernos, principalmente os ágeis, procuram focar em trazer valor ao cliente. Com uma equipe e iterações fixas, priorizam-se as funcionalidades que mais beneficiarão o cliente e, a cada iteração, uma nova versão funcional do sistema é entregue. Ao aplicarmos o Princípio de Pareto (regra do 80-20), em tese, pode-se entregar 80% do valor do sistema nos primeiros 20% do projeto.
Lições e Conclusões
O triângulo de ferro é apenas uma representação, mas nos dá um referencial para entendermos as consequências das escolhas que fazemos. Não podemos ter tudo. Mesmo quando alguém acha que pode, na verdade estará sacrificando algo. No que se refere ao desenvolvimento de software, geralmente é a qualidade.
Um projeto é mais que cronograma, um gráfico ou qualquer documento, não podemos manipular a nosso bel-prazer. Se tentarmos forçar as variáveis do projetos certamente afetaremos algo. Justamente por isso o nome “triângulo de ferro”.
Além da adoção de um processo adequado, de ações preventivas e de boas práticas em todas as fases e áreas do desenvolvimento de software, as melhores formas de lidar com as inevitáveis restrições e dificuldades dos projetos são: aprender a negociar as restrições junto ao cliente e à gerência e priorizar devidamente as funcionalidades de modo a entregar algo de valor ao cliente.
Para concluir, uma citação que usei na minha monografia sobre estimação de software:
Frequentemente falta aos gerentes de software firmeza de fazer o pessoal esperar por um bom produto 3
Referências
1) O Triângulo das Restrições de Gerenciamento de Projetos (acessado em 30/09/2013)
2) Scope, Time & Cost Triangle Balancing To Motivate Team and Satisfy Client (acessado em 30/09/2013)
3) BROOKS, F., The Mythical Man-Month, Addison-Wesley, 1975
