Gerir um projeto multimédia

Introdução

Gerir projeto não é o que se vê — é o que garante que o que se vê acontece. Esta UC introduz o vocabulário e as práticas de gestão de projeto aplicados ao contexto multimédia: agência, freelance, estúdio.

O foco não é PMP / PMI académico, mas o que realmente usas para entregar um site, um vídeo institucional, uma campanha ou uma experiência interactiva sem desastres.

1. O que é gestão de projeto

1.1 Definição prática

Projeto = esforço temporário com início e fim, para criar produto/serviço único. Por oposição a operação (trabalho repetitivo contínuo).

Gestão de projeto = aplicar conhecimentos, ferramentas e técnicas para que o projecto entregue âmbito + prazo + qualidade + orçamento prometidos.

1.2 Triângulo de ferro (e qualidade)

        QUALIDADE
           ▲
           │
      ┌────┼────┐
     ╱     │     ╲
    ╱      │      ╲
   ╱       │       ╲
  PRAZO ───┴───── ORÇAMENTO/SCOPE

Os 4 eixos lutam entre si. Apertar prazo sem mexer em mais nada degrada qualidade. Apertar orçamento sem mexer em mais nada reduz scope.

Regra prática: com o cliente, define qual é fixo (prazo para evento; orçamento para concurso; qualidade para marca; scope para regulação). Os outros podem ceder.

1.3 Fases (PMI clássico)

1. Iniciação — viabilidade, alinhamento, kick-off, contrato.
2. Planeamento — scope, prazos, orçamento, equipa, risco, comunicação.
3. Execução — produzir.
4. Monitorização/Controlo — medir vs plano, corrigir, gerir mudanças.
5. Encerramento — entregar, lessons learned, arquivar.

Em metodologias ágeis, estas fases existem mas misturam-se em sprints iterativos.

1.4 Cascata vs ágil

• Cascata (waterfall) — fases sequenciais; bom para projetos com requisitos estáveis (vídeo institucional, brochura).
• Ágil (Scrum, Kanban) — entregas curtas iterativas; bom para produtos digitais que evoluem (site, app, jogo).

A maior parte das agências usa híbrido — cascata na estrutura macro, ágil no dia-a-dia.

2. Briefing e descoberta

2.1 O briefing

Documento curto que captura o que vai ser feito e porquê. Estrutura típica:

• Cliente + contexto — quem, sector, marca.
• Problema/oportunidade — o que motiva o projecto.
• Audiência — quem vai usar/ver/comprar.
• Objectivos — mensuráveis (vendas, awareness, leads, ...).
• KPI — como vamos medir sucesso.
• Tom + estilo — referências, exemplos.
• Mandatórios — logo, claim, legal.
• Restrições — formato, prazo, orçamento, plataformas.
• Stakeholders + decisores — quem aprova.

2.2 Perguntas críticas

Antes de orçamentar, fazer 5-7 perguntas:

1. Porquê agora? (Urgência real ou wishful thinking?)
2. Como vais medir sucesso? (Sem definir, está condenado.)
3. Quem decide? (Comité de 6 paralisa.)
4. O que NÃO é para fazer? (Tão importante quanto o que é.)
5. Que aprovações já existem? (Legal, branding, IT.)
6. Que projetos passados gostas / não gostas?
7. Onde está o conteúdo? (Texto/foto/vídeo já existe?)

2.3 Briefing criativo (peça)

Para cada peça (vídeo, site, key visual), um briefing curto (1 página):

Cliente
Projecto
Objectivo (1 frase)
Audiência (perfil curto)
Mensagem-chave (1 frase memorável)
Tom + estilo (3-5 refs)
Mandatórios (logo, claim, legal)
Restrições (formato, duração, plataforma)
Entregáveis
Prazos-chave (rough cut, final cut, entrega)

3. Scope e priorização

3.1 MoSCoW

Coloca cada feature/entregável num balde:

