Essas conversas são importantes porque ajudam as pessoas a compreender o valor potencial da nova ferramenta. Mas, quando comecei a observar o que realmente precisava acontecer primeiro, percebi algo interessante. A primeira atividade da implantação era bastante simples: diferentes áreas da empresa precisavam preparar algumas planilhas e enviá-las ao responsável pela nova aplicação para que os dados fossem importados para a plataforma.

Foi nesse momento que percebi que, apesar de todas as discussões sobre tecnologia, algumas perguntas básicas de gestão de projetos continuavam sem resposta. Quem seria responsável por preparar cada planilha? Quando cada uma deveria estar pronta? Quem validaria as informações antes do envio? O fornecedor poderia começar a trabalhar com um arquivo enquanto aguardava os demais? Quanto tempo levaria a importação? Quem verificaria se os dados haviam sido carregados corretamente? E, talvez o mais importante, quem estava esperando que essas informações estivessem disponíveis na nova aplicação e até quando?

Sem essas respostas, eu conseguia compreender muitas das possibilidades que a aplicação poderia oferecer no futuro, mas ainda não tinha informações suficientes para construir um cronograma inicial confiável ou definir a primeira versão do escopo. Foi então que comecei a pensar que talvez estejamos, em algumas situações, confundindo conhecimento técnico com conhecimento sobre o próprio projeto.

Um Gerente de Projetos Precisa Ter Conhecimento Técnico?

Acredito que sim, mas talvez não da maneira como costumamos imaginar. Um gerente de projetos que trabalha com tecnologia precisa conhecer o ambiente em que atua o suficiente para acompanhar as discussões e compreender suas consequências. Se existe uma integração entre sistemas, precisamos entender o que está sendo integrado e por quê. Se uma API é necessária, precisamos compreender qual é o seu papel na solução. Se os dados precisam ser migrados, devemos saber de onde vêm essas informações, quem é responsável por elas e o que poderia impedir que a migração acontecesse conforme o planejado.

Se uma API precisa ser disponibilizada, por exemplo, preciso entender quem é responsável por essa entrega, quais atividades dependem dela, quando deverá estar disponível e o que acontecerá com o projeto caso haja um atraso. Da mesma forma, se um fornecedor precisa receber planilhas para importar dados para uma nova aplicação, preciso saber quem produzirá esses arquivos, qual formato deverá ser utilizado, quando deverão ser entregues e quem validará o resultado. Para mim, é nesse ponto que o conhecimento técnico passa a gerar valor para a gestão de projetos. O objetivo não é ser a pessoa com maior conhecimento tecnológico da reunião, mas compreender a tecnologia o suficiente para identificar suas consequências para o projeto.

Comprar um Software Não É o Mesmo que Implantá-lo

Essa diferença se torna especialmente importante quando uma empresa está comprando uma aplicação pronta, em vez de desenvolver um novo sistema. O software já existe, o fornecedor conhece o produto, o contrato pode já ter sido assinado e as licenças podem até estar pagas. Mas isso não significa que o projeto esteja próximo de terminar. Ainda é necessário definir o que será implantado primeiro, preparar os dados, revisar as configurações, coordenar as atividades com o fornecedor, preparar os usuários, organizar as integrações e estabelecer o que faz parte da implantação atual e o que ficará para uma próxima etapa.

Nesse tipo de projeto, boa parte da complexidade não está no desenvolvimento de software, mas na coordenação das atividades. O fornecedor precisa receber informações da empresa, uma equipe interna depende de outra, os usuários aguardam a disponibilidade da plataforma, a área de segurança pode precisar aprovar acessos, outro sistema pode ter que disponibilizar informações e uma área de negócio talvez precise validar os dados antes de sua utilização. Tudo isso representa dependências do projeto, mesmo quando nenhum software está sendo desenvolvido internamente.

Quando as Discussões Técnicas Começam a Afetar o Escopo do Projeto

Outro desafio aparece quando as pessoas começam a explorar tudo o que uma nova plataforma poderia fazer. Alguém comenta que a aplicação poderia ser integrada a outro sistema, outra pessoa sugere automatizar uma atividade manual e um terceiro participante pergunta se a ferramenta também poderia ser utilizada por outro departamento. Rapidamente, a conversa deixa de tratar apenas da implantação atual e começa a incorporar possibilidades futuras.

Não existe problema algum em discutir essas oportunidades. A dificuldade começa quando ninguém diferencia essas possibilidades do escopo efetivamente aprovado para o projeto. O gerente de projetos precisa compreender se determinada ideia faz parte da fase atual, se representa uma melhoria futura ou se é apenas algo tecnicamente possível. Caso contrário, o escopo acaba se transformando em um conjunto de expectativas que ninguém assumiu formalmente o compromisso de entregar.

