Collaborer peut s’avérer difficile. La vraie compétence consiste à construire un système que les gens trouveront intéressant et agréable à utiliser. Dans un article précédent, j’ai expliqué ^{comment les systèmes de conception pouvaient aider les organisations à créer d’excellentes expériences à grande échelle}. Dans cet article, j’aimerais approfondir sur la façon dont nous avons organisé le système de collaboration et géré certaines des difficultés rencontrées durant la mise en œuvre.

Des problèmes de plateforme

En 2014, avant de nous lancer dans l’aventure de notre système de conception, TELUS utilisait une feuille de style CSS maîtresse affectueusement nommée Frogger. Cet outil fournissait aux responsables des résultats un arsenal de boutons, de styles de formes, etc. de type Bootstrap qu’ils pouvaient utiliser pour créer des expériences uniformes d’une équipe AGILE à l’autre. Aucune équipe n’était vraiment responsable de cette feuille de style CSS. Les membres des équipes ont rapidement commencé à concevoir leurs propres moyens de contournement pour résoudre des problèmes qui leur étaient propres. Les équipes devaient continuer de travailler en harmonie, mais plus l’équipe Stratégie numérique grandissait, plus les styles divergeaient. Les styles étaient dupliqués un peu partout, ce qui occasionnait des pertes de temps et mettait en danger la réputation de TELUS, une marque primée.

Le problème ne se limitait pas à la conception : chaque équipe avait adopté son propre langage et son propre cadre de programmation afin de relever ses propres défis. L’équipe de direction a réalisé que le problème en était un de plateforme et que nous avions donc besoin d’une plateforme pour le régler.

Faire table rase

Pour aider les équipes responsables des fonctions, nous avons eu l’occasion unique de rebâtir l’infrastructure de Stratégie numérique de TELUS à partir de zéro. Après beaucoup de recherches et de tests, nous avons entrepris de créer une pile React ou Node.js dont la gouvernance reposerait sur des principes clairs d’accès libre. Cette configuration est devenue la ^{plateforme numérique de TELUS}.

Ce système à contribution ouverte fonctionnait à merveille pour l’aspect technique de la plateforme, mais entraînait des difficultés croissantes sur le plan de la conception. Sans guide d’orientation, le système de conception était long à démarrer. Il était difficile d’obtenir le consensus des divers responsables de la conception sur la direction à prendre. Chaque personne avait son opinion, et toutes les opinions se valaient. De plus, uniformiser l’architecture des systèmes de composants posait problème. Les responsables des technologies comptent parmi les personnes les plus occupées à TELUS, alors les rassembler en un même endroit pour prendre une décision n’est pas facile. Nous ne voyions pas en quoi cette plateforme était plus efficace que la feuille de style Frogger, et nous recevions de commentaires négatifs de la part de nos équipes internes en raison de la lenteur de nos progrès. Nous avons donc pris la dure décision d’arrêter la mise en œuvre initiale et de nous attaquer au problème de front.

Quand la conception rencontre la théorie

Il est important d’établir une gouvernance bien équilibrée dans une grande équipe de concepteurs et de développeurs. La communication entre les fuseaux horaires et les disciplines nécessitait une méthode soigneusement élaborée. Nous nous sommes donc installés confortablement, avons acheté beaucoup de livres et avons commencé nos recherches. 

 Nathan Curtis est l’un des plus grands leaders d’opinion en matière de systèmes de conception. En 2015, il a écrit un article fantastique sur sa méthode communément appelée ^{Federated Design System} (système de conception fédéré). Pour ceux qui ne l’ont pas lu, c’est un incontournable! Nous avons trouvé bon nombre des solutions à nos problèmes dans cet article qui décrit les trois types de structure de conception que l’auteur a observés : isolée, centralisée et fédérée.

Parallèlement, nous avions pensé à la ^{théorie et topologie des réseaux}. En tant que géant des télécommunications, nous sommes des experts de la topologie des réseaux. Nous comprenons que la façon dont nous choisissons d’organiser le flux d’information peut avoir d’immenses répercussions sur la vitesse à laquelle celle-ci voyage et sur sa résilience aux erreurs. 

 En combinant ces deux idées, nous avons pu brosser le portrait complet de la situation. Notre problème est alors devenu clair et limpide. Nous avions commencé avec une structure isolée : la feuille de style CSS maîtresse. C’était comme utiliser un réseau maillé comportant de nombreux nœuds, tous connectés les uns aux autres. Les réseaux maillés sont très insensibles aux défaillances, car les erreurs ne s’y répandent pas facilement ni rapidement. Toutefois, bien qu’ils facilitent l’intégration, le consensus devient de plus en plus difficile à obtenir à mesure qu’ils prennent de l’ampleur, et les équipes qui les utilisent risquent de plus en plus de commettre des erreurs. La décision de passer à un modèle de libre accès n’a pas changé la topologie du réseau. Tout était resté du pareil au même.

