Rôle de la communication dans le génie logiciel/Le rythme de la communication
La tension dans le dialogue autour du logiciel ressemble un peu à celle d'une histoire. L'attention des spectateurs et des acteurs sera captée s'il y a un élément de tension. Si les protagonistes s'ennuient, l'information est tellement déformée que le logiciel dépérit. Il est très intéressant et productif de faire l’inventaire des dialogues en cours et de chercher à modifier les conditions qui les rendent ennuyeux, le cas échéant.
Si on imagine qu'une librairie d'animation 3D est le sujet d'intérêt d'un utilisateur, d'un développeur, d'un entrepreneur et d'un passant curieux. La combinatoire des dialogues entre ses acteurs mérite un peu d'attention. En modifiant le rythme de la communication, même sans modifier la qualité des échanges, on joue sur la tension. Par exemple, si l'utilisateur dit au développeur qu’il désire un système de skinning, la tension est affaiblie parce que le problème est grand et la perspective de résolution lointaine. Si le développeur propose en retour a l'utilisateur de commencer par faire, en quelque heures au plus, une matrice des caractéristiques de quelques systèmes de skinning, il crée de la tension parce que la résolution est proche.
La modification du rythme dans le dialogue est probablement le ressort le plus puissant pour maintenir la tension. C'est aussi l’occasion des absurdités les plus spectaculaires. Une communication très hachée peut conduire les protagonistes à tourner en rond par manque de perspective. Il y a quelque chose d'indicible dans le processus qui mène à un équilibre satisfaisant entre la direction générale que prend un logiciel et les acteurs qui gravitent autour et les histoires courtes qui maintiennent leurs sens en éveil au jour le jour.
Exemple: L'ISP A dit faisons une box triple play, les développeurs approuvent, prennent des logiciels libres, corrigent des problèmes, terminent la ABOX. L'ISP B dit faisons une box triple play, les développeurs approuvent, prennent des logiciels libres, corrigent les mêmes problèmes que l'ISP A et d'autres encore, terminent la BBOX. L'ISP A dit faisons une nouvelle version de la ABOX, corrigent les mêmes problèmes que l'ISP B et terminent la ABOXv2. L'effort nécessaire est multiplié sans raison par déséquilibre entre le dialogue à court terme (construire une BOX pour les clients) et le dialogue à long terme (enrichir le patrimoine Logiciel Libre).
