Nesse artigo desenvolvo apenas uma parte da estratégia para fazer o cliente e o desenvolvedor a chegarem a um acordo justo. Esse artigo é bom para ambos os lados.

Escrever contratos de desenvolvimento de software ou prestação de serviço é difícil, tedioso e sempre desagradável.Mas quando o seu prestador de serviço, principalmente o desenvolvedor de software, lhe diz que não irá finalizar um serviço inacabado, você verá que a melhor solução era ter criado um documento escrito onde todas as fases do projeto fossem descritas, com suas datas de entrega devidamente informadas bem como todas as cláusulas de rescisão, justas para ambas as partes.

Veja um contrato de desenvolvimento ou prestação de serviço como um guia para o relacionamento entre as empresas. Se devidamente escrito, este irá evitar disputas judiciais. Se alguns problemas surgirem, este irá prover meios para resolvê-los. Se as partes envolvidas terminarem na justiça, este estabelecerá obrigações legais para cada uma das partes.

Um contrato é bom para a empresa cliente e para a prestadora de serviço e você não precisará ser um advogado para escrever um contrato de desenvolvimento de software ou prestação de serviço em Informática. Tudo o que você precisa é de apenas um pouco de bom senso.

Nem todas as possíveis nuances para os contratos poderão ser cobertas nesse artigo, mas este irá prover uma visão geral dos pontos mais importantes que devem ser inclusos em quaisquer acordos de desenvolvimento de software.

Antes de tudo - Veja o Custo/Benefício em desenvolver um software em sua empresa -

Para todos os problemas de negócio existentes, certamente existirá algum software que irá resolvê-los. Ao desenvolver um software para sua empresa, lembre-se que outras empresas já passaram por isso e que eventualmente alguém já desenvolveu o programa necessário para atender àquelas necessidades.

Exemplos de software que não precisam ser desenvolvidos “in-house”, são: Sistema de Folha de Pagamento, de Contabilidade (mesmo usando integração com o método FASB Americano), de Ativo Fixo, Business Inteligence (já existem centenas de software no mercado), de Controle de Empresas de Segurança e ERP (Enterprise Resource Planning).

Mesmo existindo algum software, lembre-se do custo de implantação e a adequação às necessidade de sua empresa. Já vimos casos onde a adequação ficou mais cara do que o desenvolvimento feito do zero.

Dependendo do tamanho de sua empresa, aplicativos criados com o Microsoft Access, Microsoft Word ou Excel, ou o Office em geral, resolvem muitos problemas sem nenhum custo adicional para sua empresa.

Use consultorias que poderão lhe indicar o que os clientes delas já usam e com qual resultado. E caso nenhum sofware tenha sido criado para isso, parta para um levantamento junto à empresas desenvolvedoras de software, que certamente poderão reutilizar uma mão de obra já patrocinadas por outras empresas e reutilizar eventualmente rotinas já pré-escritas (como inclusão de clientes, relatórios de vendas etc..).

Em último caso, utilize um programador free-lancer.

Ponha as fases do trabalho no Contrato -

O pior pesadelo de um cliente é pagar um desenvolvedor para criar um software e somente saber que o produto é insatisfatório após a entrega ter sido feita meses depois. A melhor saída para evitar este cenário é quebrar o projeto em partes ou estágios, que poderemos chamar de fases.

Ao final de cada fase, o desenvolvedor deverá entregar um produto aceitável, mesmo que sejam apenas especificações escritas ou resultado dos testes dos dados recebidos dos clientes. E caso isto seja satisfatório para o Cliente, o desenvolvedor então receberá um montante específico.

Isto facilitará a ambas as partes monitorarem o progresso do desenvolvedor e resolver problemas nas fases iniciais do projeto – ou mesmo abortar o projeto quando este se mostrar impossível de ser finalizado.

Este tipo de desenvolvimento baseado em fases também traz vantagens para o desenvolvedor.

Fazer o cliente aprovar cada fase do projeto é a melhor maneira de evitar reclamações de não conformidade ou performance insatisfatória, quando o projeto for finalizado.

Esta abordagem também dá a oportunidade de negociar as mudanças solicitadas pelos clientes. Poucos projetos de software seguem completamente suas especificações originais.

O projeto normalmente cresce na medida que o trabalho é feito, e o desenvolvedor e o cliente acabam tendo idéias que tornam o projeto melhor, porém mais complexo. O desenvolvimento em fase é um meio conveniente para discutir as mudanças e quanto isto custará para o cliente. Entretanto o desenvolvedor deverá assegurar que a programação de entrega é razoável e prover algum tipo de flexibilidade para melhor atender às novas solicitações necessárias.

A Falta de Documentação leva ao desastre (Especificação do Sofware)-

