Discussion :

[B.AF]

Par contre tes deux derniers paragraphes me semblent bizarre... c'est clair qu'on ne parle pas d'une personne mais d'une équipe. Et ceci est particulièrement valide justement pour les équipes où il y a bien plus de 15 personnes. Peut-être ai-je mal compris ?

Je dis qu'aujourd'hui, avec l'outillage, les technos et la complexité des projets, une équipe de plus de 15 développeurs sur un projet très complexe d'un point de vue métier, c'est un "break even" au dessus duquel on perd plus en productivité qu'autre chose.

[souviron34]

Oui mais ça c'est une chimére, ou alors sur des métiers simples et des softs simples.
Un intermédiaire, c'est forcément quelqu'un qui a la capacité de comprendre en détail et de traduire.
de la technique vers du non technique --> remontée de contrainte de dev
du métier vers du "non initié" --> remontée de contrainte utilisateur

Un un mec qui a suffisamment de compêtence dans les deux, il a souvent l'intelligence n'est pas de passer sa vie à jouer le go between entre tout le monde mais bien de vendre sa double expertise.

C'est aussi aujourd'hui ce que l'on appelle les AMOA, les business analystes, les experts fonctionnels, enfin pleins de noms barbares, mais souvent, c'est pas vraiment le haut du panier qu'on trouve.

C'est aussi ça les différences entre la beauté des diagrammes et la réalité.

Garulfo t'a répondu, mais je rajouterais un petit quelque chose.

Tu parles d'un domaine particulier, la finance, qui a ouvert les yeux il y a environ 6 ans sur l'importance d'avoir ce type de personnes, et qui du coup en a fait (comme tout mouvement en informatique) un dogme instantané, en y inventant un nouveau sigle (MOA) et soi-disant un nouveau métier, alors qu'ils prennent justement des gens informaticiens ayant un background en finances, ce qui est le contraire même d'une approche basée sur l'ergonomie.

Tu ne devrais pas connaître le domaine pour étudier et faire cracher le besoin, sinon tu es déjà biaisé.Si tu relis ce que j'ai dit, je n'ai pas dit qu'il fallait avoir "suffisament de compétence dans les 2", j'ai dit qu'il fallait être capable de comprendre. C'est tout à fait différent.

Comme d'habitude dans ce genre de mode, les "décideurs" et autres gestionnaires et chefs d'équipes, dès qu'ils ont eu un nouveau "buzz word", l'ont utilisé sans savoir ce que cela recouvrait, et une fois de plus se sont fourvoyés..

Pas nouveau, simplement attristant..

C'est bien de mettre de l'intermédiation partout, mais souvent quand le client dit B, c'est B'' qui arrive aux oreilles du développeur, qui passe des mois à finir.

Et c'est dangereux, parce que finalement toute la connaissance repose sur une personne, et la plupart du temps, ca finit en guéguerre de responsabilités partagées.

Voir ci-dessus.

Normalement la connaissance repose dans un document, accessible à tous, qui contient au minimum le cahier des charges, en général une desciption extrêmement précise (spécification) de ce qu'il y a à faire, sans qu'il y soit précisé aucunement la manière de l'atteindre. Cela peut aussi inclure une copie ou des dessins des écrans.

Un développeur formé aux métier d'un client, c'est du temps, des ressources et donc du pognon gagné.
Et quand je parle de ressource c'est primordial, car passé 15 développeurs, il est impossible de développer correctement du métier complexe.

Comme le dit Garulfo, même si dans le fond je suis d'accord avec toi (pour le succès des projets dans les délais et en respectant ce qui est demandé) , la réalité des gros projets est l'inverse : une personne ressource est bien plus économique et sûr que d'avoir des développeurs "formés" (comment ? dans quelle mesure ? Si ils étaient si bien formés, pourquoi ne changerait-ils pas de boulot ?) , qui, certes auront peut-être une connaissance, mais pas les trucs et ficelles du métier,cela venant avec les formations spécifiques ET l'expérience.

C'est pour cela que dans les bonnes pratiques, nous recommandions d'avoir un utilisateur-expert tout au long du projet, à niveau de responsabilité égale à celle du Chef de Projet, et qui a le dernier mot sur l'implantation d'une fonctionalité.

Y'en a certain qui devraient ouvrir les yeux et se renseigner sur ce qu'est le monde du travail. L'informatique n'est qu'un job comme un autre. Certes on y prend plus son pied quand on aime ça, mais ça reste un boulot : satisfaction du client, livrer un bon produit, et rien à foutre des ouvriers (nous, même si on nous affuble du qualificatif de "cadre").

Je dis qu'aujourd'hui, avec l'outillage, les technos et la complexité des projets, une équipe de plus de 15 développeurs sur un projet très complexe d'un point de vue métier, c'est un "break even" au dessus duquel on perd plus en productivité qu'autre chose.