Le modèle centralisé peut être comparé à un réseau en étoile sur le plan de la topologie. Les réseaux en étoile garantissent l’exactitude parce qu’une source unique de vérité transmet de l’information uniforme à chaque branche de l’étoile. Ils sont également très rapides, parce que le centre de l’étoile est le seul à approuver les décisions. Toutefois, il peut être difficile de les faire évoluer, car toute l’information doit passer par ce centre. La seule façon d’augmenter la largeur de bande sur le réseau est d’augmenter la taille du centre, qui agit comme un goulot d’étranglement.

Le modèle fédéré décrit par Nathan Curtis est essentiellement un réseau arborescent : l’hybride parfait. Les réseaux arborescents :

sont faciles à faire évoluer – il suffit d’y ajouter des branches;

facilitent le consensus – les nœuds à la base de chaque branche valident toutes les décisions;

sont insensibles aux défaillances – les erreurs sont confinées à chaque branche;

favorisent les processus – les nœuds des branches accélèrent la transmission de l’information.

Une stratégie par étapes

Enfin, il nous est paru évident qu’il fallait privilégier et viser le modèle fédéré, mais nous devions rattraper notre retard dans le reste de la plateforme. Maintenant que nous avions clairement disséqué le problème, nous pouvions analyser les compromis à faire pour chaque option. Nous avons décidé de commencer avec un système centralisé, car c’était le système le plus rapide et qui procurait le plus d’exactitude. Cela nous aiderait à créer les éléments fondamentaux et à jeter les bases d’un fantastique système de conception évolutif. Plus tard, nous ferions la transition vers une solution fédérée pour lancer le système dans toutes les équipes.

Passons maintenant à 2017. La version 1 avait subi 56 itérations au stade bêta et était rigoureusement testée par des équipes internes et externes. L’organisation l’avait lancée en fanfare lors du sommet des partenaires de la marque TELUS à Toronto. Il était temps de commencer à travailler à respecter notre promesse de décentraliser le modèle pour passer à un système fédéré.

Nous avions eu beaucoup de temps pour y penser, et, tout au long du mois de décembre, nous avions élaboré un plan d’attaque.

Diviser les composants du système monolithique

Les composants devaient être séparés de manière à ce que chaque lancement ne requière pas la mise à niveau de tout le système – ce qui est essentiel si vous n’avez pas d’équipe centralisée pour coordonner chaque mise à niveau.

Séparer les composants fondamentaux des composants propres à la communauté

Nous avons réalisé que deux types de composants avaient été développés. Les éléments les plus fondamentaux étaient utilisés par presque toutes les équipes et représentaient les principes directeurs de la marque TELUS. Nous avons décidé que, parce que ces composants étaient si cruciaux, leur gestion resterait centralisée, ce qui réduit les risques d’erreur en ce qui concerne la communication.

Création des branches

Afin de créer les branches et de les relier au système par des nœuds, nous avons créé le concept d’ambassadeurs de la plateforme numérique – qui désignait le responsable de la conception et le responsable des technologies de chaque unité d’affaires. Ces personnes sont les principaux points de liaison de chaque équipe responsable des résultats. Avec un peu de chance, ils permettraient la communication la plus directe possible dans le système.

S’entendre sur les principes et lignes directrices de la communauté

La dernière étape consistait à nous entendre sur la façon dont nous allions tous communiquer et travailler ensemble. Lors d’une réunion, les ambassadeurs de la plateforme numérique se sont entendus sur ces principes et se sont assurés d’obtenir l’adhésion de chaque unité d’affaires. Ils ont aussi déterminé la fréquence, le format et le processus pour tous les ajouts futurs.

Un système prêt à évoluer

Le temps est maintenant venu de nous fier à nos acquis. Nous croyons avoir développé un produit et un ensemble de processus dont les équipes ne peuvent plus se passer. Au cours des prochaines semaines, nous commencerons à prendre nos distances. De noyau central de régulation, nous deviendrons une des branches du système. Pour ce faire, nous avons donné libre accès aux composants TDS-Core et de communauté dans Github et créé la documentation connexe. Nous espérons que la découverte et le partage des composants prêts à utiliser dans la conception s’accéléreront spectaculairement dans les prochains mois, alors que les équipes commenceront à travailler ensemble à la création de composants que tous pourront utiliser. Tandis que la quantité de composants augmentera, nous espérons aussi voir une explosion de productivité et de créativité, car les équipes pourront cesser de se concentrer sur des tâches banales pour réaliser des choses extraordinaires.

Jack est stratège principal au sein de l’équipe responsable de la stratégie de conception. Il a à cœur de créer des expériences et des relations authentiques pour améliorer la vie des clients. Apprenez-en plus sur lui à ^{http://www.jackreeves.eu}