As especificações do Software é o equivalente à planta de um edifício. Elas definirão o software a ser criado e proverá um guia para determinar as condições e o tempo que o software estará satisfatoriamente completado. Quanto mais completo forem as especificações, menos desentendimentos existirão entre o desenvolvedor e o cliente.

Isto diminuirá a insatisfação futura do cliente, a retenção dos respectivos pagamentos e uma possível ida à juízo.As especificações são realmente o coração de qualquer contrato de desenvolvimento de software.

Existem vários meios de escrever especificações. Uma forma é primeiro rascunhar uma “especificação funcional” em uma linguagem não técnica que seja facilmente entendida pelo cliente final.

O desenvolvedor pode também preparar um protótipo ou programa de demonstração para mostrar ao cliente o design da telas e a funcionalidade do programa.

Pagando ao Desenvolvedor

Existem duas maneiras básicas de pagar um desenvolvimento de um software sob medida: Acordo de Pagamento por hora (tempo e material) ou um Acordo por preço fixo.

Sob acordos de tempo e materiais, o desenvolvedor é pago pelo tempo gasto e custos atuais incorridos na criação do software. Este esquema de pagamento obviamente é mais favorável ao desenvolvedor do que ao cliente. Diferentemente do contrato a custo fixo, o desenvolvedor é assegurado do pagamento até se o projeto levar mais temo do que o tempo originalmente calculado.

Sob o acordo de preço fixo, ao desenvolvedor é pago uma quantia fixa para todo o projeto. Em teoria, este esquema de pagamento favorece ao cliente, dando-lhe uma dada certeza do que o projeto irá custar. Mais ainda, se o pagamento é ligado ao trabalho do desenvolvedor, isto dará substancial incentivo ao cliente em forçar que a compleição do projeto esteja dentro do tempo e da qualidade pré-acordada.

Entretanto, na prática, acordos de valores fixos acabam não favorecendo aos clientes como inicialmente muitos poderiam pensar. Se o valor fixo inicialmente acordado não prover ao desenvolvedor um valor justo de compensação, devido ao próprio fato do projeto se extender demasiado (até por conta de mudanças de especificações por exemplo), o cliente acabará concordando em pagar mais ao desenvolvedor.

Caso contrário, o desenvolvedor irá desistir da entrega do produto ou o finalizará, entregando um produto bem abaixo da qualidade, apesar de aderente às especificações (algumas rotinas funcionarão bem por alguns meses e quando o banco de dados aumentar, a performance irá cair.)

A Quem pretence o Software?

No momento que o código do computador foi escrito, este é protegido pela lei dos direitos autorais (direitos intelectuais – copyright). Neste mesmo momento, alguém torna-se o proprietário intelectual. Similarmente, patentes e direitos de propriedade começam a vigorar.

Muitos clientes de desenvolvedores de software tem a impressão errada de que, uma vez que tenham pago pelo desenvolvimento do software, o software automaticamente lhes pertencerá. Entretanto, isto não é o caso. Sem um acordo, transferindo a propriedade do desenvolvedor para o cliente, o desenvolvedor será o proprietário do software – a não ser que o desenvolvedor seja considerado empregado do cliente ou, talvez, este software seja parte de um trabalho maior dentro de um acordo escrito de transferência de propriedade.

Uma das mais importantes funções de um acordo de desenvolvimento de software é estabelecer quem irá ter a propriedade efetiva dos direitos sobre o software criado. E isto é sempre uma das questões mais veementemente discutida entre o desenvolvedor e o cliente, e que podem facilmente gerar o eventual cancelamento de um acordo, já em seu nascedouro.

Existem muitas opções de propriedade disponíveis, variando da propriedade total do cliente até a propriedade do desenvolvedor, onde o cliente meramente tem uma licença de uso do software (EULA – End User Licence Agreement). E também existem muitas alternativas entre esses dois extremos. Dependendo do valor pago ao desenvolvedor, qualquer uma dessas opções pode ser satisfatória.

O background tecnológico do Desenvolvedor

Um desenvolvedor de software normalmente tem várias ferramentas de desenvolvimento, rotinas, subrotinas e outros programas, dados e materiais que ele traz para dentro do projeto e que certamente auxiliará na finalização do produto final – por exemplo, o código usado para manipulação das janelas, visualização de menus, armazenamento de dados e impressão. Um termo usado para todos esses itens é conhecido como “background tecnológico”.

Se o desenvolvedor transferir a propriedade do software ao cliente final, o cliente acabará também se apropriando deste “background tecnológico”. O desenvolvedor é normalmente evita isto, ao informar no contrato de desenvolvimento que ele ainda continua retendo os direitos sobre o material. Entretanto, neste caso, o acordo deverá dar uma licença não exclusiva de uso ao Cliente final, sobre as rotinas inclusas no software entregue.

