Guia de Equipa — Gestão de Tarefas no Zoho Projects

Projeto: Savoy Signature Hotels — Websites
Data: 2026-03-21
Versão: 1.0
Responsável: Rui Rosa (Tech Lead)

Este guia explica como funciona o nosso processo de desenvolvimento e como cada membro da equipa interage com o Zoho Projects.

Nota do Tech Lead

Olá equipa,

Este documento descreve o processo de gestão de tarefas que estou a implementar para o projeto Savoy Signature Hotels. O objetivo é dar visibilidade total a toda a equipa sobre o estado de cada tarefa, quem precisa de agir, e onde estão os pontos de espera.

O desenvolvimento deste projeto está a ser feito com recurso intensivo a inteligência artificial (Claude Code), o que nos permite uma velocidade de execução muito superior ao habitual. Mas esta velocidade só se traduz em resultados se as revisões e validações humanas acompanharem o ritmo. Este processo foi desenhado para tornar isso claro e mensurável.

Side note: chegar a este ponto não foi simplesmente “ligar a IA e deixar trabalhar”. Foram muitas horas de trabalho, muita experimentação, muitos recomeços e — confesso — alguns cabelos brancos pelo caminho. Houve processos inteiros que tiveram de ser repensados do zero, regras que foram escritas e reescritas dezenas de vezes, e muitas iterações até o Claude produzir resultados com a qualidade que exigimos. A inteligência artificial é uma ferramenta extraordinariamente poderosa, mas requer um investimento real de tempo, conhecimento e paciência para ser bem utilizada. O resultado que veem hoje — com documentação estruturada, testes automáticos exaustivos e um pipeline de qualidade robusto — é fruto desse investimento. E estou convicto de que vai valer a pena: este é o nosso projeto piloto para um novo modo de trabalhar que, se correr bem, vai elevar substancialmente a qualidade e a eficiência de todos os nossos processos futuros.

Este é um processo vivo — vamos ajustá-lo e melhorá-lo à medida que avançamos. Se sentirem que algo não funciona bem, que falta algum passo, ou que alguma coisa pode ser simplificada, falem comigo. O objetivo é que isto nos ajude, não que nos atrase.

Todo o projeto tem uma documentação técnica completa (PRD) que pode ser consultada em docs/PRD/. São 22 documentos que cobrem desde a arquitetura geral até à segurança, passando pelos módulos, API, design system, testes e performance. Este guia que estão a ler é o documento 22a — a versão simplificada do documento 22 (Project Management & Zoho), escrita especificamente para a equipa.

— Rui Rosa

1. Visão Geral

O desenvolvimento dos websites Savoy é feito maioritariamente por Claude Code, um agente de inteligência artificial que programa de forma autónoma. O Claude cria código, abre Pull Requests (PRs) e faz deploy — tudo automaticamente.

O papel das pessoas é supervisionar, validar e aprovar. Cada equipa tem momentos específicos em que precisa de agir. Este guia explica quando e como.

Como funciona o ciclo de uma tarefa

Em resumo: o Claude desenvolve, e depois a tarefa passa por 3 equipas humanas — cada uma valida a sua área. Só quando as 3 aprovam é que a tarefa está concluída.

2. O que o Claude testa antes de entregar

Uma preocupação natural é: “Mas será que o que o Claude entrega está realmente bem feito?”

A resposta curta é: sim, porque passa por uma bateria exaustiva de testes automáticos antes de chegar às vossas mãos. Quando uma tarefa sai do estado “In Development” e entra na fila de revisão, já foi validada em múltiplas dimensões. Vejamos em detalhe o que acontece internamente:

Fases internas do Claude (dentro de “In Development”)

O que cada teste verifica

