Qu’est-ce qui vous a le plus surpris lors de vos premiers pas en entreprise ?

[pcaboche]

Ces histoires de pointeuses, ça me rappelle une histoire...


Quelle est la différence entre un informaticien et un fonctionnaire ?

Le fonctionnaire arrive à l'heure et finit à l'heure.
L'informaticien arrive souvent en retard, finit parfois (rarement) en avance, mais au moins son boulot est fait !

[ArKam]

Envoyé par thierrybenji

J'en ai rien à foutre, si je sais que je travail bien l'opinion du boss ne m'importe peu.
Après si il s'intéresse un peu, il verra que je suis productif.
Mais bon, effectivement il est possible que je passe pour un branleur, mais je préfère vraiment être chez moi à 17h qu'a 19h au travail.

Idem, mon boss, si il est pas content, il me vire ou il me le dit et là je lui expose mon point de vue, arguments à l'appui, si il ne comprend toujours pas je change de boite.

Je considère que j'ai la chance d'avoir un métier dynamique, porteur, en pleine croissance avec des opportunités nombreuses et récurrentes, et qu'en plus j'ai des compétences réels et recherchés.
Je peux donc me permettre ce genre de discours et de réaction, par contre, je comprend que certains ne puissent le faire.

Envoyé par thierrybenji

Arf ya quand même moyen de se croiser avec ses collègues.
Je ne pense pas qu'il soit possible d'arriver à 11h.
Ou alors ça veut dire que souvent tu pars du boulot à 20h.

Et en plus parfois tu travail seul sur un projet.

J'ai bossé dans une boite ou mes horaires étaient flexibles en tant que non-cadre à l’époque, sans badgeuse et ou je faisait 11H 19/20H, ça se passait très bien, mes collègues qui voulais partir tôt ou avait des obligations faisait le matin, c'est aussi pour ça que l’équilibre des ages dans une équipe est important.

Perso, j’étais jeune, j’étais intéressé et motivé, donc je venais tard parce que je suis pas un lève tôt et que je partait tard vue que j'habité pas loin.

Les gens plus âgés eux préférés arriver tôt et partir tôt, du coups c’était une bonne osmose.
Les entre deux bah eux ils faisaient un peu des deux.

Les histoires d'horaire, selon ton secteur, c'est de la foutaise...
Si on laissé les gens bosser le week-end, le soir, ou de nuit de façon volontaire (la période de travail, pas le travail hein ;-) ) ça se passerai mieux, les gens serait moins stressé.

Parfois je rentre d'un voyage (pro ou pas) et c'est le dimanche ou tard le soir, bah tout est fermé, et je suis comme un con avec rien dans le frigo ou dans les placards à devoir faire 50 bornes parce qu'en France les plages horaires de travail sont ultra réglementé niveau ouverture... C'est chiant et quand tu reviens de quelques temps dans d'autres pays ça fout les boules.

Je dit pas qu'il faut faire ça à la sauvage et je suis conscient des abus que cela peut entraîner, mais il y'a tout de même moyen de faire les choses bien. Ce serait un réel plus, pour les gens et l'économie.

Envoyé par thierrybenji

Là je me suis mal exprimé, dans ma boite tout le monde boss sérieusement, le code est propre et j’apprends beaucoup.
Ce que je voulais dire, c'est que des fois je glande et ça me fait bizarre.
Je ne vais pas sur facebook au travail, mais je peux consulter mes emails, écouter de la musique ou des podcasts, voir même jouer à Tetris (2 minutes).

Aucune honte/gêne ou problème avec ça perso, si quelqu'un est pas content, qu'il le dise, et qu'il me dise pourquoi... Perso mon taff est bien fait (C'est pas moi qui le dit mais le client) et rendu à l'heure voir en avance.

Pareil, mes employés sont dans le même panier, il sont autonome, je travail avec des adultes, j'ai pas envie de faire le flic, ils sont grands et responsables, ils savent que si ils déconnent trop, ça se verra de-suite, il auront deux chances et à la troisième ils seront remerciés gentillement (Faut pas pousser, un renvoi c'est ultra facile à faire).

Je préfère qu'un employé me dise qu'il n'est pas bien, qu'il se plait pas dans la boite, lui faire une rupture à l'amiable plutôt que l'obliger a faire une période de préavis ou il sera improductif voir même nocif au bon déroulement de l'ambiance de travail etc.

Envoyé par thierrybenji