Voir ci-dessus. Mais dans tous les projets sur lesquels j'ai travaillé depuis plus de 15 ans, que l'équipe fasse 6, 15 ou 100 personnes ne change rien au fait qu'un programeur,aussi doué en communication et apprentissage soit-il, ne sera jamais la source d'une certitude par rapport à un métier autre, même si il vit dans le "milieu du métier" depuis plus de 20 ans.

Ce ne sera jamais l'utilisateur...


Et ça n'a pas changé entre il y a 30 ans et maintenant...

[chaplin]

Y'en a certain qui devraient ouvrir les yeux et se renseigner sur ce qu'est le monde du travail.

Pour aller plus loin dans ce raisonnement, à un niveau supérieur, c'est la stratégie. On fait couler un projet pour en faire un derrière qui réussit. On appelle cela perdre une bataille mais pas la guerre.

[gl]

vous connaissez des ingénieurs en mécanique qui passent eux même sur la fraiseuse ou le tour ? moi pas.

Moi oui et ce n'est pas aussi rare que ça.

Plus sérieusement, si ça n'arrive pas en production, c'est tout à fait possible qu'ils usines eux-même, au moins en parties, les premiers prototypes (et ça reste vrai pour d'autres que la mécanique).

[B.AF]

Oui c'est vrai que chaque secteur a ses spécificités (industrie, finance, aéronautique...)

Donc pour parler de ce que je connais (finance), il est plus ou moins la démonstration constante de l'échec des projets, avec pourtant des resources considérables.

Pourquoi ?
Parce que simplement, la plupart des MOA sont incompêtents car ils s'agit souvent de profils de "rang B".
La réalité fait que les utilisateurs sont peu ou pas disponibles et tributaire du marché, donc ils n'ont pas le temps d'expliquer leur métier.

Donc si tu tombes sur un client qui te dit "je voudrai une fonctionalité qui gére mes substitutions de crédits ainsi que la piste d'audit de la simulation à la réalisation", tu ne peux pas (commercialement et même "pratiquement") demander plus.

Dans cette situation, un MOA est aussi complétement inutile.
Derriére, il y a des propagations importantes, les tests sont très complexes et demandent pour la plupart le même niveau de connaissance que l'utlisateur final.

Effectivement, les projets techniques arrivent à leur fin, mais dès que le projet prend une grosse dimension métier, la plupart des organisations sont paralysées.

E.g encore frais : thétis et la sg, ce projet est un serpent de mer, alors que base camps, moa et chefs de projets partout...et c'est toujours pas fini au out de x années, alors qu'il s'agit au fonds d'un projet fonctionnellement simple.

Malheureusement, la conception ne peut pas être faite par 30 personnes en même temps, avec un dev dans un base camp, avec une moa local etc...

Je sais aujourd'hui par ex que mon équipe aurait fini ce projet en 2 ans, 3 max.

Ca finit souvent avec des SI extrêmements hétérogénes avec 1 soft d'éditeur, 100 tableurs excel / mdb à macro, des micros applications de reporting, des micros applications spécfiques, des softs externes périphériques.

Parce que l'un des problémes de fonds est aussi où localiser la réalisation ?

Et si on considére que le projet est généralement de structurer l'activité, beaucoup d'organisation échouent, pas par manque de technicité, mais par défaut de conception. Plus le projet avance, plus les vraies difficultés se montrent, plus le retard s'accumule et plus le projet dérive vers "des arbitrages" ou des "solutions dégradées" (bref, des grands mots pour dire "on est pas capable de faire, donc on revoit nos ambitions à la baisse)

Parce que la réalité reste entiére :
Si je demande à un développeur de mes créer un moteur de gestion de pile fifo multi instrument, quel développeur peut créer ce modéle sans être capable de fournir l'abstraction nécessaire qui nécessite par définition de connaitre ses instruments.
Sinon ca finit avec la table "obligations", la table "action", la table "stock"
et là.......no comment.

Je persiste et je signe, l'informatique gagnerait à admettre qu le développement n'est pas une tâche sale (moi, j'adore en faire, même si je ne suis plus censé en faire, je le fais, parce que j'aime aussi mettre en pratique avant d'avoir des certitudes), c'est au contraire un travail d'orfévre qui mérite de l'attention.
Et comme je crois fondamentalement et au test driven et domain design, je crois qu'un développeur doit aller chez le client et confronter son travail àvec l'oeil du client, pour progresser, comprendre ce qu'il veut et avancer.

Je ne crois pas aux chefs de projets, aux AMOA, aux consultants en organisation. Si des gens gagnent leur vie là dedans, just fine.
Mais mon métier c'est pas de pondre des docs pour m'abriter dérriére.
Mon métier c'est de pondre des fonctionnalités métiers qui quand elles sont utilisées par des gens du métiers (là encore, l'avis de la MOA , mais rien à péter !) disent "bien vu les gars".
Mon métier, c'est d'assumer que si mon client me choisit, c'est parce qu'on comprend de quoi il parle, qu'on a fait ce qu'il fait, et qu'on l'aidera en plus à descendre l'arbre de conséquences. Ce n'est pas de passer un temps interminable dans powerpoint , excel et project pour expliquer pourquoi l'item 1A et passé devant l'item 1B.

