Je dois être déraisonnable....
By glazou on Sunday 23 May 2004, 19:05 - Computing - Permalink
Alain Lefebvre est consultant, conférencier et écrivain et nous a pondu un Manifeste pour une Informatique (enfin) raisonnable.
- 1- Évitez la complexité
- bon, d'accord
- 2- Éxigez des choix techniques open source de la part de vos fournisseurs
- oui!
- 3- Recherchez la mutualisation
- non, pas nécessairement
- 4- Évitez les solutions “à la pointe de la technique”
- je suis fermement pas d'accord, cette recommandation est ridicule
- 5- Évitez les solution structurantes
- warf
- 6- Utilisez les solutions standards
- oui!
- 7- Préférez les solutions externes
- ah, encore un adepte du Not Invented Here qui fait tant de ravages en France... Pfffff
- 8- Minimisez votre effort de développement
- ah, Lefebvre était absolument nécessaire pour nous apprendre ça
- 9- Gérez vos risques
- ça aussi...
- 10- Ne laissez pas les techniciens diriger vos évolutions
- alors là, j'ai honte, c'est ridicule et minable... c'est avec des conneries comme ça que l'on aboutit à WAP chez Vivendi
Comments
Perso, je suis plutôt d'accord avec lui. ça dépend évidemment de l'interprétation.
Ainsi non, il ne faut pas être partout à la pointe de la nouveauté. Un serveur sous Debian Woody est réellement stable et efficace. Pas besoin de le mettre en Sarge...
Bref, ne pas vouloir être à la pointe de la nouveauté si ça satisfait les besoins. Et plutôt réduire certains besoins pour préférer la stabilité.
D'autres part, je suis aussi d'accord avec le fait de préférez les solutions externes. Ne créez pas un nouveau langage ou un nouveau parseur XML !
Il faut l'interpréter, AMHA, par "Choisissez autant que possible les solutions externes et développez ce qui n'existe pas". Ce que tu fais avec Nvu : tu crées, mais en te basant sur du code déjà existant de Mozilla. Tu ne vas pas développer un nouveau moteur de rendu HTML mais utiliser Gecko dans NVU. C'est exactement le même principe...
De plus, il a le mérité de clairement voir les enjeux de l'OpenSource et des standards (dans la pérénnité et non dans le prix).
Franchement, si son discours pouvait être plus écouté, ce serait une excellente chose. Mais, évidemment, en tant que développeur de pointe, tu t'apparentes plus aux "lanceurs de fusées" et donc tu n'es par définition par raisonnable. C'est très bien, il en faut. Juste que les conseils ne te sont pas réellement addressés..
Pour le 7, avec l'exemple qu'il a donné, je pense qu'il n'a pas forcément tord. J'ai déjà eu l'exemple d'un client qui voulait absolument tout faire lui même au niveau hebergement. Seulement il s'est rendu compte que c'était un métier mais il ne voulait pas investir suffisement pour supporter la charge (employer un admin système par exemple, pour surveiller et maintenir ses 2 serveurs et son nouveau parc informatique, alors même qu'il fait du commerce electronique, donc repose une partie de son chiffre d'affaire sur cette infrastructure).
Mais je suis d'accord avec toi, il faut savoir être à l'écoute de "ceux qui connaissent". Trop bien souvent, les avis des techniciens ne sont pas pris en compte et cela amène à des situations farfelues voire mauvaises.
Total, il a eu plein de merde, disait que c'était notre faute, a perdu de l'argent etc...
Externaliser quand on n'a pas les compétences dans le domaine en question : OUI. À moins d'y mettre les moyens nécessaires (mais ce n'est pas donné à tout le monde).
Par contre, il est clair que si en interne il y a les compétences, il ne faut pas externaliser et profiter de cette manne (et innover ! :-))
Pour le 10, c'est sûr que nous, en tant que technicien, on ne peut pas trop aimer
Pour la 4, ça me rappelle mon prof de qualité qui disait :
"Faites toujours tester les technologies par les autres"
Le dernier point est abominable. Il permet de donner de grosses chevilles aux dirigeants en leur permettant de dire "j'ai décidé X", mais comment continuer à faire faire prendre les décision par ceux qui ne comprennent pas ce qu'ils décident ? Sans forcément donner carte blanche aux techniciens (ce qui ne serait pas mieux), ne pas leur donner une grosse voix dans les choix techniques est complètement idiot.
C'est comme ça que dans beaucoup de boites on commence par choisir les logiciels achetés ou les technologies utilisées sans savoir réellement ce qui sera nécessaire. Et par la suite l'équipe de développement et de mise en place s'escrime à "mettre quelque part" le soft acheté parce qu'on leur demande, ou à utiliser une technologie non adaptée.
AMHA vous confondez "Ne laissez pas les techniciens diriger vos évolutions" et "Ne tenez pas compte de l'avis des techniciens".
Le monsieur dit explicitement "Gardez cela en tête quand vous convierez des techniciens à donner leurs avis lors du prochain choix à faire…".
Je percois plutôt cela comme "Vous êtes un gérant. Votre métier, c'est la gestion. Des techniciens sont à votre disposition, prenez compte de leurs avis. Mais attention, ce qu'il présente n'est pas toujours la meilleure solution: vous devez définir précisément vos besoins, les techniciens proproseront les solutions les plus adaptées, c'est ensuite à vous de choisir (en fonction d'autres critères: temps, budget, etc.)".
Si le budget, le temps, les efforts prêt à être concentis etc. sont clairement définis dans un bon cahier des charges, le travail du technicien est d'apporter *la* réponse appropriée (ex: Dire que le WAP est mort né). Dans la mesure où un cahier des charges n'est jamais complet à 100%, c'est au gérant ("manager"), de prendre la décision finale (en se basant sur les données fournis par le technicien).
C'est con à dire, mais je ne comprend pas pourquoi il faut toujours qu'il y ait un rapport de force :
"étudiants vs administration"
"techniciens vs managers"
etc.
Ca serait pas mieux de travailler main dans la main en arretant de se dire "il veut me voler mon autorité!" ?
plagiats
(ex chef de produit (et pas projet (donc du coté "gérant" de la barrière))