Quem já está familiarizado com as metodologias ágeis de construção de software sabe que um dos pilares dessa abordagem é exatamente não trabalhar com um escopo perfeitamente – ou demasiadamente – definindo. Isso é importante para que haja flexibilidade na hora de desenvolver o sistema e seja possível aproveitar o próprio aprendizado adquirido durante o seu desenvolvimento. Um software, como o próprio nome já remete, precisa ser um produto ‘maleável’. Estar sujeito à alterações ao longo do projeto permite que ele apresente a melhor performance, aliada ao mais eficiente conjunto de funcionalidades, baseada em testes de uso de seu funcionamento concomitante ao desenvolvimento, sem ficar preso à uma série de requisitos estáticos previamente detalhados.
Mas se não há um escopo definido, como mensurar qual investimento será necessário para o desenvolvimento do sistema? Como defender o business case para construção da solução se não há detalhamento do seu escopo e, consequentemente, seu preço?
De forma ainda mais direta: como orçar o desenvolvimento de uma solução que será construída com métodos ágeis?
Para se explorar essa questão é importante recuar um pouco em nossa análise e perguntar: qual é o verdadeiro sentido do orçamento?
Um bom orçamento deve determinar como alocar os recursos financeiros visando o alcance de objetivos estratégicos e operacionais definidos pela organização. Do ponto de vista da TI, a alocação de recursos muitas vezes se traduz no desenvolvimento de sistemas.
E aí voltamos à pergunta original: mas quanto custará mesmo?
No caminho tradicional, para saber quanto custa basta detalhar o escopo. Uma vez definido, o preço é uma mera consequência do esforço necessário para o desenvolvimento.
E aí entramos num eterno dilema: por um lado, queremos usar metodologias ágeis, pois sabemos que os resultados são infinitamente superiores; por outro, queremos definir o escopo para definir o orçamento, pois precisamos de um número fechado!
Mas será que realmente precisamos saber exatamente qual é o escopo para definir um número? Será que não podemos defini-lo com algum racional mais simples?
Existem várias formas de fazer isso:
- Pegar alguma referência passada, de algo que parece ter complexidade similar;
- Listar requisitos em alto nível, agrupar em módulos e, mais uma vez, comparar com outras referências;
ou ainda:
- Definir um nível de investimento que parece razoável, baseado no que se espera de retorno para a solução.
Mais importante do que ter um número extremamente preciso é ter uma referência legítima. E uma vez com ela, mobilizar recursos – internos e externos – para usar o dinheiro da melhor forma possível!
Esse talvez seja o ponto mais crucial da abordagem ágil: mais importante que uma definição detalhada do que deve ser feito, é preciso partir de uma referência razoável e contar com uma equipe qualificada. Essa equipe deverá atuar da melhor maneira possível, diminuindo ao máximo os custos de transação para entregar uma solução eficiente e adequada ao investimento disponibilizado.
Após alguns ciclos de desenvolvimento ágil executados, a pergunta original nem fará mais sentido! A organização terá descoberto como gerar valor em curto prazo, já estará desfrutando de um serviço e terá várias referências para novas soluções. O processo orçamentário se torna simplificado e a energia da equipe é muito mais destinada ao que fazer do que saber exatamente como será feito. Após os primeiros resultados a organização como um todo terá estabelecido uma relação de confiança com a equipe de TI desenvolvedora e saberá que esse como significa o melhor uso possível dos recursos disponibilizados.
Existem ainda algumas técnicas para mensurar o custo de um projeto. Uma delas, por exemplo, é o planning poker. Em breve, você confere um post sobre o assunto aqui no blog.
Ainda tem alguma dúvida? Entre com contato com a gente! Podemos ajudar a sua empresa a orçar um projeto ágil.
