Discussion :

[deadalnix]

« Note that the first 4 reasons above imply that the Project Manager is not properly managing and controlling his resources. »

Ça donne envie dis donc

[el_slapper]

Goldplating, celà concerne à mon sens des éléments fonctionnels non-exigés rajoutés. Jamais fait.

Quand je fais un truc "en plus", c'est toujours un truc technique qui facilité la maintenance ou améliore la fiabilité. Du genre une log complète et précise à chaque programme du batch, une gestion des erreurs plus affinée, un système robuste qui ne se contente pas de planter bêtement à chaque virgule de travers.....

Evidemment, le fait que je suis généralement celui qui maintient le code que je créée en projet modifie la perspective. Le fait que ça soit du batch aussi : difficille de rajouter une fonctionnalité non spécifiée dans un batch. Par contre, "contrôler que le code agence en entrée est valide", ça, ça peut se traduire par "planter comme un gros porc si il est invalide" ou par "si il est invalide, rejeter le fichier, envoyer un mail d'alerte, et continuer à traiter les autres fichiers".

Je ne vois pas ça comme du gold-plating.

[Caro999]

@el_slapper

Est-ce que le client est au courant que tu le fais? Si oui, la prochaine fois que le chef de projet va négocier un budget, le fait que les ingé font des trucs gratos va forcément s'inviter dans la discussion. A ce moment là, le client va peut-être augmenter ses attentes en terme de finition du produit sans donner le budget qui va avec ou alors te sortir l'argument comme quoi les budgets ont été surévalués puisque les ingés ont le temps de glisser des trucs dans le produit que personne n'a demandés.

Bref, ça met l'embrouille dans des discussions de négo. Et c'est encore pire quand le client est au courant d'un truc que toi en tant que chef de projet, tu ne sais pas en rentrant en réunion de négociation.

Moi celui qui me fait du gratuit dans le dos, c'est lui qui vient s'expliquer avec le client.

C'est pour le bien de l'équipe que je le fais, pas parce que j'aime embêter mon monde. Moi, je peux dire oui au client pour qu'il m'ait à la bonne et cravacher les ingés; mais c'est pas ma vision du travail en équipe. Je protège les gens qui bossent bien et mets moi-même les mains dans le cambouis mais en retour, on bosse ensemble pas chacun en franc-tireur.

[deadalnix]

@Caro_999

Ce dont te parle el_slapper, c'est une source d'économie, pas de coût. Le jour ou les entreprise comprendront ça, ça va être l'illumination sur terre.

[Caro999]

Evidemment, le fait que je suis généralement celui qui maintient le code que je créée en projet modifie la perspective. Le fait que ça soit du batch aussi : difficille de rajouter une fonctionnalité non spécifiée dans un batch. Par contre, "contrôler que le code agence en entrée est valide", ça, ça peut se traduire par "planter comme un gros porc si il est invalide" ou par "si il est invalide, rejeter le fichier, envoyer un mail d'alerte, et continuer à traiter les autres fichiers".

Je ne vois pas ça comme du gold-plating.

Ca dépend. Si dans un premier temps, on a volontairement bâclé l'error handling d'un batch pour (par exemple) que ça coûte moins cher au client (à sa demande) et que plus tard, l'error handling est rajouté sans demande expresse du client, alors c'est du gold plating.

[Caro999]

@Caro_999

Ce dont te parle el_slapper, c'est une source d'économie, pas de coût. Le jour ou les entreprise comprendront ça, ça va être l'illumination sur terre.

Pour qui l'économie? Qui tourne les batchs?

[nfluch]

Pour qui l'économie? Qui tourne les batchs?

el_slapper l'expliquait il y a quelques post
l'économie des deux côtés -> les chaînes et process métiers tournent mieux
j'ai déjà vécu ça pour un fabricant de plaque de verre mais sans être sur site (il y avait plusieurs usines)
au début quand les gens appelaient je les sentais vraiment stressé et à bout par les bugs à répétition ce qui implique évidemment moins de production
et pour ma part, ça m'empêchait de livrer mes évolutions à temps et surtout j'étais de temps en temps obligé de bosser jusqu'à 21h à cause d'un bug (3/8 oblige) pour corriger à la mano des bases access pourries avec une connexion pcanywhere pourrie où on pouvait attendre souvent plus d'une 1sec avant que le click arrive là bas