Por isso, acredito que uma das contribuições mais importantes de um gerente de projetos em ambientes de tecnologia é transformar possibilidades em compromissos claros. Enquanto as discussões técnicas frequentemente exploram o que pode ser feito, a gestão de projetos precisa estabelecer o que será feito.

Um Cronograma de Projeto Começa Pelo Fluxo de Trabalho, Não Pelas Datas

O exemplo das planilhas também me fez refletir sobre outro ponto: um cronograma não começa pela escolha de datas, mas pela compreensão de como o trabalho precisa acontecer. Se cinco planilhas devem ser entregues, primeiro preciso entender quem preparará cada uma, se poderão ser produzidas simultaneamente, se alguma delas depende de informações de outra área, se haverá necessidade de validação e se o fornecedor precisará receber todos os arquivos antes de começar a importação.

Depois, preciso compreender o que acontecerá na sequência. O fornecedor poderá importar os dados imediatamente? Será necessária alguma configuração adicional? Quem verificará o resultado? Quando os usuários poderão começar a trabalhar com o sistema? Somente quando essa sequência estiver clara é que as datas começam a fazer sentido. Preparação dos dados, validação, envio, importação, verificação, preparação dos usuários e entrada em produção passam a ser atividades conectadas, e não apenas datas isoladas em um calendário.

Compreender essas relações também é fundamental para identificar o caminho crítico e as dependências que podem atrasar um projeto. Se uma atividade só pode começar depois da conclusão de outra, essa relação precisa estar visível antes que compromissos sejam assumidos. Sem compreender a sequência do trabalho, as datas de um cronograma acabam sendo pouco mais do que estimativas sem uma base consistente.

Conhecimento Técnico ou Fluência Tecnológica: O Que É Mais Importante para o Gerente de Projetos?

Por esse motivo, prefiro pensar em fluência tecnológica, em vez de especialização técnica, quando falamos sobre as competências de um gerente de projetos. Para mim, ter fluência tecnológica significa compreender o ambiente o suficiente para relacionar o que está sendo discutido com suas consequências para o projeto. Se uma integração exige aprovação da área de segurança, preciso reconhecer que isso pode representar uma dependência. Se o fornecedor explica que uma personalização solicitada não faz parte do produto padrão, preciso compreender que talvez estejamos introduzindo custos, escopo ou riscos adicionais. Se uma equipe não consegue fornecer determinados dados antes da validação de outro departamento, preciso enxergar não apenas uma restrição técnica, mas também uma questão de responsabilidade e prazo.

O detalhe técnico importa porque oferece o contexto necessário para a decisão de gestão. O objetivo não é dominar todos os componentes da solução, mas compreender o suficiente para identificar quando uma decisão, limitação ou dependência técnica pode afetar o projeto e o que precisa ser feito a respeito. Essa capacidade também ajuda a reconhecer os primeiros sinais de atrasos em projetos, especialmente quando restrições técnicas começam a comprometer dependências, estimativas ou previsões de entrega.

Até Que Ponto um Gerente de Programas Precisa Entender de Tecnologia?

A profundidade do conhecimento técnico necessário começa a mudar quando passamos da gestão de um projeto para a gestão de um programa. O gerente de projetos normalmente atua mais próximo da execução, onde restrições técnicas podem produzir consequências imediatas sobre o cronograma, o escopo e as entregas. O gerente de programas trabalha em outro nível. Os problemas técnicos individuais continuam sendo importantes, mas passa a ser ainda mais relevante compreender como eles conectam diferentes projetos, equipes e resultados.

Imagine que três projetos diferentes dependam da mesma equipe de integração. Para cada gerente de projetos, essa situação pode parecer apenas uma dependência dentro de sua própria iniciativa. Para o gerente de programas, entretanto, representa algo mais amplo: uma restrição compartilhada de capacidade que pode comprometer várias entregas ao mesmo tempo. Ou imagine que um projeto esteja substituindo uma aplicação da qual outros projetos dependem. Nesse caso, a decisão tecnológica deixa de afetar apenas uma iniciativa e passa a fazer parte da arquitetura do programa, podendo influenciar a sequência das atividades, os benefícios esperados, a alocação de recursos e as entregas de diferentes projetos.

Assim, o gerente de programas pode precisar de menos detalhes sobre a implementação de cada solução, mas de uma compreensão mais ampla sobre como os diferentes componentes tecnológicos se relacionam. O foco deixa de estar apenas nas consequências da tecnologia dentro de um projeto e passa a considerar como essas consequências podem afetar os resultados de todo o programa.

Qual Conhecimento Técnico um PMO ou Gestor de Portfólio Precisa Ter?

