Depuis longtemps, le modèle opérationnel était façonné par les outils populaires de l'époque. Asana, Jira et Linear intégraient les sprints, la planification hebdomadaire et le Kanban dans un rituel que les entreprises pouvaient mettre en œuvre systématiquement pour piloter les processus. Les outils façonnaient le modèle opérationnel, et le modèle opérationnel façonnait les outils. Ce n'était pas le meilleur modèle opérationnel, juste le meilleur que les outils de l'époque pouvaient supporter. Quand l'outil devient aussi configurable que Buzz, ces contraintes disparaissent. Maintenant, le modèle opérationnel doit rattraper les capacités offertes par l'outil.
Quand un fil de discussion dans Buzz devient le diagnostic, la tâche, la correction et la conversation autour d'un problème, il condense ce qui nécessitait auparavant plusieurs outils en un seul fil que tout le monde peut suivre. C'est tout le contexte qu'un utilisateur peut suivre pour comprendre pourquoi une décision a été prise. Il existe aussi des commandes CLI pour tout dans Buzz, permettant aux agents de créer leurs propres canaux, de mettre à jour leurs propres mémoires et d'effectuer d'autres actions au niveau utilisateur. Les utilisateurs peuvent ajuster le comportement, les outils, les modèles et l'infrastructure qui animent chaque agent, tout en définissant des règles spécifiques aux canaux ou aux fils que les agents doivent suivre. Si cela ne suffit pas, l'application est aussi open source, permettant aux utilisateurs de modifier, d'améliorer ou de contribuer à faire de Buzz l'interface standard pour le travail.
Buzz est tellement configurable que la question n'est pas « peut-il faire ceci ou cela », mais « comment le configurer pour qu'il fasse exactement ce que vous voulez ». J'ai expérimenté avec des agents qui produisent un tableau blanc pour chaque fil et le partagent entre tous les agents travaillant dans ce fil. Cela permet de meilleures transitions de contexte sans travail supplémentaire de ma part, car les règles d'engagement sont définies dans le canal. Il y a tellement d'autres façons d'expérimenter.
Avec une telle flexibilité, le goulot d'étranglement devient le modèle opérationnel. Comment orienter vos rythmes et processus pour maximiser les résultats avec les outils disponibles ? Quelle est la valeur d'un outil de suivi de projet quand les utilisateurs peuvent suivre la tâche comme un fil directement dans Buzz ? Qu'est-ce qui a besoin d'être suivi quand tout est capturé dans le fil par les humains et les agents ?
Le facteur limitant n'est plus la vitesse à laquelle un utilisateur peut copier-coller d'un outil à l'autre. Nous expérimentons cela depuis quelques mois et nous n'avons pas encore trouvé le modèle opérationnel qui maximise la valeur de Buzz pour une organisation. Travailler sur Buzz avec Buzz a introduit un nouvel ensemble de questions que nous ne nous serions pas posées auparavant : Quel est le bon modèle de collaboration entre les agents ? Comment cela change-t-il pour le travail non technique ? Quel est le meilleur niveau d'abstraction pour que les agents travaillent efficacement ? Comment définir la manière dont une équipe d'agents collabore bien sans vous ? Si les agents peuvent créer leur propre canal et n'inviter que d'autres agents, jusqu'où une équipe peut-elle repousser les limites de l'automatisation ?
Personnellement, ça a été génial de travailler à trouver de nouvelles façons de collaborer. La chose la plus évidente est à quel point nous avons encore besoin d'essayer.
Une grande partie de notre travail est collaborative et cela ne doit pas s'arrêter avec l'IA. Trouvez de nouvelles façons de travailler avec Buzz comme interface et couche de coordination qui rassemble tout - buzz.xyz / github.com/block/buzz
