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 Christophe Escobar, Christophe bonjour.
Salut Bédoin.
Est-ce que tu peux te présenter en une minute pour les auditeurs qui ne te connaîtraient pas ?
Oui, alors moi c'est du coup Christophe Escobar, je suis principal engineer à Doctolib.
Mon rôle va être un peu de s'assurer de la cohérence des choix qui sont faits
au travers de plusieurs équipes à la tech et au produit,
et aussi de participer à l'analyse des risques qui peuvent arriver sur la plateforme au global.
Ok, et alors on avait évoqué l'idée de travailler sur le fait de travailler,
de parler du sujet des équipes produits.
Tu me disais que les équipes produits avaient un fort ownership sur justement leur zone de prérogative.
Qu'est-ce que ça veut dire concrètement ? Est-ce que c'est un ownership et une autonomie
sur vraiment le produit jusqu'à ce qui arrive dans les mains de l'utilisateur ?
Est-ce que c'est d'un point de vue technique ? Est-ce que c'est d'un point de vue tout ?
Est-ce que tu peux nous raconter un peu comment ça marche ?
Bien sûr, du coup au final comme dans toutes les boîtes,
on va toujours en terme de produire un peu l'aspect stratégique,
un peu de ce qu'on a de top down,
donc en haut on veut faire ça comme fonctionnalité,
bon bah voilà il va falloir le faire,
on aura toujours un peu cette répartition où on essaye de réduire le plus possible,
cette partie-là qui pour nous n'est pas la plus saine au final,
et on essaye de pousser un peu tous les équipes produits
à devenir autonomes sur quelles sont les priorités des fonctionnalités qu'on veut travailler.
Et donc là-dessus on va vraiment les pousser à se baser sur des faits,
des faits, des faits sur de la donnée,
avoir des dashboard, d'avoir des KPI, un suivi des KPI
et à se dire comment on agit sur ce KPI.
Concrètement, imaginons, je crois que vous avez fait la téléconsultation,
ça typiquement, en prenant un exemple comme ça,
un beau jour, j'imagine que c'est pas une équipe qui d'elle-même
a appris l'initiative de dire on va lancer ce chantier-là,
donc c'est quoi, c'est en gros la direction, elle arrive,
elle dit stratégiquement il faut qu'on fasse la téléconsultation,
démerdez-vous, ou ça va un petit peu plus loin que ça,
comment vous voudrez participer le rôle dans les équipes après ?
Alors du coup stratégiquement effectivement,
il faut faire cette nouvelle ligne de produits donc c'est parti,
il y a un peu les enjeux de deadline sur bon bah voilà,
on a envie d'avoir ça avant telle date,
mais ça, ça n'arrive pas tout le temps, c'est assez rare.
Et ensuite, c'est vraiment l'équipe qui va s'occuper de trouver comment on s'y prend.
On va avoir une philosophie assez agile de bah on veut MVP et on hit her.
Donc au final oui au début ça va pas être ultra propre,
mais de toute façon au moins on a quelque chose à présenter
au bout d'une semaine, deux semaines,
et on va voir comment on a meilleur,
et on va construire le produit petit à petit,
on va essayer de mettre en place assez rapidement des indicateurs de qualité du produit.
Donc par exemple avec la consultation vidéo,
assez rapidement ce qu'on a suivi comme KPI n°1,
ça a été la satisfaction des praticiens,
le rating au final qui met à la fin de la consultation,
on leur demande comment était votre consultation,
et donc là on regardait vraiment ce score,
et on s'est dit comment on fait pour le monter.
Excellent et vous êtes parti je sais pas,
c'était quoi les premiers niveaux de corps et vous avez réussi à monter à quel niveau ?
Alors là, historiquement je crois qu'on était aux alentours de 3.
3 sur 10 ?
Non c'est sur 5, donc 3 sur 5 puisque quand même,
au final vu que c'était quand même une innovation en termes du produit,
et que les gens ils étaient très satisfaits de base,
après il y avait quand même pas mal de problèmes sur la qualité de la vidéo,
sur possédant quelques bugs à gauche à droite,
ou des instabilités sur le tout workflow du patient,
et au final quand on a vu qu'une fois qu'on avait le KPI numéro 1,
après on s'est dit bon bah ok on va mettre un peu de données un peu partout sur le workflow,
sur comment ça se fait qu'il y a des gens qui se connectent pas,
comment ça se fait que la qualité est mauvaise,
comment on rajoute plus de logs,
comment on a meilleur au final l'outil qu'on utilise pour faire de la vidéo,
et ça nous a vraiment permis à arriver à des notes vraiment beaucoup plus hausse,
je crois qu'on doit être aux alentours de 4, 5 à quelque chose comme ça maintenant.
Ouais donc c'est génial, je trouve ça excellent comme démarche,
je vois encore trop d'entreprises, trop d'équipes qui vont passer des semaines à peaufiner un truc,
avant de voir des mois parfois à peaufiner un truc avant de le mettre sur le marché,
en mode non non non si c'est pas parfait je veux pas que ça sorte,
alors qu'en fait il y aura juste une énorme opportunité de progresser quoi,
je pense que les clients sont capables de comprendre si tu leur dis les choses,
tu peux leur dire on est en train de démarrer ça,
je pense que les gens comprennent quoi.
Le but c'est ça, on les contacte on dit bon voilà on va lancer ce produit,
on a besoin de beta testers, est-ce que ça vous va ?
Bon après bien évidemment tout travail mérite rémunération,
donc au final c'est des personnes à qui on va dire ok au début ce sera peut-être gratuit pour vous,
des choses comme ça et de toute façon...
Il y a une contrepartie ouais.
Oui ça de toute façon c'est normal,
mais le fait de les impliquer assez tôt,
et après du coup tu as le produit vu qu'il est assez autonome,
il va faire de la user research, il va aller voir les gens,
il va aller sur le terrain, il va demander comment vous préférez avoir ça,
on va venir avec des propositions,
et il va y avoir beaucoup d'itérations dessus au final.
Moi je trouve ça excellent, donc ça veut dire vraiment l'équipe elle est complètement autonome
sur sa mission donc dedans il y a vraiment plein de profils,
et ça veut dire que vous êtes capable d'aller jusqu'à la prod aussi alors,
toutes les équipes sont capables d'aller jusqu'à pousser un truc qui va partir en prod.
Ah oui de toute façon chaque équipe est autonome pour aller en prod,
ça c'est la fonctionnalité, elle est à Z.
Moi ça me paraît juste normal,
mais les entreprises pour qui ça paraît normal sont plus l'exception que la règle,
donc je pense ça mérite d'être clarifié,
et ça veut dire que ça va jusqu'à la je sais pas,
les devs ont même la responsabilité des machines de production,
c'est eux qui ont réveillé la nuit si ça casse, comment ça marche après ?
Alors ça pour le coup non, mais par contre,
et ça c'est quelque chose je pense qui est vraiment très très bien qu'on ait ça ici,
c'est qu'au final on a mis en place ce qu'on appelle les business golden rule,
et en fait tu fais ta fonctionnalité,
donc du coup ton équipe est responsable d'un certain de l'autre fonctionnalité,
c'est votre domaine, c'est votre scope,
et en fait on va vous demander de mettre en place des règles
qui sont liées au bêtier quoi,
et si ces règles là on va du coup mettre des sons dessus,
de l'alertine, et si jamais ça ne va pas,
ça déclenche une crise, automatiquement,
ça déclenche une crise, et après du coup derrière,
ça veut dire quoi ?
Ça veut dire qu'il y a des gens qui vont venir dans la crise,
on va avoir un manager de crise,
on va essayer de comprendre tout vient de problème,
on va savoir est-ce que c'est un problème infras,
est-ce que c'est un problème qu'il y a à l'infras,
est-ce que c'est un bug qui est nouveau, qui est suite à une mise en production,
est-ce qu'il y a un problème quelconque,
mais on va devoir régler ce problème, on repart pas.
Et ça a quelque part à l'heure du jour et de la nuit ou plutôt quand même en jour ?
Alors là, la plupart du temps, si c'est des problèmes métiers,
ça arrive plutôt la journée,
par exemple, il y a une mise en production qui s'est un peu ratée,
dans ce cas là, il faut revenir en arrière,
mais c'est arrivé de temps en temps d'avoir,
si on dépend de services externes,
qui à 22 heures, ils ont un souci,
et du coup ça impacte notre fonctionnalité qui se base dessus,
ça nous est arrivé d'avoir des crises à 22 heures.
Ok, d'accord, ok.
Et du coup, est-ce que les équipes sont plutôt stabs ?
C'est quoi une équipe typique ?
Quelle est la stabilité d'une équipe ?
Est-ce que vous allez plutôt chercher la stabilité
ou au contraire, vous allez encourager les membres d'une équipe
à bouger d'une équipe à l'autre, histoire de disperser la connaissance
et de favoriser une certaine transversalité ?
Parce que le risque quand on a des équipes qui sont autant autonomes aussi fortes,
avec autant de prérogatives, c'est de créer des silos,
c'est de recréer des silos,
alors des mini silos certes, mais des silos quand même,
comment on fait pour faire des trous dans ces silos un peu ?
Alors du coup, on va avoir une organisation qui va se baser quand même très fortement sur la...
j'ai envie de dire, sur la stratégie de la boîte.
On a 5, 4, 5 grosses lignes de produits, enfin des piliers.
Ces piliers-là, derrière, on va avoir un domaine,
on va appeler ça un domaine dans la boîte.
Et donc du coup, chaque domaine après va avoir plusieurs équipes
qui vont avoir plus des oeillères sur un certain nombre de fonctionnalités
au sein de ce domaine-là.
Ok.
Tu as un exemple de domaine pour qu'on comprenne et qu'on illustre ?
Bah un exemple de domaine, ça va être par exemple patient et virtuel carre.
Donc ça va être toutes les fonctionnalités qui sont liées,
quand tu vas sur 3w.doctoy.fr,
tout ce site-là au final,
ainsi que la ligne de produit de...
je vais faire une consultation vidéo
et dans ce qui arrivera, comment on va gérer ton espace de document.
Donc la fonctionnalité par exemple,
prends un rendez-vous avec un docteur qui est un peu la base de votre service,
ça y a une équipe quelque part d'un champ fonctionnel qui s'en occupe en fait,
qui est mandaté pour s'occuper de ça.
Qui est mandaté pour s'occuper s'il y a des évolutions à faire ?
Oui c'est ça, oui, oui, il y a des évolutions.
Ok, oui, d'accord.
Et donc, comme on disait sur le mouvement, comment ça marche ?
Bah au final, on essaye d'avoir une certaine stabilité,
même si on aime bien pousser un peu les devs à faire ce qu'on appelle les vies-ma-vie,
va voir ce qu'ils font à côté parce que ça donnera un peu...
Les process, ils sont assez libres, on a quand même des rails de process pour les équipes,
c'est des équipes agile, donc forcément il y a le stand-up, il y a la rétro et ainsi de suite,
mais bon après, chaque équipe fait un peu comme elle l'entend.
Elle améliore ses process en fonction belle,
en fonction de ce que veulent les gens dans l'équipe,
et donc du coup on va potentiellement pousser les gens à aller voir ce que font les autres.
Et après là-dessus, en termes de silos fonctionnels,
au final vu qu'on est dans une perspective de boîte qui évolue assez vite,
où on grossit assez vite, on a une stabilité en termes d'équipe,
mais après ça nous arrive assez souvent d'avoir une équipe qui a changé de scope fonctionnel plusieurs fois dans l'année.
Ça nous est déjà arrivé à cause de la croissance au final.
Ok, donc ce que tu dis c'est que les silos sont amenés à bouger par le fait que vous grandissiez en fait ?
C'est ça, on va avoir des enjeux ailleurs et du coup on peut prendre une équipe
et l'amener sur un autre sujet.
On peut avoir des nouvelles équipes qui sont créées,
dans ce cas là il va y avoir toute une phase de partage de connaissance
sur le fonctionnement que l'équipe gérait,
comment le partage à cette nouvelle équipe qui va reprendre les règles.
Super intéressant.
Bah écoute, je te propose que ce soit à la fin de cet épisode,
si les auditeurs veulent en savoir plus ils peuvent venir où ?
Alors on a un Medium, donc Medium Doctor Live et il va y avoir un anglais Tekken Project.
Cool, merci.
Merci Christophe.
Quand ça t'achète à l'auditeur, comme d'hab, j'espère que tu as apprécié cet épisode.
Si c'est le cas, je t'invite à partager ton retour d'expérience sur benoîtarobasartisandeveloper.fr
Dis-moi un petit peu comment ça marche chez toi, qu'est-ce qui se passe ?
Qu'est-ce qui marche bien ?
Est-ce que l'épisode t'a donné envie d'essayer des choses ?
Je suis tricuré de ton retour benoîtarobasartisandeveloper.fr
Je te remercie, je te dis à bientôt.