- Produtividade é uma razão entrega÷esforço — não uma unidade fixa, e muito menos 'horas por ponto de função'.
- Ponto de Função mede tamanho funcional (o quê foi entregue), não o esforço para entregar — são dimensões diferentes.
- UST (Unidade de Serviço Técnico) existe justamente para medir o que PF não mede: esforço técnico padronizado.
- Homem-hora mede esforço bruto, mas isola mal o resultado — por isso o controle empurra o setor para métricas de resultado.
- O vínculo produtividade↔remuneração é opcional: pode ser régua de preço, gatilho de SLA/IMR, ou só gestão.
- Modelar produtividade como indicador genérico (métrica-agnóstico) evita prender o contrato a uma única fórmula.
A confusão de 'horas por ponto de função'
Em muitos contratos, "produtividade" aparece cravada como uma constante: tantas horas por ponto de função. Parece preciso. Mas embute uma confusão de categorias — porque mistura duas coisas que medem dimensões diferentes.
Produtividade, na essência, é uma razão: o quanto se entrega dividido pelo esforço gasto. O ponto delicado é que a unidade da entrega é livre — e a do esforço também. Cravar "horas por PF" é escolher uma combinação específica e tratá-la como se fosse a única possível. Quando o contrato faz isso, ele herda as limitações dessa combinação sem perceber.
Ponto de Função mede o tamanho funcional da entrega, não o esforço para produzi-la. 'Horas por PF' amarra as duas dimensões como se a relação fosse fixa — e ela varia com complexidade, legado e risco.
Ponto de Função mede tamanho, não esforço
O Ponto de Função (PF, padrão IFPUG) mede o tamanho funcional de um software a partir do ponto de vista do usuário: quantas funções de dados e de transação ele oferece. É uma métrica de tamanho do quê foi entregue — independente de tecnologia, de linguagem e de quem fez.
Essa é a sua força e o seu limite. PF responde "qual o tamanho funcional da entrega", não "quanto esforço custou produzi-la". Duas entregas com o mesmo PF podem exigir esforços muito diferentes conforme a complexidade técnica, a maturidade do legado e o risco. Por isso "horas por PF" tenta amarrar tamanho a esforço como se a relação fosse fixa — e ela não é. É um índice útil para estimar, péssimo para tratar como verdade contratual rígida.
UST foi criada para medir esforço técnico padronizado — o que PF, métrica de tamanho, não captura. Contratos maduros usam PF para desenvolvimento e UST para serviço técnico, em vez de forçar tudo numa métrica só.
UST: a métrica criada para o que PF não mede
A UST (Unidade de Serviço Técnico) nasceu justamente para cobrir o vão deixado pelo PF: serviços técnicos que não são "tamanho de software", mas esforço técnico padronizado. Sustentação, operação, atividades de infraestrutura, tarefas que não geram função nova mensurável em PF — tudo isso cabe melhor numa unidade de esforço padronizado do que numa métrica de tamanho funcional.
UST não é "melhor" nem "pior" que PF — é outra coisa, para outro tipo de trabalho. Contratos maduros frequentemente usam as duas: PF para o que é desenvolvimento de função, UST para o que é serviço técnico. Forçar tudo em uma só métrica é o que distorce.
Remunerar por hora aproxima o contrato do posto de trabalho: paga-se por estar alocado, não por entregar. É o que o controle externo empurra para fora, em favor de remuneração por resultado.
Homem-hora e o empurrão para o resultado
O homem-hora mede esforço bruto: horas de pessoas alocadas. É intuitivo e fácil de contar — e é exatamente por isso que vira armadilha. Pagar por homem-hora paga por presença, não por resultado: aproxima o contrato do "posto de trabalho", em que o fornecedor é remunerado por estar lá, não por entregar.
É por isso que o controle externo e as normas de contratação empurram o setor público para remuneração por resultado — medir o que foi entregue, não as horas gastas. Homem-hora ainda tem lugar (algumas atividades são genuinamente medidas por tempo), mas como exceção justificada, não como regra padrão.
O vínculo com a remuneração é opcional — e tem papéis
Há um último mal-entendido: achar que produtividade existe sempre para descontar ou pagar. Não. O vínculo entre produtividade e remuneração é opcional, e quando existe pode assumir papéis distintos:
- Régua de preço: a produtividade converte entrega em valor (ex.: preço por PF ou por UST).
- Nível de serviço: a produtividade alimenta um IMR e pode afetar a remuneração por desempenho.
- Gestão pura: a produtividade é só indicador gerencial, sem efeito financeiro — acompanhar para decidir, não para descontar.
Por isso modelar produtividade como uma constante "horas por PF" é limitante: cobre um único papel e crava uma única métrica. O caminho mais robusto é tratá-la como indicador genérico, métrica-agnóstico — a unidade de entrega é configurável (PF, UST, homem-hora, SNAP, entregável), a série de medições é histórica, e o papel na remuneração é explícito. É assim que o EasyNuP modela produtividade: sem fabricar um preço de esforço que o modelo não tem, e sem prender o contrato a uma fórmula que engana.