Discussion :

[TacosPlease]

Bonjour,

Il y a environ 2 ans et demi j'ai commencé à me poser des questions sur l'avenir de mon métier de testeur comme vous pouvez voir dans ce topic que j'avais ouvert il y a quelques années : https://www.developpez.net/forums/d1...eur-recetteur/

Pendant ce temps là j'ai continué à évoluer un peu et aujourd'hui je me rends compte que je commence à saturer pour tout ce qui concerne la technique.

Dans mon entourage j'entends souvent parler du passage de testeur vers AMOA/Business Analyst, mais j'ai pas mal de doutes concernant la compatibilité par rapport à mon profil.
Finalement ce n'est pas parce qu'on passe coté AMOA qu'on s'éloigne de la technique non ?

A part cette piste, je n'ai pas énormément d'idées. Voici les 2 autres que j'ai à l'esprit actuellement :

• Chargé de recrutement IT : pourquoi pas mais j'ai l'impression que c'est un métier très orienté féminin où on ne recrute pas forcément les gens pour leurs compétences RH ou IT

• Business manager (en gros commercial) : c'est peut-être une piste à creuser même si j'ai des doutes concernant le nombre de boites qui accepteraient quelqu'un qui veut se reconvertir à ce point. Peut-être que postuler dans une SSII faciliterait la passerelle vu que c'est toujours dans le domaine de l'IT ?

Si vous avez d'autres idées je suis preneur.

[Carhiboux]

Salut,

ha ben si, normalement AMOA (ou MOA tout court) tu n'es plus dans la technique. Tu es dans le fonctionnel .

Tu définis un besoin, écrit les règles, peu importe comment ces règles sont implémentées par les développeurs, ce n'est pas ton soucis.

[Glutinus]

Dans la plupart de mes missions, début 2010, les MOA étaient ceux qui rédigeaient les specs et recueillaient le client, tandis que les AMOA ne faisaient que dérouler le cahier de recette, et donc, faire les tests (plus ou moins bêtement)

[Ekolamar]

Salut,

ha ben si, normalement AMOA (ou MOA tout court) tu n'es plus dans la technique. Tu es dans le fonctionnel .

Tu définis un besoin, écrit les règles, peu importe comment ces règles sont implémentées par les développeurs, ce n'est pas ton soucis.

Si l'on voulait respecter la nomenclature :

MOA (Maitre d'Ouvrage) : Il demande de répondre à des besoins fonctionnelles (que l'appli marche, que les utilisateurs soient contents, qu'on puisse faire telle ou telle chose, que telle donnée avec telle donnée donne X ou Y etc.).
MOE (Maitre d'Oeuvre) : Il met en place la solution technique (architecture, infrastructure, développement, choix du langage etc.).
L'AMOA (Aide à la Maitre d'Ouvrage) : Il sert à "faciliter" la communication entre la MOA et la MOE et que ainsi, la MOE comprenne bien les besoins de la MOA et que la MAO comprenne bien les limitations de la MOE (coût, délai, qualité).

Pour prendre un exemple simple (et forcément faux mais bon):
MOA : "Nous voulons une application qui prends tout notre historique pour en sortir des tendances de croissance pour nos investisseurs"
MOE : "Très bien, comment sont vos données ? Quelle quantité ? Quelle période en arrière ? Combien d'année de projection ? Quelle format de présentation ? Quelle sécurité pour les données ?"
MOA : "Heu..."
AMOA : "nous allons discuter ensemble et je vais essayer d'adapter, vulgariser et synthétiser les échanges pour que la MOE ait les bons éléments"

Selon moi l'AMOA est bien technique, il doit comprendre les "enjeux" des choix de telle ou telle techno pour le respect des exigences fonctionnelles et le faire valider. Si il n'est pas technique, ce n'est pas un AMOA mais un MOA (selon moi). Après il y a aussi l'AMOE qui peut aider la MOE à choisir la bonne technique pour répondre au besoin exprimé, mais un bon AMOA peut le faire (si il a le niveau technique...) mais après cela devient l'armée mexicaine.

Ps : Selon les entreprises les terminologies ne sont pas respecté et beaucoup d'acteurs ne sont en fait que des "boites aux lettres" sans aucune plus-value, et les projets se cassent la gueules par non adéquation entre le besoin et le projet (en gros la MOE n'a pas compris ce que la MOA voulait et inversement).

[Glutinus]

Ps : Selon les entreprises les terminologies ne sont pas respecté et beaucoup d'acteurs ne sont en fait que des "boites aux lettres" sans aucune plus-value, et les projets se cassent la gueules par non adéquation entre le besoin et le projet (en gros la MOE n'a pas compris ce que la MOA voulait et inversement).

Chez mon ancien client, on était divisé en Pôle Développement et Pôle Projet.
Que faisait le Projet ?
Je l'ignore.
Des consultants venant de grosses boite Accenture-like.
Les mecs - et les nanas - ne comprenaient rien au métier, à la technique, à l'organisation. Ils ne faisaient pas de management, ou de la PMO. Ils ne coordonnaient pas les différentes équipes (par exemple, Production) pour la mise en production. En fait ils organisaient des réuniosn entre les utilisateurs et les développeurs (la plupart des développeurs internes étaient là depuis quasiment 10 ans, de même que les Key Users).
Au final, les développeurs faisaient la Business Analysis, aidaient à la recette, rédigeaient le PV de recette et le bon de mise en production.

