Et quel développeur n'a jamais eu l'impression que ces réponses n'étaient qu'une façon d'évacuer la proposition innovante ? Surtout quand on entend : « il faut d'abord qualifier une solution avant de l'utiliser sur un projet, et ça n'est pas aussi simple que tu le penses ».
Alors l'architecte logiciel est-il trop frileux face aux demandes innovantes des développeurs ?
C'est sans doute l’interprétation qu'en fera le développeur. Mais il faut reconnaître qu'avant d'adopter une technologie, il faut tout de même en mesurer les risques et les opportunités. Et c'est bien cette étude de la valeur qui prend du temps, voire enterre l'innovation dans l’œuf.
Une solution pour faire élire votre langage ou votre framework fétiche au rang d'opportunité à saisir, serait de la rendre séduisante au regard du boss et de l'architecte. Bref, proposez une analyse de la valeur qui consacre votre plateforme. Pour cela, voici quelques pistes :
- porter aux yeux du boss, via la mobilité, quelques fonctionnalités embryonnaires d'un système qui reste à développer pour 95 %. Cette méthode est très employée dans le décisionnel ;
- faire un Proof Of Concept avec l'accord du chef de projet sur un périmètre faible pour montrer le temps de développement gagnable. C'est le chef de projet qui portera le risque et éventuellement les lauriers de l'innovation. Mais importe peu la gloire pourvu que le développeur ait l'ivresse (d'utiliser son nouveau langage préféré) ;
- produire une analyse focalisée sur les axes favoris de l'architecte. Pour cela, il faudra dialoguer avec l'architecte au cours d'une partie de bowling ou d'un baby-foot pour connaitre ses préoccupations (ingénierie sociale).
Mon prochain post présentera quelques arguments à faire valoir auprès de l'architecte pour l'adoption de node.js et angular.js en lieu et place de JEE.
Et vous ?
Qu'en pensez-vous ?