Merci beaucoup pour vos conseils @tobiaseigen concernant Discourse for Teams. Et c’est une excellente nouvelle, @david ! La gestion des travaux en cours sera encore plus facile maintenant. J’aimerais profiter de ce post pour vous dire quelles ont été les fonctionnalités déterminantes qui nous ont fait passer à Discourse.
Contexte
Nous sommes une équipe de développeurs de logiciels, d’analystes fonctionnels et d’administrateurs systèmes dédiée à la création de solutions de gestion d’entreprise pour le marché colombien, bien que le monde entier figure dans notre feuille de route ;). Nous développons des logiciels sur mesure pour nos clients et possédons nos propres produits originaux, mais notre activité principale consiste actuellement à fournir des services et des extensions basés sur l’ERP Odoo. Parmi toutes les applications incluses dans Odoo, nous nous sommes spécialisés dans la gestion comptable, les stocks et les ressources humaines. Comme vous pouvez vous y attendre, nous utilisons largement Odoo nous-mêmes et, depuis notre création en 2015, son application de gestion de projet a été notre meilleur allié. Grâce à son interface Kanban (à la Trello), elle permet à notre équipe de gérer le flux de travail des tâches convenues pour chaque projet de mise en œuvre. Cependant, la mise en œuvre d’un projet n’est que le début de la relation avec une entreprise cliente, et c’est pendant la période de maintenance que les choses peuvent se compliquer si une gestion efficace et une communication orientée vers le client ne sont pas assurées. Odoo dispose d’une application de service d’assistance (Helpdesk) permettant de gérer une communication basée sur des tickets avec les utilisateurs de votre logiciel via e-mail. Bien sûr, nous l’utilisons également pour fournir nos services de support. Les réponses rapides aux questions fonctionnelles sont faciles à gérer avec cet outil, mais lorsqu’un rapport de bug complexe est reçu, un document séparé doit être généré pour aider au processus de développement. Dans ces cas, nous avons utilisé Gitlab et Github Issues, ainsi que des fichiers restructuredtext personnalisés sous contrôle de version (analysés avec des outils internes développés en Python) pour établir un format de signalement d’incidents indépendant du fournisseur. Finalement, nous nous sommes retrouvés dans une situation où le travail à accomplir devait être recherché dans au moins trois endroits différents, utilisant des interfaces et des flux de travail distincts. À la fois la communication externe et interne nécessaire à nos activités quotidiennes était compromise, ce qui nous a poussés à chercher des processus et des outils alternatifs, même si cela impliquait de fracturer notre « centrisme Odoo ». Discourse est très connu en tant que logiciel de forum depuis de nombreuses années, mais nous n’avons découvert ses fonctionnalités de gestion de travail que très récemment, après avoir effectué des recherches. Trois éléments nous ont incités à l’essayer : la communication asynchrone, l’homogénéisation de la définition du travail et le contrôle du travail en cours (WIP).
Communication asynchrone
Les posts Discourse sont comme des e-mails, mais meilleurs. Dans un monde dominé par Whatsapp, Slack, Messenger, Mattermost, Odoo Chat et bien d’autres, nous avons pris l’habitude d’être constamment en mode « alerte ». Comme tout semble urgent, on est poussé à répondre par des réponses courtes, rapides et superficielles. Pas le temps de réfléchir, pas le temps de corriger. Écrire et envoyer. Écrire ce post, par exemple, m’a pris beaucoup plus de temps que prévu, mais je le fais après avoir terminé d’autres tâches plus pressantes, afin de pouvoir me concentrer sur un retour sincère et élaboré (le minimum que je puisse faire pour un outil aussi agréable que Discourse). Écrire un post est comme envoyer un e-mail, mais le lire est une toute autre histoire. Une bien meilleure. Les posts sont centralisés et partagés entre tous les membres d’une équipe (ou ceux qui y sont autorisés). Ils peuvent être recherchés par leur contenu ou leur emplacement (c’est-à-dire les sujets et les catégories) et même être accessibles aux utilisateurs externes ou aux membres du personnel qui n’ont pas participé à la conversation originale, ce qui est excellent pour conserver l’historique des décisions prises et de leur contexte. Note rapide : Le fait que python.org ait adopté Discourse comme application de gestion de communauté, plutôt que des listes de diffusion ou d’autres solutions basées sur Python, montre que ce que nous avons ici est véritablement exceptionnel en termes d’adéquation, de performance et d’accessibilité.
Homogénéisation de la définition du travail
C’est la raison principale pour laquelle nous passons à Discourse. D’après le contexte présenté plus haut, vous avez peut-être imaginé un environnement de travail très coloré et complexe. J’ai certainement été un peu trop dramatique, car nous avons effectivement disposé de processus documentés et d’outils numériques pour gérer nos activités depuis notre fondation. Mais ce qui s’est produit avec le temps, c’est que nous n’avons pas réussi à avoir une représentation unique du travail au sein de l’entreprise. Oui, nous avions des tâches pour les activités de conseil et des tickets pour le support. Le développement était piloté par des exigences documentées en texte brut ou par les problèmes bien connus liés à Git. Ce n’était pas une question de manque, mais au contraire, d’excès. Il y avait trop de sources d’information et même au sein d’une application commune (par exemple Odoo), il existait plusieurs formats (par exemple Tâche, Ticket, Problème). Bien sûr, nous aurions pu choisir l’un des instruments mentionnés ci-dessus comme seule source de vérité, mais aucun d’entre eux ne nous offrait un élément crucial : un retour d’information externe intégré. Après seulement un mois d’utilisation de Discourse, nous ressentons enfin que nous nous connectons avec les utilisateurs de nos produits. Il n’y a plus de distinction entre eux et nous, car nous utilisons tous la même interface. Cependant, nous n’avons pas à renoncer au contrôle sur la manière dont nous gérons notre travail, car certaines zones et capacités peuvent être restreintes. Mais le meilleur de tout est que, grâce aux Sujets de Discourse, ces mêmes artefacts, qui ressemblent à des commentaires de blog ou à des tickets de service d’assistance, que nous utilisons pour comprendre les besoins de nos clients, peuvent être utilisés par nous dans des catégories internes privées pour représenter les tâches planifiées à effectuer, les problèmes à traiter ou les activités opérationnelles à réaliser. Pour nous, un sujet a plusieurs synonymes, tous valables selon leur contexte : Problème, Tâche, Ticket, Activité, Liste de contrôle, appelez-le comme vous voulez. Une forme homogène de travail qui est ouverte, accessible et gérée de manière centralisée. J’ai lu que, avec Discourse for Teams, vous prévoyez de livrer un produit distinct du forum Discourse, ou en d’autres termes, que Discourse (Forum) et Discourse for Teams sont destinés à être déployés comme deux instances différentes. Je vous recommanderais de réfléchir patiemment à cela, car cette conception fracturera inévitablement l’intégration actuellement fournie entre les parties externes et internes d’une organisation.
Contrôle du travail en cours (WIP)
Enfin, l’une des meilleures surprises que nous ayons eues grâce à l’utilisation de Discourse est que nous pouvons enfin établir un contrôle sur le travail en cours au sein de l’organisation. Parce que le travail à accomplir a toutes la même « forme », il est facile de définir des politiques pour limiter la quantité de travail que l’organisation devrait avoir à tout moment. Grâce au plugin Assign, les tâches sont attribuées à un responsable unique qui doit chercher de l’aide si nécessaire (ce qui est un ‘@’ au loin), puis, en utilisant une interface unifiée (trouvée à ‘/g/staff/assigned/everyone’), la quantité d’activités en cours (c’est-à-dire le WIP) dans l’ensemble du système peut être contrôlée. Actuellement, par exemple, nous itérons avec un WIP par personne de 5 tâches/sujets/incidents. Comme nous sommes 14, cela signifie que notre capacité maximale en tant qu’équipe devrait être de 70. C’est très important pour nous car cela aide à apporter de la stabilité à l’une des entreprises les plus difficiles de la vie : l’estimation. Selon la loi de Little (Little's law - Wikipedia), le nombre moyen à long terme d’éléments dans une file d’attente est égal à son taux d’arrivée moyen ou son débit, multiplié par le temps d’attente moyen que chacun de ces éléments passe dans le système. Ainsi, avec un WIP contraint de 70 éléments, si nous recevons 140 tickets par semaine, ils seront en moyenne complétés en 0,5 semaine, et ce serait 0,33 semaine en moyenne si nous recevions 210. Cela suppose bien sûr que le système est dans un état stable et que la file d’attente n’augmente pas indéfiniment, de sorte qu’un étalonnage approprié du WIP doit être effectué de manière itérative. Nous avons toujours (et aurons toujours) des quantités moindres de types de travail qui ne pourront pas être représentés dans Discourse, tels que la gestion de nos messages e-mail ou de notre pipeline CRM, mais comme la majorité de notre travail à accomplir a maintenant une forme unique sous forme de Sujets Discourse, la mise en œuvre de pratiques Kanban et Agile telles que la limitation du WIP sera beaucoup plus facile. C’est pourquoi je conseillerais que, si Discourse for Teams est destiné à être une instance séparée de Discourse Forum, ce serait dommage de ne pas avoir une manière fédérée de maintenir une vue centralisée et composée du WIP dans les deux systèmes.
J’espère que ce post aidera à améliorer Discourse en tant que plateforme de communication et de construction de communauté. Encore une fois, merci beaucoup pour tout et je vous souhaite le meilleur à tous !
displays search with “Search posts by @tobiaseigen” tickbox. It would make more sense to see “Search assigned to @tobiaseigen”.
