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ó:
A Hora é Essa para Trabalho Remoto - vai contar tudo que já conhecemos como pontos negativos de grandes escritórios: as reuniões longas, as interrupções, a distância para se locomover, a qualidade de vida. Acho que sem ler o capítulo já sabemos exatamente o que nos incomoda. O problema é que esse é um ponto difícil de contra-argumentar, a premissa é que qualquer lugar vai ter coisas que agradam e coisas que desagradam. Listar o que desagrada não é necessariamente o mais relevante. Por exemplo, se você tem namorada ou é casado, você fez uma lista de itens do seu parceiro(a) comparado à Miss Universo ou ao Mister Universo? É o conjunto de coisas que desagrada que importa ou as coisas que agradam?
Lidando com Desculpas - novamente, seriam os "argumentos", "demagogia", "retórica" que, no caso, assume-se que é o que os gerentes e donos de empresa usam de desculpas para não permitir trabalho remoto. E o problema é que metade não são o que as empresas dizem mas o que os vendedores de auto-ajuda motivacional dizem. "Trabalhar próximo aumenta troca de informações e portanto a criatividade". Outras são as políticas como "segurança dos dados", atendimento ao cliente, perda do controle. E de fato, esses são itens secundários. Como dono de empresa, a maioria ou todos os pontos são fáceis de lidar e concordar. Acreditem, a indústria não é tão ruim assim, e nenhum desses pontos passou em branco nas últimas décadas. Ainda há resquícios, sem dúvida, mas compare hoje com 20 anos atrás e verá a diferença.
Como Colaborar Remotamente - resumindo o que já sabemos: a tecnologia diminuiu as distâncias. Skype/Hangout/etc, Basecamp/Tracker/Asana/etc, Github/Bitbucket/etc, IRC/Campfire/etc. Fora que muitos outros serviços terceirizados já são remotos, contador é um bom exemplo - e vou retornar neste ponto, então lembrem dele.
Cuidado com os Dragões - esta é a única parte que "balanceia" o livro e dizer que trabalho remoto não é sempre flores. Não se sentir sozinho, não trabalhar mais horas do que deveria, ter hábitos saudáveis, etc. São dicas que valem não somente para trabalho remoto mas hábitos normais de qualquer um. Resumindo: tenha bom senso, mas você já sabia disso.
Contratando e Mantendo os Melhores - resumindo, e eu concordo, existem profissionais excelentes em todos os locais do mundo - meu motivo para explorar fora de São Paulo. Novamente, é muito simples evangelizar um argumento e não levar todos os pontos possíveis em consideração. Como disse, concordo com o ponto e vou retornar a ele depois.
Gerenciando Trabalhadores Remotos - mais uma vez, bom senso de gerenciamento. Bons gerentes já sabem disso. Acreditem, temos multinacionais funcionando em todos os continentes faz algumas décadas. Somos bons nisso. A premissa que muitos acreditam, de que as empresas não querem trabalho remoto é porque não sabemos gerenciar trabalhadores remotos. Isso não é inteiramente verdade, veja o massivo movimento de outsourcing de serviços pra países como Índia. Como nos jornais, só nos focamos nas más notícias, mas acreditem, sabemos fazer isso. E só tem ficado mais simples. Parece que terceirizar para indivíduos é mais complicado que terceirizar para filiais em outros países, mas no geral o processo é basicamente o mesmo.
Vida como um Trabalhador Remoto - mais bom senso para qualquer pessoa: tenha disciplina, construa uma rotina balanceada, reserve tempo para sua família. Deste episódio o único capítulo que é relevante é o último: "Garanta que você não está sendo ignorado". Este é meu ponto principal para o restante do artigo, então lembrem disso.
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.
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.
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:
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.