Integração: como coordenar um projeto inteiro

Ter dez pessoas competentes não garante um projeto coordenado. Cada uma pode fazer bem o seu trabalho e o projeto inteiro sair atrasado, caro ou fora do objetivo, porque ninguém uniu as decisões em um só lugar.

Já vi isso acontecer de forma explícita no nosso ERP. O time fiscal fechou uma alteração de cálculo, o time de interface ajustou a tela e o time de banco mudava a estrutura. Cada peça, correta. Na data combinada, o resultado das três partes não fechou. Alguém tinha decidido uma coisa em uma reunião, outra pessoa havia decidido o oposto em outra, e as duas decisões estavam vivas no mesmo projeto sem ninguém perceber. Quem testou a integração foi o cliente. Esse tipo de falha não vem de falta de competência técnica. Vem de ausência de coordenação.

Este é o sexto artigo da série PMBOK sem Burocracia. O índice central está em PMBOK sem Burocracia: série com 40 artigos sobre gestão de projetos.

TL;DR

• O gerenciamento da integração é a área que junta planos, mudanças, conhecimento e encerramento em um único esforço coordenado.
• O plano de gerenciamento do projeto é um documento único, dono das linhas de base, e não uma pilha de planos paralelos.
• Mudança que afeta mais de uma área de conhecimento passa por controle integrado de mudanças, com análise de impacto antes da decisão.
• Integração não acontece no final: pontos de verificação durante a execução evitam descobrir o problema no teste do cliente.
• Decisão que não fica registrada vira retrabalho: quem decide, quando decide e onde a decisão está escrita fazem parte do trabalho.
• Em ERP e software, contratos entre equipes (API, banco, interface) e critério de “pronto” com teste integrado são a forma prática de coordenar.

~ 9 min de leitura · 1613 palavras

🎧 Ouvir resumo (63) — voz gerada por IA, narração dos pontos principais do post.

🤖 Peça a uma IA resumir e discutir este texto: ChatGPT • Claude

O problema real: a integração acontecia no cliente

Volto ao caso do ERP. Três equipes trabalhavam na mesma versão. O time fiscal atendia a mudança de legislação, o time de interface queria entregar a tela nova e o time de banco precisava migrar estrutura. O cronograma de cada um fazia sentido isolado.

O problema só apareceu quando as três partes se encontraram na mesma release. O cálculo fiscal esperava um campo com outro nome. A tela usava um formato que a nova API não recebia mais. O script de banco apagava uma tabela que a tela ainda consultava. Cada equipe tinha informado as demais por mensagem informal, e cada mensagem chegou com versão diferente.

Nada de mais sofisticado resolveu isso. O que resolveu foi uma pergunta direta: quem mantém o plano do projeto inteiro? A resposta, naquele momento, era “ninguém”. Cada time mantinha o plano da sua parte. A integração, então, acontecia na cabeça de quem usava o sistema.

Conceito e importância: o que o PMBOK chama de gerenciamento da integração

No PMBOK da 6ª edição, o gerenciamento da integração é uma das dez áreas de conhecimento, e é a que coordena as outras nove. Enquanto escopo cuida do que entra, prazo cuida do quando e custo cuida de quanto, a integração cuida de como tudo isso vira um projeto único, com coerência interna.

A área cobre, na 6ª edição, seis processos: desenvolver o plano de gerenciamento do projeto, dirigir e gerenciar o trabalho, gerenciar o conhecimento do projeto, monitorar e controlar o trabalho, realizar o controle integrado de mudanças e encerrar o projeto ou fase. A 7ª edição abandonou a estrutura de processos em favor de princípios e domínios de desempenho, mas o papel permanece: alguém precisa coordenar o conjunto quando as áreas individuais já estão cuidadas.

O documento central é o plano de gerenciamento do projeto. Ele consolida os planos subsidiários (escopo, cronograma, custo, recursos, comunicação, riscos, aquisições, envolvidos, qualidade) e as linhas de base: a referência registrada contra a qual o andamento é medido. Sem esse documento como fonte única, a palavra “plano” passa a designar tantas coisas quantos times existem, e o ajuste entre eles é feito por acaso.

Um detalhe muda o comportamento do time inteiro: no controle integrado de mudanças, a análise de impacto atravessa áreas. Pedido do comercial pode mexer no escopo fiscal, que mexe no banco, que mexe na interface. A pergunta não é “o comercial aprova o pedido?”. É “quem mede o impacto dele nas demais áreas antes de aprovar?”. A 6ª edição trata essa avaliação cruzada como trabalho do gerente — não é comitê cerimonial.

Há ainda o encerramento. Encerrar projeto ou fase significa validar entrega, formalizar aceitação, arquivar o que ficou aberto e registrar as lições. Sem isso, itens abertos vazam silenciosamente para a operação, e a empresa passa a conviver com pendências não documentadas.

Aplicação prática: um plano, uma linha-base, um lugar para decidir

Transformar isso em rotina exige pouco. O que é pouco não é fácil: é disciplina.

Primeiro, escreva o plano único. Não um documento de 200 páginas. Um plano enxuto com cinco seções basta: objetivo do projeto e critério de sucesso; limites de escopo (o que entra e o que fica fora); linhas de base (escopo, cronograma e custo como foram aprovados); dependências entre as partes; cadência de acompanhamento e de decisão. Se o plano não responde a essas cinco perguntas, ele não coordena, apenas decora.

Segundo, tornar o controle de mudanças real. Toda mudança que afeta mais de uma área passa por registro com impacto calculado nas linhas de base. Mudança que afeta uma área só: o dono da área decide e registra a decisão. Sem esse limite, o controle vira fila burocrática que todos contornam pela janela do chat.

