Ce que j'aime dans les projets, c'est qu'on fabrique quelque chose. Quand on y pense, c'est beau de voir toutes cette effeverscense, les gens qui bougent, les esprits en fusion. Ce qui est aussi intéressant, c'est de voir les différents points de vue des acteurs d'un projet. C'est un peu comme au cinéma. Il y a en a qui aime se mettre en bas pour être immergé dans le film et d'autres qui préfère les sièges du haut pour avoir une vue d'ensemble. Et bien c'est un peu pareil en entreprise.
Par exemple, le codeur (au hasard...) est focalisé sur la conception technique du produit. Il a deux niveaux de vision : de près et de loin, tout en restant proche du sol. Je m'explique. De près, il a le nez dans son application. C'est un peu normal, il la code. Néanmoins, il lève très souvent les yeux pour regarder au loin. Non pas pour admirer le bleu turquoise de la cloison qui le sépare de son collègue d'en face mais pour projeter son application dans le futur. Comment se comportera son code à la première demande de changement? Son application sera-t-elle facilement évolutive, migrable? Bref, c'est la hantise du concepteur : concevoir un truc bancal. A tel point qu'il regarde parfois tellement loin qu'il arrive à des équations en rupture totale avec l'espace-temps. Dans ce cas symptomatique, il s'aperçoit généralement à la fin de la journée qu'il n'a rien produit! Et ça, ça coûte très cher à l'entreprise en argent et très cher au développeur en satisfaction. Bref, malgré ce regard porté au loin, le codeur reste souvent au niveau du sol. Je veux dire par là qu'il reste principalement au niveau technique de l'application. Et c'est un peu normal : comment pourrait-il imaginer ce que deviendra le métier de son client? D'abord, son client sait-il lui même ce que sera son métier demain? Moi, quand j'achète une perceuse, c'est que j'en ai besoin maintenant. Si, dans un an, il m'en faut une plus puissante, j'en achèterai une autre. De plus, le codeur n'a pas une vision globale du métier de l'entreprise. Du coup, il prépare son application à recevoir l'inconnu. Et même s'il sait que ça coûte cher à l'entreprise sur le moment, il a la conviction de la préparer à l'avenir (d'autant plus qu'elle n'accepterait pas de refaire toute l'application à la première demande d'évolution un peu carton). Reprenons pour résumer : codeur = visions de près et de loin proche du sol.
L'utilisateur, lui, a plutôt une vision intermédiaire. C'est le gars qui va chez Renault et qui fait trois fois le tour de la Mégane. Il monte dedans, touche les boutons. Il se fout de savoir si la voiture a un des disques de frein ventilés sans amiante patin, couffin, etc, etc... Il est très factuel : la Mégane, c'est une voiture (oui oui). Se projeter dans l'avenir de la Mégane, ce n'est pas forcément son truc. Seul hic, le modèle qu'il souhaite avoir n'a jamais "l'Option" qui déchire. Il est soit frustré parce que son application ne fait pas ce qu'il veut, soit résigné parce qu'elle n'a jamais fait ce qu'il voulait (c'est pire), soit chiant car il harcèle sans arrêt le service informatique. Dès fois, il est satisfait. Quand c'est le cas, il faut savourer ce moment d'exception. Sa vision est aussi quelquefois bouillonnante. Il s'aperçoit en pleine recette de l'application qu'elle pourrait faire ceci... et cela... et puis ça... et ainsi de suite. Dans ce cas, il faut sortir son arme secrête : le chef de projet qui dit NON. (Le chef de projet PAS MAINTENANT est aussi assez efficace et moins conflictuel)
Quant au DSI, c'est celui qui a une vision de loin et de haut. En principe, il aime bien s'assoire tout en haut au cinéma. Il regarde de haut ses projets parce qu'il aime tous les voir en même temps. Il les regarde de haut parce que c'est le métier autour de son SI qu'il aime observer. Il regarde aussi au loin pour essayer de préparer l'entreprise à l'avenir. Finalement, la technique l'emmerde probablement royalement. Elle ralentie ses idées. Le rêve du DSI, c'est le développement "PowerPoint" : si tôt projeté, si tôt réalisé. Au quotidien, il trouve ses collaborateurs pas assez "méta", "high level". Le plus terrible, c'est qu'ils ne peuvent pas vraiment l'être car ils dépensent déjà toute leur énergie à se débattre dans la glue de la réalité du terrain.
Mais alors, développeur et DSI ont donc tous deux leur vision de loin du projet? Oui. Sauf qu'elle n'est pas identique, d'où leur sentiment parfois d'incompréhension mutuelle. Ils vivent deux réalités différentes autour d'un même projet. Pourtant, ils ont le sentiment faire l'effort de prendre du recul par rapport au projet. Pas simple.
Quel est donc le dénominateur commun à tout cela? J'ai malheureusement l'impression qu'il est tout petit : juste le métier du projet, son service rendu. Hélàs, vous devez accepter messieurs les codeurs que votre DSI a peu d'intérêt pour la technique du moment que ce service est rendu. Messieurs les DSI, vous devez accepter que la technique est un mal nécessaire et qu'il a un coût en argent et en temps. Messieurs les utilisateurs, vous devez accepter que certaines fonctionnalités ne soient pas développées. C'est donc une affaire de compromis où chacun met de l'eau dans son vin. Les projets informatiques seraient donc condamnés avoir des DSI frustrés, des utilisateurs jamais complètement satisfaits et des développeurs se sentant déconsidérés? Peut-être. Soyons indulgents les uns envers les autres et acceptons d'avancer moins vite, mais tous ensemble dans la même direction. Ca sera déjà pas mal.
Aucun commentaire:
Enregistrer un commentaire