O desenvolvimento de software, como bastante enfatizado, é um trabalho criativo, e empresas sempre têm um ótimo retorno quando investem em um ambiente que propicie a criatividade da equipe. Como escreveu o desenvolvedor do Github, Zach Holman, em uma sequência de posts, uma decisão que muito contribui para a melhoria do ambiente de trabalho é fazer com que toda a interação da equipe se dê de forma assíncrona.
No caso do Github, a solução é simples: a forma principal de comunicação na empresa é uma ferramenta de chat:
O Github não teve um escritório nos seus dois primeiros anos; toda a interação da equipe era feita via chat. Hoje já estamos no segundo escritório, e o chat continua sendo a maneira que fazemos as coisas funcionarem.
Pode-se notar as vantagens claras da "assincronicidade" em um ambiente de desenvolvimento, em que não raro os desenvolvedores passam grande parte do tempo concentrados, programando, e em que a comunicação com o restante da equipe é feita através de emails ou mensagens instantâneas em momentos de pausa. Encontra-se até equipes inteiras que passam dias fisicamente distantes, porém com o projeto fluindo sem que a distância se torne um empecilho.
A comunicação assíncrona, reforça Holman, permite que cada membro da equipe decida quando é a melhor hora para interagir com os outros membros, sem a necessidade interromper seu fluxo de trabalho a todo momento, para atender ligações ou responder perguntas de colegas. Isso pode soar óbvio, mas é fato recorrente dentro de ambientes comuns de trabalho, e afeta diretamente a produtividade e os resultados do desenvolvedor:
Usar a comunicação assíncrona significa que se pode sair para almoçar e mais tarde acompanhar tudo o que foi discutido; que se pode fazer uma pergunta a alguém da equipe e não se preocupar em atrapalhar sua concentração. E que se pode trabalhar em casa ou em lugares remotos e se sentir como se estivesse no escritório.
Outro ponto citado pelo autor, sobre como a comunicação se dá geralmente de forma assíncrona, é o processo de desenvolvimento adotado pelo Github. Toda implementação, seja ela de uma nova funcionalidade ou correção de bug, é feita em paralelo por cada membro da equipe, através de um modelo chamado Pull Requests.
No lugar de todo desenvolvedor trabalhar diretamente com o código-fonte de produção, é criada uma estrutura em separado deste código para cada membro da equipe, e todo o desenvolvimento é feito neste código auxiliar. Quando finalizado o código, é iniciada uma discussão sobre as mudanças feitas, incluindo revisão do código, comentários sobre as modificações etc., antes que a mudança seja incorporada ao repositório principal. Isso que permite que a colaboração durante o desenvolvimento também aconteça de forma assíncrona:
No modelo de Pull Requests, não preciso arrastar ninguém para uma reunião que seria inconveniente para eles e para mim.
A principal vantagem deste modelo é reduzir reuniões ao mínimo ou mesmo evitá-las totalmente. Holman destaca que outras empresas consideram reuniões "extremamente tóxicas”.
Reuniões tendem a envolver mais pessoas que o necessário, e mesmo que se esteja extremamente interessado no assunto da reunião, impedem que se trabalhe passando em vez disso a discutir sobre o trabalho.
Nota-se que o aumento de reuniões é proporcional ao número de reclamações da equipe pelo tempo perdido e os poucos resultados alcançados.
Detalhes como estes contribuem para que a equipe de desenvolvimento tenha um ambiente saudável e criativo para trabalhar. Maior ainda é o ganho para a empresa, ao manter a equipe comprometida e, principalmente, motivada.