Ce que je comprend pas avec les cadres, c'est qu'ils peuvent faire ce qu'ils veulent et au lieu de partir tôt, ils aiment finir tard.
Comme si c'était une réussite social de rentrer chez soi à 20h30 tout les jours.
C'est bien si t'essaies d'éviter ta femme et tes enfants
Mais si tu veux avoir une vie, c'est pas top.
Remarque j'ai l'impression qu'ils prennent plus de 5 semaines de vacances par an.

Les cadres c'est étrange, ils ne sont pas payé à l'heure et au lieu de faire 35h on dirait qu'ils en font 50, mais ils ont pas l'air de travailler.
En même temps un gars qui écrirait du code 10h par jour devrait avoir un mal de tête ultra violent.

Parce que les cadres ont deux régimes:
Le régime des cadres autonomes, qui sont eux soumis à résultats sur objectifs et donc avec des horaires flexibles (en théorie, mais souvent effacé par la charge de travail soumise).

Et un dit des cadres intégrés qui sont soumis à leurs convention collective et horaire de l'entreprise avec un calendrier similaire a celui des autres employés.

Personnellement, j'ai eu les deux cas, et l'un comme l'autre tu faits plus d'heure car t'as plus de responsabilité, qu'on te donne une charge de travail qui souvent n'est pas en adéquation avec ce que tu peux/doit gerer.

Le top, c'est le dernier cas que j'ai vécu, c'est un mix des deux ou en fait t'est cadre intégré, mais t'as une badgeuse et toute heure supp n'est pas payé mais incrémentés et tu peux poser des jours comme tu le sent dans la mesure ou t'as cumulé 7H30++ dans ton compteur.
Dans ce même cas, j'avais cette histoire de compteur badgeuse, mais en plus de ça, ce que faisait l'entreprise, c'est simplement compter que tu faisait 218J par an, ou 7H30 par jours, ou 37H par semaine, et ça c'est un bon deal.

D'un coté toi t'est flex sur tes horaires, de l'autre les patrons a la vue basse et courte se base sur des chiffres dont ils ont l'habitude et on l'impression de contrôler leur boite.

Apres, pour finir, perso, j'ai choisi de prendre des amis, des personnes de confiances, et des gens compétent et de monter une boite avec eux dont le maître mot c'est "Qualité de vie" car les clients le récentes, les gens sont contents de venir bosser, et tout le monde est heureux.
Apres, je dit pas que parfois on fait pas de grosses semaines etc, mais en tous cas au moins on sait qu'on bosse pas pour rien.

[erwanlb]

Envoyé par pcaboche

Ces histoires de pointeuses, ça me rappelle une histoire...


Quelle est la différence entre un informaticien et un fonctionnaire ?

Le fonctionnaire arrive à l'heure et finit à l'heure.
L'informaticien arrive souvent en retard, finit parfois (rarement) en avance, mais au moins son boulot est fait !

Et pour les informaticiens de la fonction publique ?

[ArKam]

Envoyé par erwanlb

Et pour les informaticiens de la fonction publique ?

Ils sont parfaits vue qu'il arrive à l'heure, part à l'heure et son boulot est fait

CQFD

[thierrybenji]

Pour moi pointer et faire les heures qu'on veut ce serait le rêve.
Je commencerais avant 8h et en faisant 1h de plus par semaine au bout de 35 semaines de travail j'aurais une semaine de vacances en plus par an !

Se dire qu'un quart d'heure de plus par jour pourrait permettre d'avoir une semaine de vacances en plus c'est génial.

Mais bon je pense que les entreprises qui permettent de faire ça sont relativement rare.

[erwanlb]

Envoyé par ArKam

Ils sont parfaits vue qu'il arrive à l'heure, part à l'heure et son boulot est fait

CQFD

Même dans l'informatique il y a des mythes et légendes....j'aurais pas cru !

[pcaboche]

Envoyé par ArKam

Ils sont parfaits vue qu'il arrive à l'heure, part à l'heure et son boulot est fait

CQFD

Ou alors c'est l'inverse : c'est le seul qui bosse mais il n'arrête pas de se faire engu***ler à cause de son "attitude".

Et puis, on parle de la "fonction publique" mais c'est un stéréotype pour parler de toute entité pointilleuse sur les horaires mais laxiste sur les résultats réels (bref, le genre de structure où on peut trouver des gens bien planqués et où s'applique plus facilement le principe de Dilbert ).

D'ailleurs, tout cela me rappelle un excellent comic :
http://dilbert.com/strips/comic/2001-10-21

