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

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. Até lá, se alguém discordou, talvez seja na linha em que o @porcelli também discordou e que tentei explicar pelo Twitter, embora seja mais o caso de concordarmos em concordar do que uma discordância de fato :-) O ponto principal é simples: não sou contra trabalho remoto, muito pelo contrário. O TL;DR é que não acredito que seja a “única” solução, e a intenção aqui é explorar alguns cenários. Conheço excelentes profissionais que trabalham remoto. Eu mesmo, como digo no artigo, tenho equipes geograficamente separadas, então esse não é o ponto em discussão.

Para variar, SoHo é um daqueles assuntos que a maioria de nós pensa só na superfície e decide “é bom” ou “é ruim”. É ruim que a 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. Vale lembrar que SoHo é um tema que a indústria discute praticamente desde o advento do computador pessoal, em meados dos anos 80. Não tem nada de recente.

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

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

• A Hora é Essa para Trabalho Remoto: lista tudo o que já conhecemos como ponto negativo dos grandes escritórios, as reuniões longas, as interrupções, o tempo de locomoção, a qualidade de vida. Sem ler o capítulo já sabemos o que nos incomoda. O problema é que isso é difícil de contra-argumentar, porque qualquer lugar tem coisas que agradam e coisas que desagradam. Listar só o que desagrada não é o mais relevante. Se você namora ou é casado, fez uma lista comparando seu parceiro à Miss Universo ou ao Mister Universo? O que importa é o conjunto que agrada ou o que desagrada?

• Lidando com Desculpas: de novo, os “argumentos”, a “demagogia”, a “retórica” que se assume serem as desculpas de gerentes e donos de empresa para não permitir trabalho remoto. Metade delas nem sai da boca das empresas; sai dos vendedores de auto-ajuda motivacional, no estilo “trabalhar próximo aumenta a troca de informação e, portanto, a criatividade”. A outra metade são políticas de segurança de dados, atendimento ao cliente, perda de controle. Esses itens são secundários. Como dono de empresa, quase todos são fáceis de lidar e de concordar. 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: resume o que já sabemos, que a tecnologia diminuiu as distâncias. Skype/Hangout, Basecamp/Tracker/Asana, Github/Bitbucket, IRC/Campfire. Fora que muitos serviços terceirizados já são remotos. Contador é um bom exemplo, e vou voltar a ele mais adiante, então guarde esse ponto.

• Cuidado com os Dragões: a única parte que “equilibra” o livro e admite que trabalho remoto nem sempre é um mar de flores. Não se sentir sozinho, não trabalhar mais horas do que deveria, manter hábitos saudáveis. São dicas que valem para o trabalho remoto e para a rotina de qualquer pessoa. Resumindo: tenha bom senso, mas isso você já sabia.

• Contratando e Mantendo os Melhores: resumindo, e aqui eu concordo, existem profissionais excelentes em todo canto do mundo. É a minha razão para explorar fora de São Paulo. De novo, é fácil evangelizar um argumento sem levar todos os pontos em consideração. Concordo com a ideia e volto a ela mais para frente.

• Gerenciando Trabalhadores Remotos: mais uma vez, bom senso de gestão. Bons gerentes já sabem disso. Temos multinacionais funcionando em todos os continentes há décadas, e somos bons nisso. Muita gente acredita que as empresas rejeitam o trabalho remoto porque não sabem gerenciar gente à distância. Isso não se sustenta: veja o movimento massivo de outsourcing de serviços para países como a Índia. Como nos jornais, a gente só olha para a má notícia, mas sabemos fazer isso, e tem ficado cada vez mais simples. Terceirizar para indivíduos parece mais complicado do que terceirizar para filiais em outros países, mas no geral o processo é o mesmo.

• Vida como um Trabalhador Remoto: mais bom senso para qualquer pessoa. Tenha disciplina, monte uma rotina equilibrada, reserve tempo para a família. O único trecho realmente relevante é o último, “garanta que você não está sendo ignorado”. Esse é o meu ponto central para o resto do artigo, então guarde bem.

Concluindo: dos livros que já li da 37signals, este é sem dúvida o mais fraco. Quando ler o índice basta para entender o livro inteiro, a conclusão vem fácil. Isso não significa que ele esteja errado ou seja ruim, mas um post de blog daria conta da mesma mensagem: sim, existem muitas vantagens no trabalho remoto. E, claro, por coincidência eles vendem ferramentas para exatamente o que o livro descreve. É uma excelente peça de self-marketing, e seria burrice não fazer.

A Verdade sobre o Trabalho Remoto

Agora ao outro lado da moeda. No meu artigo recente Matemática, Trolls, Haters e Discussões de Internet tentei passar um conceito simples e importante: fórmula incompleta não serve para nada. Recapitulando, um procedimento, uma metodologia ou um processo só viram “fórmula” quando definem o “domínio” do problema.