Tipo de teste	O que verifica	Exemplo
Testes unitários	A lógica do componente funciona corretamente	”Se não há título, o componente não mostra a secção de título”
Testes visuais (Pixel Perfect)	O resultado visual corresponde ao Figma	Compara screenshots automáticos com o design original, pixel a pixel
Testes de renderização	O componente aparece sem erros	”O componente renderiza sem crashar com dados mínimos”
Verificação de acessibilidade	O HTML é semântico e acessível	Uso correto de headings (h1, h2, h3), textos alternativos em imagens, navegação por teclado
Verificação de responsividade	Funciona em todos os tamanhos de ecrã	De 375px (mobile) a 1440px (desktop) sem quebras de layout
Verificação de temas	Funciona nos 8 temas dos hotéis	Cores, fontes e espaçamentos adaptam-se a cada hotel
Verificação TypeScript	Não há erros de tipo no código	Garante que os dados são do tipo correto (texto onde é texto, número onde é número)
Verificação de qualidade	O código segue as regras do projeto	Indentação, nomes de variáveis, organização de ficheiros
Teste CMS	O conteúdo do Umbraco mapeia corretamente	Os dados inseridos no backoffice aparecem corretamente no site

O que isto significa para vocês

Quando recebem uma tarefa para revisão, podem ter confiança de que:

O componente não vai crashar — foi testado com dados completos, mínimos e vazios
O visual está próximo do Figma — foi comparado automaticamente com diferença máxima de 5% (desktop) e 10% (mobile)
O HTML é semântico e acessível — headings corretos, imagens com texto alternativo
Funciona em todos os tamanhos de ecrã — de mobile a desktop, sem conteúdo cortado
Funciona nos 8 temas dos hotéis — cores e fontes adaptam-se
O CMS está integrado — os dados do Umbraco mapeiam corretamente

O que vão encontrar e reportar são tipicamente:

Nuances visuais difíceis de captar automaticamente (alinhamentos subtis, espaçamentos em edge cases muito específicos)
Animações e transições que não são testáveis de forma automática
Comportamentos de interação complexos (gestos, scroll, hover states em contextos específicos)
Diferenças entre o Figma e o que faz sentido no browser (o Figma é estático; o site é dinâmico)
Problemas com conteúdo real muito específico (texto em PT com acentos longos, nomes de hotel muito grandes, etc.)

Isto é exactamente o valor que as pessoas acrescentam — o olho humano para os detalhes que a máquina não consegue avaliar.

3. Os Estados da Tarefa (o que significam)

Cada tarefa no Zoho passa por vários estados. O estado indica onde a tarefa está no processo e quem precisa de agir.

Mapa Visual

Tabela de Estados

#	Estado	O que significa	Quem precisa de agir
1	Backlog	Trabalho identificado mas ainda não planeado	Ninguém — está na lista para o futuro
2	To Do	Priorizado e pronto para ser desenvolvido	Ninguém — o Claude vai pegar nisto
3	In Development	O Claude está a programar ativamente	Ninguém — deixar o Claude trabalhar
4	Awaiting Input	O Claude precisa de uma decisão ou informação de alguém	A pessoa indicada no comentário — responder para desbloquear
5	Dev — Ready for Review	O código está pronto, na fila para revisão técnica	Tech Lead (Rui) — rever o código quando possível
6	Dev — In Review	O Tech Lead está a rever o código	Tech Lead (Rui) — aprovar ou pedir alterações
7	Design — Ready for Review	O código foi aprovado tecnicamente, na fila para validação visual	Design (Liliana, João) — pegar na revisão
8	Design — In Review	A equipa de Design está a validar o visual contra o Figma	Design (Liliana, João) — aprovar ou reportar problemas
9	QA — Ready for Acceptance	O Design aprovou, está deployed em DEV para testar	QA/PM (Gabriela, Michelle) — testar no ambiente DEV
10	QA — In Acceptance	A equipa QA está a testar no ambiente DEV	QA/PM (Gabriela, Michelle) — aceitar ou reportar bugs
11	QA — Accepted	O QA passou, à espera de aprovação final	PO ou Tech Lead — dar o OK final
12	Done	Tarefa concluída e fechada	Ninguém — está feita
99	Dropped	Tarefa cancelada ou abandonada	Ninguém

