Reprise du message précédent :

 
Ouai et après ça donne le SI des Covea qui fait flippé ça race et réussir a être ransomwarisé à cause du télétravail... Et qui a été paralisé plus d'une semaine...
 
Mais bon heureusement on peu sans problème parier que tout les SI des banques/assurances ne sont pas fait pas les doigts de pieds par des armées de codeurs sans intelligence...

Non, heureusement, y'a la moa métier pour diriger les codeurs.

 
Non mais rien que dans ma boite. Des fois on nous demande notre avis entre 2 solutions. On dit que la solution B est à chier. Et bien sur on choisi la solution B et plusieurs année après le metier/la direction comprends on repart sur la solution A. Mais pendant tout ce temps on nous as maudit...

Excuses moi  

 
Rouen
 
Metz à l'ouest

 
Rouen, sa cathédrale, ses usines seveso.

AMHA t'es juste un peu super loin de maîtriser la notion de MOA/MOE... Puis bon c'est un peu juste l'organisation has-been qui est de moins en moins utilise depuis >10 ans avec les méthodes agiles... où il n'y a plus forcement de distinction entre l'équipe MOA/MOE.
 
En tout état de cause, si tu vois ton job d'ingénieur logiciel dans le sens le plus strict du terme, tu va implémenter l'application avec le fonctionnement que l'on t'as décris. Et en fait, souvent, une initiative pour prendre en compte tel ou tel cas dans un comportement sera un problème pour toi quand viendra le moment des tests ou des premiers bugs. Du coup le plus simple souvent c'est de se cantonné à implémenté telles qu'elles les spécifications fonctionnelles. S'eut été à la charge de l'analyse fonctionnel de lever les doutes et de faire les interview nécessaire aux bonnes personnes lorsque de la rédaction des spécifications fonctionnelles à partir de l’expression de besoin.
 
En tout état de cause, au mieux, en tant qu'ingénieur logiciel, tu ne peux que poser la question à l'analyste fonctionnel. Ce qui la plupart du temps sera - en fait - sans plus-valus dans sa réponse.
 
Là où ça devient compliqué, c'est quand seuls l'équipe d'ingénierie logicielle connais parfaitement le fonctionnement de l'application dans son ensemble et est à la seule à pouvoir lever des lièvres sur des potentielles régression de comportement lors de nouveaux développement. Et malheureusement, même si ça ne devrais pas être le cas, ça reste encore assez courant...

 
Faut l'excuser, il bosse dans un domaine où les process IT sont quand même assez archaïque et old school...

Chez nous, on est plutôt sur le classique : "c'est trop cher, faites le avec moitie de budget" donc tu te retrouve a arbitrer et a traîner des boulets (vieux automates, passerelle de com...) qui font que ça marche pas mieux (des fois moins bien) en attendant de pouvoir les faire évoluer.
Et pendant tout ce temps, on nous maudit...

Alors qu'en vrai, personne ne connait parfaitement le fonctionnement de l'application dans son ensemble  

C'est assez classique de toute façon en info de partir sur la solution dégueulasse mais qui coûte pas cher ("on fera l'autre solution plus tard" et on le fait jamais au final ).
 
Comme je vois qu'il y a pas mal de gens qui bossent dans l'info, est-ce qu'il y a justement des MOA sur le topic?    
 
Je me pose pas mal de questions quant à la suite de ma carrière, ça m'intéresse d'avoir le parcours de gens qui sont MOA actuellement ou qui l'ont été.

Yes, classique.
En même temps certains prix sont vraiment gonflés. Batailles classiques.

C’est assez joli Rouen !
Je ne m’y enterrerais pas mais je comprends l’attrait.

J'en viens, et j'y serais resté si seulement il y avait du taff là-bas.

Dante bosse au Lux, ne mets pas la France là dedans stp
 
comme tous les médiocres qui n'ont pas réussi en France, il va chercher le pognon à l'étranger