Je sais ce que je vend, pourquoi je le vend, jusqu'où ça va, jusqu'où ca n'ira pas. Et aussi point important, ça permet aussi de connaitre sa marge au moment de la signature.

[souviron34]

Effectivement, les projets techniques arrivent à leur fin, mais dès que le projet prend une grosse dimension métier, la plupart des organisations sont paralysées.

E.g encore frais : thétis et la sg, ce projet est un serpent de mer, alors que base camps, moa et chefs de projets partout...et c'est toujours pas fini au out de x années, alors qu'il s'agit au fonds d'un projet fonctionnellement simple.
....
Et si on considére que le projet est généralement de structurer l'activité, beaucoup d'organisation échouent, pas par manque de technicité, mais par défaut de conception. Plus le projet avance, plus les vraies difficultés se montrent, plus le retard s'accumule et plus le projet dérive vers "des arbitrages" ou des "solutions dégradées" (bref, des grands mots pour dire "on est pas capable de faire, donc on revoit nos ambitions à la baisse)

Tu as pu voir dans d'autres threads que ce n'est pas particulier à la finance, mais que je critique également ouvertement l'usage systémique de "méthodes", "méthodologies" (voir plus bas prochaine réponse) , ou tout autre vocabulaire ou outil (XML par exemple) supplétif à l'appréhension de la réalité de développement..

Les exemples sont foisons dans le monde (de Airbus à Ariane à Intermarché à Carrefour à ..) de développements qui échouent, qui pètent les délais et le budget...

Je persiste et je signe, l'informatique gagnerait à admettre qu le développement n'est pas une tâche sale (moi, j'adore en faire, même si je ne suis plus censé en faire, je le fais, parce que j'aime aussi mettre en pratique avant d'avoir des certitudes), c'est au contraire un travail d'orfévre qui mérite de l'attention.

Je suis d'accord, sauf que je ne parlerais pas d'orfèvre (sauf en certains cas particuliers), mais de manière générale d'artisanat..

Je pense fondamentalement que la grande erreur des méthodes, méthodologies, etc , est de considérer le développement avec des pions humains., remplaçables mais non caractérisés.

Il ne viendrait à l'idée de personne dans les banques de mettre au trading le comptable d'un artisan de quartier (enfin, il y en a quelquues uns qui ont réussi). Il ne viendrait à l'idée de personne dans l'industrie automobile de mettre au design de la chambre de combustion un expert en traitement d'images.. Ni à la banque de se dire qu'avec 100 comptables de quartir elle fera le même boulot qu'avec un seul gars qui sera super spécialisé (c'est bien la raison d'être des traders). Ni à l'industre automobile de se dire qu'avec 100 fraiseurs elle remplacera l'ingénieur chimiste/métallurgiste pour le design de la chambre de combustion..

C'est pourtant ce qui se fait tous les jours dans les équipes informatiques, et qui est soutenu par les "méthodes" et "méthodologies". Toute personne doit y être remplaçable, et n'importe qui est équivalent à n'importe qui d'autre.. Du moment qu'il a un minimum de diplôme ou d'expérience... Ca me fait doucement rigoler quand je vois des offres "expert" ou "sénior" ou "confirmé" avec "de 6 mois à 2 ans d'expérience"...

Dans ce cadre, la notion même d'artisanat, de responsabilité et de maîtrise de son sujet, disparaît..

D'ailleurs, le découpage en cycle de vie et en "phases" etc est strictement copié sur le Taylorisme et les chaînes de fabrication, sauf qu'à mon humble avis ça plante pour une seule et bonne raison : une chaîne de production reproduit un prototype établit en bureau d'études. Un développement informatique est le prototype, l'équipe le bureau d'études. La reproduction est instantanée et ne nécessite rien de particulier.


Tu parlais d'orfèvres. Mais entre le bijoutier vers chez moi et Chaumette, il y a un monde. Entre le gars qui danse à la Star-Ac ou dans la salle polyvalente du coin et Patrick Dupont ou n'importe quel autre danseur de l'Opéra, il y a un monde.

On a vu ce que devenait Apple le jour où Steve Jobs est parti...

Je crois fondamentalement que c'est ce qui manque à l'industrie. Inclure la notion de l'humain, et que si on veut un bon projet, il faut des bons.

Un Directeur Technique m'a dit un jour : "mon défi, c'est de faire quelque chose d'extra-ordinaire avec des gens ordinaires". Je lui avais répondu "tu n'y arriveras pas. Si tu veux faire quelque chose d'extra-ordinaire, il te faut des gens extra-ordinaires". La boîte a fermé 7 mois plus tard..

Je ne crois pas aux chefs de projets, aux AMOA, aux consultants en organisation. Si des gens gagnent leur vie là dedans, just fine.
Mais mon métier c'est pas de pondre des docs pour m'abriter dérriére.
Mon métier c'est de pondre des fonctionnalités métiers qui quand elles sont utilisées par des gens du métiers (là encore, l'avis de la MOA , mais rien à péter !) disent "bien vu les gars".

