Chez Bonitasoft, l'une des règles qui est régulièrement rappelée aux équipes est : « Ne dites jamais Ça n'est pas mon travail ! »...

...pour nous inciter à rester curieux et prendre des initiatives pour améliorer Bonita et la vie chez Bonitasoft. 

Cela dit, le risque de ce postulat, c’est que chacun·e finisse par s’éparpiller et perde parfois de vue le cœur de ce qu’il·elle est censé·e faire. 

Par contre, comme nous allons le voir, il s’avère que sans ce type d’injonctions, certains projets ne verraient tout simplement pas le jour.

Le projet

J'ai ainsi récemment fait partie d'une équipe en charge de la création du nouveau « Customer Service Center », qui constituera pour nos clients le point d’accès tout-en-un pour bénéficier de nos services : téléchargement de nos produits, support technique, demandes d’expertise ponctuelle pendant un projet, demandes de formations et questions sur l’abonnement.

Dans ce contexte, notre mission première était de développer une application offrant une expérience utilisateur optimisée pour nos clients et nos équipes de services clients. 

Voici ce en quoi ce projet est devenu original et ce qui pour moi explique qu’il a si bien fonctionné.

Plateforme de développement

Tout d’abord, après une longue recherche, une évidence s’est imposée à l’équipe : pour créer la nouvelle application de “Services clients” pour nos clients qui utilisent Bonita au quotidien, rien ne pourrait remplacer Bonita. 

C’est ainsi que nous avons utilisé notre plateforme non seulement pour notre propre usage (ce que nous faisons déjà depuis quelques années avec nos applications internes),  mais aussi pour interagir avec nos clients. 

De plus, son déploiement est aujourd’hui effectif dans le cadre de notre offre Bonita Cloud.

Composition de l’équipe

Voici d’abord la description du poste exercé par chacun·e des membres de l’équipe chez Bonitasoft :

• Le responsable du Support, en charge de l'équipe qui assiste les clients rencontrant des problèmes liés à l’utilisation de la plateforme Bonita (basé à Grenoble)

• Une Product Owner (moi), responsable d’une partie des nouvelles fonctions et améliorations de la plateforme (basée à Grenoble)

• Un consultant, expert technique Bonita qui aide les clients à implémenter leurs projets avec Bonita (basé à Malaga en Espagne)

• Une spécialiste en Marketing digital, en charge du site officiel de Bonitasoft (basée à San Francisco)

Mais voilà, lorsque nous avons entendu parler du projet “Customer Service Center” et des compétences nécessaires à sa réalisation, nous avons décidé de ne pas dire "Ça n'est pas mon travail !”. 

Et c’est ainsi que nous avons tous mis en œuvre d’autres compétences et expériences qui se sont avérées porteuses de valeur ajoutée. 

Ainsi :

• Le responsable Support a appris le rôle de Product Owner. Comprenant parfaitement les attentes des utilisateurs finaux en matière de support client, il a pu décrire le modèle de données et les processus, définir les attentes et les cas d'utilisation et enfin décrire et prioriser finement les développements attendus. Il a également joué le rôle de responsable du projet, prenant les décisions opérationnelles et la communication avec les directeurs de projet.

• En tant que Product Owner, j’ai  soutenu le responsable du support technique dans son rôle de Product Owner, en lui transmettant le savoir-faire acquis durant 4 années à ce poste chez Bonitasoft. En parallèle, j’ai apporté au projet mes compétences de 15 ans en tant que responsable de l’expérience utilisateur (ergonome). En pratique, j’ai aidé l’équipe à rester focalisée sur les besoins de l'utilisateur, j’ai créé les maquettes sur lesquelles le développement a été basé en intégrant les bonnes pratiques en ergonomie du numérique, et j’ai contribué à la rédaction des tests. 

• Notre consultant a pour sa part d’abord convaincu le responsable du projet du bénéfice d’un développement avec Bonita. Puis son expertise en tant que développeur full stack acquise lors de ses précédentes expériences a permis une implémentation de grande qualité.

• Enfin, notre spécialiste en Marketing digital a contribué au projet en tant que graphiste, puisqu’elle apprécie cette activité et … qu’elle est douée pour ça.

Pourquoi et comment ça a fonctionné ?

Je crois que du fait des positions inhabituelles que nous avons occupées pendant ce projet, nous l’avons abordé et vécu avec un état d’esprit plus ouvert. En effet, en plus de nos compétences techniques, nous avons pu facilement exprimer nos compétences inter-personnelles :

1. Éviter les tensions “naturelles” entre Métier’ et ‘Technique’

Dans des contextes précédents, j’ai pu constater que la communication développeur-ergonome et développeur-Product Owner est parfois complexe.

D’abord, n’ayant pas de formation technique, il m’est parfois difficile de savoir ce qui, dans un élément de conception, va être coûteux à implémenter et maintenir, ou ce qui sera facile et mettra en œuvre peu de ressources.

Les équipes de développement avec lesquelles j'ai travaillé dans le passé, alors toutes dévouées à bien réaliser leur tâche d’implémentation, ne se permettaient pas de négocier les spécifications ou le contenu d’une maquette. En essayant d’implémenter au mieux les suggestions, cette approche menait parfois à des dépassements sur le temps de développement et à l’accumulation de frustrations alors que tout le monde avait fait de son mieux.