Tu peux utiliser la terminologie/méthodologie que tu veux, ça ne change rien au fait, que l’IT est là pour répondre aux besoins des utilisateurs (en tenant compte de contraintes dont le métier n’a pas forcément connaissance - la sécurité par exemple). Je trouve que les informaticiens ont un peu trop tendance à oublier cette vérité fondamentale.

 
C'est pour ça que t'es capable de te vendre beaucoup plus chère quand t'as une appétence de ce côté.  

J’ai fait ce choix il y a presque vingt ans. J’y ai gagné en rémunération, mais j’y ai perdu en stimulation intellectuelle.
 
C’est personnel, mais je trouve que la programmation est un exercice intellectuel très motivant/enrichissant que je regrette parfois d’avoir abandonné.

 
oui c'est sur, on a tout : bonne bouffe, bons alcools, montagnes, plages, campagnes, grandes villes.
Et réparti un peu partout en plus
de quoi satisfaire tout le monde    
 

 
je connais pas trop la normandie, faudrait que je me bouge un peu dans ce coin là aussi

 
c'est partout pareil.

En France, on ne valorise pas ou mal les compétences techniques. Il n’y a qu’à voir l’usage régulier sur ce topic de l’expression « pisseur de code ».
 
On se retrouve donc avec des consultants brillants qui font des spécifications qui sont mal interprétées/programmées par des juniors ou des bras cassés.
 
Alors qu’on obtient un meilleur produit avec un bon informaticien et des mauvaises specs qu’avec des bonnes specs et un mauvais informaticien.
 
Ca se démontre facilement par un raisonnement à la limite. On peut faire un programme sans specs. On ne peut pas faire un programme sans écrire du code

+1 surtout que dans le cadre d'un projet qui n'est pas que informatique, tu as toujours un "maître d’ouvrage" charger de faire le lien. Chez nous, c'est jamais des mecs qui viennent du monde info (par contre ça engendre d'autre problème).

Oui et non, je suis le premier a gueuler que l'on ne valorise pas assez le technique, mais avoir un super logiciel (propre, optimisé, évolutif.....) s'il ne fait pas ce a quoi on l'attends réellement, bah ça sert a rien.

 
Cette illustration est tellement vrai...

 
Donc, si c'étais vraiment le cas, on ne nous casserais pas les burnes avec des manipulations politico-économique... pour nous imposer des contraintes ubuesque... On ne nous demanderais pas des choses incompréhensible en nous soutenant que si-si ça va marcher... En vrai,  On réponds plutôt aveuglément aux volontés des utilisateurs, qui pour la plupart ne comprennent rien à l'outil informatique et ses contraintes... Et encore pire, pour une bonne partie, également à leur métier...    

 
oui oui personne comprend rien à son métier à part toi    
 
Une des raisons pour lesquelles l'IT est mal perçu en général c'est justement à cause de ça, prendre les autres pour des débiles car ils savent pas coder.

Cette façon de ramener l'IT a du dev c'est assez impressionant je dois dire.

c'est vrai que c'est ultra impressionnant  

 
Ce raisonnement est valide pour beaucoup de cas. Tant que le besoin est figé.
 
Par contre quand ton besoin d'évolution coûte cher, très cher, là ça deviens compliqué. Et souvent, au final, on a un rendement bien plus mauvais sur du code legacy. Donc y'a quand même un ROI visible à avoir du software développé dans l'état de l'art et proprement.

Bah oui, cette illustration est vrai (tu remarqueras que les "codeurs" ne font pas mieux que les autres).  
Et coté utilisateurs, ils ne connaissent pas forcement les capacités de l'outils info (dans un sens ou l'autre) donc ils ne savent pas ce qui est possible ou pas, et c'est pas toujours le mec qui utilise qui fait les specs (d'autant plus vrai quand il va y avoir beaucoup d'utilisateur différent, impossible de contenter tout le monde donc les choix a faire sont pas toujours les meillers).
Et coté info aussi, on n'est pas tous toujours "irréprochable"

 
C'est l'illustration basique qui sert à montre que ce n'est pas parce que c'est évident qu'il ne faut pas creuser un peu plus. Et qui tend à monter que de faire des interview de toutes les personnes concernées par l'utilisation du logiciel reste important avant de finalisé les spécifications fonctionelles.
 
