Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Sondage : l'échéance des tâches oblige-t-elle les ingénieurs IT à faire des heures sup gratuitement ?
    Sondage : l'échéance des tâches oblige-t-elle les ingénieurs IT à faire des heures supplémentaires gratuitement ?
    Partagez votre avis sur le sujet

    L’ingénieur informatique est la main-d’oeuvre innovante d’une entreprise, à travers la conception de nouveaux outils et la mise en place de nouveaux systèmes. Certains vont jusqu’à dire que cela représente plus qu’un métier. L’ingénieur informatique peut être polyvalent, généraliste ou spécialiste d’un domaine technique spécifique. Dans l’un ou l’autre des cas, la société qui l’emploie s’attend à ce qu’il soit très compétent, rigoureux et doté d’un fort sens d’analyse. Cependant, l’ingénieur informatique est-il aujourd’hui pris au piège par les échéances de tâches ? Certains disent oui.

    Dernièrement, plusieurs messages sur certains forums estimaient que les échéances de tâches sont conçues en réalité pour obliger les ingénieurs à travailler gratuitement. Ces derniers en sont même arrivés à dire que l’ingénierie est une carrière frustrante. Selon eux, leur avis pourrait s’expliquer par le fait que l’ingénieur n’a aucun pouvoir et que tout le monde attend de lui qu'il résolve tous leurs problèmes. Bien sûr, tout le monde n’est pas d’accord avec cette affirmation, deux clans s'affrontent donc.

    L’ingénierie informatique serait une carrière frustrante

    Pour ceux qui sont d’accord, la plupart du temps, une tâche descend d'un cadre plus haut placé dans une organisation et dont l'ingénieur ne connaît pas l'identité. Il peut ne pas savoir, parce que son patron veut le tenir dans l'ignorance, parce que le patron de son patron veut tenir son patron dans l'ignorance... La plupart du temps, les tâches sont imaginées par quelqu'un qui n'a aucune idée de ce qu'il demande ni du temps que cela prendra. Et c’est là que le premier abus intervient. Voici, selon eux, un scénario courant qui se joue entre un ingénieur et son patron.

    Le patron de l'ingénieur lui demande combien de temps il lui faudra pour accomplir une nouvelle tâche. Généralement, l'ingénieur n'avait jamais fait cette tâche auparavant, et il répond honnêtement qu'il n'a aucune idée du temps que cela prendra. Mais, selon les gens du premier clan, ce qui arrive c’est que son patron n’est pas disposé à accepter cette réponse. Ainsi, il lui repose la question à nouveau et quand cela arrive, l'ingénieur fait alors une supposition. Mais une fois encore, le patron est susceptible de trouver le temps supposé par l’ingénieur trop long. Cela arriverait même dans les cas où l'ingénieur sait combien de temps il faudra pour accomplir une tâche et donne une estimation réaliste.

    Au bout du rouleau, le patron finit par imposer à l’ingénieur un délai quelque peu dérisoire. De son côté, lorsque l'ingénieur demande depuis combien de temps son patron est au courant de la tâche, le patron répond qu'il le sait depuis un mois. Lorsque l'ingénieur lui demande pourquoi il ne lui a pas dit il y a un mois, le patron le regarde comme s'il ne comprenait pas la question. Il arrive donc qu’un responsable de l'ingénierie fixe à un ingénieur un délai impossible à respecter, par exemple trois jours pour résoudre un problème qui prendrait probablement un mois.


    Dans ce cas, ces derniers estiment que deux choix s'offrent généralement à l’ingénieur. Soit il fait un travail de qualité inférieure (mauvais) ou bien il peut revenir à la fin du délai et dire à son patron que le travail n'est pas terminé. La plupart du temps, s'il choisit de faire un mauvais travail, tout le monde semble heureux que quelque chose ait été produit, même si ce qui a été produit peut être un déchet total qui n'était bon à rien. Si l'ingénieur revient dans trois jours et dit à son responsable que le travail n'est pas terminé, son patron lui demande pourquoi.

    Et le fait que l'ingénieur n'ait pas eu suffisamment de temps n'est pas une réponse acceptable. S’il n’a pas fini le travail, deux cas se distinguent. Selon eux, si le travail doit être fait ou s’il est important, le patron lui accorde encore un autre délai. Par contre, si le travail n'avait jamais été important au départ, le patron se contente de dire à l'ingénieur que le délai est écoulé et d'aller faire autre chose. Ces derniers pensent que cette interaction entre le responsable de l'ingénierie et l'ingénieur n'est rien d'autre qu'un jeu : soit pour le responsable, soit pour l'entreprise.

    Ce jeu peut constituer en une démonstration de pouvoir de la part du directeur ou en une stratégie de l'entreprise pour augmenter ses bénéfices. En d'autres termes, si un patron n'est pas désemparé (ce qui semble être le cas de certains), il sait qu'un ingénieur ne peut pas accomplir en trois jours un travail qui prendra un mois. Mais il doit donner l'impression de jouer le jeu. Le patron veut que l'ingénieur fasse des heures supplémentaires non rémunérées, autant d'heures supplémentaires non rémunérées qu’il peut supporter. Selon ce qu'ils disent, c’est pourquoi dans certaines entreprises, les ingénieurs travaillent régulièrement 70 heures par semaine.

    Un grand nombre de sociétés d'ingénierie loueraient essentiellement leurs ingénieurs à l'heure à leurs clients. Ces sociétés facturent un travail soit en fonction du nombre estimé d'heures nécessaires pour l’accomplir, soit en fonction du nombre d'heures d'ingénierie réellement nécessaires. En fait, elles facturent le client pour chaque heure d'ingénierie. Si leurs ingénieurs travaillent gratuitement au fil du temps, cela représente un pur profit pour l'entreprise. Ainsi, elles ont d'énormes incitations financières pour obliger les ingénieurs à faire des heures supplémentaires gratuitement.

    Par conséquent, de nombreuses entreprises essaient de contraindre leurs ingénieurs à faire autant d'heures supplémentaires non rémunérées que possible, même si cela signifie qu'elles doivent inventer de faux délais pour que les ingénieurs travaillent plus longtemps. Et, selon les dénonciateurs, ce comportement est légal aux États-Unis. Il l'est parce que les ingénieurs sont salariés, et non payés à l'heure. Le terme “salarié” signifie essentiellement que l'employé est payé le même montant chaque semaine, quel que soit le nombre d'heures qu'il travaille réellement.

    Cette pratique est aussi légale parce que les grandes sociétés de la Tech sont capables d'engager des lobbyistes, mais les ingénieurs ne le peuvent pas. Par ailleurs, dans un contexte technique, ces derniers ont déclaré que cela signifie que de nombreux ingénieurs sont surmenés et produisent des déchets. La culpabilité et le manque d'empathie auraient poussé les entreprises à transformer leurs directeurs et ingénieurs en menteurs.

    Ils sont obligés de dire qu'un travail a été achevé alors que ce n'est pas le cas, afin que l'entreprise puisse faire assez de bénéfices. Et les dirigeants ne semblent pas s'en soucier.

    Tout le monde ne partage pas cet avis

    À l’opposé, ceux qui réfutent ces allégations estiment que les entreprises sont aujourd’hui mieux organisées que cela. Selon eux, il existe plusieurs manières de procéder lorsqu’un ingénieur se retrouve face à un travail qu’il n’avait jamais fait auparavant. Voici un plan de comment procéder selon eux :

    • faire un projet d'enquête pour évaluer la complexité et/ou examiner des projets similaires ;
    • échanger du temps (délais) pour le champ d'application et les ressources. « Oui, nous pouvons livrer en un mois, mais seulement si nous réduisons le champ d'application et si nous obtenons 2 personnes supplémentaires pour l'assurance qualité, etc.» ;
    • vous pouvez également négocier pour échanger du temps contre de la qualité et/ou prendre une dette technique en sachant que cela réduit la vitesse future ;
    • si ni l'un ni l'autre de ces points ne se produit, vous devez échanger le ridicule contre un salaire/une croissance plus élevé.

    Pour ces derniers, “tout est une négociation”. Il n'y a pas de délai strict. Souvent, ce que dit l’ingénieur en chef, c'est : « pour réussir sur le marché, je pense qu'il me faut X choses en Y jours ». Ensuite, ce serait à l’ingénieur de fournir les données et les estimations qui détermineront l'orientation de l'entreprise. Selon eux, si vous ne clarifiez pas ou ne négociez pas les exigences en vous basant sur vos connaissances techniques et aussi votre expérience et que vous considérez les exigences comme des lois écrites dans le marbre, vous n'apportez pas la véritable valeur d'un ingénieur.

    Enfin, si vous faites cela, en repoussant et en ancrant les exigences dans la réalité, et que l'entreprise poursuit de toute façon des objectifs irréalistes, cela signifie simplement que les personnes avec lesquelles vous travaillez ne sont pas raisonnables et que vous devriez chercher un emploi ailleurs. S'ils ne sont même pas prêts à écouter les gens qu'ils paient pour leur expertise, alors ils sont sûrement en train de mal interpréter le marché.

    Et vous ?

    Quel est votre avis sur le sujet ?
    Selon vous, l'échéance des tâches oblige-t-elle les ingénieurs informatiques à travailler gratuitement ?
    Avez-vous déjà été dans une situation de délai non raisonnable pour accomplir une tâche ? Partagez votre expérience

    Voir aussi

    La difficulté à recruter de bons ingénieurs en informatique résulte-t-elle de la baisse générale du niveau scolaire, notamment en maths et en sciences ?

    Un ingénieur en informatique de Netflix gagne plus de 300 000$ par année. Pourquoi cette entreprise paie-t-elle plus que Google et Facebook ?

    Ingénieur Full Stack : mythe ou réalité aujourd'hui ? Peut-on vraiment avoir un haut niveau d'expertise du back-end au front-end ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre confirmé
    Tu travailles en entreprise, tu présentes le projet en discute avec la direction valide le projet... tu démarres le projet avance bien tout est ok, la direction voit que ses directives prennent formes, tu fais une petite présentation histoire d'être bien dans le cadre ( ben faudrait faire participer ...) et là tout ce passe bien, alors me direz-vous, la nuit passe et ils réflechissent revienne avec le sourire vous demande en réunion et là patatraque on vous annonce qu'ils pensaient pas que cela étaient possible et qu'ils en avaient pas bien entrevue (ils sont des commerciaux des cracs la dessus rien à dire bien au contraire avec des idées de conception de marché donnant des ouvertures sur le monde industriel, mais l'informatique c'est un monde à part, il s'en servent par obligations, c'est le faîte de la gestion, de tableau de bord et suivi d'avancement usine etc... et la comptabilité c'est pus facile...) alors votre projet en prend un coup et parfois avec des extentions que vous devriez avoir dès le début mise en oeuvre, vous essayez de faire comprendre qu'il n'est pas possible de tenir les délais et l'on vous demande en vous donnant une petite rallonge de temps et de grande ralonge d'effort sur votre temps, vous n'avez plus 30 ans et une famille etc... que croyez-vous que l'on fait, ON PLIE, et comme j'étais beaucoup à cheval sur la propretée de projet on reprend et refond car la maintenance est beaucoup plus simple après. Alors certain me diront les syndicats, ben là tu peux toujours courrir tu es cadre et parfois cadre supérieur ou du moin souvent tu en joues le rôle et croyez m'en mon expérience les syndicats pour les pme grosse pme ils s'en contre foute, et ton équipe tu la protèges et eux aussi on des contraintes personelles, tu mets la main grandement à la pate, ainsi la maltraitance s'insinue... C'est vrai qu'une fois pris dans l'engrenage difficile très difficile d'arrêter tout ça. Alors on a fait des outils pris sur notre temps pour dégager du temps et ne rien dire pour ménager notre vie courante ça été la seul solution que l'on a trouvé, des outils soulageant fortement l'écriture et la maintenance. Mais quand même cela me laisse un gout amère du manque de respect. Le manque de respect devrait faire l'objet d'un article tant il est le problème, même si votre travail est reconnu.

  3. #3
    Membre habitué
    Je suis dans le 2ème cas. (On est en France, surement pour ça que c'est plus simple)

    Je n'ai jamais travaillé dans une grosse boite, et ça fait parti de mes raisons de travailler pour une petite boite.
    Si on vous "oblige" a faire une tâche dans des délais impossible, soit c'est pour juger votre gestion du stress, soit c'est des connards.

    Pour la gestion de stress, c'est très peu souvent donc suffit juste de faire son travail.
    Par contre, si c'est des connards, changez de boulot ! Vous serez peut être moins bien payé, et encore, mais surtout vous aurez une meilleure atmosphère de travail.

    Les boites avec un gros turn-over sont connues, et on les évite.

    Il y a beaucoup de boulot pour un informaticien, donc pourquoi se ruiner la santé pour un travail ?

  4. #4
    Expert éminent
    Pour moi c est idiot.

    Au-delà d un certain nombre d heure on fait de la merde.

    Donc c est une décision stupide.
    Le fait que ça soit payés ou gratuit n est même pas pertinent.

    Mais on à tendance à faire reporter toute la responsabilité de l échec de la conception sur l.equipe de dev, et ce faisant de les convaincre de faire cet effort en plus.
    Mon profil linked in

    Chez Adaptive, nous cherchons un dev senior python / Cloud sur Toulouse sud.
    Nous diffusons de la presse digitale à bord des avions avec les plus beaux partenaires !

    Envoyez moi un mp

  5. #5
    Membre extrêmement actif
    Citation Envoyé par Bill Fassinou Voir le message
    Selon vous, l'échéance des tâches oblige-t-elle les ingénieurs informatiques à travailler gratuitement ?
    Si pour des raisons exceptionnelles vous travaillez jusqu'à très tard, débrouillez-vous pour récupérer les heures quand il n'y a pas d'urgence.
    Le premier truc ce serait de dire "je suis resté au bureau jusqu'à 23h parce que je devais finir des tâches pour pouvoir faire la livraison, donc je ne viens pas demain matin".
    Si les chefs ne sont pas d'accord envoyez-les se faire foutre, ou barrez-vous du boulot tous les jours à 15h, jusqu'à ce que vous aillez rattrapé les heures en trop. (il faut bien que le fait d'être ingénieur, cadre ou ce que vous voulez ait des avantages)

    Citation Envoyé par Bill Fassinou Voir le message
    Avez-vous déjà été dans une situation de délai non raisonnable pour accomplir une tâche ? Partagez votre expérience
    Je n'ai jamais eu de deadline vraiment critique, cela dit c'est arrivé à certains de mes collègues.
    - J'ai travaillé dans une entreprise qui publiait un journal, régulièrement ils doivent envoyer un document à l'imprimeur à temps, le problème c'est que ceux qui achètent de la pub les envoient au dernier moment, donc il faut les attendre puis les placer pour finir le document.
    - Dans un cadre différent, il y a une équipe A qui doit produire un document pour que l'équipe B puisse l'utiliser, et juste avant la date limite il y a des chefs qui modifient le travail que doit rendre l'équipe A
    - Il parait que la surcharge arrive souvent en fin de cycle en V. Dans un projet tu fais 90% tranquille et les 10% restants sont horribles, ces 10% du projet peuvent prendre 50% du temps total du projet.

    Si un commercial fait des promesses irréaliste à un client, expliquer lui qu'il ne faut pas promettre n'importe quoi au client sans consulter les ingénieurs. Le commercial ne peut pas savoir combien de temps prend une tâche.
    Keith Flint 1969 - 2019

  6. #6
    Membre éprouvé
    c'est un faux problème en France.
    Les heures sup non payé sont interdites et aucun employeur ne pourra vous virer pour ça, le cdi protège bien... et quand bien même trouver du travail en informatique c'est facile, il se passe pas 1 semaine sans que je soit contacter.

    faut il refuser de bosser tard en cas de rush exceptionnel ? non, ma philosophie c'est d’être arrangeant envers la boite et réciproquement, quand je dois aller à la préfecture à 11h faire un papier ou un RDV chez le médecin à 9h j'y vais sans poser de congé et je m'arrange avec mon chef, c'est gagnant gagnant tant que ces situations reste exceptionnel.

    les boites qui ne respectent pas leurs salariées, il y'a un turn over important et sur le long terme c'est néfaste pour l'accomplissement des projets.
    Pour moi c'est juste du bon sens, et les managers doivent aussi faire leurs boulot et pas ce laisser écraser par leurs supérieure, il doivent apprendre à dire non quand c'est pas possible. c'est leurs boulot pas de lécher les bottes constamment.

  7. #7
    Membre expert
    Bonsoir,

    Quel est votre avis sur le sujet ?
    Je pense que certains manager sont carrement "maladifes" de leur fonction ... Je suis passé dans plusieurs grosses boites. J'ai déjà vu des managers envoyer des mails le samedi ou dimanche à des heures pas possible , pensant que le mail sera traité le lundi à 7h30 ... Maintenant c'est simple au plus il y a de mail et demande , au moins je traite vite les mails ...

    Ne pas hésiter a envoyer balader séchement quand on vous balance des "urgences" à tous les niveaux. On est ni robot , ni automate ni sur homme. Ne pas hésiter non plus a y aller au culot en partant si les urgences sont grandissantes.

    Histoire d'en recadrer certains.

    Etonnement on arrive vite à ce qu'on nous lâche les baskets.

    Selon vous, l'échéance des tâches oblige-t-elle les ingénieurs informatiques à travailler gratuitement ?
    En avec la hiérarchie pyramidale des managers arrivent à en "offrir du temps pour l'entreprise" . L'entreprise "vous dit merci" ... en fait elle s'en balle les cacahuètes.

    Avez-vous déjà été dans une situation de délai non raisonnable pour accomplir une tâche ? Partagez votre expérience
    Oui en travaillant en banque-services financiers des délais "légaux" de 3 ans non respectés sur des projets réglementaire (ficovie, ficoba , lutte contre la déshérence des comptes...) . En grande distribution générale et spécialisée, des délais intenables pour prendre contact avec des commerciaux ou fournisseurs pour obtenir de la data ... En grande distribution les taux d'insatisfactions d'obtention de la data sont stratosphériques ... car on a "que 80 à 90% de la data bonne ou de disponible" . Forcement les managers mettent un pression de dingue pour arriver à des résultats quasi inatteignable.

  8. #8
    Expert éminent
    Moi c'est simple, je suis en forfait jour.
    Du coup en cas de livraison il m'arrive de commencer tôt et de finir tard.
    Mais à contrario quand il n'y a plus de boulot je rentre chez moi.

    Bon pour les rendez-vous médicaux ou autre par contre on a des RHs qui veulent qu'on pose des demi-RTT... (oui parce qu'au final c'est un faux forfait jour que j'ai, comme beaucoup...)
    Mais bon, à part cet aspect là c'est plutôt pas mal.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  9. #9
    Membre actif
    @transgohan:
    oui, ça s'appelle travailler en bonne intelligence entre manager et ingénieur. Et ça existe.

    Le problème pour un manager qui ne respecte pas les horaires de ces ingénieurs et les fait travailler gratuitement, c'est qu'ils vont simplement partir.
    Après, ils peuvent aussi proposer de gros salaires, et là, libre à ceux qui font des heures sup non rémunérées d'accepter ou non. Et certains vont partir car ils ne veulent passer qu'un temps limité dans l'entreprise, ce qui peut se comprendre si on a une famille par exemple.

    Pour le travail au forfait, ça permet en effet de moduler les amplitudes horaires en fonction de la demande.
    Le problème, c'est que parfois les employeurs oublient que cette modulation peut être à la baisse.
    Le plus simple est quand même d'avoir un certain nombre d'heures rémunérées, et de respecter ces horaires. Ca évite d'avoir un système de jugement biaisé par une perception.

    Pour les évaluations du temps que va prendre un projet, c'est pareil, il faut faire preuve de bon sens des 2 cotés. Et c'est souvent pour cela qu'on a un responsable technique qui peut juger d'un délai trop court au niveau de la demande ou d'un délais trop long du coté de la réponse de l'ingénieur.
    Et ce responsable technique devra prendre en compte que certaines personnes mettent parfois 2 ou 3 fois le temps qu'un autre mettrait. C'est normal, on est pas tous égaux, on est pas tous experts dans tous les domaines, et certain seront plus lents que d'autres.

    Certain ingénieurs vont aussi passer beaucoup de temps sur de la qualité, alors qu'on demande d'aller vite et de faire une qualité moyenne pour un projet (over engennering).
    Certains ingénieurs vont développer très vite alors qu'on a besoin de plus de qualité. (bâclé)
    Certains ingénieurs vont adresser des fonctionnalités non demandées (au cas où) et passer beaucoup plus de temps que prévu.
    Tout cela est à définir si possible au départ, ou à faire évoluer au cours du projet, mais il est préférable d'avoir une interaction régulière pour éviter tous ces écueils.

    C'est toujours bien de donner une approximation du temps que peut prendre une tache, mais il faut que le manager accepte les erreurs sur ce plan.
    Parfois (souvent), on passe plus de temps que prévu. Mais d'autres fois, le manager peut se dire: "l'ingénieur me ballade, il a mis une planning délirant": et puis finalement, c'est l'ingénieur qui a raison.

    Tout ça pour dire qu'il faut qu'il y ait un climat de confiance pour que tout le monde puisse s'exprimer, et tant pis si c'est faux, si on a mis moins ou plus de temps, ça fait partie de la vie d'un projet et il faut pouvoir l'accepter de part et d'autre. Cela permet de s'améliorer et de faire de meilleures estimations à l'avenir.

    Bref, tolérance, confiance réciproque, ça devrait faire partie du manager/ingénieur moderne. Et les projets ne s'en porteront que mieux.
    Хајде Јано коло да играмо

  10. #10
    Membre averti
    Citation Envoyé par transgohan Voir le message
    Moi c'est simple, je suis en forfait jour.
    Du coup en cas de livraison il m'arrive de commencer tôt et de finir tard.
    Mais à contrario quand il n'y a plus de boulot je rentre chez moi.

    Bon pour les rendez-vous médicaux ou autre par contre on a des RHs qui veulent qu'on pose des demi-RTT... (oui parce qu'au final c'est un faux forfait jour que j'ai, comme beaucoup...)
    Mais bon, à part cet aspect là c'est plutôt pas mal.
    Tu dis que c'est plutôt pas mal mais quand on te lit ca semble tout sauf "pas mal"
    t'as un faux forfait jour qui permet juste d'avantager ton patron et quand t'en a vraiment besoin on te demande un RTT ...
    en plus en informatique c'est difficile de justifier le "il n'y a plus de boulot" il y a toujours quelques choses à faire

  11. #11
    Membre confirmé
    Citation Envoyé par SuperCed Voir le message

    travailler en bonne intelligence entre manager et ingénieur. Et ça existe.

    C'est toujours bien de donner une approximation du temps que peut prendre une tache, mais il faut que le manager accepte les erreurs sur ce plan.
    Parfois (souvent), on passe plus de temps que prévu. Mais d'autres fois, le manager peut se dire: "l'ingénieur me ballade, il a mis une planning délirant": et puis finalement, c'est l'ingénieur qui a raison.

    Tout ça pour dire qu'il faut qu'il y ait un climat de confiance pour que tout le monde puisse s'exprimer, et tant pis si c'est faux, si on a mis moins ou plus de temps, ça fait partie de la vie d'un projet et il faut pouvoir l'accepter de part et d'autre. Cela permet de s'améliorer et de faire de meilleures estimations à l'avenir.

    Bref, tolérance, confiance réciproque, ça devrait faire partie du manager/ingénieur moderne. Et les projets ne s'en porteront que mieux.
    Normalement c'est ce qu'il se passe, mais les délires arrivent très souvent avec les managers sortie de grande écoles qui n'ont jamais touché une ligne de code, promettent tout et son contraire enfin de compte ne font que de la politique.

    J'ai été dans une très grosse entreprise plus de 10 000 personnes , avec un service logistique et la direction à jugé bon de faire intervenir l'informatique, aux début ils n'avaient pris que le directeur (j'avoue qu'il avait des bonne idées mais ....) bref la direction général c'est vite aperçue .... ils m'ont demandés de faire partie du groupe, alors les choses ont commencés à changer, des rêves ils sont devenu beaucoup plus pragmatique cela à évité d'une part des dépenses inutiles mais aussi permis de prévoir à longue échéance et d'entreprendre du travail de fond ( on était le site Pilote pour IBM et pour l'Europe), et lorsqu'il y avait un travail hors norme c'était comblé par des vacances et une grosse rallonge.

    Vraiment je garde un excellent souvenir de cette société, et pour elle pas question de faire des heures en veux tu en voilà, il fallait plus que justifier...

    Quand aux travailles hors normes, c'était par exemple 4 jours d'affilés non stop avec 5 ingénieurs IBM on dort sur place etc pendant le 15 août, arrêt de l'entreprise complète les usines, les dépôts l’administration .... la carte bleu de l'entreprise repas seul distraction , puis deux semaines de vacances et un salaire en liquide à la fin du mois pour service rendu et sur toute l'équipe 10 personnes, seulement deux était choisi … bon ce n’ait pas un pc

    c'était pour confirmer ce que tu dis

  12. #12
    Expert éminent
    Citation Envoyé par Chuck 3.50 Voir le message
    Tu dis que c'est plutôt pas mal mais quand on te lit ca semble tout sauf "pas mal"
    t'as un faux forfait jour qui permet juste d'avantager ton patron et quand t'en a vraiment besoin on te demande un RTT ...
    en plus en informatique c'est difficile de justifier le "il n'y a plus de boulot" il y a toujours quelques choses à faire
    Si tu as toujours du boulot, trois hypothèses :
    - tu ne sais pas t'organiser
    - tu n'as pas eu le budget pour le développement demandé et tu fais des heures sup' pour rattraper la bêtise de tes patrons
    - tu flambes le budget qui t'es alloué pour des fonctionnalités non demandées
    Dans les trois cas ce n'est pas la faute de l'employeur (bon la seconde si, mais il ne t'oblige pas le flingue sur la tempe à faire des heures sup' non ?), vois-tu un quatrième cas auquel je n'aurai pas pensé ?



    Mais je ne vois pas pourquoi tu dis que mon commentaire est si négatif que cela...
    Ce soir je quitte le bureau à 16h30, je pense que bon nombre de lecteurs ici m'envieront.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  13. #13
    Expert confirmé
    @transgohan, tu oublies la dette technique. Ce n'est pas tout le monde qui code une application depuis zéro et, parmi ceux qui ne codent pas depuis zéro, c'est rare qu'ils récupèrent un existant bien fait.

    Imagine : tu récupères une application sur laquelle de nombreux développeurs sont passés, il y a 0 test unitaire, l'architecture est moisie, etc. À cause de la dette technique, tout nouveau développement est ralenti, est plus difficile à chiffrer et a plus de risques d'ajouter des bogues.

    Alors, quand les délais sont moins serrés que d'habitude, on en profite pour passer plus de temps à améliorer l'existant.

    De mon côté, j'évite de faire des heures sup. Si je travaille plus longtemps un jour, je travaille moins longtemps un autre jour. Mais, du boulot, j'en ai toujours.

  14. #14
    Expert éminent
    Citation Envoyé par Pyramidev Voir le message
    @transgohan, tu oublies la dette technique. Ce n'est pas tout le monde qui code une application depuis zéro et, parmi ceux qui ne codent pas depuis zéro, c'est rare qu'ils récupèrent un existant bien fait.

    Imagine : tu récupères une application sur laquelle de nombreux développeurs sont passés, il y a 0 test unitaire, l'architecture est moisie, etc. À cause de la dette technique, tout nouveau développement est ralenti, est plus difficile à chiffrer et a plus de risques d'ajouter des bogues.
    Pas besoin de l'imaginer malheureusement car c'est l'image de mon projet.
    Mais on inclut dans le devis tout cela, ce qui permet de ne pas travailler gratuitement pour rattraper la dette technique.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  15. #15
    Membre extrêmement actif
    Quel est votre avis sur le sujet ?

    Je ne suis pas Ingénieur IT, mais pour ceux avec qui j'ai travaillé, ils avaient presque tous un contrat cadre et donc pas vraiment d'horaires mais plutôt des résultats à fournir.
    Partant de là peut-on vraiment parler d' "heures supp" ?
    Si vous acceptez de signer un contrat cadre et donc le salaire et les avantages qui vont avec, il y a forcement une contre partie pour l'employeur, c'est logique.

    Après pour ceux qui sont effectivement salarié, aucune raison de faire des heures si celle-ci ne sont pas payés.
    D'ailleurs, peut-on même parlé d' "heures supplémentaire" puisque ce qui est décrit dans l'article s'apparenterait plutôt à du bénévolat.

    Selon vous, l'échéance des tâches oblige-t-elle les ingénieurs informatiques à travailler gratuitement ?

    Obliger, non. Inciter, visiblement oui, mais ce n'est absolument pas spécifique aux Ingénieurs IT, c'est une méthode de management tout à fait commune.
    Qui, dans un boulot n'as jamais eu des contraintes de temps justifié ou non, absurde ou non ? Réponse : Personne.
    C'est notre société de consommation rapide qui veut ça et c'est notre faute collectivement si cette pratique c'est installé, pas le seule fait des manager / commerciaux.

    Avez-vous déjà été dans une situation de délai non raisonnable pour accomplir une tâche ? Partagez votre expérience

    Bien sur, je ne connais d'ailleurs personne à qui ce ne soit jamais arriver .
    Exemples :
    • Le client super enthousiaste qui vous contact pour un projet, puis annule quelque temps après et en date butoir initiale vous recontacte pour finalement que vous lui fassiez en "express" parce que sont presta la lâché.
    • Le commercial tout comptant de lui (et de ça prime) qui ramène un projet bancale monté sans l'aval de la team technique, avec des délais à faire rêver Emmett "Doc" Brown dans "Retour vers le Future".
    • Le chef de projet qui vous convoque dans sont bureau, soit disant parce-que vous êtes trop lent à implémenter une spec, mais qui fait semblant (j’espère) de ne pas comprendre en réunion quand vous lui expliquer que sont "découpage de tâche" à été fait avec un dès 12 faces et qu'une tâche qui comprend la moitiés des fonctionnalités d'une appli ne met pas le même temps à être implémenter qu'une qui nécessite de modifier une UI de quelques pixels sur la gauche (véridique et merci au pif-o-mètre).
    • Le chef de projet qui veut que vous vous débrouillé pour mettre en prod le prototype que vous aviez montré au client la veille et que vous aviez fait dans un autre but pour vous amuser pendant votre temps libre.
    • ...Liste non exhaustive .

  16. #16
    Membre actif
    Citation Envoyé par Pyramidev Voir le message
    @transgohan, tu oublies la dette technique. Ce n'est pas tout le monde qui code une application depuis zéro et, parmi ceux qui ne codent pas depuis zéro, c'est rare qu'ils récupèrent un existant bien fait.

    Imagine : tu récupères une application sur laquelle de nombreux développeurs sont passés, il y a 0 test unitaire, l'architecture est moisie, etc. À cause de la dette technique, tout nouveau développement est ralenti, est plus difficile à chiffrer et a plus de risques d'ajouter des bogues.

    En effet, comme tu le dis, il est rare de tout reprendre de zero.
    C'est le pire des cas, ton appli que tu récupères, mais ça arrive. Ca se quantifie comme le dit transgohan, et je pense qu'on peut toujours proposer un planning, même s'il est moins précis.

    Enfin, certains projets ont en effet 0 tests unitaires, mais ce n'est pas forcément très grave. Parfois, ils sont très simples, ou bien pensés, ou ne nécessitent pas de tests car non critiques. Dans ce cas, ce n'est pas forcément plus lent à développer qu'un autre projet. Tout dépend des contraintes externes et de l'entreprise. Evidement, pour de l'aéronautique, la question se pose moins, il faudra très certainement des tests auto.
    Parfois, c'est mal conçu, mais il faut faire avec et patcher comme on peut, en essayant de rien casser. Mais ça, un manager est normalement capable de le comprendre. A moins qu'il y ait tellement de modifs qu'il vaut mieux tout ré-écrire... Ca dépend à chaque fois des cas, mais tout s'explique, et le bon sens est souvent d'une aide précieuse, beaucoup plus qu'un dogme ou une méthode.
    Хајде Јано коло да играмо

  17. #17
    Membre éprouvé
    Pour l'aéronautique, les contraintes imposées pour garantir la fiabilité / robustesse du code sont vraiment drastiques. Suffit pas d'avoir quelques tests unitaires.
    Sur Youtube je suis "Le développeur des cavernes"
    https://www.youtube.com/channel/UCSz...bYl_pSNMv_zerQ

  18. #18
    Membre expérimenté
    J'ai toujours respecté mes horaires définis par contrat : si mon patron veut que je travaille plus, il doit payer les heures travaillées. La règle est simple...

    Contrepartie : j'essaye toujours de faire du travail de qualité et je refuse de réaliser un travail médiocre ou mauvais.

    Une fois, cela m'a coûté ma place, les autres fois mes responsables ont apprécié sur la durée...
    La connaissance ne sert que si elle est partagée.
    http://ms2i.net

  19. #19
    Expert éminent
    Pour moi la réponse est clairement NON.

    Ce n'est pas l'échéance mais la quantité de travail qui est en cause.

    Je peux très bien avoir des échéances normales et raisonnable, et avoir une multitudes de tâches à faire.

    Et de mon expérience les ingénieurs IT sont très mauvais pour évaluer la charge. (et je m'inclus dans le lot)

    Je constate trop souvent le même scénario. Un besoin est exprimé et il donne lieu à une spécification. Quand on demande aux ingénieurs eux-mêmes de donner une estimation de charge, ils sont très souvent très en deçà de la réalité.

    Du coup pour les partenaires qui entendent à longueur de temps de telles estimations, cela devient la norme. et on se retrouve avec des échéances aberrantes.

    Mais ce qui surtout fait que ça déraille et qu'on explose les heures sup ce sont les tâches annexes "parfois" non référencés.

    En clair tu travaille de 9h00 à 18h00 avec 1h00 de pause. donc 8h00 de taff.
    Ta tâche fait exactement 8h00. Donc sur le papier toute est normal et l'échéance de 18h00 est logique.
    Mais tu passe 0h30 à répondre au mail, 1h00 en réunion et tu fais 1h00 de support pour les dev que tu as déjà livré et qui sont en production.
    à cela tu ajoute 0H30 à dépanner un autre ingénieur qui rencontre un problème.
    Tu dois aussi rédiger tes rapport d'activités
    et répondre à toutes les sollicitations administratives.
    et là étrangement tu dépasse les 18h00.

    Pour moi le vrai problème est là.

    heureusement la majorité du temps les échéances sont cohérente avec le projet
    et mal heureusement la gestion des resources ignore trop de tâches annexes.

    Il faut dire que pour une boite qui te vend du dev afficher un taux "heures de production/heure de travail" qui est sous les 90% c'est mal vu.
    Alors on vend de la journée d'ingénieur qui exclus tout ou presque et le pauvre gars se retrouve à faire des heures sup s'il veut tenir ces délais.

    A+JYT

  20. #20
    Nouveau Candidat au Club
    cheance-taches-oblige-t-ingenieurs-it-faire-heures-sup-gratuitement/
    Affirmative , Surtout en Guinee ou les heures supplémentaires des Ingénieurs n'est même pas prise en compte dans beaucoup de société, surtout le secteur Bancaire

###raw>template_hook.ano_emploi###