4. Colunas “Ready” vs “In” — Porquê?

Repararam que cada revisão tem duas colunas: “Ready for…” e “In…”. Isto é propositado.

Coluna	Cor (clara)	Significa
Ready for…	Clara (azul claro, rosa claro, verde claro)	A tarefa está à espera que alguém a pegue. Ninguém está a trabalhar nela.
In…	Escura (azul, rosa, verde)	Alguém está ativamente a trabalhar nela.

Porquê esta separação?

Permite medir quanto tempo as tarefas ficam à espera vs quanto tempo demora a fazer a revisão. Se as tarefas acumularem na coluna “Ready”, significa que a equipa correspondente precisa de dar prioridade às revisões.

Exemplo:
   5 tarefas em "Design — Ready for Review"  →  A equipa de Design tem trabalho à espera
   0 tarefas em "Design — In Review"          →  Ninguém pegou ainda nas revisões

   Acção: Liliana ou João devem iniciar as revisões de Design

5. O que cada equipa deve fazer

5.1 Tech Lead (Rui)

Quando agir: Quando há tarefas em 5. Dev — Ready for Review

O que fazer:

Abrir a tarefa no Zoho e ler o comentário do Claude com os detalhes do PR
Mover o estado para 6. Dev — In Review (para todos saberem que estás a rever)
Abrir o PR no Azure DevOps e rever o código
Se aprovado: Mover para 7. Design — Ready for Review
Se precisar de alterações: Mover para 3. In Development e deixar comentário com o que precisa de mudar

Também verificar diariamente:

4. Awaiting Input — o Claude pode estar bloqueado à tua espera

5.2 Equipa de Design (Liliana, João)

Quando agir: Quando há tarefas em 7. Design — Ready for Review

O que fazer:

Abrir a tarefa no Zoho e ler o comentário “Design Review Handoff” — este comentário tem tudo o que precisam:
- Links para o Figma (desktop e mobile)
- Links para o Storybook (componente isolado)
- Links para o site DEV (componente em contexto real)
- Link para o CMS Umbraco
- Lista de critérios de aceitação
- Resultados dos testes visuais automáticos
Mover o estado para 8. Design — In Review
Validar no Storybook (componente isolado):
- Abrir o link do Storybook fornecido no comentário
- Comparar com o Figma desktop e mobile
- Testar em pelo menos 3 temas diferentes (usar o seletor de temas no Storybook)
- Verificar responsividade nos tamanhos: 375px, 768px, 1024px, 1440px
Validar no site DEV (componente em contexto):
- Abrir o link do DEV site fornecido no comentário
- Verificar como o módulo aparece numa página real, com conteúdo real
Preencher os critérios de aceitação do comentário (marcar os que passam)
Deixar um comentário na tarefa com o resultado:
- Se aprovado: “Design aprovado. Todos os critérios de aceitação passam.”
- Se tem problemas: Descrever exactamente o que está errado, com screenshots se possível
Mover o estado:
- Se aprovado: 9. QA — Ready for Acceptance
- Se tem problemas: 3. In Development (o Claude vai corrigir e voltar a submeter)

Dicas importantes:

O comentário “Design Review Handoff” é o vosso guia — leiam-no com atenção
Se algo não está claro, deixem um comentário na tarefa a perguntar
Não precisam de ver código — foquem-se no resultado visual

5.3 Equipa QA / PM (Gabriela, Michelle)

Quando agir: Quando há tarefas em 9. QA — Ready for Acceptance

O que fazer:

Abrir a tarefa no Zoho e ler os comentários anteriores para contexto
Mover o estado para 10. QA — In Acceptance
Testar no site DEV com conteúdo real do CMS:
- Abrir o Umbraco CMS → navegar à página com o módulo
- Verificar que o conteúdo aparece correctamente
- Testar com conteúdo diferente (textos longos, textos curtos, campos vazios)
- Verificar que desligar o módulo (toggle “Active” = OFF) o esconde completamente
- Testar em pelo menos 2 hotéis diferentes
Deixar um comentário com o resultado dos testes
Mover o estado:
- Se tudo OK: 11. QA — Accepted
- Se encontraram bugs: 3. In Development (descrever os bugs no comentário)

5.4 PO / Tech Lead (fecho de tarefa)

Quando agir: Quando há tarefas em 11. QA — Accepted

O que fazer:

Confirmar que a tarefa está realmente completa (QA passou, Design aprovou, código aprovado)
Mover para 12. Done

Este é o último passo — a tarefa está oficialmente concluída.

6. O que fazer quando a tarefa volta para trás

Por vezes, uma tarefa vai voltar ao estado “3. In Development”. Isto acontece quando:

Quem devolve	Porquê	O que acontece
Tech Lead (do estado 6)	O código precisa de alterações	O Claude corrige e volta a submeter
Design (do estado 8)	O visual não corresponde ao Figma	O Claude ajusta o CSS/layout e volta a submeter
QA (do estado 10)	Foram encontrados bugs	O Claude corrige e volta a submeter

Isto é normal e esperado. O Claude corrige o que for necessário e a tarefa volta a avançar pelo processo.

Quando devolvem uma tarefa, é muito importante:

Deixar um comentário claro na tarefa a explicar o que está errado
Ser específico — “O espaçamento entre o título e o texto está errado no mobile” é muito melhor do que “Está mal”
Incluir screenshots quando possível

7. Módulos sem Figma finalizado

Alguns módulos vão ser desenvolvidos antes do design em Figma estar finalizado. Isto é normal no nosso fluxo — o Claude consegue avançar com a parte técnica enquanto o design é finalizado.

Como funciona

O que muda para a equipa:

Na primeira passagem, o Design valida o que é possível (estrutura, responsividade, interações)
Na segunda passagem, o Design faz a validação pixel-perfect completa contra o Figma final
A tarefa vai aparecer duas vezes no pipeline de revisão — isto é esperado

Tags visuais no Zoho

Cada tarefa tem uma tag que indica o estado do Figma:

Tag	Significado	O que a equipa de Design faz
`design:none`	Não existe Figma para este módulo	Validar estrutura e responsividade apenas
`design:draft`	Existe Figma, mas não é a versão final	Validar contra o draft; reportar diferenças óbvias
`design:final`	Figma aprovado pelo cliente	Validação completa pixel-perfect — esta é a que conta
`design:revised`	Figma foi alterado após desenvolvimento	Claude vai ajustar; Design re-valida as alterações

8. O Quadro Kanban do Zoho

O quadro do Zoho mostra todas as tarefas organizadas por estado. Cada coluna corresponde a um estado.

┌─────────┬────────┬──────────┬──────────┬───────────┬───────────┬────────────┬────────────┬────────────┬────────────┬────────────┬──────┐
│ Backlog │ To Do  │  In Dev  │ Awaiting │Dev—Ready  │Dev—In     │Design—Ready│Design—In   │ QA—Ready   │ QA—In      │QA—Accepted │ Done │
│         │        │          │  Input   │for Review │Review     │for Review  │Review      │for Accept. │Acceptance  │            │      │
│         │        │          │          │           │           │            │            │            │            │            │      │
│ futuro  │ fila   │ CLAUDE   │ ALGUÉM   │ fila→Rui  │ RUI       │fila→Design │ DESIGN     │ fila→QA    │ QA/PM      │fila→PO/TL  │  ✓   │
│         │        │(a prog.) │(responda)│           │(a rever)  │            │(a validar) │            │(a testar)  │            │      │
│         │        │          │          │           │           │            │            │            │            │            │      │
│  cinza  │  azul  │ roxo     │ laranja  │azul claro │ azul      │ rosa claro │ rosa       │verde claro │ verde      │verde escuro│verde │
└─────────┴────────┴──────────┴──────────┴───────────┴───────────┴────────────┴────────────┴────────────┴────────────┴────────────┴──────┘

