Discussion :

[el_slapper]

(.../...), la culture, la chanson, le BAC, la malbouffe, ou n'importe quoi..

Si on augmente le nombre, on diminue la qualité. ..

Forcément...

Et des deux côtés : la qualité des "encadrants" et la qualité des "encadrés"..

Non, parcequ'on ne racle pas les fonds de tiroir. En Malaisie ou en Roumanie, plus de la moitié des informaticiens dont des femmes. Nous n'en avons que 15 à 20%. Nous avons aussi très peu de gens issu des couches les plus défavorisées. Nous avons aussi plein d'anciens qui on été mis au rebut. En nous éliminons quasiment systématiquement les gens qui n'ont pas le bon profil scolaire. Ce sont là d'importants gisements de talent qui permettraient d'améliorer la qualité moyenne du pool sans en réduire la taille.

Non, je ne suis pas d'accord.. ça se résume à des problèmes d'argent...

Entre les "aides à l'embauche", les "aides aux stages", et la notion de "chaine de production", tu as tous les ingrédients..

Dans une grosse boite, un employé est un pion - quel que soit son niveau -

Puisque c'est un pion, d'une part on doit gagner de l'argent dessus, et d'autre part on doit raisonner comme si c'était quelqu'un d'autre..

Donc forcément, ça va dans le sens contraire de l'esprit de l'agilité.... Même si on se prétend "agile"...

Pas compris, là..... Je suis un pion, certes, mais il est arrivé qu'il soit l'interêt du grand chef de me laisser tranquille(pour pouvoir accuser le prestataire en cas d'echec, aucun interne n'ayant accepté de risquer sa carrière sur le projet). Bizarrement(ou pas), ça a été mon meilleur projet.

Tu ne peux pas empêcher, mais tu peux lutter contre : d'une part en ne courbant pas l'échine et en ne ratant pas une occasion de mettre le nez dans leur c.c. aux chefs, et d'autre part, si cela ne marche pas, en allant choisir une meilleure boite (ou, mais là il faut être vraiment motivé, et éventuellement avoir les moyens, en faisant le même projet en // en suivant ce que tu crois)

Je n'ai pas les moyens de faire un projet complet en sous-marin. Et quand "ce qu'il faudrait faire", c'est désactiver une appli fausse, inutile, couteuse, inmaintenable, déjà remplaçée, mais que les utilisateurs(qui ne l'utilisent plus depuis 11 mois) flippent comme un rat face à un aigle à cette idée, fatalement, il est plus délicat d'agir en sous-marin. Ca se verrait.

Bon, ça m'arrive de le faire quand le contexte est favorable. Mais je ne me vois pas violer entièrement un ordre direct. Le contourner ou l'adapter, oui.

Je suis d'accord, mais cependant les exigences pour être architecte ou CP dans le cadre d'un cycle en V demand(ai)ent une rigueur dans les formulations / délimitation de périmètre / hiérarchie de la pensée / découpage des éléments ...

On a pas vu les mêmes.....

La mode "agile" a remplacé ça par des termes comme "sprint" et autres "Scrum Master", qui du coup ont le privilège d'avoir des formations spécialisées, mais en dehors de la base de l'architecture de la pensée et de l'analyse..

là, on est d'accord. Les meilleurs s'en sont emparés d'abord, mais une horde d'incapables s'est engouffrée dans la brêche.

Comme "cycle en V"" ou "Waterfall" c'est devenu ringard, on a "oublié" la base.. (.../...)

Je n'ai pas croisé beaucoup de gens qui l'aient un jour maitrisé.

[Logan Mauzaize]

Méfie toi l'agilité peut être un mirage aux alouettes ... elle apporte son lot de défauts a commencer par celui de supprimer la pression d'une livraison sur l'équipe de développement et d'entendre un sempiternel "au prochain run".

Etre agile (/souple) ne veut pas dire qu'il n'y a pas de planning (ni date, ni jalons). Bien au contraire.

Chaque "ticket" a une durée estimée. C'est grâce à elle que soit on détermine la date du prochain jalon, soit qu'on repousse à plus tard si on ne veut pas dépasser une certaine date pour le prochain jalon.
Certes chaque jalon ne donne pas lieu à une livraison "externe" mais doit représenter une livraison "interne". Cela pourrait par exemple servir de "démo" au client.

Dans un processus plus globale, tu pourrais commencer un dev, continuer par un autre et finir le premier des mois plus tard. Il y a une différence entre faire 4 tâches en 1 mois et en faire 48 en 12.

[rimram31]

Etre agile (/souple) ne veut pas dire qu'il n'y a pas de planning (ni date, ni jalons)...

Certes, mais a contenu, "livrable" variable :-) c'est bien le principe on garantit une date de livraison par contre on se donne quelques libertés sur ce qu'il y aura dedans (c'est même le principe car elle priorise ce qu'elle peut le plus facilement "produire").

