Muito obrigado pela sua orientação, @tobiaseigen, sobre o Discourse for Teams. Além disso, essas são ótimas notícias, @david! Gerenciar o trabalho pendente ficará ainda mais fácil agora. Gostaria de usar este post para contar quais foram os recursos decisivos que nos fizeram migrar para o Discourse.
Contexto
Somos uma equipe de desenvolvedores de software, analistas funcionais e administradores de sistemas dedicados a criar soluções de gestão empresarial para o mercado colombiano, embora o mundo inteiro esteja em nosso roteiro ;). Desenvolvemos software personalizado para nossos clientes e também temos nossos próprios produtos originais, mas atualmente nossa principal linha de negócios é oferecer serviços e extensões sobre o ERP Odoo. Entre todas as aplicações incluídas no Odoo, especializamos-nos nas áreas de Contabilidade, Estoque e Gestão de Recursos Humanos. Como você pode imaginar, usamos o Odoo extensivamente e, desde nossa fundação em 2015, sua aplicação de Gerenciamento de Projetos tem sido nossa melhor aliada. Com sua interface Kanban (estilo Trello), ela permite que nossa equipe gerencie o fluxo de trabalho das tarefas acordadas em cada projeto de implementação. No entanto, a implementação de um projeto é apenas o início do relacionamento com uma empresa cliente, e é no período de manutenção que as coisas podem ficar complicadas se não houver gestão eficiente e comunicação voltada para o cliente. Mas o Odoo possui uma aplicação de Helpdesk que você pode usar para gerenciar uma comunicação baseada em tickets com os usuários do seu software por e-mail e, claro, novamente, temos usado essa ferramenta para oferecer nossos serviços de suporte. Respostas rápidas a perguntas funcionais têm sido fáceis de gerenciar por meio dessa ferramenta, mas quando um relatório de bug complexo é recebido, é necessário gerar um documento separado para auxiliar no processo de desenvolvimento. Nesses casos, temos usado o Gitlab e o Github Issues, e até mesmo arquivos restructuredtext controlados por versão personalizados (analisados com ferramentas internas desenvolvidas em Python) para estabelecer um formato de relatório de problemas independente de fornecedor. No final, nos encontramos em uma situação em que o trabalho a ser feito precisava ser buscado em pelo menos três lugares diferentes, usando interfaces e fluxos de trabalho distintos. Tanto a comunicação externa quanto a interna para cumprir nossas atividades diárias estava em risco, o que nos levou a buscar processos e ferramentas alternativas, mesmo que isso implicasse fragmentar nosso “centralismo Odoo”. O Discourse é muito famoso como software de fórum há muitos anos, mas só conhecemos seus recursos de gerenciamento de atividades muito recentemente, após realizar algumas pesquisas. O que nos motivou a experimentá-lo foram três coisas: comunicação assíncrona, homogeneização da definição de trabalho e controle de trabalho em andamento (WIP).
Comunicação Assíncrona
Os posts do Discourse são como e-mails, mas melhores. Em um mundo de Whatsapp, Slack, Messenger, Mattermost, Odoo Chat e muitos outros, nos acostumamos a estar sempre em modo de “alerta”. Como tudo parece urgente, somos pressionados a responder com respostas curtas, rápidas e superficiais. Sem tempo para pensar, sem tempo para revisar. Apenas escreva e envie. Escrever este post, por exemplo, levou muito mais tempo do que eu havia previsto, mas estou fazendo isso após concluir outras tarefas mais urgentes, para que eu possa me concentrar em fornecer o feedback mais sincero e elaborado possível (o mínimo que posso fazer, de fato, por uma ferramenta tão agradável quanto o Discourse). Escrever um post é como enviar um e-mail, mas lê-lo é uma história completamente diferente. Uma história muito melhor. Os posts são centralizados e compartilhados entre todos os membros de uma equipe (ou os autorizados). Eles podem ser pesquisados por seu conteúdo ou localização (ou seja, tópicos e categorias) e até mesmo acessados por usuários externos ou membros da equipe que não participaram da conversa original, o que é ótimo para armazenar o registro histórico de como as decisões são tomadas e qual foi o contexto delas. Nota rápida: Ver como o python.org adotou o Discourse como sua aplicação de gerenciamento de comunidade, em vez de listas de e-mail ou outras soluções baseadas em Python, mostra que o que temos aqui é realmente excepcional em termos de adequação, desempenho e acessibilidade.
Homogeneização da Definição de Trabalho
Esta é a principal razão pela qual estamos migrando para o Discourse. Pelo contexto fornecido anteriormente, você pode ter imaginado um ambiente de trabalho muito colorido e intrincado. Com certeza fui um pouco dramático, pois efetivamente temos processos documentados e ferramentas digitais para gerenciar nossas atividades desde nossa fundação. Mas o que aconteceu com o passar do tempo é que não conseguimos ter uma única representação do trabalho dentro da empresa. Sim, tínhamos tarefas para atividades de consultoria e tickets para suporte. O desenvolvimento era conduzido por meio de requisitos documentados em texto puro ou os bem conhecidos problemas relacionados ao Git. Não era uma questão de falta, mas, pelo contrário, de excesso. Havia muitas fontes de informação e, mesmo dentro de uma aplicação comum (por exemplo, Odoo), havia vários formatos (por exemplo, Tarefa, Ticket, Problema). Claro, poderíamos ter escolhido qualquer um dos instrumentos mencionados acima como nossa única fonte de verdade, mas nenhum deles nos forneceu um elemento crucial: feedback externo integrado. Com apenas um mês de uso do Discourse, finalmente estamos sentindo que estamos nos conectando com os usuários de nossos produtos. Não há distinção entre eles e nós, pois todos usamos a mesma interface. No entanto, não precisamos abrir mão do controle sobre como gerenciamos nosso trabalho, pois algumas áreas e capacidades podem ser restritas. Mas o melhor de tudo é que, por meio dos Tópicos do Discourse, esses mesmos artefatos, que são semelhantes a comentários de blog ou tickets de helpdesk, que usamos para entender as necessidades de nossos clientes, podem ser usados por nós em categorias internas privadas para representar tarefas planejadas a serem feitas, problemas a serem atendidos ou atividades operacionais a serem realizadas. Para nós, um tópico tem vários sinônimos, todos válidos dependendo do contexto: Problema, Tarefa, Ticket, Atividade, Lista de Verificação, o que você preferir. Uma forma homogênea de trabalho que é aberta, acessível e gerenciada centralmente. Li que, com o Discourse for Teams, vocês planejam entregar um produto separado, diferente do fórum Discourse, ou, em outras palavras, que o Discourse (Fórum) e o Discourse for Teams são destinados a serem implantados como duas instâncias diferentes. Eu recomendaria que vocês pensem nisso com paciência, pois esse design inevitavelmente fragmentará a integração atualmente fornecida entre as partes externas e internas de uma organização.
Controle de WIP
Finalmente, uma das melhores surpresas que tivemos com o uso do Discourse é que finalmente podemos estabelecer um controle sobre o trabalho em andamento na organização. Como o trabalho a ser feito tem toda a mesma “forma”, é fácil definir políticas para limitar a quantidade de trabalho que a organização deve ter em qualquer momento. Por meio do plugin Assign, as tarefas recebem um responsável único que deve buscar ajuda conforme necessário (que é um ‘@’ à distância) e, em seguida, usando uma interface unificada (encontrada em ‘/g/staff/assigned/everyone’), a quantidade de atividades em andamento (ou seja, WIP) em todo o sistema pode ser controlada. Agora, por exemplo, estamos iterando com um WIP por pessoa de 5 tarefas/tópicos/problemas. Como somos 14, isso significa que nossa capacidade máxima como equipe deve ser 70. Isso é muito importante para nós, pois ajuda a fornecer estabilidade a uma das tarefas mais difíceis da vida: a estimativa. De acordo com a Lei de Little (Little's law - Wikipedia), o número médio de elementos em uma fila a longo prazo é igual à sua taxa média de chegada ou throughput, multiplicado pelo tempo médio de espera que cada um desses elementos permanece no sistema. Portanto, com um WIP limitado de 70 elementos, se recebermos 140 tickets por semana, eles serão concluídos em média em 0,5 semanas, e seria de 0,33 semanas em média se recebêssemos 210. Isso assume, claro, que o sistema está em um estado estável e que o backlog não está crescendo indefinidamente, portanto, uma calibração adequada do WIP deve ser conduzida de forma iterativa. Ainda (e sempre teremos) quantidades menores de tipos de trabalho que não poderão ser representados no Discourse, como gerenciar nossas mensagens de e-mail ou nosso pipeline de CRM, mas como a maioria do nosso trabalho a ser feito agora tem uma única forma como Tópicos do Discourse, implementar práticas Kanban e Ágeis, como limitar o WIP, será muito mais fácil. É por isso que eu aconselharia que, se o Discourse for Teams for destinado a ser uma instância separada do Discourse Forum, seria uma pena não ter uma maneira federada de manter uma visão centralizada e composta do WIP em ambos os sistemas.
Espero que este post ajude a melhorar o Discourse como plataforma de comunicação e construção de comunidade. Mais uma vez, muito obrigado por isso e desejo a vocês tudo de melhor!
displays search with “Search posts by @tobiaseigen” tickbox. It would make more sense to see “Search assigned to @tobiaseigen”.