[Cincinnatus]

Envoyé par thierrybenji

En même temps un gars qui écrirait du code 10h par jour devrait avoir un mal de tête ultra violent.

ça m'est arrivé, sur un projet intéressant, de finir à 20h+, simplement pour avoir la satisfaction du boulot terminé.


Pour reprendre la discussion du début, je dirais que la complexité et la taille du code/ interactions interapplicatives (points 1 et 2) ne m'ont pas surpris, mais je venais d'une filière industrielle, où il vaut mieux produire du code fiable, à intégrer à l'existant (points 2 et 3).

Ces dernières années, j'ai eu la chance de développer des applications nouvelles. Certaines ont fortement évolué au fil des ans, d'autres non, selon les demandes, et la plupart ont formé un écosystème et s'échangent des données. La reprise de l'existant était simple, puisque des mêmes auteurs . Cependant, nous avons eu aussi à reprendre du code d'un autre développeur, extérieur, celui-là. Je me demande encore s'il n'était pas débutant en programmation... mais son code a évolué sur plusieurs années (et là, un tel niveau de mauvaise qualité frise la correctionnelle ).

Le plus choquant est donc sans doute la qualité de certains programmes produits par des prétendus 'professionnels'... (point 4).

[sinople]

Concernant les histoires de badgeuses fantaisie (attention ce qui suit concerne la Suisse):

La pause de midi et du matin sont obligatoires. Elle doivent au minimum faire x minutes (j'ai plus le chiffre exact en tête). Même si l'employé veut rester bosser pour finir plutot, c'est illégal. Donc que le système sucre automatiquement cette pause est un comportement tout à fait compréhensible (en cas de contrôle si l'historique de la badgeuse indique des manquements à cette pause, le patron peut avoir des emmerdes....).

Effectivement le temps de préparation au travail n'est pas considéré comme du temps de travail. Néanmoins c'est la badgeuse qui devrait être placée près du poste de travail et non pas décompter 10 minutes pour faire un trajet de 100 mètre. Note que t'as qu'à faire 20 minutes pour le trajet, tu te feras probablement plein d'amis sur le trajet?

[baton]

C'est tellement triste, ça donne envie de se révolter...

[thierrybenji]

J'ai bossé dans une usine Suisse.

Si on pointait avant 7h ça ne comptait pas, ni après 12h, ni avant 13h.
Bon ça c'est déjà un truc.

À la base c'était sur du papier et les opérateurs contrôlaient le total sur leur fiche de paie, apparemment le patron se trompait souvent.

Moi même je n'avais pas vérifié et j'étais déjà bien content de ma paie.
Mais mes amis avec qui j'étais on vérifié et effectivement le total ne correspondait pas.

Le patron a mis ça sur le dos de la calculatrice Il ne pouvais pas accepter d'avoir fais une erreur à chaque fois c'était de la faute à quelqu'un d'autre...

Ensuite la pointeuse a été changé par une numérique et du coup les opérateurs devaient tenir une feuille en papier en parallèles.

Si je retournais bossé à l'usine avec le taux de change je gagnerai 16.65€/h.

Sachant qu'il est possible de faire des journées de 10h (7h-12h / 13h-18h).
Ça vaut le cout pour un job d'été.

Taux de change sur 5 ans :
http://fr.finance.yahoo.com/q/bc?s=C...=on&z=m&q=l&c=

Comme vous pouvez le constater sur cette image à un moment 1 chf était égal à plus de 0.9€.

C'est violent ^^

[jfchretien]

Ce qui me surprend le plus ?
Etant, selon mes missions côté utilisateur ou côté développeur c'est le décalage entre l'attendu (ce dont a besoin l'utilisateur final) et le réalisé (ce qu'ont produit les développeurs).
Suis-je bête... Entre les deux y'a un responsable projet côté client qui se fout des besoins réels des utilisateurs et un responsable projet côté prestataire qui se fout de ce que les développeurs ont besoin de savoir.
A l'arrivée : des développeurs qui prennent les utilisateurs finaux pour des emmerdeurs qui savent pas ce qu'ils veulent et des utilisateurs qui prennent les développeurs pour des abrutis de geek qui n'ont aucun sens de réalités...

[sevyc64]

Envoyé par jfchretien

A l'arrivée : des développeurs qui prennent les utilisateurs finaux pour des emmerdeurs qui savent pas ce qu'ils veulent

Ou des développeurs qui se démerdent tant bien que mal à avoir en direct les remontées des futurs utilisateurs en court-circuitant les intermédiaires.

