Discussion :

[pcmac]

Bonjour à tous,

Ingénieur généraliste, je travaille depuis 5 ans chez Bouygues. Quotidiennement, je participe à des projets, je rencontre des sous-traitants, je fais des offres. Pour résumer j'ai l'occasion de rencontrer des gens et d'être en contact avec un client. Je songe à changer de direction et à faire de l'AMOA (un ami en fait et le rapport salaire/temps de travail semble être excellent), mais je n'ai aucune expérience en informatique (toutes les offres avec les mots java, j2e etc sont complètement abstraites pour moi).

Avant de prendre une décision (il n'y a pas que le salaire dans la vie) je voudrais en savoir plus sur les métier de l'AMOA pour savoir concrètement en quoi cela consiste. J'imagine en effet qu'un consultant AMOA va chez le client afin de comprendre son besoin qu'il traduit ensuite dans un cahier des charges. Il "benne" alors le cahier des charges à une équipe de spécialistes (MOE) dont le rôle est de taper du code (enfin je suppose). Ensuite il y a une période de test (j'imagine qu'on "appuie" un peu sur tous les boutons, voir si ca fonctionne bien...). On rend alors le projet au client.

Je suis désolé pour le côté simpliste de la description, mais je ne m'y connait pas de trop.
Est-ce ca ou suis-je à côté de la plaque ?

Pourriez-vous décrire vos missions ? concrètement ? ainsi que les horaires ?

Merci par avance

[Invité]

...dont le rôle est de taper du code (enfin je suppose).

désolé pour le côté simpliste de la description]

Tu vas te faire plein de copains ici

[pcmac]

Rhooooo j'ai bien precise que je m'y connaissais pas et que je m'excusais a l'avance :-)

C'est comme si vous me disiez que mon metier c'etait de couler du beton hahaha

[Invité]

Haha oui c'est vrai !

Nan t'inquiète je disais juste comme ça ! En plus, malheureusement je ne peux pas répondre à ta question... Dans le genre commentaire qui sert à rien...

[Saverok]

Je vais prendre un peu de temps pour t'expliquer un peu ce job
Pour commencer, connaître la techno ne sert à rien
Par contre, il se doit d'avoir les qualités suivantes :
- sens de l'écoute
- sens de la synthèse
- curiosité
- modélisation ==> le BPM (Business Process Management) est un énorme plus et c'est la grande tendance du moment

Le job d'un AMOA est de comprendre le job de son client :
- qu'est ce qu'il fait
- comment il le fait
- pourquoi il le fait
Ensuite, comprendre son besoin et comment celui-ci s'articule autour de son activité
Pour finir, mettre cela par écrit de la façon la plus claire et synthétique possible ==> partie la plus complexe de ce travail, à mon sens
En effet, la plupart de gens ont beaucoup de mal à prendre du recul sur leur travail
Ils ont tendance à la voir plus complexe qu'il ne l'est ou encore, à l'opposé, trop simple (en oubliant des étapes qui leur paraissent évidente car ils les font "sans réfléchir")
Le hic, c'est que c'est souvent un mélange des 2 en fonction des tâches.

Ensuite, une fois les dev effectués, il y a le contrôle par les tests
Et là encore, c'est un vrai job qui nécessite de la méthode (écriture des cas de tests, maîtrise des outils, etc.).

Pour ce qui est du salaire, faut pas s'attendre à des miracles
Et puis, ça dépend de tellement de chose qu'il n'y a pas de norme là dedans
Quoiqu'il arrive, si tu cherches un boulot de planqué, passe ton chemin

[Glutinus]

A ceci j'ajouterai qu'il peut avoir d'autres tâches comme

- Une idée d'architecture de process
- En plus de la rédaction du cahier de tests, il peut aussi en venir à le dérouler. Donc tout simplement lancer l'appli, rentrer une valeur. Des fois c'est pensé bêtement "je rentre A / j'appuie sur OK / je regarde si c'est bon", des fois plus finement avec des test imbriqués.
- L'AMOA peut être en charge de former les utilisateurs au nouveau produit et les accompagner sur la migration de l'outil. Et des fois utiliser le produit à la demande de l'utilisateur pour faire le boulot à leur place parce que le produit est trop complexe pour eux.
Exemple : le projet est la mise en place d'un outil de reporting en mode bac à sable, le but est que l'utilisateur puisse faire ses camemberts et ses tableaux de manière autonome.
Une fois le projet fait et tous les objets mis à disposition, les utilisateurs ne comprennent rien à l'interface qu'on leur a promis de simple, et demandent "en fait je voudrai un camembert du Chiffres d'Affaires réparti par trimestre, uniquement sur les clientes de 25 à 35 ans", et c'est l'AMOA qui s'en occupe (et qui peut déléguer aux développeurs parce qu'ils ne maitrisent pas non plus l'outil...)


Bref, le métier d'AMOA peut être un affreux fourre-tout. Tout comme le métier de MOE au final.

[eulbobo]

Sur ce genre de poste, les qualité principales sont
- la communication
- la communication
- l'organisation
- la communication
J'ai dit la communication en qualité principale?

Une fois le projet fait et tous les objets mis à disposition, les utilisateurs ne comprennent rien à l'interface qu'on leur a promis de simple, et demandent "en fait je voudrai un camembert du Chiffres d'Affaires réparti par trimestre, uniquement sur les clientes de 25 à 35 ans", et c'est l'AMOA qui s'en occupe (et qui peut déléguer aux développeurs parce qu'ils ne maitrisent pas non plus l'outil...)

