Quelles sont les qualités et les compétences que doit avoir un Chef de Projet ?

[souviron34]

Envoyé par javamine

Bon, reprenons depuis le début.
Tu crois vraiment qu'un DSI iraient vendre une migration à son PDG et aux actionnaires en leur disant "Euh oui c'est cher parce qu'il n'y a personne de compétent..." hum...

Intéresse toi d'un peu plus près à ce qui se passe dans les entreprises. Migrer une application coûte très cher (et surtout très risqué), mais il y a un bon ROI pour les évolutions futures. Regarde les architectures cobol, et celle J2EE et Dotnet après, tu comprendras pourquoi c'est 10 fois moins cher de faire évoluer une application qui n'est pas en cobol (en prenant le cas d'un expert cobol d'un coté, et d'un expert J2EE de l'autre).

On voit que franchemet tu n'as pas dû beaucoup fréquenté (et subir) les décisions marketing d'importance sur des gros projets...


Cela n'a pas grand chose à voir avec la technologie nécessaire, et/ou les évolutions en termes de besoins, ou les possibilités, ni avec la finance engagée (de toutes façons, ce sera le client qui paiera). Cela a beaucoup plus à voir avec "qu'est-ce qu'on peut "vendre" qui nous donnera un "plus" par rapport à nos concurrents ?".. Et dans ce cadre, promouvoir qu'on est "à la pointe des avancéées technologiques c'est le nec plus ultra... marketing..

Car comme ce gars du marketing a en face de lui la plupart du temps un autre gars de marketing ou un administratif qui n'y connait rien, les 2 sont dans le même monde de "buzz"....

Envoyé par lepinekong

..snip..
J'aurai encore beaucoup de choses à dire, mais ce sera pour un autre fil peut-être

Excellent témoignage, merci


Mais que rien ne t'empêche d'en dire plus

[javamine]

Envoyé par souviron34

Cela n'a pas grand chose à voir avec la technologie nécessaire, et/ou les évolutions en termes de besoins, ou les possibilités, ni avec la finance engagée (de toutes façons, ce sera le client qui paiera). Cela a beaucoup plus à voir avec "qu'est-ce qu'on peut "vendre" qui nous donnera un "plus" par rapport à nos concurrents ?"..

Il y a comme qui dirait un malentendu.
Je parlais d'entreprises "non informatique", où chez eux, la finance passera avant tout pour leur service informatique (puisque c'est eux qui paient et non un éventuel client).

Tu parles d'entreprises dont leurs métiers est de vendre l'informatique. Tu expliques que c'est par soucis marketing qu'ils prennent des décisions. Qu'est ce qui se cache derrière le marketing? => les retombés financières.
Tu réduis ce que j'ai dis par "finance engagée" or je te parlais de retour sur investissement. Donc même les soit disantes considération marketing sont égale à "on dépense beaucoup plus mais c'est joli ça nous fera vendre plus"

On revient donc sur ce que je t'ai dis => on "migre, casse tout, change de techno" (rayer la mention inutile) uniquement quand on se rend compte que même si on engage de grosses dépenses, ça nous fera gagner plus.

[souviron34]

Envoyé par javamine

On revient donc sur ce que je t'ai dis => on "migre, casse tout, change de techno" (rayer la mention inutile) uniquement quand on se rend compte que même si on engage de grosses dépenses, ça nous fera gagner plus.

C'est ce que j'ai dit plus haut : cela n'a rien à voir avec la techno, et ses évolutions/pérennités, mais tout aveec l'argent..

Ce serait donc au CP de dire : non, on va plus s'emmerder qu'autre chose...

Envoyé par javamine

C'est un besoin business.
Les vieilles applications cobol fonctionnent très bien certes, mais dès qu'il s'agit de faire une évolution, de la maintenance, ... cela coûte beaucoup plus cher que si ces applications utilisait, comme tu le dis, ce qui est novateur.

FAUX..

C'est uniquement parce que les fomations (BTS, DUT, fax, écoles spécialisées) ne forment plus qu'aux nouvelles technos..


C'est comme les mécanos automobile : aucun mécano "normal" ne sait s'en sorir avec les voitures de maintenant..