No nível do PMO ou da gestão de portfólio, as perguntas se tornam ainda mais amplas. Um gestor de portfólio provavelmente não precisa saber por que determinada importação de dados falhou ou qual API está impedindo a comunicação entre duas aplicações. Mas pode precisar compreender se várias iniciativas estratégicas dependem da mesma plataforma, se diferentes projetos disputam os mesmos especialistas técnicos, se áreas da empresa estão adquirindo aplicações com funcionalidades semelhantes ou se uma decisão tecnológica está criando riscos para diferentes iniciativas importantes.

Nesse nível, o conhecimento técnico passa a contribuir cada vez mais para a compreensão do negócio. As decisões envolvem investimentos, capacidade organizacional, priorização, benefícios e riscos estratégicos. Uma limitação tecnológica que parece relativamente pequena quando analisada dentro de um projeto pode assumir outra dimensão quando diversas iniciativas dependem do mesmo sistema, fornecedor ou grupo de especialistas.

Talvez essa seja a distinção que considero mais importante: o gerente de projetos precisa compreender como a tecnologia afeta as entregas. O gerente de programas precisa entender como ela cria dependências entre diferentes iniciativas. Já o PMO ou gestor de portfólio precisa compreender como essas dependências afetam os investimentos, a capacidade, os riscos e a estratégia da organização.

À medida que avançamos por esses diferentes níveis de gestão, a necessidade de conhecer os detalhes da implementação pode diminuir, mas a importância de compreender as consequências da tecnologia permanece. Isso também está relacionado ao papel de um PMO moderno, que deve ajudar a organização a entender não apenas se seus projetos estão avançando, mas se estão efetivamente gerando valor para o negócio. Explorei essa diferença com mais profundidade no artigo sobre como utilizar a inteligência artificial na gestão de projetos para construir um PMO que gera valor para a empresa.

Gerente de Projetos e Gerente Técnico de Projetos: Qual É a Diferença?

Acredito que também seja importante distinguir um gerente de projetos que atua em iniciativas de tecnologia de um gerente técnico de projetos, frequentemente chamado de Technical Project Manager. A diferença não está simplesmente no fato de um compreender tecnologia e o outro não. Qualquer profissional responsável pela gestão de um projeto de tecnologia precisa ter conhecimento técnico suficiente para conduzi-lo de maneira adequada.

Um gerente técnico de projetos normalmente atua mais próximo da solução tecnológica e pode participar com maior profundidade de discussões sobre arquitetura, restrições de engenharia, ambientes, integrações e decisões de implementação. Já um gerente de projetos pode atuar em um nível menos detalhado, apoiando-se mais intensamente nos especialistas técnicos enquanto concentra sua atuação na coordenação das atividades, na gestão das entregas e nos resultados de negócio. Essa divisão varia conforme a organização e a natureza do projeto, mas o cargo de gerente de projetos não deveria significar que a tecnologia se torne uma caixa-preta que o profissional não precisa compreender.

Afinal, Quanto um Gerente de Projetos Precisa Entender de Tecnologia?

Talvez seja necessário reformular a pergunta original. Em vez de questionar apenas quanto conhecimento técnico um gerente de projetos deve ter, acredito que uma pergunta mais adequada seria: quanto preciso compreender sobre a tecnologia para tomar as decisões de gestão que fazem parte da minha responsabilidade?

Um gerente de projetos precisa compreender a tecnologia o suficiente para reconhecer como decisões, limitações e dependências técnicas podem afetar o escopo, o cronograma, os custos, os riscos e as entregas. O objetivo não é necessariamente desenvolver uma especialização técnica profunda, mas adquirir fluência tecnológica suficiente para fazer as perguntas certas, identificar consequências e transformar informações técnicas em decisões de gestão.

Se não consigo compreender a tecnologia o suficiente para identificar como ela pode afetar o projeto, provavelmente preciso aprofundar meus conhecimentos. Ao mesmo tempo, se começo a tomar decisões de arquitetura que deveriam pertencer aos especialistas, talvez esteja ultrapassando os limites da minha função. O equilíbrio está em algum ponto entre esses dois extremos: compreender o suficiente para interpretar as consequências, sem assumir a responsabilidade por decisões que exigem uma especialização técnica mais profunda.

E, algumas vezes, especialmente quando uma empresa está comprando uma nova aplicação, as perguntas mais importantes são muito mais simples. O que exatamente estamos implantando? Quem precisa entregar o quê? Quem está esperando o resultado? Quais atividades dependem dessa entrega e quando tudo isso precisa acontecer?

Essas perguntas podem parecer simples, mas sem elas é muito difícil definir um escopo consistente, construir um cronograma realista ou compreender se um projeto está realmente avançando.

Até a próxima!

Erik Scaranello