Fora de escopo (de projeto web)
A inserção, no contrato ou plano de trabalho, de ressalvas sobre "o que o projeto web não cobre", ou do que está fora do escopo do projeto, ajuda a esclarecer para as partes envolvidas, em última análise, os produtos que serão desenvolvidos. A omissão de ressalvas pode significar que está implícita a realização dos serviços não citados no contrato, o que nem sempre se aplica.
Alguns clientes podem não ter muito clara a percepção sobre a necessidade de alguns serviços indispensáveis ao projeto web, às vezes por desconhecimento do processo de criação e produção ou por uma percepção ainda incompleta do produto final. Por isto, tendem a achar que o desenvolvimento não precisa incluí-los, o que pode ser influenciado pela grande pressão em reduzir ao máximo os custos da realização.
No meio do projeto, podem se surpreender não só com a necessidade dos serviços omitidos mas com o fato da parte contratada não tê-los incluído no escopo. Estes mal-entendidos podem ser evitados com a inserção de ressalvas no contrato, que têm função "instrutiva", pois às vezes informam ao cliente que alguns serviços simplesmente existem.
-> Por exemplo, um cliente faz negociações muito rigorosas em relação aos valores de serviços de projeto e o preço geral dos serviços fica abaixo das estimativas iniciais. Neste caso, o fornecedor pode precisar registrar que não proverá relatórios nas etapas intermediárias de projeto, que o site não terá ferramenta de busca ou animações ou ferramentas participativas, que não serão fornecidas especificações finais do produto (para manutenção e atualização de forma consistente), que a equipe do cliente não será treinada.
Listamos abaixo alguns aspectos a considerar s como ressalvas na declaração de escopo de projetos web, ou em contratos relacionados a estas atividades.
Sua menção deve variar a cada caso, baseada no produto a desenvolver (web site? aplicativo web? intranet?), na metodologia de gestão e desenvolvimento (ágil? em cascata?), no ambiente de realização (as partes estão na mesma empresa? em empresas diferentes?), nas características do cliente (tem perfil criativo? é uma empresa com relações verticais?), no relacionamento entre contratante e contratada (às vezes a realização de alguns serviços pode ficar implícita, baseada na realização de outros projetos de mesma natureza).
Algumas ressalvas a considerar na declaração de escopo ou contrato de serviços de produtos web
◊ Número de reuniões presenciais a realizar ou a realização remota de encontros. Em projetos curtos ou com prazos apertados (a maioria), muitas reuniões podem significar atrasos ou aumentos significativos no custo do desenvolvimento, já que os desenvolvedores podem estar envolvidos no envio de atas e relatórios em vez de códigos e testes de usuários, além precisar deidcar parte do tempo nas reuniões. Neste caso, a explicitação do número de reuniões ou a ocasião em que serão realizadas permite melhor uso do tempo.
Pode ser necessário também observar que reuniões adicionais incorrem em horas de preparo e deslocamento que consomem tempo de desenvolvimento do produto e serão cobradas em separado da proposta global.
◊ Horário do atendimento telefônico e de respostas a chamadas online ou por email. Em casos em que o cliente e sua atividade não estão condicionados pelo horário comércial entre 8 e 18h, de segunda a sexta-feira, pode ser necessário explicitar que o atendimento terá caráter excepcional fora deste horário e destes dias, e ficar sujeito a cobrança adicional.
◊ Modo de aprovação dos produtos. Ver se os processos de aprovação dos produtos das etapas serão realizados presencial ou remotamente, de modo que o cliente saiba de antemão se o modelo é adequado ao seu perfil e possa aceitá-lo ou não.
O cliente pode aceitar a aprovação remota de fluxogramas e diagramas de processo, mas preferir discutir presencialmente os layouts, que implicam em percepções e conceitos mais subjetivos, difíceis de explicitar em mensagens de textos ou conferências online.
◊ Autoria e edição para mídias online do conteúdo a ser publicado no site, inclusive anúncios. Caso o cliente seja o responsável pelo provimento do conteúdo a ser publicado, o simples envio de arquivos como textos, vídeos, imagens, não é suficiente, estes devem estar formatados e prontos para publicação online.
Textos devem ser preparados e revisados; imagens devem ser enviadas no formato da publicação online. Vídeos devem ser compactados e preparados para transmissão em tempo real sem grandes demoras no download.
◊ Prazos de entrega do conteúdo, de contratação de serviços de terceiros e outros fornecedores, de aprovação dos produtos e o impacto da sua não-observância no prazo final do projeto. Projetos com cronogramas rígidos ou datas de entrega urgentes e irrevogáveis podem se ressentir muito da demora de entrega de conteúdo pelos agentes responsáveis, ou pela dificuldade de aprovação dos produtos de algumas etapas.
Nestes casos é importante também especificar informações provenientes do cliente necessárias à entrega do produto no prazo estipulado.
◊ Publicação do site em língua portuguesa. Em casos em que o produto precise de visibilidade internacional, é importante explicitar que o desenvolvimento será realizado para cada idioma, o que pode, inclusive, demandar a criação de arquitetura da informação e infra-estrutura diferenciadas.
◊ Provimento de serviços ou informações técnicas de responsabilidade do cliente. Caso o ambiente de hospedagem por exemplo, seja controlado pelo cliente, este é o responsável pelo provimento de informações necessárias à publicação e atualização do site. Também se aplica à integração de bancos de dados internos a serviços online.
◊ Termo de confidencialidade das informações providas pelo cliente, especialmente crítico em caso de produtos novos ou originais, com proteção de direitos de autoria ou sob forte concorrência em sua área de atividade.
◊ Direito de uso e autoria de ferramentas usadas no produto final, aplicável quando o fornecedor ou o cliente desenvolveu um produto de autoria protegida.
◊ Processos internos a implementar ou alterar. Caso o cliente seja responsável pela atualização do conteúdo ou suporte técnico, por exemplo, deve se preparar para realizá-los, ou o resultado do projeto pode ficar comprometido.
◊ Caso a parte proponente aplique metodologias ágeis de gestão de projeto e o cliente não estiver familiarizado com estes procedimento, pode ser importante incluir algumas observações na declaração de escopo sobre os direitos e deveres dos stakeholders que considerem práticas ágeis.
◊ Registrar possíveis ajustes no orçamento (e nas taxas aplicadas) caso seja necessário realizar tarefas urgentes, durante a noite ou em finais de semana. A cobrança adicional, além de cobrir os custos adicionais com a equipe, deixa claro que a demanda bem planejada dos pedidos pode significar uma economia razoável nos custos dos serviços.
O valor das taxas urgentes pode chegar ao dobro, ou mesmo ao triplo, das aplicadas em dias e horários comerciais regulares.
◊ Realização remota das tarefas de gestão e desenvolvimento. Caso seja necessário realizar uma tarefa internamente, esta declaração deve estar formalizada em contrato, com a explicitação das devidas condições comerciais. Caso seja pedido que um colaborador do cliente acompanhe presencialmente o desenvolvimento, isto também deve ficar explicitado deste o início.
◊ Atualização do site depois de formalizado o encerramento do escopo combinado inicialmente. A atualização de sites com ou sem ferramentas de gerenciamento de conteúdo pode se confundir com o ajuste do conteúdo relacionado ao acabamento do produto. Às vezes a empresa contratada pode se ver fazendo ajustes que na verdade já fazem parte da rotina de atualização. Neste caso, a ressalva explicita as características do processo de atualização, a natureza do serviço e, caso se aplique, o valor dos serviços de atualização.
◊ Tempo de acompanhamento e realização de ajustes depois do lançamento. Esta ressalva é especialmente crítica para ambientes web que dependam da realização de tarefas pelo público. O acompanhamento do uso durante algum tempo permite o aperfeiçoamento do produto para atender a necessidades não previstas dos usuários finais.
■ Dependendo da sua amplitude, as ressalvas podem ser apresentadas ao longo da proposta ou do contrato, ou ficar localizadas ao final do texto principal, como observações para a realização.
Caso se refiram à realização de produtos adicionais, não cobertos pela proposta de projeto, sua descrição não precisa excluir de maneira definitiva estes produtos, mas deixar claro que o seu desenvolvimento acarreta tempo, conhecimento e competências não previstas. Na prática, sua mobilização implica em valores adicionais aos declarados na proposta inicial.
Texto criado em 7.2.2010.
Assuntos relacionados
► Mudanças do escopo
► Abordagens do escopo
► Elementos do Termo de Abertura do Projeto
► Atividades relacionadas (à articulação do escopo)
► Visão geral do escopo – modelo resumido
► Gerenciamento dos riscos
► Recursos disponíveis
► Cronograma
► Relacionamento com o cliente (projetos web)
Mais informações sobre o assunto (links externos)
► Devo me preocupar em fazer contrato de serviços? de Alexandre Mota (Webinsider, acesso em 14.5.2006)
► Between the lines (Projects@Work, acesso em 23.12.2005)
Serviços úteis
► Contratos digitais (acesso em 15.1.2008) – modelos de contratos com cláusulas e estruturas prontas, adaptáveis às necessidades de cada cliente, inclusive o layout
► http://www.internetlegal.com.br/legis/ – as leis municipais, estaduais e federais sobre a publicação de web sites a ser consultadas para a elaboração de projetos de web sites de órgãos públicos (sugestão de André Luiz P. Domarques de Menezes, da http://www.dmd2.com.br).
