Comment briller en démo lorsque l’on est développeur ?

Tous ceux qui ont travaillé en agile le savent : la démonstration est un temps fort qui permet à une équipe de présenter ses avancées et la somme des travaux effectués durant le sprint. Trop rarement, les développeurs saisissent cette opportunité de communiquer et de mettre en valeur leur travail. Voici quelques conseils pour vous aider à Franchir le pas !

La démonstration (ou démo) est un moment d’échange privilégié entre les interlocuteurs du projet qui peut s’avérer très gratifiant lorsque l’équipe glane quelques retours à chaud positifs, voire un compliment du client au sujet d’une feature particulièrement appréciée.

Au contraire, une démo mal ficelée peut rapidement faire passer votre projet pour une petite Bérézina que vos interlocuteurs vont tenter par tous les moyens d’éviter. Comment faire alors pour communiquer efficacement quand on n’a pas été forcément formé pour ?

Le développeur, un grand timide ?

La culture populaire a longtemps dépeint les codeurs comme des êtres asociaux, hirsutes, et cantonnés à des tâches purement techniques, renâclant devant le fait de devoir échanger avec des néophytes.Tous ces clichés sont évidemment faux, mais plusieurs facteurs continuent à les faire perdurer :

• Un manque de pluridisciplinarité dans l’enseignement de base : à l’école ou l’IUT, on enseigne trop souvent à l’apprenti développeur qu’il se doit d’être technicien habile, et rien d’autre. Un développeur est après tout un artisan qui construit lui aussi des choses de ses mains et doit pouvoir en parler avec aisance. Il n’y pas de raison de laisser le monopole de la passion aux ébénistes et ostréiculteurs. Les développeurs ont aussi un cœur !
• Une sur-optimisation du temps de travail qui transforme le développeur en “coding monkey”, c’est à dire une ressource “pissant du code”, dont chaque minute doit être rentabilisée par la réalisation d’une tâche précise, devant rentrer elle même dans une timesheet. L’agilité en tant que méthodologie a aussi sa part de responsabilité en fragmentant les tâches et en rendant chacun responsable d’un périmètre ultra précis parfois déconnecté des réalités du terrain.
• Un management parfois “old school” qui a tendance à cloisonner les expertises et range les gens dans des silos étanches, laissant le soin aux “chefs” d’échanger entre eux, quand le développeur de base doit rester à jouer dans son coin sans attendre d’autre chose de lui qu’un code propre.
• Ce que j’appelle un “effet de bulle”: un développeur qui a travaillé longtemps sur une feature aura un grand mal à adopter la dose de recul nécessaire pour en parler spontanément de manière simple et schématisée

Amis développeurs, voici donc quelques conseils simples pour briller en démo et mettre en valeur vos divers apports au projet

1/ Préparez bien votre session de démo

Jérôme Bonaldi dans sa grande époque Nulle Part Ailleurs, circa 1995.

Le temps passé en préparation n’est pas du temps perdu ! Steve Jobs himself répétait ses fameuses keynotes pendant deux jours entiers car il avait compris que l’on a rarement l’occasion de faire deux fois une première bonne impression. Préparez-vous donc une petite checklist de préparation avant chaque démo. Cela évitera l’effet “Jérome Bonaldi”, un nom synonyme d’échecs cuisant aux heures de grande écoute qui parlera surement aux plus anciens d’entre vous :

• Vérifiez les conditions matérielles de votre démo : wifi, adaptateur, écran, accès aux environnements de travail, nécessité de services tiers etc.
• Garantissez un navigateur propre. J’ai déjà vu un dev faire une demo avec des tabs de service de livraison d’alcool à domicile ouvert… La blague peut faire rire l’équipe, mais trouvera moins d’écho auprès d’un client plus tatillon. Ouvrez les bons onglets, démarrez une session de navigation privée si vous avez besoins de cookies ou d’historiques cleans
• Retrouvez les tickets que vous avez traités durant le sprint afin de ne pas tomber en panne sèche au moment de parler
• Faites vous un pense bête avec les principaux les messages que vous voulez faire passer devant votre démo : cela vous permettra de sélectionner les informations utiles et de structurer de manière claire votre propos

J’ai fait un petit rappel slack automatique pour automatiquement prévenir les gens quelques temps avant une démo. Enjoy !

2/ Devenez techno-aveugles le temps de la démo

Stack, API, front, commit, get, post, push, react, nginx, backbone, framework… Les gens en règle générale ne comprennent rien au language des équipes de développement, surtout si ces dernière utilisent les mots “windaubes” et “macfags” en gloussant entre eux…

Essayez donc d’employer un langage simple et imagé pour faire passer les messages clefs de votre démo. Les notions de back office sont aussi plus complexes à faire passer que celles de front. N’hésitez donc pas à bien scripter vos démos avec des exemples concrets afin de rendre le message plus facilement assimilables. Tout le monde vous en sera reconnaissant !

3/ Travaillez vos messages clefs

Oui, même quand on est dev, il est toujours bon de faire un peu de com’, désolé.

Les compétences techniques d’un développeur sont très difficiles à évaluer pour la plupart de vos interlocuteurs qui n’ont pas tous le nez dans le projet tous les jours. Vos interlocuteurs vous jugent donc avant tout sur votre capacité à comprendre, synthétiser et interpréter leurs besoins.

N’hésitez donc pas à les reformuler dans votre démo, cela rassurera les gens présents autour de la table et montrera que vous prêtez attention à eux ainsi qu’à leur besoin.

Faites travailler également vos interlocuteurs et impliquez les en leur demandant de préciser, d’illustrer, de commenter leurs besoin.

Ex :

“Alors comme nous l’a remonté Christine, la simplicité est clef…”

“Comme tu peux le voir, on s’est rapproché de Bérard de la compta, le système se synchronise avec une API spécifique…”

“Si je me souviens bien Philippe, ce user case était hyper important pour les gens de la distribution… etc”

4/ Rendez votre démo vivante en racontant l’histoire qui va avec votre feature

Beaucoup de développeurs se bornent à décrire factuellement et avec une voix monocorde le fruit de leur travail. Cette approche est honnête mais peut avoir le don d’endormir votre auditoire.

Les features sorties sont souvent le fruit de dizaines d’heures de réflexion et de travail individuelles et collectives, ces dernières méritent d’être un peu mieux racontées : un peu de tension narrative va garder vos interlocuteurs intéressés par la démo et aussi mieux faire comprendre le quotidien d’un développeur qui est fait lui aussi de questionnements et de challenge.

Pour prendre un peu de distance et bien raconter sa feature rien ne vaut le bon vieux schéma narratif du conte en 3 étapes :

Ceci est enseigné au programme de 5ème donc ça devrait être ok pour vous.

Ex :

Ma situation initiale : On me demande de traiter ce ticket….donc j’ai commencé par…

Ma péripétie : je suis tombé sur ce problème… en raison de…

Mon dénouement : j’ai surpassé cette difficulté… en faisant… …. (car je suis un beau gosse du code)

5/ Amenez autour de la table quelques idées bonus

Parfois les équipes sont frustrées par des délais trop courts, des budgets manquants ou des solutions intéressantes techniquement, mais sans réel apport pour le métier. La démo est aussi un bon moyen pour l’équipe de partager une partie de sa veille. De quoi montrer que derrière de bon exécutants, il se cache très souvent aussi des gens alertes, curieux et créatifs, des qualités de plus en plus appréciées et reconnues.

Allez les amis, je vous laisse, j’ai démo !

Envie de lire d’autres articles sur le bien travailler (et bien vivre) à l’ère du numérique ? Abonnez-vous à notre medium !

Future@haigo