### **Guia de Trabalho Remoto da No-Budget Science Hack Week** <hr> Trabalho remoto é uma tendência recente e para muitas pessoas na academia é uma novidade [trazida pela pandemia][1] - sem muito aviso prévio e tempo de preparação. E, diferente da ciência biomédica de bancada, a ciência "no-budget" ([na nossa definição][2]) se presta a ser realizada remotamente. Esse guia tem como objetivo descrever princípios em torno dos quais o trabalho remoto funciona, além de falar de como isso vai acontecer durante o evento - que ferramentas usaremos e como será o uso delas durante a Hack Week. Fazer tudo do mesmo jeito que você faria se estivesse no laboratório pode até funcionar, mas é ineficiente e não aproveita as vantagens do remoto. Para além da Hack Week, vale considerar que saber trabalhar remotamente é uma habilidade transferível importante. Parece existir uma tendência no mercado de trabalho na direção de trabalho remoto - sem dúvida impulsionada pela necessidade [durante a pandemia][3]. As vantagens mais óbvias para quem trabalha remotamente é não ter mais o translado diário casa-trabalho, ter horários flexíveis e não ter que se mudar por causa de uma oportunidade de emprego (na Estônia, você pode ser [nômade digital][4]). Pra quem contrata, a vantagem é não ter que manter um espaço físico e poder contratar de qualquer lugar do mundo. E parece que a academia não vai escapar da tendência: muita gente foi apresentada ao trabalho remoto recentemente, mas a [discussão na academia][5] [vem de antes][6]. #### Funcionando assincronamente Talvez o princípio central do trabalho remoto seja a assincronia. Num laboratório, você teria as pessoas trabalhando ao mesmo tempo. Remotamente, você tem que trabalhar como se todos as pessoas que trabalham com você estivessem dormindo (e reciprocamente, como se você fosse estar dormindo quando elas estiverem trabalhando). Pra isso funcionar, entram os outros princípios abaixo. #### Responsabilidade > Rigidez Se não tem ninguém do seu lado olhando se você foi ao trabalho ou não, a responsabilidade sobre como e quando você trabalha é toda sua. Isso significa: - Horários flexíveis: você pode trabalhar [quando e como preferir][7] sem que te julguem por essas escolhas. E claro, você não deve julgar as escolhas de horários das outras pessoas. - Igualmente, também cabe a você dizer quando você precisa de um intervalo, descanso ou quando parar de trabalhar - e descanso é essencial pra produtividade. - O corolário disso é que o que importa são os resultados obtidos e não a quantidade de horas trabalhadas (e muito menos exatamente que horas foram trabalhadas). - Se torna importante avisar dos seus horários de disponibilidade, pra que seu grupo de trabalho possa se planejar quando necessário. Avise pelo status ou por uma mensagem do Slack. - Dependendo do seu ambiente de trabalho, pode também ser importante você ter um sinal para avisar as pessoas que moram com você quando você está trabalhando (e.g. um chapéu ou uma porta aberta/fechada). - Se você não pode consultar colegas em tempo real antes de uma decisão, é importante que você tome as decisões - desde que elas sejam fáceis de reverter, não tem problema. Deixe pra discutir e deliberar longamente só sobre as decisões que tem um custo alto para serem desfeitas. Na Wikipédia, existe um princípio análogo, o ["be bold"][8]. - Vale se preocupar com a sua postura e condição de trabalho também (passar horas ininterruptas em frente ao computador vai ter um custo lá na frente). [O guia de bem-estar da BioCuration tem boas dicas][9]. - Na Hack Week, a programação da segunda semana (a semana de hacking) é bem livre. Estaremos disponíveis durante as tardes, mas a ideia é que os grupos se organizem por conta própria, trabalhem nos seus horários e marquem reuniões de mentoria com a organização conforme for necessário. #### Documentação Não tendo pessoas do seu lado pra você consultar sobre como proceder na situação Y ou qual a versão atual do arquivo X ou de onde veio o dado Z, é importante que tudo isso esteja documentado (assim as pessoas podem ler a documentação quando você estiver dormindo). - Se alguém tem uma dúvida, ela pode aparecer de novo e a pessoa que sabe a resposta vai estar dormindo. Em vez de explicar algo verbalmente ou por mensagem, documente. - Um princípio (mais extremo) é que se alguma coisa não está na documentação ou nos protocolos, essa coisa não existe. - Para a Hack Week, temos uma wiki, associada ao [repositório do evento na OSF][10], que participantes podem editar (se você está participando do evento e não criou uma conta na OSF ainda, [clique aqui para se cadastrar][11], depois nos avise para te adicionarmos no repositório). - Cada grupo/projeto deve ter uma página nessa wiki. Recomendamos que essa página seja sempre atualizada, e no mínimo sirva de índice: uma lista de links para outras páginas, documentos compartilhados, pads, código, etc. A ideia é que a partir dessa página seja possível achar tudo que for necessário para trabalhar no projeto. #### Comunicação Se as pessoas não estão do seu lado, pessoalmente, a maior parte da comunicação vai ser via texto. E texto é desprovido das nuances de linguagem não-verbal. Então se torna central usar bem os meios de comunicação, para prevenir que as expectativas mal-comunicadas estraguem tanto o trabalho quanto as relações interpessoais. - Todo mundo está dormindo, então não espere respostas imediatas. - Use emojis. Isso lembra as pessoas que parte da mensagem não é transmissível por canais puramente textuais. E [assuma a boa intenção das pessoas][12]. - Existem várias funções diferentes dentro do guarda-chuva "comunicação". E existem canais e condições apropriadas pra cada uma (que por sua vez, tem que ser comunicados de antemão). - Comunicação formal: contratos, documentos, certificados e afins. Na Hack Week, usaremos o e-mail para essa função. - Comunicação informal, com permanência: a comunicação informal que diz respeito ao trabalho do grupo e que você vai querer ver depois - é importante que seja possível buscar nas mensagens. Idealmente, o que aparece aqui é documentado depois. Na Hack Week, recomendamos que toda a comunicação desse tipo seja via Slack. Isso permite que a organização acompanhe assincronamente o trabalho dos grupos e que haja comunicação entre os grupos ou mesmo com as pessoas da nossa comunidade no Slack que não estão participando da Hack Week mas tem algo pontual a contribuir ou algum pitaco pra dar. No momento oportuno, criaremos um canal no Slack para cada um dos grupos. - Comunicação não-relacionada ao projeto: pra isso recomendamos o Telegram e, relutantemente, o WhatsApp - ambos autores desse manual acreditam que o Telegram é o app superior aqui. :) - Como dito acima, é importante que questões do projeto não sejam discutidas por Telegram/WhatsApp. Memes, críticas a organização e fofocas gerais se encaixam aqui. - Comunicação complexa: quando houverem muitas discordâncias, quando decisões complexas precisam ser tomadas, quando existe algum mal entendido a se resolver, quando os canais de texto não forem suficientes ... Nesses casos, use reuniões por vídeo (com ressalvas, veja abaixo). Para isso, na Hack Week, usaremos o Zoom - para eventos gerais, da programação - e um link fixo do Google Meet para cada grupo. #### Reuniões Uma piada recorrente do mundo corporativo é ["sobrevivi a mais uma reunião que devia ter sido um email"][13]. Por extensão, um monte de gente deve "sobreviver a emails que deviam ter sido uma mensagem" e "sobreviver a uma enquete quando a pessoa devia ter decidido sozinha". Existem [argumentos contra reuniões][14] mesmo em ambientes co-localizados de trabalho. - Use reuniões por vídeo como último recurso. - Não marque reuniões [desnecessariamente][15] (e tudo bem desmarcar reuniões que não são mais necessárias) - Por exemplo, se alguém tem que fazer uma apresentação pra demonstrar como usar uma ferramenta, não é necessário que todo mundo esteja online ao mesmo tempo vendo a apresentação. A pessoa pode gravar o vídeo antes, quem precisar assiste no seu tempo. A reunião pode ser encurtada e ter apenas as perguntas/discussão sobre a apresentação. Brainstorming não precisa de todo mundo junto, pode ser por um documento compartilhado (veja a seção de ferramentas no final). Updates do projeto podem ser dados por escrito. - Vale lembrar também que reuniões por vídeo são ruins por outras razões (por exemplo, não são buscáveis - é difícil saber o que alguém falou sem reassistir o vídeo). Isso nos leva ao próximo tópico. #### Como fazer reuniões Para que elas sejam tão efetivas quanto é possível, uma vez que você marque uma reunião, é sua responsabilidade fazer com que ela funcione. Os pontos abaixo valem para a Hack Week (mas tem aplicação mais ampla). - Tenha sempre uma pauta para a reunião. Um documento compartilhado (Google Docs ou pad) com os tópicos a serem discutidos. - Faça uma ata do que foi discutido e tome notas dos pontos importantes e tarefas definidas na reunião. - Faça a ata **durante** a reunião. Se deixar pra depois você vai ter que vencer a preguiça (assumindo que você lembre tudo o que foi discutido). - Reuniões tem que ter horário de início e fim, e eles devem ser seguidos pontualmente. Isso respeita o tempo das outras pessoas e permite que todo mundo se planeje em torno das reuniões. - Recomendamos que as reuniões sejam planejadas com uma sobra na duração (e.g. reuniões de 1 hora acabam em :50 minutos, reuniões de 30 min acabam em 25). Isso dá tempo para as pessoas entre reuniões. Recomendamos que esse tempo (opcionalmente) seja também usado com "break" (veja o próximo tópico). - Grave reuniões importantes. Mas isso não é substituto pra ata - ler ou buscar uma informação num documento é muito mais eficiente do que reassistir 1 hora de reunião (ninguém reassiste, não vamos nos enganar). E qualquer coisa que precisa ser lembrada depois tem que ser enviada por chat (e.g. links importantes). #### Organização do projeto Os projetos da Hack Week serão conduzidos remotamente e de forma distribuída, sem supervisão direta. Então é importante ter alguma estrutura na organização, para que as pessoas saibam o que fazer e as responsabilidades de cada pessoa fiquem claras, assim como o plano para o projeto. - Como dito acima, cada projeto deve ter uma página na [wiki][16] que sirva de índice para os arquivos de trabalho e outras coisas relevantes. - Essa página deve conter também um plano de trabalho: um curto resumo do que é a ideia do projeto e que etapas planeja-se executar durante a Hack Week. - Recomendamos que cada grupo tenha um "gerente". Essa pessoa não é dona do grupo, só é responsável por marcar e conduzir reuniões ou manter a wiki atualizada. - Recomendamos ter um "porta-voz" do grupo. Essa pessoa fica automaticamente responsável pela comunicação com a comissão organizadora, quando necessário. #### Social estruturado Aqui chegamos ao grande problema do trabalho remoto: a falta do aspecto social do trabalho. Bom, na verdade, o que falta é o aspecto ["serendipituoso"][17] do social. Num esquema totalmente remoto, não existe o local de almoço compartilhado ou o encontro não-planejado pelo corredor que mantém as relações interpessoais. Também não existe o conjunto de experiências que quebram o gelo entre pessoas que não se conhecem. Pra que o trabalho remoto funcione, o aspecto social tem que ser promovido intencionalmente. Com base nisso (e no fato de que trabalho remoto é novidade pra muita gente) é que a programação e formato da Hack Week sabota muitos dos príncipios que mencionamos acima (e nos quais acreditamos). Especialmente na primeira semana, de formação de grupos, teremos vários eventos síncronos, com horário marcado. Alguns desses são explicitamente para que as pessoas se conheçam e outros para que participantes debatam ideias que evoluam para um projeto para ser executado na segunda semana. Assim o andamento do evento não fica completamente dependente da pró-atividade entre pessoas que ainda não se conhecem bem. Num ambiente de trabalho remoto de longo prazo, esses eventos sociais podem tomar uma variedade de formas: minutos reservados no fim das reuniões para "small talk" (o "break" mencionado na seção sobre reuniões), apresentações de pessoas recém-integradas a um grupo, vídeo chamadas para jogos, horários combinados para trabalhar sincronamente, etc (a [GitLab][18] e a [Zapier][19] contém várias outras sugestões). Em resumo, é importante que todos os momentos síncronos sejam vistos como sociais, como oportunidade para conhecer os outros, já que para o trabalho em si a interação é só com um avatar na tela que te manda mensagens (quando não está dormindo). #### Lista curada de ferramentas que podem ser úteis Na Hack Week, faremos uso "oficial" apenas do Zoom, Google Meet, Slack, OSF e email. Dito isso, essas não são as únicas nem as melhores ferramentas disponíveis - a escolhaé resultante de tentar evitar apresentar várias ferramentas diferentes com as quais as pessoas não estão familiarizadas. O uso de outras ferramentas no trabalho dos grupos fica a cargo dos próprios grupos. E de qualquer forma, você pode achar a lista útil pro futuro além da Hack Week. **Vídeo-chamadas:** - [Zoom][20]: é o que todo mundo anda usando, aparentemente. Tem um plano gratuito com algumas limitações. Parece ter superado os problemas de segurança. Funciona no navegador ou baixando o cliente próprio deles para o seu sistema. - [Google Meet][21]: tem a vantagem de ser gratuito. Não tem tantos recursos quanto a versão paga do Zoom. Também funciona no navegador. - [Jitsi][22]: similar ao Meet, mas com o apelo de ser de código aberto e ter foco em privacidade e segurança. ["Free as in freedom"][23]. Também funciona no navegador. **Comunicação estruturada:** - [Slack][24]: permite a criação de canais e threads para separar assuntos. Guarda suas mensagens, permite anexos, tem integração com vários outros softwares (e.g. Dropbox, GitHub, etc). Na versão paga, tem também canais de vídeo e voz. - [Discord][25]: faz tudo que o Slack faz e também chamada de vídeo e voz, na versão gratuita. Carrega um pouco da reputação de não ser "sério" porque tem origem na comunidade gamer (embora esteja passando por um rebranding no momento). Repositórios/Documentação: - [Open Science Framework][26]: repositório de dados e documentos para uma ciência mais aberta. Todo projeto na OSF vem com armazenamento e uma wiki. Gratuito, também tem umas conveniências para pesquisa, como fazer pré-registro de protocolos e postar preprints, além de integração com outros serviços (Google Drive, GitHub). - Wikis: o formato popularizado pela Wikipédia, é excelente pra organizar documentos interligados. - [GitHub][27]: o lugar universal de facto pra disponibilizar código. Se você programa ou pretende começar em breve, vale conhecer. Embora não obrigatório na Hack Week, se torna obrigatório caso o projeto possua código. :) - [Trello][28]: um app muito usado para gerenciamento de projeto/tarefas no esquema de Kanban, com cartões virtuais sendo movidos de "To Do" para "Doing" para "Done". A versão gratuita funciona bem para grupos pequenos. **Quadros brancos:** - ... **Colaboração/Compartilhamento de arquivos:** - [Google Drive/Docs][29]: como todo mundo já tem uma conta do Google mesmo, se torna conveniente usar o Drive e os editores associados (Docs, Sheets, Slides) pra trabalhar colaborativamente e compartilhar documentos (e outros arquivos de trabalho). - [Dropbox][30]: serviço de armazenamento também bem usado (a versão gratuita dá menos espaço do que o Google Drive). Tem o Dropbox Paper pra trabalho colaborativo (com uns features extra em relação a um documento simples). - [OneDrive + Office][31]: a opção da Microsoft para documentos colaborativos e armazenamento. - [Wikimedia Etherpad][32]: Pads são arquivos de texto simples e colaborativos, online, em tempo real. O serviço é baseado no Etherpad, que também é [*libre*][33]. Esse guia se baseia na nossa experiência (não muito vasta) com trabalho remoto colaborativo e em diversos outros guias e ensaios sobre trabalho remoto (linkados no texto). Em particular, aprendemos muito com o material da [GitLab][34], [Zapier][35], Wikipedia, [Friday.app][36] e [Twist][37] - preparar esse guia foi um grande aprendizado e mudou nossa própria opinião sobre como trabalhar remotamente. Kleber e Tiago Comissão Organizadora, No-Budget Science Hack Week [1]: https://www.nature.com/articles/d41586-020-01518-y [2]: https://www.reprodutibilidade.bio.br/hack-week-2020 [3]: https://www.nature.com/articles/d41586-020-01518-y [4]: https://qz.com/quartzy/1216964/estonia-is-launching-a-digital-nomad-visa/ [5]: https://www.sciencemag.org/careers/2020/05/it-s-competitive-advantage-scientists-tout-benefits-hiring-remote-postdocs [6]: https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1007809 [7]: https://about.gitlab.com/company/culture/all-remote/non-linear-workday/ [8]: https://en.wikipedia.org/wiki/Wikipedia:Be_bold [9]: https://www.biocuration.org/wellness/ [10]: https://osf.io/s8bmp/wiki/home/ [11]: https://osf.io/register [12]: https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith [13]: https://dilbert.com/strip/2020-02-07 [14]: http://www.paulgraham.com/makersschedule.html [15]: https://about.gitlab.com/handbook/communication/#scheduling-meetings [16]: https://osf.io/s8bmp/wiki/home/ [17]: https://pt.wikipedia.org/wiki/Serendipidade [18]: https://about.gitlab.com/company/culture/all-remote/informal-communication/ [19]: https://zapier.com/blog/remote-team-activities/ [20]: http://zoom.us [21]: http://meet.google.com [22]: https://jitsi.org [23]: https://www.gnu.org/philosophy/free-sw.html [24]: http://slack.com [25]: https://discord.com/ [26]: https://osf.io/ [27]: http://github.com [28]: https://trello.com/ [29]: http://drive.google.com [30]: http://dropbox.com [31]: https://onedrive.live.com/ [32]: https://etherpad.wikimedia.org/ [33]: https://www.gnu.org/philosophy/free-sw.html [34]: https://about.gitlab.com/company/culture/all-remote/guide/ [35]: https://zapier.com/learn/remote-work/ [36]: https://www.friday.app/asynchronous-miscommunication [37]: https://twist.com/remote-work-guides