IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Emploi Discussion :

Lire des docs fait-il partie du travail du développeur ?


Sujet :

Emploi

  1. #1
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mai 2020
    Messages
    31
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mai 2020
    Messages : 31
    Points : 57
    Points
    57
    Par défaut Lire des docs fait-il partie du travail du développeur ?
    Salut tout le monde !

    Régulièrement dans le métier de développeur, je suis amené à lire de la doc pour utiliser de nouvelles APIs ou en apprendre plus sur le projet sur lequel je suis (entre autres).
    Certains jours ces tâches de "lecture" prennent peu de temps mais parfois lire de la doc me prend au moins la demi-journée et cela m'inquiète car dans le métier de développeur aujourd'hui tout est tracé : on voit la quantité de travail produite et à quel moment grâce à la gestion de version (git,...), pendant les daily meetings il faut raconter ce qu'on a fait ces derniers temps (et si on a + lu de la doc que touché au clavier on se fait regarder sévèrement par les autres devs ) sans compter le fait qu'on peut vous voir bosser dans l'openspace. D'ailleurs j'ai l'impression que le daily meeting est plus un système de contrôle pour vérifier qu'on travaille qu'autre chose. En plus, je sais pas vous mais j'ai souvent l'impression que partout où je tombe mes collègues donnent l'impression de savoir tout sur tout et regardent vraiment d'un œil sévère les devs qui ne connaissent pas telle ou telle techno.

    Pour contrer cela j'ai donc mis au point une astuce que j'applique depuis que je suis développeur (et que tout le monde fait j'imagine). Quand je suis sur site, à chaque fois que je ne connais pas quelque chose je le note dans mon téléphone pour pouvoir regarder de quoi il s'agit le soir (ou si possible dans les transports pour que ça me fasse perdre moins de temps). Quand je suis en télétravail par contre c'est plus cool car je n'ai pas besoin de faire ça et je me documente pendant le boulot. J'ai néanmoins tendance à faire de plus grosses journées ensuite pour compenser la baisse de productivité.

    Néanmoins je trouve quand même ce rythme crevant (ou alors il faut que ce soit ponctuel). Est-ce qu'au lieu de devoir toujours faire semblant de tout savoir il ne serait pas possible de justifier le fait qu'on ne sache pas quelque chose qui sort du cadre des compétences exigibles et donc prévoir du temps de formation pendant le boulot ? Ne serait-ce qu'une demi-journée par semaine serait suffisante.

    D'autres devs qui vivent aussi le métier de cette manière-là ?

    Et vous ? Vous lisez des docs pendant le temps de travail ou vous considérer que le temps de travail n'est destiné qu'à la production ?

  2. #2
    Membre confirmé
    Homme Profil pro
    Collégien
    Inscrit en
    mai 2012
    Messages
    111
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Collégien
    Secteur : Industrie

    Informations forums :
    Inscription : mai 2012
    Messages : 111
    Points : 488
    Points
    488
    Par défaut
    Bonjour, je pense que lire les doc et se documenter sur le métier avant de développer on appelle cela de l'étude, dans le sprint il doit donc y avoir des tâches d'études qui sont sizé, et regarder le soir comme tu fais c'est des heures supplémentaire non payé donc si tout le monde fait ça (j’espère c'est pas le cas) c'est tout benef pour les patrons

    De mon peu d'expérience l'étude de doc ou d'un sujet avant de commencer un dev est quelque chose de normal dans le métier de développeur et je n’ai JAMAIS vu quelqu'un de mes collègues ne pas utiliser une doc sur un nouveau sujet.

    Peut-être que tes sentiments vis à vis de ton travail sur les docs est plus psychologique, et que tu te sens pas légitime à étudier un sujet car tu penses qu'être dev c'est pisser du code h24, je t'avoue avoir déjà eu ce sentiment au début, car t'as ton déjà fait la remarque en dayly ou après par exemple ?

  3. #3
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 879
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 879
    Points : 18 870
    Points
    18 870
    Par défaut
    Citation Envoyé par Röyksopp Voir le message
    Est-ce qu'au lieu de devoir toujours faire semblant de tout savoir il ne serait pas possible de justifier le fait qu'on ne sache pas quelque chose qui sort du cadre des compétences exigibles et donc prévoir du temps de formation pendant le boulot ? Ne serait-ce qu'une demi-journée par semaine serait suffisante.
    ça faut le demander au management.
    Ce que vous décrivez ça s'apparente au syndrome de l'imposteur déjà décrit sur ce forum.
    Mais j'arrive pas trop bien à saisir la pertinence du message; si vous êtes boulanger et que vous préparez, faites cuire du pain, le principal c'est que le client achète votre pain et apprécie de la manger non ?

  4. #4
    Membre régulier
    Homme Profil pro
    Consultant MOA
    Inscrit en
    mars 2021
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : Consultant MOA
    Secteur : Conseil

    Informations forums :
    Inscription : mars 2021
    Messages : 25
    Points : 78
    Points
    78
    Par défaut
    Bonjour,

    Alors mo je ne suis pas développeur mais AMOA mais partout où je suis intervenu les développeurs ont toujours une phase d'étude et de prise de connaissance donc pour moi cela fait partie du métier Comme dit plus haut ce que vous faites en gros c'est des heures supplémentaires non rémunérés je ne vois pas de raison qui vous empêche de vous documenter pendant vos heures de travail.

  5. #5
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 879
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 879
    Points : 18 870
    Points
    18 870
    Par défaut
    Citation Envoyé par Kiwi15 Voir le message
    Comme dit plus haut ce que vous faites en gros c'est des heures supplémentaires non rémunéré.
    aah un grand merci ! Affirmé ainsi je comprends mieux.
    C'est bien connu "ce que l'on conçoit bien s'énonce clairement" comme dirait l'autre

  6. #6
    Expert éminent
    Avatar de Escapetiger
    Homme Profil pro
    Administrateur système Unix - Linux
    Inscrit en
    juillet 2012
    Messages
    1 269
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Administrateur système Unix - Linux

    Informations forums :
    Inscription : juillet 2012
    Messages : 1 269
    Points : 9 504
    Points
    9 504
    Par défaut
    Citation Envoyé par Röyksopp Voir le message
    Certains jours ces tâches de "lecture" prennent peu de temps mais parfois lire de la doc me prend au moins la demi-journée et cela m'inquiète car dans le métier de développeur aujourd'hui tout est tracé : on voit la quantité de travail produite et à quel moment grâce à la gestion de version (git,...), pendant les daily meetings il faut raconter ce qu'on a fait ces derniers temps (et si on a + lu de la doc que touché au clavier on se fait regarder sévèrement par les autres devs ) sans compter le fait qu'on peut vous voir bosser dans l'openspace. D'ailleurs j'ai l'impression que le daily meeting est plus un système de contrôle pour vérifier qu'on travaille qu'autre chose.
    "À DÉCOUVERT"

    Pour Danièle Linhart, sociologue du travail au Cresppa-CNRS, le contrôle visuel induit par l'open space est plus pesant encore que les difficultés de voisinage. "Sur un plateau, les salariés travaillent en permanence sous l'oeil de leurs collègues et de leurs chefs. Or tout le monde a besoin d'un peu d'ombre, d'un peu d'intimité, d'un peu de quant-à-soi. Il faut, dans une journée de travail, pouvoir, de temps en temps, prendre de la distance, souffler, adopter une posture de dérision. Dans un open space, c'est impossible : il faut au contraire adopter des comportements de façade et revêtir les habits du salarié modèle. Ce contrôle de soi épuise les salariés et nourrit leur stress. Ce n'est sans doute pas un hasard si la question du mal-être est au coeur de nos débats sur le travail."

    Danièle Linhart va même beaucoup plus loin : elle estime que l'open space, dans sa version la plus difficile – les grands plateaux – est le symbole même des dérives du management moderne. "Ce management recherche une relative déstabilisation du salarié car il veut éviter les habitudes ou les routines qui pourraient éloigner des méthodes de travail les plus performantes. Avec sa transparence, l'open space est au coeur de cette stratégie : les salariés sont en concurrence visible, ils travaillent à découvert et comprennent vite qu'il faut se mobiliser et adopter les règles de l'entreprise. L'open space est une manière de planter le décor de la guerre économique."
    Source : Dans la cage de l'open space - Le Monde (2012)

    Danièle Linhart - wikipedia

    et,

    Il y a là de quoi inquiéter. On comprend, à lire l’ouvrage, que la pratique du management repose sur une sorte de myopie morale. La question de la liberté individuelle est évacuée, au profit d’une liberté communautaire largement illusoire. Il engendre aussi l’apparition d’un type humain malheureusement bien connu, celui du manager stressé, suicidaire, bourreau de soi et de ses subordonnés. Il institue une sorte d’état d’exception permanent, dans l’entreprise comme dans l’État, où le droit se meurt, au profit d’un certain culte de la performance et du résultat.

    Surtout, il y a là une perversion abyssale. Parlant de Höhn et consorts, Chapoutot écrit : « Ils ont élaboré, paradoxalement, une conception du travail non autoritaire, où l’employé et l’ouvrier consentent à leur sort et approuvent leur activité, dans un espace de liberté et d’autonomie a priori bien incompatible avec le caractère illibéral du IIIe Reich, une forme de travail “par la joie” qui a prospéré après 1945 et qui nous est familière aujourd’hui à l’heure où l’“engagement”, la “motivation” et l’“implication” sont censés procéder du “plaisir” de travailler et de la “bienveillance” de la structure. »
    Source : Libres d’obéir de Johann Chapoutot | Résumé sur Dygest

    Johann Chapoutot - wikipedia


    Autre source sur developpez, entre autres, pour les deux auteur.e.s cité.e.s ici :

    91 % des responsables des ressources humaines s'inquiètent du taux de rotation du personnel
    50 % des employés des 12 derniers mois ont reçu deux autres offres d'emploi, selon Gartner



    ps
    Tout est tracé/surveillé de nos jours; ç'est valable pour tous les métiers, notamment également, les fonctions autres que les études et développement IT pro
    « Developpez.com est un groupe international de bénévoles dont la motivation est l'entraide au sens large » (incl. forums developpez.net)
    Club des professionnels en informatique

  7. #7
    Membre éprouvé Avatar de Momoth
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2013
    Messages
    317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2013
    Messages : 317
    Points : 1 234
    Points
    1 234
    Par défaut
    Salut,

    Tu soulève pas mal de points différents là.

    Pour ce qui est de lire de la doc, en soit, pour moi ça fait partie du job, que la doc soit technique ou non. Si tu as besoin de lire de la doc pour comprendre ce que tu fais et proposer / implémenter la meilleure des solutions à un problème plutôt que la solution "bête et méchante", fais le. C'est ce qui différencie quelqu'un qui réfléchis et qui fait avancer les choses, d'un simple exécutant.

    Pour ce qui est des collègues qui te regarde de travers car tu lis de la doc plutôt que de pisser du code, il y'a pour moi deux raisons possibles derrière cette attitude :
    - Tu pisse pas de code, du coup tu retarde les devs. Ca veut dire que globalement vous chiffrer pas vos taches de façon safe, et vous serez dans la mouise dès le moindre imprévue. Comme dit plus haut, l'étude doit faire partie du chiffrage.
    - Se documenter, faire de la veille tout ça, globalement, presque tout le monde est d'accord pour dire que c'est important, et presque tout le monde ne prend pas le temps de le faire (pour diverses raisons pas forcément dépendant de leur volonté, et également pour certains par flemme). C'est pas impossible que les autres devs aiment pas trop le fait que tu fasse ce qu'eux ne veulent / peuvent pas faire.
    - Recherche = progression. A force de te documenter, tu vas progresser et donc tu finira par mettre un fossé de connaissance avec tes collègues.

    Globalement, la majorité des soucis avec tes collègues, c'est surtout un problème d'égo mal placé de leur part. Vous formez une équipe et devriez plutôt avancer dans la même direction. Faut en discuter avec eux, mais peut être que le problème est ailleurs (délais, organisation du projet, répartition des responsabilités, etc). Ce qui est sûr, c'est que si vous n'en discutez pas entre vous, rien ne s'arrangera. La rétro sert à ça justement. Pointer les problèmes du doigt, confronter les idées.

    Momoth
    La Triforce du développement : Fainéantise, Curiosité et Imagination.

  8. #8
    Expert éminent sénior
    Avatar de Glutinus
    Homme Profil pro
    Freelance EURL / Business Intelligence ETL
    Inscrit en
    avril 2005
    Messages
    5 649
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance EURL / Business Intelligence ETL
    Secteur : Finance

    Informations forums :
    Inscription : avril 2005
    Messages : 5 649
    Points : 26 787
    Points
    26 787
    Billets dans le blog
    3
    Par défaut
    Bonjour,

    Faire semblant de tout savoir, c'est bon en entretien.
    Une fois sur mission, ne pas hésiter de dire que tu ne comprends pas, que tu ne connais pas. Sauf si bien sûr on t'a recruté pour faire du PHP et tu déclares que tu ne sais pas. Mais si c'est un "plus", une activité annexe, le client aura déjà oublié.

    Et puis sinon, c'est la chose la plus débile à faire que de lire le soir au sujet d'une chose que tu ne sais pas. La veille technologique fait partie de ton boulot. Lire la documentation, surtout.

    Quant au daily meeting, que dire à part que "Oui", c'est pour savoir si tu es sur quelque chose et que tu avances ? Cela semble poser beaucoup de problème le "flicage". Cela ne me dérange pas de dire que je suis sur une tâche en particulier. Ce que j'apprécie moins, c'est les remarques que "cela n'avance pas" au rythme que l'on voudrait ; d'expérience, mes analyses ont souvent permis de gagner beaucoup de temps plutôt que de livrer un patch qui va foutre la prod en carafe.
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!
    ****
    "The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
    ***
    Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019

  9. #9
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mai 2020
    Messages
    31
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mai 2020
    Messages : 31
    Points : 57
    Points
    57
    Par défaut
    Merci pour vos réponses. Je crois avoir compris parmi vos retours que lire de la doc est OK pendant le temps de travail. Là où je me pose plus de question c'est jusqu'à quelle quantité de recherche documentaire un dev est autorisé à faire ? En particulier quand il bloque sur un problème. Ou même lorsqu'il doit apprendre une nouvelle techno qu'on pourrait considérer comme faisant partie de la "base" genre Subversion.

    Dans des cas comme ça on est obligé de mouiller un peu la chemise.

  10. #10
    Expert éminent
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    4 223
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 4 223
    Points : 9 488
    Points
    9 488
    Par défaut
    cela sent à plein nez le junior qui est vendu comme "prestataire" et qui tombe dans 1 équipe d'experts ou de trous de balle.

    Citation Envoyé par Röyksopp Voir le message
    En particulier quand il bloque sur un problème.
    C'est juste 1 truc classique on lit la documentation. En cas de problèmes, Internet et les forums ... peut-être la documentation en interne. Et toujours en cas de problèmes, on demande à ses collègues.
    Et à l'extrème, si tu n'arrives pas à faire le travail, tu demandes à passer à autre chose : tu feras gagner du temps à l'équipe (et tu pourras voir la solution plus tard)


    Citation Envoyé par Röyksopp Voir le message
    Ou même lorsqu'il doit apprendre une nouvelle techno qu'on pourrait considérer comme faisant partie de la "base" genre Subversion.
    Si tu ne sais pas faire 1 [partie du] travail lorsqu'on te l'affecte, il faut que "les chefs" le savent, le planifient et te permettent de te former correctement s'ils le peuvent.


    Citation Envoyé par Röyksopp Voir le message
    Dans des cas comme ça on est obligé de mouiller un peu la chemise.
    En début de carrière ou au démarrage d'1 mission sur 1 nouvelle techno, l'autoformation est nécessaire ... à moins d'être "placardisé"/ "pistonné".
    Mais comme les développeurs sont maintenant en grande partie recrutés/ vendus comme des prestataires, il faut être opérationnel tout de suite.
    T'imagine 1 plombier ou 1 installateur d'équipement par exemple, prendre du temps pour lire les instructions et tester la procédure ... souvent à 25 €uros le quart d'heure.

  11. #11
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 879
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 879
    Points : 18 870
    Points
    18 870
    Par défaut
    Citation Envoyé par Röyksopp Voir le message
    Je crois avoir compris parmi vos retours que lire de la doc est OK pendant le temps de travail. Là où je me pose plus de question c'est jusqu'à quelle quantité de recherche documentaire un dev est autorisé à faire ?
    bah oui c'est préférable ; se documenter ça fait partie de l'activité pro.
    Cependant si vous devez par exemple apprendre Javascript et que vous n'arrivez pas à écrire la moindre ligne de code deux mois après ça va pas le faire comme dirait l'autre
    y'en a qui ont essayé ils ont eu des problèmes

  12. #12
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 747
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 747
    Points : 31 633
    Points
    31 633
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    (.../...) si vous devez par exemple apprendre Javascript et que vous n'arrivez pas à écrire la moindre ligne de code deux mois après ça va pas le faire comme dirait l'autre
    y'en a qui ont essayé ils ont eu des problèmes
    ça peut durer, ça, parfois des années. Mais oui, ça finit toujours mal.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  13. #13
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    mai 2004
    Messages
    10 067
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : mai 2004
    Messages : 10 067
    Points : 27 683
    Points
    27 683
    Par défaut
    Hello,

    Je peux apporter un point de vue de manager, en espérant que ça t'aide. Attention, mon idée du management n'est valable que dans mes équipes, au mieux dans les équipes à côté car on est aligné avec d'autres managers, mais même pas au niveau de mon entreprise -- donc encore moins dans la tienne !

    Un dev qui bosse en dehors de ses heures pour du boulot, ce sont des heures supplémentaires. Mais si c'est à l'initiative de l'employé, ce qui est ton cas, ça n'a pas à être pris en compte.

    Est-ce que tu dois te former sur des APIs / 3rd party / ... ? Oui, bien sûr. Si demain on décide d'utiliser une nouvelle interface, je ne m'attends pas à ce que les devs de l'équipe la connaisse déjà, donc c'est normal qu'ils prennent du temps pour se former.
    Combien ? Ben là, ça dépend du besoin et aussi de chacun. Dans certains cas, 30 minutes sur les principales API et tu en sais assez, dans d'autres tu vas devoir te taper toute la doc pour chercher le paramètre caché dont tu as besoin.

    Pour le reste -- surveillance au daily, collègues qui savent tout et te regardent de travers -- ben... c'set difficile à juger en n'ayant que ton point de vue, mais visiblement cette équipe / ambiance ne te convient pas, donc est-ce que tu l'as rencontrée partout, ou bien uniquement dans cette boite ?
    Si c'est partout, difficile de savoir si c'est pas de chance ou si ça vient de toi.
    Si c'est que dans cette équipe / boite, alors il est peut-être temps de changer ?
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  14. #14
    Expert confirmé Avatar de ed73170
    Homme Profil pro
    Développeur indépendant
    Inscrit en
    mai 2009
    Messages
    744
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur indépendant

    Informations forums :
    Inscription : mai 2009
    Messages : 744
    Points : 5 385
    Points
    5 385
    Par défaut
    Bonjour,

    Citation Envoyé par gangsoleil Voir le message
    Un dev qui bosse en dehors de ses heures pour du boulot, ce sont des heures supplémentaires. Mais si c'est à l'initiative de l'employé, ce qui est ton cas, ça n'a pas à être pris en compte.
    Je ne peux pas laisser passer cette opinion sans réagir : Ton rôle de manager est aussi de t'assurer qu'un développeur ne se sentira pas obligé de faire des heures supplémentaires de sa "propre initiative", ou plutôt à cause de la pression subie par l'encadrement et par des délais bien souvent incohérents imposés par la hiérarchie. Il ne devrait jamais arriver que quelqu'un se sente obligé de travailler chez lui en plus des heures sur place, pour quelque raison que ce soit.

  15. #15
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    mai 2004
    Messages
    10 067
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : mai 2004
    Messages : 10 067
    Points : 27 683
    Points
    27 683
    Par défaut
    Citation Envoyé par ed73170 Voir le message
    Je ne peux pas laisser passer cette opinion sans réagir : Ton rôle de manager est aussi de t'assurer qu'un développeur ne se sentira pas obligé de faire des heures supplémentaires de sa "propre initiative", ou plutôt à cause de la pression subie par l'encadrement et par des délais bien souvent incohérents imposés par la hiérarchie. Il ne devrait jamais arriver que quelqu'un se sente obligé de travailler chez lui en plus des heures sur place, pour quelque raison que ce soit.
    Entièrement d'accord : l'employé n'a pas à le faire, et c'est bien sûr au manager de s'assurer que ce n'est pas le cas. Et si c'est le cas, comme ici, alors le manager doit passer du temps pour comprendre ce qui pousse l'employé à le faire, pour voir ce qui ne va pas et changer cela dans l'équipe / l'organisation -- et non pas aller voir l'employé en lui disant que ce n'est pas bien...
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

Discussions similaires

  1. Réponses: 0
    Dernier message: 23/10/2017, 19h28
  2. Réponses: 4
    Dernier message: 14/03/2015, 14h20
  3. Comment lire des parties d'une page web
    Par Whombat dans le forum Visual Studio
    Réponses: 0
    Dernier message: 17/10/2009, 06h14

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo