Refinar e escalar
Iteração e cadência de releases
Um ritmo previsível para introduzir mudanças de configuração sem voltar a entrar em modo projeto. Sprint, mês ou trimestre — escolha o passo que encaixa e mantenha-o.
Atualizado em 18/05/2026
Refinar · 6.2
Porque é importante agora
Dois padrões comuns após o go-live: (1) nada muda mais (“estamos em produção, está feito”) e (2) tudo muda de forma ad hoc (cada alteração é uma crise). Ambos levam à estagnação ou ao caos. A cadência de releases é a forma de evitar os dois — mudanças pequenas, previsíveis, com os mesmos passos.
O que entrega?
Calendário de releases
Ritmo fixo (p. ex. mensal na primeira terça) com scope e janelas de freeze.
Fluxo RFC
Template de Request for Change: pedido → triagem → impacto → aprovação → release.
Estratégia de teste
Ambiente de aceitação + smoke tests por release, com sign-off de cada service owner.
Template de comunicação
O que muda, quando, para quem — release notes que os utilizadores percebem.
Três tipos de mudança — três cadências
Pequena e segura
Quando necessário
Adicionar um campo, publicar um artigo KB, mudar um template. O dono trata, regista no change register.
Média
Release mensal
Mudança de fluxo, extensão de classificação, novo relatório. Fluxo RFC, teste de aceitação, comunicação.
Grande / estrutural
Release trimestral
Ativar um novo módulo, adicionar uma integração, fazer a IA passar ao nível seguinte. Mini-projeto, decisão do comité de direção.
Perguntas-chave
- 1Que ritmo encaixa — sprint (2 semanas), mês ou trimestre para a camada "média"? Quanta mudança aguentam os utilizadores?
- 2Quem faz a triagem dos pedidos de mudança que entram? Que critérios (impacto × frequência × esforço) usa?
- 3Aprovação — que change board aprova o quê? Que mudanças pode o admin fazer sozinho, quais precisam do sponsor?
- 4Ambiente de aceitação — tem um? Como sincroniza a config de produção para o teste? Quanto tempo testa antes de ir a produção?
- 5Smoke tests por release — um conjunto mínimo de cenários que tem sempre de passar, qualquer que seja o conteúdo do release.
- 6Roll-back por alteração — sobretudo em ajustes de fluxo: consegue reverter se o comportamento der errado?
- 7Release notes — quem escreve, em que idioma, com que nível de detalhe? Para utilizadores: curto e na sua língua. Para admins: detalhe técnico.
- 8Momentos de freeze — sem mudanças durante semana de auditoria, fecho fiscal, fim de ano? Trave no calendário.
- 9Backlog — onde mora a lista de pedidos de mudança abertos? Quem prioriza, com que frequência?
- 10Atualizações do produto Gfacility — ler release notes, verificar regressões, informar utilizadores finais. Quem é dono desse ritmo?
Modelo — Ficha de RFC
| Campo | Valor de exemplo |
|---|---|
| Título | Adicionar categoria "assistente IA" ao fluxo de tickets de IT |
| Requisitante / service owner | Sara Janssen (Service manager) |
| Tipo | Média — extensão de classificação |
| Porquê | 15% dos tickets são sobre Copilot/ferramentas IA, atualmente "outros" |
| Impacto | Reporting, regra de routing IA, tags KB |
| Riscos | Tickets em "outros" precisam de ser reclassificados |
| Roll-back | Desativar a categoria — os tickets existentes mantêm o seu valor |
| Release proposto | Release mensal de novembro |
| Aprovação | CAB (service mgr, configurador, PM) — sem sponsor necessário |
Modelo — Calendário de releases
| Mês | Data do release | Freeze de/até | Foco de scope | Comunicação |
|---|---|---|---|---|
| Out | Ter 7 Out 20:00 | Sex 3 Out — Qua 8 Out 9:00 | Mudanças de fluxo IT | Release notes sex |
| Nov | Ter 4 Nov 20:00 | Sex 31 Out — Qua 5 Nov 9:00 | Extensão de classificação | Release notes sex |
| Dez | — (nenhum) | Mês inteiro | Freeze para fecho de ano | Anúncio fim de novembro |
| Jan | Ter 13 Jan 20:00 | Sex 9 Jan — Qua 14 Jan 9:00 | Release trimestral: novo dashboard | Release notes + sessão de briefing |
| … | … | … | … | … |