Pour chaque constructeur il y a des bancs de tests électroniques spécialisés, incompatibles les uns avec les autres..

Alors je veux bien que vous défendiiez cette pratique, mais je suis résolument et fondamentalement contre...

Envoyé par javamine

Parfois il faut mieux tout refaire (et dépenser énormément), pour qu'à l'avenir les évolutions soient moins coûteuses, et donc sur le long terme avoir un bon retour sur investissement.

Tu ne vois pas comme une contradiction, là ??


Faire le total "dépenses énormes pour refaire" + "dépenses moins coûteuses plus tard" (et je suis très dubitatif sur ce point, en particulier à cause justement du turnover des technos) à comparer à "former les jeunes générations à garder les compatibilités avec l'ancien" ???

[javamine]

Envoyé par souviron34

C'est ce que j'ai dit plus haut : cela n'a rien à voir avec la techno, et ses évolutions/pérennités, mais tout aveec l'argent..

C'est ce que je disais aussi donc on est d'accord la dessus.

Envoyé par souviron34

FAUX..

C'est uniquement parce que les fomations (BTS, DUT, fax, écoles spécialisées) ne forment plus qu'aux nouvelles technos..

Tu me dis que c'est faux et après tu donnes un argument qui va dans mon sens. Cherchez l'erreur?
Mais je suis d'accord, c'est pour ça que ce je dis est vrai et tu le confirmes. On ne forme plus qu'aux nouvelles technos, donc les compétences vieux systèmes sont plus rares donc plus cher.

Je n'ai jamais dis que je défendais cette pratique, mais les entreprises s'adapte simplement à la réalité des formations actuelles.

Envoyé par souviron34

Tu ne vois pas comme une contradiction, là ??

Non.
Exemple bidon :
Coût de maintenance d'une vieille appli : 50 € par an
Refonte de l'appli : 200 €
Coût de maintence de la nouvelle appli : 5 € par an

Au bout de quelque temps on fini par moins dépenser que ce que l'on dépensait avant.

Envoyé par souviron34

(et je suis très dubitatif sur ce point, en particulier à cause justement du turnover des technos)

On peut l'être effectivement. Mais quand tu vois l'ancienneté des vieux systèmes, on peut penser que les nouveaux qui les remplaceront dureront également longtemps. Donc le turnover n'est peut être pas si impactant.

Envoyé par souviron34

à comparer à "former les jeunes générations à garder les compatibilités avec l'ancien"

Possible...Mais de nos jours, trouver des "jeunes" pour travailler sur ces vieux systèmes ne cours pas les rues. Les nouveaux talents sont attirés par ce qui est neuf, ce qui brille, alors ça ne doit pas être évident d'en trouver des bons à former.

Enfin pour résumer, comme tu le dis, tout à avoir avec l'argent. Quand on fait un choix on fait celui qui semble être le plus viable économiquement. Après si les DSI se sont planté, et que former des gens sur les vieux systèmes auraient été moins cher, moi je m'en fiche, je suis sur les nouvelles technos et ça me fait du travail

[lepinekong]

Envoyé par B.AF

...

Et avec tout ça, il a encore le droit à une vie le chef de projet ?

Chacun son truc, mais moi devenir un amas de tâche de couleur parce que des "wise men" l'ont décidé, très peu pour moi.


Ca suffit un peu ce genre de classification de l'humain idéal, on a l'impression de voir une sélection de barbaque dans des caissettes de supermarché.

Je suis d'accord

Chef de projet c'est des fois enviables et des fois non enviables. De plus en plus il y a beaucoup de tâches administratives (reporting ils appellent ça) où des fois tu te demandes si t'as pas fait bac + 5 pour faire du boulot de niveau de secrétariat, donc si tu aimes trop le technique ça va te gonfler. Moi ça va parce que comme à l'origine je suis ingénieur généraliste je m'adapte assez bien à tout que ce soit pour faire des cocottes en papier (des fois tu te demandes vraiment pourquoi ils avaient besoin d'un chef de projet sauf pour le prestige ou pour porter le chapeau au cas où ça tournerait mal) soit pour travailler à un rythme de fou (enfin des fois t'as des envies de meurtre).