Vou assumir que a 37signals argumenta que profissionais de serviços poderiam trabalhar remotamente. Restrinjo à computação porque várias outras áreas simplesmente não funcionam assim, como piloto de avião, bombeiro, médico. O domínio se limita a serviços, nunca produção, e cujo resultado não precisa de mídia física, ou seja, chega pela Internet. Músico, programador, escritor, contador, advogado, arquiteto (em parte). É simples de definir. Para os meus propósitos, fico na área de serviços de desenvolvimento de software.

O maior problema de livros e de pessoas que evangelizam sobre comportamento humano é ignorar a Sociologia, a Psicologia e os campos que já estudaram isso a fundo. O livro Remote é conveniente para o domínio da 37signals e funciona lá. Do jeito que está descrito, funciona só lá. Essa é a primeira pista para separar pesquisa séria de auto-ajuda: “Funcionou para mim, então pode funcionar para você.” É assim que se vende dieta.

Por várias razões, a 37signals deu muito certo como empresa de produtos. Entre elas, as que Zed Shaw explica nesta palestra e o aporte de capital de Jeff Bezos. Ótimo para eles, mas isso quer dizer que o domínio do problema é “empresa de produtos que fatura e lucra muito bem”. E isso já elimina uma fatia enorme do mercado da equação. Se você não conhece os números, estamos falando de um universo bem maior, que no Brasil chegava perto de R$ 37 bilhões. Muito maior do que o universo restrito das tech startups.

Vale entender outra coisa que Getting Real e Remote tentam argumentar, e que poderiam ter simplificado. Estruturas muito centralizadas, com controle top-down forte e pouca ou nenhuma valorização da equipe, costumam ser lugares ruins de trabalhar. A conclusão precipitada é que a descentralização completa seria a melhor forma. Pior ainda é imaginar a 37signals como uma empresa descentralizada só porque todos são remotos e não há uma hierarquia dura. Na prática ela é centralizada, com níveis intermediários de descentralização.

Dá a impressão de organização descentralizada porque usa processos de open source na execução. Mas a cadeia de comando é claramente centralizada em Jason Fried e David Hansson. Não há problema nenhum nisso, e é assim que deve ser mesmo.

Com isso em mente, quero mostrar um gráfico que tirei de uma aula do Nicholas Christakis. Ele cita um estudo sobre os shows da Broadway. Alguns fazem muito sucesso, outros são fracasso de bilheteria, e os pesquisadores queriam saber se havia correlação entre o tipo de rede social da organização do show e a taxa de sucesso.

Imagine no eixo X a densidade de relacionamentos entre os profissionais da equipe. 0 é a rede altamente centralizada, onde as pessoas nas pontas nem se falam; 100 é a rede altamente descentralizada, onde qualquer um fala com qualquer um. O nível 0 a intuição já entrega como ruim, e a correlação confirma: aparece nos shows que fracassaram. O contraintuitivo é que as redes totalmente descentralizadas fracassam na mesma medida. Os shows de sucesso estão nas redes intermediárias, com um pouco de descentralização e um pouco de centralização.

A da 37signals não é totalmente centralizada, já que os programadores remotos conversam por chat, via Github e afins. E não é totalmente descentralizada, porque existe algum nível de especialização e, claro, um comando estratégico central.

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

Mas, como falei, não vou desviar do assunto principal aqui. Fica só a dica.

O Problema da Carreira

Repito que definir o domínio importa porque, no caso da 37signals, dá para aumentar o salário das pessoas quase indefinidamente. O produto já atingiu uma escala em que o faturamento é ordens de grandeza maior que custos e despesas. Ora, se dá para bancar corridas em Le Mans, dá para pagar 5 ou 6 dígitos aos programadores.

Continuando a evoluir o produto, criando novos produtos com cuidado, mantendo os clientes antigos satisfeitos e fazendo bom marketing para atrair novos, enfim, o que uma boa empresa deve fazer, é possível seguir crescendo por um bom tempo.

Só que empresa de produtos assim não é comum. Na verdade é o caso mais raro da indústria, e as mesmas regras não valem para empresas de serviço, que são a maioria. E o motivo é estrutural, ligado aos fundamentos da indústria.

Daí vem o raciocínio: “Por isso não vale abrir empresa de serviços, melhor ir direto para produtos.” Minha resposta é simples: “boa sorte”. A premissa óbvia é que empresa de produtos dá certo na hora. Já discuti isso no artigo anterior Tech Startups, superlotação de B2C. Boring..

“Ah, é só seguir Lean Startup, processos Ágeis, Business Canvas” e todo o pacotinho que vendem hoje, com instruções que qualquer criança segue e pilha inclusa, e boom, sucesso automático… alguém acredita mesmo nessa bobagem?

