[Debat] L'orgueil, le pire ennemi du projet

[nuke_y]

Salut à tous. J'aurai bien lancé ce débat dans la partie "Débats sur le développement" mais j'ai peur qu'il fasse trop philosophique et pas assez sérieux pour ce forum, alors je le met dans la taverne.

Je crois que c'est François Mitterand, à qui un journaliste demandait ce qui dirigeait le monde (l'argent, les femmes ?), qui a répondu

Non, c'est l'orgueil.

En y reflechissant bien, je me demande si l'orgueil n'est pas le pire ennemi de tous les projets, et bien évidemment du projet informatique.

Développons un peu : je me suis posé la question suivante : comment et pourquoi si peu de projets informatiques terminent dans les temps, les coûts et les fonctionnalités vendus ? Comment est-ce possible alors que des dizaines de chefs de projets sont formés aux techniques les plus avancées de gestion de projet ?

Bien sûr, on rejette toujours la faute sur les autres :
- C'est les développeurs qui n'en font qu'à leur tête,
- C'est le chef de projet qui gère comme un pied,
- C'est l'estimation qui a été mal faite,
- C'est le niveau n-1 qui ne remonte pas les problèmes.

Si on occulte le facteur d'incompétence (oui, si on mène un projet avec des développeurs nuls, dirigés par un chef de projet jamais là et à partir d'une analyse incomplète, ça risque de poser des problèmes), je pense que la principale raison du plantage des projets informatiques nécessitant un minimum de gestion de projet est l'orgueil des chefs de projet.

Que le chef de projet (ou même le développeur tout seul) qui n'a pas eu la prétention "d'y arriver" et "dans les temps" lève la main. Combien de projets sont partis mal définis, mal dimensionnés mais dirigés par des gens pensants que, eux, ils arriveraient à faire mieux que les autres ?

Combien de problèmes n'ont pas été remontés en temps et en heure parce que le responsable pensait être capable "de s'en sortir" ?

Combien de bouts de codes ont été buggés parce que le développeur préférait passer son temps à "optimiser" plutôt qu'à tester, parce qu'il est sûr de son code et surtout parce que c'est plus valorisant de livrer un code qui tourne 3 fois plus vite que la version précédente ?

Combien de grands chefs ont eu la prétention d'organiser une migration "sans perte de service ni de fonctionnalité" et combien ont réussi ?

D'un certain point de vue, n'est-ce pas l'orgueil qui nous fait avancer, qui nous pousse à essayer de toujours faire mieux. L'orgueil n'est-il pas ce que nous appellons "la satisfaction personnelle" si présente dans tous les projets (personnels, en entreprise, open source, etc.) ? N'est-ce pas par orgueil que je vous fait part de mes reflexions, dans l'espoir que vous m'approuverez ?

Et enfin, l'orgueil étant principalement un défaut des hommes, les femmes ne sont-elles pas de bien meilleures chefs de projets ?

Sur ce, bon appétit

[Kenji]

Envoyé par nuke_y

Et enfin, l'orgueil étant principalement un défaut des hommes, les femmes ne sont-elles pas de bien meilleures chefs de projets ?

Autant je suis d'accord avec ce qui précède autant je suis totalement en désaccord avec cette phrase.

Je pense que la parité s'applique même au niveau de l'orgueil et qu'il faut arrêter de prêter des qualités/défauts aux femmes sous pretexte qu'elles sont des femmes.

Sinon oui je pense qu'il y a du avoir pas mal de projets qui ont avorté à cause du fait que le chef de projet ne voulait pas choisir une solution meilleure que la sienne à cause de son orgueil.

[nuke_y]

Ouaih enfin cette phrase là, c'était plus la note d'humour pour conclure le truc

[DavidDeTroyes]

Moi je suis d'accord avec toi en gros.

Au jour d'aujourd'hui je bosse seul (je suis mon propre chef de projet, mon analyseur et mon testeur) et j'ai tres peu d'imperatif de temps mais dans mon ancienne boite c'etait une autre histoire. On etait 5, 1 gerant/chef de projet/analyseur, 1 secretaire et 3 developpeurs. On avait des "cahiers des charges" fait à la va-vite basé sur des analyses faites à la va-vite et comme on avait peut de temps pour finir le projet et le livrer, le developpement se faisais à la va-vite (donc niveau test et debuggage, c'etait aussi à la va-vite !).

Le chef, par orgueil, nous donnais sa vision des choses du futur projet (en pensant que son idée est la meilleure) et nous developpions à notre manière... Bref rien de bien, quoi !