En général, sauf pour les chanceux et planqués, c'est assez stressant parce que le client en veut toujours plus surtout quand c'est du forfait alors que c'est pas facile de motiver des développeurs quand de manière générale il y a eu dévalorisation du métier, donc il faut compter sur leur passion, heureusement il y en a encore.

[B.AF]

Envoyé par javamine

Non.
Exemple bidon :
Coût de maintenance d'une vieille appli : 50 € par an
Refonte de l'appli : 200 €
Coût de maintence de la nouvelle appli : 5 € par an

Au bout de quelque temps on fini par moins dépenser que ce que l'on dépensait avant.

Le coût de la maintenance applicative est plus sensible à la qualité de conception et d'utilisation qu'à la technologie de l'application.

Il veut mieux une équipe de star qui fait une appli en brainfuck qu'une bande de singe qui fait du J2E.

[lepinekong]

Envoyé par B.AF Voir le message
Les gens extraordinaires créent
Les gens ordinaires maintiennent.

C'est plus facile de créer que de maintenir le code de zigotos qui ont parfois disparu dans la nature: donc je préfère créer c'est pour ça que je fais des nouveaux projets et jamais des projets de maintenance tout au plus sur des applications existantes je peux être 1/10 du temps Responsable d'Application, car comme tout le monde sait Responsable seulement veut dire Non-Coupable

[souviron34]

Je me permet de constater qu'il semble bien il y avoir une différence de point de vue entre "vieux routards" et "jeunes lascars"

[fcharton]

Envoyé par javamine

Exemple bidon :
Coût de maintenance d'une vieille appli : 50 € par an
Refonte de l'appli : 200 €
Coût de maintence de la nouvelle appli : 5 € par an

Au bout de quelque temps on fini par moins dépenser que ce que l'on dépensait avant.

Ca c'est le discours avant la refonte, celui que tient le jeunot qui n'a pas envie de se cogner du CDA (code des autres, 90% du travail en informatique), et qui croit qu'il saura bâtir en 6 mois ce qu'on n'a pas réussi à refondre en 10 ans...

Si cette estimation était correcte, et que la refonte dure 1 an, note qu'il faudrait quand même près de 5 ans pour l'amortir au travers des économies de maintenance réalisées. Je connais pas mal de décisionnaires qui hésiteraient: ce n'est pas un bon retour sur investissement. (5 ans, c'est souvent plus que la durée de vie du DSI qui prend la décision...)

Mais le vrai problème, c'est que les 50€ par an, ils sont connus, certains, sans risque. Les 200€, ils ont tendance à devenir 500, et puis, ils mettent 2 ou 3 fois plus de temps que prévu à arriver (donc on continue à payer les 50 pendant ce temps). Et même si on arrive à quelque chose qui marche aussi bien que l'appli d'origine (je connais pas mal de contre exemples), on découvre à ce moment que la maintenance coutera plus de 5€, parce que dans les 50, il y avait toute une maintenance évolutive qu'on n'avait pas compté dans les 5... En fin de course, on va payer 500, et réaliser une économie de 25 (vs les 200 et 45 prévus) et là, le système s'amortit sur 20 ans... La refonte n'est plus rentable !

Et ca, bien sur, c'est quand tout va bien... Parfois, le nouveau projet n'aboutit pas, et on reste avec le vieux système, après que le jeune chef de projet qui a vendu la refonte ait décidé de larguer le projet en route, ou que la super techno de la mort sur laquelle on comptait n'a pas tenu ses promesses... Et là, il y a toujours quelqu'un pour dire que moyennant 200 euros de refonte, on pourrait...

Sérieusement, la plupart des décideurs (DSI et financiers) connaissent ce discours, et ont une mauvaise opinion de la capacité des informaticiens à évaluer les couts et les charges de travail (et ils ont raison). La force des vieilles technologies, c'est non seulement qu'elles sont éprouvées, mais surtout que leurs couts (directs et indirects) sont connus et maîtrisés.

