Implementar um projeto multimédia

Introdução

Esta UC é a continuação prática da UC02640. Se na anterior se aprende a planear, aqui executa-se um projeto real do briefing à entrega ao cliente + defesa. É também a espinha dorsal da PAP — Prova de Aptidão Profissional.

50h dá para um projecto de média dimensão (vídeo institucional de 90s + site companion; ou app interactiva em Figma + WebXR; ou peça de transmedia pequena). O critério é completude: melhor entregar pequeno e completo do que grande e cinzento.

1. Da gestão à execução

Tudo da UC02640 (briefing, scope, plano, orçamento, risco, comunicação) aplica-se. Esta UC é onde o plano encontra a realidade — e tipicamente perde, na 1ª iteração.

Atitude: - Disciplina sobre genialidade. Planos cumpridos > ideias geniais. - Comunicar mau cedo. A surpresa é o inimigo. - Reagir com replanear, não com horas extra eternas.

2. Setup profissional

2.1 Repositório

Tudo num repositório Git (GitHub privado ou organizacional). Vantagens:

• História completa do projecto.
• Branches para tentativas.
• Code review entre pares.
• CI/CD para deploy automático.

Se há ficheiros binários grandes (PSD, vídeo raw), usar Git LFS ou separar para Drive/Dropbox sincronizado, referenciando no README.

2.2 Estrutura de pastas

Padrão proposto:

projecto-cliente-x/
├─ 00-brief/
│   ├─ briefing-criativo.md
│   ├─ contrato.pdf
│   └─ comms/
├─ 01-research/
│   ├─ moodboard.png
│   └─ refs/
├─ 02-design/
│   ├─ figma-link.txt
│   ├─ exports/
│   └─ tokens.json
├─ 03-content/
│   ├─ copy/
│   ├─ fotos/
│   └─ video/
├─ 04-build/
│   └─ (código fonte)
├─ 05-qa/
│   ├─ checklist.md
│   ├─ lighthouse-reports/
│   └─ ua-test-results.md
├─ 06-deliverables/
│   └─ (entregáveis finais com versão)
├─ 07-archive/
│   └─ (rascunhos, takes não usadas)
└─ README.md

O README.md é o mapa do projeto — alguém entra hoje sabe ler em 5 min.

2.3 Naming

Convenção consistente. Sugestão:

aaaammdd_componente_versao.ext
20260615_logo_v3.svg
20260615_homepage_v2-aprovado.fig
20260615_rough-cut_v4.mp4

Sem espaços, sem acentos, sem caracteres especiais. Acordado no kick-off entre toda a equipa.

2.4 Ferramentas alinhadas

Confirmar no kick-off: - Onde estão tarefas? (Asana / Notion / Linear). - Onde está a comunicação? (Slack / Discord / email). - Onde estão ficheiros? (Drive / Dropbox / OneDrive). - Que software de design? (Figma / Sketch / Adobe XD).

Trocar de ferramenta a meio = caos. Decidir cedo.

3. Versionamento

3.1 Git workflow

