A entrega de um website deve permitir à sua empresa aceder às contas certas, localizar os ficheiros acordados, compreender como as alterações chegam ao site publicado e saber quem resolve os problemas. Peça um inventário escrito, verifique-o com os seus próprios acessos autorizados e registe tudo o que ficar pendente antes de encerrar o projeto.
Esta checklist de entrega de um website destina-se a empresas que recebem um novo site ou mudam a equipa responsável pela sua manutenção. Abrange o controlo prático e a continuidade. Os recursos, permissões e serviços que tem direito a receber dependem do que foi acordado; um convite para uma conta ou uma pasta de ficheiros não resolve, por si só, a questão dos direitos de propriedade intelectual.
1. Acorde o que está incluído na entrega
Comece pela proposta e pelo âmbito final acordado. Liste as páginas, os idiomas, as integrações e os materiais editáveis a entregar. Distinga o website publicado dos ficheiros de código-fonte, ficheiros de design, exportações de conteúdo e serviços de terceiros. Um website criado num editor alojado pode ter um processo de exportação diferente do de um projeto com código à medida. Por isso, pergunte de que precisaria outro fornecedor autorizado para manter este site em concreto.
Registe a data da entrega, a versão exata que está a ser aceite e a pessoa responsável por cada elemento. Se o trabalho continuar após o lançamento, identifique a versão a que se refere a documentação. Uma gravação de um editor antigo ou um arquivo criado antes da última correção podem induzir em erro, mesmo quando existem todas as pastas previstas.
Use três estados simples: recebido e verificado, recebido mas não verificado e pendente. «Enviado por email» não significa «utilizável pela equipa que recebe o projeto». Acrescente uma nota de aceitação que explique a verificação efetuada, como abrir o ficheiro de design na aplicação acordada ou entrar na conta de alojamento com o perfil previsto.
Escolha cedo o formato da entrega
Mantenha um inventário curto num local partilhado que a empresa possa conservar. Guarde os ficheiros de apoio em pastas com nomes claros, incluindo a versão ou a data quando isso for relevante. Não transforme esse inventário num documento de palavras-passe. Registe onde são geridas as credenciais e quem pode conceder acesso, mantendo os dados secretos num sistema seguro adequado.
2. Verifique as contas, o domínio e as responsabilidades de faturação
Identifique a entidade de registo do domínio, o fornecedor de DNS, o serviço de alojamento, o editor do website ou repositório de código e todos os serviços de formulários, reservas ou email de que o site depende. Podem corresponder a contas distintas. Poder editar uma página não significa necessariamente poder renovar o domínio, alterar o contacto de faturação ou restaurar o website.
Para cada conta, registe a organização responsável, o utilizador convidado, o nível de permissões, o responsável pela renovação ou subscrição e o contacto de recuperação. Use convites individuais sempre que a plataforma o permitir. Verifique se as pessoas certas conseguem entrar com as suas próprias contas e executar as tarefas exigidas pelo seu papel. Siga o processo do fornecedor para a autenticação multifator e a recuperação; evite fazer circular uma única palavra-passe de administrador partilhada.
Peça à equipa atual que explique quais os registos DNS que servem o website e quais os que servem o email ou outros serviços. Guarde um registo datado da configuração antes de uma alteração acordada. A Cloudflare documenta a importação e a exportação de registos DNS; outros fornecedores dispõem dos seus próprios controlos. Uma lista de registos exportada é um comprovativo útil, mas não constitui uma cópia de segurança completa de todos os serviços associados ao domínio.
A entrega não exige necessariamente mudar todos os fornecedores. Se for necessária uma transferência, acorde primeiro a conta de destino, as dependências, o calendário e as verificações. Não cancele o serviço existente apenas porque chegou um novo convite. Confirme quem paga a próxima renovação e para onde seguem os avisos importantes, sobretudo quando o contacto original está a sair do projeto.
3. Crie um inventário que possa realmente verificar
A tabela seguinte é um ponto de partida. Substitua os exemplos pelos seus sistemas reais e pelos elementos a entregar que foram acordados. Atribua um responsável e um estado a cada linha. Quando um elemento estiver fora do âmbito do projeto, registe-o expressamente, juntamente com a próxima ação, em vez de o considerar entregue sem qualquer indicação.
| Elemento a registar | Comprovativos a pedir | Verificação da equipa que recebe o projeto |
|---|---|---|
| Domínio, DNS e alojamento | Localização das contas, perfis, contacto para renovações e registo da configuração | As pessoas autorizadas conseguem encontrar os serviços e consultar as definições necessárias |
| Código-fonte ou editor do website | Repositório ou espaço de trabalho, versão aceite e instruções de publicação | A equipa consegue abrir o projeto e identificar a versão publicada |
| Conteúdos e materiais de design | Ficheiros editáveis acordados, exportações, lista de recursos e referências das licenças | Os ficheiros abrem corretamente e estão documentados os eventuais limites de utilização ou edição |
| Formulários e integrações | Destinos, contas responsáveis, dependências e procedimento de teste seguro | Um teste acordado demonstra o percurso previsto sem contactar clientes reais |
| Cópias de segurança e recuperação | Localização, conteúdo e data das cópias de segurança, e instruções de restauro | Uma demonstração segura de recuperação abrange as partes relevantes do site |
| Apoio e trabalho pendente | Canal de contacto, âmbito, período de cobertura e lista de problemas | Cada questão por resolver tem uma próxima ação acordada e uma pessoa responsável |
Peça comprovativos que possa voltar a consultar depois da chamada. Uma gravação curta pode explicar uma alteração habitual de conteúdo; um comando escrito ou uma sequência de publicação pode ajudar quem faz a manutenção técnica. Nenhum destes materiais deve expor chaves secretas. O inventário deve indicar onde se encontram e quem os mantém atualizados quando o site muda.
Verifique separadamente o acesso ao código-fonte e à publicação
Um repositório de código e uma conta de alojamento têm finalidades diferentes. Se for acordada a transferência de um repositório, reveja depois as suas integrações e permissões. O GitHub indica que os webhooks, os segredos e as chaves de implementação continuam associados a um repositório transferido. Por isso, uma transferência não substitui a revisão de quem e do que ainda pode atuar sobre o projeto.
4. Torne os ficheiros e as instruções de recuperação utilizáveis
Peça os materiais previstos no acordo num formato que a equipa que recebe o projeto consiga usar. Podem incluir conteúdo editável das páginas, originais de imagens, ficheiros de logótipo aprovados, documentos de design e código-fonte. Liste os tipos de letra externos, imagens de bancos de imagens, plugins e outras dependências, com os dados de conta ou licença necessários para esclarecer a continuidade da utilização. Não parta do princípio de que todos os recursos de terceiros podem ser transferidos ou reutilizados sem restrições.
Num projeto feito à medida, peça o ambiente de execução suportado, as instruções de instalação das dependências, o comando de compilação, os nomes das variáveis de configuração e o processo para pré-visualizar e publicar uma alteração. Não inclua os valores secretos na documentação geral. Um profissional de manutenção com as competências necessárias deve conseguir identificar as definições que pertencem ao ambiente de teste e as que estabelecem ligações a serviços em produção.
Defina o que está incluído numa cópia de segurança. A documentação do WordPress explica que um restauro típico exige tanto a base de dados como os ficheiros. Noutra plataforma, peça ao fornecedor que descreva as dependências equivalentes. Uma captura de ecrã, um arquivo de código-fonte ou uma exportação do texto das páginas podem ser úteis, mas nenhum deve ser apresentado como um plano de recuperação completo sem explicar as suas limitações.
Acorde quem faz as cópias de segurança, onde são guardadas, durante quanto tempo são conservadas e como se verifica o restauro. Peça uma demonstração num ambiente seguro, com o tratamento adequado dos dados dos clientes. Registe o que foi restaurado e o que ficou fora do exercício. Não use o website publicado como um teste improvisado de recuperação, nem presuma que um arquivo não testado resolverá qualquer falha de serviço.
5. Faça uma breve sessão de verificação para aceitação
Use as contas próprias e autorizadas da equipa que recebe o projeto durante a sessão. Encontre a versão aceite do website, abra o editor ou o projeto, localize as instruções de apoio e demonstre uma alteração habitual num ambiente de pré-visualização ou teste. O objetivo é perceber se a próxima pessoa consegue operar o site com os materiais entregues, sem depender de explicações que só existem na memória do fornecedor.
Reveja um pequeno conjunto de percursos reais de clientes: ler a descrição de um serviço, navegar no telemóvel, chegar à forma de fazer um pedido de informação e inspecionar os estados de confirmação e de erro acordados. Use condições de teste seguras para formulários, reservas e pagamentos. Acorde previamente os endereços e destinos de teste para que o exercício de entrega não envie mensagens a clientes reais nem crie encomendas involuntárias.
Verifique se as contas de pesquisa e medição, quando incluídas, também têm os acessos adequados. O Google Search Console distingue proprietários, utilizadores com acesso total e utilizadores com acesso restrito, e explica como os tokens de verificação afetam a propriedade verificada. A revisão das permissões do Search Console é distinta do acesso ao próprio website. Registe a propriedade e o perfil relevantes, sem tratar o acesso como prova de que o Google indexou todas as páginas.
Uma entrega hipotética a uma consultora
Imagine uma consultora que recebe um website de cinco páginas. O seu gestor consegue editar o texto, mas os avisos de renovação continuam a ser enviados para um antigo fornecedor e o destino do formulário não está documentado. A equipa regista ambas as lacunas, confirma o contacto de faturação através do processo do fornecedor e documenta o percurso do formulário com um teste acordado. O gestor repete depois uma edição em pré-visualização seguindo as instruções entregues. Este é um exemplo do método, não o relato de um resultado obtido por um cliente.
6. Defina o apoio e reveja os acessos restantes
Registe o que acontece após a aceitação. Quem trata de uma interrupção do serviço, de um formulário com falha, de uma alteração de conteúdo ou da renovação de uma subscrição? Distinga a correção dos defeitos de entrega acordados das novas funcionalidades e da manutenção contínua. Indique o meio de contacto acordado, o período de cobertura, os custos aplicáveis e os eventuais compromissos de resposta. A existência de um endereço de email de apoio não significa que haja monitorização permanente.
Mantenha uma lista curta de trabalho pendente com o problema, o impacto, a próxima ação, a pessoa responsável e a data de revisão. Decida quais os problemas que impedem a aceitação e quais podem ser tratados depois, mediante um acordo explícito. Se uma integração de reservas continuar indisponível, por exemplo, registe o percurso alternativo para os clientes e quem decide quando a integração final está pronta.
Reveja os colaboradores que saem, os convites, os tokens de integração e os contactos de recuperação depois de a equipa que recebe o projeto ter verificado a continuidade. Mantenha apenas os acessos necessários ao trabalho contínuo acordado. Coordene a remoção ou rotação de credenciais com o responsável técnico, para que a limpeza não interrompa inesperadamente a publicação, os formulários ou outro serviço dependente. Conserve um registo das decisões sem nele guardar valores secretos.
7. Inclua os requisitos de entrega no briefing do website
O momento mais simples para acordar uma entrega útil é antes do início do trabalho. Acrescente os editores previstos, as competências técnicas internas, os ficheiros necessários, a organização das contas e as necessidades de apoio ao briefing do projeto do website. Para um site existente que muda de fornecedor, combine este inventário com uma revisão para reformulação do website, para que as responsabilidades pelos serviços existentes continuem claras.
Antes de encerrar o projeto, confirme que o inventário corresponde ao acordo, que os acessos necessários funcionam, que os ficheiros entregues abrem, que a sessão de verificação segura está registada e que o trabalho por resolver tem um responsável. Guarde a versão aceite juntamente com as notas de entrega. Assim, a próxima pessoa responsável pela manutenção terá um ponto de partida prático quando surgir uma alteração ou um problema.
O serviço de websites da Digital Studio começa nos 2.190 EUR para a criação pontual de um site com até cinco páginas, usando conteúdo fornecido, com design responsivo, bases de SEO, um formulário de contacto para potenciais clientes e lançamento no seu domínio. Os materiais de entrega específicos, as transferências, a formação e o apoio contínuo devem ser acordados por escrito para o seu projeto; esta checklist não os acrescenta ao pacote publicado. Descreva o seu website e as necessidades de entrega para que o âmbito possa ser discutido antes do início do trabalho.