donc à un moment donné, j'ai fais le nécessaire et là ça été l'apothéose, plus que 2-3 coup de fils reçus par jour, de moins en moins de bug, des horaires nettement plus cool et mes évol en temps et en heure et même souvent à l'avance
et pour eux, gain de productivité, donc tout les deux gagnants

[phili_b]

C'est assez classique en informatique que des membres de l'équipe fassent du gratuit en sous main dans le dos des chefs de projets. C'est fait généralement avec plein de bonnes intentions à la clef mais développer gratuitement un truc que le client n'a pas demandé a bien souvent des impacts profonds dans la relation client fournisseur, bien souvent supérieurs au bénéfice de l'amélioration délivrée.

A telle enseigne, que les théories en management de projet recommandent de NE JAMAIS FAIRE du gratuit.

D'accord mais tout n'est pas aussi simple. A un moment je devais faire une mission de ssii d'un mois pour faire de l'excel ou des rapports basiques BO, mais ça m'emmerdait. Résultat je leur ai dit laissez moi faire je vous faire quelque de mieux, filez moi power amc et je m'en occupe. Résultat je leur ai pondu à partir de leur expression de besoin très peu de rapports mais un datawarehouse qui permettait de faire leur rapport mais aussi bien plus.

Donc j'ai fait finalement un DWH dont le TJM aurait du être bien plus élevé, mais est-ce que je serai resté ces quelques mois, au lieu de ces quelques semaines. Certes ils auraient du payer le vrai prix. Mais d'un autre côté c'est plus un problème commercial. J'ai fait une réalisation conforme à leur expression de besoin, ça m'a permit de ne pas être en intercontrat, et j'ai fait quelque chose de bien plus intéressant que la mission basique de chez basique prévue à l'origine.

Après si j'avais été indépendant, j'aurai peut-être vu les choses différemment...mais pas forcément d'un point de vue opposé. J'aurai peut-être négocié ou fait payer par jalon, mais pas non plus des sommes faramineuses pour être concurrentiel avec les ssii.

[ulspider]

D'accord mais tout n'est pas aussi simple. A un moment je devais faire une mission de ssii d'un mois pour faire de l'excel ou des rapports basiques BO, mais ça m'emmerdait. Résultat je leur ai dit laissez moi faire je vous faire quelque de mieux, filez moi power amc et je m'en occupe. Résultat je leur ai pondu à partir de leur expression de besoin très peu de rapports mais un datawarehouse qui permettait de faire leur rapport mais aussi bien plus.

Donc j'ai fait finalement un DWH dont le TJM aurait du être bien plus élevé, mais est-ce que je serai resté ces quelques mois, au lieu de ces quelques semaines. Certes ils auraient du payer le vrai prix. Mais d'un autre côté c'est plus un problème commercial. J'ai fait une réalisation conforme à leur expression de besoin, ça m'a permit de ne pas être en intercontrat, et j'ai fait quelque chose de bien plus intéressant que la mission basique de chez basique prévue à l'origine.

Après si j'avais été indépendant, j'aurai peut-être vu les choses différemment...mais pas forcément d'un point de vue opposé. J'aurai peut-être négocié ou fait payer par jalon, mais pas non plus des sommes faramineuses pour être concurrentiel avec les ssii.

Eh bien pour moi tu as eu tord de faire cela. Tu n'as pas à changer le besoin du client !

Mise en place d'un datawarehouse, mais dans quel but ? Le client en avait-il besoin ? Quid de la maintenabilité maintenant que tu n'es plus là ? L'application est-elle toujours utilisée ?

Les applications faites sur un coin de table par des personnes qui s'en vont du jour au lendemain, pour moi ce n'est pas un modèle à suivre.

Chez le client où je travaille, il y a eu une prestataire qui était vraiment très très forte en Excel / VBA. Elle a pondu des rapports avec des calculs financiers extrêmement complexes et techniques et aujourd'hui personne ne sait faire évoluer ou valider les chiffres que l'application sort, ce qui fout le client dans une merde pas possible.

Ton raisonnement c'est un peu :
Explique moi ton besoin, je t'expliquerai comment t'en passer ou faire autrement...

[rawsrc]