[tp1024]

Je trouve que nous, développeurs informatique, nous nous auto flagellons trop. Les réalisations informatique sont indispensable dans le monde moderne et sont un facteur marquant la puissance d'un pays.

Issue d'une formation double compétence, j'ai eu un regard deux mondes (informatique/electronique). La qualité, les process dans l’électronique, de ce que j'en connais, ne sont pas meilleur qu'en informatique. Je côtoie beaucoup d’ingénieur de divers spécialité et j'ai envie de généraliser à la mécanique, l’électronique, l'aéronautique....

L'informatique est un nouveau métier, qui est contrôlé par les SSII, et donc n'a pas de passé "glorieux" ou "révolutionnaire".

Les managers des sociétés profitent de l'auto critique que peuvent se faire les développeurs, pour que ces derniers aient l'image la plus négative possible du boulot qu'ils réalisent et son importance. Et donc que ces informaticiens soient moins exigent en salaire.

Conséquence, j'ai appris avec le temps que le poids de l'avis d'une personne dépend de son salaire. Les informaticiens sont sous considérés par le monde industriel, qui se justifie ainsi de sous traité ces tâches "facile".
En France, l'informatique est aujourd hui concassé dans cette boucle, qui ne sait que ce plaindre du coût des développements, mais jamais de la qualité des réalisations ou des économie réalisée par un logiciel de qualité.

[xelab]

Ce qui m'a surpris, ou plutôt marqué car ce n'était pas toujours de grosses surprises:

- l'absence totale de documentation et l'existence de personnes "indispensables" étant les seules à connaître certains mots de passes ou le fonctionnement (au niveau logique du code) d'une appli.
- un peu dans le même genre du premier point: aucun commentaire dans le code ou alors l'inverse avec du commentaire à toutes les lignes.
- les bases de données modélisées n'importe comment (ou en fait, pas du tout modélisées), surtout pour les bases qui ont plus de 10 ans. Pourtant merise est enseigné depuis longtemps, à défaut d'UML...
- les jeunes managers aux dents longues et autres "chefs" en tout genre qui n'ont bien souvent aucune compétence particulière (voire ni de formation pour), mis à part de bien s'entendre avec la direction, mais qui sont quand même mieux payés que des ingés de plus de 10 ans d'expérience et qui trouvent ça "normal".
- l'utilisation de machines virtuelles copies de machines existantes pour éviter de payer des licences diverses et variées avec du coup pour obligation de bosser sur des machines virtuelles... sur un vieux portable.

[erwanlb]

Envoyé par jfchretien

Ce qui me surprend le plus ?
Etant, selon mes missions côté utilisateur ou côté développeur c'est le décalage entre l'attendu (ce dont a besoin l'utilisateur final) et le réalisé (ce qu'ont produit les développeurs).
Suis-je bête... Entre les deux y'a un responsable projet côté client qui se fout des besoins réels des utilisateurs et un responsable projet côté prestataire qui se fout de ce que les développeurs ont besoin de savoir.
A l'arrivée : des développeurs qui prennent les utilisateurs finaux pour des emmerdeurs qui savent pas ce qu'ils veulent et des utilisateurs qui prennent les développeurs pour des abrutis de geek qui n'ont aucun sens de réalités...

Ayant passé 10 ans dans l'industrie dans un boulot tout autre que l'informatique...c'est ce qui saute aux yeux dans ce domaine...

On aura pas vu PSA fabriquer une voiture plus longue de 5cm puis une plus courte...
Faire un avion jaune quand le client le veut blanc...
Etc.

Dans le dév les résultats sont beaucoup plus incertains parfois et moins "définis" en amont !

[sevyc64]

Dans l'industrie, généralement la documentation existe, elle est faite et exigée par les clients, bien souvent parce qu'il y a des process à valider ou une nécessité d'une certaine traçabilité.
Surtout que de plus en plus, maintenant, quelque soit l'industrie, il est demandé l'application de certaines normes, recommandations, certifications, etc ...


Par contre, dans l'informatique de gestion, c'est, la quasi majorité du temps, la valse du n'importe quoi. On a rarement des docs. Quand on les a, elles font de la prose sur tout et n'importe quoi mais ne comporte pas les informations principales et essentielles.

Pour avoir côtoyer les 2, le monde du développement pour l'industrie et le monde du développement pour l'informatique de gestion sont 2 mondes totalement à part, ils vivent pas sur la même planète.
Et si j'avais la possibilité, je reviendrais bien dans le développement pour l'industrie, nettement plus intéressant et valorisant.