Là par contre je ne te suis pas.

Il y a plusieurs volets dans un développement, et tout projet qui réussit réussit à cause d'une équipe, pas d'une personne seule.

• Un Chef de Projet est nécessaire. (en dehors de la vision d'ensemble et de l'aspect technique, il y a plein de choses à faire, et de coordination, et de gestion, et de réunions, et de présentations ..)
  
  
• Un AMOA je ne sais pas vraiment ce que c'est, mais quelqu'un du métier est nécessaire.
  
  
• Vraisemblablement aussi des gens issus de milieux (ou de métiers) différents, même si à l'heure actuelle ils font tous de l'informatique. Rien de tel que d'avoir des points de vue différents pour trouver une belle solution à des problèmes..

[smonew]

... faute d'une mauvaise définition du besoin initial :

http://www.01informatique.fr/infrast...ava-php-44117/

[B.AF]

Là par contre je ne te suis pas.

Il y a plusieurs volets dans un développement, et tout projet qui réussit réussit à cause d'une équipe, pas d'une personne seule.

• Un Chef de Projet est nécessaire. (en dehors de la vision d'ensemble et de l'aspect technique, il y a plein de choses à faire, et de coordination, et de gestion, et de réunions, et de présentations ..)
  
  
• Un AMOA je ne sais pas vraiment ce que c'est, mais quelqu'un du métier est nécessaire.
  
• Vraisemblablement aussi des gens issus de milieux (ou de métiers) différents, même si à l'heure actuelle ils font tous de l'informatique. Rien de tel que d'avoir des points de vue différents pour trouver une belle solution à des problèmes..

C'est dans la seconde qu'est l'explication de ma phrase :
La réalité est qu'aujourd'hui dans mon domaine, l'expertise métier n'est pas des ces métiers car il s'agit souvent des profils qui n'ont pas pu faire du métier "pur". Donc on tombe souvent sur des gens 'frustrés', qui passe leur temps à expliquer que les utilisateurs ne comprennent rien à ce qu'ils font et que d'ailleurs à leur place.
Souvent dans ce cas, le projet est utilisé par ces personnes pour se prouver qu'elles auraient pu...

Quelle que soit la méthode, je reste convaincu que l'on peut mettre en place une organisation et une structure, seuls les hommes font le job.

Si les hommes ne sont pas à l'aise dedans, ça ne fonctionne pas.

[Garulfo]

Je dis qu'aujourd'hui, avec l'outillage, les technos et la complexité des projets, une équipe de plus de 15 développeurs sur un projet très complexe d'un point de vue métier, c'est un "break even" au dessus duquel on perd plus en productivité qu'autre chose.

Oui c'est vrai que chaque secteur a ses spécificités (industrie, finance, aéronautique...)

Donc pour parler de ce que je connais (finance), il est plus ou moins la démonstration constante de l'échec des projets, avec pourtant des resources considérables.[...]

Les exemples que je te parle ont tous au moins 50 développeurs. Ils ont tous réussi et dans certain cas, comme MTI avec Meteor, la productivité a été excellente. Tu ne devrais pas généraliser. Je ne parle pas de projet dans lesquelles j'ai travaillé (enfin pas tous) mais de projet que j'ai étudié de l'extérieur parce que je fais de la recherche en GL. Le seul projet que je connais en finance est un échec (London Stock Exchange — TAURUS), la raison étant le manque de méthodologie dans la phase d'Ingénierie des besoins. Le travail a été mal fait. Ceci pourrait donc appuyer ta remarque. Mais vu que ce n'est là qu'une observation superficiel de ma part, je n'en conclurais rien.

[Garulfo]

[...]
Si les hommes ne sont pas à l'aise dedans, ça ne fonctionne pas.

C'est vrai partout en tout d'une certaine manière.

Maintenant en regardant les cas concrets, c'est-à-dire en prenant en compte le fait que ce n'est jamais unanime ce genre de sentiment, les projets où plusieurs développeurs n'étaient pas particulièrement à l'aise et qui ont pourtant très bien fonctionné sont très nombreux. Ils font leurs travails de manière mécanique sans entrain, mais avec sérieux. Et il est rare de trouver des projets où tous le monde est vraiment heureux.

Encore une fois, je peux te citer Meteor. Les développeurs de la partie sécuritaire ont travaillé avec une nouvelle méthodologie. Ils n'étaient pas tous à l'aise loin de là. Et tout à bien fonctionné. C'etait des ingénieurs professionnels quand même. Ils ont appris à s'adapter.

[B.AF]

