Skip to main content
Vida e comportamento

6 dicas para se dar bem trabalhos remotos

Ao contrário do que muitos acham, trabalho remoto (ou até um projeto freelancer) não é algo fácil. Para ter esse privilégio, você não precisa ser só bom no que faz, você precisa ser responsável e ter disciplinas extras que vão além das suas responsabilidades técnicas.

Diego Eis

Ao contrário do que muitos acham, trabalho remoto (ou até um projeto freelancer) não é algo fácil. Eu sei que é o sonho de todo mundo ficar em casa, organizar o seu próprio horário para ir ao parque (cinema, praia, sítio, bar, prostíbulo etc etc etc) enquanto todo mundo se mata em um escritório.

Para ter esse privilégio, você não precisa ser só bom no que faz, você precisa ser responsável e ter disciplinas extras que vão além das suas responsabilidades técnicas.

Você precisa encontrar profissionais que tem um senso “social” muito apurado. Que não pensam apenas na sua tarefa, mas também na tarefa de todos os outros integrantes do projeto, inclusive, o lado do cliente, que geralmente está preocupado com o andamento do projeto.

Estas são algumas dicas básicas para você não ser um fiasco quando quiser se aventurar em trabalhar remotamente.

1. Dê status

A equipe não está o tempo todo do seu lado e é muito difícil todo mundo trabalhar no mesmo horário. Trabalhar em uma equipe remota não quer dizer que todo mundo precisa estar ali no chat o dia inteiro. Claro, é bem diferente se você trabalha em uma empresa convencional e vai fazer um dia de trabalho remoto. Nesse caso é muito aconselhável que você trabalhe no horário normal, como se você tivesse ido à empresa normalmente.

Em uma equipe não presencial, o status é o que faz as coisas não saírem dos eixos. Você precisa dar e receber o status do projeto o tempo inteiro. Seja por email, por sms, por código morse ou sinal de fumaça. Você precisa dar notícias e essas notícias precisam ser frequentes.

“Mas Diego, não basta a equipe olhar os commits e pronto?”

Não, não é só checar os commits e a listagem de issues concluídas. A equipe e a pessoa que interage e atende o cliente precisa saber de TUDO. Embora seu commit seja incrivelmente detalhado, isso não basta. Você precisa conversar com a equipe e dizer exatamente qual o status da sua parte no projeto. A lista de tarefas feitas e a lista de commits serão o apoio, mas o que vai mesmo deixá-los seguros e informados são as suas palavras.

Se você não gosta de dar satisfações, esqueça, você não serve para fazer trabalho remoto. Se você não gosta de mandar email dizendo detalhadamente em que pé está seu trabalho, desista, isso não é para você.

Geralmente o status pode ser dado 2 vezes ao dia, pela manhã e na parte da tarde. Se você fizer uma parada longa no decorrer do dia, é bom também manter a equipe informada. Mas geralmente um report no meio da manhã e outro no final da tarde é essencial para que o gerente do projeto possa informar ao cliente como tudo está andando.

2. Nunca omita informações

Se você precisa dar notícias o tempo todo, você não pode, em hipótese alguma, omitir ou esquecer informações. Quando alguém perguntar a você qual o status da tarefa, não se preocupe se ela está incompleta, diga exatamente o status atual. Não tente agradar ou dar aquela enrolada, isso não funciona.

Se falta fazer um pedaço da funcionalidade, diga. Se você se esqueceu de fazer alguma coisa, diga. Se você bebeu até cair na noite anterior e não vai conseguir trabalhar, diga. Mas nunca, de forma nenhuma, omita qualquer tipo de informação.

Digo isso porque toda a equipe e também quem está lidando direto com o cliente necessita de informações exatas. Se você simplesmente omitir informações, as decisões emergenciais, que são as decisões mais importantes, serão totalmente equivocadas.

Essas informações serão usadas também indicar um status mais adequado para o cliente. Aqui no Tableless eu sou bem sincero. Prefiro perder o cliente falando a verdade do que tentar enrolá-lo. Dá mais trabalho enrolar do que perder o projeto. Prefiro ficar são para finalizar os outros projetos que restam, do que aflito e maluco tentando inventar uma desculpa para o cliente.