Agora de volta à realidade. O maior problema de contratar programador home office é de Recursos Humanos e de gestão de carreira, não só de controle. Estamos chegando a um nível de maturidade em desenvolvimento de software em que programar com boas práticas, boa tecnologia, eficiência, previsibilidade e facilidade de manutenção deixou de ser Premium e virou o normal. Não vou oferecer um programador mais barato a um cliente por ele ter qualidade baixa. Quero que meu júnior vire pleno rápido, que o cliente tenha o mesmo nível técnico independentemente de quem faça, e que a qualidade fique sempre acima da média, porque a média da indústria ainda está abaixo da linha da pobreza.

Só que, se isso é o normal, como uma empresa dá aumento a programador? Até certo ponto a capacidade técnica faz muita diferença. Mas casos de tecnologia altíssima e ainda experimental, em que pouca gente sabe o que fazer, são raros, tanto em serviços quanto em produtos. O resto se comoditiza rápido. O mundo open source quase garante que, resolvido um problema difícil, ele se replica em pouco tempo. Se um dia foi “complicado” fazer um front-end web responsivo e minimamente bonito, um Foundation ou um Bootstrap já eliminaram boa parte dessa curva.

Esse é o núcleo da questão: só programar é pouco para 90% dos projetos de software. Já 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 boa parte de um projeto de software não se resolve com software. O profissional “sênior” se define menos pelo código bonito e mais por saber gerenciar as expectativas do cliente, seja ele corporativo ou consumidor, e por assumir responsabilidade.

De novo, não vou me prender às exceções, como centros de pesquisa ou produtos consolidados. Dentro de um grupo, emergem propriedades que só existem dentro de um grupo. (Veja de novo a palestra do Christakis, ou outros como Duncan Watts, para começar a entender essas propriedades.) São atividades que costumam não acontecer sozinho: treinamento peer-to-peer, em que o júnior aprende com alguém mais sênior, e o exercício de comunicação, negociação, responsabilidade e trabalho em equipe.

Tudo isso é possível remoto, só que bem mais devagar e bem menos óbvio, porque cada indivíduo fica de fato isolado. Um cluster geográfico também influencia o mercado e a comunidade local ao redor, então ele não se restringe ao grupo primário: grupos secundários emergem. E cada cluster se relaciona como o próprio Remote descreve, com ferramentas online e viagens presenciais de vez em quando.

Na prática, quanto mais produtivo e eficiente um bom desenvolvedor sênior é em relação a um júnior? Dez vezes, se muito? Ou seja, se um júnior ganha 1000, um sênior ganha no máximo 10.000? E depois disso? Agora, um bom profissional que treina, orienta e se auto-escala de 1 para 3 já subiu ordens de grandeza. Ele chega fácil a 20.000 ou mais por esse caminho. Faça isso em clusters e logo você tem uma rede mais resiliente.

Não estou dizendo que mentoria só rola presencialmente, mas quem consegue fazer isso remoto ainda é a exceção, não a regra. A gente contrata quem tem pouca experiência ou saiu há pouco da faculdade, e mentorar essa pessoa à distância, embora não seja impossível, é complicado. No fim, sempre depende da pessoa.

Então um indivíduo trabalhando remoto está errado? Claro que não. Esse é outro problema desse tipo de argumentação: faz parecer que só existem dois caminhos. Como em tudo na sociologia, há vários cenários para várias configurações. O que as evidências apontam como mais ineficiente são justamente os dois extremos, o totalmente centralizado e o totalmente descentralizado. No intervalo entre eles mora uma série de oportunidades diferentes.

Conclusão

Então sim, não há nada de errado no que está no Remote. O erro é tratá-lo como a única solução. Eu poderia contratar indivíduos isolados em home office sem problema nenhum. Só que ainda não consigo imaginar como fazê-los evoluir, expô-los a mais do que codificar, e dificilmente conseguiria delegar responsabilidade além do código. A grande vantagem de atuar no mercado de serviços é ter acesso a mais empresas e mais situações do que qualquer funcionário de uma só empresa ou de um único produto teria. Remoto e isolado, sobram pouquíssimas dessas oportunidades.

E, de novo, existem exceções: grandes nomes do mundo open source que trabalham como freelancers, sozinhos, muito bem, com reputação só crescendo. Devolvo com a pergunta: isso é a regra ou a exceção? Exceção existe, e, se der, é melhor ser a exceção. Mas evangelizar o caminho da exceção o tempo todo é muita irresponsabilidade.

Trabalhar de casa é uma experiência que vale a pena. De maneira nenhuma ela é obrigatoriamente melhor do que trabalhar dentro de um grupo, mesmo contando o “tempo perdido” na locomoção, que, aliás, é uma péssima desculpa. Muito depende de a sua região ter opções. Se elas são escassas, aí o remoto vira uma boa alternativa. Só considere que sempre há prós e contras.