Hora de programador Magento: o que na plataforma mexe no valor e nas horas

Quanto cobra um programador Magento por hora, afinal?

Não conheço fonte pública e confiável com o valor da hora de profissional autônomo de Magento no Brasil, separado por nível e atualizado. E mesmo quando aparece um número de salário, ele não se compara direto com hora de autônomo: quem trabalha por conta paga imposto, equipamento, férias e as horas sem cliente. Qualquer valor que eu escrevesse aqui seria chute.

O que dá para fazer com honestidade é mostrar o que, na plataforma, empurra o valor da hora para cima e o que faz uma demanda consumir mais horas. Separei em dois grupos, porque misturar os dois atrapalha qualquer comparação de propostas.

O que mexe no valor da hora de desenvolvedor Magento

A curva de aprendizado da plataforma

O Magento cobra conhecimento que não se reaproveita de outras plataformas. Quatro exemplos concretos:

• Injeção de dependência: as classes são montadas a partir do di.xml, e em produção esse mapa é compilado pelo setup:di:compile. Erro aqui quebra o deploy.
• EAV: os atributos de produto ficam espalhados em tabelas por tipo de dado, como catalog_product_entity_varchar, catalog_product_entity_int e catalog_product_entity_decimal. Consulta ou importação que ignora isso sai errada.
• Indexadores: preço, estoque e produtos por categoria chegam à vitrine por índices, atualizados no salvamento ou por agendamento no cron. Quem não entende isso corrige no código um problema que era só índice desatualizado.
• Deploy: em modo de produção, a documentação da Adobe diz que os arquivos estáticos são servidos só do cache, então cada entrega passa por compilação e geração de estáticos.

Quem domina essas quatro coisas erra menos e demora menos. Na minha visão, é isso que justifica uma hora mais cara, e não o tempo de carreira sozinho.

Adobe Commerce Cloud e B2B encarecem a hora?

Podem encarecer, e o motivo é técnico. No Adobe Commerce Cloud, build e deploy passam pelo pacote ece-tools e pelos arquivos .magento.app.yaml e .magento.env.yaml, com Fastly na frente da loja. O B2B é uma extensão da Adobe para o Adobe Commerce, com contas de empresa, catálogos compartilhados, cotações negociadas e ordens de compra. É experiência que depende de ter participado de projetos nessas edições pagas, então peça evidência dela antes de aceitar um valor maior por isso.

Urgência e horário

Trabalho fora do horário combinado, ou que obriga o dev a largar outro cliente, pode ter valor diferente. O problema não é existir diferença; é ela aparecer só na fatura. Combine por escrito antes.

Por que dev Magento cobra mais que dev WordPress?

Não tenho pesquisa para dizer quanto a mais, então não vou afirmar diferença de valor. O que consigo mostrar é por que a mesma mudança pede mais etapas no Magento. Pegue um exemplo simples, um selo de frete grátis na página de produto quando o preço passa de um limite:

• a regra vira um módulo, com registration.php, etc/module.xml e um view model ou bloco;
• o selo entra pelo layout XML do tema, e o template é diferente em Luma e em Hyvä;
• o preço pode variar por website, e a página passa pelo cache de página inteira;
• o deploy exige compilação, geração de estáticos e limpeza de cache.

Cada etapa é pequena, mas todas existem. A pergunta certa não é só o valor da hora, e sim quantas horas cada profissional precisa para percorrer esse caminho sem quebrar nada.

O que mexe no número de horas: tema, integrações e estado da loja

Hyvä ou Luma muda o número de horas?

Muda, e o sentido depende da demanda. No Luma, mexer em componente de interface envolve RequireJS e Knockout.js. No Hyvä, a base é Tailwind CSS e Alpine.js, mas a documentação do Hyvä avisa que módulos feitos para Luma ou Blank precisam de um módulo de compatibilidade. Se a extensão que você quer usar não tem essa compatibilidade pronta, as horas de adaptação entram na conta.

Integrações

Integração com ERP, marketplace ou gateway consome horas fora do Magento: ler a documentação da outra API, mapear campos, tratar falha, reprocessar. A qualidade da documentação do outro lado pesa tanto quanto a habilidade do dev.

Estado da loja

Três condições aumentam as horas de qualquer demanda: loja sem staging (cada teste exige cuidado dobrado), código fora do Git (o dev gasta tempo descobrindo o que já foi alterado) e extensão com código ofuscado (não dá para ler nem estender, só contornar). Por isso o inventário da loja ajuda tanto, como mostro no artigo sobre os dados para pedir orçamento.

Custo real da demanda: valor-hora, horas e retrabalho

A fórmula que eu uso para comparar propostas:

custo da demanda = valor-hora × horas estimadas × (1 + taxa de retrabalho)

A taxa de retrabalho é a sua estimativa de quanto do trabalho vai precisar ser refeito, a partir do que você viu no teste técnico, nas referências e nas primeiras entregas. Não é número exato; serve para testar cenários.

Nesse exemplo, com números hipotéticos escolhidos só para a conta, as duas propostas somam R$ 3.600 antes do retrabalho. Quem decide é a taxa: a proposta A só empata com a B se o retrabalho dela também for de 10%. Na vida real as horas raramente batem, mas a lógica vale: hora barata com muitas horas e muito retrabalho sai cara.

O que perguntar antes de aceitar o valor da hora

• Quantas horas você estima, e o que faria esse número crescer?
• Já trabalhou com o tema da minha loja (Luma ou Hyvä) e com as integrações que eu listei?
• O valor inclui testes, deploy e acompanhamento depois da entrega?
• Como fica a correção de um defeito que for seu?

As respostas dizem mais que o número da hora. Se ainda não sabe qual perfil a sua demanda pede, veja o que faz um programador Magento antes de comparar valores.