Variantes: - GitHub Flow — main + feature/* PRs. Simples; bom para equipa pequena. - Git Flow — main + develop + feature/* + release/* + hotfix/*. Mais formal; bom para projetos grandes. - Trunk-based — só main, feature flags. Avançado.

Para a maior parte dos projetos da UC: GitHub Flow.

3.2 Branches

• main — sempre produzível.
• feature/nome-curto — uma feature ou bug. Curto.
• fix/nome-curto — correções.

Merge via Pull Request com revisão de outro membro.

3.3 Commits (Conventional Commits)

tipo: descrição em minúsculas

Corpo opcional explicando porquê.

Footer opcional (issues, BREAKING CHANGE).

Tipos: feat, fix, docs, style, refactor, test, chore.

Exemplos:

feat: adiciona página de menu com filtros
fix: corrige contraste do botão CTA (a11y WCAG 1.4.3)
docs: actualiza README com instruções de deploy
chore: bump dependencies para Next 15.3

Não:

update
asdf
final final v2 (verdadeiro)

3.4 Versionar designs

Figma tem history próprio e branching (em plano Pro). Para Adobe, CC Libraries + versioning. Para ficheiros locais (Premiere, After Effects), guardar versões nomeadas em 02-design/exports/ ou 07-archive/.

4. Controlo de execução

4.1 Prazo

Acompanhar plano vs real semanalmente:

Caminho crítico atrasado = projeto atrasado. Fora do crítico = absorvível com folga.

4.2 Burndown chart

Gráfico clássico ágil:

horas
restantes
   200 │\
   150 │ \____plano
   100 │      \____
    50 │     real \ \
     0 │             \
       └─────────────────  tempo
        sem 1   2   3   4

Real acima do plano = atraso a acumular. Real abaixo = à frente (raro, suspeitar de scope falso).

4.3 Orçamento

Registar horas reais (Toggl, Harvest, Clockify) por papel/tarefa. Confrontar com estimado:

Vermelho se: 80% orçamento gasto + 50% do prazo. Tempo de replanear.

4.4 Qualidade

Para cada entregável, ter Definition of Done clara:

Ex. página web "pronta": - Aprovada visualmente. - HTML válido (W3C). - Lighthouse ≥ 90 (3 métricas). - Mobile real testado (375 px). - Funciona em Chrome + Firefox + Safari. - Sem console.error em produção. - Formulários funcionais. - Cliente aprovou por escrito.

5. Gerir mudanças

5.1 Change requests

Cliente pede mudança a meio. Processo:

1. Receber por escrito (email, Notion ticket).
2. Avaliar impacto em horas, prazo, custo, riscos.
3. Apresentar 3 opções:
4. (a) Incluir + custo extra + nova data.
5. (b) Trocar por feature equivalente já planeada.
6. (c) Adiar para fase 2.
7. Aguardar aprovação escrita antes de mexer numa linha.
8. Actualizar plano + comunicar à equipa.

Sem este processo: scope creep, equipa stressada, projeto a derrapar.

5.2 Bloqueios

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

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

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

5.3 Crises

Quando algo grande corre mal (hosting cai, key person fora, scope explode):

1. Parar e avaliar (1-2h).
2. Decidir com calma — comunicar ao cliente o que aconteceu.
3. Plano de recuperação com prazos novos.
4. Aprender — post-mortem para evitar repetir.

Pânico não acrescenta nada. Calma comunicada sim.

6. QA — Quality Assurance

6.1 Tipos de teste

• Unit testing (código) — funções isoladas.
• Integration testing — partes a funcionar juntas.
• End-to-end — fluxos completos como utilizador (Playwright, Cypress).
• Smoke testing — está vivo? Páginas carregam?
• Regression testing — não estragámos o que já funcionava?
• UAT (User Acceptance) — cliente confirma que cumpre o briefing.

Para projetos pequenos: smoke + UAT chegam.

6.2 Checklist genérica

Web: - HTML válido (validator.w3.org). - Lighthouse ≥ 90 (Perf/A11y/Best/SEO). - Cross-browser (Chrome, Firefox, Safari, Edge). - Mobile real (375 px sem scroll horizontal). - Formulários funcionam + validações. - 404s tratadas. - Performance: LCP < 2.5s, CLS < 0.1. - HTTPS + redirect. - Robots/sitemap. - Analytics instalado. - Política de cookies/RGPD.

Vídeo: - Resolução/fps/codec corretos para destino. - Loudness ~ −14 LUFS (web) ou −23 (TV). - Legendas sincronizadas, sem typos. - Exporta sem artefactos. - Testado em mobile + desktop.

App / experiência interactiva: - Fluxos principais funcionam. - Erros tratados (rede, dados inválidos). - Permissões pedidas com contexto. - Performance perceptível. - Acessibilidade básica.

6.3 UAT

Cliente testa com cenários acordados antes da go-live:

Cenário 1: Visitante encontra horário e morada.
Cenário 2: Visitante faz reserva pelo formulário.
Cenário 3: Cliente edita uma página no admin do CMS.
Cenário 4: Mobile — fluxo completo do menu até reserva.

Cliente confirma por escrito ("aceito o entregável"). Sem isto, "estar pronto" é eterno.

6.4 Defects vs improvements

• Defect — diverge do scope acordado. Corrigir dentro da garantia, sem custo extra.
• Improvement — ideia nova que surgiu ao usar. Change request com custo (ou fase 2).

Saber distinguir poupa atrito.

7. Entrega ao cliente

7.1 Dossier final

Pacote que o cliente recebe:

• Ficheiros-fonte organizados (Figma, Premiere, código, Photoshop).
• Exports finais (PDF, MP4, build production).
• Credenciais (admin CMS, hosting, domínio, email).
• Manual — escrito + vídeos curtos (Loom) de tarefas frequentes.
• Lista de dependências + versões + onde renovar (domínio, SSL, plugins).
• Plano de manutenção sugerido (preços, frequência).
• Contactos — quem ligar para problema X.

7.2 Treino do cliente

Sessão 1-2h de handover: - Mostrar painel de admin. - Criar/editar conteúdo em direto. - Mostrar onde estão backups + como restaurar. - O que fazer em caso de problema (passos primeiros + contacto). - Como pedir suporte / change requests.

Gravar a sessão (Zoom record + Drive) — cliente pode rever quando quiser.

7.3 Garantia

Janela de 30 a 90 dias após go-live: - Inclui correção de bugs do scope acordado. - Não inclui scope novo, formação adicional, hosting, manutenção.

Vende-se à parte: - Contrato de manutenção mensal (X €/mês para Y horas + monitorização + backups). - Banco de horas (10h por 600€, válido 6 meses). - SLA para emergências.

7.4 Marketing pós-entrega

Com permissão do cliente: - Case study no site da agência. - Posts redes sociais. - Testemunho do cliente para próximos.

Pedir antes do projeto acabar quando a satisfação está alta.

8. PAP — Prova de Aptidão Profissional

8.1 O que é

Apresentação oral e demo do projecto perante júri (interno + externo) no final do curso. Equivale a uma "defesa de tese" no ensino vocacional.

Estrutura típica: - Apresentação 15-20 min. - Q&A 5-15 min. - Júri dá nota.

8.2 Conteúdo a cobrir

1. Quem é o cliente (real ou pseudo-real).
2. Problema que motivou o projecto.
3. Solução que entregaste.
4. Processo — como chegaste lá (não só resultado).
5. Decisões críticas — porquê esta tecnologia? Porquê este conceito?
6. Demo ao vivo.
7. Métricas / resultados se aplicável.
8. Lessons learned.

8.3 Slides

• 15-25 slides chega.
• Imagens grandes, texto pouco.
• 1 ideia por slide.
• Demo ao vivo > screenshots quando possível.
• Plano B se internet/equipamento falhar (screenshots, vídeo gravado).

8.4 Linguagem corporal

• Olhar o júri, não os slides.
• Postura — pés assentes, ombros descontraídos.
• Voz clara, ritmo controlado, pausas após pontos-chave.
• Mãos visíveis, não nos bolsos nem cruzadas.
• Vestir apropriado (smart casual mínimo).

8.5 Q&A

Júri pergunta para: - Confirmar que tu fizeste o trabalho (vs colega). - Testar decisões (e se fosse X? e se o cliente quisesse Y?). - Sondar limites (o que correu mal? o que farias diferente?).

Respostas: honestas, curtas, com exemplo. "Não sei" é melhor que inventar.

8.6 Como NÃO defender

• Ler slides — júri lê mais depressa que tu falas.
• Esconder o que falhou — vão notar; preferem erros assumidos.
• Slides em 8pt com 200 palavras — distraem em vez de apoiar.
• Demo gravada "porque não dá para fazer ao vivo" — desconfiam.
• Estar atrasado — chega 30 min antes.

9. Pós-defesa

9.1 Arquivo

Guardar: - Ficheiros-fonte de tudo. - Slides da defesa. - Contratos, comunicações relevantes. - Lessons learned escrita. - Métricas.

3 anos depois quereres mostrar a alguém ou recuperar um asset — saberes onde está = profissionalismo.

9.2 Portfolio

A PAP é a primeira peça séria do teu portfolio. Trabalhá-la em formato apresentável: - Case study no site pessoal (cliente, problema, solução, processo, resultado). - Behance / Dribbble para a parte visual. - GitHub com README rico para a parte código. - YouTube/Vimeo com peças de vídeo.

9.3 Continuar a aprender

Após o curso: - Comunidades (Discord, Slack de profissões). - Cursos online (Frontend Masters, Domestika, etc.). - Projetos pessoais. - Open source contributions. - Mentoria + ser mentor.

A profissão muda; quem deixa de aprender torna-se obsoleto em 2-3 anos.

10. Liga a outras UCs

Esta UC integra todas as anteriores: - UC02640 — gestão de projeto (a base). - UC02285 / UC02199 / UC02632 — briefing, conceito, storyboard. - UC02236 / UC02208 / UC00504 / UC02258 — base visual e áudio. - UC02233 / UC02633 — vídeo. - UC02631 / UC02209 / UC02242 — animação 2D/3D + publicação. - UC02634 / UC02635 / UC02249 — web + CMS + interativo. - UC02636 — acessibilidade. - UC02637 / UC02638 / UC02639 — jogos / AR / VR.

A graduação é fazer tudo isto convergir num projeto.

11. Conclusão

Executar é a parte que distingue alunos de profissionais. Quem só sabe falar, planear ou desenhar fica para trás. Quem entrega, repete e melhora, cria carreira.

Esta UC é o portão de saída do curso — e a porta de entrada para o mercado.

Apêndice A · Checklist de execução (semanal)

SEMANA __ / __  ·  data: __

PLANO VS REAL
- Tarefas no caminho crítico: estado?
- Folgas a esgotar?
- Buffer ainda disponível?

ORÇAMENTO
- Horas planeadas vs reais:
- Custos fixos pagos:
- % usado:

COMUNICAÇÃO
- Status report enviado?
- Stand-ups ocorrem?
- Cliente actualizado?

QUALIDADE
- Reviews realizados?
- Bugs abertos / fechados:
- Checklist de DoD a cumprir?

RISCO
- Riscos novos?
- Riscos agravados?
- Mitigações activas?

PRÓXIMO PERÍODO
- Top 3 prioridades:

Apêndice B · Estrutura típica de defesa (15 min)

Apêndice C · Recursos

• Conventional Commits — conventionalcommits.org
• GitHub Flow — docs.github.com/en/get-started/quickstart/github-flow
• Lighthouse — developer.chrome.com/docs/lighthouse
• Playwright — playwright.dev (E2E web)
• Loom — gravar handover/manuais
• PMI PMBOK — referência clássica
• Atlassian Agile — atlassian.com/agile
• Templates de contrato, status report, lessons learned no repositório da UC.