Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante.
Prêts à passer au niveau supérieur ? C'est parti !
Aujourd'hui, je suis avec David Olivier, David bonjour.
Bonjour.
Est-ce que tu pourrais te présenter pour ceux qui ne te connaitrait pas ?
Je m'appelle David, je travaille à GoJob depuis un peu plus de 6 ans.
Je suis actuellement staff engineer à GoJob, donc essentiellement je fais du dev, du coaching.
J'amène mes équipes à mon temps en compétences.
Aujourd'hui, ce qui me passionne et ce qui me motive dans mon métier, c'est tous les
aspects un peu craft, qualité logicielle et comment on fait grandir surtout les individus
de nos deux équipes.
Super.
Et le sujet du jour que tu m'as proposé et que j'ai pris avec grand plaisir, c'est le
Fronten First.
Je suis vraiment curieux qu'on actuellement dise plus sur ça parce que je comprends
le concept, mais visiblement quand on t'en parle, ça a l'air d'être plus qu'un concept,
mais plutôt une démarche structurée.
Alors est-ce que tu peux nous en dire plus sur ce que c'est, comment ça marche et quel
est ton retour d'expérience parce que je crois que c'est justement quelque chose
que tu as pu mettre en œuvre et expérimenté dans ta boîte.
Oui, ça s'est passé.
Donc en effet, le Fronten First, c'est plus une approche de comment on va essayer de
faire émerger des solutions par rapport à nos besoins métiers.
Et donc moi, concrètement, c'est quelque chose qu'on m'a apporté au fil de l'eau
sur des discussions un peu craft avec différentes personnes.
Et en fait, c'est quelque chose que j'ai voulu vite appliquer dans mon expérience à
Goodjob et ça s'applique pas tout le temps.
Déjà, je préfère le mettre au clair, c'est que cette approche là, vraiment, déjà, c'est
qu'on peut avoir une interaction le plus possible avec le métier.
Nous, on a de la chance que là, pour le coup, sur ce concept-là, c'était du métier et
des personnes qui étaient en interne de Goodjob.
On pouvait facilement y térer avec eux.
Donc, quand tu dis en interaction, tu parles de qui ?
Tu parles des devs avec des utilisateurs finaux, des devs avec des représentants
du métier qui doit interagir.
Il y a plusieurs acteurs en effet.
Il y a le développeur, il y a le PM, il y a même le design mix, ainsi que quand
j'ai dit du coup le métier, aujourd'hui, c'est des personnes qui travaillent à Goodjob et
que tu as une autre solution en interne, qu'on a un back office pour pouvoir
gérer notre notre notre business et justement, on travaille directement avec ces
personnes. Là, c'était des features qui étaient liées justement aux personnes
qui utilisent notre solution en interne.
Donc là, quand j'ai dit justement, part travailler avec le métier, on travaille
avec le PM, le designer UX et le staff qui utilise notre solution.
OK. Donc ça, ça veut dire que c'est un travail.
Déjà, ça a un point important.
C'est un travail collaboratif où il faut être à plusieurs types de compétences
dessus. Et alors, ça ressemble à quoi concrètement ?
Parce que dire front-end first, j'imagine, ça veut dire que tu te concentres d'abord
sur l'expérience client, en fait, sur à quoi va ressembler ou comment va être
utilisé ton front-end, ton système, en fait ?
Mais au-delà de ça, qu'est-ce qu'il y a derrière ?
Oui, voilà. En fait, il y a un vrai but derrière.
Le but est en fait le premier point qui était posé pour cette pratique là.
Et ce qui nous, nous a beaucoup séduit dans l'approche.
C'était plutôt d'essayer de détérer avec le métier pour valider des concepts métiers.
C'est-à-dire quand on fait de la recherche au niveau de notre métier, de savoir
qu'il y a des concepts qui ont bien été concrètes pour apporter des bonnes solutions.
En fait, aujourd'hui, on essaie de faire des ateliers avec le PM UX.
On essaie d'extraire des concepts métiers.
On essaie de faire des mapping des fois un peu d'event storming, mais très rarement
parce que pour l'instant, c'est quelque chose qui est un peu lourd et qu'on n'a pas
arrivé encore à mettre en place dans notre structure.
Et en fait, aujourd'hui, comme on essaie de faire etterrés ça, c'est qu'on essaie de faire
justement une maquette, on essaie de montrer à l'utilisateur de se dire avec le design
arrivi que c'est le PM. OK, est-ce que ça correspond à votre besoin par rapport
à telle feature ? Et on y terre avec le sur ça.
Et en fait, là, le problème de ce genre de choses, c'est qu'on est sur le chute des choses qui sont assez
statiques et on n'arrive pas un peu à jouer.
Il n'y a pas des choses qui sont maléables avec de la donnée qui est qui est réelle par rapport à ce
qui va se passer avec des peut-être même des règles de logique où là, on va être
commencé à construire des gros prototypes très trop même trop complexes.
Et ça, on l'a eu fait.
C'est un des deux feedbacks que je vais faire, c'est que tout quand on part avec directement
avec le design UX, lpm et les utilisateurs sans les devs ont déjà nous, ça nous met
un petit train de retard pour attraper le chemin.
Et puis en plus, même sans parler de ça, il y a les challenges que peuvent faire les devs par rapport
à ça. Et en fait, ce que je veux dire dans ça, c'est que le fait de faire ça en isolation, c'est
que malheureusement, nous, on s'est rendu compte que le designer UX va faire un proto avec des
liens dans tous les sens pour essayer de faire quelque chose que soit le plus interactif possible
pour notre utilisateur.
En fait, ce qu'on s'est rendu compte, c'est que oui, ça donne des idées, mais c'est très difficilement
maintenant sur des outils comme Figma, parce que notre UX utilise Figma.
Et c'est très difficilement utilisable avec notre UX et notre métier, parce qu'en fait, les interactions,
dès qu'il y a des modifications encore, en fait, j'assure que tu vois le schéma d'enfigma,
c'est une tentacule de use case coller les uns sur les autres pour maintenir dès que tu modifères
un truc à un endroit, un composant d'endroit. En fait, tu dois remodifier tout ton flow et c'est très
compliqué. Et en fait, ce qu'on s'est rendu compte justement, c'est que ça, c'est quand même une
bonne base, en effet, pour commencer à discuter des concepts avec le métier.
Et c'est pas assez.
Là, on va faire une pause et faire une capture pour être sûr que j'ai bien compris ce que tu
m'as dit. Ce que tu me dis, c'est que dans votre manière de fonctionner, avant de passer à quelque
chose qui est plus structuré sur la partie approche et utilisateur, vous étiez dans une logique où
l'UX, travailler son UX avec Figma notamment, te faisait un truc le plus interactif possible,
mais du coup, tout en statique, donc quelque chose qui devient vite énorme et exponentiel,
finalement en termes de complexité et de quantité de choses à mettre, parce que chaque petit
bout qui bouge, il faut un écran presque à part entière. Et du coup, tu te retrouves à quelque
chose qui est très chiant à maintenir. Exactement. Et tu parlais aussi de la tentation peut-être de
laisser lui, qui fait un peu trop partir devant, et les développeurs derrière qui galérernt un peu
à rattraper le travail. Exactement. Et en plus, des fois, ça amène un truc, on va
dire, attends, il faut que tout mon concept, toute ma feature, j'ai déjà concepté sur le
Proto pour dire, on l'envoie en dev. Moi, c'est quelque chose que j'ai vécu, en fait, dans
les dernières expériences quand j'avais mon agence, là, on travaillait avec certains clients,
on essayait d'avoir vraiment une approche orientée utilisateur, mais c'est un peu ça que j'ai vécu,
c'est que du coup, on se retrouvait avec un designer qui avait toute la pression d'abord pour nous
faire la maquette la plus complète possible et exhaustive possible. Puis une fois qu'il avait
fait tout son travail, qu'il avait épuré tout l'arbre de décision et que tout avait été
validé, ça partait en dev. J'étais resté vraiment avec cette frustration de me dire,
ben ouais, mais c'est pas très agil quand même. Il y avait vraiment ce truc de lui,
il faut toujours qu'il a un sprint d'avance ou d'eux, et je me disais, il doit bien avoir une
manière de fonctionner où tout le monde est au même rythme et bosse en même temps à peu près
sur la même chose. C'est exactement le point. C'est exactement ça. Et même, ce qu'on a vu,
ça peut même amener à des dérives encore plus, un peu plus accentuants, on va dire.
C'est que, en fait, il y a la feature, on se rend compte de nouveau du dev,
quelque chose qui ne va pas parce que ça ne correspond pas. À un moment donné,
un concept ou même un retour qu'on a eu au moment où du dev, au moment où on faisait l'accueil
avec l'utilisateur, ça rend du compte quelque chose qui n'allait pas. Et en fait, des fois,
c'est, attends, on va rediscuter avec le design. Le design, lui, il a déjà switché sur notre
sujet, donc il faut que tu sois là-dedans. Et là, ça devient très compliqué. Il y a tout qui,
et en effet, cette genre de pratique est là, en fait, pour amener quelque chose à ses
seins. C'est-à-dire qu'on essaie d'avoir des interrations les plus petites possibles.
Ok, comment on intervient avec notre métier ?
Quand tu dis ce genre de pratique, c'est quoi ? On revient sur le concept de Front & First.
Oui, pardon. Quand on revient sur le...
Pour régler ce problème-là de désynchronisation entre lui et les développeurs,
et j'imagine que ça va amener d'autres bénéfices aussi, on rentre dans cette pratique du Front & First.
Alors, concrètement, comment ça marche le Front & First ? Et comment vous l'avez mis en
place ? Alors, je vais parler de l'expérience de Good Job. C'est pas la vérité absolue sur
le Front & First. C'est comment nous l'a approché. Concrètement, c'était notre
première expérience de comment vous l'avez approché. On avait déjà voulu l'approcher
avant, on l'avait tout à l'heure, mais on avait déjà voulu l'approcher avant, et en fait,
ça n'était pas appliqué. Au fur et à mesure, on a commencé à y être rien. On a vu qu'avec le
métier, c'était des problèmes qui étaient plus back-end, c'est des choses qui parlent avec
d'autres services. Il n'y avait aucun retour utilisateur concret à ce moment-là, donc déjà,
ça ne s'applique pas partout. Et là, concrètement, on a eu un besoin de facturation. On doit
générer des factures à Good Job. Je ne vais pas aller plus loin que ça. Et pour ça, on a beaucoup
de use cases qui arrivent autour de ce concept. Et en fait, on a besoin de dire qu'on aimait déjà
comment on affiche une facture à Good Job, comment on affiche de la donnée devant nos
utilisateurs, comment nos utilisateurs vont commencer à jouer avec. Et en fait, l'approche,
c'était quoi ? C'était de se dire qu'on a besoin déjà d'aller changer ça toujours pareil avec
le métier, le PM. Et cette fois-ci, on met les devs aussi dedans. Donc, maintenant,
c'est d'en essayer de tout le temps mettre les devs en mise à pratique. Et en fait,
le but est en se dire, OK, on a une première éterration de se dire, OK, on fait un petit
proto, même on peut appeler ça une maquette, pas forcément de métier, pas besoin de faire
de liens différents avec d'autres choses. On essaie de valider ça et on le met en développement. On le
met en développement au moment où ça a déjà commencé à avoir une petite maquette. Le fait
de le mettre en développement de suite, c'est de se dire, comment je fais en sorte pour avoir le
plus rapidement un feedback possible sur les différents traits qu'on va avoir,
au moment où on va le mettre en développement. Et quand j'ai le mettre en développement,
on va me dire, mais attends, si j'ai besoin d'afficher une facture, j'ai besoin du coup
d'avoir de la donnée, j'ai besoin d'avoir du backend, j'ai besoin d'avoir de l'authentification,
si on a un licéateur, non, non, là, on s'arrête à là. On s'arrête à où vraiment on a besoin
de pur. C'est-à-dire qu'on va faire d'abord le front. Et c'est là, en fait, il y a toutes les
sens de cette pratique-là. C'est d'abord, on va faire le front. Donc, pour faire d'abord le front,
on va commencer directement, nous, on utilise des technos comme réacte. On va commencer déjà
à faire nos composants. On va déjà commencer à faire des vues. Et pour la data et pour les
différentes interactions, en fait, on va s'assurer de titre tel que la clinachitecture côté
frontaine. C'est une pratique que nous, on effectue aujourd'hui à good job. Et donc,
du coup, on va faire cette pratique-là et on va faire en sorte de dire, OK,
nous, nous emboutons à ce qu'ils sont sensibles et sur du backend, on va les faire les plus
bêtes possible pour en fait retourner le minimum de data possible pour qu'il y ait une interaction
avec de la data dans notre frontaine. Donc, concrètement, pendant ton intération,
quel designer qui commence à sortir une maquette et tout de suite, ça dev, ça dev le truc,
mais tu t'arrêtes vraiment que à la partie frontaine. C'est exactement ça. On ne va pas plus
loin que le reste, en fait, et c'est pour toi. Et est-ce que tu prends, est-ce que tu prends
d'autres raccourcis sur la partie frontaine ? Est-ce que tu fais un truc déjà propre en
clinarchie, tout ça ? Oui. Ou est-ce que tu fais un truc jetable ? Non, non, non. Là, aujourd'hui,
justement, le but, c'est quand même d'essayer de capitaliser sur les vues qu'on est en train de
sortir les concepts déjà à travers qui sont communiqués avec quelque chose d'extérieur,
vraiment en impliquant, bien, justement, des certains use cases dans notre frontaine,
en impliquant des adapteurs qui, eux, sont au début simplement du fake et vont envoyer,
vont en fait, stubber la partie back end. Et à ce moment-là, en fait, là, on peut déjà
commencer à insérer de la donnée et jouer avec des use cases qui sont en concrét niveau frontaine,
parce qu'en fait, c'est des use cases qui resteront après. Est-ce que la donnée,
elle vient de quelque chose que j'ai mis dans mon frontaine ou est-ce qu'elles viennent
dans mon back end ? Et même derrière, ce qu'on a amené à faire, c'est qu'en fait, on s'est dit,
ok, il va avoir des use cases qui sont plus ou moins complexes côté back end, mais pour l'instant,
nous, la seule chose qu'on va dire, c'est qu'on veut juste sortir le load put de ce use case
complexe côté back end. Pourquoi ? Parce qu'en fait, l'essence même de ce que,
de cette pratique-là, c'est pas forcément de dire, ok, j'ai validé que du visuel. Non,
en fait, c'est de valider les use cases et les concepts métiers qu'on est en train de mettre
en place et les règles métiers qu'on est en train de mettre en place avec une solution où il n'y a
pas toute la structure back end avec tout ce que ça comporte. Et on a juste un front end qui,
lui derrière, va simuler des choses qui vont se faire par rapport au back end. Et en fait,
le fait de livrer juste ça, c'est que tu peux déjà le challenge avec ton métier,
lui, il va déjà pouvoir commencer à jouer. Et après, justement, on en parle peut-être,
si tu veux un peu après, mais en fait, quand on a eu des feedbacks de PM pour se dire,
ok, mais pour que ce soit vraiment cohérent, qu'est-ce qu'il faut ? Parce que si par exemple,
sur une facture, je te dis, je t'ai mis deux lignes, deux lignes de facture, et en fait,
sur deux lignes de facture, en fait, quand je la déplace, je veux qu'il se passe ça ou n'importe
quoi, tu vois, c'est pas réel de si je te dis, mais attends, moi, ma facture, j'ai 25 000 lignes.
Comment je fais ? C'est pas la même chose. Du coup, les interactions UX, les interactions en
termes de moi-même, de mon concept, sont pas forcément les mêmes avec autant de data.
Ce sont pas forcément les mêmes. C'est clair.
Mais alors, du coup, ce que je comprends, c'est que tu livres pendant l'itération directe et live,
tu livres du front end de bonne qualité, quasiment ready to prod. C'est juste qu'il est branché
sur une source de données qui est faite. Mais alors, en quoi tu gagnes du temps de faire ça ?
Est-ce que c'est parce que, du coup, tu t'abstrais de toute la, en quoi tu es plus véloce,
plus rapide ? C'est le fait de t'abstraire de tout le bac qui fait que tu peux, du coup,
aller plus vite ? Exactement. En fait, c'est le fait de s'abstraire de toutes les problématiques
que le public se portait, en fait, sur toute la partie backend, sur les termes de déploiement,
d'architecture, de l'OCD, de l'identification et tout le reste. C'est que pour l'instant,
avant de se dire, OK, déjà, comment, moi, je vais stocker mon utilisateur, comment je vais
l'authentifier ? Avant de parler de tout ça, en fait, déjà, on est là juste en train de se dire,
OK, minefacture, c'est quoi ? Et comment on va interagir avec elle ? En fait, ça permet quoi ?
Ça permet déjà avant du feedback sur est-ce que le concept qu'on va, après conceptualiser
côté backend, il a du sens ? Est-ce qu'on va pas, on va pas en fait trop loin sur un de nos
besoins ? Est-ce qu'on va pas trop loin sur une de nos conceptions alors que peut-être, on pourrait
dire, drain de déjà avec notre utilisateur, avec de la vraie faible donnée qui serait dans notre
contexte, est-ce qu'on pourrait déjà dire, OK, voilà, là, notre concept, il est valable. Et après,
d'un côté, ça va, bien sûr, tu auras tout ça à implémenter côté backend et ça, c'est réel.
Ça sera toujours le même problématique. Par contre, déjà, tu seras serein sur le fait que tu as déjà
validé le concept en lui-même et ça n'a pas l'entrain de te dire, OK, je vais commencer à
implémenter plein de choses côté backend et je n'ai pas eu encore un retour utilisateur.
OK, donc tu fais toute cette économie de backend et tu raccourcis ton cycle de feedback et de
feedback et donc de d'itération, tu as capables d'itérer beaucoup plus vite. Qu'est-ce que tu as
remarqué, du coup, en termes d'impact ? Ça veut dire quoi ? Ça veut dire que là où avant, il vous
fallait, je ne sais pas, quelques semaines de travail peut-être pour sortir un truc. C'est quoi la
différence entre avant et après, tu dirais ? Avant, c'était quoi l'ordre de grandeur pour avoir un
feedback entre le moment où le designer a démarré le boulot et le moment où vous aviez un retour
utilisateur et aujourd'hui ? Je vais prendre un exemple le plus récent qu'on a eu parce qu'en fait,
cette pratique, encore une fois, on l'a initié à good job, c'est-à-dire que vraiment c'est la première
fois qu'on le fait. C'est-à-dire quoi ? C'est-à-dire qu'on a quand même eu des fails et je pense
que c'est important aussi après dans le Paris de ces fails-là. Mais concrètement, si je prends
l'insucsé qu'on a eu avec cette pratique-là et pourquoi on a continué à la faire, concrètement,
ça dépend bien sûr le type de feature dont on parle, ça dépend le type de besoin parce que
suivant le besoin, c'est plus ou moins compliqué et long à développer. Mais là, typiquement,
un exemple très récent, on a eu besoin de ces factures-là dont je te parlais, on a eu besoin
d'avoir un pro-format. Je ne sais pas si tu vois ce que c'est un pro-format, c'est un brouillon
de factures qui n'est pas valable comptablement. Et en fait, on avait des choses à valider,
à challenger à-dessus. Le design UX et le PM, ils ont dit en fait, moi j'ai envie de faire ça,
j'ai envie de faire telle chose par rapport à mon utilisateur parce qu'on a vu qu'on avait
tel, tel, tel besoin. Par contre, je ne suis pas sûr que ça fonctionnera avec tel data, je ne sais pas
que ça fonctionnera de telle façon. En fait, on l'a fait directement en front end first, on a
développé un truc le plus basiquement possible pour essayer de valider les hypothèses et les
questions qui se posaient le PM sur ces problématiques-là. Et en fait, même pas une journée, on a
réussi à sortir quelque chose en mode, on valide ou on a valide cette hypothèse de
d'évolution de notre produit. Et contrairement à si on avait dû, allez, commencer à développer,
comment on génère un pro-format, peut-être même la génération de PDF, peut-être même comment
on fait l'interaction de stream pour faire que le front y récupère directement un stream et
il affiche directement le PDF sans d'avoir téléchargé un fichier et ainsi de suite. On n'a pas
pensé à toutes ces problématiques-là. La seule chose dont on a pensé, c'est un pro-format,
je sais que ça affiche comment, avec quoi je peux l'afficher et dans quel cas. Et en fait,
on a juste validé le concept de la pro-format. Et en fait là, clairement, on a gagné énormément
de temps parce que je ne serais pas à te dire de quand est-ce qu'une fois on a fait un autre
pro-format qui serait équivalent à un autre feature qui serait équivalent aux pro-formats,
je n'ai pas d'exemple à te donner, mais clairement tu as appuyé de faire toute la partie
backend donc je viens de te parler. Donc en termes de timing, tu as gagné potentiellement plusieurs
jours ? Oui, clairement. Parce que déjà, on essaye de faire dans les pratiques où on fait du TDD,
on essaye de développer nos features côté backend, après on les expose plus à petit,
après on fait les tests M2N pour tes, c'est tout ça. Enfin, ça ne nous aurait pas pris du tout le
même temps que juste de dire déjà, on règle dans le front-end, tu as besoin d'avoir un pro-format
de valider le fait comme un pro-format, on peut lui faire ça avec avec ça, c'est
suffisant, c'est largement suffisant pour valider le concept. Donc on est d'accord que
c'est pas que tu as économisé du temps de dev, c'est que tu as eu un feedback beaucoup plus rapide,
ce qui t'a permis de développer le potentiellement le truc qui collait le mieux au besoin de l'utilisateur.
Exactement. Ceci dit au final, j'imagine que tu dois gagner du temps parce que tu vis le rework,
mais intrinsèquement le gros avantage, il est surtout qu'au lieu d'avoir mis plusieurs jours à
dev la feature avant de te rendre compte si ça collait ou pas, c'est que voilà, en une journée,
tu as eu ton feedback utilisateur, tu as pu le mettre le truc contre les mains d'un utilisateur
qui a pu te dire ça marche ou bah non, c'est de la merde, ton truc ça marche pas.
C'est exactement ça. C'est très puissant, moi je trouve ça extrêmement puissant.
Sincèrement, nous à GoJob on en a quand même un bon feedback de ça, après je peux en parler
comme ça parce qu'on s'est pris aussi quelques murs.
Moi tu me parlais des fails alors, c'est quoi les fails que tu as eu ?
Déjà je pense qu'il n'y a pas toutes les équipes, c'est à dire déjà quand il y a des
équipes où il n'y a pas d'appétence fronte, c'est un peu compliqué déjà de pouvoir faire ce genre
de pratique. C'est à dire que si tu as une équipe de DevBag qui te leur explique,
ils vont ne servir à rien pendant l'itération, en tout cas au début ça va être compliqué.
Oui, ça risque de être très compliqué, ça n'est pas vraiment du tout.
Si tu me demandes de faire un smart contract mais sans smart contract, je vais te dire bah écoute,
tu me rappelles quand tu as un smart contract.
C'est exactement ça et en fait déjà le contexte de l'équipe est très important,
le contexte de la future comme je l'ai dit tout à l'heure, nous on a eu un moment où on voulait
le utiliser. En fait on s'est rendu compte que le niveau utilisateur n'y avait pas de besoin,
on allait beaucoup trop loin pour résoudre le problème donc ça ne servait à rien d'aller
aussi loin. Ça dépend aussi de ça et en fait ça dépend aussi quand même des outils qu'on peut
mettre en place. Nous aujourd'hui on a réussi à le faire parce qu'on sait faire de la clinage
structure côté fronte. On a des outils comme le design system qui permettent d'interagir très
facilement avec notre design UX et les devs. On n'a pas besoin de faire énormément d'interactions,
on a le même design system pour la partie design et la partie dev. Bien sûr il y aura un peu de
casse pour en parler avec Timur. On peut faire un peu de teasing pour l'épisode avec Timur
qui nous fera un petit retour d'expérience sur ça aussi, sur comment c'est quoi un design
system, comment l'utilise et même on a le plan de faire un live qui nous montre en vrai un zone,
comment on vous fait ça, comment il fait ça. Mais ça ce que je comprends c'est que tout ça c'était
en place en fait. Du coup avec ton design system tu as déjà des tas de briques, tu as déjà une
boîte de composants prêtes à l'emploi avec le principe de clinarchie, tu as déjà une architecture
qui est front and first friendly et qui te permet de venir moquer facilement donc tu as déjà une
bonne boîte à outils pour le faire. Sans tout ça ça serait quand même plus compliqué.
Ça serait quand même bien plus compliqué et après il y a quand même aussi un autre contexte aussi
c'est que la structure fait qu'on ne peut le faire. Aujourd'hui on est dans une équipe, on arrive à
y térer tous très facilement ensemble avec le design, le PM et aujourd'hui on était sur des
utilisateurs comme je l'ai dit au tout début, des utilisateurs qui sont internes sur cool,
on est proches de nos utilisateurs. J'avais tendance à dire ça avec nos intérimaires qui sont nos
GoJuber qui ont travaillé, ça aurait été plus compliqué, il aurait fallu organiser des plus
de workshops avec, ça aurait été différent parce que la distance entre le métier qu'on veut
couvrir, elle est très importante parce que ça permet justement de se dire ok est-ce qu'on va
pouvoir vite éterrer avec eux. Et après sincèrement en termes d'organisation comme je disais sur le
travail avec les PM et les UX, c'est très important de pouvoir y térer en même temps. On l'a très
bien vu là récemment avec ce que je te parlais du pro forma où ça a été un succès mais comme je
disais on s'est pris des murs et concrètement au début on est parti sur exactement le pattern que
tu décrivais juste d'ailleurs, c'est à dire qu'en fait le designer est parti avec un méga proto
énorme mais un truc énorme et en fait il avait été ré un mois avant nous.
Mais vas-y mec maintenant fais ton approche France, on se force l'être en avant.
Exactement, donc en fait on s'est retrouvé un peu démuni, on était là, on a essayé quand même
parce que on voulait quand même essayer de démontrer, on ne voulait pas encore commencer à déployer le
backend en l'an, on l'a quand même fait, ça a quand même apporté quelque chose mais ça avait beaucoup
moins d'impact, c'était beaucoup moins efficace que sur les dernières features dont je te parlais tout
à l'heure. Donc ça c'était hyper important de pouvoir être ré en même temps que le designer,
c'est un truc qui est primordial parce que nous on se l'est pris et c'était difficile. Et en fait
ce qui est aussi ce qu'il faut dire c'est que le but n'est pas de faire de toute l'application
en front end first, c'est pas ça le but hein. Je pense que tu l'as bien compris, le but c'est de
pouvoir tester des paternes, tester des concepts, pardon, avec métiers et ainsi de suite et de
valider ces concepts là. Mais ça veut dire quoi ? Ça veut dire que derrière tu vas pas aller
commencer à implémenter tout ton front end, toute ta solution en front end first, après tu vas
dire c'est bon on fait le backend non, puis tu as pitié après on va commencer à implémenter du
backend pour après connecter le backend au front end et continue notre développement.
Et en même temps on fait du front end first sur le reste. Et en fait si ça soit quelque chose qui
jongle entre eux et eux, parce qu'en fait si on crée un trop grand écart entre le moment où
on fait notre front end, notre backend, en fait on se rend compte que c'est hyper difficile de
rattraper les wagons facilement parce qu'en gros il faut se remettre dans les premières règles qu'on
avait commencé à développer, à concevoir et après commencer à reconnecter et en fait il y a plus
de friction quand on laisse trop d'écart entre le moment où on a implémenté le front end et le
backend. Donc l'optique est bien de faire du front end first et bien sûr après il ne faut pas laisser
trop de temps, il ne faut pas développer tout ton produit en front end first. Il faut petit à petit
remigrer des parties dans ton backend et essayer de faire fonctionner sans ça. Et après vraiment
ce que je disais aussi et ça on l'a vécu et on l'a même vécu sur des anciens projets à good job,
c'est que s'il n'y en a pas de la vraie data sur certaines features ça ne marchera pas. Pourquoi ?
Parce qu'on va valider ça avec oui le super success case quoi, au final le proto c'est pareil. Si on
fait ça juste avec deux cas métiers possibles à utiliser et que ça fonctionne, ben oui en effet
ça fonctionne mais c'est pas sûr que dans le cas de la vie réelle avec de la vraie data que ta
solution va fonctionner. Donc ça c'est très important.
Oui c'est toujours ce B-Mod Live, il faut que ton jeu de données que tu rentres qui
s'affailles soit le plus proche possible de la réalité sinon tu passes peut-être à côté de
quelque chose quoi.
C'est ça mais franchement après c'est un... Sinon je suis devenu un feedback dessus, c'est
quand même hyper positif, on l'a réitéré et on le réitera. Même la partie produit design,
ils sont hyper contents parce qu'en fait c'est énormément plus fluide de la façon qu'on travaille
dans cette façon là donc c'est voilà ça.
Est-ce que tu t'es documenté sur quelle ressource tu as allé piocher pour récupérer ces choses-là ?
Est-ce que tu as trouvé du retour d'expérience ? Est-ce qu'il y a des gens qui ont partagé
des choses, formalisé des choses ?
Oui alors moi j'ai beaucoup discuté avec, je pense que tu le connais, Nikaï Lazerade,
mais j'ai pas mal discuté avec lui sur cette pratique-là parce que en fait c'était sur
son discussion avec lui, qu'il m'a un petit tir sur ce point-là. Après j'ai pas vraiment trouvé
de vraies littératures là-dessus, je pense qu'il faudrait vraiment se documenter dessus là maintenant
pour pouvoir se trouver des choses, mais moi j'ai rien trouvé de particulier dessus.
Et après c'est plus sincèrement de comment découper les choses, comment l'essayer d'avoir
du feedback rapide, qui nous ont amené à dire ok mais de toute façon c'est du bon sens
et comment l'implémenter. Après c'est les outils techniques que j'ai cités tout
à l'heure qui permettent de le faire.
Ça marche. Et que David on a bien mangé la boîte de temps, merci d'être venu,
si les auditeurs veulent en savoir plus sur ce que tu fais, te suivre ou est-ce qu'ils peuvent venir ?
Alors moi je me rend pas très publié sur les réseaux sociaux et tout ça,
par contre je peux parler du blog Tech de Goodjobs et TechGoodjob.com, je te donnerai le lien.
Mais en tout cas là on publie pas mal de petits articles sur la qualité logicielle,
sur du no code aussi parce qu'on fait du no code de Goodjob et PM et tout ça.
Tout bien généré en général.
Ah bah super, on mettra le lien dans la description de l'épisode.
Merci David d'être venu aujourd'hui.
Merci à toi.
Quand t'as t'en sur auditeur, comme d'habitude j'espère que t'as aimé cet épisode.
Si tu as envie d'en savoir plus, pour apprendre à écrire du code durable,
pour te préparer à faire de l'architecture hexagonale, faire du TDD,
apprendre à refactoriser tes classes et à écrire du code un petit peu plus propre.
Je t'invite à découvrir le cursus artisan-developer sur companion.artisan-developer.fr rubrique formation.
Je te dis à bientôt.