[Off-Topic] Trabalho Remoto - Small Office, Home Office (SoHo)

2013 November 18, 19:11 h

Update: Esse é assunto é mais complicado e alguns pontos talvez precisem de mais explicação. Depois vejo se faço um adendo ou um post para complementar, mas até lá, se alguém discordou talvez seja na linha que o @porcelli também discordou e tentei explicar via Twitter, embora seja mais para dizer que estamos concordando em concordar do que realmente uma discordância :-) Acho que o principal ponto é: não sou contra trabalho remoto, pelo contrário. O TL;DR é que não acredito que seja a "única" solução e a intenção é explorar alguns cenários, apenas isso. Conheço excelente profissionais que trabalham remoto. Eu mesmo, como digo no artigo, tenho equipes geograficamente separadas, portanto não é este o ponto discutido.

Para variar SoHo é um dos diversos assuntos que a maioria de nós pensa apenas superficialmente e decidimos "é bom" ou "é ruim". É ruim que Marissa Mayer proibiu Home Office. É bom que a 37signals está evangelizando Home Office. É ruim que a Microsoft concorda com Home Office mas com uma possível visão distópica. Lembrando que SoHo é um assunto que a indústria discute praticamente desde o advento do computador pessoal no meio dos anos 80, isso não é de maneira nenhuma algo recente.

Um disclaimer, eu sou dono de um software shop, uma empresa que oferece serviços de desenvolvimento de software e, portanto, o core da empresa são programadores contratados não somente em São Paulo (onde moro e tenho clientes), como Porto Alegre, Fortaleza e Natal. Não pretendo entrar no meu processo neste artigo.

Eu pensei em dissecar o livro Remote, que é a referência atualmente. Mas não há muito o que dissecar. Se você ler o índice, basicamente já sabe tudo o que o livro diz, o resto é fermento. Veja só:

Concluindo, dos livros que já li da 37signals, este é sem dúvida o mais fraco deles. Quando ler o índice é suficiente para entender o livro todo, não é difícil chegar a essa conclusão. Só isso não significa que está errado ou é ruim, mas um artigo de blog seria suficiente para passar a mesma mensagem: sim, existem muitas vantagens em trabalho remoto. E, claro, coincidentemente eles desenvolvem ferramentas para o que está sendo descrito no livro, portanto, é uma excelente obra de self-marketing, seria burrice não fazer isso.

A Verdade sobre o Trabalho Remoto

Agora vamos ao outro lado da moeda. No meu artigo recente Matemática, Trolls, Haters e Discussões de Internet tentei passar um conceito simples mas muito importante: fórmulas incompletas não servem para nada. Recapitulando, um procedimento, uma metodologia, um processo só podem ser "fórmulas" se elas definem o "domínio" do problema. Vou assumir que a 37signals está argumentando que profissionais da área serviços poderiam trabalhar remotamente. Restringi à computação porque diversas outras áreas simplesmente não funcionam remotamente. Pilotos de avião, bombeiros, médicos, etc. Portanto o domínio se limita a serviços - nunca produção - e cujos resultados não precisam de mídia física, portanto, Internet. Músicos, programadores, escritores, contadores, advogados, arquitetos (parcialmente), etc. Acho que isso é simples de definir. Para meus propósitos vou me restringir à área de serviços de desenvolvimento de software.

O maior problema de livros ou pessoas que evangelizam sobre comportamento humano é não ter bases na Sociologia, Psicologia e campos de estudo que já estudaram esse problema. O livro Remote é conveniente para o domínio da 37signals e funciona lá, mas da forma descrita funcionará apenas lá. Essa é a primeira coisa que você procura para definir entre uma pesquisa séria e uma auto-ajuda: "Funcionou para mim, portanto pode funcionar para você." É como se vendem dietas.

Por diversas razões - incluindo as que Zed Shaw explica nesta palestra, incluindo o aporte de capital de Jeff Bezos - a 37signals deu muito certo enquanto empresa de produtos. Bom para eles, mas significa que o domínio do problema é "empresa de produtos que fatura e lucra muito bem". Isso elimina uma parcela considerável do mercado da equação. E se você não conhece os dados, estamos falando de um universo muito maior que no Brasil representa perto de R$ 37 bilhões. Bem maior do que o universo restritivo de tech startups.

