segunda-feira, 18 de agosto de 2008

Nirvana em orçamento de projetos

Stock Photos Eu particularmente não gosto de usar (nem ler) as palavras sem esclarecer seu real significado. Portanto, significado de Nirvana no Wikipédia.

Com anos fazendo orçamento para projetos de desenvolvimento, aprendi que muito mais do que as questões técnicas e científicas (matemáticamente) desta tarefa, bem como teorias para se alcançar o melhor resultado possível para ambas as partes, acaba prevalecendo, pelo menos sempre foi assim com a maioria dos clientes que eu já tive até hoje, o fator: "o quanto o cliente quer pagar". Raramente podemos chamar esse fator de: "quanto o cliente pode pagar", embora isso seja contraditório em relação às alegações que ele faz.

Bom, mas isso não importa. Se o seu pensamento for o de arrancar o máximo que ele pode pagar, além disso ser um desvio de comportamento e uma indicação clara de amadorismo (na minha opinião e por mais capitalista que eu seja/tenha que ser), o que vou escrever aqui não lhe serve de nada, pois você só objetiva o seu resultado e não o do seu cliente.

Princípio: Bom resultado como objetivo sempre!

Já tive muitas vezes a sensação não ter cobrado um preço justo. Porém jamais saí com a sensação de não ter atendido as expectativas do cliente. Essa sensação sim seria extremamente frustrante para mim. Portanto, o que tenho praticado e quero relatar aqui, tem como princípio básico a satisfação de resultados. Parece óbvio, mas tentando sempre aplicar algo para atingir esse objetivo, até hoje eu ainda não tinha feito nada que atendesse em todos os sentidos: facilidade, praticidade, conveniência, transparência, objetividade e rapidez quanto ao processo de se desenvolver um orçamento e negociá-lo.

A matéria-prima da fórmula.

budget01Na grande maioria das vezes o seu cliente solicita um orçamento, mas por mais que ele não tenha a menor condição e critérios para tal avaliação (se ele as tivesse ele mesmo faria o projeto), ele já sabe o quanto ele quer (ou pode) investir.

Por outro lado, você como profissional absolutamente bem informado e capacitado quanto as possibilidades de resolver a questão para a qual o seu cliente necessita de solução, tende a oferecer justamente o que há de melhor e com base na sua visão de solução, definir o custo do projeto.

Na grande maioria das vezes, e falo por experiência própria, devido aos custos, após apresentar a sua proposta de solução, junto com o orçamento, o cliente vai solicitar a revisão, não por uma crítica, mas sim por ajustes orçamentários.

O que acaba sendo aprovado é justamente a solução reformulada que o orçamento atende. Ou em outras palavras, o melhor que você pode fazer, pelo melhor que o cliente pode pagar.

A fórmula: inverter a matéria-prima.

Isso mesmo! Simplesmente hoje eu pergunto ao cliente qual o orçamento que ele disponibiliza para aquele projeto e desenvolvo a proposta com a melhor mão-de-obra, técnica e tecnologia que aquele orçamento pode cobrir.

O impressionante desta forma de tratar o orçamento de um projeto, é que se você procura selecionar bem as tecnologias com as quais vai trabalhar, busca o melhor domínio possível sobre as mesmas, bem como as melhores e mais atualizadas técnicas de desenvolvimento com estas tecnologias, você apresentará ao seu cliente algo que atende e até mesmo supera as expectativas dele. E para isso, você não precisa se tornar minimalista. Pode manter a análise sobre o que você consideraria ideal (aquela primeira proposta que normalmente seria rejeitada), mas apresenta ao cliente um projeto escalonável, onde o resultado do primeiro investimento/fase do mesmo oferece o resultado que ele necessita no prazo requisitado. Ao mesmo tempo, ele terá em mãos suas sugestões de implementação que podem servir de base para investimentos futuros no mesmo projeto sob o qual você já tem domínio. Há aí uma grande possibilidade de demanda para você, sem contar que com isso você já apresentou comprometimento com os resultados esperados pelo seu cliente.

Requisitos

Claro, é importante ressaltar que, se você ainda não pensou: "Vicente, isso não é uma descoberta!", deve então tomar essa frase como uma afirmação minha. Embora eu não tenha pesquisado absolutamente nada a respeito para ter funcionado como base de raciocício e tendo usado somente minha experiência particular de 12 anos atuando com treinamento, consultoria e desenvolvimento de soluções web-based, é muito provável que exista algum estudo que analise e explique melhor esse tipo de forma de encarar o processo de orçamento e negociação de projetos.

Outro fator, talvez mais importante , que cabe a mim deixar claro, é que existem alguns princípios que tornaram para mim possível aplicar essa forma de tratar o assunto junto ao cliente:

  • Os clientes com os quais tenho aplicado essa forma de negociar o orçamento de um projeto, são clientes que já tiveram a oportunidade de avaliar o meu trabalho de alguma forma anteriormente.
  • O processo de análise (levantamento de requisitos, casos de uso e outros diagramas e documentações) é exatamente o mesmo. Extingue-se apenas o processo de reavaliar o projeto posteriormente. Portanto não encare o que estou colocando aqui como forma de otimizar o seu trabalho de formalização de um orçamento técnico.
  • Deve-se tomar o cuidado de não penalizar o cliente para favorecer a si mesmo. Ou seja, para tornar um projeto escalonável, acaba-se consumindo um esforço e consequentemente tempo, ligeiramente maior do que se considerar aquela etapa como única. Quero dizer, em favorecimento a sua previsão de melhorias futuras ao sistema, pode-se consumir um tempo/esforço de desenvolvimento a mais, para permitir certas implementações futuras, que acabará refletindo num custo para o cliente, na etapa para a qual ele está investindo em uma solução que o atenda já. Deixe isso claro na apresentação da sua proposta de projeto. Ele pode preferir, ao custo de tornar futuras implementações mais caras, melhorar o resultado da primeira etapa. Seja com custos relacionados a treinamento, implantação/homologação, etc. que poderíam ser extendidos, melhorados em recursos, caso eliminado algumas tarefas inerentes a recursos futuros imaginados para o produto em questão.