• Must have — sem isto, projecto falha.
• Should have — importante, mas projecto sobrevive sem.
• Could have — nice-to-have.
• Won't have (this time) — explicitamente fora.

Cliente decide entre Must e Should quando há trade-offs.

3.2 Definition of Done

Para cada entregável: o que significa "pronto"?

Ex.: "Site v1 pronto" = - Todas as páginas no menu principal funcionam. - Lighthouse ≥ 90 em Performance, A11y, SEO. - Form de contacto envia email. - Funciona em iOS Safari, Chrome, Firefox. - Aprovado pelo cliente.

Sem isto, debate eterno sobre "está pronto ou não?".

3.3 Scope creep

Scope creep = pedidos pequenos que se vão somando, sem renegociar prazo/orçamento. Sinais:

• "Já agora, só uma coisinha..."
• "Tens 5 minutos para mudar X?"
• "Achei que já estava incluído..."

Defesa: change request formal.

1. Cliente pede mudança.
2. PM avalia impacto (horas, prazo, custo).
3. PM apresenta opções (incluir + custo extra, trocar por outra coisa, adiar para fase 2).
4. Cliente decide antes de qualquer trabalho começar.

Por escrito, sempre.

4. Plano de projeto

4.1 WBS — Work Breakdown Structure

Decompor em pacotes de trabalho progressivamente menores.

Website
├─ 1. Design
│  ├─ 1.1 Wireframes
│  ├─ 1.2 Visual design
│  └─ 1.3 Sistema de componentes
├─ 2. Conteúdo
│  ├─ 2.1 Copy
│  ├─ 2.2 Fotografia
│  └─ 2.3 Vídeo
├─ 3. Dev
│  ├─ 3.1 Setup + repos
│  ├─ 3.2 Frontend
│  ├─ 3.3 CMS / backend
│  └─ 3.4 Integrações
└─ 4. Lançamento
   ├─ 4.1 QA + ajustes
   ├─ 4.2 Deploy
   ├─ 4.3 Treino do cliente
   └─ 4.4 Documentação

Cada folha = pacote de trabalho estimável em horas.

4.2 Estimar tempo

• Analogia — projeto parecido demorou X.
• 3 pontos — Otimista, Provável, Pessimista. Estimativa = (O + 4P + Pe) / 6. Reduz vieses.
• Planning poker (ágil) — equipa estima junta com cartas de Fibonacci (1, 2, 3, 5, 8, 13).

Para buffer: 20-50% acima da estimativa otimista. Multimédia tem muito retrabalho criativo.

4.3 Gantt

Visualização tempo × tarefas com dependências:

        Sem 1   Sem 2   Sem 3   Sem 4   Sem 5
Brief   ▓▓
Design     ▓▓▓▓▓▓
Conteúdo   ▓▓▓▓▓▓
Dev          ▓▓▓▓▓▓▓▓▓▓
QA                       ▓▓▓
Deploy                       ▓
Treino                         ▓

Ferramentas: Asana, ClickUp, Notion timeline, TeamGantt, GanttPRO, MS Project.

4.4 Caminho crítico

Sequência de tarefas dependentes que define a duração mínima do projecto. Atraso aqui = atraso no projecto inteiro. Identifica-o e protege-o com buffer.

Tarefas fora do caminho crítico têm folga — podem atrasar dentro de limites sem afetar prazo final.

4.5 Marcos (milestones)

Pontos-chave sem duração — usados para sincronizar e pagar:

• Kick-off.
• Design aprovado.
• Alpha pronta.
• Beta entregue.
• Go-live.
• Encerramento.

Tipicamente pagamento em 3 tranches: 30% kick-off, 40% design aprovado, 30% go-live. Reduz risco de não receber.

5. Equipa e papéis

5.1 Papéis numa agência multimédia

