Gestão de projeto🔗

Um projeto de porte médio, acompanhado do início ao fim. O exemplo é a migração de um sistema para outro banco de dados, mas a estrutura serve para qualquer coisa.

Passo 1 — a raiz define o escopo🔗

Migração para PostgreSQL — entrega até 2026-11-30

A raiz é um entregável com data, não uma categoria. Isso importa: uma raiz chamada Banco de dados produz um mapa que nunca termina.

Passo 2 — a estrutura de primeiro nível🔗

Seis ramos, no máximo sete:

├── Escopo
├── Fases
├── Riscos
├── Equipe
├── Orçamento
└── Registro

Escopo guarda o que está dentro e — mais importante — o que está fora. Um ramo Fora do escopo com cinco itens evita metade das discussões futuras.

Registro guarda as decisões com data e justificativa. É o que você vai reler em seis meses.

Passo 3 — os atributos🔗

Registre em Gerenciar atributos do mapa:

Restringir responsável e estado é o que faz os filtros funcionarem seis meses depois.

Ponha a visibilidade em Ver → Atributos → Só do nó selecionado — o mapa fica limpo e os dados aparecem sob demanda.

Passo 4 — as fases e tarefas🔗

Fases
├── 1. Preparação
│   ├── Levantar esquema atual      responsável: Ana   prazo: 2026-08-15  estimativa: 16
│   ├── Mapear incompatibilidades   responsável: Bruno prazo: 2026-08-22  estimativa: 24
│   └── Definir estratégia de corte responsável: Ana   prazo: 2026-08-29  estimativa: 8
├── 2. Migração de dados
│   ├── Escrever scripts de ETL     responsável: Bruno prazo: 2026-09-20  estimativa: 60
│   ├── Testar em cópia             responsável: Carla prazo: 2026-10-04  estimativa: 40
│   └── Validar integridade         responsável: Carla prazo: 2026-10-11  estimativa: 24
├── 3. Adaptação da aplicação
└── 4. Corte e monitoramento

Numere as fases no texto. A ordenação alfabética passa a coincidir com a ordem real, o que ajuda em exportações e scripts.

Passo 5 — os estilos condicionais🔗

Em Formatar → Gerenciar estilos → Estilos condicionais do mapa, nesta ordem:

A ordem é essencial: concluída precisa vir antes de prazo vencido, ou tarefas prontas aparecem como atrasadas.

A partir daqui o mapa se formata sozinho. Você muda o estado de uma tarefa e a aparência acompanha.

Passo 6 — as fórmulas de acompanhamento🔗

Em cada fase, os atributos:

// horas
=node.children.sum { it['estimativa'].num0 }

// concluído
=def t = node.children.size()
 def d = node.children.count { it['estado'] == 'concluída' }
 t ? "${(d*100/t).round()}% (${d}/${t})" : '—'

// bloqueadas
=node.children.count { it['estado'] == 'bloqueada' } ?: ''

Na raiz de Fases, as mesmas fórmulas sobre node.branch.

No ramo Orçamento, a soma hierárquica descrita em Soma de custos.

Passo 7 — as vistas🔗

Cinco filtros salvos, que são o painel de controle do projeto:

Com “mostrar ancestrais” ligado, cada um mostra o resultado no contexto da fase a que pertence.

Sem responsável é o filtro que mais rende: tarefa sem dono não acontece, e o mapa denuncia.

Passo 8 — o ritual semanal🔗

1. Ctrl+O no mapa, Ferramentas → Atualizar fórmulas.
2. Filtro Bloqueios — o que precisa de decisão.
3. Filtro Vence em 7 dias — o que precisa de atenção.
4. Atualize estado das tarefas mexidas na semana.
5. Filtro Sem responsável — atribua ou remova.
6. Anote no Registro o que foi decidido.
7. Ctrl+S, git commit -m "semana 12".

O commit semanal transforma o mapa num histórico do projeto. git log -p conta a evolução melhor que qualquer relatório.

Passo 9 — comunicando🔗

Onde o Freeplane não é a ferramenta🔗

Vale ser honesto sobre os limites:

O Freeplane brilha na fase em que o escopo ainda está sendo entendido — onde a estrutura muda toda semana e nenhuma ferramenta rígida acompanha. Quando o plano estabiliza e o que importa é cronograma e alocação, exporte e mude de ferramenta.

Muitos projetos nunca chegam a essa fase, e o mapa basta do começo ao fim.

Referências🔗

1. Freeplane — Mind map examples
2. Freeplane — Formulas
3. Freeplane — Conditional node styles