Public-by-Default – A filosofia da informação acessível, parte II

Boa parte deste texto, é traduzido de um post escrito por Sergio Nouvel, CEO da Get on Board. Caso você queira, pode ler o texto na integra em inglês aqui

Estou obcecado com o gerenciamento de informações e comunicações em uma equipe remota desde que o Get on Board começou a crescer. Reduzir o bus factor é um objetivo primário – mas outra igualmente importante é diminuir a dependência da sincronicidade. Quando o que sei está documentado e acessível aos outros, é menos provável que eu seja um gargalo para qualquer outro membro da equipe. Portanto, se eu estiver ocupado, cuidando de assuntos familiares, em férias ou doente, eu não estarei bloqueando ninguém.

Isto, por sua vez, dá a todos na equipe a liberdade de construir seus próprios horários de trabalho de acordo com suas necessidades, trabalhar de qualquer fuso horário, ou desfrutar de momentos mais livres de distrações. Ao escrever estas linhas, a maior parte do mundo está sob quarentena (o artigo original foi escrito em 2020), confiando em chamadas de vídeo sem parar para continuar trabalhando. É desnecessário dizer que isso não é um cronograma de trabalho sustentável a longo prazo.

É por isso que adotamos alguns princípios que nos ajudam a tornar a informação mais resiliente, para que não tenhamos que estar continuamente aumentando a carga mental uns dos outros. Dentre esses princípios, public-by-default é o mais importante.

Dê uma olhada nas seguintes camadas de visibilidade que definimos para nossa informação:

Camadas de privacidade

Estes são as camadas de visibilidade que definimos na “Get on Board”. Toda vez que criamos um fragmento de informação, começamos com a camada pública por padrão.

⭐️ Public-by-default significa: todas as informações pertencem a camada mais externa possível, e só as movemos para dentro se tivermos uma razão convincente para fazê-lo.

Este mesmo artigo é um exemplo deste princípio posto em ação. Ele existe principalmente para nosso uso interno, mas dado que não há razão para que o público em geral não possa se beneficiar dele também, ele está em nossa camada mais pública.

Por que Public-by-default

  • O conhecimento tornado público é mais resiliente e encontrável. As informações em canais públicos são mais fáceis de encontrar (você pode até usar o Google ou o archive.org para recuperá-las) e menos propensas a perdas acidentais. Mais pessoas saberão sobre ela – e se lembrarão dela – do que se ela for privada.
  • O conhecimento tornado público é mais robusto. Está aberto ao escrutínio, validação, correção e complementação de outros. Podemos testar a qualidade de nossas suposições de forma mais ampla se outros puderem dar feedback sobre elas. Se estivermos errados, saberemos disso mais cedo.
  • O olhar do público nos faz trabalhar mais arduamente. Ter informações sujeitas a um escrutínio aberto nos motiva a torná-las de alta qualidade desde o início: melhor escritas, melhor referenciadas, melhor fundamentadas.
  • Maior facilidade na tomada de decisões. Se todos tivermos acesso às mesmas informações, teremos um contexto compartilhado que, por sua vez, nos ajudará a tomar melhores decisões e com menos atritos.
  • O conhecimento público ajuda mais pessoas e agrega mais valor. Por exemplo, se outros compartilham este artigo, ele beneficia novos leitores e nos ajuda a tornar nossa marca mais visível. Um novo membro da equipe que se juntará à empresa no futuro poderá já ter lido esta matéria, acelerando o seu onboarding.

Ações práticas!

Tentamos fazer a informação permanecer na camada mais externa possível:

  • Faça perguntas em canais públicos, não em mensagens privadas. Mesmo que você pretenda perguntar a uma pessoa específica, colocar a pergunta em um canal aberto permite que outros se sintonizem e encontrem a resposta. Você não sabe necessariamente quem tem a resposta para sua pergunta!
  • Coloque suas descobertas técnicas e aprendizados em nosso blog (4Future). Ao colocar estes aprendizados em público, aumentamos a chance de que outros sugiram melhores alternativas ou deem novas ideias.
  • Converse, tome decisões por canais de texto (Camada Organização) ao invés de videochamadas (Camada Equipe / Camada Privado). Os canais de texto são sempre mais acessíveis e compartilháveis do que os áudios e as videochamadas (mesmo com gravação automática).
  • Mantenha a documentação do produto em sites públicos (Camada pública) em vez de manuais internos (Camada Organização). Quando um novo membro da equipe quer aprender sobre como funciona a empresa, ele pode usar nossas informações disponíveis ao público. Isto nos ajuda a testar e melhorar nossas informações para o benefício de todos os nossos usuários.
  • Rascunhos, Projetos em andamento e arquivos inacabados devem estar, por padrão em nossos arquivos e ferramentas compartilhados (Camada Organização). Em vez de deixá-los em uma pasta privada “até que estejam prontos”. Não temos vergonha do trabalho inacabado. Esse é o “progresso” no trabalho em andamento!

Precauções ao praticar o public-by-default

Estamos cientes dos seguintes perigos ao abraçarmos o public-by-default:

📣 Excesso de ruido