Pour avoir pas mal bossé dans l'édition de logiciel où l'on faisait pas mal de spécifique pour chaque client, franchement c'est largement par rare que de mauvaise compréhension en mauvaise compréhension, on ne développe par du premier coup ce qui était attendu.

 
il y a surtout une forte proportion d'informaticiens prêt à se jeter a la gorge de ceux qui comettent des approximations dans leur petit domaine de compétence mais qu'ils sont si fiers de maitriser, plutôt que d'expliquer calmement sans prendre les gens pour des cons.  C'est assez détestable comme attidude comme on peut le noter ici même
 

Je suis d'accord avec toi sur la théorie, mais j'aimerais bien avoir des chiffres en pratique de la chose car de ce que j'ai vu, a part dans le domaine du web, bien souvent les évolutions sont "légère" rapport au soft (donc si fait salement au départ, on fait pareil, pas sur que ce soit beaucoup plus long a faire).

Et en cas d’évolution lourde, bien souvent c'est le système même qui change avec un nouveau soft complet (des fois même changement de techno).

 
Il etait temps de s'en rendre compte
 

 
+1

 
yes bien sûr l'illustration est classique je l'avais déjà vue, je réagissais plutôt à la phrase derrière, et cette illustration elle est applicable dans presque tous les métiers de création de services / produit. En fait dès que tu as de la gestion de projet qui implique plusieurs équipes tu vas te retrouver avec ce genre de situation.
 
De toute façon l'aptitude à collaborer c'est clairement une aptitude à écouter les autres et comprendre leurs besoins, en gros trouver un langage commun. T'as beau être un crack techniquement si t'es pas capable de discuter sans prendre les autres pour des merdes tu sers à rien dans un projet.

 
En 2020    
 

 
La MOA n'existe plus dans les nouvelles organisations
 
On a rebrandé ça en product owner.
 
 

 
C'est de moins en moins vrai même dans une cogip comme la mienne.

Ne pas être un expert du code OK, mais n'avoir jamais coder tu peux pas dire que tu es informaticien. Et ce que dit MEI est vrai, la plupart du temps t'es face à des gens qui comprennent rien et qui bluffent comme ils peuvent.  
 
Il n y a qu'à voir les annonces des moutons à 5 pattes pour comprendre que tout le monde fait semblant de savoir ce qu'il cherche. Il y a tellement de technos, de domaines différents dans l'IT, qu'on est vite largué.  
Moi de ce que j'ai vu dans les différentes boites que j'ai faite, c'est l'armée mexicaine : 10 bluffeur qui comprenne rien et qui sont grassement payés pour un mec qui va bosser réellement.
 
Personnellement ça m'arrange, j'ai fais rapidement le choix de faire du vent plutôt que d'avoir un vrai travail technique qui me prend de grosses ressources mentales et qui est moins bien rémunéré.  

 
L'informaticien se croit souvent au dessus du lot intellectuellement.
C'est peut-être vrai vis à vis de la population globale, mais sans doute faux vis-à-vis des cols blancs des grandes entreprises françaises.
Et je ne parle pas des ingés en particulier, tout le monde sait que seuls les ingés en méca sont vraiment intelligents
L'informaticien a aussi souvent tendance à mordre la main qui le nourrit.

 
Tu as fait quel move? MOE vers MOA?
 

 
C'est quoi que tu appelles nouvelles organisations?

 
Alors en gros de mes expériences pro on a eu :
- changement de technos de communication entre la brique "serveur d'application" et l'application Web afin d'utiliser le même protocole que le client lourd qu'un protocole de Web Services dédié (et donc avoir accès à toutes les API de l'application sans avoir à faire beaucoup de réécriture). Comme les choix techniques et le niveau d'abstraction fait côté serveur et client étaient pas trop mauvais, on a pas eu trop de boulot à faire pour arriver à faire ce move. Si on avait pas prévu d'abstraction pour la couche de persistance des données, on aurai sans doute du repasser sur toute l'appli.
 
