Imagine-se como um vendedor de uma loja de roupas fechando uma venda para um cliente. Ele decidiu levar uma camisa e uma bermuda. De repente, quando está na boca do caixa, muda de idéia e decide comprar também um boné. Você, como vendedor que ganha por comissão, ficaria
feliz ou triste?
A resposta parece bastante óbvia. Todavia, quando transportamos esse exemplo para o mundo do desenvolvimento web nem todos os “vendedores” ficam felizes quando o cliente pede algo a mais. Geralmente, os desenvolvedores web até reclamam do cliente. “Poxa, mas isso não estava combinado”, “o projeto não foi pensado para agregar isso”, “não dá para acrescentar mais nada a essa altura do campeonato”.
O que podemos constatar nesse caso são dois erros básicos que muitos cometem: o da relação contratual referente ao escopo e o da projeção do site.
Ao elaborar uma proposta comercial e um contrato para desenvolvimento de sites ou aplicações web para clientes, o desenvolvedor precisa deixar claro – por escrito – que o orçamento e o prazo informados referem-se ao escopo descrito.
Nessas horas, é bom mesmo ser redundante e depois dessa explicação acrescentar ainda que quaisquer alterações no escopo solicitadas após a assinatura do contrato acarretarão em uma revisão tanto do prazo quanto do orçamento.
Com essas poucas linhas você vai conseguir que o cliente sempre pense duas vezes antes de sair mudando o escopo do projeto a torto e a direito. Além disso, se realmente ele solicitar tal alteração, você deve ficar feliz, afinal está aumentando o valor do projeto que está vendendo.
Para essa felicidade se concretizar, entretanto, é necessário que o projeto preveja possíveis expansões.
Em Arquitetura de Informação, existe um termo designado para definir possíveis expansões em projetos web: phantom labels. Trata-se de áreas previstas de um site, porém que ainda não existem na versão inicial.
Futurologia é um tema complicado, mas o ideal é o desenvolvedor ter uma boa conversa com o cliente para tentar sondar o que ele pode querer incluir no projeto após o lançamento, ou mesmo durante o desenvolvimento do mesmo. Para isso, é bom fazer um levantamento completo das necessidades do cliente, do mercado em que ele atua, da concorrência, do público-alvo e principalmente dos objetivos do projeto.
Claro que as expansões de um site ou aplicação são decorrentes do uso que os visitantes fazem do mesmo. Quando não há um mínimo de planejamento para possíveis expansões, contudo, o projeto pode acabar ficando com aquela cara de puxadinhos por todos os lados, já que a arquitetura de informação, o design e o sistema não foram projetados para agregar tais alterações.
Projetando um site maleável para futuras expansões e deixando claro ao cliente que alterações no escopo deverão ser pagas e ter novos prazos mensurados, você não terá mais arrepios quando o cliente ligar dizendo que teve aquela idéia genial. [Webinsider]
Walmar Andrade
Walmar Andrade (walmarandrade @wenetus.com) é jornalista com MBA em Planejamento, Gestão e Marketing Digital, diretor-executivo da Wenetus Interactive e autor do blog FatorW.com.
14 respostas
gostei do texto, porem acho a ideia ja esta em pratica a bastente tempo
concordo com o Pierre Sandora
ja vi contratos para o caso citado, onde recisao de contrato nao havia ressarcimento do que ja foi pagado.
e acho que isso é o mais justo, pois cobre os gastos ate o momento que o cliente deu piti
Também já testei os dois caminhos:
– fazer alteração sem cobrar a mais;
– e dizer não à alteração.
O problema de fazer alteração sem cobrar a mais é muito simples: o cliente, como todo brasileiro, também quer o braço quando você dá a mão. Ou seja, você aceita inserir uma nova área no site, já que o cliente foi gentil, educado, prestativo etc., mas o problema é que podem aparecer mais idéias da parte dele, e como não foi cobrado na primeira vez, ele se acha no direito de não ser cobrado de novo. Claro que isso depende muito do cliente, estou me baseando nas minhas experiências.
O caminho certo é fazer um contrato que ambas as partes assinem, com todo o serviço discriminado, como foi dito na matéria.
Abraços.
Wladimir, o cliente interno pode ser o mais difícil de lidar se as pessoas que estão na chefia não são familiarizados com desenvolvimento web (ou de software). Acho que o gerente de projetos deve deixar claro à diretoria que o prazo que está sendo passado inicialmente refere-se ao escopo discutido e aprovado e que se houve alteração neste escopo o prazo precisará ser revisto.
Prezado Walmar,
parabéns pelo artigo. As questões relativas a requisitos e prazos são importantes na gestão de projetos, especialmente projetos de software.
Entretanto, as modificações nos requisitos têm impacto maior quando o desenvolvimento é interno (não-contratado). Neste caso, qual a sua sugestão para o gerente de projetos e para o stakeholder?
Acredito que não são em todos os casos que isso funciona, já aplico esse método em meus projetos, mas existem casos que o cliente simplesmente não aceita o novo prazo, assim, vc tenta cumprir o prazo estipulado pelo cliente, e quando vc atraza, perda a razão para cobrar por mais alterações que o cliente pede em sequida.
Essa é uma ciência muito complicada e imprevisível
Realmente isso é uma situação que ocorre com frequência em muitas agências, e também com profissionais freelancer. Eu acho que só aprendemos a lidar com essas coisas quando vivemos na pele. Não adianta dizer que vai fazer isso e aquilo, e que essas pertubações não vão mais acontecer.
Nossa esse texto caiu como uma luva, acabei de viver exatamente isso com um cliente.
É impressionante o que eles conseguem pedir e alterar nos site e é justamente o que o texto diz q estamos fazendo aqui na empresa, atingir o bolso deles, pois pelo menos assim conseguimos aumentar o valor do projeto.
Parabéns ótimo texto.
Estas claúsulas de contrato resolvem o primeiro problema, porém existe um segundo muito comum, consequencia do primeiro.
(depois de várias horas de discussão)
Cliente: Ok, eu entendi que vou ter que pagar a mais para mudar o que eu quero e que vocês não previram. A questão é, quanto tempo mais e qual valor vocês vão cobrar?
Empresa: Vai demorar X horas e R$Y.
1° Caso
Cliente: Não, nós não temos tanto tempo, se vira com X/3.
2° Caso
Cliente: Não, foge completamente do orçamento inicial, isso eu não vou pagar.
Pior caso:
1° + 2°
Nesses casos o cliente já deve ter pago parte do projeto, ou/e o fornecedor já investiu esforço, ou seja, um Então tá procure outro fornecedor então. nessa altura não é uma opção. Ou então, quem sabe do problema de fazer em X/3 o que deveria ser em X, não é a mesma pessoa que tem autonomia de negociar com o cliente.
Nada é tão fácil assim nesse mercado louco.
o texto é perfeito. só não concordo com o título dele.. afinal, não é o caso de tirar proveito (uma expressão que até me parece anti ética) sim fazer um contrato onde nenhuma das partes saia prejudicada com mudanças no escopo.
cláusulas claras e respeito mútuo com o projeto, todos saem ganhando.
Excelente matéria! Já adicionei tais linhas ao meu modelo de contrato! Nos próximos contratos já estarei mais tranquilo! 😀
Abraços!
Belo texto!
Estou começando agora a fazer freelance e gostaria de saber se freela precisa fazer contrato também. Se sim, onde eu posso arrumar um modelo de contrato de freela em webdesign?
Já testei os dois caminhos:
– fazer alteração sem cobrar a mais;
– e dizer não à alteração.
Nenhum deles foi legal nem pra mim, nem pro cliente. Concordo 100% com o texto e com o comentário do Alex Piaz.
Parabéns Walmar, foi a melhor matéria, referente há projetos, que eu ja li.
obrigado pela matéria e continue assim.
Este texto deveria ser colocado como plano de fundo em todos os desktops de gerentes de projeto e atendimentos. Ao não respeitar o escopo, sem a devida contrapartida em pagamento, além de gerar normalmente mais trabalho, desagrega valor ao servico prestado, aumenta responsabilidades (> funcionalidade >> probalidade de bugs = > manutencao), e não faz o filme com o cliente. Você não perderá clientes ao forcar o estrito cumprimento do escopo, pelo contrário.