• Account / Project Manager — interface com cliente, plano, orçamento.
• Creative director / Designer lead — visão criativa.
• UX/UI Designer — estrutura e visual de produtos digitais.
• Designer gráfico — peças visuais.
• Copywriter — texto.
• Frontend / Fullstack dev.
• Producer audio/video — captura/edição.
• Animador / motion designer.
• QA tester.

Numa equipa de 2-3 pessoas, vários chapéus por pessoa. Saber qual chapéu se tem em cada momento é gestão.

5.2 RACI

Para cada tarefa importante:

• Responsável — quem faz.
• Aprovador — quem assina (sempre um único).
• Consultado — input antes da decisão.
• Informado — notificado depois.

Evita "achei que era ele a fazer" e "ninguém me disse".

5.3 Stand-ups

Reuniões curtas (10-15 min) regulares (diárias ou 3×semana): - O que fiz desde a última. - O que vou fazer hoje/até à próxima. - Bloqueios — onde preciso de ajuda.

Não é status report. É alinhar e desbloquear. Sem isto, problemas escondem-se até serem grandes.

5.4 Ferramentas

Regra: poucas ferramentas, bem usadas. Mudar a meio do projeto = caos.

6. Orçamento

6.1 Componentes

• Horas × custo/hora (€/h) por papel.
• Licenças (Adobe CC, Figma, plugins, stock photo/music).
• Hosting / infra (servidor, domínio, CDN).
• Subcontratação (locução, fotografia, tradução, ilustração).
• Imprevistos / contingência (10-20%).
• Margem (lucro da agência, 30-50%).

6.2 Day rate / hourly rate (Portugal, 2026)

Ordens de grandeza (variáveis por experiência e cidade):

Fixed-price contratos: somar tudo + buffer + margem.

6.3 Fórmula prática

Horas estimadas × rate × pessoas
+ Custos fixos (licenças, hosting, stock)
+ Subcontratação
+ Contingência (15-20%)
+ Margem (30-50%)
= Preço para cliente

Underestimar = trabalhar de graça. Overestimar = perder concurso.

6.4 Cobrar valor, não horas

Para clientes maduros, evitar "10 horas a 50€". Apresentar valor: "Site institucional completo, lançado, em 6 semanas" → 5500€. Cliente compra resultado, não input.

7. Risco

7.1 Risk register

Tabela com riscos:

Concentrar atenção nos P×I mais altos. Rever a cada milestone.

7.2 Tipos comuns de risco em multimédia

• Aprovações lentas — clientes com 5 stakeholders.
• Conteúdo em falta — fotos não tiradas, copy em "vou enviar".
• Mudanças tardias — "mudei de ideias" no fim.
• Dependências externas — API de terceiros, fornecedor.
• Doença/saída de pessoa-chave.
• Tecnologia nova — primeira vez sempre demora mais.

7.3 Contratos

O contrato mitiga risco: - Scope descrito (e o que não está incluído). - Prazos com responsabilidades de ambos. - Pagamentos por marcos. - Aprovações com prazos de resposta. - Change requests — como se gerem. - Propriedade intelectual. - Confidencialidade. - Resolução de disputas.

Modelos: Docracy, AND.CO, ou advogado próprio.

8. Comunicação

8.1 Princípios

1. Comunicar mau cedo > comunicar tarde. Surpresa = falha.
2. Por escrito o que importa. Conversas decisivas resumidas em email.
3. Frequência regular > sporádica. Cliente expecta saber estado.
4. Linguagem do cliente — sem jargão.
5. Uma fonte de verdade (Notion/Docs) onde tudo importante está.

8.2 Status report

Semanal (ou quinzenal), 1 página: - Feito desde último. - A fazer próximo período. - Bloqueios + ajuda necessária. - Decisões pendentes. - % prazo + orçamento consumidos vs plano. - Riscos novos / agravados.

8.3 Reuniões úteis

• Kick-off — alinhar visão, papéis, processo, comunicação.
• Sync semanal (15-30 min) — estado + bloqueios.
• Revisões de design / demos em milestones.
• Lessons learned no final.

