Qu'est-ce que l'AMOA ?

La 1ère question en entreprise est de définir les missions, et ce qui est attendu pour chaque poste.
Il y a tout un sujet sur les fiches de mission, mais ça me parait très important d'être au clair là dessus.
Sur ces fiches, il est bien de définir les prérequis minimum pour assurer le poste, et les must have.

Ensuite, il faut s'assurer que les personnes que l'on met sur un poste colle bien à cette fiche.
ET que les missions qu'on lui donne collent également.

On ne doit pas mettre une personne sur un poste si elle ne coche pas les attendus minimum sur ce même poste. Seule exception, une personne avec un potentiel important, mais dans ce cas, on prévoit un accompagnement sur mesure.

Si la personne a une réelle compétence, qui peut avoir une valeur pour l'entreprise, mais qu'elle ne rentre pas dans une définition de fonction déjà existante dans l'entreprise, il faut créer une nouvelle fiche de mission.
Dans l'exemple donné par DevAndOps, on est peut être plus sur du PMO ou Assistant CdP. Peut être faut-il aller dans ce sens.

Promouvoir une personne sur un poste qu'elle ne maîtrise pas et pour lequel elle n'a aucune appétence ne sera bénéfique ni pour la personne elle même, ni pour l'entreprise.
Ca peut rejoindre la discussion sur les grilles salariales (https://www.free-work.com/fr/tech-it/forum/t/grille-salariale-formation-puis-demission). Il faut trouver autre chose pour promouvoir les personnes.

2 exemples vécus sur un sujet similaire :

• Une PME qui marche bien et qui grossit. On veut "récompenser" les développeurs internes salariés. Pour se faire, on les promeut à des postes de chef de projet. Résultat : C'est une catastrophe. La gestion de projet n'a pas grand chose à voir avec le développement. Un bon dev ne sera pas forcément un bon CdP. Pire, ces personnes sont en difficultés car pas ou peu formées. Elles ne font plus ce qu'elles aimaient (développer) et sont prise à partie car gère pas ou mal les projets qui leurs sont confiés.

• Dans une grande structure, tous les postes sont surévalués pour rentrer dans les grilles. Le tarif d'un AMOA étant tellement faible, on le met dans une case CdP. Mais c'est complètement bâtard, car c'est bien un poste d'AMOA. Plus personne n'y comprend rien. Et sur un projet, il y a des réunions avec un CdP MOA, un CdP AMOA, un CdP technique, un CdP MOE, un CdP intégrateur. En gros, 5 CdP pour un même projet. On marche sur la tête.

ça ressemble à des AMOA qui font de la PMO et pas de la Business Analysis... c'est dommage par ce que personne ne fait l'accompagnement transverse, du coup...

Un AMOA n'a pas pour seul rôle de faire le passe plat entre le métier et la technique.

En phase amont, il doit être capable de challenger le besoin, afin que le projet soit réaliste. Ceci nécessite d'être emblée capable d'estimer un coût dès que le métier vous formule une demande. C'est la partie qui est peut-être la plus compliquée sur le plan "politique" dans certaines missions, surtout lorsqu'on a été vendu comme un simple exécutant, voir un fusible.

Ensuite, il doit produire des livrables qui ne se contentent pas de réécrire le besoin, mais de proposer une solution assez détaillée pour débuter les développements (nature et contenu des flux, règles de gestion précises associées aux écrans, algorithme écrit en vrai pseudo code et pas en charabia, paramétrage des domaines de valeurs, voir même règles de reprise en cas d'incident). Pour cela, mieux vaut avoir déjà développé.

Enfin, tout ça c'est 20 à 50% du temps de travail d'un AMOA. Le reste va passer en RUN, support aux équipes de développement, suivi de la recette, gestion des demandes ponctuelles ...

Maintenant au niveau du marché, j'ai l'impression qu'il y a énormément de candidats aujourd'hui par rapport à la demande. Cela est sans doute lié à la pyramide des âges (beaucoup se sont reconvertis dans cette voie depuis une quinzaine d'années, et forcément on les retrouve aujourd'hui), et au fait que les jeunes diplômés qui sortent de bonnes écoles ne commencent plus leur carrière comme développeur.

(DevAndOps) => Depuis la valorisation assez forte des AMOA, beaucoup d'entre eux sont partis pour vendre leurs services aux plus offrants

Cette phrase est amusante, car pendant plusieurs années, beaucoup de mes confrères développeurs se demandaient pourquoi je voulais basculer MOA. Personnellement, je pense que je suis un développeur correct, un concepteur OK et surtout je m'intéresse beaucoup au métier des clients que je rejoins. Mes collègues développeurs ne voient que des chaines de caractères et des nombres à virgule, mais je trouve aussi important de comprendre ce pourquoi on travaille, pour prendre les bonnes décisions (j'y reviens en-dessous).

Pour eux, les AMOAs deviendront inutiles à terme dans les projets avec toutes nouvelles méthodologies, DevOps et/ou Agile par exemple. Il suffit de regarder le positionnement d'un AMOA sur une méthodologie SCRUM par exemple, pour beaucoup il se rapproche d'un Proxy Product Owner ; et beaucoup, dans la méthodologie Agile, estiment que ce rôle n'auraient pas lieu d'être (qu'il est juste là pour héberger les BA / AMOA).

Comme tu le dis, c'est une cellule un peu bâtarde car, au lieu de valoriser l'aspect que certains AMOAs sont très techniques (ce qui permet d'être plus souple à la discussion avec la MOE, d'assister également à l'architecture logicielle, à la conception d'un modèle) et d'autres plus fonctionnels, ce qui permet de discuter avec les utilisateurs et de mieux comprendre les enjeux, on les voit souvent par leurs mauvais penchants : les utilisateurs les trouvent trop techniques, et la MOE estiment qu'ils ne comprennent pas le métier.

Un des problèmes est qu'il existe aucune formation, du moins en sortie de bac. C'est donc un métier que tu apprends sur le tas et pour cause : cela peut dépendre des contextes techniques et fonctionnels. J'ai beaucoup bossé dans le décisionnel / DATA / SGBD côté techniques et les banques côté fonctionnel. Je connais les spécificités, les difficultés, et les politiques de chaque côté. Mais je n'aurai pas pu apprendre. Maintenant, est-ce que j'ai envie de faire par exemple de la banque / nouvelle techno, ou de la Data / industrie ? Il y a un des deux pendants pour lesquels je serai moins bon, et qu'il faudrait que j'apprenne.

(Paul92) En phase amont, il doit être capable de challenger le besoin, afin que le projet soit réaliste.

C'est extrêmement important, surtout de bien comprendre. Je vais donner un exemple précis. Je bossais en tant que développeur sur un entrepôt de données et une des contraintes que voulait le chef de projet était de pouvoir bloquer l'alimentation. J'ai demandé "combien de temps ?", il n'avait aucune idée. Le développeur qui était parti sur l'architecture a proposé une solution, pour faire d'un seule code tous les calculs intermédiaires, qui était une véritable usine à gaz, et qui s'est avérée catastrophique. Moi de mon côté, j'ai proposé de faire un calcul d'un jour comptable le plus court possible, et de faire une astreinte s'il fallait alimenter par exemple 10 jours d'affilée.

Mais pour que ma solution soit bonne, il fallait une contrainte : si "bloquer plusieurs jours signifiait" bloquer 7 jours ou bloquer 40 jours.

Au final, à ma sortie de projet, je suis allé voir les utilisateurs (la comptabilité), chose que m'a interdite pour raison politique le chef de projet ("faut pas les déranger..."), qui m'ont accueilli avec grand sourire. Ils n'avaient aucune visibilité sur notre projet et étaient contents d'avoir des nouvelles. Quand je leur ai demandé combien de jours ils bloquaient pour pouvoir faire leur vérification, ils ont été surpris. "Mais ton chef de projet est au courant... Chaque année on bloque la prod 3 jours !!!"

Au final, on aurait très bien pu appliquer ma solution que celle de mon collègue qui a fait une usine à gaz. D'ailleurs, il s'est barré la veille de la mise en prod (freelance comme le reste de la mission), sans aucune doc, et derrière personne ne voulait déconstruire ce qu'il avait fait. Je pense qu'il s'est servi de ce client comme d'un laboratoire, pour revenir ensuite chez son ancien client... pour confirmer qu'il n'était pas capable d'alimenter.

(DevAndOps) => Depuis la valorisation assez forte des AMOA, beaucoup d'entre eux sont partis pour vendre leurs services aux plus offrants. Et quelquefois, nous avons promus des personnels, sans réelle compétence ni sur le métier, ni sur la technique, au titre d'AMOA. La seule compétence qu'ils ont, c'est le cycle projet : Demande d'engagement, passage dans les instances projets, GO/NO GO, etc.....

Je le constate aussi. Ensuite, on peut prendre des personnes motivées, aptes à apprendre. Mais beaucoup sont postionnés là tels quels, comme s'ils connaissaient déjà la méthodologie alors que cela s'apprend à terme.

Ce qui me hérisse le poil, c'est qu'on prend souvent pour de la MOA ou de l'AMOA fonctionnelle des jeunes diplômés chez les gros cabinets de consulting type Big 4, bien facturés, mais qui n'ont jamais bossé de leur vie en IT. Très vite le projet part en vrille parce qu'ils finissent par enterrer les squelettes sous les tapies et temporiser le temps qu'on se rende compte qu'ils sont inutiles ( et souvent, après plusieurs mois, on ne les vire pas car ce serait un aveu de faiblesse de l'avoir gardé si longtemps)

(Droopyann) => Promouvoir une personne sur un poste qu'elle ne maîtrise pas et pour lequel elle n'a aucune appétence ne sera bénéfique ni pour la personne elle même, ni pour l'entreprise.

Le fameux théorème de Peters / Dilbert. Je suis déjà arrivé chez un client, ils venaient de promouvoir quelqu'un, par ancienneté, au rôle de chef de projet. Il y a bossé 2 ans à ce poste puis est revenu à son poste précédent, qui correspondait plutôt à une mise au placard. En même temps, il ne gérait absolument rien. Il était venu une semaine avant la remise d'un fichier règlementaire annuel pour me dire qu'il y avait des nouvelles demandes du régulateur. Il avait ça sous le coude depuis l'année précédente, mais s'est dit que la bonne idée était d'attendre la veille. Ensuite, étant donné qu'il n'avait aucune compétence fonctionnelle et que la cellule MOA non plus (comme dit plus haut, des petits jeunes catapultés), j'ai dû me retrousser les manches et faire aussi bien l'analyse business que les développements, la gestion du planning (enfin... sur 5 jours c'était vite réglé, mais quand même, même les PV de validation il ne voulait les signer).