Como organizamos nosso slack: do caótico ao estruturado

O Slack é uma ferramenta incrível que conquistou os times de desenvolvimento com seu charme e simplicidade. Seu design clean, suas integrações com outros serviços e sua flexibilidade são simplesmente fantásticos.

É simplesmente a maravilha do mundo do software que conseguiu organizar o que tínhamos antes (emails, grupos de WhatsApp, arquivos no Dropbox, etc.) em um só lugar. A comunicação é vital para a sobrevivência de uma empresa, tendo ela 5 ou 1000 funcionários. Mas todos sabemos como funciona a Teoria do Caos e esse post do The Verge mostra que o Slack não é a panaceia da comunicação. É necessário um esforço adicional para que a desorganização não tome conta.

Recentemente passamos por um dilema envolvendo nosso fluxo de trabalho no dia a dia e o uso do Slack como uma ferramenta de gestão e comunicação interna. Quando vimos que quase 74% de nossas mensagens eram Direct Messages, percebemos que algo estava errado e precisávamos corrigir. Pausamos então por um momento e resolvemos destrinchar todas as nossas necessidades para arrumar a casa.

Para descobrir as estatísticas de seu Time no Slack clique no nome do seu Time no canto superior esquerdo e depois selecione Statistics no menu de contexto

O PROBLEMA

Porque 74% de mensagens sendo Direct Messages é um problema?

  • conversas não são reaproveitadas por outros membros do time;
  • conversas pessoais e de trabalho começam a se misturar;
  • tudo parece muito parado, não há transparência e não há acompanhamento do que está acontecendo;
  • não há uma interação entre os membros do time de forma multidisciplinar.

Vamos então as causas:

Percebemos que o que estava causando isso era primeiramente uma falta de definição de “regras”. Mas regras são muito rígidas, engessam e limitam. Não queremos isso, devemos nos reinventar e adaptar a cada dia e a cada aprendizado. Por isso o termo correto seria criar uma doutrina, um conjunto de ideias fundamentais que sejam coerentes para dar base a uma lógica que nos permita ser mais produtivos, uma filosofia.

O segundo ponto é que possuíamos apenas um canal por produto (#ProdutoA, #ProdutoB). Os assuntos se concentravam nesse único canal, poluindo e misturando temas com conversas paralelas e tópicos diversos desde regras de negócio até definições de design e atendimento ao cliente. Isso obviamente se mostrou nada saudável em pouco tempo. O canal era caótico e naturalmente, aos poucos, nosso time migrou para conversas particulares sem perceber o erro que estávamos cometendo. Isso se tornou mais prático e acabou virando o padrão de nossas conversas. Que erro!

Chegamos então no terceiro ponto: a cultura do caos estava plantada! Três quartos de todas as mensagens no nosso slack eram mensagens individuais privadas, 74(FUCKING)%! Quando vimos isso, percebemos o tamanho real do sangramento e precisávamos estancar com urgência. Da maneira que estavam sendo utilizadas, mensagens privadas eram um câncer na nossa comunicação e uma armadilha para a cultura organizacional.

Como então fazer com que isso seja minimizado e tenhamos mais engajamento coletivo em prol do aprendizado e produtividade?

A SOLUÇÃO

Levando em consideração que um único canal concentrava toda a comunicação pertinente a um produto, começamos a nos questionar como criar outros canais de maneira mais efetiva para que pudéssemos direcionar melhor nossa comunicação de forma aberta e menos confusa. Resolvemos aplicar o conceito de “Divide and Conquer” usando uma árvore binária:

Separar o tópico mais abordado do restante e repetir até ter uma visão clara do seu processo em forma de canais.
Começamos dividindo a parte de desenvolvimento de código do "resto", afinal somos uma empresa de software. Muito da nossa conversa gira em torno de tópicos como backend, web, ios e android.
Para fazer um exercício rápido, se nosso produto se chama SKYNET (mwahaha), temos os canais #SKYNET-dev e #SKYNET, que por enquanto representa o "resto". 
Mas isso não se mostra suficiente pois como disse anteriormente, a parte de desenvolvimento ainda é um mundo e devemos pensar em como quebrar isso. Continuando nessa linha, #SKYNET-dev acabou virando #SKYNET-dev-backend e #SKYNET-dev-frontend, sendo backend onde tratamos assuntos de DevOps e API por exemplo, e frontent onde lidamos com as interfaces mais específicas como web, iOS e Android.
Aqui vale uma ressalva: nos perguntamos se seria necessário criar um canal específico para esses três (web, iOS e Android), ou talvez separar web de mobile. Não achamos que é o momento ainda. Preferimos manter agregado por hora, mas sabendo que pode ser necessário no futuro caso o volume de algum desses tópicos se mostre maior.
Voltando ao "resto", nossa avaliação é de que design também era um assunto muito recorrente e merecia seu próprio canal de discussão, criamos então o #SKYNET-design, contemplando discussões de UX, mockups, fluxos, etc.
Para finalizar, resolvemos chamar o #SKYNET de #SKYNET-business, onde assuntos menos recorrentes se concentram como helpdesk, comercial e qualquer outro de menor escala.

Nomear os canais de forma a reproduzir um fluxo natural no processo do produto
Fez todo sentido então nomearmos os canais de maneira que ficassem verticalmente organizados e fáceis de identificar. Dado o exemplo anterior, chegamos aos seguintes canais:

  • #SKYNET-business (regras de negócio, comercial, helpdesk e outros)
  • #SKYNET-design (mockups, apresentações, UX, etc)
  • #SKYNET-dev-backend (DevOps, API, etc)
  • #SKYNET-dev-frontend (web, iOS e Android)

Decidimos nomear desta maneira, pois reflete o fluxo natural do ciclo do produto como vimos na imagem anterior. Começamos pela definição do negócio (business), passamos por fases de criação (design) e então chegamos ao desenvolvimento da ferramenta por trás dos panos (backend) e sua interface com o usuário (frontend).

CONSIDERAÇÕES FINAIS

Ta maluco? Eu precisaria de uns 30 canais! 
É claro que nossa ideia não é criar trocentos canais, no nosso caso um número entre 3–5 pareceu razoável dadas as nossas necessidades. Cabe ao time definir junto quais são os tópicos mais relevantes e qual separação fazer com o objetivo de tornar a comunicação mais clara e objetiva.

Um canal de duas pessoas não é a mesma coisa que Direct Messages?
Mesmo que um canal tenha apenas duas pessoas responsáveis por um determinado assunto, não ache que seria uma besteira mantê-lo pois além de deixar organizado, nada impede que uma terceira pessoa participe como “ouvinte”.

Bonus Track!
Essa organização nos trouxe também uma liberdade maior para as integrações. Serviços como Trello, Zeplin e Github por exemplo possuem integração com o Slack que podem poupar tempo e direciona-las para o canal correto é importante. Mas isso é uma discussão para um outro momento.


Entendemos que isso é um processo e que não há solução definitiva. O diagnóstico de nosso problema nos fez tomar medidas para combater o que identificamos como prejudicial nesse momento, mas ainda temos muito trabalho pela frente. Seguir essas doutrinas é importante como um passo inicial e um guia para as boas práticas, mas se policiar o tempo todo é necessário para evitar que o caos se espalhe.