Mais da metade dos profissionais PHP ouvidos pela Perforce em 2026 tinha mais de 15 anos de experiência com a linguagem. Apenas 15% tinham cinco anos ou menos. Para diretores e gerentes da amostra, contratação apareceu como a principal preocupação.
O dado descreve uma combinação desconfortável: aplicações continuam ativas, enquanto a reposição de conhecimento fica mais difícil. Isso pesa em upgrades, incidentes, estimativas e mudanças que atravessam partes antigas do sistema.
Há uma ressalva importante. O PHP Landscape Report é produzido pela Perforce, fornecedora de produtos e suporte para PHP, e reúne respostas de mais de 700 usuários de software open source no mundo, com recorte para quem usa a linguagem. O levantamento não representa todos os desenvolvedores nem prova uma fuga global de iniciantes. Serve como sinal sobre organizações que já dependem desse ecossistema. Para liderança técnica, o sinal merece ação porque a falha aparece dentro da empresa antes de aparecer no mercado.
Uma stack ativa pode ter conhecimento concentrado
Na pesquisa, PHP empatou com JavaScript como linguagem open source mais usada entre os respondentes. A Perforce também informa que 99% dos usuários de PHP pesquisados mantiveram ou aumentaram o uso de open source no ano anterior. A combinação enfraquece a ideia de um parque em simples desativação.
Ao mesmo tempo, 24% dos participantes do levantamento mais amplo de open source apontaram falta de pessoal com habilidades e experiência adequadas como um desafio operacional relevante. Esse percentual não deve ser reapresentado como "24% das empresas PHP". O valor vem do contexto mais amplo da pesquisa.
O risco não depende apenas de quantas vagas ficam abertas. Uma equipe pode estar completa e ainda concentrar decisões críticas em duas pessoas: como reproduzir a produção, quais jobs não podem rodar juntos, por que certo índice existe, onde a regra fiscal diverge do código novo. Tempo de carreira não se transforma automaticamente em conhecimento compartilhado.
É possível descobrir essa concentração sem criar um programa enorme. Escolha os cinco fluxos que mais doem quando param e peça que alguém diferente do mantenedor habitual execute diagnóstico, deploy e rollback em ambiente seguro. As lacunas que surgirem são mais úteis do que uma matriz genérica de competências.
Contratar pela lista da stack piora o filtro
Uma vaga que exige muitos anos na versão exata do framework reduz o grupo antes de avaliar capacidade de trabalho. Para sistemas maduros, eu procuraria fundamentos que atravessam versões: HTTP, SQL, filas, testes, observabilidade, segurança, leitura de código e desenho de migrações.
Conhecer PHP e o framework em uso encurta a entrada, claro. A diferença está em tratar cada biblioteca histórica como requisito eliminatório. Parte do trabalho real consiste justamente em investigar código que ninguém escolheria hoje. Essa habilidade pode vir de outras stacks.
O processo seletivo também precisa mostrar a natureza da vaga. Se metade do trimestre será dedicada a modernizar uma aplicação importante, escondê-la atrás de um anúncio sobre projetos greenfield cria uma contratação frágil. Há profissionais interessados em reduzir risco e melhorar sistemas existentes. Eles precisam saber que esse é o problema.
Uma tarefa curta de leitura pode avaliar melhor do que um exercício do zero. Dê um trecho pequeno, explique o contexto e peça hipóteses, riscos e o próximo teste. Quem pergunta pela produção, pelos dados e pela possibilidade de rollback demonstra algo que a contagem de anos não captura.
Formação interna compete com o custo da espera
Esperar uma pessoa pronta no mercado parece barato porque o custo fica espalhado. Enquanto a vaga permanece aberta, revisões se acumulam, upgrades são adiados e os especialistas restantes recebem toda decisão difícil. O desgaste aumenta justamente no grupo que a empresa não consegue repor.
Um caminho interno precisa de trabalho real e supervisão disponível. Curso isolado ensina sintaxe, mas não explica as decisões do sistema. Eu começaria por pares em mudanças pequenas, revisão com contexto e rodízio de responsabilidade por um fluxo. A pessoa em formação entrega algo; o especialista deixa uma trilha que outra pessoa consegue seguir.
Documentação entra como produto desse trabalho. Um runbook deve responder como detectar o problema, quais comandos são seguros, onde observar o resultado e quando interromper. Copiar arquitetura para uma página sem testar seus passos produz um arquivo confortável e pouca capacidade operacional.
Também vale reduzir a variedade acidental. Três bibliotecas para a mesma tarefa, padrões diferentes entre módulos e ambientes montados à mão aumentam a quantidade de conhecimento necessária. Padronizar o caminho comum amplia o grupo capaz de operar a aplicação. A exceção pode continuar onde houver motivo explícito.
Reescrever não resolve falta de conhecimento por decreto
Diante da dificuldade de contratar, trocar a stack inteira pode parecer uma forma de alcançar um mercado maior. A decisão adiciona um período em que a equipe precisa entender o sistema antigo, reproduzir seu comportamento e operar dois caminhos durante a transição.
Uma reescrita pode fazer sentido quando há mudança de produto, limites técnicos medidos ou custo de manutenção incompatível com a estratégia. Escassez de uma palavra-chave no anúncio não basta. Sem mapa de regras e dados, a nova stack recebe as mesmas dependências ocultas com uma camada extra de migração.
Eu separaria três decisões: manter, modernizar e substituir. Manter pede suporte e rotina previsível. Modernizar remove versões fora de suporte, melhora testes e reduz variações. Substituir exige uma vantagem que pague a transição. Misturar as três transforma qualquer contratação difícil em justificativa para um projeto plurianual.
O relatório da Perforce aponta uma base madura e uma renovação menor dentro de sua amostra. A pergunta local é mais concreta: se a pessoa que conhece o fluxo crítico sair amanhã, quanto tempo outra levará para fazer uma mudança segura? Essa resposta já mostra onde contratar, formar ou simplificar primeiro.