Terceiro, um diário de decisões. Data, decisão, motivo, responsável. Não é ritual: é memória. Quando dois times divergem duas semanas depois, o diário mostra o que foi decidido e por quê, e a discussão volta ao custo — em vez de recomeçar.

Quarto, pontos de verificação de integração dentro da execução. Antes do fim das sprints, o time valida o contrato de API contra o consumo real, o script de migração contra uma cópia restaurada do banco, a tela contra o dado produzido pela API. O teste de integração antecipado vale por dez reuniões de status.

Quinto, encerramento formal por fase. Aceite registrado, itens abertos listados com dono, lições anotadas. Fase encerrada sem isso deixa herança fantasma na operação.

Nenhuma dessas medidas é sofisticada. Todas dependem de uma coisa apenas: existir um lugar único onde o projeto inteiro é descrito.

Exemplo em ERP e software: a migração do Posseidom

Uso o nosso caso porque conheço os detalhes. O Posseidom começou em C# com WebForms, arquitetura legada que serviu por muitos anos e chegou ao limite. A modernização em curso segue para .NET moderno com APIs, Angular e SQL Server. Um projeto assim é um caso de integração em tempo real, porque três frentes precisam avançar juntas: o sistema novo, a operação do sistema antigo e a transição dos clientes.

O que aplicamos de gerenciamento da integração, em termos práticos:

Contrato por API, versionado. A interface que o frontend consome é um contrato escrito, com versão, e não um entendimento verbal. A equipe de backend não muda o contrato sem registrar nova versão e avisar o consumidor.

Migração de banco versionada e testada. Cada script roda contra uma cópia restaurada de um banco real do cliente antes de entrar na linha-base. O resultado esperado fica escrito: o script precisa produzir aquela saída, não “aparentemente funcionar”.

Rodagem paralela com relatório de divergência. Em cálculo fiscal, o sistema novo roda em paralelo com o antigo por um período. Um relatório compara resultado a resultado. Divergência vira item com dono, não comentário em tópico.

Registro único de mudança para pedidos que atravessam times. Cliente pede um campo novo em nota fiscal. Esse campo toca cálculo fiscal, banco de dados e tela. É um único registro de mudança com impacto por área, dono único e data. Antes, seriam três conversas paralelas e uma incompatibilidade descoberta pelo QA — ou pelo cliente.

Critério de pronto que inclui integração. Uma funcionalidade só entra como entregue quando passa teste integrado com dado real, e não apenas teste unitário da peça isolada. Essa regra de encerramento por sprint é um pedaço de “encerrar projeto ou fase” aplicado no nível correto.

O efeito é concreto: menos surpresa em produção e um ritmo de release previsível. O ganho não vem de cerimônia maior. Vem de decisões concentradas em um lugar e testadas cedo.

Erros frequentes e como evitá-los

Plano escrito para arquivar. O plano único que ninguém consulta só cria a ilusão de coordenação. Correção: plano enxuto, mantido vivo, citado nas decisões.

Controle de mudanças como carimbo. Aprovada sem impacto calculado, a mudança passa e o comitê vira decoração; as áreas criam controle paralelo. Correção: entrada de impacto (escopo, prazo, custo, áreas afetadas) obrigatória antes da aprovação, com dono único da decisão.

Integração só no final. Descobrir no dia da entrega que o cálculo fiscal não fala com a tela é o erro mais comum e o mais caro. Correção: pontos de verificação dentro da execução, com contrato de API e migração testados antes do marco.

Coordenação por conversa informal. Decisões em corredor e no chat não sobrevivem ao fim da semana. Correção: diário de decisões com responsável e data; decisão não registrada não é decisão.

Encerramento ignorado. Sem aceite formal e lista de itens abertos, o projeto “termina” e a operação herda pendências sem dono. Correção: checklist de encerramento por fase, registrado junto ao plano.

Achar que a ferramenta integra. O sistema de gestão registra; a coordenação acontece entre pessoas. Ferramenta sem plano único é arquivo bonito de fragmentos.

Eu já entreguei sistemas com esses erros. Quem os repete devolve ao cliente o papel de teste de integração.

Reflexão final e próxima ação

O gerenciamento da integração é a diferença entre possuir várias entregas e possuir um produto. As outras áreas cuidam de partes; a integração responde pela soma. É também a área mais invisível: quando funciona, quase ninguém nota; quando falta, todos notam — normalmente no cliente.

A próxima ação é verificável: pegue um projeto ativo e responda três perguntas por escrito. Onde está o plano único, com data e dono? Qual é a linha-base vigente de escopo, prazo e custo? O que exatamente acontece hoje com uma mudança que afeta duas equipes? Se alguma resposta não couber em dois parágrafos, você não tem integração — tem boa vontade distribuída.

É assim que eu uso o PMBOK: não como coleção de rótulos, mas como lembrete de que alguém precisa manter o todo coerente enquanto as partes correm. Integração não é burocracia que atrasa. É a ordem interna que impede o projeto de se despedaçar por dentro.

Leitura relacionada

• PMBOK sem Burocracia: série com 40 artigos sobre gestão de projetos — o índice central, com a agenda completa da série.
• O que é PMBOK e por que todo profissional deveria conhecê-lo — a abertura da série, com o contexto do manual da PMI.
• Os cinco grupos de processos do PMBOK — iniciação, planejamento, execução, controle e encerramento, o esqueleto por fase.

A série continua no próximo artigo com o termo de abertura e o controle integrado de mudanças: por que um projeto nasce com contrato de meia página — e não com uma tarefa.