Le seul projet que je connais en finance est un échec (London Stock Exchange — TAURUS), la raison étant le manque de méthodologie dans la phase d'Ingénierie des besoins. Le travail a été mal fait. Ceci pourrait donc appuyer ta remarque.

Dans mon domaine, c'est très binaire : l'ingénierie des besoins n'existe pas.
La réaction locale est "tu comprends, c'est très bien", "tu ne comprends pas, tu n'as rien à faire dans ce secteur". Je schématise un peu, mais c'est le raisonnement de base.

Si tu prends un travail d'ingénierie tel que meteor, les équipes sont dédiées --> les "métiers" sont là pour ça.

Le boulot d'un gérant de portefeuille c'est pas de faire des specs ou de passer 12H00 à expliquer son travail.

Malheureusement, ce n'est pas un métier que tu apprends sur les bancs de l'école, et encore moins dans un livre.

Jusqu'où définir un besoin ? C'est notre problème au quotidien, jusqu'où est-il jouable de demander une explication ?

"Bonjour, je voudrai avoir une appli simple pour gérer mon book d' ordres actions"
"D'accord, qu'appellez vous un book"
"Bah ma pose quoi!"
"C'est quoi une pose?"
"Ben mes comptes clients..."
"Ah ,comment sont-ils définis..."
"Ben c'est la pose de mon client"
"Oui comment vous identifiez votre client ?"
"Mais on s'en branle, je veux suivre les ordres que je shoote"
"Commebnt vous shootez des ordres alors ?"
"Bah je pose la strat, je sonde des broks, et quand j'ai un bon price c'est good et après je checke mon vwap"
"Vus voulez faire du wap ?"
etc,etc...

N'importe quel sujet à une récursivité dramatique.
Donc tu tombes dans la situation typique où le moa est haït par le métier qui ne comprend pas son utilité (réaction standard : "comment on fait pour organiser des trucs qu'on ne comprend pas ?"), il finit par dire, "démerdez vous, moi c'est pas mon job, vous bossez dans le secteur donc vous connaissez", et quand on va lui dire faut tester il va te dire "J'ai autre chose à foutre que de vérifier si 5 ingénieurs peuvent faire une multiplication".

[souviron34]

Dans mon domaine, c'est très binaire : l'ingénierie des besoins n'existe pas.
La réaction locale est "tu comprends, c'est très bien", "tu ne comprends pas, tu n'as rien à faire dans ce secteur". Je schématise un peu, mais c'est le raisonnement de base.

Voir ce que j'ai dit plus haut

Le boulot d'un gérant de portefeuille c'est pas de faire des specs ou de passer 12H00 à expliquer son travail.

Non ce n'est pas son métier. Mais tant que le dialogue ne permet pas de faire admettre que si il veut un bon outil, il doit participer à sa définition, il n'aura jamais un bon outil pour faire son travail.