Vamos entender outra coisa que tanto Getting Real e Remote tentam argumentar - e poderiam ter simplificado. Estruturas altamente centralizadas, com alto controle top-down, pouca ou nenhuma valorização da força de trabalho, costumam ser lugares ruins de trabalhar. A conclusão errada é que descentralização completa é a melhor forma, e a conclusão mais errada ainda é imaginar a 37signals como uma empresa descentralizada por ter todos remotos, por não ter uma estrutura hierárquica dura e imexível. Na realidade é centralizada, com níveis intermediários de descentralização.

Jason Fried, DHH no centro

Dá a impressão de ser uma organização descentralizada porque se utiliza de processos de open source para a execução, mas a cadeia de comando é claramente centralizada em Jason Fried e David Hansson. Não há nenhum problema nisso, e é como deveria ser mesmo.

Dado esse entendimento, quero mostrar um gráfico que tirei da aula de Nicholas Cristakis. Ele menciona um estudo sobre os shows da Broadway. Alguns tem muito sucesso, outros são fracassos de bilheteria, e os pesquisadores queriam saber se havia alguma correlação entre o tipo de rede social da organização dos shows e as taxas de sucesso.

Considere no eixo X, a densidade de relacionamentos dos profissionais da equipe do show. 0 sendo altamente centralizada onde as pessoas no canto da rede não se falam, e 100 sendo uma rede altamente descentralizada onde qualquer um fala com qualquer um. O nível 0, altamente centralizado, por intuição, sabemos que deve ser ruim e, de fato, a correlação é que ela se associa a shows fracassados. Porém o que não é intuitivo é que redes totalmente descentralizadas demonstram o mesmo nível de fracasso. Os show de sucesso estão nas redes intermediárias, onde há alguma descentralização e alguma centralização.

O sucesso está no meio

A da 37signals não é totalmente centralizada (os programadores remotos conversam em chats, via Github, etc) e não é totalmente descentralizada (existe algum nível de especialização, e obviamente existe um comando estratégico central).

Estou experimentando diferentes cenários, e o primeiro passo - no meu caso - começa com este outro diagrama:

Codeminer 42

Mas como disse antes, não vou desviar do assunto principal neste artigo. Apenas fica a dica.

O Problema da Carreira

Estou repetindo que a definição de domínio é importante porque no caso da 37signals você pode indefinidamente aumentar o salário das pessoas porque o produto já atingiu patamar de escala onde o faturamento é ordens de grandeza superior aos custos e despesas. Oras, dá para investir em correr na Le Mans, certamente dá para pagar 5 ou 6 dígitos para os programadores.

Se continuar a evoluir o produto, criar novos produtos com cuidado, manter os clientes antigos contentes, fazer bom marketing para atrair novos, enfim, o que uma boa empresa deve fazer, será possível continuar crescendo por um bom tempo.

Só que empresas de produtos semelhantes não é comum, na verdade é o mais incomum na indústria, e as mesmas regras não se aplicam a empresas de serviço, que são a maioria. E não é por má vontade, é por fundamentos da indústria.

E disso vem o pensamento de "Por isso não é bom abrir empresas de serviços e sim ir direto pra produtos." E minha resposta é simples: "Boa sorte". A premissa óbvia desta afirmação é que empresas de produtos imediatamente dão certo. Eu discuti isso no meu artigo anterior Tech Startups, superlotação de B2C. Boring..

"Ah, basta seguir Lean Startup, processos Ágeis, Business Canvas", e todo o pacotinho que vendem atualmente, que tem instruções que qualquer criança consegue seguir e as pilhas já vem inclusas, e boom sucesso automático ... alguém realmente acredita nessas bobagens?

Agora vamos voltar à realidade. O maior problema de contratar programadores home office é um problema de Recursos Humanos, de gestão de carreira, e não somente de controle. Estamos atingindo um nível de maturidade em desenvolvimento de software, onde programar seguindo boas práticas, boas tecnologias, com eficiência, com previsibilidade, com facilidade de manutenção futura, etc, não é mais um Premium, está se tornando o normal. Eu não vou oferecer um programador mais barato a um cliente porque ele tem qualidade baixa, eu quero que meu júnior suba para pleno rápido e que o cliente tenha um nível de qualidade técnica semelhante, não importa quem faça, e que a qualidade esteja sempre acima da média - porque a média da indústria ainda é indiscutivelmente abaixo da linha da pobreza.

