Modelos de desenvolvimento de software e mercado

April 20, 2007

Há pouco eu estava conversando com um amigo desenvolvedor de software. Ele dizia que tinha sido procurado para desenvolver um projeto simples. Eis a especificação passada por ele:
um sisteminha de gerenciamento: - 7 módulos/páginas - cada uma com um CRUD básico… - Listagem de coisas cadastradas - Inserção de novos elementos - Busca por elementos, usando vários critérios de busca - um sistema de gerenciamento de usuários com 3 perfis diferentes - interface simles (uso interno), com AJAX
Dada esta breve descrição, ele me pergunta quanto eu cobraria. Depois de pensar um pouco, dei minha estimativa (não vou citar valores, mas é um valor módico – o sistem parece ser bem simples…). Qual não foi minha surpresa, quando ele diz que tinha feito um levantamento com outras pessoas, e estas chegavam a cobrar 10 vezes o valor que eu havia sugerido.

Daí quis saber o porque de se cobrar tanto por algo tão simples, e ele me disse que era porque poderiam surgir picuinhas, que interface de usuário é algo cheio de detalhes, que especificações podem mudar …

Refletindo um pouco sobre estes motivos, percebi que todas as afirmações eram verdadeiras. No entanto, usar estas razões para precificar o desenvolvimento de um software não parece razoável. De acordo com minha experiência, todo software tem picuinhas, toda interface vai ter inúmero detalhes, as especificações sempre mudam. O que fazer então? Tentar esmiuçar cada detalhe do software, validar cada interface do sistema, exercitar todas as possibilidades de uso do sistema? Com isto, você com certeza vai inchar o seu produto de tal forma que a quantidade de recursos demandados realmente justificaria um preço elevado. E isto também resultaria em um prazo maior para a entrega do produto.

Qualquer um consegue ver que isto não é nada positivo: qual o cliente que quer contratar o desenvolvimento de um software que será caro, e irá demorar para ser entregue? Com certeza nenhum …

Qual é portanto a melhor alternativa? Simplifique, seja ágil (gosto cada vez mais dessa palavra). Surpreenda seu cliente desenvolvendo uma solução que atenda suas necessidades de forma satisfatória rapidamente. Isso irá resultar em um produto de menor custo entregue num curto espaço de tempo. Quando o cliente for usar seu produto terá grande parte de suas necessidades atendidas, mas com certeza encontrará um caso específico que não está contemplado, não irá gostar de alguma coisa da interface … nestes casos ele pode contratá-lo novamente para resolver estes problemas, que certamente serão resolvidos de forma muito rápida, uma vez que ele saberá dizer exatamente o que há de errado com o produto que você desenvolveu.

Da forma que vejo, no final das contas, em ambos os modelos você chegará a um mesmo produto, com a mesma qualidade e as mesmas funcionalidades. No entanto, na forma ágil, este resultado será obtido muito mais rapidamente, e com um custo bem menor. Bom para o cliente, e bom para os desenvolvedores.

Powered by ScribeFire.

posted in Desenvolvimento by Alexandre Barbosa

Follow comments via the RSS Feed | Leave a comment | Trackback URL

  • http://log4dev.wordpress.com/ Miguel Galves

    Concordo que hoje em dia, iterações muito longas, descrições muito extensas e detalhadas são umprato cheio para atrasos e orçamentos mal feitos. Por outro lado, o grande perigo desta tua estratégia é tentar captar um cliente a qualquer custo, baixando orçamentos na esperança de que novos contratos ou adendos serão feitos no futuro. Isto pode não acontecer, os prazos podem aumentar devido N fatores e o desenvolvedor pode ficar com o prejuizo.

  • Alexandre Barbosa

    Quando penso em baixar orçamento, vejo duas alternativas: 1. Fazer mais com menos: tentar sugar seus recursos (programadores, tempo) ao máximo, para entregar algo que não seria possível com a quantidade de recursos disponível. 2. Fazer menos com o que se tem: reduzir a complexidade do que vai ser feito, para poder entregar o que pode ser feito com os recursos disponíveis.

    Se você utlizar a primeira alternativa, você vai conseguir um ou dois trabalhos, e nunca mais será contratado por ninguém, a não ser pra fazer software de controle de fluxo de caixa de buteco. Minha sugestão se baseia na segunda alternativa. É importante manter um nível de qualidade adequado, e atender o cliente. Não necessariamente, ao reduzir a complexidade do projeto, você está focando em novos contratos ou adendos no futuro. É possível que a solução com complexidade menor seja suficiente para o cliente, e não seja mais necessário mexer no produto entregue. Para outros clientes, talvez seja necessário outra iterações.

    A questão é deixar isto claro para o cliente, e mostrar as vantagens deste modelo. Para tanto, é preciso estabelecer uma relação de confiança com o cliente, o que pode ser extremamente difícil. Como você sabe, minha experiência com este modelo é com desenvolvimento para clientes internos, onde esta relação de confiança é mais fácil de ser adquirida. Acredito realmente que este modelo pode ter sucesso para uma empresa de software, mas certamente será necessário confrontar o modelo vigente, o que pode não ser fácil.

  • http://rec6.via6.com/ Miguel via Rec6

    Modelos de desenvolvimento de software e mercado

    “Alexandre Barbosa discute metodologias de desenvolvimento e o impacto destas na questão de precificação, estimativa de prazos e escopo.”

blog comments powered by Disqus

Switch to our mobile site

 
Powered by Wordpress and MySQL. Theme by Shlomi Noach, openark.org