J’apprécie que l’équipe Discourse soit ouverte aux suggestions des nouveaux venus, ici et ailleurs.
J’ai vu ce problème se produire souvent sur Meta au fil des ans, mais cela m’a incité à partager également mes réflexions en général. Cela m’avait également frustré de le voir, mais je ne savais pas vraiment comment soulever la question. Je vais donc essayer d’en parler maintenant :
Contexte
Parfois, sur Meta, j’ai vu une tendance à s’acharner sur les suggestions des nouveaux venus concernant les fonctionnalités ou les changements de Discourse. Au lieu d’écouter et de comprendre l’expérience des personnes plus novices avec le logiciel – dont les idées peuvent être utiles même à ceux d’entre nous qui utilisent Discourse depuis plus de 10 ans – parfois des membres de la communauté démolissent préventivement l’idée.
Souvent, cela se produit si une idée a été rejetée par le passé par l’équipe Discourse, ou si un paramètre par défaut particulier a été choisi plutôt que d’autres configurations par l’équipe Discourse, etc.
Même si tel est le cas, je voudrais offrir mes réflexions sur la raison pour laquelle nous ne devrions pas rejeter préventivement les idées ou les plaintes concernant le logiciel, même si elles ont déjà été discutées par le passé.
L’équipe Discourse a le dernier mot. Beaucoup de choses ont changé. Les choses d’alors ne s’appliquent peut-être plus maintenant.
Premièrement, nous, en tant que membres de la communauté, ne sommes pas les chefs de produit pour Discourse. Si nous nous précipitons pour dire à quelqu’un que son idée a été rejetée par le passé et pourquoi, cela ne reflète pas nécessairement les décisions actuelles de l’équipe produit Discourse.
Parfois, même l’équipe Discourse peut décider de travailler sur une fonctionnalité qui avait été précédemment écartée. Pendant longtemps, le chat a été une telle fonctionnalité.
Il ne fait aucun doute que nous avons besoin d’un support “voie rapide” (chat) et “voie lente” (sujet) côte à côte. C’est ma faute si nous ne l’avons pas fait plus tôt, mais soyez assurés que ce sera un tout autre niveau de finition super brillante avec une intégration complète.
Il n’y a donc jamais de garantie à 100 % que les décisions passées seront les mêmes que les décisions présentes.
Même les membres de l’équipe Discourse peuvent avoir des points de vue différents les uns des autres concernant ce qui devrait être une priorité pour Discourse.
Par exemple, j’ai souvent suivi le blog de @erlend_sh et il y discute de la façon dont il avait une opinion différente du reste de l’équipe sur la façon dont le chat devrait être dans Discourse – l’emphase en gras est de moi :
La plupart des projets open source n’ont pas de forum dédié, mais ceux qui en ont ont presque certainement aussi un chat de groupe. Mon dernier passage chez Discourse a été une tentative de fusionner les deux modes, avec l’introduction de Discourse Chat.
Je suis vraiment fier de ce MVP (qui est depuis passé au cœur du projet), mais la direction que je voulais prendre à partir de là était compréhensiblement incompatible avec l’ADN du projet Discourse en tant que forum traditionnel : j’ai proposé que le chat soit le principal de notre expérience communautaire. La communauté commence dans les salons de discussion, pensais-je. Discourse n’était pas d’accord, alors nous nous sommes séparés à l’amiable.
Des années plus tard, ma position reste inchangée. Le “chat de groupe” et le “forum” devraient signifier à peu près la même chose. C’est d’ailleurs la direction dans laquelle nous semblons nous diriger, puisque Discord, maître de nos terres communautaires, prend désormais en charge une variété de fonctionnalités de fils et de tableaux qui s’intègrent parfaitement dans le paradigme du forum.
Il n’appartient donc pas vraiment à nous de décider prématurément de ce qui ne devrait pas être inclus dans Discourse, car cela peut aussi changer avec le temps.
Ceux d’entre nous qui étaient là aux débuts de Discourse se souviendront quand CDCK comptait moins de 10 personnes et que la gestion de produit était souvent très axée sur les cofondateurs de Discourse. Mais aujourd’hui, CDCK compte 100 personnes et CDCK a une équipe produit entière !
Discourse lui-même a une base d’utilisateurs beaucoup, beaucoup plus large, dont les besoins et l’utilisation du logiciel ont grandi au-delà des premiers adoptants initiaux de Discourse. Plus largement, le paysage des plateformes sociales a changé (l’élan est passé de Facebook à Discord et plus encore, etc.), et les attentes générales des gens ont changé.
Étant donné que l’équipe est beaucoup plus grande qu’aux débuts de Discourse, elle a plus de capacité à travailler sur d’autres fonctionnalités qui pouvaient être de priorité beaucoup plus faible pendant les premiers jours du développement du produit, dans le passé.
La façon dont ils examinent les demandes de fonctionnalités maintenant sera probablement très différente de celle du début. L’équipe produit aura son propre processus de prise de décision et de détermination de ce qui sera finalement réalisé et quand.
Plus de points de données, c’est mieux
Deuxièmement, il est généralement utile pour l’équipe Discourse d’entendre plus de points de données plutôt que moins.
Il y avait quelque chose largement popularisé sur Meta comme une Règle des 3 (un minimum de 3 personnes se plaignent de quelque chose avant que cette demande de fonctionnalité ne soit prise en compte). Même avec cela, il faut laisser les gens partager leurs expériences et se plaindre, afin d’entendre 3 personnes différentes trouver un problème avec quelque chose.
En dehors de cela, une autre idée popularisée était le développement piloté par les plaintes. Et avec cela, vous devez également écouter les opinions des gens :
La seule chose que j’ai jamais vue fonctionner est de descendre dans les tranchées avec vos utilisateurs, de communiquer avec eux et de cultiver des relations.
Après avoir relu cela, je soumets également très fortement que la prémisse originale derrière cette “règle des 3” n’est PAS que votre opinion n’a pas d’importance si personne d’autre ne s’en plaint.
Le cœur de la question était que (surtout si vous êtes une équipe à faibles ressources) trouver les choses dont les gens se plaignent le plus est un moyen efficace de trouver les problèmes qui dérangent le plus vos utilisateurs – afin de les résoudre en premier.
Comme le dit Steve Krug dans Don’t Make Me Think :
Vous trouverez toujours plus de problèmes que vous n’avez de ressources pour les résoudre, il est donc très important de vous concentrer sur la résolution des plus graves en premier. Et trois utilisateurs rencontreront très probablement bon nombre des problèmes les plus importants liés aux tâches que vous testez.
Donc, ce n’est pas parce que peu d’autres personnes se sont plaintes de la même chose que cela n’a pas d’importance. Davantage de points de données sont toujours utiles pour l’équipe Discourse lorsqu’elle examine les points douloureux majeurs/mineurs actuels pour les utilisateurs.
Il est possible d’apprécier les commentaires des gens, même si vous ne les mettez pas en œuvre
Troisièmement, il est toujours possible de remercier les gens pour leurs commentaires, même si vous ne pouvez pas mettre en œuvre toutes leurs suggestions ou si vous avez décidé de ne pas le faire.
J’ai acquis plus d’expérience dans la gestion des commentaires de cette manière, après avoir étudié la conception de jeux où donner et recevoir des commentaires était une partie énorme du processus. Sur les itérations de chaque niveau de jeu, document de conception, ou quoi que ce soit, nous donnions des commentaires sur le travail d’au moins 3 autres personnes et recevions des commentaires d’au moins 3 autres. J’essayais souvent de donner des commentaires pour 4 ou 5 personnes pour compenser l’absence d’autres personnes / la soumission tardive de leurs devoirs, etc.
Souvent, les commentaires sont très perspicaces et utiles, mais il y a plus de 10 points importants et vous n’avez actuellement le temps d’en mettre en œuvre que 1 à 3.
Cela a également été le cas lorsque j’ai travaillé professionnellement en tant qu’ingénieur logiciel, interagissant souvent avec la communauté, dans le cadre d’une petite startup. Il peut y avoir plus de 10 rapports de bugs importants, mais dans la prochaine mise à jour, vous avez le temps d’en corriger 1 à 3.
Dans tous les cas, je me sens toujours très obligé de remercier les gens pour leurs observations, de les remercier d’avoir partagé leurs réflexions, de les remercier d’avoir pris le temps de décrire les étapes pour reproduire un bug et de m’excuser pour le désagrément.
La plupart du temps, les utilisateurs/joueurs ne disent rien à moins d’être vraiment dérangés. Donc, la plupart des commentaires écrits / demandes de fonctionnalités / rapports de bugs proviennent de quelqu’un qui a pris le temps de partager ses réflexions sur quelque chose – des choses auxquelles beaucoup d’autres ont peut-être pensé mais n’ont pas encore identifiées ou dites, des choses que vous avez probablement manquées, et ainsi de suite.
Donc, même si vous ne pouvez pas mettre en œuvre tout ce que tout le monde dit – ce qui peut même être 90 % du temps – cela ne signifie pas que vous devez vous jeter sur tous ces commentaires et les rejeter. Les commentaires sont toujours importants, même si vous n’avez pas les ressources pour y donner suite maintenant ou même si vous avez décidé de ne pas y donner suite.
Quoi qu’il en soit, c’est pourquoi je pense qu’il vaut la peine, pour nous en tant que membres de la communauté, de laisser les nouveaux venus partager leurs réflexions et de ne pas sauter immédiatement pour rejeter les suggestions des gens pour Discourse. En effet, la position de l’équipe Discourse sur les fonctionnalités peut changer avec le temps, et les commentaires restent utiles comme points de données pour l’équipe Discourse, même si elle ne les met pas en œuvre immédiatement.