D'où la question : A quoi servait le Projet ?
(sachant qu'en plus que le turn-over moyen était de 3 mois chez eux, donc aucune capitalisation des process ou de la connaissance projet en cours...)

[TacosPlease]

Salut,

ha ben si, normalement AMOA (ou MOA tout court) tu n'es plus dans la technique. Tu es dans le fonctionnel .

Tu définis un besoin, écrit les règles, peu importe comment ces règles sont implémentées par les développeurs, ce n'est pas ton soucis.

Là où je suis actuellement il y a des AMOA qui ne font que du fonctionnel et des AMOA qui travaillent sur des sujets qui sont quand-même techniques (bien sûr sans toucher au code). C'est pour ça que j'ai des doutes sur ma reconversion en tant qu'AMOA. Si finalement il s'agissait juste de changer de rôle sur des sujets techniques autant rester là où je suis.

[Ekolamar]

Là où je suis actuellement il y a des AMOA qui ne font que du fonctionnel et des AMOA qui travaillent sur des sujets qui sont quand-même techniques (bien sûr sans toucher au code). C'est pour ça que j'ai des doutes sur ma reconversion en tant qu'AMOA. Si finalement il s'agissait juste de changer de rôle sur des sujets techniques autant rester là où je suis.

Parce que les "entreprises" font n'importe quoi et que les terminologie utilisés ne correspondent pas : J'ai connu des CTO totalement incompétent techniquement (ils ne comprennent rien de rien aux contraintes techniques, même macro) alors que c'est littéralement des "Chief Technical officer" et qui prennent des décisions techniques à l'opposé du besoin fonctionnel (bon courage pour rattraper ça à la fin quand les clients vont se rendre compte que ça répond pas au besoin, mais c'est toujours la faute aux équipes en dessous).

Y'a des chefs de projet qui se content d'organiser des réunions entre les équipes techniques et les clients et c'est à la technique de s'arranger pour respecter le planning (plus-valu = 0)
Y'a des directeurs de projet qui ne font que de la communication (ils serrent des mains et organisent des séminaires) et n'ont aucune vision globale de leur programme, et tous les projets se marchent dessus.(stratégie = 0)
Souvent on remonte aux équipes techniques des besoins fonctionnels "processus" (gestion de l'escalade, procédure en cas d'incidents, guichet unique etc.) en les prenant pour une équipes de gouvernance dont on ne sait pas ce qu'elle fait (gouvernance = 0 et MOA = 0)

En gros, ce qu'il faut comprendre c'est que même en te formant (gestion de projet, ITIL etc.), tu ne pourras jamais appliquer et tu devras "faire avec" les méthodes internes. Donc un même titre dans une boite X ne correspond pas au même travail dans une boite Y, et dans les deux cas, il y a peu de chance que cela corresponde à signification réelle de ton titre (du moins c'est courant dans les grosses entreprises françaises).

[TacosPlease]

Tout à fait, j'ai vu la même chose pour mon métier de testeur : avec le même intitulé de poste tu peux avoir quelqu'un qui ne fait qu'exécuter des steps toute la journée sur ALM sur un projet en TRA, ou alors quelqu'un qui travaille sur des sujets complexes et définit une stratégie, écrit des cas de test, automatise un peu etc

[Glutinus]

Tout à fait, j'ai vu la même chose pour mon métier de testeur : avec le même intitulé de poste tu peux avoir quelqu'un qui ne fait qu'exécuter des steps toute la journée sur ALM sur un projet en TRA, ou alors quelqu'un qui travaille sur des sujets complexes et définit une stratégie, écrit des cas de test, automatise un peu etc

D'où, sur son CV, ne pas mettre "tests" mais "UAT strategy officer" ou un truc du genre, tu feras peut-être de l'automatisation ou bien apprendre le métier plutôt que de passer tes journées à mettre A dans des cases qui attendent des chiffres et noter le comportement de la page d'erreur...

[el_slapper]

Tout à fait, j'ai vu la même chose pour mon métier de testeur : avec le même intitulé de poste tu peux avoir quelqu'un qui ne fait qu'exécuter des steps toute la journée sur ALM sur un projet en TRA, ou alors quelqu'un qui travaille sur des sujets complexes et définit une stratégie, écrit des cas de test, automatise un peu etc

tout à fait. J'ai réussi à toujours échapper aux postes pousse-bouton, et j'en suis à un niveau ou je forme les utilisateurs à faire leurs propres tests un peu correctement(i.e. pas juste le chemin passant principal). Mais je suis un "ingénieur qualité développement", désormais, plus un "homologateur" (même si ça fait toujours partie de mon job). Tu arrives à un niveau ou il faut faire son propre marketing pour continuer à évoluer.