Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante.
Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui, je suis avec Cécile Larude chez E-Waken.
Cécile, bonjour.
Bonjour.
Comme c'est la première fois que tu passes sur le podcast, est-ce que tu peux nous expliquer
ce que tu fais chez E-Waken ?
Bien sûr, merci d'abord pour l'invitation.
Alors chez E-Waken, qu'est-ce qu'on fait ?
On développe un outil pour les formateurs et les coachs qui leur permet de prolonger
l'acte d'apprentissage au-delà d'une session présentielle.
En fait, on développe un produit qui permet l'ancrage cognitif et le passage à l'action
suite à une formation.
Ok, super.
Donc on est en plein dans le mouvement de dire l'acte de formation pendant qu'on a fait
un jour, deux jours, trois jours.
Après, il faut qu'il soit suivi pour que ce soit suivi d'effet, c'est ça ?
Oui, on est dans...
La formation, elle doit être durable.
Et donc pour qu'elle le soit, il faut qu'elle d'abord soit efficace et donc pour qu'elle
soit efficace, que le cerveau s'en souvienne.
Il faut prolonger en effet l'acte de l'apprentissage.
Il faut être coaché d'une certaine façon.
Et durable, ça veut dire qu'un peu tous les jours, il faut se mettre en posture d'apprenant.
Interessant.
Et justement, cet outil, vous le faites développer.
Vous n'avez pas encore de dev' interne.
Et je trouvais ça super intéressant d'échanger sur ton expérience parce que tu as eu une
expérience plutôt boeuf et une expérience plutôt bonne.
J'étais curieux de ton retour d'expérience sur qu'est-ce qui a fait la différence entre
les deux ?
Tout à fait.
Alors ça, c'est un sujet, si on se lance, il reste longtemps.
Mais je vais essayer d'être brève.
Donc en effet, on a une première expérience avec des développeurs.
On est passé par une petite boîte de dev' qui fait développer à l'étranger, qui
travaille avec des dev' à l'étranger.
Et puis on a une deuxième expérience avec un dev' qu'on a en direct qui bosse pour
nous une forme de prestation classique.
La première expérience, elle n'est pas bonne.
La deuxième, elle est très bonne.
Donc la première expérience, elle n'est pas bonne parce que, globalement, on s'est
retrouvés face à des exécutants qui ont développé, indépendamment du produit que
l'on voulait faire, mais le produit au sens que l'on voulait donner à notre produit.
Et ce qui est intéressant, c'est que tu me disais, quand il finissait par livrer,
ce qu'il livrait effectivement faisait la tâche qui était demandée, mais ça allait pas
du tout dans le sens du produit.
Oui, ça n'allait pas du tout dans l'expérience client, dans l'expérience de la user expérience.
C'était à côté de la plaque.
Et pourtant, on avait l'impression d'avoir hyper bien expliqué et longtemps.
En fait, l'expérience s'est prolongé un peu trop.
C'est la répétition des problèmes qui nous a fait nous dire.
Mais là, juste, on n'arrive pas à communiquer ensemble.
C'est-à-dire que j'ai l'impression de dire A et le mec comprend B.
Et je crois que c'est ce qui m'a le plus frappé.
C'est l'incapacité de communiquer.
Et le dev en face, dès lors qu'il avait exécuté la tâche purement technique de la feature
que je lui demandais, il était satisfait.
Mais pourtant, il tombait à côté de la plaque de l'usage que je voulais en faire.
Et alors, la deuxième expérience, ça se passe mieux.
Et qu'est-ce qui commence ?
Déjà, comment ça se concrétise le fait que ça se passe mieux ?
En fait, tout est dans la communication.
Alors, maintenant, j'en parle avec plus de recul.
Donc, je mets des mots plus précis dessus.
Et je pense qu'il y a un sujet de communication.
Ça se passe mieux parce que notre temps avec notre dev, on le passe à discuter.
Et notre dev, il passe du temps à essayer de comprendre le produit.
A prendre du recul par rapport à ce qu'on lui dit en 10.
Et à projeter le produit comme un tout, comme un ensemble, comme une globalité.
Et donc, quelque part, il met du sens dans son développement.
Dès lors qu'il met du sens, ce qui développe, même quand il y a un bug,
s'inscrit dans quelque chose de plus grand, j'ai envie de dire.
Et donc, globalement, même quand ça marche pas, on le dit qu'on prend tout de suite.
Claque et rectifié, on est dans une interaction très vivante.
Il fait partie de l'équipe.
En fait, il est prestat.
Il n'est pas à côté de nous.
Il est, on ne le voit jamais.
Mais il fait partie de la boîte.
Parce que tu sens qu'il est...
Qu'est-ce qui te fait sentir ça ?
Parce qu'il porte vraiment le produit, parce qu'il s'est vraiment approprié le produit ?
Parce qu'il comprend la finalité du produit.
Il comprend...
Je pense qu'il se met en empathique client.
C'est-à-dire qu'on prend le produit, c'est comprendre son client.
Donc, il a fait cet effort-là.
Et je crois que c'est juste à l'intéresse.
Il est curieux de ça et qu'il ne cherche pas juste à exécuter une prestation informatique.
Ce qu'il intéresse, c'est de comprendre pourquoi il fait la prestation informatique.
Qu'est-ce qui sert comme en jeu plus grand ?
Et sur les rythmes de livraison, c'est quoi la différence entre les deux expériences
sur les rythmes de livraison approprié ?
C'est rigolo comme question, parce que dans la première expérience, on était dans un effet tunnel.
Le fait tunnel, c'est zéro visibilité sur là où on en est, quand est-ce que ça va livrer.
Voir pire que ça, oui, oui, ça va livrer demain et ça ne livre jamais demain.
Et donc, ça, c'est hyper anxiogène au bout d'un moment.
Dans le deuxième cas, c'est plutôt l'inverse.
C'est-à-dire que nous, on n'a pas une team, on n'est pas à cheval sur l'équipe I et tout.
Donc, on n'est pas capable de dire à un mec, il faut que tu aies fait ça pour telle heure.
D'empêche que le gars, quand on lui demande de faire un truc, il est souvent,
on est surpris de voir qu'il livre plus vite que ce qu'on aurait imaginé.
Et donc, le deuxième, il te livre plus régulièrement.
Donc, il est plus réactif, oui.
Tu vois, ça rejoint deux pensées que j'ai...
La première, c'est que de développer, ce n'est pas juste codé.
Codé, c'est qu'une partie du boulot qui reste importante,
mais qui par moments, je pense, est secondaire face à la compréhension des enjeux du business, de l'utilisateur.
Après, on ne peut pas complètement le négliger, sinon un jour, on s'en morle les doigts.
Mais en tout cas, ce qui est sûr, c'est que si tu as bien codé un truc qui sert à personne, ça sert pas à grand chose.
Oui, tout à fait.
Et puis, le deuxième, c'est la...
Notre croyance qui est que plus tu vas livrer fréquemment,
et mieux, ce sera d'une manière globale.
Oui, carrément.
Alors, ça, c'est certain.
C'est plus il livre régulièrement, plus dès qu'il y a un bug, il est capable de l'analyser tout de suite, plus il comprend...
Enfin, c'est complètement un cercle vertueux.
Je suis entièrement d'accord avec ça.
C'est l'heure de la fin.
Merci, Cécile, d'être venu aujourd'hui, ce qui les auditeurs,
de l'enfant, qui compèrent en outil peuvent venir où ?
Eh bien, sur notre site, sur notre page Wacken.fr, Wacken, attention, ça s'est crié A-W-K-N.
Il y avait trop de voyelles, donc on en a enlevé quelques-unes.
Merci, Cécile.
Merci.
Quant à toi, chers auditeurs, j'espère que ce podcast t'a plu.
Je t'invite à nous rejoindre dans la communauté des artisans-développeurs sur artisandéveloppeurs.fr.
Je te dis à demain.