Alors peut-être pas lui, mais il doit déléguer quelqu'un qu'il connaît et en qui il a confiance (vraisemblablement quelqu'un qui a 20 ans de boîte et qui soit est monté dans les échelons soit à envie de faire autre chose soit "coach" déjà les nouveaux venus ) .

Jusqu'où définir un besoin ?

Jusqu'au bout

C'est notre problème au quotidien, jusqu'où est-il jouable de demander une explication ?

Jusqu'à ce que tu aies tous les éléments nécessaires...

D'où la nécessité d'avoir quelqu'un du métier...

"Bonjour, je voudrai avoir une appli simple pour gérer mon book d' ordres actions"
"D'accord, qu'appellez vous un book"
"Bah ma pose quoi!"
"C'est quoi une pose?"
"Ben mes comptes clients..."
"Ah ,comment sont-ils définis..."
"Ben c'est la pose de mon client"
"Oui comment vous identifiez votre client ?"
"Mais on s'en branle, je veux suivre les ordres que je shoote"
"Commebnt vous shootez des ordres alors ?"
"Bah je pose la strat, je sonde des broks, et quand j'ai un bon price c'est good et après je checke mon vwap"
"Vus voulez faire du wap ?"
etc,etc...

D'où la nécessité d'avoir quelqu'un qui sache faire cracher "en bon français" ce qui est demandé (voir ergonome et arguments cités dans les autres posts)

Donc tu tombes dans la situation typique où le moa est haït par le métier qui ne comprend pas son utilité (réaction standard : "comment on fait pour organiser des trucs qu'on ne comprend pas ?")

Encore une fois, problème résolu si ce n'est pas un MOA mais une association personne du métier/personne non spécialisée mais technique.

, il finit par dire, "démerdez vous, moi c'est pas mon job, vous bossez dans le secteur donc vous connaissez", et quand on va lui dire faut tester il va te dire "J'ai autre chose à foutre que de vérifier si 5 ingénieurs peuvent faire une multiplication".

Ce en quoi il a raison.

[B.AF]

Voir ce que j'ai dit plus haut


Non ce n'est pas son métier. Mais tant que le dialogue ne permet pas de faire admettre que si il veut un bon outil, il doit participer à sa définition, il n'aura jamais un bon outil pour faire son travail.

Jusqu'au bout
Jusqu'à ce que tu aies tous les éléments nécessaires...
D'où la nécessité d'avoir quelqu'un du métier...

D'où la nécessité d'avoir quelqu'un qui sache faire cracher "en bon français" ce qui est demandé (voir ergonome et arguments cités dans les autres posts)


Encore une fois, problème résolu si ce n'est pas un MOA mais une association personne du métier/personne non spécialisée mais technique.

Ce en quoi il a raison.

Ben voilà tu as mis le doigt sur l'énigme...La science du métier n'est pas le fait de 120 personnes, et celles qui l'ont, si elle voulait faire de la spec, ça se saurait.

Dans l'exemple que je donnai, il n'y a même pas de spec à cracher.
Un développeur en finance qui ne comprend pas la ligne sera malheureux.

[Garulfo]

Dans mon domaine, c'est très binaire : l'ingénierie des besoins n'existe pas. [...]
Si tu prends un travail d'ingénierie tel que meteor, les équipes sont dédiées --> les "métiers" sont là pour ça.[...]

Je suis d'accord avec à peu près tout.
Mais explique moi en quoi cela fait-il que l'ingénieur besoin n'est pas important ? Tu sembles justement soutenir le contraire ! Dans un domaine où les experts ne s'y connaissent pas en informatique et les informaticiens ne connaissent pas bien le métier, c'est le travail des ingénieurs besoins de faire le pont.

Où est le problème ?

Tu ne crois pas quand même que ce que tu cites est propre à la finance ? Ça a toujours été comme ça dans toute les premières fois où l'informatique est entré dans un métier. Et ça a toujours évolué vers du mieux.

[Garulfo]

Ben voilà tu as mis le doigt sur l'énigme...La science du métier n'est pas le fait de 120 personnes, et celles qui l'ont, si elle voulait faire de la spec, ça se saurait.

Dans l'exemple que je donnai, il n'y a même pas de spec à cracher.
Un développeur en finance qui ne comprend pas la ligne sera malheureux.

Il existe toujours des spécification à faire. Je pense que tu n'as pas compris que c'est l'attitude que tu cites qui a mené aux échecs cinglants des grands projets informatique. Et en comprenant ça, les choses se sont améliorés.

Des ingénieurs besoins sont là pour comprendre le domaine et régurgiter la partie nécessaire à ceux qui vont faire la conception. Ça marche dans de nombreuses industries. La finance n'échappe pas à ça. Il y a des programmes spécialisés pour former des personnes qui font justement le pont métier/informatique dans les facultés d'administration en Amérique du nord.

[B.AF]

Je suis d'accord avec à peu près tout.
Mais explique moi en quoi cela fait-il que l'ingénieur besoin n'est pas important ? Tu sembles justement soutenir le contraire ! Dans un domaine où les experts ne s'y connaissent pas en informatique et les informaticiens ne connaissent pas bien le métier, c'est le travail des ingénieurs besoins de faire le pont.

Où est le problème ?

Tu ne crois pas quand même que ce que tu cites est propre à la finance ? Ça a toujours été comme ça dans toute les premières fois où l'informatique est entré dans un métier. Et ça a toujours évolué vers du mieux.

Evidemment, je ne peux pas parler des ecteurs que je ne connais pas ou artificiellement. L'informatique n'est pas nouvelle en finance, elle est même plutôt bien installée.
L'écartement se produit surtout du fait que :
Les besoins métiers ont une complexité croissante
Les technologies ont une complexité croissante.

il y a 15 ans il était possible de connaitre les deux, aujourd'hui, il est impossible de connaitre exhaustivement les deux.

[souviron34]

il y a 15 ans il était possible de connaitre les deux, aujourd'hui, il est impossible de connaitre exhaustivement les deux.

Je re-répète :personne ne demande de connaître exhaustivement les 2. C'est même le contraire.

La personne dont nous parlons , Garulfo et moi, n'est ni un expert technique ni un expert métier (financier en l'occurence). Et ne doit surtout pas l'être.

Il doit juste comprendre "suffisamment" pour, en discutant avec les experts métier, les pousser dans leurs retranchements mentaux pour leur faire cracher toute leur connaissance ou leurs besoins (sans les comprendre. juste comprendre la démarche). (ce qui se fait par écouter, observer, voire filmer ou enregistrer, puis entretien serré, puis définition petit à petit)
.

Cependant, il doit avoir une bonne base (sans être expert) technique, pour savoir ce que peut ou ne peut pas faire l'informatique (au sens large. Pas tel ou tel langage). Pour deux raisons :

la première est, dans la définition des besoins ci-dessus, il doit pouvoir inclure dans la discussion certaines limites techniques (avoir toutes les transactions du monde en mémoire à t donné par exemple est impossible), mais aussi proposer des traitements automatiques là où cela pourrait être utile.

