Download Word gratuito • Edite on-line • Salve e compartilhe com Drive • Exporte para PDF
Um Acordo de Desenvolvimento Geral é um contrato formal entre um cliente (Consumidor) e um desenvolvedor ou fornecedor de serviços técnicos para a elaboração de especificações funcionais e/ou desenvolvimento de um sistema de negócio baseado em computador. O documento estabelece, de forma clara e vinculativa, o escopo do trabalho, as responsabilidades de cada parte, o cronograma de execução, a estrutura de custos, os prazos de pagamento e a titularidade dos direitos de propriedade intelectual. Este modelo é totalmente editável, disponível para download em Word gratuitamente, e permite que você customize anexos críticos como cronogramas, requisitos funcionais e estrutura de pagamento conforme sua situação específica. É o alicerce legal de qualquer projeto de desenvolvimento que envolva investimento significativo de tempo ou recursos.
Sem um acordo formalmente documentado, existe risco elevado de malentendidos custosos. O desenvolvedor pode interpretar o escopo de forma minimalista e deixar funcionalidades fora; o cliente pode exigir mudanças radicais no meio do projeto sem pagar a mais; ninguém sabe quem é proprietário do código ou se documentação pode ser compartilhada. Estes conflitos resultam em processos judiciais, perda de investimento e projetos paralisados. Um Acordo de Desenvolvimento Geral bem redigido define expectativas claras, estabelece marcos de validação, estrutura pagamentos de forma justa e protege ambas as partes. Para o cliente, garante que recebe exatamente o que foi prometido, na data acordada, e que é proprietário do resultado. Para o desenvolvedor, confirma escopo e evita pedidos infinitos de revisão grátis. É um documento essencial para qualquer projeto de TI acima de alguns milhares de euros.
| Se sua situação é… | Use este modelo |
|---|---|
| Projeto de curta duração com escopo simples e orçamento reduzido | Acordo básico — projeto pequeno |
| Desenvolvimento complexo com múltiplos marcos, revisões e integração | Acordo completo — projeto empresarial |
| Quando desenvolvedor reutiliza componentes próprios no projeto | Acordo com propriedade compartilhada |
| Incluir serviços pós-lançamento, atualizações e assistência técnica | Acordo com suporte e manutenção |
| Projeto com dados sensíveis ou requisitos de segurança elevados | Acordo com confidencialidade reforçada |
| Projetos de longo prazo com entrega gradual e validação incremental | Acordo com pagamento por marcos |
Por que importa: Sem documentos de suporte, o contrato fica incompleto e ambíguo. As partes podem discordar sobre o que foi prometido.
Fix: Prepare e assine todos os sete inventários (A–G) e numere-os no corpo do contrato.
Por que importa: Cliente e desenvolvedor podem ter expectativas radicalmente diferentes sobre custo total, levando a conflito e falta de pagamento.
Fix: Especifique um valor fixo ou, se houver variação, defina a fórmula de ajuste e limite máximo de custo.
Por que importa: Desenvolvedor pode reivindicar propriedade do código, impedindo o cliente de usá-lo livremente ou modificá-lo depois.
Fix: Indique explicitamente que toda obra é propriedade do cliente, exceto ferramentas preexistentes do desenvolvedor.
Por que importa: Cliente pode não cooperar, fornecer dados tarde ou mudar requisitos constantemente, atrasando o projeto sem que desenvolvedor tenha recourse.
Fix: Defina obrigações claras do cliente (acesso à informação, disponibilidade de pessoal, revisão de documentos em prazo X).
Por que importa: Se cliente ou desenvolvedor desejar desistir, falta clareza sobre reembolsos, propriedade do trabalho parcial e direitos adquiridos.
Fix: Adicione cláusula de rescisão por conveniência e rescisão por inadimplência, com detalhes de quitação financeira.
Por que importa: Leigos podem interpretar 'especificações funcionais', 'integração' ou 'API' de forma distinta, causando disputas sobre escopo.
Fix: Use o Inventário E para listar cada termo técnico com exemplos práticos e explicação simples.
Em linguagem simples: Estabelece o significado de conceitos-chave como Especificações Funcionais, Plano de Desenvolvimento, Cronograma e Preço, baseado em dicionários da indústria.
Todos os termos de processamento de dados neste acordo terão o significado aplicado a eles pelo Dicionário Nacional [PAÍS] de Sistemas de Processamento de Informação conforme publicado em [DATA].
Erro comum: Não definirem termos ambíguos ou deixarem cláusulas sem anexos (Inventários), causando interpretações conflitantes depois.
Em linguagem simples: Obriga o desenvolvedor a usar metodologias profissionais, coletar dados, validar possibilidade de reutilização de sistemas antigos e fornecer pessoal competente.
O Desenvolvedor será responsável por estabelecer as metodologias de desenvolvimento, conduzir coleta e análise de fatos, validar incorporação de sistemas existentes e supervisionar pessoal experiente.
Erro comum: Omitir detalhes sobre revisão de qualidade, testes ou validação, deixando ambíguo quem verifica a conformidade.
Em linguagem simples: Exige que o cliente forneça acesso a registros, informações de negócio e pessoal para auxiliar o desenvolvimento sem impedimentos.
O Consumidor deverá oferecer cooperação imediata e eficiente de seu pessoal, dar acesso a registros de negócio e informações, e oferecer estrutura apropriada.
Erro comum: Não definir quem representa o cliente nas reuniões ou não especificar que atrasos na resposta afetam o cronograma.
Em linguagem simples: Obriga ambas as partes a designar representantes qualificados para encontros periódicos de alinhamento técnico e de negócio.
Ambas as partes definirão representantes qualificados que atenderão a encontros regulares para troca de informações técnicas e de negócio, coordenando atividades conforme necessário.
Erro comum: Não especificar frequência de reuniões ou não exigir relatórios escritos de progresso, deixando o projeto sem acompanhamento formal.
Em linguagem simples: Reconhece que todas as especificações, documentação, cópias e direitos autorais pertencem ao cliente, excepto informações proprietárias claramente marcadas do desenvolvedor.
O Desenvolvedor reconhece que todos os direitos, titularidade e interesse nas Especificações Funcionais e direitos de propriedade intelectual são e permanecerão como propriedade do Consumidor.
Erro comum: Não esclarecer o que é propriedade do cliente versus o que o desenvolvedor pode reutilizar em outros projetos.
Em linguagem simples: Proíbe o desenvolvedor de vender, transferir, publicar ou revelar as especificações ou cópias sem autorização, sob pena de manutenção de confidencialidade.
O Desenvolvedor não deverá vender, transferir, publicar, revelar ou disponibilizar as Especificações Funcionais para qualquer outra pessoa ou entidade e deverá protegê-las com as mesmas medidas de segurança aplicadas a seus próprios segredos de mercado.
Erro comum: Omitir quais funcionários do desenvolvedor têm acesso ou não definir sanções por vazamento de informação.
Em linguagem simples: Reconhece que o desenvolvedor pode incorporar suas próprias ferramentas, bibliotecas ou componentes, desde que claramente identificadas e não incluídas na propriedade do cliente.
O Consumidor reconhece que pode ser necessário incorporar certas informações proprietárias do Desenvolvedor, que deverão ser claramente identificadas e excluídas da propriedade do Consumidor.
Erro comum: Não especificar quais componentes reutilizáveis permanecem sob licença do desenvolvedor ou quais exigem pagamento adicional.
Em linguagem simples: Define o montante total a ser pago pelo cliente, conforme anexo, e os termos de pagamento (parcelas, datas, condições).
O Preço, conforme definido no Inventário G, deverá ser pago pelo Consumidor ao Desenvolvedor conforme cronograma de pagamento destacado no Inventário F.
Erro comum: Não indicar se o preço é fixo ou se há cláusula de variação; deixar ambíguo o que inclui ou exclui no preço (suporte, treinamento, implementação).
Em linguagem simples: Estabelece que todos os custos relacionados aos serviços do desenvolvedor estão incluídos no preço, a menos que expressamente acordado de forma diferente.
A menos que de outra forma previsto neste acordo, todas as taxas e custos relacionados aos serviços fornecidos pelo Desenvolvedor estão incluídos no Preço.
Erro comum: Deixar aberta a possibilidade de cobranças extras indefinidas por 'custos adicionais' não mencionados no contrato.
Insira a data efetiva do contrato, nome legal completo, CNPJ/NIF, endereço da sede de ambas as partes (cliente e desenvolvedor).
💡 Use os dados registrados na junta comercial ou registro de empresas para garantir correspondência legal.
Descreva o negócio do cliente (ex. 'software de gestão de inventário'), o problema ou necessidade a resolver e anexe o Pedido de Proposta original (Inventário A) e a Proposta aceita (Inventário B).
💡 Se não houver documento formal anterior, redija um breve resumo do escopo para evitar interpretações conflitantes depois.
Indique qual será o sistema ou solução a desenvolver (ex. 'gerenciamento de contas e inventário') e detalhe os requisitos no Inventário E (Requisitos de Conteúdo das Especificações Funcionais).
💡 Quanto mais específico, menor o risco de trabalho adicional não remunerado. Use lista de funcionalidades, fluxos de negócio e integrações esperadas.
Anexe como Inventário C as atividades principais (análise, design, validação) e como Inventário D o cronograma com datas de início, marcos intermediários e conclusão.
💡 Inclua buffer para revisões do cliente. Marcos claros ajudam a gerenciar expectativas e justificar prolongamentos.
No Inventário F, detalhe se o pagamento é à vista, parcelado ou por marcos (ex. 30% na assinatura, 40% no design, 30% na conclusão). No Inventário G, indique o valor total em moeda especificada.
💡 Pagamento por marcos reduz risco para o cliente e incentiva entregas pontuais do desenvolvedor.
Confirme se todas as especificações, código e documentação pertencem ao cliente. Identifique qualquer componente proprietário do desenvolvedor que será licenciado e não transferido.
💡 Se o desenvolvedor usará ferramentas ou frameworks próprios, liste-os explicitamente para evitar conflitos futuros sobre direito autoral.
Nomeie um contato principal de cada lado e especifique se reuniões serão semanais, quinzenais ou mensais. Estabeleça formato (presencial, vídeo, telefone).
💡 Encontros regulares reduzem atrasos causados por falta de comunicação e permitem ajustes rápidos de rumo.
Leve o contrato preenchido a um advogado especializado em contratos de TI para validar conformidade com leis locais, cláusulas de rescisão, responsabilidade civil e garantias.
💡 Um contrato mal redigido pode resultar em litígios custosos. Investir em revisão jurídica é economia preventiva.
Conforme este contrato, o cliente (Consumidor) é proprietário de todas as Especificações Funcionais, código, documentação e direitos autorais derivados do projeto. O desenvolvedor não pode reutilizar, vender ou compartilhar o trabalho sem permissão escrita. Exceção: se o desenvolvedor claramente identificou suas próprias ferramentas ou bibliotecas proprietárias (ex. framework usado em múltiplos projetos), essas podem ser licenciadas ao cliente mas não transferidas. Sempre especifique isto no contrato antes de assinar.
Este modelo estabelece um cronograma no Inventário D, mas não inclui automaticamente multas por atraso. Recomenda-se adicionar uma cláusula de penalidade diária ou ajuste de preço se o atraso ultrapassar X dias. Em alternativa, defina marcos obrigatórios: se desenvolvedor não entregar o design no prazo, cliente pode rescindir e retém pagamentos proporcionalmente. Consulte um advogado para incluir cláusula de força maior (eventos imprevistos) que proteja ambas as partes equitativamente.
Mudanças no escopo devem ser registadas por escrito como aditivos ao contrato. Cada mudança deve indicar impacto no cronograma e no preço. Este modelo recomenda que o cliente aprove requisitos antes de o desenvolvedor iniciar (Inventário E), minimizando revisões. Se mudança é solicitada após desenvolvimento começar, há custo adicional que deve ser negociado e documentado. Sem processo formal de mudança, o desenvolvedor pode alegar que está cumprindo o contrato original e não é obrigado a fazer ajustes extra.
Este contrato inclui cláusula de confidencialidade que proíbe desenvolvedor de revelar ou usar dados do cliente. Refforce isto adicionando cláusula de Acordo de Confidencialidade (NDA) separada se dados são muito sensíveis (financeiros, médicos, pessoais). Especifique que desenvolvedor deve: (a) usar dados apenas para o projeto, (b) guardar em servidor seguro, (c) não compartilhar com subcontratados sem permissão, (d) destruir cópias após conclusão. Defina penalidades por vazamento (ex. indenização, rescisão imediata).
Este modelo não menciona subcontratação explicitamente. Recomenda-se adicionar cláusula proibindo ou limitando subcontratação sem consentimento escrito do cliente. Se subcontratação é permitida, desenvolvedor continua responsável pela qualidade e cumprimento de prazos. Subcontratado deve assinar mesmo NDA e cláusulas de propriedade intelectual. Sem clareza, desenvolvedor pode terceirizar trabalho e desaparecer se qualidade cai, deixando cliente sem recourse.
Este contrato cobre apenas desenvolvimento das Especificações Funcionais, não suporte pós-lançamento. Se cliente deseja manutenção, bug fixes ou atualizações, deve incluir cláusula separada ou contrato adicional especificando: (a) duração (ex. 12 meses), (b) horário de atendimento, (c) tempo de resposta, (d) custo (mensal, por incidente ou retainer). Sem clareza, desenvolvedor não é obrigado a responder a pedidos de ajuda depois de entregar.
Este Acordo de Desenvolvimento Geral cobre criação e entrega de Especificações Funcionais e/ou sistema customizado. Contrato SaaS cobre acesso contínuo a software alojado no servidor do fornecedor, normalmente com subscrição mensal ou anual. Se cliente compra um sistema desenvolvido sob este contrato mas depois o desenvolvedor oferece hospedagem ou suporte, é contrato separado com termos de acesso, segurança de dados e renovação. Use este modelo apenas se entrega é código/documentação entregue uma vez ao cliente.
Sim, recomenda-se fortemente. Este modelo é genérico e pode não cobrir todos os riscos específicos do seu projeto. Um advogado especializado em contratos de TI pode: (a) adaptar à legislação do seu país (Brasil, Portugal, outro), (b) adicionar cláusulas de limitação de responsabilidade, seguro e indenização, (c) validar termos de rescisão e cobrança, (d) proteger propriedade intelectual conforme direito autoral local. Custos de revisão (tipicamente 500–2000 EUR) são mínimos comparado a conflitos que custam 10x mais.
Inventário é termo usado para anexos formais do contrato. Este modelo recomenda 7: Pedido de Proposta, Proposta Aceita, Plano de Desenvolvimento, Cronograma, Requisitos de Conteúdo, Cronograma de Pagamento e Preço. Todos são críticos: sem Cronograma (Inv. D), não há forma de reclamar atrasos; sem Preço (Inv. G), cliente pode ser cobrado indefinidamente. Sim, é trabalho preparar 7 documentos, mas protege ambas as partes e evita surpresas custosas depois.
Um Acordo Simples é genérico e cobre qualquer serviço (consultoria, limpeza, design). O Acordo de Desenvolvimento Geral é específico para TI e desenvolvimento, com cláusulas detalhadas sobre propriedade intelectual, especificações funcionais, metodologias de desenvolvimento e segredos proprietários. Use Acordo Simples apenas para serviços não-técnicos; use este modelo para qualquer projeto que envolva código, documentação técnica ou sistemas digitais. Este é mais robusto e protege melhor investimento em software.
Um contrato de desenvolvimento completo (full development contract) cobre não apenas especificações mas também codificação, testes, implementação, treinamento e suporte pós-lançamento. Este Acordo de Desenvolvimento Geral foca principalmente na fase de especificações funcionais e análise de requisitos. Se seu projeto inclui codificação e lançamento, use contrato de desenvolvimento completo. Se apenas quer definir o quê construir antes de contratar, use este modelo como fase 1, depois contrate codificação separadamente.
Um NDA simples protege informação confidencial durante conversas iniciais sem comprometer a relação comercial. Este Acordo de Desenvolvimento inclui confidencialidade mas também define escopo, preço, cronograma e propriedade. Se você está em fase exploratória e ainda não sabe se vai contratar o desenvolvedor, comece com NDA. Quando decide prosseguir com projeto, substitua por este Acordo de Desenvolvimento ou adicione aos termos existentes.
Um contrato de licença rege como o cliente usa software já pronto (ex. Microsoft Office, Salesforce). Este Acordo de Desenvolvimento é para criar software novo customizado. Se desenvolvedor entrega um produto que será usado por múltiplos clientes (SaaS), use licença. Se desenvolvedor faz sistema única e exclusivamente para este cliente, use Acordo de Desenvolvimento. Alguns projetos combinam: desenvolvedor customiza software existente, então ambos os contratos aplicam.
Desenvolvimento de sistemas customizados, aplicações web, mobile ou desktop; criação de especificações técnicas e funcionais para soluções tecnológicas.
Contrato entre consultores e clientes para desenvolvimento de análises, diagnósticos ou soluções de processos de negócio.
Desenvolvimento de plataformas e-commerce, integrações de pagamento, sistemas de inventário e gestão de vendas online.
Desenvolvimento de aplicações de análise financeira, sistemas de compliance, plataformas de trading ou gestão de carteiras.
Sistemas de gestão de registros médicos, aplicações de telemedicina ou software de análise clínica com requisitos regulatórios.
Sistemas de gestão de produção, supply chain, rastreamento de inventário ou automação de processos operacionais.
No Brasil, contratos de desenvolvimento devem respeitar código civil (propriedade intelectual sob Lei 9.609/1998), cláusulas de limitação de responsabilidade e Lei de Proteção de Dados (LGPD). Recomenda-se adicionar cláusula de arbitragem e eleição de lei (ex. Lei Brasileira) para evitar litígios em tribunal.
Em Portugal, aplicam-se normas de direito civil português e Lei de Proteção de Dados (RGPD). Contrato deve ser claro quanto a prazos, responsabilidades e direitos autorais conforme código autoral português. Recomenda-se validação com advogado português se cliente ou desenvolvedor é pessoa coletiva em Portugal.
| Caminho | Melhor para | Custo | Tempo |
|---|---|---|---|
| Use o modelo | Projetos pequenos, startups com orçamento limitado, ou relações de confiança prévia entre cliente e desenvolvedor. | Gratuito (modelo); tempo de preenchimento ~2–4 horas | 1–2 dias para preparar anexos e assinar |
| Modelo + revisão jurídica | Projetos de médio porte (5–50 mil EUR), quando há dúvidas sobre termos ou legislação local aplica-se. | Modelo gratuito + revisão jurídica 500–1500 EUR | 1–2 semanas (revisão jurídica 3–5 dias úteis) |
| Redigido sob medida | Projetos enterprise (>100 mil EUR), relacionamentos complexos, múltiplos subcontratados, requisitos regulatórios (financeiro, saúde). | 2000–10000 EUR + custo do modelo (se aplicável) | 2–6 semanas (negociação + draft jurídico + aprovações) |
Este documento é um dos 3,000+ modelos comerciais e jurídicos incluídos no Business in a Box.
Acesse mais de 3,000+ modelos empresariais e jurídicos para qualquer tarefa, projeto ou iniciativa.
Personalize seu modelo de documento empresarial pronto para uso e salve-o na nuvem.
Compartilhe seus arquivos e pastas com sua equipe. Crie um espaço de colaboração contínua.
"De um valor fantástico! Não sei o que faria sem essa plataforma. Vale cada centavo e valeu o investimento diversas vezes."
"Eu uso o Business in a Box há 4 anos. Tem sido a fonte mais útil de documentos que encontrei. Recomendo a todos."
"Salvou minha vida tantas vezes que eu perdi a conta. O Business in a Box me poupou muito tempo e, como você sabe, tempo é dinheiro."
Pare de baixar documentos. Comece a operar com clareza. Business in a Box fornece o sistema operacional usado por mais de 250.000 empresas no mundo para estruturar, gerenciar e expandir seu negócio.
Comece grátis · Não é necessário cartão de crédito