Como ler o quadro

O que vejo	O que significa	O que fazer
Muitas tarefas em “Awaiting Input”	O Claude está bloqueado à espera de respostas	Verificar os comentários e responder
Muitas tarefas em “Dev — Ready for Review”	Há PRs à espera de revisão de código	Rui deve agendar tempo para revisão
Muitas tarefas em “Design — Ready for Review”	Há trabalho validado tecnicamente à espera da equipa de Design	Liliana/João devem pegar nas revisões
Muitas tarefas em “QA — Ready for Acceptance”	Há funcionalidades deployed à espera de teste	Gabriela/Michelle devem testar no DEV
Muitas tarefas em “QA — Accepted”	Tudo testado mas não fechado oficialmente	PO/Tech Lead devem fechar as tarefas
Nenhuma tarefa em “To Do”	O Claude não tem trabalho	Mover tarefas do Backlog para To Do

9. Comentários no Zoho — O que esperar

O Claude deixa comentários estruturados em cada tarefa. Estes comentários são a principal forma de comunicação sobre o progresso.

Tipos de comentários que vão ver

Comentário	Quando aparece	O que contém
”Development Started”	Quando o Claude começa a trabalhar	Branch criada, âmbito do trabalho
”Phase Update”	Durante o desenvolvimento	Progresso por fase (Storybook → React → Visual → CMS)
“Awaiting Input”	Quando o Claude precisa de ajuda	O que precisa, opções disponíveis
”PR Created”	Quando o código está pronto	Link para o PR, lista de alterações, resultados dos testes
”Design Review Handoff”	Quando o código é aprovado pelo Tech Lead	O mais importante para a equipa de Design — links, critérios, screenshots
”Deployed to DEV”	Quando está no ambiente de teste	URLs para testar
”Development Pass N”	Quando a tarefa volta ao desenvolvimento	O que mudou, porquê, que fases vão ser repetidas

O comentário mais importante: “Design Review Handoff”

Este comentário é criado especificamente para a equipa de Design e contém:

Links para o Figma (desktop e mobile)
Links para o Storybook (ver o componente isolado com todos os estados)
Links para o site DEV (ver o componente numa página real)
Critérios de aceitação (checklist do que validar)
Resultados dos testes visuais automáticos (diferença percentual face ao Figma)
Notas do Claude (decisões tomadas durante o desenvolvimento, desvios do Figma com justificação)

Leiam este comentário com atenção antes de começar a revisão de Design.

10. Regras Importantes

Para todos

Quando mudam o estado de uma tarefa, deixem sempre um comentário a explicar porquê
Sejam específicos nos comentários — “O espaçamento do título está 20px em vez de 16px no mobile” é muito mais útil do que “Está mal”
Incluam screenshots quando reportam problemas visuais
Não saltem estados — sigam a ordem (5→6→7→8→9→10→11→12)

Para a equipa de Design

O Storybook tem um seletor de temas — testem sempre em pelo menos 3 temas
Usem o modo responsive do browser para testar a 375px, 768px, 1024px e 1440px
Quando há tag design:draft, reportem problemas óbvios mas tenham em conta que o Figma pode mudar
Quando há tag design:final, a validação deve ser rigorosa e pixel-perfect

Para a equipa QA

Testem sempre no site DEV com conteúdo real do CMS (não no Storybook)
Verifiquem que o toggle “Active” = OFF esconde o módulo completamente
Testem em pelo menos 2 hotéis diferentes (ex: Savoy Palace + Hotel Next)
Testem com conteúdo variado — textos longos, textos curtos, campos opcionais vazios

11. Links Úteis

