Mais valia em tecnologia
Tenho observado recentemente muita discussão sobre cargos e salários em tecnologia, mais especificamente na área de desenvolvimento de software e a essência por detrás destas discussões é uma só, a dúvida sobre qual é o real valor do trabalho e isto me motivou a escrever sobre algo que há algum tempo me incomoda, mas não esperem resposta pois é algo que até hoje não encontrei uma solução real e efetiva.
Temos hoje uma infinidade de formas de relações de trabalho que vão desde a clássica CLT, contratações por projeto, freelancers até os “MEI/PJtinhas” e independentemente da forma tudo gira em torno de um valor hora. O valor hora é algo tão arraigado na nossa cultura que mesmo que exista um valor mensal ou por projeto, certamente este valor teve origem num valor hora.
Quando se fala de gerenciamento de projeto de software temos várias abordagens de precificação como linhas de código, pontos de função, requisitos, pontos de caso de uso e novamente no final tudo é “traduzido” ou melhor diria “reduzido” para uma quantidade de horas.
Mas não vou entrar no mérito de qual seria o valor hora justo, primeiro porque não quero mais do mesmo já se fala muito sobre isto e segundo que estamos falando de um universo muito amplo com variados perfis e necessidades onde tudo é muito particular. O fato é que a tecnologia de uma forma geral evoluiu absurdamente nas últimas duas décadas mas ninguém pensou ou conseguiu “disrruptar” este conceito.
Pense nas situações abaixo descritas:
Eu estimo que irei gastar X horas nesta tarefa, mas vou pedir X+n para ter uma “gordura”
Concluído, mas não vou entregar nada antes do prazo combinado
Pressiona porque sabemos que eles sempre colocam uma “gordura”
Cada uma destas situações podem e costumam gerar discussões inconclusivas com direito a múltiplas opiniões a depender do olhar do contratado ou contratante mas que demonstram que as relações são essencialmente baseadas em mentiras.
Meu ponto é que isto é um limitador ao que chamo de “mais valia” em tecnologia, especialmente por não premiar a eficiência, todos saem perdendo contratado e contratante.
Vou compartilhar um caso pessoal, um dos softwares que ajudei a desenvolver tinha uma quantidade muito grande de módulos de CRUD, quando evoluímos para uma estrutura baseada em API existia uma grande quantidade de código repetitivo a ser escrito. Numa visão clássica teríamos N linhas de código a ser escrito em X tempo, optamos por uma abordagem onde usamos um framework1 especializado para construir um gerador automatico para este código repetitivo, .
Usando este caso como referencia, numa situação hipotética em que estivéssemos sendo contratado para codificar todo aquele código repetitivo, no modelo clássico de quantidade de horas x valor hora, meu contratante seria “limitado” em receber o que precisava num tempo muito inferior ao esperado e como contratado para não ser “limitado” e receber um valor considerado justo para uma abordagem eficiente teria que “mentir” sobre o tempo/esforço efetivamente gasto.
Se refletirmos sobre o dia a dia, veremos que esta realidade é muito presente nas relações e certamente encontraremos outras situações similares. Exceto funções que executem estritamente codificação e testes onde o trabalho é praticamente em nível industrial, não deveria se aplicar uma métrica massificada de remuneração.
Observo que nas relações entre empresas fica um pouco mais fácil negociar o valor de uma solução, as startups pela própria natureza são mais ágeis neste sentido, algumas corporações com politicas de inovação aberta (Open Innovation), pela proximidade com startups, já começam a perceber os ganhos de uma nova abordagem, mas na grande maioria a estrutura ainda resiste em abandonar o modelo das métricas de valor hora, muito arraigado desde o RH até os departamentos de compras, com suas listas de referencia, que servem como uma forma de auto-proteção e em muitos casos métrica para bônus.
Como eu disse no início não tenho a solução mas penso que o futuro das relações de trabalho intelectual em tecnologia irão cada vez mais se distanciar do modelo CLT puro e se aproximar mais de um modelo de inovação aberta, já existem experiencias nesta linha como bônus baseado no sucesso de projetos, planos de stock options, etc … mas para evoluir para um novo modelo, temos um longo caminho a trilhar primeiro será necessário quebrar alguns paradigmas enraizados tanto nos contratados como nos contratantes.
Paulo Moreno
Empreendedor serial, conselheiro consultivo e investidor anjo/seed em startups de base tecnológica ligadas a Saúde, AI e Equity Crowdfunding.
Apaixonado por inovação, história e tecnologia e que para manter o equilíbrio adora pedalar e viajar.
https://www.codesmithtools.com/product/generator
Mind Outburst a imagem que ilustra este artigo é parte do trabalho do artista digital Gianfranco Weiss