Aujourd'hui je bosse seul et donc je doit mettre mon orgueil de coté pour avancé un minimum... Je dit pas que la solution c'est de tout faire seul (dans de tres gros projet c'est impossible) mais que plus l'equipe est petite et plus, je pense, que le projet sera proche de la finalité desirée.

C'etait mon point de vue mais je doit etre hors sujet, non ?

[nuke_y]

Ben pas tellement hors sujet en fait. Je pense aussi que beaucoup de problèmes de communication sont causés par l'orgueil. C'est aussi l'orgueil qui nous fait dire (qui ne l'a pas dit ?) "Mais c'est quoi cette merde ? Ce type a programmé ça comme un blaireau." chaque fois qu'on tombe sur un bout de code qui n'est pas le notre.

[r0d]

Si je puis me permettre de rajouter mon grain de sel, je dirais que ce n'est tout de même pas aussi simple que ça.

Il m'est arrivé, récemment encore, de coder presque toute la nuit pour finir une dll que mon CP (chef de projet) attendait pour une recette. S'il y a certainement un part d'orgueil dans ce comportement, il n'en est pas le seul vecteur. Il y a aussi l'envie de faire plaisir à un ami (ce CP est un ami en dehors du travail). Il y a également le respect du client, une certaine éthique professionnelle, la volonté de plaire aux supérieurs (si on veut une augmentation, une promotion, etc.).

De même pour l'exemple du "Rhaaa j'y crois pas, je vais devoir bosser sur du code fait par un stagiaire!! Quoi? C'était pas un stagiaire?! Mais c'est pas vrai!! Regardez-moi ce code!!". Je n'impute pas cette réaction à la seule expression de l'orgueil. Il y a, ici aussi, beaucoup de choses qui entrent en jeu: différences entre les formations, expériences différentes entre les développeurs, le fait qu'on voit plus aisément les erreurs (en général on les a déjà faites) que les points positifs, etc.

Enfin voilà, tout ça pour dire que c'est, à mon avis, plus compliqué et que nous ne pouvons pas raisonnablement rapporter tout cela à l'orgueil. Pour moi, le problème vient des fondations. Le principe même que l'unique but d'une entreprise soit de faire du profit. C'est ici que se dissimule de diable, et c'est à partir de là qu'il dirige les tentacules du mal dans notre système. Babylone perverti l'Eden, les anges n'ont plus de viagra et les succubes s'ennuient... la fin de l'univers connu est proche!!

ok je

[edit]Les 2 dernières phrases sont de l'humour (enfin, une tentative )

[la drogue c'est mal]

je me suis posé la question suivante : comment et pourquoi si peu de projets informatiques terminent dans les temps, les coûts et les fonctionnalités vendus ? Comment est-ce possible alors que des dizaines de chefs de projets sont formés aux techniques les plus avancées de gestion de projet ?

les raisons sont multiples, dans le désordre et sans trop développer :

- une certaine incompréhension entre les acteurs d'un projet: Un informaticien ne connait pas les contraintes d'un trader et inversement

- un trop grand nombre d'acteur : plus il y a de personne sur un projet, plus les informations ont du mal à circuler

- une estimation des charges faites trop tot

- une concurence "agressive" sur les projets: la société qui proposera la réalisation d'un projet la plus rapide et la moins couteuse remportera l'appel d'offre

- le turn-over et l'incapacité des entreprises à se constituer un capital connaissance

- impossibilité de prévoir l'imprevisible

- faille dans les modèles de gestion de projet

- hétérogénité lié à la complexité du métier: quand on dit qu'il faut 5j*h pour réaliser une tache signifie qu'il faudra 2j pour un expert et 7j pour un débutant. On ne tient pas compte du "niveau" de son equipe en se disant qu'en moyenne, sur le projet, tout s'équilibre. Ca fonctionne sauf quand on se retrouve sur un point bloquant

- les projets doivent integrer le moule d'un modèle de gestion alors que d'apres moi ca doit etre l'inverse. Je trouve ridicule de dire que l'expression des besoins ne doit pas dépasser XXj et que ce soit graver dans le marbre

- le facteur humain (dont l'orgueuil)

- etc...

donc l'orgueil est l'une des raisons parmis bcp d'autre

[Nemerle]

une rq rapide: j'ai encadré de nombreux prestataires de SSII, certains sur des projets de plus de 2 ans.

Le prestataire SSII est une petite chose fragile, car... parfois orgueilleux certes, mais surtout très susceptible.

Mais quand une "âme" d'équipe se crée, le prestatairee SSII est capable de vivre uniquement avec du café, sans dormir...

Et c'est de la responsabilité du manager d'équipe de créer cette ame d'équipe, et de faire disparaitre l'orgeuil de certains. ET de faire des récup. gratos après une grosse période de charge...

Car on trouve aussi toujours meilleurs que soit (et surtout, penser qu'on est bon, c'est une chose, le prouver, c'est une autre). C'est pourquoi en particulier nous on fait passer des tests (1h30) écrits portant sur le core technique & projet avant d'accepter un prestataire. Et certains repartent la queue entre les jambes (t'façon, moi j'aurais 2/20 au test )