Implementar um projeto multimédia

Há um pacote premium desta unidade: um PowerPoint editável de 100 ou mais diapositivos, um manual em PDF e dois testes com correção. Esta sebenta continua gratuita.

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.