Reprise du message précédent :

 
Je pense qu'on te fera redoubler ta L3 pour MIAGE.
 
Tu as déjà de l'Xp en IT ?

+1, tu vas avoir trop de manque en IT pour moi

J'ai vu des licences mass aller en Master mais j'avais eco désolé. Mais demande quand même.

 
 
Je suis actuellement en M1 Miage et je me pose des questions concernant la branche vers laquelle m'orienter en début de carrière:
 
_ classique dev java full stack
_ test logiciel avec python + framework de test
_ faire de la data
_ ou partir sur du fonctionnel et devenir product owner... (mais j'ai peur que ce soit un bullshit job )
 
Mon principal objectif c'est de pouvoir trouver facilement du travail n'importe où en France (ou peut être ailleurs ).
 
La data a l'air de payer un peu plus.
Product Owner c'est sympa parce qu'il y a plus de conception mais ça ne me semble pas très exportable.
Faire du dev java ça a l'air d'être la voie la plus safe à suivre.
 
Quand au test logiciel, là je ne sais pas du tout quoi en penser...
 
Des avis? Retours d'exp?

Fais ce que t'aimes déjà. Les 4 voies sont OK pour trouver du taff.

Comparé aux autres postes dont tu parles, faire du dev te permettra d'avoir du taf assez facilement partout en France
 
Pour avoir fait du dev pendant pas mal d'années et étant actuellement PO : commence par faire un peu de dev pour voir comment ça se passe concrètement.  
Puis quand ça te saoûle de faire du dev (ou pas...), tu pourras envisager de faire autre chose selon tes affinités (PO/PM, expertise technique, expertise métier, etc.)
 
PO est tout sauf un bullshit job si on parle d'un PO orienté IT : tu dois construire intelligemment ton backlog + le workflow qui va avec, prioriser les demandes métier versus les demandes IT (et donc te fâcher avec tes collègues + leurs directions respectives), écrire / concevoir les tickets (mes tickets de spec API / de spec BDD sont très détaillés), recetter le produit fini (et donc te fâcher avec les devs) + je file des coups de main à gauche à droite (scripts de redressement de data via formules Excel, optimisations, monitoring, extraction de données, j'en passe...) car j'ai les compétences techniques pour.
 
Je précise que j'ai accès aux repositories de l'équipe, que je regarde le code (sans avoir pour autant le rôle de tech lead, j'ai autre chose à faire que de valider des PR), je m'occupe des livraisons en prod...  
 
Bref, l'important c'est pas l'étiquette que tu te colles sur le front, c'est ce que tu fais concrètement au quotidien + quelles compétences tu développes au quotidien grâce à ça.  
PO est un bullshit job si tu sers uniquement de passe plat entre métiers et dev sans apporter de valeur ajoutée. Je ne suis pas ce genre de PO

 
Est-ce que tu es impliqué en amont dans les phases de recueil des besoins et de conception générale?

 
Sur le besoin, pas vraiment car je bosse avec des chefs de projet métier qui s'en chargent et qui le font très bien. Je ne peux pas être partout
 
Sur la conception générale, ça va de soi car selon la taille des projets, je dois faire intervenir des architectes pour cadrer la solution technique. Pour de la petite maintenance c'est pas nécessaire, mais pour des gros projets c'est indispensable afin d'éviter de faire n'importe quoi (et donc de ne pas devoir refaire le projet dans quelques années, l'IT rend des super services mais ça coûte bien assez cher...)

Tu ressembles plus à un chef de projet IT à l'ancienne+++ qu'à un PO au vu de la description perso enfin du moins par rapport à la définition du scrum guide .
 
Mais bon, tout dépend de l'organisation et des étiquettes et missions qu'on file aux employés.

 
Comme je disais, y a l'étiquette et y a ce que tu en fais
Je fais "de l'agilité" mais pas du Scrum stricto sensu (comme partout ). Sinon j'aurais répondu que l'archi sera vu par l'équipe de dev pendant les sprints entre 2 stories... Sauf que y a des archis dans ma COGIP, et ils sont là pour nous empêcher de faire n'imp avec nos produits. Il vaut mieux qu'ils soient là en phase de cadrage que trop tard quand les développements sont faits... et à refaire.