Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Salut ! Aujourd'hui, je suis heureux de te retrouver sur un épisode à une seule voie.
Quelques news avant de rentrer dans le cœur de l'épisode d'aujourd'hui.
D'abord, je sais pas si tu l'as remarqué depuis quelques temps, j'ai basculé le blog,
pas le blog, le podcast, sur la plateforme Ocha.
Ocha qui a l'air assez prometteuse, dédié au podcast et j'ai parlé avec son fondateur.
Ils ont vraiment une approche que je trouve intéressante.
Du coup, t'inquiète pas, la city sur Suncloud, le podcast Trestra dispose sur Suncloud.
Mais j'ai basculé sur Ocha et je t'invite vraiment à aller jeter un œil.
En tout cas, tu verras que dans les intégrations que je fais sur les articles,
sur artisandeveloper.fr, tu as le player Ocha et rien que ça déjà,
ça me donne envie d'utiliser Ocha parce qu'il y a des petites choses que j'aime bien.
Le player, tu peux mettre un léger facteur d'accélération.
Des fois, je trouve que je parle un petit peu lentement.
Donc si tu as envie d'accélérer le truc, tu peux faire des fois un 25 ou un demi
pour aller plus vite sur l'épisode.
Des fois, 10 minutes, c'est même trop long.
Donc si tu veux le faire en plus court, tu peux.
Il y a aussi tout un historique des derniers épisodes avec leur player.
Je trouve ça intéressant parce que du coup, si ça fait longtemps que tu n'as pas regardé
ou écouté les épisodes, tu peux assez facilement te laisser guider,
te laisser porter et reprendre l'historique.
Et puis un truc sympa aussi que je trouve, c'est qu'il s'occupe de publier sur Spotify aussi.
Donc je ne suis même pas allé vérifier le truc que je le fasse.
Si tu es sur Spotify, je suis curieux de savoir est-ce que tu vois bien le podcast?
En tout cas, normalement, tu peux avoir le podcast grâce à Ocha sur Spotify.
Et rien que pour tout ça, c'est cool.
Merci les gars, c'est top ce que vous faites.
Dans la série des news, je suis à Grenoble cette semaine
et on a au moins trois occasions de se rencontrer
puisqu'il y a le grand événement agile Grenoble, les 14, 15 et 16.
Donc on aura l'occasion de se rencontrer soit le 14, déjà lors du salon.
Je ferai une session aussi à 14h40, le 14 sur comment démêler le plat spaghetti.
Je t'invite à citer dans le coin, à passer une tête
et j'espère qu'on pourra se rencontrer.
On a l'occasion de se voir aussi le 15 dans la journée,
mais également le 13 au soir au Human Talk Grenoble.
Le 14 au soir dans l'after où on va faire des jeux agile.
Tout ça, ça a l'air très bien.
Et le 15 au soir où je rencontre la communauté craft man de Grenoble.
Il faut un événement pour ça, vraiment.
Voilà, j'écoute, j'espère que si tu es dans le coin, on pourra se rencontrer.
Ça me fera super plaisir de te payer un café
et puis de t'chatter un peu sur la communauté, les bonnes pratiques
et puis ce qui te plaira.
Voilà pour les news.
Également, cette épisode va inaugurer quelque chose que j'ai envie de lancer.
Et je suis curieux de ton feedback aussi là-dessus.
De toute façon, je le verrai bien.
Si personne joue le jeu, c'est que c'est intéressant.
Personne.
Ce que je te propose, c'est de m'envoyer une question ou une ou plusieurs questions.
D'ailleurs, j'ai les deux aliases avec ou sans pluriel.
Elle marche à questionarobaseartisandeveloper.fr
pour me poser des questions sur sur ton quotidien,
sur les difficultés que tu peux rencontrer,
sur les questions que tu te poses et où tu aimerais bien un éclairage de ma part.
Et j'en ferai un épisode de podcast.
Alors aujourd'hui, merci Jérémie pour ta question.
Jérémie qui nous demande,
est-ce que tu penses que tu pourrais faire un podcast
sur l'usage de l'agilité au sein de ta société
pour schématiser sa commercialisation à vos clients ?
Alors c'est vrai qu'il faut juste, je remets deux éléments de contexte.
Moi, j'ai également une société qui est la boîte qui me fait vivre aujourd'hui,
avec sa pâle agile idée, on fait du développement sur mesure.
On est une petite ESN, toute petite, on est trois.
Alors d'abord, j'ai remis pour commencer, je ne commercialise pas d'agilité.
En fait, ce que je vends, c'est du logiciel sur mesure.
Et il se trouve que je le fais avec une approche agile.
Ça peut paraître surprenant, déjà comme démarrage de réponse,
mais je... en fait, même si c'est dans le nom de la boîte,
en fait, je me rends compte que l'agilité n'intéresse pas grand monde.
Je commence à avoir à peine des gens qui sont sensibles,
en tout cas dans le réseau des prospects que j'ai, des clients que j'ai.
Et le point principal qui les intéresse quand je parle d'agilité,
c'est les itérations courtes.
Ça, ils se disent, ah cool, je vais pouvoir commencer à mettre les mains
dans le logiciel plus vite, ça a l'air bien.
Parce que je pense que les effets BingBang avec des projets sur plusieurs mois
ou des espèces d'énormes livraisons où tu te prends tout dans la tête d'un coup,
je pense que les gens, ça commence à être diffus
et connu qu'on n'est pas obligé de subir ça
et que si on veut augmenter les chances de réussite du projet,
c'est d'ailleurs peut-être pas la meilleure approche
et que les itérations courtes apportent énormément
dans les chances de voir le projet grandir et voluer.
Après, très clairement, presque personne n'est sensible
aux arguments de code propre, de bonne qualité de code,
de craftsmanship, de TDD et tout ces trucs-là.
En fait, il faut être assez lucide, ce n'est pas différentiant
parce que tout le monde dit qu'il fait du bon boulot.
Et puis après tout, chacun, je pense, croit qu'il fait du bon boulot.
Et puis la qualité, ça se voit pas tout de suite.
Dire que c'est assez, ce que je remarque, c'est que les gens qui travaillent avec nous
sont contents de travailler avec nous,
mais ils se rendent compte à quel point ils sont contents
après avoir commencé à travailler avec nous.
Toute la difficulté, c'est comment est-ce que tu leur fais sentir ça en avance
sur la contractualisation, ça m'aiderait bien des fois.
Mais bon, écoute, honnêtement, aujourd'hui,
c'est vrai que les arguments de qualité de code,
ce n'est pas ce qui satisfait ou ce qui est, je pense, déclencheur.
En tout cas, ce n'est pas l'impression que j'ai.
Après, pour essayer de répondre plus directement à ta question,
on a deux modes de contractualisation.
Un premier mode qui est à la régie, c'est-à-dire à l'heure au temps passé.
Finalement, du point de vue de ta question,
comment est-ce qu'on met en oeuvre l'agilité ?
C'est assez facile.
Du coup, on se laisse un peu guidé par le client,
par sa manière de bosser, parce qu'il nous semble bien collé.
Et là, on fait de tout, on fait des interrations ultra courtes
à la nuit où on livre toutes les demi-journées, quasiment.
On livre plusieurs fois par jour en prod,
jusqu'à des intérations ultra longues,
où on a parfois plusieurs mois entre deux livraisons.
Et des fois, on a des intérations qui s'étalent sur un moins
et qui durent une demi-journée de travail.
Ça, c'est le pire.
Et à l'inverse, on peut aller jusqu'à livrer plusieurs fois par jour
et on est plusieurs à bosser en même temps sur le même projet.
En général, le client se rend compte assez vite
de l'avantage de travailler à la régie.
Mais honnêtement, je ne le propose pas à tout le monde.
Il faut quand même que le client soit un petit peu habitué à ce mode de travail,
parce que s'il n'est pas habitué à faire du logiciel,
s'il n'est pas habitué à ce mode-là,
il ne se rend pas forcément compte que c'est à lui de porter le risque de réalisation.
Et si jamais à un moment donné, le budget est consommé,
alors que le travail n'est pas fini,
il peut avoir l'impression de se sentir floué.
C'est pour ça que je travaille quand même encore beaucoup au forfait,
ce fameux forfait qui est tant décrillé par la communauté.
Alors très clairement, on va aller tout de suite ce que j'aime pas dans le forfait,
c'est que dans le forfait,
ce que j'aime pas, c'est le côté un peu comme dans les restaurants All You Can Eat.
Puisque finalement, une fois que tu as payé 18 euros,
ta place de resto,
qu'est-ce qu'il va y avoir comme principe de base ?
C'est que tu dois t'en mettre plein l'estomac, puisque tu as payé le repas.
J'ai l'impression parfois que le forfait, c'est un peu pareil.
Les clients, on a beau leur dire, mais ça, vous en avez pas besoin.
Ils te disent, oui, mais on sait jamais.
Et au final, on se retrouve à avoir un logiciel
qui devient gros, en fait, avec du code qui n'est pas forcément utile,
voire carrément inutile.
Mais bon, c'est un petit peu la limite du mode forfait.
Après, très clairement,
le forfait, c'est aussi une bonne manière pour le client de se sentir rassuré,
de savoir où il met le pied, les pieds.
Et c'est quand même important.
Ce n'est pas tant moi ce qui me perturbe dans le forfait,
ce qui est là où je suis toujours insatisfait pour être honnête.
Ce n'est pas tant sur le mode forfait, c'est sûr.
Comment est-ce qu'on définit vraiment ce qui est à réaliser ?
Alors, j'ai essayé plusieurs approches.
J'ai essayé avec le cahier des charges super précis.
Bon, au final, ça ne sert à rien,
puisqu'on ne fait jamais, ne serait-ce que la moitié de ce qui a été prévu comme prévu.
En fait, ce n'est pas très grave.
Au final, on s'arrange, on discute,
et on trouve des solutions, on trouve des arrangements,
on substitue un truc à un autre.
Et finalement, on arrive à rester dans l'enveloppe,
sans pour autant renier notre marge.
Après, s'il manque des choses,
ou là, très clairement,
c'est évident que ce n'était pas prévu,
et il manque quelque chose.
Moi, j'aime pas faire des avenants.
J'aime pas faire des avenants parce que, quelque part,
j'ai l'impression de prendre un peu le client au piège
ou le client peut se sentir un peu enfermé.
Je préfère systématiquement repousser dans les versions suivantes.
Après, si le client veut vraiment quelque chose
dans le cadre de la livraison,
alors que ce n'était pas prévu,
on va faire une proposition d'avenant, on va rajouter quelque chose.
Mais en général, on s'en sort très bien avec des V2, V3.
Dès lors qu'on est dans une logique de cycle,
je peux rencontre que les clients acceptent assez facilement
de passer aux choses de passer à la version suivante.
Et au final, sur ce mode de contractualisation,
ce qui marche le mieux aujourd'hui,
c'est qu'on fait une liste des cas d'usage de l'application.
Comme ça, on reste très fonctionnel.
Et après, on croise les doigts.
C'est-à-dire que des fois, on va avoir
survolé quelque chose et on va l'avoir sous-estimé.
Et bien là, c'est tant pis pour nous.
Soit c'est le client qui imaginait
quelque chose de beau ou plus compliqué
qu'est-ce qu'on avait en tête.
Là, on essaye de voir avec le client
comment on peut simplifier les choses.
Bien souvent, le client comprend, s'adapte
et on fait des propositions de simplification
et ça marche bien.
Et puis de temps en temps,
ben non, il y avait vraiment quelque chose d'importance.
C'est vraiment important pour le business.
Il faut le faire, il faut le faire comme ça.
Et ça marche bien.
Finalement, on en discute.
Autre chose que j'avais testé,
c'était de définir des wireframes en amont.
Mais très franchement, ça prend beaucoup de travail
en amont de la contractualisation.
Et alors pour certains, c'est OK.
Mais moi, ce que je trouve gênant,
c'est que du coup, si je veux vraiment
pouvoir supporter ce coup-là,
ben ça veut dire qu'il faut que je augmente mes coûts.
Et j'essaye d'avoir des coûts les plus compétitifs possibles.
Donc, c'est à été un petit peu compliqué.
Et finalement, ce n'est plus une approche qu'on comprend.
Ou alors, c'est dans le cadre d'une prestation
ou une vraie prestration de définition de wireframe.
Mais en général, à ce moment-là,
on travaille avec un UX designer,
ce qui me paraît plus pertinent que de le faire nous.
Donc voilà, finalement, ce qui marche le mieux aujourd'hui pour nous,
c'est de travailler à partir de quelque chose
qui a un besoin qui a déjà été établi,
que ce soit par, je te dis, un UX designer
qui a fait les wireframes ou par un chef de projet
qui nous a fait une première version de KID charge.
Et à partir de là, nous, on fait la liste des cas d'usage
auquel on répond dans l'offre commercial qu'on envoie.
Voilà, voilà pour ta réponse, Jérémy.
J'espère que ça répond vraiment à ta question.
Si ce n'est pas le cas, dis-le moi et on continue dans les commentaires.
Si c'est le cas, dis-le moi aussi, ça me fera plaisir.
Et puis, quant à toi, chers auditeurs, voilà,
je te répète, question à rebase artisan développeur.
Envoie-moi les questions qui te tarabustent
et ça me donnera des bons sujets d'épisode.
Je te remercie et je te dis à demain.