Bloco 1 · Da gestão à execução

Esta UC é onde se faz

Se a UC02640 ensina a planear, esta UC é onde se executa um projeto real — do briefing ao entregue + defendido.

Aplica-se tudo:

• Brief, scope, plano (UC02640).
• Produção (UC02236 / UC02233 / UC02633 / UC02631 / UC02209).
• Web/CMS/interativo (UC02634 / UC02635 / UC02249).
• A11y (UC02636).
• AR/VR se aplicável (UC02638 / UC02639).

A "espinha dorsal" da PAP

PAP = Prova de Aptidão Profissional. Esta UC é o espinha do projecto final que vai defender no júri.

Tipicamente: 1 projecto de cliente real ou pseudo-real entregue no final do 3º ano.

A nota desta UC + a PAP marcam fortemente o portfolio inicial.

Bloco 2 · Ambiente de trabalho

Setup do projecto

Antes de codar/desenhar uma linha:

• Repositório Git centralizado (GitHub/GitLab).
• Espaço de trabalho (Notion/Drive) com estrutura padrão.
• Ferramentas alinhadas com a equipa.
• Convenções acordadas (naming, branches, ficheiros).
• Permissões correctas (quem pode ver/editar o quê).

Estrutura de pastas

projecto/
├─ 00-brief/          (briefing, contrato, comms cliente)
├─ 01-research/       (referências, moodboard, análise)
├─ 02-design/         (Figma, exports, sistema)
├─ 03-content/        (copy, fotos, vídeos)
├─ 04-build/          (código, repositório)
├─ 05-qa/             (relatórios, checklists)
├─ 06-deliverables/   (entregáveis finais)
├─ 07-archive/        (versões antigas, ficheiros-fonte)
└─ README.md          (mapa do projecto)

Naming

Convenção consistente: aaaammdd_componente_versao.ext

20260520_logo_v3.svg
20260520_hero_v1.jpg
20260520_homepage_v2-aprovado.fig

Sem espaços, sem caracteres especiais. Acordado no kick-off.

Bloco 3 · Versionamento

Git para tudo (ou quase)

• Código — sempre.
• Sebentas, docs — sim, em Markdown.
• Modelos pequenos (SVG, glTF baixo peso) — sim.
• Assets binários grandes (PSD 500MB, vídeo 4K) — Git LFS ou drive separado.

git log é a memória do projecto.

Branches

• main — sempre produzível / entregável.
• develop (opcional) — integração.
• feature/xxx — trabalho em curso.
• fix/xxx — correções.
• release/v1.0 — preparação de lançamento.

Pull requests revistos por outro membro.

Commits significativos

Não:

update
fix
asdfg
final final v2 (verdadeiro).psd

Sim:

feat: adiciona página de menu com filtros
fix: corrige contraste do botão CTA (a11y)
docs: actualiza README com instruções de deploy

Formato: tipo: descrição curta (Conventional Commits).

Bloco 4 · Controlo

Prazo

Acompanhar o plano vs real semanalmente:

• Tarefas concluídas / em curso / atrasadas.
• Caminho crítico continua viável?
• Há reserva de buffer ainda?

Atrasos detectados na semana 2 = recuperáveis. Detectados na semana 5 de 6 = crise.

Burndown / burnup chart

Gráfico que mostra trabalho restante ao longo do tempo:

horas
restantes
   200 │\
   150 │ \
   100 │   \____  ← real (mais lento que plano)
    50 │     \  \
     0 │       \  \
       └──────────────  tempo
            plano  real

Acima da linha plano = atraso a acumular.

Orçamento

• Horas registadas (Toggl/Harvest) por papel.
• Comparar com horas planeadas.
• Custos fixos pagos (licenças, stock).
• Ainda há buffer?

80% do orçamento + 50% do prazo = vermelho. Replanear cedo.

Qualidade

• Checklists de Definition of Done por entregável.
• Reviews entre pares antes de mostrar ao cliente.
• Testes automáticos (lint, build) em CI.
• QA manual com cenários acordados.

Qualidade negociável dentro de limites. Bugs críticos não.

Bloco 5 · Mudanças e bloqueios

Change requests (revisão)

Cliente pede mudança a meio:

1. Receber pedido por escrito.
2. Avaliar impacto (horas, prazo, custo).
3. 3 opções:
   • Incluir + custo extra + nova data.
   • Trocar por outra feature de peso equivalente.
   • Adiar para fase 2.
4. Aguardar aprovação por escrito.
5. Implementar.

Sem este processo, scope creep + atrito.

Bloqueios

Quando alguém não pode avançar porque depende de outra coisa:

• Falta de aprovação.
• Falta de input/conteúdo do cliente.
• Dependência técnica (API, biblioteca).
• Ausência (doença, férias).

Levantar no stand-up; PM resolve, não a pessoa bloqueada.

Quando atrasar é OK

Atrasos pequenos com aviso são geríveis. Comunicar:

"Estamos 2 dias atrasados no design devido a aprovações tardias da semana passada. Compensámos com horas extra mas vamos chegar à beta com 24h de atraso. Confirmas que está OK ou queres replanear?"

Cliente é parceiro, não inimigo.

Bloco 6 · QA e aceitação

QA — Quality Assurance

Checklist por entregável:

Web:

• HTML válido (W3C).
• Lighthouse ≥ 90 (Perf/A11y/SEO).
• Cross-browser (Chrome/Firefox/Safari).
• Mobile real (375 px).
• Formulários funcionam.
• 404s tratadas.
• Performance < 3s LCP.

Vídeo:

• Resolução/codec corretos.
• Áudio com loudness adequado.
• Legendas sincronizadas.
• Exportações testadas em 2+ plataformas.

UAT — User Acceptance Test

Cliente testa com cenários acordados:

• "Procurar restaurante e fazer reserva."
• "Editar uma página no CMS."
• "Submeter contacto."

Cliente confirma por escrito que aceita. Sem UAT formal, "estará pronto" é eterno.

Defects vs improvements

• Defect (bug) — diverge do scope acordado. Corrigir sem custo extra (dentro da garantia).
• Improvement — ideia nova depois de ver. Change request com custo (ou para fase 2).

Saber distinguir evita conflitos.

Bloco 7 · Entrega

Dossier de entrega

Pacote final que o cliente recebe:

• Ficheiros-fonte (Figma, Premiere, código).
• Exports finais (PDF, MP4, build).
• Credenciais (admin CMS, hosting, domínio).
• Manual — como gerir (vídeos curtos ajudam).
• Lista de plugins/dependências instalados.
• Plano de manutenção sugerido.
• Contactos de emergência.

Treino do cliente

Sessão (1-2h) de handover:

• Mostrar painel de admin.
• Como criar/editar conteúdo.
• Onde estão backups.
• O que fazer em caso de problema.
• Como pedir suporte.

Cliente sai com autonomia suficiente.

Garantia

Janela de 30-90 dias após go-live para corrigir bugs que se manifestam.

Não cobre:

• Mudanças de scope.
• Conteúdo novo.
• Formação adicional.
• Hosting/manutenção (vende-se à parte).

Bloco 8 · PAP — defesa

A defesa

Apresentação ao júri PAP (15-20 min) + Q&A (5-15 min). Inclui:

• Apresentação — quem é o cliente, o problema, a solução.
• Demo ao vivo — mostrar a peça a funcionar.
• Processo — como chegámos aqui (não só resultado).
• Decisões críticas — porquê esta tecnologia? Porquê este conceito?
• Resultados — KPI atingidos? Aprendizagens?

Como NÃO defender

• Ler slides — júri lê mais rápido que tu.
• Esconder o que falhou — vão notar; preferem-se erros assumidos.
• Slides com 100 bullets — slides ajudam, não substituem.
• Demo gravada — preferem-se ao vivo (com plano B se internet falhar).
• Vestir descuidado — primeiro projecto profissional, vestir como tal.

O que mostrar

• Antes/Depois ou Problema/Solução.
• Processo visualmente — Figma, frames de Premiere, Git log.
• Métricas — Lighthouse, tempo, satisfação.
• Demo navegada com confiança.
• Reflexão honesta — o que mudarias.

Q&A

Júri pergunta para:

• Confirmar que sabes o que fizeste (não foi só o colega).
• Testar decisões (porquê isto e não aquilo).
• Verificar limites (e se o cliente quisesse X?).

Respostas: honestas, curtas, com exemplo.