Perso, j'ai poussé le truc plus loin et j'allais voir les utilisateurs avec des maquettes AVANT de faire les specs, pour avoir plusieurs avis et... Mon dieu... Ne me tapez pas... Pour comprendre comment les gens travaillaient et voir de quoi ils avaient réellement besoin dans leur quotidien... Histoire que ce qu'on leur met à disposition leur soit utile et qu'ils l'utilisent !

Le job d'un AMOA est de comprendre le job de son client :
- qu'est ce qu'il fait
- comment il le fait
- pourquoi il le fait

J'ajouterai qu'il faut être apte à comprendre ce que veut réellement le client qui va avoir à tendance à t'expliquer ce qu'il veut comme étant le résultat de sa propre réflexion. Or dans 90% du temps, le client n'est pas apte à voir quelle sera la BONNE solution pour répondre à son besoin, et il te présentera son besoin sous la forme "Je veux ça comme ça qui fait ça et ça".
Ton boulot, c'est de lui demander "Pour quoi faire? Que voulez-vous faire? De quoi voulez-vous partir et que voulez-vous obtenir au final?", bref, repartir à la base du travail du client (voir des utilisateurs) afin de déterminer ce qui sera utilisable tout en répondant au besoin !

Et il faut aussi essayer de descendre au plus bas dans les utilisateurs : souvent les chefs ont envie que leur utilisateurs puissent répondre à un besoin, il ne faut pas s'arrêter à la définition du besoin donné par les chef, mais aussi voir avec ceux qui vont l'utiliser.



Après, dans l'expérience personnelle, je ne te cache pas que connaitre la technique aide BEAUCOUP à la qualité : tu peux faire des audits de code en amont et tout de suite esquiver des bugs qui seront bloquants en lisant le code (s'il est bien fait)

[Glutinus]

Sur ce genre de poste, les qualité principales sont
- la communication
- la communication
- l'organisation
- la communication
J'ai dit la communication en qualité principale?

Je dirai bien que la communication est une des qualités principale dans à peu près n'importe quel boulot à partir du moment qu'on bosse pas tout seul... mais oui je confirme, il faut quand même avoir beaucoup de communication pour être AMOA, pour faire parler le client et être sûr qu'on est en phase entre ce qu'il veut, ce qu'il veut dire, ce qu'il dit réellement, ce qu'il pense, ce qu'il a compris et ce qui va être produit.

Perso, j'ai poussé le truc plus loin et j'allais voir les utilisateurs avec des maquettes AVANT de faire les specs, pour avoir plusieurs avis et... Mon dieu... Ne me tapez pas... Pour comprendre comment les gens travaillaient et voir de quoi ils avaient réellement besoin dans leur quotidien... Histoire que ce qu'on leur met à disposition leur soit utile et qu'ils l'utilisent !

HS - les personnes qui recherchent des infos pour l'AMOA, je vous déconseille de lire ce qui suit pour éviter d'être embrouillé

De manière générale, je ne peux que conseiller à un développeur, DBA, architecte technique etc. d'avoir une idée fonctionnelle et métier de sur quoi il travaille. Je suis adepte du "science sans conscience n'est que ruine de l'âme", on ne peut pas rendre un bon produit si on ne comprend pas un minimum sa finalité mais :

1/ on peut tomber sur des gars à la MOE bornés et sans curiosité et qui ne veulent pas essayer de comprendre le métier - au même titre qu'il y a des utilisateurs qui ne veulent pas comprendre juste la périphérie d'un projet informatique

2/ dans certaines structures, les process sont tellement forts qu'on l'en empêche la MOE d'en savoir plus sur le fonctionnel ou le métier... pour mieux dissimuler l'incompétence, un travail de planqué, facturé le plus longtemps possible ou garder de la chevrotine sous le coude si jamais on veut tirer à boulets rouges - et quand le mec est méchant, c'est les quatre à la fois.

Voir l'exemple dans une expérience que j'ai vécu chapitre validation fonctionnelle.

J'ajouterai qu'il faut être apte à comprendre ce que veut réellement le client qui va avoir à tendance à t'expliquer ce qu'il veut comme étant le résultat de sa propre réflexion. Or dans 90% du temps, le client n'est pas apte à voir quelle sera la BONNE solution pour répondre à son besoin, et il te présentera son besoin sous la forme "Je veux ça comme ça qui fait ça et ça".
Ton boulot, c'est de lui demander "Pour quoi faire? Que voulez-vous faire? De quoi voulez-vous partir et que voulez-vous obtenir au final?", bref, repartir à la base du travail du client (voir des utilisateurs) afin de déterminer ce qui sera utilisable tout en répondant au besoin !

Tout à fait. Et c'est compliqué de "challenger" l'utilisateur (anglicisme bien aimé des commerciaux...), il faut comprendre déjà comment il fonctionne dans sa tête pour être sûr d'avoir toutes les clés. Car des fois ça peut pas mal changer l'architecture d'un projet.

[Saverok]

Sur ce genre de poste, les qualité principales sont
- la communication
- la communication
- l'organisation
- la communication
J'ai dit la communication en qualité principale?

Tout à fait
Je n'ai pas assez insister sur ce point dans mon post
L'AMOA est au carrefour de tous les acteurs du projets et il se doit de savoir comprendre et se faire comprendre de tout le monde
Bref, savoir adapter son discours en fonction de son interlocuteur est primordiale et au cœur de cette fonction.