Discussion :

[tidou]

Bonjour,

Je suis en contact avec une banque et m'apprête à signer mon 1er CDI pour un poste de développeur mainframe pour travailler dans le domaine métier des titres.

N'ayant encore jamais développé dans le domaine bancaire (mais j'ai une courte expérience en environnement mainframe) et encore moins dans le domaine des titres, je me poste des questions sur ce type de travail surtout que je ne veux pas me tromper pour mon 1er emploi et savoir un minimum à quoi m'attendre. Pour information je vais avoir un master en informatique avec un profil orienté "développement d'applications".

Par exemple :
-on m'a parlé lors de mon entretien de la nécessité pour ce type de poste de savoir calculer une valeur net d'inventaire par exemple. Après une recherche sur internet, la manière de calculer cette "chose" ne semble pas compliquée et un calcul basique en suivant la procédure suffit à trouver le résultat. Néanmoins et de manière général, est-ce que pour ce type de poste il faut des compétences en mathématiques élevées et si oui dans quels domaines (probabilités, statistiques) ? Je n'ai pas suivi une filière scientifique et donc je ne suis pas un as des mathématiques ce qui me fait douter. De plus je suppose que ce type de calculs pour calculer différentes choses liées au domaine des titres sont couramment demandés. Avez-vous vu eu au départ besoin d'apprendre toutes ces formules ou bien vous les avez apris sur le tas, petit à petit, avec l'appui de vos collègues de travail ?
-est-ce que ce type de poste est plus stressant qu'un autre ? Je ne serai pas en relation avec les courtiers directement mais je suppose qu'ils sont à même d'utiliser mes logiciels.
-d'une manière générale est-ce que le temps d'apprentissage du contexte métier est long est difficile ? Je suppose que oui car tous ces termes abscons ne veulent rien dire au départ si, comme, moi on a pas eu de formations en ce sens lors de notre parcours scolaire.

Merci d'avance à celles et ceux qui prendront la peine de me décrire leurs expériences.

[julien-blaise]

Salut,

Je travaille moi aussi dans le domaine bancaires. En effet, tu auras pas mal de terme et aspect financier à comprendre et à assimiler. Mais normalement ton employeur est conscient que tu as un profil technique et non financier. Tu seras donc certainement soutenu par des analystes financiers dans tes travaux.
Ces derniers sont au courant des formules de calcul de telle ou telle valeur et devrait t'aider lors de la réalisation de tes logiciels. Ils devront de toute manière les tester pour valider que tu as bien répondu à leur demande.
Je ne pense pas que ce métier soit plus ou moins stressant qu'un autre. Après tout dépend des gens. Tu pourrais très bien trouver ce job stressant et un collègue le trouver pas stressant du tout.
Concernant le temps de formation, oui ce sera certainement long. Tu risques d'en apprendre un peu plus tous les jours jusqu'a la fin de ta vie
Le domaine financier est assez vaste et le nombres de produit financier surprenant. Mais t'inquiète pas ça viendra

Bon moi aussi il serait temps que je me mette à la finance

A+

[el_slapper]

niveau algo, ça ne devrait pas casser trois pattes à un canard. Dans ce domaine, j'ai toujours trouvé que la principale difficulté, c'était l'épaisseur du système d'information. Du genre, il faut que j'appelle le référentiel client pour obtenir un numéro qui me permet d'appeler le carnet d'ordres qui me permet d'obtenir un montant quie je dois convertir grâce au référentiel devises, puis je dois vérifier dans le référentiel comptes que le compte est bien dans la devise prévue, auquel cas.......

Tout ça pour faire 3 additions et 2 soustractions. Genre l'algo que tu as trouvé sur internet. Mais l'algo ne te dis pas ou trouver dans le SI les données dont tu auras besoin. Tu risques de faire pas mal de "social", en fait, pour trouver des interlocuteurs qui savent comment accéder aux données dont tu as besoin.....Et beaucoup de débogage, parceque les exemples qu'on te donnera seront incomplets, que tu n'auras pas les droits d'accès au référentiels, que tu n'auras pas accédé à la bonne fonction parceque la doc est obsolète, etc.....

Et l'algo t'aura couté 3 heures de boulot, mais le programme 2 semaines. Nan, t'en fais pas pour l'algo. Cherches à communiquer, et ça devrait aller.

[tidou]

Merci à vous deux pour vos remarques

J'ai également demandé à un développeur qui travail au niveau des titres et il m'a dit la même chose que vous.
C'est vrai qu'en environnement bancaire il faut constamment communiquer avec les autres personnes et souvent de plusieurs services vu l'énormité de ces systèmes, du nombre de couches qui se sont empilées avec le temps et également pour aller à la pêche à l'information (comment ça marche, où cela se trouve-t'il, commen récupérer etc.).

Je pensais à tort apparement qu'il fallait être une bête en maths dû fait que je comparais avec les métiers d'actuaire ou de trader qui eux demandent un très bon niveau dans cette matière.

[julien-blaise]

En effet, pour certain métier, il faut un bon niveau en math et autre. Mais toi ton job c'est de faire du développement et de t'occuper de la partie technique de leur métier. On ne te demande pas de les remplacer, mais de leur fournir les outils leur permettant de faire au mieux leur boulot. Dans ce contexte, c'est à tes clients de te fournir les spécifications de leur besoin, ce qui inclut les formules de calcul si c'est nécessaire.
Après c'est toujours un plus de comprendre ce que tu fais, car tu peux ainsi au vu des problèmes techniques que tu rencontres suggérer des solutions fonctionnelles pour satisfaire tout le monde. Et ça, croit moi, ce sera très apprécié
Donc rien ne t'empêche si t'es vraiment motivé de te former petit à petit. Tu le feras certainement sur le tas en discutant avec tes collègues. Ils t'expliqueront pourquoi ils veulent que tu fasses les autres d'une certaine manière et petit à petit tu apprendras

A+

[la drogue c'est mal]

si tu fais du mainframe c'est que tu es sur du back office donc les maths c'est de la compta. Ca se limite à des additions et soustraction. Il n'y a pas de quoi déménager un chameau

[julien-blaise]

Certainement en BO, il faut juste faire des additions et des soustractions, mais faut aussi savoir quoi additionner et quoi soustraire et ça, seul les analystes pourront lui dire.
Donc conclusion, même si en dév ça ne casse pas des noix (bien que parfois tu va te trouver sur des cas assez complexes certainement ), il faut bien communiquer pour comprendre les besoins de tes clients

[el_slapper]

"seulement des additions et des soustractions?" Je suis pas d'accord, faut diviser, aussi. Spécialement pour les transactions en devises non-Euro. On avait un module COBOL de plus de 1000 lignes qui ne faisait QUE les arrondis de divisions. Suivant des règles hyperstrictes. Que des opérations simples; mais en grand nombre.

Sinon, d'accord sur le reste : on peut survivre sans comprendre ce qu'on fait, et le faire bien quand même(à condition d'être rigoureux), mais la "proactivité"(le fait de signaler quand on hume quelque chose de louche, voire de proposer des solutions) est fortement appréciée. Et pour être "proactif", il faut comprendre le contexte dans lequel on évolue.