Une fois que le calendrier n’était plus tenu, il n’y avait plus de bonne solution pour rattraper ce temps dépassé : la tension grandissante était totalement contre-productive, ne permettait plus d’envisager sereinement les aléas rencontrés lors des développements, et contribuait systématiquement à dégrader l’entente entre ‘Métier’ et ‘Technique’, nuisant au bon déroulement du projet… et des suivants.

Mais ce qui aurait pu être tendu et frustrant dans ce projet comme tout autre a été au contraire très plaisant. Voici les principes à retenir de cette expérience réussie : 

• Travailler dur pour instaurer la confiance. Pas de surprise ici. Une fois cette confiance gagnée, les appréhensions disparaissent et la communication s’ouvre : il est alors plus simple de dire « je ne comprends pas » ou « je ne sais pas ».
• Pour le ‘Métier’, beaucoup communiquer avec beaucoup de détails pratiques sur les besoins utilisateurs, afin que la ‘Technique’ puisse se projeter dans l’utilité de ce qui est à créer. Nous avons ainsi pu tous comprendre les " must have " par rapport aux " nice to have " des clients et équipes internes pour envisager la bonne implémentation.
• Pour la ‘Technique’, dire simplement et calmement “non” lorsque la première suggestion d’implémentation semble trop chère en termes de temps ou d’efforts. 
• Mais systématiquement proposer une idée alternative pour faire progresser la discussion.
• Dans cette cinématique de discussion, valoriser les intentions de chacun·e pour que chacun·e se sente considéré·e dans ce qu’il·elle apporte au projet.
• Considérer les erreurs avec humour : tout le monde en fait à un moment ou un autre.
• Être flexible sur les changements : les points réguliers sur le calendrier projet modifient les priorités, poussent à envisager de nouvelles solutions, voire demandent de procéder à des changements. C’est inhérent à la vie du projet. Ne pas s’en offusquer est une clé pour préserver l’entente de l’équipe au cœur de multiples contraintes.

2. Combler l'écart entre « ce que je sais » et « ce que je voudrais que tu saches »

Il n'est pas toujours facile de partager son expertise ou de servir de mentor à quelqu'un pour l'aider à acquérir de nouvelles compétences. Aussi, voici ce que nous avons appris en faisant passer l’application de services clients du projet à la réalité :

• De mon point de vue de mentor, assistant le ‘Product Owner’ de notre équipe dans ce nouveau rôle, j'ai souvent oublié combien il peut être difficile de devoir organiser son savoir-faire pour pouvoir le transmettre ! 

• Du point de vue du mentoré, en tant que responsable d’équipe chevronné, j’imagine qu’il n’a sans doute pas été facile de reconnaître qu’on ne sait pas (encore) faire.

• Pour le développeur, traduire les contraintes techniques rencontrées pour les placer à notre niveau de compréhension et guider la prise de décision a relevé d’un effort d’accessibilité continu

Cette expérience m'a montré à quel point le mélange d'empathie et d'humilité a été essentiel pour enseigner,  apprendre et expliquer. Ce qui aurait pu générer des tensions a été au contraire un partage fluide, autant dans les sessions de rédactions, d’organisation et de priorisation des user stories que lors des discussions d’implémentation.

3. Créer du lien malgré le travail à distance

Du fait de notre répartition géographique et  de la période de pandémie où la distanciation sociale était de mise, nous avons réalisé l’intégralité du projet en télétravail.

De façon classique, nous avons découpé et documenté le travail sur Jira et traité les questions/réponses de détails avec Slack. Cela nous a permis de centrer nos réunions en visioconférence Google Meet sur les discussions permettant de trouver les solutions d’implémentations optimisées ainsi que la planification des prochaines fonctionnalités. 

Nous avons également veillé à ne pas dépasser la fréquence hebdomadaire pour nos réunions, pour nous laisser le temps du travail individuel… et parce que tout le monde était aussi engagé sur ses missions “officielles” par ailleurs !

Mais aussi, nous avons pris plaisir à démarrer chaque réunion par un petit point sur notre situation personnelle, soit en découvrant un enfant curieux attiré par la caméra chez l’un, en échangeant sur les interventions plomberie ou électricité du jour chez l’autre, ou en partageant l’évolution des situations liées à la pandémie dans nos régions du monde.

 Ce faisant, l'une de nos heureuses constatations est que cela nous a permis de renforcer notre appartenance à “l’équipe projet”.

En résumé

En résumé, nous pouvons recommander aux responsables projet d’être attentifs à TOUTES les compétences portées par leurs employé·e·s. 

Nous avons fait ce projet original en acceptant de ne pas dire “ça n’est pas mon travail !”. Cela a créé la condition d’un très bon esprit d’équipe, en ouvrant complètement notre communication et en permettant le respect, l’empathie et l’humilité. 

A-t-on toujours fait preuve d’une communication et d’un alignement parfait pendant le projet ? Non, bien sûr. Nous sommes humains, mais nous y avons mis du nôtre et nos intentions étaient très positives.

Nous nous sommes bien épaulé·e·s, ce qui nous a permis de faire une belle expérience pour un bel apprentissage.

Notre Customer Service Center est en production, Mission Accomplie !

Je conclue en disant que quelles que soient les compétences que nous mettons à profit, dépenser de l’énergie sur la qualité des relations interpersonnelles, c’est permettre une communication ouverte.