Só que se isso é o normal, como uma empresa pode dar aumentos a programadores? Até certo grau, a capacidade técnica faz muita diferença, mas considerando que são raros - não só na área de serviços, mas até mesmo na área de produtos - que estejamos lidando com altíssima tecnologia ainda experimental e que pouca gente tem noção do que fazer, o resto se comoditiza rápido. O mundo open source quase garante que uma vez que um problema difícil é resolvido, ele será replicado rapidamente. Se em algum momento era considerado "complicado" fazer um front-end web responsivo, com elementos visuais minimamente bonitos, um Foundation ou Bootstrap eliminaram boa parte dessa curva, por exemplo.

Este é o core da questão: apenas programar é muito pouco para 90% dos projetos de desenvolvimento de software. Discuti em outro artigo, Estimativas são Promessas. Promessas devem ser cumpridas. que a coisa mais difícil na carreira de um Engenheiro de Software é entender que muito de um projeto de software não se resolve com software. Um profissional "sênior" não é quem faz o código mais bonito, mas quem melhor sabe gerenciar as expectativas do cliente (seja ele um cliente corporativo ou cliente consumidor) e assumir responsabilidades.

Novamente, não vou me ater às exceções como centros de pesquisa, ou produtos consolidados. Ao estar dentro de um grupo emergem propriedades que só existem dentro de um grupo (novamente, vejam a palestra do Christakis ou outros como Duncan Watts para começar a entender essas propriedades). Atividades que normalmente não acontecem individualmente como treinamento peer-to-peer, onde um junior tem a oportunidade de aprender com alguém mais senior, onde habilidades de comunicação, negociação, responsabilidade, team work no geral pode ser exercitado. Tudo isso é possível estando remoto, mas é bem mais devagar e bem menos óbvio porque cada indivíduo está de fato isolado. Um cluster geográfico também tem influência no mercado e comunidade local que o cerca, então não está restrito somente ao seu grupo primário, mas grupos secundários emergem. E cada cluster se relaciona como descrito mesmo no livro Remote, com ferramentas online e eventuais viagens presenciais.

Na prática, quanto melhor um desenvolvedor sênior é mais produtivo e mais eficiente que um júnior? 10 vezes, se muito? Significa que se um júnior ganha 1000, no máximo um sênior ganha 10.000? E depois disso? Agora, um bom profissional que consegue treinar, orientar e se auto-escalar de 1 para 3, já subiu ordens de grandeza. Ele pode facilmente ir pra 20.000 ou mais dessa forma. Faça isso em clusters e em breve temos uma rede mais resiliente. E não estou dizendo que mentorar é algo que só possa ser feito presencialmente, mas novamente quem consegue fazer isso remoto é a exceção hoje, não a regra. Contratamos quem ainda tem pouca experiência, ou saiu faz pouco tempo da faculdade, e embora não seja impossível também é complicado mentorá-los à distância. No fim sempre depende da pessoa.

Significa então que um indivíduo trabalhando remoto é errado? Claro que não, e esse é outro problema desse tipo de argumentação, faz parecer que só existem dois caminhos. E como em tudo em sociologia, existem diversos cenários diferentes para diferentes configurações. O que as evidências indicam como os mais ineficientes são de fato os dois extremos: totalmente centralizado e totalmente decentralizado. No intervalo entre eles existe uma série de oportunidades diferentes.

Conclusão

Portanto sim, o que está no Remote não tem nada de errado. O que está errado é considerá-lo a única solução. Eu poderia contratar indivíduos isolados como home office e não teria nenhum problema com isso. Mas eu não consigo imaginar ainda formas para fazê-lo evoluir, expô-lo a mais atividades que não seja apenas codificação, e dificilmente poderia delegar mais responsabilidades que não apenas código. A grande vantagem de trabalhar no mercado de serviços é ter acesso a mais empresas e mais situações do que qualquer funcionário de apenas uma empresa ou um único produto jamais teria como ter acesso. Estando remoto, existem muito poucas oportunidades.

E novamente, existem exceções, grandes nomes do mundo open source que trabalham como freelancers, sozinhos, e estão muito bem e sua reputação só cresce. Agora devolvo com: essa é a regra ou a exceção? Exceções existem, e se possível é melhor ser a exceção. Mas seria muita irresponsabilidade evangelizar o caminho da exceção o tempo todo.

Trabalhar de casa é uma experiência que vale a pena experimentar, de maneira nenhuma ela é necessariamente melhor que trabalhar dentro de um grupo, mesmo considerando "perder tempo" de locomoção - que, aliás, é uma péssima desculpa - considerando se sua região tem opções. Se não as opções são escassas, no entanto, remoto é de fato uma boa alternativa, só considere que existem prós e contras.

tags: off-topic career insights

Comments

comentários deste blog disponibilizados por Disqus