Recurso	URL	Para quê
Zoho Projects	Portal wygroup	Gestão de tarefas
Storybook (DEV)	savoy-dev-storybook.wycreative.com	Ver componentes isolados
Site DEV (Signature)	savoy-dev-signature.wycreative.com	Ver site em contexto
Umbraco CMS	savoy-dev-cms.wycreative.com/umbraco	Gerir conteúdo
Azure DevOps	dev.azure.com/Bycom/Savoy Signature	Pull Requests

12. Perguntas Frequentes

P: O que é o Claude Code? R: É uma inteligência artificial que programa de forma autónoma. Cria código, testes, e faz deploy. O papel das pessoas é supervisionar e validar o resultado.

P: Preciso de saber programar para fazer a minha parte? R: Não. A equipa de Design valida o visual (comparar com Figma). A equipa QA testa funcionalidades (clicar, navegar, verificar conteúdo). O PO/PM faz o fecho. Nenhuma destas ações requer conhecimento de programação.

P: E se o Claude fez algo que não corresponde ao Figma? R: Mova a tarefa para 3. In Development e deixe um comentário detalhado com o que está errado. O Claude vai ler o comentário, corrigir, e voltar a submeter para revisão.

P: E se eu não entendo o que o Claude escreveu no comentário? R: Deixe um comentário na tarefa a perguntar. O Claude ou o Tech Lead vão responder.

P: Uma tarefa voltou para “In Development” — é normal? R: Sim, é completamente normal. Significa que algo precisa de ser ajustado. A tarefa vai voltar a passar por todo o processo de revisão.

P: Porque é que uma tarefa aparece duas vezes no processo de revisão? R: Provavelmente porque o módulo foi desenvolvido antes do Figma estar finalizado. A primeira passagem valida a estrutura; a segunda passagem (quando o Figma chega) valida o pixel-perfect.

P: Quanto tempo tenho para fazer a minha revisão? R: O ideal é:

Tech Lead (Code Review): < 8 horas
Design (Visual Review): < 24-48 horas
QA (Acceptance): < 24 horas
PO/TL (Sign-off): < 8 horas

P: O que acontece se eu não mexer na tarefa? R: Ela fica na coluna “Ready” (à espera). Quanto mais tempo ficar lá, mais atrasa o projeto. O quadro Kanban torna isto visível para toda a equipa.

13. Documentação do Projeto

Todo o projeto Savoy Signature Hotels tem uma documentação técnica completa que pode ser consultada por qualquer membro da equipa. São 22+ documentos organizados na pasta docs/PRD/, que cobrem todas as áreas do projeto:

Área	Documentos	Para quem é mais relevante
Arquitetura e infraestrutura	PRD 01, 02	Tech Lead, Devs
Multi-site e domínios	PRD 03	Toda a equipa
Frontend e design system	PRD 04, 05	Devs, Design
Modelação de conteúdo (CMS)	PRD 06	Devs, Editores
Módulos e templates	PRD 07	Toda a equipa
API e integrações	PRD 08, 19	Devs
Cache e performance	PRD 09	Devs, Tech Lead
Multi-língua	PRD 10	Toda a equipa
SEO	PRD 11	Marketing, Devs
Formulários	PRD 12	QA, Devs
Media e imagens	PRD 13	Design, Devs
Acessibilidade	PRD 14	Design, QA
Segurança	PRD 15, 21	Tech Lead, Devs
Analytics	PRD 16	Marketing, PM
A/B Testing	PRD 17	Marketing, PM
Testes e QA	PRD 18	QA, Devs
Roadmap	PRD 20	PM, PO
Gestão de tarefas (este guia)	PRD 22, 22a	Toda a equipa

O índice completo está em docs/PRD/00_Introduction_and_Index.md.

Se tiverem curiosidade ou precisarem de contexto sobre qualquer área, consultem o documento correspondente ou peçam ajuda ao Rui.

Referência técnica completa: docs/PRD/22_Project_Management_and_Zoho.md
Índice de toda a documentação: docs/PRD/00_Introduction_and_Index.md