Do briefing ao site no ar: processo de desenvolvimento em etapas

Um site não deveria avançar diretamente do briefing para o código. Cada etapa reduz um tipo diferente de incerteza.

Cada etapa existe para reduzir uma incerteza diferente Projetos de site costumam atrasar não porque escrever código seja necessariamente a parte mais difícil, mas porque decisões fundamentais permanecem abertas enquanto a implementação avança. O público não está definido. O conteúdo ainda não foi aprovado. As integrações não foram inventariadas. A pessoa responsável pelo domínio não foi identificada. O layout é discutido antes da mensagem. O prazo de publicação chega enquanto ainda se decide o que será publicado. Um processo de desenvolvimento não elimina mudança. Ele organiza a mudança para que cada decisão seja tomada no momento em que custa menos corrigir. O fluxo não precisa ser rígido. É comum voltar uma etapa depois de descobrir uma restrição ou observar usuários. O que deve ser evitado é pular diretamente de uma ideia genérica para uma implementação difícil de revisar. O briefing não é um formulário de preferências visuais Perguntas como “qual cor você prefere?” e “quais sites você acha bonitos?” podem ajudar mais tarde. Elas não definem a finalidade do projeto. Um briefing útil investiga: problema que motivou o projeto; público atendido; serviços ou produtos prioritários; dúvidas recorrentes; ações esperadas; conteúdo disponível; restrições de prazo e orçamento; integrações; responsáveis; riscos; critérios de sucesso. Compare duas solicitações: Precisamos de um site moderno, com animações e formulário. Precisamos apresentar três serviços para pequenas empresas, responder dúvidas de contratação e encaminhar oportunidades qualificadas para a equipe comercial. A segunda ainda não define a solução inteira, mas permite discutir arquitetura, conteúdo, métricas e escopo. Etapa 1: descoberta A descoberta existe para confirmar o problema, o contexto e a viabilidade inicial. O GOV.UK Service Manual orienta que a fase de descoberta seja usada para compreender o problema e decidir se vale a pena avançar, não para começar a construir o serviço. Para um site empresarial, a descoberta pode incluir: entrevistas com direção, vendas, atendimento e operação; análise do site atual; levantamento de dúvidas de clientes; inventário de conteúdo; avaliação de concorrentes e referências; análise de métricas existentes; mapeamento de sistemas; identificação de requisitos legais e de segurança; revisão de domínio, DNS e hospedagem; definição preliminar de métricas. Entregáveis da descoberta Não é necessário produzir um relatório extenso em todos os projetos. O mínimo útil costuma ser: 1. declaração do problema; 2. públicos prioritários; 3. tarefas principais; 4. mapa de conteúdo; 5. restrições; 6. riscos; 7. escopo inicial; 8. hipóteses a validar; 9. responsáveis; 10. critérios de sucesso. Critério para avançar A equipe deve conseguir explicar por que o site será feito e quais resultados indicarão que ele está funcionando. Se não houver resposta, iniciar o design apenas transforma incerteza em retrabalho visual. Etapa 2: conteúdo e arquitetura da informação A arquitetura organiza páginas, caminhos e relações. O conteúdo define o que essas páginas precisam comunicar. Um site institucional pode ter: Essa árvore não é um padrão obrigatório. Ela deve refletir como pessoas procuram e compreendem a oferta. Durante essa etapa, registre: título e objetivo de cada página; público; mensagem principal; evidências necessárias; ação esperada; links internos; responsável pelo conteúdo; data de revisão. O design fica mais preciso quando utiliza conteúdo próximo do real. Texto fictício esconde problemas de comprimento, hierarquia e clareza. Conteúdo também é requisito técnico Uma página pode exigir: tabela; vídeo; formulário; download; mapa; dados estruturados; comparação; área autenticada; integração com CRM. Essas necessidades alteram desenvolvimento, acessibilidade, segurança e desempenho. Devem aparecer antes da aprovação final do layout. Etapa 3: protótipo Protótipo não é uma versão incompleta do produto. É uma representação criada para responder perguntas com custo reduzido. O guia da fase alpha do GOV.UK recomenda explorar abordagens, restrições e riscos antes da construção integral. Dependendo da dúvida, o protótipo pode ser: esboço em papel; wireframe; fluxo navegável; componente isolado; página com conteúdo real; prova técnica de uma integração; formulário simulado. O nível de fidelidade deve acompanhar a pergunta Pergunta Protótipo apropriado A ordem das páginas faz sentido? Mapa e wireframe A mensagem é compreensível? Página com texto real O usuário encontra o contato? Fluxo navegável A integração é tecnicamente viável? Prova de conceito A identidade visual funciona? Protótipo de alta fidelidade O formulário é excessivo? Protótipo preenchível Criar uma interface visualmente detalhada antes de resolver estrutura e conteúdo pode gerar apego a decisões ainda frágeis. Etapa 4: definição da primeira entrega MVP significa Minimum Viable Product , ou produto mínimo viável. No contexto de um site, não deve ser interpretado como “qualquer coisa que possa entrar no ar”. A primeira entrega precisa ser pequena o suficiente para caber no projeto e completa o suficiente para operar. Ela deve incluir, conforme o risco: páginas prioritárias; conteúdo aprovado; identidade aplicada; formulários funcionais; comportamento responsivo; acessibilidade mínima planejada; segurança administrativa; HTTPS; analytics quando autorizado; backups; monitoramento; política de publicação; responsáveis pela manutenção. O guia sobre MVP sem atalhos perigosos aprofunda a diferença entre reduzir escopo e remover qualidade operacional. Etapa 5: preparação técnica Antes de implementar páginas, a equipe precisa definir a base do projeto. Decisões comuns: framework ou geração estática; CMS ou conteúdo versionado; repositório; convenções de código; ambientes; gerenciamento de segredos; estratégia de deploy; hospedagem; banco de dados; armazenamento de arquivos; envio de e mails; logs; monitoramento; backup; rollback. A escolha deve acompanhar o problema. Um site institucional de poucas páginas pode não precisar de uma aplicação cliente complexa. Um portal com estados, permissões e integrações pode exigir arquitetura diferente. O NIST SSDF 1.1 recomenda incorporar práticas de segurança ao ciclo de desenvolvimento, independentemente do modelo de desenvolvimento utilizado. Isso inclui preparar ambientes, proteger artefatos, produzir software seguro e responder a vulnerabilidades. Segurança não deveria aparecer como uma auditoria inesperada no último dia. Etapa 6: desenvolvimento por fatias verificáveis Em vez de construir o site inteiro e apresentar tudo no final, a equipe pode trabalhar por fluxos ou páginas completas. Exemplo: 1. cabeçalho e navegação; 2. página inicial; 3. página de serviço; 4. formulário; 5. conteúdo editorial; 6. integrações; 7. rodapé e páginas institucionais. Cada fatia passa por: O code review eficaz deve avaliar contexto, risco, testes, manutenção e impacto, não preferências pessoais de estilo. Definição de pronto Uma página não está pronta apenas porque se parece com o protótipo. Um critério pode incluir: conteúdo aprovado; comportamento em diferentes larguras; navegação por teclado; contraste validado; imagens otimizadas; formulário com erros compreensíveis; tratamento de estados vazios; metadados; testes; logs sem dados sensíveis; documentação da configuração. Etapa 7: acessibilidade integrada O W3C orienta integrar acessibilidade ao processo de produção, com planejamento, responsabilidades, avaliação e acompanhamento. Isso afeta diferentes papéis: Conteúdo linguagem clara; títulos estruturados; textos alternativos; links descritivos; legendas e transcrições. Design contraste; foco; estados; tamanho de alvos; leitura com zoom; ausência de dependência exclusiva de cor. Desenvolvimento HTML semântico; navegação por teclado; nomes acessíveis; gerenciamento de foco; mensagens anunciadas adequadamente. Teste automação; teclado; zoom; leitor de tela; tarefas reais. O checklist completo está em acessibilidade web desde o projeto. Etapa 8: validação antes da publicação A validação deve ser orientada pelo risco. Conteúdo telefones, e mails e endereços estão corretos; serviços correspondem ao que a empresa oferece; preços e prazos estão atualizados; links funcionam; arquivos são os definitivos. Funcionalidade formulários enviam; mensagens chegam ao destino; integrações registram dados; autenticação funciona; erros são tratados; redirecionamentos estão corretos. Experiência celular, tablet e desktop; zoom; teclado; navegadores suportados; conexões menos rápidas; estados de carregamento e erro. Operação domínio e DNS; HTTPS; backups; restauração; monitoramento; logs; alerta de indisponibilidade; procedimento de rollback. Segurança contas administrativas; MFA; segredos; dependências; headers; permissões; exposição de ambientes; dados pessoais. O artigo sobre testes web orientados por risco ajuda a decidir onde investir maior profundidade. Etapa 9: publicação controlada Um plano de publicação deve registrar: 1. data e janela; 2. responsáveis; 3. versão; 4. backup prévio; 5. mudanças de DNS; 6. ordem das ações; 7. validações; 8. condição de rollback; 9. comunicação; 10. monitoramento intensivo. Fluxo simplificado: Em migrações, mantenha o ambiente anterior disponível durante a janela de retorno quando isso for tecnicamente possível. Publicar manualmente por FTP pode funcionar em operações muito pequenas, mas reduz rastreabilidade. Projetos que evoluem com frequência se beneficiam de versionamento e automação, como descrito em DevOps e entrega confiável. Etapa 10: operação O site entrou no ar, mas ainda precisa provar que funciona. O guia da fase live do GOV.UK destaca operação contínua, análise de métricas e melhoria baseada no que é observado. Nas primeiras horas e dias, acompanhe: disponibilidade; erros; formulários; indexação; certificados; performance; eventos de conversão; logs; reclamações; comportamento em dispositivos reais. A área de performance do web.dev reúne orientações para medir carregamento, interatividade e estabilidade. Um projeto saudável mantém decisões visíveis O documento central do projeto não precisa ser sofisticado. Precisa registrar: Item Resposta Problema O que motivou o projeto Público Quem precisa utilizá lo Escopo O que entra e o que não entra Métricas Como o resultado será observado Responsáveis Quem decide, aprova e opera Riscos O que pode comprometer a entrega Conteúdo Quem produz e aprova Publicação Como a versão entra no ar Recuperação Como voltar ou restaurar Evolução Como novas demandas serão priorizadas Esse registro reduz discussões baseadas em memória e permite avaliar mudanças. O processo não termina em uma linha reta Projetos digitais evoluem porque o negócio, o conteúdo e o uso mudam. Um processo adequado não tenta impedir isso. Ele cria ciclos curtos de observação, decisão e entrega. O site no ar deve ser tratado como um produto operado: A principal diferença entre um projeto improvisado e um processo sustentável não está na quantidade de reuniões. Está na capacidade de explicar por que cada decisão foi tomada, testar antes que o custo aumente e operar o resultado depois da publicação.