Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Nous faisons un métier dont une part essentielle consiste à se comprendre mutuellement.
Les échecs sur les projets viennent rarement de facteurs techniques.
Un produit qui ne fait pas ce dont a besoin le client n'est pas un problème technique.
Bon après il y a les bugs, ça c'est des problèmes techniques, on est d'accord.
Mais on va partir d'un principe, c'est que en général au début du projet au moins,
les bugs apparaissent rarement, les bugs apparaissent surtout avec le temps, sinon c'est un vrai gros problème.
Et en fait, si on se concentre sur un point qui est de transmettre le besoin,
il y a le fameux cahier des charges du XXe siècle qui avait l'objectif de décrire le besoin de manière exhaustive.
Ce cahier des charges cristallise l'idée qu'il est possible de transmettre de l'information via l'écriture.
Alors, dit comme ça, évidemment.
Mais la vraie question est, dans notre cas, est-ce que c'est efficace ?
Est-il efficace de passer du temps à écrire quelque chose qu'il faudra de toute façon prendre le temps de présenter ?
Non parce qu'on est d'accord une bonne fois pour toutes.
Arrêtez de croire, arrête de croire qu'il suffit de décrire ce que tu veux dans un cahier des charges et de l'envoyer au développeur pour recevoir un truc fini un mois plus tard.
Ça marche aussi bien au sein de l'équipe.
Croire qu'il suffit de poster un message sur Basecamp ou le forum interne pour que tout le monde s'approprier le sujet.
Ça marche pas comme ça.
Tu vas avoir besoin de le présenter, le point que tu abords, tu vas avoir besoin de fédérer autour de ça.
Et puis par ailleurs, tu n'écris pas un livre, tu produis une information dont la durée de vie est assez limitée.
Je te donne un exemple, une spécification.
Elle reste rarement valide après la livraison si tu ne la mets pas à jour.
Alors je sais, ça peut paraître étrange parce que la spécification est censée décrire ce qu'on va recevoir.
Mais, dans la vraie vie, ça ne se passe pas toujours comme ça, rarement même.
Et ce n'est pas grave d'ailleurs.
Parce qu'en fait, tout change tout le temps et c'est une super opportunité de coller au plus près du besoin.
Un diagramme d'architecture, un diagramme de classe lui aussi, si tu l'imprimes par exemple, il va être figé.
Elle va rarement rester valide plus de quelques jours.
Ça bouge tout le temps. Le code en interne bouge tout le temps aussi.
Alors du coup, plutôt que de passer toute cette énergie à écrire des choses, on fait comment ?
Le principe 6 du manifeste nous dit, la méthode la plus simple et la plus efficace pour transmettre de l'information à l'équipe et à l'intérieur de celle-ci est le dialogue en face à face.
Il n'y a rien de tel que l'échange direct pour transmettre de l'information.
Et il y a là un double enjeu qu'il faut bien comprendre.
Un enjeu sur le mode de communication d'abord.
Où tu passes de l'écrit à l'oral.
Et l'oral apporte quelque chose de vachement intéressant et l'amène le non-verbal.
Quelque chose qui est très difficile à transmettre dans de l'écrit, à part peut-être avec des emoticons.
Mais j'avoue que j'ai rarement vu des cailles de charge avec des emoticons dedans.
Puis ça serait quand même assez fat je pense.
L'essentiel de la communication vient du non-verbal.
Ce qui est important, ce sont moins les mots qu'on dit que la manière de les dire.
Et puis il y a un autre enjeu aussi.
C'est que quand tu passes dans un échange face à face, tu deviens synchrone.
C'est-à-dire tu es en même temps en train d'aborder la question.
Et du coup ça permet une boucle de rétroaction rapide.
Je peux donner du feedback dans un sens ou dans l'autre sur ce qui est en train d'être fait.
Il y a un atelier que j'aime beaucoup sur ça, l'atelier des spécifieurs.
Ou tu dois décrire une forme géométrique et la faire faire à un développeur.
Les écarts que j'ai pu consater à chaque fois que je le fais sont juste énormes.
Pourquoi ? Parce que d'un côté tu écris quelque chose et tu essaies de décrire quelque chose qui est difficile à transmettre.
Et de l'autre, tu peux ajuster en temps réel et en direct et voir ce que fait l'autre.
Toutes proportions gardées, c'est un peu comme les échanges par email ou les échanges par téléphone.
Tu te rends bien compte que tu fais pas passer la même chose et tu fais pas passer avec le même niveau de finesse les choses.
Et du coup d'ailleurs est-ce que c'est toujours adéquate de faire comme ça ?
Je ne pense pas.
L'écrit asynchrone à ses avantages aussi.
D'abord l'écrit force à poser une réflexion.
Il te permet de structurer ta réflexion.
Il permet de le relire.
Une fois que tu vas te dire quelque chose, c'est dit, tu peux toujours attraper le coup.
Mais l'écrit te permet de produire quelque chose de complet, de cohérent.
Et puis le côté asynchrone à un autre avantage aussi, c'est qu'il permet à chacun de suivre son rythme de travail.
Tu n'es pas obligé à un moment donné de caler, de synchroniser tout le monde pour que tout le monde ait la contrainte de se retrouver au même endroit au même moment.
Alors même endroit, ça peut être dans le virtuel.
Moi je bosse beaucoup en télétravail et c'est essentiellement du Skype.
Et du coup, je suis toujours à la recherche du meilleur compromis entre le temps investi,
l'efficacité du processus, les contraintes imposées sur l'équipe.
Et je jongle et je m'adapte entre les deux.
C'est un équilibre, c'est un équilibre instable que j'essaye de faire évoluer au cours du temps,
selon les phases du projet, la maturité de l'équipe et puis aussi la taille de l'équipe.
Bref, l'important, c'est de rester souple et de s'adapter en cours de route.
Je te remercie d'avoir écouté ce podcast jusqu'au bout.
Si il t'a plu, je t'invite à le partager avec un copain.
Et je te dis à demain, ciao !