Usando Access

Um contrato simples para desenvolvimento de software

Nota importante: para ter acesso aos vídeos e arquivos exemplos deste site, adquira um dos planos apresentados abaixo. Você pode comprar em até 5x no Cartão de Crédito, através do Paypal. 

Veja como comprar e saiba mais sobre o material oferecido,  clicando aqui.

De Gilberto Mendes

Como não existe um mundo ideal, no qual os clientes e desenvolvedores se comunicam com clareza, onde os prazos são cumpridos e os sistemas não apresentam bugs, então é necessário um meio adequado para mediar estas relações. Embora geralmente uma proposta assinada por ambas as partes possa auxiliar bastante para esclarecer as regras do jogo, um contrato é a forma mais adequada. Pense nisso como uma espécie de VBA para os homens da lei.

Antes de entrar no mérito do contrato, assista este pequeno vídeo de 4 minutos, de Alan Siegel, um conceituado profissional de comunicação:

Se você quiser assistir a este vídeo com legendas, clique aqui.

Tanto para sistemas quanto para contratos, a simplicidade é um diferencial.   É uma forma de obter clareza (isto é, dizer exatamente o que você quer dizer), transparência (não ocultar nada, nem criar armadilhas) e empatia (que as duas partes possam compreender as necessidades e preocupações do outro).

Baseado nestes princípios, resolvemos criar um contrato simplificado aqui na AccessPro.   Do contrato mais genérico de 7 páginas, chegamos a um modelo de 2 páginas, que apresento e comento abaixo. Se aplica a 80% dos projetos de desenvolvimento.

Página 1 - Quem é quem, o que vai ser feito.

Nesta primeira página, colocamos quem é o cliente e quem é o fornecedor. Optamos por esta nomenclatura por acreditar ser a mais clara do que contratante e contratada.

Descrevemos em seguida o preço e o prazo. Ao lado, as condições de pagamento.

Por fim, descrevemos o que será feito. Se você acha que o seu projeto pode ter problemas de entendimento do que será feito, descreva ao invés das características do sistema, os requisitos.  Ou seja, coloque no contrato (e explique cuidadosamente ao cliente) que o sistema será considerado concluído se cumprir todos os elementos do contrato.

Um dos grandes perigos é o tal do "é óbvio" ou o "está implícito".   É melhor detalhar em excesso do que deixar coisas em aberto. Aqui, na empresa, nós buscamos o mais simples, anotamos as necessidades de forma um pouco mais detalhada na elaboração do projeto e negociamos com o cliente, caso haja alguma divergência.   Às vezes temos de trabalhar um pouco mais do que o estimado, mas olhamos isto como um investimento na relação. Temos a sorte (ou um bom critério de seleção) de ter uma grande maioria de clientes que tem esta visão mais madura da contratação de serviços.

Uma conhecida consultoria da área de desenvolvimento, para apresentar um contraponto, tem como regra não enviar propostas se não houver um requisito elaborado, enviando em determinado momento uma proposta especifica para fazer esta análise.

Página 2 - As regras do jogo.

Aqui definimos como funciona a relação. Os tópicos principais:

E se mesmo assim tivermos problemas?

Contrato, como seguro, é o tipo de coisa que temos para não usar.   O melhor caminho é o diálogo e a prevenção (por exemplo: apresentar prévias do sistema para o cliente e manter uma relação de clareza e transparência).

Mas pode acontecer da relação com o cliente se deteriorar.  Neste caso, tente ter uma conversa com o cliente em termos como "Estamos numa situação em que os dois estão perdendo. Como saímos dessa?".  Todo projeto ou serviço tem um componente de risco para ambas as partes.   Às vezes pode caber um valor adicional para conclusão, uma devolução de parte do valor, aceitar um prejuízo e refazer parte do projeto, ou indicar uma outra pessoa para assumir o trabalho.

As piores escolhas são abandonar o projeto ou ir para uma disputa na justiça.   A primeira acaba com a sua reputação profissional, a segunda é cansativa e demorada.

Outras considerações

Tenha em cada projeto uma reserva real de tempo para testes e ajustes.  É no começo que você deve estabelecer uma relação profissional e durante o projeto deve cultivá-la, sem ser "bonzinho", aceitando mudanças para depois sentir-se "traído" porque o projeto não termina nunca.

Seja criterioso na hora de escolher os seus clientes.  Afine seu "desconfiômetro" para detectar com antecedência, clientes espertalhões: os que pedem pra fazer controle de caixa dois, os que tratam mal seus funcionários ou aqueles em que o dono não aparece como representante legal da empresa.

Se o cliente contar a história de que um outro programador o deixou na mão, há chances de que o problema seja do outro programador, assim como de que o problema seja dele.   Faça um esforço para não "herdar" a parte ruim da relação anterior.

Não se iluda com o papo de que "se você fizer um preço baixo, depois deste projeto lhe indico um monte de clientes" ou "este sistema tem um enorme potencial".   Se atenha ao concreto e saiba que para um sistema se tornar um produto, o esforço de transformação é duas ou três vezes maior que o de elaborar o sistema.

Espero que este artigo e este exemplo, um meio termo entre um contrato mais complexo e uma proposta comercial possa ajudar a você a estabelecer relações sadias com os seus clientes, pautadas pela simplicidade. Assim como existem várias maneiras de desenvolver sistemas, existem diversas abordagens para os contratos.

Baixe aqui o modelo de contrato

Boa sorte!

| Home | Vídeos-aulas | Tutoriais | Dicas | Blog | Downloads | Contato | Artigo |