O que mais estará envolvido na criação de um software

Um software pode ser escrito usando inúmeras ferramentas de desenvolvimento, porém o cliente deverá ter a completa noção do ônus em ter o sofware em seus computadores.

Por exemplo, caso o desenvolvedor opte em trabalhar com Visual-Basic + SQL Server ou Delphi + SQL Server ou Oracle, e o Cliente terá que ter as licenças do Servidor Windows e do SQL Server e/ou Oracle.

Muitas vezes esses custos não são discutidos durante o acordo de desenvolvimento do software, e o Cliente somente saberá que irá pagar mais R$8.000 (no mínimo) quando o software for entregue, e isto já é tarde demais. Existem alternativas no mercado de base de dados, como o MySQL, Firebird ou PostGress que deverão ser trazidos à baila no momento da negociação, para evitar dissabores.

Outro exemplo é o caso do desenvolvedor optar em trabalhar em uma plataforma específica, como Windows, e depois a empresa Cliente precisar trabalhar com estações Linux ou Thin Client.

Para evitar esses dissabores, opte por desenvolvimento for WEB (ASP, PHP) que permitirá que qualquer máquina acessando a Internet possa trabalhar com a nova aplicação criada.

Garantia do Produto

Todos temos familiaridade com o termo garantia. Quando um produto qualquer é comprado – de um carro até um televisor – o vendedor normalmente garante ou promete que o produto irá fazer o que é suposto que ele faça, por um período razoável de tempo, e que o vendedor irá consertá-lo ou trocá-lo caso isto não ocorra.

Os desenvolvedores de software são naturalmente hesitantes em dar garantias por algo ainda não pronto. Entretanto, nenhum cliente em seu juízo perfeito irá concordar em pagar uma larga soma por um software, sem ter uma garantia de funcionamento do produto. Garantias são sempre inclusas na maior parte dos contratos de desenvolvimento de software. Porém, devido a esta ser uma area de grande barganha entre o cliente e o desenvolvedor, elas variarão muito.

Uma das garantias mais encontradas em contratos de desenvolvimento de software, refere-se à sua performance. Isto significa que o desenvolvedor promete que o software irá funcionar da forma como o desenvolvedor prometeu e em caso contrário, o software será corrigido sem custos. Essas garantias duram de 90 dias a um ano após o software ter sido entregue. Dentre outras importantes garantias incluimos a garantia de que o software não infrige nenhum direito de propriedade ou acordo secreto de terceiros.

Teste do Software

A fase de teste é uma das mais importantes no processo de desenvolvimento. O propósito para os testes de aceitação é determiner se o software faz o que é suposto fazer e se ele é confiável. Particularmente onde alguma missão crítica está envolvida por exemplo, softwares de controle de compra/venda de ações on-line, software de controle de equipamentos hospitalares – estes devem ser testados e retestados o máximo possível.

Certamente, o desenvolvedor deverá testar o software antes de entregá-lo ao cliente, mas o cliente não deverá confiar no resultado. Antes deste aceitar ou pagar pelo software, o cliente deverá:

testa o software por si mesmo, assumindo que ele esteja pessoalmente qualificado para faze-lo;

ter um teste do desenvolvedor sob sua supervisão direta e usando o hardware do local onde o software efetivamente sera utilizado;

ter o software testado por um laboratório independente.

Documentação Final do Produto (e o processo de manutenção da documentação)

Um produto sem um processo de documentação do Sistema e do Usuário Final fica inacabado por inúmeros motivos:

Somente os usuários do momento da Implantação saberão como o Sistema funciona, e em caso de transferências ou demissões, a história da empresa termina;

Modificações no código, feitas durante a vida do software, ficam residindo somente no corpo do programa.

Modificações feitas que causarem problemas no uso do programa, não poderão ser rastreadas, tornando o Sistema não confiável.

Manutenção do Software

Um software sofre modificações em sua vida devido à mudanças nas regras de negócio. Sem um compromisso escrito entre as partes, as modificações ficaram a mercê da boa vontade do desenvolvedor.

Inclua itens específicos no contrato de desenvolvimento que permita modificações em questões de impostos, percentuais de rateio e/ou outros itens que aos serem modificados, impactarão sobremaneira seus negócios. Obviamente o desenvolvedor deverá receber por isso, porém tenha a certeza de que ele irá fazer as modificações necessárias ao seu tempo.

VEJA MAIS:
Para Melhorar o relacionamento entre Área de TI e usuários finais -

Jose Claudio Claudelino
Diretor de Tecnologia
Smart Union Consultoria e Soluções em Tecnologia