Chez le client où je travaille, il y a eu une prestataire qui était vraiment très très forte en Excel / VBA. Elle a pondu des rapports avec des calculs financiers extrêmement complexes et techniques et aujourd'hui personne ne sait faire évoluer ou valider les chiffres que l'application sort, ce qui fout le client dans une merde pas possible.

Je suis sûr qu'au moment où cet outil a été pondu, il répondait à un besoin et devait satisfaire le client.

Après c'est un autre problème : le départ d'un salarié/prestataire ne se gère pas la veille pour le lendemain...
Chez ton client, ils ont 2 problèmes :
- manque de compétences sur Excel / VBA
- manque de compétence professionnelle sur le métier : équations trop complexes, méthode de résolution tellement optimisée qu'elle en devient incompréhensible

Tu ne peux pas jeter la pierre sur la personne qui a répondu à un besoin ou résolu un problème. Elle a fait son boulot.
Il arrive que tu tombes sur quelqu'un de très pointu qui va te proposer une soluce en utilisant pleinement l'outil fourni (Excel) et pas juste "y clique y clique". C'est au client de suivre ça en amont surtout si ça touche son coeur de métier et est appelé à être amélioré ou réutilisé.
N'oublie pas que généralement le prestataire répond au problème du mieux qu'il peut (c'est ce qui lui est demandé aussi).
Après soit le client encadre son prestataire, soit il exige une doc technique sur la méthode de résolution du problème soit ils conviennent d'un support.

Bref, y a toujours moyen de s'arranger pour que personne ne soit pénalisé mais le client se doit de bien connaitre le niveau de ses équipes et ne pas avoir une vision toujours à court terme.

[gangsoleil]

Ton raisonnement c'est un peu :
Explique moi ton besoin, je t'expliquerai comment t'en passer ou faire autrement...

Attention, il faut aussi comprendre que dans beaucoup de cas, le client ne sait pas ce dont il a besoin, mais grace a l'internet il a trouve 3 mots-cles qu'il a msi bout-a-bout pour faire une base de spec..

Bref, on en revient toujours au meme dessin, dont il existe plusieurs variantes, du genre :

[phili_b]

Eh bien pour moi tu as eu tord de faire cela. Tu n'as pas à changer le besoin du client !

Je n'ai pas changé les besoins: il a eu ses rapports.

Mise en place d'un datawarehouse, mais dans quel but ? Le client en avait-il besoin ?

Oui il en avait besoin. J'ai calculé que compte tenu de mes connaissances je serais finalement plus efficace avec un petit DWH que des rapports à refaire de A à Z. En effet des rapports sur DWH sont beaucoup plus rapides et optimisés à réaliser et aussi à exécuter.

Les applications faites sur un coin de table par des personnes qui s'en vont du jour au lendemain, pour moi ce n'est pas un modèle à suivre.

Ma solution est clairement mieux réalisée que l'objectif initial de la mission qui était de la bidouille.

Quid de la maintenabilité maintenant que tu n'es plus là ?

Pour la même raison qu'expliquée plus haut: beaucoup plus maintenable.

Il faut aussi voir que mon CV a été garni d'une expérience de 6 mois d'un nouveau DWH que je peux mettre en avant, et non de rapports que j'aurais pu faire des années plus tôt en tant que débutant, et que je n'ai pas été en intercontrat. En plus mon client a eu une solution plus robuste: c'est peut-être effectivement la valeur ajoutée "gratuite", pour reprendre l'expression de Caro999, pas prévue au départ et c'est pour cela que je voulais en parler pour montrer un exemple pas aussi simple à classer que cela dans la "gratuité" si c'est conforme au besoin.

[npuzin]

C'est une analyse à deux balles cet article du Figaro.

Si il y a moins de gens qui postulent dans l'informatique, c'est peut être qu'il y a moins de chômage dans ce secteur.

[el_slapper]

@el_slapper

Est-ce que le client est au courant que tu le fais? Si oui, la prochaine fois que le chef de projet va négocier un budget, le fait que les ingé font des trucs gratos va forcément s'inviter dans la discussion. A ce moment là, le client va peut-être augmenter ses attentes en terme de finition du produit sans donner le budget qui va avec ou alors te sortir l'argument comme quoi les budgets ont été surévalués puisque les ingés ont le temps de glisser des trucs dans le produit que personne n'a demandés.

Je suis en régie alors ça change un petit peu : ça n'est pas ma boite, mais mon contact client(dans les faits ma chef, mais si je le dit, alors je suis dans l'illégalité) qui négocie avec la MOA. Celà dit, le problème est quand même similaire : chaque "camp" se bat pour des budgets, et si effectivement j'ai 120 jours pour faire mon projet, j'ai interêt à ce que mes éléments "supplémentaires" rentrent dans les 120 jours(ou 15, ou 2, ou 4000, suivant la taille du projet).