Dinheiro nenhum paga uma dor de cabeça desse tipo.

3. Mantenha o repositório do projeto sempre atualizado

NUNCA, NUNCA, NUNCA saia da frente do computador sem dar um push antes. Vai pra praia curtir? Atualize seu projeto e envie seus commits para o repositório. Vai pro parque correr com seu cachorro? Atualize o repositório.

Atrasar um projeto por que você não atualizou o repositório é coisa de júnior. Ainda mais quando as suas tarefas afetam as tarefas do time.

Esse é um erro que pode causar uma dor de cabeça terrível para equipe inteira.

Só para deixar claro: não estou dizendo que você tem que subir tarefas incompletas. Você só sobe tarefas totalmente completas e revisadas para o repositório. Mesmo assim, se você estiver trabalhando em um branch separado dedicado para uma determinada tarefa, suba tudo o que puder e avise o time que determinado branch está com uma tarefa incompleta, mas sempre deixe esse branch atualizado. Alguém, eventualmente, pode continuar seu projeto de onde você parou. Se isso acontecer e você não tiver atualizado o branch, alguém vai ter problemas.

4. Uma notícia ruim é melhor do que notícia nenhuma

Ahhh, notícias ruins. Notícias ruins são normais em projetos de internet. Contudo, não ter notícia nenhuma é pior. O cliente fica desesperado, estressado e começa a duvidar da sua capacidade. Problemas acontecem. Estamos falando sobre desenvolvimento de software, ou seja, problemas invariavelmente acontecerão.

O problema é a sua posição perante este cenário. Ninguém gosta de receber notícias ruins, mas todo mundo gosta de receber notícias sobre seu projeto. É importante para que o cliente consiga programar seu cronograma. Ele pode ter engatilhado um grande lançamento, campanha de marketing, apresentação para executivos ou qualquer outra coisa importante. Quando você não dá a notícia ruim (ou qualquer outra notícia), você prejudica uma cadeia inteira de pessoas e processos.

Lembre-se que O problema não é dar a notícia ruim, o problema é não dar notícia nenhuma. Sempre dê notícias sobre o projeto para o cliente, por mais insignificante que essa notícia seja.

5. Não pegue o projeto se você acha que não vai entregá-lo

Talvez você esteja muito atarefado. Talvez você esteja de saco cheio e queira tirar férias. Talvez você queira tanto dinheiro que se envolve em muitos projetos e não entrega nenhum. Talvez você tenha problemas de saúde… Não importa o motivo, mas se você sabe que não vai conseguir entregar o projeto, seja por incompetência ou por qualquer outro motivo, não se comprometa.

É melhor perder um cliente que talvez possa te contactar novamente mais tarde, do que você se envolver, estragar o projeto do cliente e depois largá-lo com um problema gigante nas mãos.

Nesse cenário, o melhor é ser honesto. Diga que você não tem tempo porque está com muitos projetos, porque pretende viajar ou por causa de qualquer outro motivo. Nunca dispense o cliente sem uma desculpa verdadeira.

O cliente não vai ficar bravo com você. Nesse momento você não está comprometido com nada. Você pode dizer não tranquilamente nesse momento.

6. Seja responsável

Eu sinto que não deveria conversar sobre nenhum destes pontos com ninguém, pelo simples motivo de que isso é questão de ter ou não responsabilidade. Se você tiver responsabilidade e claro, comprometimento, você vai se dar bem. O problema é que muitos devs simplesmente pisam na bola e para mim isso não tem outro nome: irresponsabilidade.

Você tem um trabalho para entregar e existem pessoas que contam contigo. Você tem um cliente, que te paga para fazer um determinado projeto, ele “manda” na bagaça toda. É muita falta de responsabilidade, de educação e comprometimento você falhar ao tentar deixá-lo a par dos acontecimentos do seu próprio projeto.

Lembre-se de todas essas disciplinas e com certeza você vai se destacar da média.