Quant au fait de "créer" vs "maintenir", bien souvent, en informatique "créer" c'est assembler pêle mêle des bouts de librairies, et laisser à d'autres le soin de les maintenir et de les faire évoluer. La difficulté, ce n'est pas d'assembler les 500 (ou les 5000) premières lignes de code, c'est de les transformer en un produit utilisable, et de les faire évoluer sans avoir besoin de tout refondre tous les 3 ans...

Je ne crois pas que les gens ordinaires maintiennent (ou plutôt, je ne crois pas qu'ils maintiennent bien)...

Francois

[B.AF]

Envoyé par lepinekong

C'est plus facile de créer que de maintenir le code de zigotos qui ont parfois disparu dans la nature: donc je préfère créer c'est pour ça que je fais des nouveaux projets et jamais des projets de maintenance tout au plus sur des applications existantes je peux être 1/10 du temps Responsable d'Application, car comme tout le monde sait Responsable seulement veut dire Non-Coupable

Facile à dire sur le papier, créer une application pro, c'est pas une histoire de technique, c'est une histoire d'expérience. Tout le monde peut assembler des technos et des processus, tout le monde ne peut pas concevoir une application avec tout ce que cela implique. Et souvent, ce sont les moins créatifs qui critiquent le plus l'existant. Pour créer du neuf, il faut aimer déplaire, se faire des ennemis, entendre des reproches.
Je vois qu'à priori concepteur est un métier contraignant que tu ne connais absolument pas. Je ne supporte pas de me dire qu'un de mes "bébés" dysfonctionne et j'y ferai toujours ce qu'il faut. Ceux qui ont voulu les migrer dans des big bangs fabuleux ce sont toujours cassés les dents, sans que je les pousse d'ailleurs.
Ce n'est pas drôle non plus de voir passer les patchs de maintenance d'un développeur qui n'a rien compris au sujet et qui a créé une dérivation dangereuse.

L'intelligence de faire de la modélisation objets, ce n'est pas de le faire dans eclipse avec un plugin UML; c'est d'avoir un esprit suffisamment clair pour le faire de la façon la plus optimale possible.

[souviron34]

d'ailleurs, à l'inverse, maintenir une application superbement conçue est un plaisir aussi bien intellectuel que pratique...


(ce qui justement était le cas de l'application dont je parlais plus haut, que certains ont poussé (et réussi malheureusement) pour une décision de refonte...)

[javamine]

Envoyé par fcharton

Ca c'est le discours avant la refonte, celui que tient le jeunot qui n'a pas envie de se cogner du CDA (code des autres, 90% du travail en informatique), et qui croit qu'il saura bâtir en 6 mois ce qu'on n'a pas réussi à refondre en 10 ans...

Desfois ça marche !

Envoyé par fcharton

Si cette estimation était correcte, et que la refonte dure 1 an, note qu'il faudrait quand même près de 5 ans pour l'amortir au travers des économies de maintenance réalisées. Je connais pas mal de décisionnaires qui hésiteraient: ce n'est pas un bon retour sur investissement. (5 ans, c'est souvent plus que la durée de vie du DSI qui prend la décision...)

C'est vrai que l'amortissement sur 5 ans de mon exemple est peut être mal choisi.

Envoyé par fcharton

Mais le vrai problème, c'est que les 50€ par an, ils sont connus, certains, sans risque. Les 200€, ils ont tendance à devenir 500, et puis, ils mettent 2 ou 3 fois plus de temps que prévu à arriver (donc on continue à payer les 50 pendant ce temps). Et même si on arrive à quelque chose qui marche aussi bien que l'appli d'origine (je connais pas mal de contre exemples), on découvre à ce moment que la maintenance coutera plus de 5€, parce que dans les 50, il y avait toute une maintenance évolutive qu'on n'avait pas compté dans les 5... En fin de course, on va payer 500, et réaliser une économie de 25 (vs les 200 et 45 prévus) et là, le système s'amortit sur 20 ans... La refonte n'est plus rentable !

Et ca, bien sur, c'est quand tout va bien... Parfois, le nouveau projet n'aboutit pas, et on reste avec le vieux système, après que le jeune chef de projet qui a vendu la refonte ait décidé de larguer le projet en route, ou que la super techno de la mort sur laquelle on comptait n'a pas tenu ses promesses... Et là, il y a toujours quelqu'un pour dire que moyennant 200 euros de refonte, on pourrait...

Discours relativement pessimiste. Je le pense malheureusement réaliste, mais de mon expérience de chef de projets, je n'ai pour l'instant que des contre exemple à ce discours. Je garde espoir!

Envoyé par fcharton

Sérieusement, la plupart des décideurs (DSI et financiers) connaissent ce discours, et ont une mauvaise opinion de la capacité des informaticiens à évaluer les couts et les charges de travail (et ils ont raison).

C'est de toute façon leur travail de s'assurer de tout ça.

Envoyé par souviron34

Je me permet de constater qu'il semble bien il y avoir une différence de point de vue entre "vieux routards" et "jeunes lascars"

Entre les jeunes fougueux qui veulent tout rénover et les vieux routards qui refusent de prendre le moindre risque, on arrive généralement à de bon compromis

[el_slapper]

Moi je vois que vous vous concentrez sur une seule source de couts : le développement. Mais il y en a d'autres. Les machines, bien sur, mais aussi et surtout les bugs. Une banque qui envoie un courrier faux, voire ridicule, à 500 gros clients, ça lui coute extrêmement cher en termes d'image. Et dans ce cas, on regarde de plus près les méthodes. Et si on s'aperçoit que le système est tellement mal foutu(ce qui ne dépend pas forcément de son âge) que la moindre maintenance est un risque majeur de bugs, alors le prix de refonte, voire de maintenance de l'appli refondue, on s'en fout, ça sera toujours inférieur au cout du bug.

C'est dans ce cadre(enfin, presque, en assurances) qu'on m'a demandé de refondre une appli qui tournait comme du papier à musique depuis plus de 35 ans, mais à laquelle personne ne comprenait rien : le risque d'erreur était devenu trop grand en cas de maintenance. Je pense que les couts de maintenance ont été réduits, mais ça n'est pas là le principal intérêt de la manœuvre. L'intérêt, c'est que l'ensemble des mécanismes fonctionnels ont été découpés et isolés, et sont ainsi facile à corriger en cas de bug.

[lepinekong]

Envoyé par B.AF

Facile à dire sur le papier, créer une application pro, c'est pas une histoire de technique, c'est une histoire d'expérience.
Tout le monde peut assembler des technos et des processus, tout le monde ne peut pas concevoir une application avec tout ce que cela implique. Et souvent, ce sont les moins créatifs qui critiquent le plus l'existant. Pour créer du neuf, il faut aimer déplaire, se faire des ennemis, entendre des reproches.
Je vois qu'à priori concepteur est un métier contraignant que tu ne connais absolument pas.

Je ne sais pas danq quel environnement tu travailles mais moi ça fait 20 ans que je travaille dans des multinationales et vois-tu quand je conduis un projet c'est pas pour quelqu'un fasse mumuse sur des technos pas mûrs. Effectivement ce n'est pas sûr qu'on s'entende

Envoyé par B.AF

Je ne supporte pas de me dire qu'un de mes "bébés" dysfonctionne et j'y ferai toujours ce qu'il faut. Ceux qui ont voulu les migrer dans des big bangs fabuleux ce sont toujours cassés les dents, sans que je les pousse d'ailleurs.
Ce n'est pas drôle non plus de voir passer les patchs de maintenance d'un développeur qui n'a rien compris au sujet et qui a créé une dérivation dangereuse.

L'intelligence de faire de la modélisation objets, ce n'est pas de le faire dans eclipse avec un plugin UML; c'est d'avoir un esprit suffisamment clair pour le faire de la façon la plus optimale possible.

Quel lyrisme, si le développeur a pas compris c'est peut-être qu'il fallait le former

[B.AF]

Envoyé par lepinekong

Je ne sais pas danq quel environnement tu travailles mais moi ça fait 20 ans que je travaille dans des multinationales et vois-tu quand je conduis un projet c'est pas pour quelqu'un fasse mumuse sur des technos pas mûrs. Effectivement ce n'est pas sûr qu'on s'entende


Quel lyrisme, si le développeur a pas compris c'est peut-être qu'il fallait le former

C'est peut être surtout qu'on rencontre au quotidien beaucoup de gens qui réagissent comme toi : plutôt que d'essayer de comprendre, tu ironises et te moques.

Donc, j'arrête. Je comprends bien que tu es un planificateur et pas un créateur, et que par définition, je suis ce que tu déteste le plus.

Le dernier comme toi à m'avoir répondu cela en vrai m'a dit que je ne savais pas planifier, c'est probablement vrai, mais comme je lui ai dit, lui ne sait pas avoir d'idées.

Moi mon job, c'est d'avoir des idées pour que ma boite vende. Rien de plus.
Pouir cela au quotidien, je prends des risques d'archi, de techno, de spécifications. Et j'assume. Le risque zéro en informatique n'existe pas.
Et ce n'est certainement pas la planification qui donne l'intelligence d'une solution. Pas plus que les visions surrannées ou les technos hypes.

Un bon chef de projet, il code, il pige, il fédére et il vend. Pour le reste, c'est du contrôle de gestion et de la communication d'entreprise. Bref, des anxyolitiques pour gens ordinaires qui cherchent un CDI dans une multinationale pour y rester au chaud.

[souviron34]

hum.....

Calmez-vous un peu, tous les 2

En ce début d'année, soyez zen

[B.AF]

Envoyé par souviron34

hum.....

Calmez-vous un peu, tous les 2

En ce début d'année, soyez zen

Face à l'irrespect, je ne garde jamais mon calme, ça n'en vaut pas la peine.

[fcharton]

Envoyé par el_slapper

Moi je vois que vous vous concentrez sur une seule source de couts : le développement. Mais il y en a d'autres. Les machines, bien sur, mais aussi et surtout les bugs. Une banque qui envoie un courrier faux, voire ridicule, à 500 gros clients, ça lui coute extrêmement cher en termes d'image. Et dans ce cas, on regarde de plus près les méthodes. Et si on s'aperçoit que le système est tellement mal foutu(ce qui ne dépend pas forcément de son âge) que la moindre maintenance est un risque majeur de bugs, alors le prix de refonte, voire de maintenance de l'appli refondue, on s'en fout, ça sera toujours inférieur au cout du bug.

C'est effectivement une bien meilleure raison que l'économie sur la maintenance. Maintenant, l'analyse est assez compliquée. D'abord, parce que le cout des bugs n'est pas simple à évaluer, et ensuite parce que si l'application actuelle souffre de régressions quand on la maintient, il y a gros à parier que la future arrive avec son lot de nouveaux bugs, qu'il faudra corriger, et qui entraineront (peut être) de nouvelles régressions.

Bref, on échange des régressions connues et actuelles contre des bugs futurs et inconnus. Au global, on y gagne souvent, parce qu'il y a un effet d'apprentissage, mais la bonne question (du point de vue du donneur d'ordre, toujours un financier) c'est "est ce que ca en vaut la peine?".

Mon impression c'est que les entreprises oscillent sans cesse entre deux postures extrèmes :
- la résignation vis à vis du système informatique, et de ses bugs: depuis des années, on nous dit que c'est comme ca, alors, on s'habitue, à la longue. C'est la position normale.
- l'exaspération vis à vis du système actuel, une sorte de panique vis à vis des "vieilles technologies" et la certitude que les nouvelles vont magiquement régler tous les problèmes. C'est la situation exceptionnelle, qui déclenche la refonte.

En fait, la décision de refondre est presque toujours irrationnelle...

Francois

[Franck SORIANO]

Envoyé par B.AF

Facile à dire sur le papier, créer une application pro, c'est pas une histoire de technique, c'est une histoire d'expérience. Tout le monde peut assembler des technos et des processus, tout le monde ne peut pas concevoir une application avec tout ce que cela implique. Et souvent, ce sont les moins créatifs qui critiquent le plus l'existant. Pour créer du neuf, il faut aimer déplaire, se faire des ennemis, entendre des reproches.
Je vois qu'à priori concepteur est un métier contraignant que tu ne connais absolument pas.

Je trouve ta réaction exagérée et disproportionnée. Tu décris le travail et les compétences de l'architecte. lepinekong ne s'en prenait pas à l'architecte, mais faisait le constat de ce que tu récupères au final en maintenance.

Une fois que l'architecte a pondu son oeuvre d'art, cette dernière va être réalisée par une armée de petits développeurs débutants (voir des prestataires payés pour faire acte de présence (dont certains seront peut-être en réalité des stagiaires)) qui vont tout massacrer, avec un CP qui ne se souciera que de la date de livraison.

Au début, tout le monde dira oh oui c'est beau, on fait mumuse avec les dernières technos, on utilise pleins de design-pattern et autre. On va faire les choses bien...
et puis la deadline va arriver. Très vite, l'ambience va devenir : on est à la bourre, il faut livrer.... le CP dira : "l'architecte (ou le responsable technique, ou le responsable qualité) je l'emmerde, c'est pas lui qui doit respecter la date de livraison, peu importe comment c'est fait, l'important c'est que ça marche"... la doc sera sacrifiée pour rattraper le retard. Puis les tests seront baclés car plus le temps de tester...

Au final, le CP parviendra a livrer un truc qui marchote dans les délais. On le bricolera à coups de rustines pour passer la recette...
Et son projet sera considéré comme une réussite parce qu'il aura passer la recette dans les temps.

Par contre, lorsque derrière tu récupères le projet en maintenance, tu subis les contraintes d'un existant que tu n'as pas choisi. Tu dois maintenir en fonctionnement un truc branlant qui défie toute logique, dont la doc est inexistante, voir pire obsolète et contraire à ce que fait réellement le système.
Tu dois faire évoluer le tout, garantir l'absence de regressions, mais tu ne sais déjà pas toi-même comment le système est censé fonctionner.
On t'impose une obligation de résultat face à des problèmes dont tu n'as parfois aucune compréhension, voir sur lesquels tu n'as parfois aucune emprise.

Bref, dans un cas tu fais une oeuvre d'art mais de toute façon on ne te jugera pour ainsi dire que sur ta capacité à livrer dans les délais.
Dans l'autre, on te demande de faire des miracles, tu seras toujours considéré comme responsable de tous les maux de l'offre, tu auras envi de faire une oeuvre d'art pour remplacer le tas de bouses mais on ne te donnera jamais les moyens de la refonte (qui il est vrai serait probablement réalisée selon le même processus que le développement initial ).

Je trouve aussi qu'en termes de responsabilités, il est beaucoup plus facile d'assumer un nouveau projet que de maintenir un produit existant.

Envoyé par B.AF

Face à l'irrespect, je ne garde jamais mon calme, ça n'en vaut pas la peine.

Je ne trouve pas l'attitude de lepinekong irrespectueuse, mais plutôt réaliste par rapport à ce qu'on rencontre généralement en entreprise.
Tu te sens aggressé parce que dans ton cas de figure tu arrives à maîtriser la réalisation pour qu'elle colle parfaitement à ton idée initiale (ou tes projets sont suffisamment petits pour que tu puisses tout coder toi-même), mais dans les grandes boîtes, ça se passe rarement comme ça.
(sans oublier que des architectes qui pondent des usines à gaz pour résoudre un problème trivial, ça existe aussi)

Et pourtant, je suis l'architecte dont le travail se fait massacrer par des CP qui sont prêts à tous les sacrifices sur la qualité pour livrer la liste de livraison la plus longue possible au moment de la mise en prod !

[souviron34]

Envoyé par fcharton

Bref, on échange des régressions connues et actuelles contre des bugs futurs et inconnus.

Et c'est bien tout le problème...

Et la croyance dans "on a une méthode sûre qui fait qu'il y aura pas de bugs" est aussi stupide que de dire que l'existence de Dieu est prouvable (ou improuvable)...

Envoyé par fcharton

Au global, on y gagne souvent, parce qu'il y a un effet d'apprentissage

Eh malheureusement non !!

Ceci supposerait que l'équipe est stable...

Or justement quand il y a refonte le plus souvent on change d'équipe, soit parce qu'on l'estime "incapable", soit parce qu'elle est partie (trop vieille, à la retraite, "dépassée"..) soit parce que la boîte a été rachetée, et qu'on change l'équipe... ou bien parce qu'il y a un nouveau Directeur Technique, qui croit tout savoir (ou qui se résigne parce que tous les jeunes qu'il embauche sont incapables de faire autre chose que du .Net ou du C# et sont dépassés dès qu"on n'utilise pas UML ou qu'on leur donne pas à la becquée tous les mots technocratiques qu'on leur a foutu dans le crâne à l'école, ou si on leur parle de "fonctions enregistrées"))

En très gros, et ce que tu dis plus bas le confirme :

Envoyé par fcharton

une sorte de panique vis à vis des "vieilles technologies" et la certitude que les nouvelles vont magiquement régler tous les problèmes. C'est la situation exceptionnelle, qui déclenche la refonte.

En fait, la décision de refondre est presque toujours irrationnelle...

Ce qui, compte-tenu de l'extrême rareté de la situation que tu envisageais ci-dessus (l'équipe est la même, donc il y a apprentissage), amène dans la quasi-totalité des cas à un coût (très) largement supérieur à moyen terme (3 à 5 ans).

Et surtout qu'on re-crée des bugs, qui avaient déjà été corrigés dans les versions précédentes, provoquant un ras-le-bol, puis un fatalisme, des utilisateurs..

Et des développeurs, quand ils voient eux-aussi que le bug avait déjà été corrigé 6 ans avant...

Ce qui fait que tout le monde y perd :

• l'entreprise, qui dépense des sous et du temps qu'elle aurait pu passer à améliorer le produit.
  
  
• Les utilisateurs, qui se foutent pas mal de savoir quelle techno on utilise, du moment que ça fait le boulot, et qu'on ne revient pas en arrière.. Mais qui auraient préféré avoir très nettement plus de fonctionalités que une re-mouture de l'ancien..
  
  
• Les développeurs "anciens", qui ont vu leur bébé se faire démanteler, et qui éventuellement se sont fait virer (ou mis de côté)
  
  
• Les développeurs nouveaux, qui, après s'être bien éclatés, s'aperçoivent qu'il faut reprendre un à un tous les bugs depuis 10 ans.... et qui perdent donc tout intérêt , car c'est un travail fastidieux.. et qui pour eux est .. humiliant : ils pensaient avoir tout fait bon !!! Et que le temps qu'ils fassent ça, ils sont à leur tour "dépassés" par une nouvelle techno à la mode...

et on répond donc à el_slapper par la même occasion : ton bug de ta banque aurait été très vraisemblablement plus facilement corrigé (et à moindres frais), et SANS regénérer de nouveaux bugs (ni mobiliser toute une équipe pendant 3 ou 5 ans, et donc des ressources considérables) si on avait pris la décision de le corriger plutôt que de tout refaire... Et ton 'impact" sur les utilisateurs sera pire si il faut leur ré-expliquer que ça, qu'ils voient sur leur relevé, ah ben "c'est une erreur de l'info.. Oui, c'est vrai, il y avait déjà eu ce problème il y a 3 ans, mais vous en faites pas, ça va être corrigé le mois prochain"

Envoyé par Franck SORIANO

Une fois que l'architecte a pondu son oeuvre d'art, cette dernière va être réalisée par une armée de petits développeurs débutants (voir des prestataires payés pour faire acte de présence (dont certains seront peut-être en réalité des stagiaires)) qui vont tout massacrer, avec un CP qui ne se souciera que de la date de livraison.
..
Et pourtant, je suis l'architecte dont le travail se fait massacrer par des CP qui sont prêts à tous les sacrifices sur la qualité pour livrer la liste de livraison la plus longue possible au moment de la mise en prod !

Sauf quand le CP est un vieux de la vieille, qui prend son boulot à coeur et sait ce qu'il fait...


Mais il y en a comme des bons patrons.. Rarement...