Bref, ça met l'embrouille dans des discussions de négo. Et c'est encore pire quand le client est au courant d'un truc que toi en tant que chef de projet, tu ne sais pas en rentrant en réunion de négociation.

Généralement, en ce qui me concerne, le budget temps est verrouillé avant même que la spec(incomplète) ne le soit. Et la mémoire des MOA étant cele d'un poisson rouge, que j'ai fait plus ou moins que prévu n'est pas un critère

Moi celui qui me fait du gratuit dans le dos, c'est lui qui vient s'expliquer avec le client.

Pas de souci. La MOA m'a flambé parfois, mais a aussi demandé, très souvent, des fonctionnalités supplémentaires sur son compte-rendu d'erreur(dont elle ne voulait pas entendre parler). "S'expliquer", ça n'est pas forcément parler. Ca peut être en montrant des choses.

C'est pour le bien de l'équipe que je le fais, pas parce que j'aime embêter mon monde. Moi, je peux dire oui au client pour qu'il m'ait à la bonne et cravacher les ingés; mais c'est pas ma vision du travail en équipe. Je protège les gens qui bossent bien et mets moi-même les mains dans le cambouis mais en retour, on bosse ensemble pas chacun en franc-tireur.

Ma conception du boulot, c'est qu'il doit être bien fait. Si l'occident ne s'est pas encore effondré, malgré ses surcouts colossaux et ses diverses faiblesses, c'est parcequ'il y a encore plein de gens qui travaillent comme moi. Si la spec se contente de dire "refuser telle valeur" sans plus de précision, voire dit juste "on saisit un montant dans une case", c'est à moi, professionel, de faire tout ce que le client ne demande pas, mais dont il a besoin dans ce cadre.

Si je me contente de faire une case avec un titre "montant", et que je laisse passer les montants à 3 décimales, ou négatifs(si le traitement ne le permet pas), ou alpha-numériques au prétexte que ce n'est pas explicité dans la spec, quelle valeur ajoutée ai-je par rapport au premier délocalisé venu qui coute trois fois moins cher que moi? Parceque le délocalisé, il ne faut pas se leurrer : il n'est pas plus bête que moi. Mais, en raison de la distance, il ne peut pas se permettre d'interpréter les specs. Moi je peux. Si je ne le fais pas, je suis mort.

Encore une fois, il ne s'agit pas d'inventer des fonctionnalités. Quand je demande à mon plombier d'installer des WC, il ne s'amuse pas à rajouter un lavabo. Ca serait du gold-plating. Mais si il y a un branchement de tuyau que je n'avait pas anticipé pour que ça marche, lui va le faire quand même. Parceque c'est son métier. Mon métier, c'est de faire des programmes qui marchent bien. Mon métier, c'est que les utilisateurs oublient que j'existe. Je n'ai pas à leur installer de lavabo non sollicité. Mais si ils demandent des toilettes, ils ont le droit à avoir des toilettes qui marchent. Sans vice caché. Sans bricolage horrible qui déconne au premier souci venu.

Je suis un professionnel. Je livre des programmes de qualité, qui ne font pas "boum" au premier dos-d'âne.

EDIT : il y a un point que j'ai oublié : généralement, une amélioration de la gestion des erreurs est rentable, avant même la fin du projet. Parcequ'une gestion rudimentaire va planter un max, et on va se battre avec ça, au lieu d'analyser tranquillement les rejets propres et d'avancer dans la recette. La qualité paye.

[phili_b]

Encore une fois, il ne s'agit pas d'inventer des fonctionnalités. Quand je demande à mon plombier d'installer des WC, il ne s'amuse pas à rajouter un lavabo. Ca serait du gold-plating. Mais si il y a un branchement de tuyau que je n'avait pas anticipé pour que ça marche, lui va le faire quand même. Parceque c'est son métier.