A l'usage en pratique, vs une deadline "classique", je leur ai trouvé l'inconvénient de ne pas garantir une date de livraison pour un feature donné, soit qu'il ne sera tout simplement pas livré, soit qu'il a été réinterprété (trop d'acteurs ...) avec une tendance des équipes de "dev" a ne plus se mouiller, se réfugiant derrière "la méthode". Il suffit de te poser la question de l'adéquation d'une méthode agile avec les tests pour comprendre.

[souviron34]

Il suffit de te poser la question de l'adéquation d'une méthode agile avec les tests pour comprendre.

C'est justement ce qui me pose (entre autres) de gros problèmes avec les "méthodologies"...

Et ce que je disais plus haur...

On peut être souple sur le développement, mais les tests sont les tests...

Alors on peut facilement se passer des TU (surtout des fonctions faisant A+B) et des docs y référant..

Par contre, les tests fonctionnels, de régression, etc , je vos mal comment livrer une version opérationnelle (même incomplète) sans ça...

C'est bien pour ça que je prône, tout comme les auteurs du Manifeste, une approche agile, dans la manière de gérer et de concevoir les rôles, réunions, communication, docs, évolutions, points noirs, etc etc, mais pas une méthodologie...

Car c'est non seulement un état d'esprit et une manière de fonctionner, mais cette manière ne peut se reposer que sur des gens (très) compétents... (voir le Manifeste, qui le dit pratiquement clairement)


Si donc on a une équipe de gens compétents, les tests ne posent pas de problèmes particulier.... Ni la garantie de fournir à une date donnée une fonctionalité demandée (éventuellement partielle).

J'avoue avoir non seulement de sérieux doutes sur les "méthodologies", mais encore plus sur leur application à grande échelle... On revient à ce que je disais plus haut : le texte du Manifeste a été écrit par des gens très expérimentés, à destination de gens très expérimentés...

Certains ont dérivé des "méthodologies" à suivre pour une utilisation de masse... Forcément y'a des choes qui coincent.. fort...

[Logan Mauzaize]

Certes, mais a contenu, "livrable" variable :-) c'est bien le principe on garantit une date de livraison par contre on se donne quelques libertés sur ce qu'il y aura dedans (c'est même le principe car elle priorise ce qu'elle peut le plus facilement "produire").
A l'usage en pratique, vs une deadline "classique", je leur ai trouvé l'inconvénient de ne pas garantir une date de livraison pour un feature donné, soit qu'il ne sera tout simplement pas livré, soit qu'il a été réinterprété (trop d'acteurs ...) avec une tendance des équipes de "dev" a ne plus se mouiller, se réfugiant derrière "la méthode". Il suffit de te poser la question de l'adéquation d'une méthode agile avec les tests pour comprendre.

Je pense qu'on a vraiment pas le même point de vue sur l'approche agile.
Ce que tu me dis n'est pas le défaut mais la force ! S'il n'y a pas de date sur une feature c'est qu'il y en a des plus nécessaires aux yeux du client. Le scope est définit en grande partie par lui, pas par les développeurs !

Le fait qu'une feature n'arrive jamais veut simplement dire que le client n'en a pas besoin. Ce qui comble l'effet tunnel d'une approche classique et qui empire avec les avenants.

Ensuite un dernier point sur l'approche agile. Actuellement, nous travaillons en étroite collaboration avec le client. Ca se passe bien mieux que sur les projets, où ce n'est pas le cas. Mais ce serait encore autre chose si le client faisait partie de l'équipe comme le souhaite l'approche agile.
Le fait d'avoir des jalons réguliers et procéder par itération (y compris au sein d'une feature) permet également de rapidement corriger les erreurs d'interprétation avant qu'elle ne se propage dans une part trop importante de l'application.

[souviron34]

Ensuite un dernier point sur l'approche agile. Actuellement, nous travaillons en étroite collaboration avec le client. Ca se passe bien mieux que sur les projets, où ce n'est pas le cas.

Je vois que finalement mes convictions et exposés, plus la pratique, t'ont convaincu

J'en suis très heureux...

[rimram31]

Je pense qu'on a vraiment pas le même point de vue sur l'approche agile...

Tu me parles d'approche, je te parle de méthode , tu ne me convaincras pas sur l'approche car bien avant "la mode agile", j'appliquais cette approche depuis plus de vingt ans! A l'époque, on appelait ça une approche par prototype et/ou incrémentale et je n'avais pas besoin d'un arsenal de principes pour la faire fonctionner :-) simplement planifier de nombreuses réunions d'avancement et prévoir des livrables intermédiaires.

Mais j'ai connu l'application de la "méthode" qui a déjà comme défaut d'ajouter des intermédiaires et de cloisonner (au contraire de ce que tu me décris) et une dérive que j'ai vécu c'est que le résultat était ajusté a l'effort et non l'inverse, j'ajouterai le résultat jugé possible par l'équipe et non celui demandé. J'ai donc connu exactement l'inverse de ce que tu décris, les pleins pouvoirs de l'équipe de dev au détriment des demandes client.