[gangsoleil]

Envoyé par erwanlb

On aura pas vu PSA fabriquer une voiture plus longue de 5cm puis une plus courte...
Faire un avion jaune quand le client le veut blanc...
Etc.

PSA, de meme que Boing et Airbus, decident seuls du produit qu'ils font, puis disent au client "Voila, on a ca en stock, avec 42 options possibles, demerdez-vous pour que vos choix collent a l'existant".

Envoyé par erwanlb

Dans le dév les résultats sont beaucoup plus incertains parfois et moins "définis" en amont !

L'informatique, c'est le contraire : le client vient te voir en te disant "je veux un logiciel qui fasse du cafe, pour 42 euro, et j'en ai besoin demain"
Tu expliques donc au client que pour faire du cafe, il faut de l'eau et des grains de cafe, et un recipient, et que le logiciel peut faire le cafe a partir de ces ingredients.
Il te repond que c'est inadmissible, que ca coute trop cher, et que vraiment tu ne comprends pas.
Apres discussions, vous arrivez a vous mettre d'accord sur une specification, que les developpeurs developpent ; puis livraison, qui ne correspond pas a ce que veut le client car il n'avait pas compris exactement et le commercial non plus.
Retour a la case depart.

[deathness]

Envoyé par gangsoleil

PSA, de meme que Boing et Airbus, decident seuls du produit qu'ils font, puis disent au client "Voila, on a ca en stock, avec 42 options possibles, demerdez-vous pour que vos choix collent a l'existant".



L'informatique, c'est le contraire : le client vient te voir en te disant "je veux un logiciel qui fasse du cafe, pour 42 euro, et j'en ai besoin demain"
Tu expliques donc au client que pour faire du cafe, il faut de l'eau et des grains de cafe, et un recipient, et que le logiciel peut faire le cafe a partir de ces ingredients.
Il te repond que c'est inadmissible, que ca coute trop cher, et que vraiment tu ne comprends pas.
Apres discussions, vous arrivez a vous mettre d'accord sur une specification, que les developpeurs developpent ; puis livraison, qui ne correspond pas a ce que veut le client car il n'avait pas compris exactement et le commercial non plus.
Retour a la case depart.

Même the mentalist n'arriverait pas à savoir ce que le client veut

Personnellement ce qui me marque c'est la discussion ou on fait remarquer au client que ça va être difficile de faire ce qu'il veut vu que lui même ne le sait pas, et que celui-ci répond oui ben commencé (?) et je vous dirai plus tard
(plus tard variant d'une précision par heure à silence de mort)

[ElJipi]

Envoyé par erwanlb

Ayant passé 10 ans dans l'industrie dans un boulot tout autre que l'informatique...c'est ce qui saute aux yeux dans ce domaine...

On aura pas vu PSA fabriquer une voiture plus longue de 5cm puis une plus courte...
Faire un avion jaune quand le client le veut blanc...
Etc.

Dans le dév les résultats sont beaucoup plus incertains parfois et moins "définis" en amont !

La grande différence, c'est que dans l'industrie, le cahier des charges est très précis en amont

Dans la majorité des cas, le client ne sais pas exactement ce qu'il veut. Il a un besoin, il veut une solution et il a des idées sur la façon de répondre a ce besoin. A ce moment du projet (bien en amont), on commence a discuter avec le client sur ce qu'il veut, les fonctionnalités requises, les contraintes diverses qu'il faut prendre en compte. (jusqu'ici tout va bien)

De ce travail collaboratif entre le client et la société qui va faire l'appli, nait le document de spécification signé par les deux partie (rappelons que le client a un besoin, mais il n'a qu'une idée vague de la façon dont l'application doit répondre a ce besoin).

Le document de spécification va permettre aux développeurs de créer cet application qui va être montré au client (plusieurs maquettes bien entendu on déjà été validé par le client en amont). Et la, c'est toujours le moment ou les opérateurs (ceux qui vont vraiment utiliser l'appli) découvrent pour la première fois l'application et peuvent enfin indiquer les fonctionnalités primordiales manquante qui sont obligatoire a son bon fonctionnement (fonction inexistante du document de spécification bien entendu )

Dans la majorité des cas, le problème vient du manque de communication entre les différent acteurs.

Cette illustration bien connue explique beaucoup mieux mon point de vu
http://www.duhamelphilippe.com/tag/gestion-de-projet/