- changements réglementaires... par ex longtemps dans une appli sur laquelle j'ai bossé, on avait qu'un seul niveau de TVA. Puis un jour y'a eu plusieurs niveaux de TVA et puis après on a voulu gérer des pays européens. Du coup on a du migrer une TVA en dure en constante (dupliquée un peu partout hein ), d'une gestion de TVA complète. Et ça a été un gros chantier. Pour autant on a pas réécrit tout le soft pour ça. mais si ça avait été juste un peu plus abstrait on aurai pu aller beaucoup plus vite.

 
Pas vraiment.
Si on veut faire des analogies avec l'ancien modèle, le product owner c'est plutôt l'assistance maîtrise d'ouvrage et pas la maîtrise d'ouvrage en tant que telle.
Mais même là l'analogie est un peu bancale car le PO fait partie de l'équipe, quand l'AMOA a un centre de gravité bien + proche du client que de ceux qui font.
Dans l'ancien modèle l'AMAO tapait sur la tête de la MOE, dans le nouveau modèle c'est le PO qui prend les coups du client.
 
Concrètement l'informatique applique maintenant des modèles organisationnels de + en + proches de l'industrie (la vraie )
Et clairement dans l'industrie ce ne sont pas les gens qui produisent qui sont le mieux payés.
Si on aspire à des revenus confortables, rester dans la technique est un choix possible mais il faut alors aller vers une niche/un domaine d'expertise rare.
Et si on a des capacités dans le pipeau et l'enfumage, il sera bien + facile de faire illusion dans des postes pas/peu techniques.
Il faut aussi bien jauger la baisse parfois énorme d'intérêt intellectuel en changeant de fonction.
Baisse d'intérêt que des revenus confortables ne compensent pas forcément.

 
non. du moins sauf a considérer que faire 3 scripts est savoir coder.

De toute façon dans la gestion de projet de manière générale, je pense que clairement la rémunération est plus importante quand on est en face du client ce qui explique à mon avis la différence de salaire entre un MOE et un MOA/PO (suivant les organisations).
 
Effectivement, c'est rarement ceux qui produisent qui vont être le mieux rémunérer mais en même temps c'est pas le même type de compétence qu'on demande à ces deux types de poste.

perso j'ai fait MOE -> MOA et maintenant je remets un peu les mains dans la techno. Je suis chef de projet mais du mal à ne pas garder les mains dedans, donc je suis un peu entre les 2
.car j'aime bien
.car je trouve que tu as au final plus à apporter en étant un peu technique avec une vision un peu plus haute et transverse
.pour ne pas me faire balader par la MOE (au niveau des devis, au niveau du diagnostic des problèmes)
.car c'est quand même plus valorisée je trouve. Autant pour le métier, tu peux plus facilement appeler un ami pour une règle de gestion/un truc super pointu, autant en techno quand tu piges pas grand chose et que tu n'en n'a pas fait/plus depuis longtemps c'est compliqué

Le problème c'est que des MOE avec de l'expérience, il y en a peu, du coup, mécaniquement ils sont moins bien payés que la MOA qui a plus d'expérience

Après je bosse autour des données, avec mise en place/utilisation de nouveaux (à notre niveau) outils et "technos" pour essayer de résoudre plus facilement et efficacement des cas d'usages.
On fonctionne par mission dans ma COGIP et l'avantage c'est que tu peux en changer régulièrement, permettant ainsi d'apprendre de nouvelles technos/domaines fonctionnels/concepts et d'agrandir ton réseau, ce qui est primordial dans les grosses structures car savoir qui contacter pour avoir telle ou telle information est souvent le plus difficile.