Tout ça c'est bien sympa mais quand "le client" te demande une date de correction ou de livraison parce que lui il a du business lié a ton produit, quand il doit anticiper un minimum l'allocation de ressources et de budget pour des tests et des campagnes de communication, tu fais comment? Bien entendu que cela dépend des contextes et des gens en présence, mais en tout cas de mon expérience, ça peut paraitre surprenant, j'ai trouvé que cela éloignait les équipes de dev du client et ça arrangeait bien l'équipe qui pouvait se cacher derrière "la méthode".

[souviron34]

Non, parcequ'on ne racle pas les fonds de tiroir. En Malaisie ou en Roumanie, plus de la moitié des informaticiens dont des femmes.

D'une part je ne parlais ni des femmes, ni de la Roumanie (que je ne connais pas), mais de la France et du système français, basé sur de très grosses SSII et de très gros "services infos"..

Ensuite, je suis au regret de te contredire, car, que ce soit la qualité des enseignants (ce qui se voit dans les arguments avancés ici par certains sur certains threads "généraux" touchant à l'informatique), ou la qualité des "enseignés", de base en termes de clarté de la pensée, de l'analyse, et de la mise en contexte (par exemple par rapport aux méthodes plus traditionnelles (affublées de "has been" ou "dinousauresques" (voir les commentaires sur les différents paradigmes et que l'OO est le Dieu et le procédural une horreur)), et de manière plus générale en termes de pensée "hors mode" ou "hors outils/framewotrk/IDE..." 'est considérablement appauvrie...

Et l'explication est assez simple : l'écrémage n'étant que peu fait, on se retrouve avec beaucoup de médiocres pour la même quantité de bons..

C'est pareil en musique : comme il est extrêmemnt facile de faire un CD, et maintenant de faire un site où on le met en ligne, on a pléthore "d'offre"... On compte toujours sur les doigts d'une à 2 mains les bons...

Pas compris, là..... Je suis un pion, certes, mais il est arrivé qu'il soit l'interêt du grand chef de me laisser tranquille(pour pouvoir accuser le prestataire en cas d'echec, aucun interne n'ayant accepté de risquer sa carrière sur le projet). Bizarrement(ou pas), ça a été mon meilleur projet.

Tu es alors un privilégié dans une bonne boite...

Dans une grande SSII, le CP ou architecte est sur une mission donnée pour un temps donné.. Au bout du temps, si le boulot est pas fini et qu'il y a une autre mission, il est envoyé sur l'autre mission...

Vécu personnellement plusieurs fois, y compris pour le CP ou le Directeur Technique ou du Projet... y compris sur de très très gros projets..

On a pas vu les mêmes.....

Sans doute pas, et ça rejoint mon premier point...

Si tu regardes évoluer et travailler des gens dans la cinquantaine ou plus je crois que tu verras la différence...

là, on est d'accord. Les meilleurs s'en sont emparés d'abord, mais une horde d'incapables s'est engouffrée dans la brêche.

Non, ce n'est pas une "bande d'incapables".. Ce sont juste des étudiants et des jeunes à qui on a bourré le mou en disant "ça c'est le nec-plus-ultra", mais qu'on a oublié de former (et de respecter et connaître) à ce qui se faisait avant...

Et ça rejoint là-encore le premier point : un manque de culture et de recul historique fondé sur des connaissances...

Je n'ai pas croisé beaucoup de gens qui l'aient un jour maitrisé.

Voir plus haut ("on n'a pas vu les mêmes")

Mais j'ai connu l'application de la "méthode" qui a déjà comme défaut d'ajouter des intermédiaires et de cloisonner (au contraire de ce que tu me décris) et une dérive que j'ai vécu c'est que le résultat était ajusté a l'effort et non l'inverse, j'ajouterai le résultat jugé possible par l'équipe et non celui demandé. J'ai donc connu exactement l'inverse de ce que tu décris, les pleins pouvoirs de l'équipe de dev au détriment des demandes client.

Tout ça c'est bien sympa mais quand "le client" te demande une date de correction ou de livraison parce que lui il a du business lié a ton produit, quand il doit anticiper un minimum l'allocation de ressources et de budget pour des tests et des campagnes de communication, tu fais comment? Bien entendu que cela dépend des contextes et des gens en présence, mais en tout cas de mon expérience, ça peut paraitre surprenant, j'ai trouvé que cela éloignait les équipes de dev du client et ça arrangeait bien l'équipe qui pouvait se cacher derrière "la méthode".

Je te crois tout à fait...

Comme je l'ai déjà dénoncé ailleurs, ce sont des "buzz-word" où les marketeux s'engouffrent, décrochent des contrats sur l'argument du siècle "c'est ce qui se fait de plus en pointe", et comme les grosses SSII et les groses boites n'aiment ni le flou, ni le fait de se reposer sur quelques personnalités, on a fait des belles théories et "méthodologies"...

Comme parallèllement les étudiants ont appris ça, ils ne jurent plus que par ça... Et du coup ça devient une justification en soi...

C'est bien pour ça d'ailleurs que le Manifeste (et moi-même modestement, comme toi visiblement) ne mentionne absolument pas une quelcquonque méthodologie..

L'approche consiste à shunter ce qu'on peut quand on peut avec les personnes qu'on peut et de la manière qu'on peut..

Rien de tangible là-dedans.. Tout repose sur les personalités des gens...

Mais comme c'est pas beau, dans notre belle société, d'être élitiste, la "démocratisation" implique des guides rigides pour ce Bas Peuple... et donc de détourner ce qui étaient des idées de bon sens de gens expérimentés pour en faire un carcan absurde pour des gens peu expérimentés... Qui du coup se protègent (ironiquement comme les équipes en V se protégaient derrière le cycle) en arguant de la méthode... Et comme de plus pour les SSII le client n'est qu'un payeur, et les employés que des moyens de gagner de l'argent...


De la chair à canon... c'est la base de la réflexion et de l'émergence des "méthodologies", et encore plus de leur application dans un système à la française...

[el_slapper]

Je ne crois même pas que ça soit de la lutte contre l'élitisme. C'est juste une pensée industrielle, appliquée là ou elle ne devrait pas. Ou plutôt, appliquée parceque l'efficacité n'est pas le critère principal.

Le critère principal, c'est "je suis le chef, comment je reste chef". Réponse : en rendant mes subordonnées remplaçables.

Je n'ai rien contre la pensée industrielle, elle est for utile dans bien des domaines - dont certains liés à l'informatique(spécialement pour la partie déploiement, ou pour gérer des serveurs). Sauf qu'elle a pour résultat secondaire de niveler le niveau des gens. Quand on cherche à fabriquer toujours la même voiture, ça a son charme. Dans une discipline comme le développement, c'est destructeur.

[gigigo]

oui, c'est sur, comme il n'y pas un monde parfait, il n'y a pas non plus un template qui peux répondre tout.
mais maintenant le travail reste plustôt un "assemblage" ou "montage" sur les produits existants.

[souviron34]

Je ne crois même pas que ça soit de la lutte contre l'élitisme. C'est juste une pensée industrielle, appliquée là ou elle ne devrait pas. Ou plutôt, appliquée parceque l'efficacité n'est pas le critère principal.

Oui je suis assez d'accord...

Mais pas avec :

Le critère principal, c'est "je suis le chef, comment je reste chef". Réponse : en rendant mes subordonnées remplaçables.

Ton chef est lui-même remplaçable..

Il y a bien entendu le Principe de Peter en action.

Mais plus profondément, il y a le critère principal qui est l'argent..

A la question "comment je peux gagner de l'argent", une SSII répondra "en employant au maximum des gens relativement peu payés, en étirant au maximum des contrats, et en flattant l'égo de mes interlocuteurs".

Il n'y a aucune notion d'efficacité dans la production du logiciel par une grosse SSII, c'est même le contraire.. : plus ça dure longtemps, plus tes employés seront payés, et donc plus tu gagneras de l'argent. Même chose si, à la livraison, on te demande des modifs : ces modifs seront payantes, et les employés payés... Au vu des marges entre tarif du salarié envers le client et montant du salaire, on parle ici d'un incentif majeur... *

De plus, on vend de l'esbrouffe, le "dernier truc à la mode" est le plus vendeur quand en face de soi on a des administratifs qui décident, et qui ne font référence qu'au "buzz".. Et, cerise sur le gateau, comme c'est pour être "à la pointe", on peut le vendre nettement plus cher que le classique...


Le cas est "un tout petit peu différent" pour les très grosses boîtes avec un gros SI interne... Mais peu, d'autant plus que ces très grosses boîtes sont en général des banques ou des assurances, pour lesquelles le budget info est un gros sac indiscriminé - et permanent d'une année sur l'autre.. Et donc le coût de tel ou tel projet est non seulement délayé dans le temps, mais dilué par projet sans vraiment de notion d'efficacité (un de mes beaux-frères au ex-GAN maintenant Groupama depuis 25 ans est .... totalement dégoûté.. Et parfaitement sur la même ligne d'analyse que moi là-dessus)



* : quand on voit des soumissions pour passer de la Phase 2 à la Phase 3 d'un projet chiffrée 10 millions (sur 2 ans), mais surtout évaluées à 42000 h/j, ce qui fait 2 siècles de boulot, je ne vois pas où est l'efficacité du projet.. Par contre, je vois une super-efficacité budgétaire.. (42000 fois une marge entre 100 et 300% !!!)

[el_slapper]

(.../...)

A la question "comment je peux gagner de l'argent", une SSII répondra "en employant au maximum des gens relativement peu payés, en étirant au maximum des contrats, et en flattant l'égo de mes interlocuteurs".

Et pourquoi le client achète? Parceque l'acheteur(généralement un grand chef) a peur pour sa place. Plus l'offre retenue est "rassurante", plus le parapluie est efficace : "cher actionnaire, j'ai fait le standard, je n'ai pris aucun risque"

Il n'y a aucune notion d'efficacité dans la production du logiciel par une grosse SSII, c'est même le contraire.. : plus ça dure longtemps, plus tes employés seront payés, et donc plus tu gagneras de l'argent. Même chose si, à la livraison, on te demande des modifs : ces modifs seront payantes, et les employés payés... Au vu des marges entre tarif du salarié envers le client et montant du salaire, on parle ici d'un incentif majeur... *

+1. Il me semble juste que "incentif" c'est pas du Français, mais ça se comprend quand même, et je suis 100% d'accord.

De plus, on vend de l'esbrouffe, le "dernier truc à la mode" est le plus vendeur quand en face de soi on a des administratifs qui décident, et qui ne font référence qu'au "buzz".. Et, cerise sur le gateau, comme c'est pour être "à la pointe", on peut le vendre nettement plus cher que le classique...

Et l'administratif prend du "buzz" parceque ça protège sa carrière. La SSII vend du buzz parceque ça marche. Ca marche parceque les décideurs ne maitrisent rien et ont peur.

Le cas est "un tout petit peu différent" pour les très grosses boîtes avec un gros SI interne... Mais peu, d'autant plus que ces très grosses boîtes sont en général des banques ou des assurances, pour lesquelles le budget info est un gros sac indiscriminé - et permanent d'une année sur l'autre.. Et donc le coût de tel ou tel projet est non seulement délayé dans le temps, mais dilué par projet sans vraiment de notion d'efficacité (un de mes beaux-frères au ex-GAN maintenant Groupama depuis 25 ans est .... totalement dégoûté.. Et parfaitement sur la même ligne d'analyse que moi là-dessus)

Pas d'accord sur le permanent : ça change tous les ans(en tous cas ici). Mais comme les changements sont aveugles, au final, ton raisonnement est quand même tout à fait vrai. Hélas.

ça fait 3 ans que je suis chez mon client actuel(Je vais partir fin mars, limite des 3 ans oblige). Dès mon arrivée, on m'a parler de la grande migration vers la maison mère(c'est chez Glutinus, pour ceux qui suivent). Ca n'a pas bougé des masses, même si les dépenses ont été colossales.

* : quand on voit des soumissions pour passer de la Phase 2 à la Phase 3 d'un projet chiffrée 10 millions (sur 2 ans), mais surtout évaluées à 42000 h/j, ce qui fait 2 siècles de boulot, je ne vois pas où est l'efficacité du projet.. Par contre, je vois une super-efficacité budgétaire.. (42000 fois une marge entre 100 et 300% !!!)

C'est de la marge sur forfait, ça. Sur régie, c'est nettement moins. Et bon, des forfaits de 18 mois et 60 personnes qui ont 3 ans de retard, ça relativise les marges.....(le pire, c'est que la partie de 25 personnes(dont 12 programmeurs) sur laquelle j'étais homologateur, avec la bonne techno, j'aurais torché la programmation tout seul en 6 mois. Evidemment, ils ont fait des choix aberrants pour vendre plus de jours. Mauvaise pioche).

En interne, c'est moins mouvementé. De toutes façons, le budget est voté, il sera dépensé, et advienne que pourra. La SSII a interêt à rester au-dessus de 80% d'activité pour rester rentable. Les marges sont plus faibles, mais plus pépères, aussi, tant que la plupart des "consultants" sont plaçés.


Mais la conclusion est la même : c'est piloté par des gens qui (1) ne comprennent pas ce qu'ils font, (2) ont peur, et (3) moutonnent pour garder leur place. Donc la SSII joue sur du velours.

[rimram31]

...C'est bien pour ça d'ailleurs que le Manifeste (et moi-même modestement, comme toi visiblement) ne mentionne absolument pas une quelcquonque méthodologie...

Je ne critique pas fondamentalement le principe, je me suis battu des années pour faire accepter des approches prototypes et incrémentales. J'avais beau démontrer a tous les coups que ça marchait, le projet suivant il me fallait de nouveau reprendre ma croisade. Mais j'ai aussi pesté des années après le manque d'implication des équipes de dev sur les demandes client, je trouve que ces méthodes n'aident pas en ce sens. Fini le temps du rythme fou a l'approche d'une deadline, on se retrouve dans un "rythme mou" qui arrange bien les développeurs ...

[mumen]

Bonjour el_slapper, souviron, tous

Franchement, ça fait peur votre discussion.

Mais je ne peux que corroborer par ma seule expérience en contexte de développement 'corporate', qui a été proprement sidérante.

Mon client, racheté par une corporation, abandonnait mon développement pour un gros ERP. Il m'a fallu participer à la conversion : en quelques mois j'ai doublé avec lui mon chiffre d'affaire de 10 ans pour faire presque rien avec panache. Ceci dans une ambiance de conquête ou pas moins d'une cinquantaine de loups venus du monde entier s'activaient apparemment avec brio. "So many people for so little knowledge" a été le résumé laconique du plus conscient de tous ces gens.

Quand j'avais été présenté la première fois à l'équipe de conversion, j'ai reçu une chose que je n'attendais vraiment pas : une reconnaissance incrédule de mon travail en solo chez cet équipementier, pour un prix, vous l'avez compris, dérisoire eu égard aux critères des corporations. Pourtant j'estime avoir gagné ma vie normalement avec ce client parmi d'autres...

Dire que le premier négociateur auquel j'avais eu affaire sur ce dév m'a refusé un paiement de deux jours de prétendu dépassement, parce que j'avais dit, suite à la première écoute des besoins et comme toujours sans la moindre analyse, "Oh je ne sais pas mais disons qu'il y en aura pour une vingtaine de jours pour faire tout ce que tu demandes dans un premier temps - sans garantie" et que j'en avais mis 22, évidemment pour en faire plus que prévu !

Mais quelle est donc la valeur de mon travail dans ces circonstances ? Quand je travaille à merveille pour presque rien, on me chipote mon dû et quand je fais acte de présence dans une gabegie sans nom, ma déontologie est bousculée par la gêne d'être surpayé !

En guise épilogue, après des mois d'invasion de l'entreprise par les hordes d'ingénieurs, le grand chef de la conversion a été remercié pour cause d'échec. Je me dois d'ajouter à la décharge de cet homme que la conversion de mon client était une tentative de formaliser une conversion-type à généraliser ensuite à toutes les filiales de la corporation .

L'entreprise, je vous rassure, a survécu. Je travaille toujours pour elle de loin en loin, parce que la solution d'ingénierie n'est pas encore définie au niveau corporation et que cela sera fait dans deux ans. Ceci depuis cinq ans.

[souviron34]

C'est de la marge sur forfait, ça. Sur régie, c'est nettement moins.

J'auras dit l'inverse, moi...

Régie, c'est bien quand tu es chez le client ??

Moi j'ai vu (même sur ma tête) un facteur 3 entre le salaire horare que je gagnais et le prix demandé à l'heure... C'est pour ça que je disais entre 1 et 3 de marge.. Et c'est la moyenne de ce que j'ai vu.

A moins que ça ait - beaucoup beaucoup - changé...

[el_slapper]

J'auras dit l'inverse, moi...

Régie, c'est bien quand tu es chez le client ??

Moi j'ai vu (même sur ma tête) un facteur 3 entre le salaire horare que je gagnais et le prix demandé à l'heure... C'est pour ça que je disais entre 1 et 3 de marge.. Et c'est la moyenne de ce que j'ai vu.

A moins que ça ait - beaucoup beaucoup - changé...

Ca a beaucoup changé, et de toutes façons, il faut regarder tous les frais annexes. Je touche 43k brut(à 2PI près). Je dois coûter environ 65k à l'année, rien qu'en salaire et charges étatiques. Ajoute le salaire du commercial, des équipes administratives. Je dois être facturé un peu plus de 400 roros par jour de présence, soit 90k par an. Tu prends 80% de ce total pour compter les intercontrats, et tu arrives à une marge finalement assez faible.

Ajoutes à celà le fait que les clients sont dans une logique de masse "nous avons 36 consultants de chez vous chez nous. Pour le même prix, il nous en faut 40. Sinon, les 36 autres giclent". Rien à péter de la qualité ou de la pertinence des 4 profils en question. La SSII suit les demandes aberrantes du client pour rester vivante. Et essaye de faire du forfait, parceque là-dessus, elle peut facturer la journée plus cher, et essayer d'entuber le client sur le temps réel passé.


@Mumen : mon père a eu le même genre d'expérience que toi, sauf qu'il a été viré à la fin. Puis il s'est mis en équipe avec un spécialiste de la gestion de stock, et a tout seul réalisé un logiciel complet de gestion de stock optimisée. En 6 mois. Si on demande le même à une SSII, il faudra 2 ans, un chef, un sous chef, une armada de devs, des homologateurs, un chef de produit, un ergonome..... D'ailleurs la demande a été faite. Plusieurs fois. Toujours avec la même réponse : "C'est pas possible de faire ça à moins de 4000 jours-homme". Même pas 200.....

[rimram31]

...Mais quelle est donc la valeur de mon travail dans ces circonstances ? Quand je travaille à merveille pour presque rien, on me chipote mon dû et quand je fais acte de présence dans une gabegie sans nom, ma déontologie est bousculée par la gêne d'être surpayé !

Parce qu'il y a une différence entre la valeur produite et la valeur ajoutée (objective ou subjective, la seconde parfois en "corporate" ...). J'ai eu quelques projets où des idées jetées "en un week-end" (bien rempli!) sont devenus des produits facturés au prix fort au client parce qu'il le voulait absolument! On a tous eu des projets où l'on a pu très bien valoriser "peu de boulot" comme d'autres où on a bossé comme des fous pour un échec au final. C'est sans rapport avec la qualité du travail technique produit même si on a toujours tendance dans "l'évaluation" a rendre la technique pour partie responsable.

...Moi j'ai vu (même sur ma tête) un facteur 3 entre le salaire horare que je gagnais et le prix demandé à l'heure...

La "régie", c'est bien quand tu es chez un client.

Loin de moi l'idée de défendre les SSII, j'en connais un peu les rouages et c'est pas toujours joli, joli ... mais méfie-toi du raccourci salaire/facturation client.

D'une, je ne sais pas ce que tu comptes, mais entre ton salaire et le coût employeur, ajoute déjà entre 40 et 50% au brut salarié, de deux, tu ne travailles jamais qu'un peu plus de 200j par an (journées "facturées"), enfin, compte le "brut total", avantages éventuels compris: 13ème mois, frais, primes...

Au final, c'est entre 30 et 50% de "marge brute" sur ta pomme, plutôt 50 sur des débutants, la raison pour laquelle les SSII préfèrent virer les vieux pour prendre des jeunes :-) (les salaires progressant plus vite que la facturation), c'est la rémunération de la "structure", les efforts qu'il faut faire pour trouver du business. Après tout dépend des gens en présence et de la "philosophie" de la SSII mais si tu étais a ton compte, réfléchis au temps que tu devrais passer en prospection, c'est pas aussi simple qu'il n'y parait.

Mais sur le fond, une SSII va préférer de loin la régie au forfait (c'est d'ailleurs un indicateur pour les "évaluer") car c'est une activité avec très peu de risques qui n'engage pas sur le résultat mais uniquement sur des moyens.

Ce qui est déplorable dans ce business c'est que tu n'es pas une ressource de l'entreprise mais tu deviens rapidement un "centre de profit" avec le risque de devenir un "centre de coût" en inter contrat, on a alors déjà prévu la case "coût de licenciement" dans le tableau Excel

[souviron34]

Fini le temps du rythme fou a l'approche d'une deadline, on se retrouve dans un "rythme mou" qui arrange bien les développeurs ...

Je ne vois pas pourquoi.. En tous cas avec ma vision des choses, cela reste une évidence... Même en "approche" agile...

Mais il est certain que mes deadlines étaient ..... non négociables : des salons internationaux... ou des mises en opération à l'échelon national..

Maintenant, il est tout à fait possible que les "méthodologies" et les gens qui les poussent à l'heure actuelle s'en fichent comme de leur première chemise, dans ces contextes de pures relations clients/fournisseurs, mais si c'est le cas, c'est une aberration et une raison de plus qui me confirme dans la pensée que c'est un "buzzword" marketing. et une mode imbécile..

Franchement, ça fait peur votre discussion.

Désolé nous parlons malheureusement d'expérience..

Mais je ne peux que corroborer par ma seule expérience en contexte de développement 'corporate', qui a été proprement sidérante.

Ben oui

Mais quelle est donc la valeur de mon travail dans ces circonstances ? Quand je travaille à merveille pour presque rien, on me chipote mon dû et quand je fais acte de présence dans une gabegie sans nom, ma déontologie est bousculée par la gêne d'être surpayé !

Tu fais (malheusement pour ton bien-être moral) partie des gens ayant une conscience professionnelle et une déontologie..

Bienvenue au club..

Il semble que nos soyons une très faible minorité à avoir cette éthique...

Mais ça me rappelle les réflexions que j'ai entendues avant de partir au Canada, quand, en tant qu'ingénieur, je refusais les boulots militaires pour fabriquer des bombes et des missiles, et qu'on me disait "t'es con, si c'est pas toi qui le fait ce sera quelqu'un d'autre"...

Avec ce genre d'argument, tout est "avalable"... Par contre, je ne sais pas comment ces gens-là peuvent se regarder dans une glace...

En guise épilogue, après des mois d'invasion de l'entreprise par les hordes d'ingénieurs, le grand chef de la conversion a été remercié pour cause d'échec. Je me dois d'ajouter à la décharge de cet homme que la conversion de mon client était une tentative de formaliser une conversion-type à généraliser ensuite à toutes les filiales de la corporation .

L'entreprise, je vous rassure, a survécu. Je travaille toujours pour elle de loin en loin, parce que la solution d'ingénierie n'est pas encore définie au niveau corporation et que cela sera fait dans deux ans. Ceci depuis cinq ans.

Moi, comme expérience, j'ai eu 2 très gros projets, l'un de 60 personnes/15 ans/80 millions, que les utilisateurs ne voulaient même pas tester tant c'était horrible, qui a coulé alors que nous l'avions remonté en 1 an1/2 à 6 et pour 600000, avec des demandes d'achat et des prix internationaux, mais pour lequel la boîte d'origine a quand même récupéré 15 ans * 59 personnes * la marge (), bien que je l'ai dénoncé haut et fort, y compris dans la presse (ce qui a créé un tel scandale qu''ils ont quand même dû arrêter la gabegie, car c'était sur des fonds publics), et un autre, pour lequel ça a été encore plus fort : 100 personnes pendant 10 ans, projet incomplet et rejeté par les utilisateurs, avec un contre-projet de .. 3 personnes pendant 5 ans, qui a réussi et comblé les utilisateurs pour 350 000, et qui finalement a été abandonné pour causes politiques pour lesquelles on a re-dépensé 80 millions pour un truc encore moins souple... mais qui fonctionnait sur le Web... Yes !! ça ça fait chic et "à la pointe"... Ce qui fait au total une dépense d'environ 200 millions... pour un truc bancal... avec la moitié des fonctionalités...

Dans le premier cas c'était une grosse SSII, dans l'autre le gouvernmenent.

Le gouvernement (et donc les contribuables) ont perdu énormément d'argent. La SSII s'est fait des c.uiles en or pendant 15 ans (sur 60 personnes, 59 étaient "louées")...

Et les avatars du Dossier Médical Informatisé, démarré depuis 1984, relancé par Douste-Blazy en 2004, dont le CP a fini par démissioner l'an dernier, mais qui consomme entre 2 et 3 milliards d'euros par an depuis 1984, n'est pas là pour me démentir...

Ca a beaucoup changé, et de toutes façons, il faut regarder tous les frais annexes. Je touche 43k brut(à 2PI près). Je dois coûter environ 65k à l'année, rien qu'en salaire et charges étatiques. Ajoute le salaire du commercial, des équipes administratives. Je dois être facturé un peu plus de 400 roros par jour de présence, soit 90k par an. Tu prends 80% de ce total pour compter les intercontrats, et tu arrives à une marge finalement assez faible.

Bon, ça dépend des "spécialités" et du niveau.. Moi on me louait/loue 3 fois mon salaire..

La SSII suit les demandes aberrantes du client pour rester vivante.

On rejoint le point au dessus sur la déontologie.. Dans le projet que je mentionnais plus haut (60 personnes/15 ans), j'ai fait arrêter la collaboration (et pourtant la boite qui m'avait loué était membre du CA de la mienne), après avoir convanincu ma PDG..

On a perdu des sous mais on n'a pas été entraîné dans la chute ni dans les commentaires et retombées dans le milieu après la chute... et donc on a plus gagné des sous après, parce que les boîtes estimaient qu'on ne leur mentaient pas...

Mais c'est sûr qu'il faut être soutenu et avoir une éthique, à tous les niveaux..

Et c'est bien pour ça que je disais que le moteur principal est l'argent, contrairement à ce que tu disais sur la hiérarchie et les chefs..

Et essaye de faire du forfait, parceque là-dessus, elle peut facturer la journée plus cher, et essayer d'entuber le client sur le temps réel passé.

Je sais pas moi mais c'est qu'alors les clients sont c.ns ou matraqués.. Parce que pour moi, un prix de journée au forfait doit être largement inférieur à un prix en régie..

En tous cas c'est comme ça que moi je négocie....

Et si moi (quand c'est moi qui fournit une estimation) ou la boîte que je prend (quand c'est moi qui engage) s'est trompé sur l'estimation, ben tant pis pour moi - eux..

Et c'est pour ça qu'on retombe sur "comment faire une bonne estimation"

[infofree]

Bonjour,

Je vous assure que votre discussion est fort intéressante et je vous lis avec beaucoup d’intérêt
Cela dit, ne vous-êtes pas entrain de vous éloigner du sujet du post ?

En aucun cas je veux faire mon rabat-joie, si vous estimez que c'est la continuité du sujet, alors aucun problème pour moi, continuons dans ce sens...

Vos expériences sont riches et enrichissantes et c'est avec plaisir que je vous lis

[chaplin]

Tu fais (malheusement pour ton bien-être moral) partie des gens ayant une conscience professionnelle et une déontologie..

Bienvenue au club..

Il semble que nos soyons une très faible minorité à avoir cette éthique...

Mais ça me rappelle les réflexions que j'ai entendues avant de partir au Canada, quand, en tant qu'ingénieur, je refusais les boulots militaires pour fabriquer des bombes et des missiles, et qu'on me disait "t'es con, si c'est pas toi qui le fait ce sera quelqu'un d'autre"...

Avec ce genre d'argument, tout est "avalable"... Par contre, je ne sais pas comment ces gens-là peuvent se regarder dans une glace...

Comment tu fais pour durer? Parce que là tu résumes dans ces propos la dérive complète de notre société. J'ai capitulé, je laisse faire, jusqu'à ce que ça explose.