Tempo de leitura: 5 minutos
No desenvolvimento de software, a premissa de bom, rápido e barato é difícil de alcançar. Podemos conseguir os três? É possível alcançar um equilíbrio? Vamos falar sobre isso aqui.
Muitos de nós que trabalham na indústria de software, quando começamos a trabalhar em cotações, consultas ou estimativas de projetos, enfrentamos um must quase inevitável do mercado: desenvolver software bom, rápido e barato. É possível ter estas três variáveis ao mesmo tempo? Esta idéia é utópica?
Para responder a esta pergunta e ver a viabilidade deste postulado, é importante que primeiro revisemos duas idéias-chave.
Que preço você coloca em uma entidade intangível?
Software é um produto intangível; não podemos vê-lo, nem conhecer a sua bondade até que ele esteja terminado. Colocar um preço no desenvolvimento de um software é algo complexo (a menos que você compre software empacotado ao invés de desenvolvimento personalizado), não só por causa da subjetividade que existe do seu valor (baseado em muitos critérios), mas também por causa das diferenças existentes sobre se o projeto é mais fácil ou mais complexo de realizar.
Espera, um pilar para o sucesso
Dada a conjuntura do intangível, fazer uma estimativa correcta -e o mais precisa possível, dado que é uma aproximação-, é muito importante para que se evitem derrapagens orçamentais e perdas de tempo.
Conteúdo relacionado: 10 dicas úteis para a estimativa de projetos de software
Cientes de que uma boa estimativa é a base para o sucesso de um projeto de desenvolvimento, não podemos ignorar o fato de que toda estimativa é traduzida em horas-homem. A qualidade profissional dos membros da equipe e suas experiências são diretamente proporcionais ao custo do desenvolvimento.
Em suma, sabendo que a estimativa, o planejamento e a execução de um projeto são realizados por pessoas, podemos deduzir que a qualidade e a experiência dos profissionais afetam o custo de um projeto.
O bom, o rápido, e o barato
Cientes de que o software é uma entidade intangível cujo preço é difícil de definir, especialmente se não houver uma estimativa clara, vamos continuar a explicar os atributos do bom, rápido e barato e como é possível combiná-los mas não ter os três simultaneamente.
Bom e rápido
É possível fazer algo de bom com rapidez. Para conseguir isto, é essencial fazer uma boa estimativa e depois ter um bom plano de execução do projecto para que a velocidade não afecte a qualidade do resultado.
A chave para conseguir qualidade e velocidade está nas pessoas que trabalham no projecto, que devem estar suficientemente qualificadas para enfrentar o projecto. Lembre-se que a qualidade dos profissionais é um factor determinante no custo.
Tenham em conta que a velocidade pode ser contraproducente para a produtividade: Em teoria, uma equipe (e seus membros) atinge seu pico de produção em um determinado tempo e a mantém até o final do projeto. Quanto maior a velocidade, menor o tempo em que a equipe estará no pico de produtividade.
Likewise, a coordenação também será um fator a ser analisado: Quanto mais pessoas trabalharem em paralelo, maior coordenação será necessária (talvez mais pessoas devam ser adicionadas como coordenadores).
O bom e rápido se aplica especialmente para projetos críticos ou chave, onde a qualidade do produto deve ser garantida a todo custo. Nestes casos, é necessário ter equipes com muita experiência. Se este for o caso, a solução será boa e rápida, mas também cara.
Rápida e barata
Aqui está a segunda das nossas combinações das três variáveis: A maneira mais simples de fazer algo rápido e barato é fazê-lo sem qualidade ou, pelo menos, estar ciente de que pode ser inferior à desejada. Podemos sacrificar a qualidade até certo ponto, desde que o software não lide com informações críticas, ou não dependa de alguma parte sensível da organização.
Para efeitos de velocidade -como no futuro a qualidade da aplicação pode ser melhorada-, é possível entrar em produção com as características chave para o produto funcionar. Nestes casos, isto é o que pode ser feito:
- Minimizar a qualidade do código
- Simplificar sua usabilidade
- Deixe as revisões de código de lado
- Reduzir controles de qualidade e testes.
Ao fazer isto, muito provavelmente obteremos uma ferramenta com uma funcionalidade básica, mas não obteremos um produto 100% satisfatório. Sua usabilidade pode não ser a melhor, assim como a qualidade do código, e sua extensibilidade (possibilidade de mudança ou extensão) e reusabilidade podem ser problemáticas.
Isto aplica-se a aplicações demo, testes de conceito, software não crítico, ou qualquer aplicação que seja escalável ou extensível ao longo do tempo.
Bom e barato
Eu dou-lhe a última das nossas equações: Se o cliente quer uma solução boa e barata, não pode esperar uma entrega rápida.
Algo bom e a um custo aceitável pode ser feito, mas em detrimento do tempo. Basicamente, se houver tempo, é mais fácil de planear – visto que não há tantas tarefas em paralelo e não é necessária tanta coordenação – e o pico de produtividade das pessoas envolvidas vai estar no seu auge por mais tempo.
Conseguir algo bom e barato é adequado para projectos onde o tempo não é uma variável crítica, bem como para projectos incrementais ou com equipas com tempos parciais (que tenham projectos ou iniciativas internas).
Não perca isto: Qualidade ou preço do software: Qual realmente importa?
Para resumir
No desenvolvimento de software, o postulado de desenvolvimento de software bom, rápido e barato é muito difícil de alcançar. Sempre seremos capazes de conseguir dois deles, mas teremos que abandonar o restante. Desta forma, é possível conseguir qualidade em tempos estipulados e a um custo razoável; basta saber como encontrar o equilíbrio entre estas três variáveis, conhecendo as implicações e como elas se inter-relacionam entre si para alcançar esse equilíbrio.
Atingir esse equilíbrio será possível desde que as estimativas, a coordenação, a seleção da equipe, a metodologia de trabalho e o uso de ferramentas e tecnologias sejam as corretas.
Você conseguiu um equilíbrio entre essas variáveis em qualquer projeto? Como você conseguiu?