Bon exemple

[jouana]

Je suis d'accord avec toi la qualité paye sur le long terme, le soucis est plus la vision à court terme que les entreprises ont actuellement.

[maazza]

Rares sont les offres qui sont bien rédigées, dans une langue compréhensible par toutes les cultures d'entreprise et non pas dans un jargon local pimenté de quelques concepts à la mode qui ne veulent rien dire. J'ai souvent l'impression que l'offreur veut impressionner tout en ne connaissant rien à ce qu'il demande.

exemple :

- You focus on delivering results, your applications work "first time right"
....
- Need a Master Degree (Minimum a Bachelor)

avec

Excellent understanding of available JavaScript libraries and frameworks (JQuery/​JQM, Mootools, Sencha Touch, Backbone, etc)

on est sensé faire quoi ? étudier 5 frameworks qui font la meme chose ?
si oui dans quel interet ?
http://jobview.monster.be/Looking-fo...119227931.aspx

ridicule

[MiaowZedong]

http://www.projectmanagementlearning...anagement.html

How to Avoid Gold Plating?

La meilleure façon d'éviter ce genre de problème, c'est de faire developper ses logiciels en interne le plus souvent possible, et quand ce ne serait pas viable de chercher d'abord à acheter un logiciel existant sur le marché, n'ayant recours au bespoke que quand c'est strictement nécessaire. Et dans ce dernier cas, le client devrait faire jouer la concurrence, de façon à ce que ses fournisseurs cherchent à lui offrir du gold plating pour garder ses contrats.

Mais, encore une fois, il faudrait éviter le plus possible d'entrer dans une relation client/fournisseur car celle-ci est adverseriale*, comme on peut d'ailleurs le voir dans l'article cité, et à long terme cette opposition nuira aux deux parties.

*est-ce un mot Français? Dans le cas contraire, désolé de l'anglicisme.

Edit: du point de vue d'un chef de projet de SS2I, Caro999 a tout à fait raison. C'est bien pour cela qu'el_slapper a (malheureusement) raison dans sa grande envolée sur le déclin de l'occident...

[Caro999]

Je suis d'accord avec toi la qualité paye sur le long terme, le soucis est plus la vision à court terme que les entreprises ont actuellement.

C'est là que le bat blesse: ce que les informaticiens nomme "qualité" n'a rien à voir avec ce qui se trouve dans un contrat. Contractuellement, l'aspect qualité ne signifie pas qu'il va y avoir zéro défaut dans ce que le client va accepter mais qu'il y a un niveau de fonctionnalité suffisant pour que ça fasse le job. Donc on va dire que le soft est accepté si - par exemple - il n'y a pas de severity 1 et qu'il ya moins de 3 problèmes de niveau 2.

Dans le cas d'un problème d'error handling détecté pendant une phase d'accptance testing, il est probable qu'un client sensé préferera pondre un document d'une page pour indiquer ce qu'il faut rentrer plutot que de repartir pour une phase d'acceptance de 1 ou 2 semaines avec 20 personnes mobilisées. Parce que économiquement cela fait plus de sens de signer le document d'acceptance.

Par ailleurs je comprends qu'il y a une certaine fierté à vouloir livrer du zéro défaut mais il faut comprendre que dans une relation commerciale ce n'est pas forcément ce qui est privilégié.

Je lis souvent que les chefs de projets sont des minables parce qu'ils acceptent - parfois malgré eux - des situations dans lesquelles les équipe de devs sont écrasées de travail avec des délais de livraison insoutenables mais dans le même temps, je remarque qussi souvent que ces mêmes équipes trouvent le temps de faire des trucs en plus que personne n'a demandé.

Moi c'est pas ma religion de laisser souffrir les équipes de devs dans des death marchs mais après, il faut aussi me donner les billes pour pouvoir négocier et protéger les équipes.

[Caro999]

Edit: du point de vue d'un chef de projet de SS2I, Caro999 a tout à fait raison. C'est bien pour cela qu'el_slapper a (malheureusement) raison dans sa grande envolée sur le déclin de l'occident...

Pas qu'en SSII. J'ai aussi bossé chez un gros éditeur de gros progiciels bien complexes et la problématique est la même qu'on fasse de la nouvelle fonctionnalité, du sur-mesure ou du déploiement/intégration sur site.