Cada reunião: agenda + objetivo + decisões a tomar. Sem isso, é tempo perdido.

8.4 Apresentar trabalho

• Contextualizar (briefing → resposta).
• Mostrar direcção, não pixel-perfect.
• 2-3 opções (não 1 nem 10).
• Justificar com objectivos, não gosto pessoal.
• Convidar feedback estruturado (3 dimensões: clareza, tom, marca).

9. Encerramento

9.1 Entrega

• Dossier final — ficheiros, credenciais, manuais.
• Treino do cliente (se aplicável) — sabe usar/gerir.
• Garantia — janela de correções (30-90 dias).
• Pagamento final processado.

9.2 Lessons learned

Reunião pós-projeto (30 min, com a equipa): 1. O que correu bem? Para repetir. 2. O que correu mal? Para evitar. 3. O que faríamos diferente? Para crescer.

Documentar. Próximo projecto começa melhor preparado.

9.3 Arquivo

• Repositório versionado.
• Ficheiros-fonte em backup duplicado (3-2-1).
• Documentação final.
• Contrato + entregas + comunicações relevantes guardados.

3 anos depois, cliente pode pedir "podes recuperar X?". Saberes onde está = profissionalismo.

10. Estilo de gestão

10.1 Servant leadership

Bom PM não dá ordens — remove obstáculos para que a equipa entregue. Pergunta "o que precisas?", não "porque é que ainda não fizeste?".

10.2 Soft skills

• Comunicação clara — escrita e falada.
• Empatia — perceber clientes, equipa, fornecedores.
• Negociação — encontrar trade-offs.
• Resolução de conflitos — diferenças saudáveis vs tóxicas.
• Calma sob pressão — equipa olha para o PM em crise.

10.3 Hard skills

• Estimativa — pode-se aprender a estimar melhor com prática.
• Planeamento + Gantt + dependências.
• Orçamentação.
• Ferramentas de gestão.
• Análise de risco.
• Contratos básicos.

11. Liga a outras UCs

• UC02641 — Implementar projeto (a continuação prática).
• UC02285 / UC02199 / UC02632 — briefing, conceito, storyboard.
• UC02635 / UC02634 — entrega web/CMS.
• UC02633 — entrega vídeo.
• Mais transversal: aplica-se a todos os outros projectos.

12. Conclusão

Gestão de projeto em multimédia é parte arte (gerir pessoas, criatividade, expectativas) e parte ofício (estimar, planear, controlar). Os melhores PMs não são os mais organizados — são os que ouvem, comunicam e decidem cedo.

Para portfolio: documentar 1-2 projetos com brief, plano, orçamento, risk register e lessons learned vale tanto quanto mostrar peças finais.

Apêndice A · Modelo de plano (1 página)

PROJECTO: ____________________
CLIENTE: _______ PM: _______ DATA: _______

OBJECTIVO (1 frase)
KPI

SCOPE
- Must: ...
- Should: ...
- Won't: ...

ENTREGÁVEIS PRINCIPAIS
- ...

CRONOGRAMA
- Kick-off: dd/mm
- Design aprovado: dd/mm
- Alpha: dd/mm
- Go-live: dd/mm

EQUIPA + PAPÉIS (RACI)

ORÇAMENTO (resumo)
- Horas: X €
- Custos fixos: X €
- Contingência: X €
- Total: X €

RISCOS PRINCIPAIS (top 3)
1. ___
2. ___
3. ___

COMUNICAÇÃO
- Sync semanal: quinta 10h
- Status report: sexta
- Ferramenta: Notion

Apêndice B · Recursos

• PMI PMBOK Guide — referência clássica.
• Scrum Guide — scrumguides.org (grátis).
• Asana Academy, Notion Academy.
• Basecamp Shape Up (Ryan Singer) — alternativa interessante.
• "The Manager's Path" (Camille Fournier).
• "High Output Management" (Andy Grove) — clássico de gestão.
• AND.CO templates — contratos freelancer.