Quando tudo é público, isso significa que qualquer pessoa terá acesso a toneladas de informações. Se mal administrada, isso significará que os colegas de equipe se afogarão em muito ruído, permanentemente distraídos, e lutando para encontrar o que é importante.

Vemos isto com bastante frequência quando usamos ferramentas de trabalho em equipe, tais como Slack ou Discord. Sim, talvez tudo o que já discutimos esteja em um canal do Discord – mas boa sorte na tentativa de encontrá-lo. E espero que você se acostume a ter aquelas notificações a cada 15 minutos.

Como podemos conter o ruído?

  • Saiba a diferença entre tornar algo visível para todos e notificar a todos. Só porque algo é público, não significa que todos tenham que ser interrompidos e obrigados a prestar atenção imediata a ele. Cuidado com o uso de notificações e @s. Public-by-default não significa que tudo tem que estar no canal #geral; usar um canal não-privado (para que qualquer um possa entrar e procurar a informação mais tarde) é mais do que suficiente.
  • Procure primeiro, se não encontrar a resposta, então crie. Suponha que é muito provável que as informações que você está prestes a criar já existam em outro lugar (incluindo a Web). Se ela já existe, crie um link para ela ou desenvolva a partir dela.
  • Seja breve. Resumir, reduzir palavras, fazer sentenças mais simples.
  • Forneça contexto e dicas. Devemos tentar responder à pergunta: “será que eu realmente preciso continuar lendo isto?” em menos de 5 segundos. Um título de página mais longo, ou um parágrafo introdutório, vai muito longe em informar ao leitor se ele deve continuar passando tempo lendo esta matéria.
  • Torne as informações localizáveis, etiquetando e classificando-as adequadamente. Arquitetura da Informação é fundamental aqui. O conhecimento só é útil se for acessível quando você precisar dele. Tome tempo para organizar e descrever a informação. Ao invés de apenas postar um link no canal público, descreva-o brevemente.
  • Torne a informação amigável e fácil de navegar. Se necessário, divida-o em várias páginas, forneça um índice, use links generosamente e inclua ilustrações e gráficos.
  • De preferência por canais assíncronos de longo prazo. Nosso blog tem um prazo de validade mais longo do que o Discord, e o conhecimento no Discord tem um prazo de validade mais longo do que no WhatsApp. Quanto mais longo é o tempo de vida de um canal, menos imediatismo ele exige. Você pode ler este artigo amanhã ou no próximo ano, se preferir, e ele continuará a ser relevante.

😱 FOMO

É fácil de ser levado pelo medo de estar perdendo algo e tentar estar a par de cada nova informação que é criada. Se você é o tipo de pessoa que gosta de participar de TODOS os canais Slack / Discord, ler ou participar de TODOS os tópicos de conversa e ler TODOS os artigos que a equipe compartilha, você sabe do que estou falando.

Precisamos estar atentos ao FOMO dos colegas e tentar não os distrair desnecessariamente, precisamos estar cientes de que temos uma quantidade limitada de informações que podemos consumir diariamente. Precisamos gastar essa quantidade com sensatez.

Reduzir o FOMO no longo prazo requer confiança de que as informações serão fáceis de encontrar quando você precisar delas, de modo que você não precise buscá-la compulsivamente. Uma boa arquitetura de informação é fundamental para construir essa confiança – a informação deve ser bem identificada, bem classificada, pesquisável e fácil de navegar.

🤐 Divulgação de informações confidenciais ou sensíveis

Public-by-default ainda exige discrição e tato. Isso não significa que ninguém possa guardar segredos, nem que todas as discussões devam ser realizadas publicamente. Não exige que revelemos tudo. Ainda precisamos nos preocupar com a privacidade e a segurança da informação. Portanto, ainda precisamos ser cuidadosos e proteger adequadamente as informações que, se divulgadas:

  • Pode comprometer a segurança ou a privacidade de qualquer membro da equipe, usuário, parceiro ou cliente
  • Pode prejudicar a confiança (por exemplo, compartilhar um segredo que nos foi confiado por outra pessoa ou uma captura de tela de uma conversa particular sem permissão)
  • Pode violar um NDA, a lei, ou um acordo entre partes.

As informações pessoais geralmente pertencem a camada mais privada.

Para concluir: mentalidade

A maioria de nós tende a ser naturalmente cautelosa em compartilhar informações com o público externo. Tememos que outros possam copiar nossa ideia ou nossa estratégia, tememos parecer mal se alguém der uma olhada naquele rascunho inacabado, tememos parecer bobos para fazer perguntas básicas, tememos receber críticas públicas.

Nosso objetivo é construir um espaço seguro onde todos são encorajados a compartilhar, tanto interna como publicamente.

Aceitamos perguntas, críticas e um debate saudável por nos permitir confrontar nossas ideias.

Estamos mais preocupados em encontrar a solução do que parecer bem na fita.

É por isso que fazemos publicamente – para que possamos aprender mais rápido.

Sobre Filipe Borges 11 Artigos
Coordenador do time de desenvolvimento na BNP Soluções em TI. Ex-treinador de overwatch. Viciado em resolução de problemas. Sommelier de café não-oficial e pai do Heitor

Seja o primeiro a comentar

Faça um comentário

Seu e-mail não será divulgado.


*