La seconde est d'une part dans la discussion avec l'expert métier il doit suivre un découpage (une arborescence, un ordre) logique et pointer du doigt les incohérences éventuelles entre ce qui est dit et la technique (par exemple "on ne peut pas faire ça à ce moment, tu n'as pas encore l'écran contenant ça"), et d'autre part dans l'écriture même de la spécification. Il doit se garder d'être trop technique et orienté. Son expérience technique lui sert juste à écrire avec des mots compris par les informaticiens ce qu'il vient de définir avec l'expert, mais aussi à le présenter d'une manière logique pour l'équipe, mais surtout ne pas orienter la décision d'implémentation ou le choix du langage ou de l'architecture des BD ou autres. Chacun son métier.

Le sien est purement de soutirer l'information la plus exacte et utile possible , dans le bon ordre et avec les bonnes hiérarchies, entrées, sorties, et conséquences, et le présenter à l'équipe de développement sous une forme utilisable, mais qui devra être le guide et "l'architecture de base".

Ce qu'il est censé produire est en fait grosso modo ce qui auparavant s'appelait "la spécification fonctionnelle".

[Garulfo]

[...]
il y a 15 ans il était possible de connaitre les deux, aujourd'hui, il est impossible de connaitre exhaustivement les deux.

Je re-répète :personne ne demande de connaître exhaustivement les 2. C'est même le contraire.

La personne dont nous parlons , Garulfo et moi, n'est ni un expert technique ni un expert métier (financier en l'occurence). Et ne doit surtout pas l'être.[...]

C'est là effectivement qu'il semble y avoir un malentendu. L'ingénieur besoins n'a pas le temps d'être un expert métier, et en général il n'est pas un expert de la conception ou d'une bébèlle technique quelconque.

C'est ça force. Si ton ingénieur besoins penchent trop d'un bord ou l'autre, il devient inutile en fait. Il a pour but de produire des documents qui serviront d'interface entre les deux parties-prenantes, comme le souligne intelligemment Bray dans son livre.

C'est justement la complexité de l'informatique et des problèmes auxquels l'informatique s'attaque qu'il impose ce genre de personnes dans un projet.

[B.AF]

C'est là effectivement qu'il semble y avoir un malentendu. L'ingénieur besoins n'a pas le temps d'être un expert métier, et en général il n'est pas un expert de la conception ou d'une bébèlle technique quelconque.

C'est ça force. Si ton ingénieur besoins penchent trop d'un bord ou l'autre, il devient inutile en fait. Il a pour but de produire des documents qui serviront d'interface entre les deux parties-prenantes, comme le souligne intelligemment Bray dans son livre.

C'est justement la complexité de l'informatique et des problèmes auxquels l'informatique s'attaque qu'il impose ce genre de personnes dans un projet.

Non mais ça en théorie c'est génial, maintenant, je ne vais pas vendre 150 à client sous prétexte que la personne qui analyse le besoin à besoin de 50 là où un expert pourrait passer 5 et où justement on pourrait passer beaucoup plus de temps en conception.

La réalité est qu'un client ne veut pas payer pour "former" quelqu'un.
Et on ne peut pas avoi 100 J de charges pour un revenu de 50 J uniquement au titre de la méthode.

C'est ça aussi la différence fondamentale entre la SSII et l'éditeur de soft, c'est que la marge d'un éditeur de soft, elle se situe dans sa valeur ajouté, pas dans la différence salaire / prix jour.

La valeur ajoutée d'un éditeur de soft, c'est une connaissance globale d'un métier (ou une niche métier serait plus juste aujourd'hui) et sa capacité à adresser une somme de besoins par capacité à extraire ce qui est du core et ce qui est du satellite. Et ce discernement ne se fait pas sans expertise.

Les erreurs de conception dans le soft ça coute des centaines de milliers d'euro dans certains cas.

C'est aussi ce qui gére le produit au quotidient : la capacité à comprendre rapidement les demandes DES clientS et de pouvoir les rejoindre de telle façon à éviter les pertes de consistence.

Effectivement, les dev internes ou les SSI n'ont pas cette contrainte, puisqu'elle s'inscrive dans une logique spécifique et que finalement, ils ne vendent pas (encore que...) d'expertise, mais une méthodo pour atteindre le résultat.

C'est là que nos visions divergent, même si j'aimerai qu'en réalité vous ayez raison et que l'on puisse procéder ainsi.

Le défaut de l'informatique est qu'elle ne considére pas le client.
Au mieux l'utilisateur, mais pas le client.

Que l'utilisateur soit content soit, mais ca ne sert à rien si on fait des pertes.

Le meileur processus projet, c'est celui qui te donne la pérennité applicative, la confiance des clients, et des prix de vente supérieurs à tes coûts de production.

Donc utiliser des "ingénieurs besoins" "néophyte", oui je l'ai fait, non je n'y crois pas parce que :
Ca coute cher (faut le payer, et le client ne veut pas payer parce qu'il n'est pas mis en confiance)
Ca plombe le projet (le temps de conception est réduit parce que la phase d'analyse est trop importante)
Ca provoque des contaminations (bah oui, dans un soft il peut y avoir des dépendances et des impacts fonctionnels et c'est précisemment là que l'expertise montre son importance)
Ca coute cher en tests parce qu'il faut aller chercher les tests ailleurs, les penser, les faire réaliser...

Et au final, le client discute la facture parce que le résultat n'est pas foudroyant. (Je veux dire que le temps de réalisation a tendance à ternir la résultat final)

Moi je veux bien échanger des documents que tout le monde prenne ses garanties, mais la sur-documentation ne sert à rien. Et le document n'a de sens que dans ce qu'il contient. Pas dans le fait qu'il existe.

Il vaut même mieux parfois un A3 avec une combinatoire des cas qu'un document de 20 pages.

La méthode n'a de sens et d'apport que dans une organisation qui peut s'en passer sans perdre en qualité. Essayer de rentrer des méthodes aux forceps dans des organisations, ça ne fonctionne pas, parce qu'avant d'avoir la méthode, il faut l'adhésion des gens à cette méthode, et qu'il y ait le réservoir humain pour réaliser cette méthode.

J'ai des clients qui veulent du cycle en V, on fait du cycle en V. D'autres veulent de l'itératif, on fait de l'itératif. Mais c'est la façade client.
On fait du Domain DD et du Test DD, par rapport à nos méthodes, les responsabilités sont identifiées sur des personnes qui peuvent porter cette responsabilité, et le reporting projet, n'est au final qu'un re-formatage à destination du client.

[souviron34]

je crois que tu te méprends sur ce qu'on dit...

On n'a pas parlé de "former"....

Et c'est bizarre, mais des boîtes comme Philips, At&T, EDF, EADS, Boeing, ... sont-elles des philantropes ? Non..

Pourtant elles ont adopté ce genre de pratiques...

Parce que, sur le long terme, c'est beaucoup moins cher, et ça amène à de nouveaux produits, concepts, etc, et qu'en plus ça réduit les coûts de formation, justement, et augmente la satisfaction des clients, et donc prépare le terrain pour de futurs contrats....

Tu n'as pas vraiment lu le fond de ce que nous avons posté. Personne ne parle d'"ingénieur besoin néophyte". On parle au contraire de gens avec beaucoup d'expérience, mais variée et non spécialisée...

Les temps de conception (contrairement à ton affirmation) sont réduits, car les découpages sont clairs et ne sont jamais remis en cause (bonne analyse), et que de plus la présence continue d'un expert-ressource corrige avant qu'une dérive trop importante (par rapport à la fonctionalité et par rapport au soft) ne soit apparue.

C'est étrange que ça puisse marcher pour tous les domaines industriels mais pas pour la finance...


Pour exemple :

• l'hiver dernier j'étais dans une boîte qui fait les systèmes d'entraînement pour les contrôleurs du ciel. 3 pliotes (2 militaires et un civil) et 5 contrôleurs étaient à plein temps dans la boîte. Non seulement ils ajustaient, définissaient, raffinaient les demandes, mais nous les consultions environ 1 fois par jour, même pour la correction d'un bug.. Cependant, chaque décision était prise après réunion entre le Chef d'Equipe (qui en l'occurence avait été militaire aussi, mais pas pilote, et qui après avait fait informatique), nous, et les pilotes/contrôleurs. Il n'y avait donc pas d"Ingénieur-besoin" indépendant, mais la présence continue des utilisateurs du métier assure le fait que ce soft est classé 1er du monde par les contrôleurs de tous les pays...
  
  
• Deuxième exemple : une équipe de 60 personnes travaillant pendant 14 ans pour faire un logiciel de Dossier Médical Informatisé (DMP en France), avec une structure traditionnelle (cycle en V, découpage tayloriste du travail) et une approche "traditionnelle" : analyse du besoin au début (par des gens de l'équipe), puis définition du détail de la fonctionalité ((et écriture des specs) par les analystes. Résultat au bout de 14 ans : grève des médecins et infirmières pour ne même pas tester le soft tellement c'était pourri. J'arrive dans cette équipe en extérieur, en tant que "consultant ergonomie", je m'associe avec un médecin reconnu par ses pairs (élu au Conseil de l'Ordre), je monte une petite équipe, et en moins d'un an on présente un produit qui, même non fini, est non seulement classé premier lors de salons internationaux, mais que les mêmes médecoins qui faisaient grève un an avant veullent acheter directement... Et pourtant je n'étais pas médecin, et je faisais que découvrir Delphi. Sauf que je partageais la position de "Chef d'équipe" avec le médecin.

Dans les 2 cas, il y a un certain investissement de base (les salaires), mais le gain est tellement gigantesque que cela vaut la peine...