Équilibre entre la charge de travail et l'aide aux nouveaux employés [fermé]

J'occupe mon premier emploi depuis environ 2 mois et j'ai commencé à remarquer qu'il y a un équilibre délicat entre la charge de travail et l'aide aux nouveaux embauchés. Puisqu'il y a beaucoup de pression de la part de la direction pour corriger les bogues et résoudre autant de problèmes que possible, tout le monde dans l'équipe semble être très concentré sur son arriéré de travail au lieu d'aider les nouveaux employés à se mettre au courant. Les nouveaux employés peuvent poser des questions et parfois nous demanderons à un développeur de nous asseoir et de nous aider, mais nous obtiendrons souvent une réponse obscure que seul un vétéran du produit comprendrait car il est trop occupé par sa tâche.

Je comprends que le nouvel employé doit également maintenir un équilibre. Parfois, il faudra 3 jours à un nouvel employé pour enquêter et réparer quelque chose où un ancien combattant aurait pu le faire en 20 minutes. Les nouveaux employés doivent faire preuve d'efforts pour apprendre le produit et la base de code.

Sans réduire simplement la charge de travail des anciens combattants, comment pouvez-vous trouver un équilibre entre aider les nouveaux embauchés et continuer à travailler sur votre arriéré à un rythme raisonnable?

Je suppose que vous posez cette question du point de vue de la «nouvelle embauche». J'ai été dans cette situation plusieurs fois. Parfois, vous vous sentez mal de poser autant de questions, mais il n'y a vraiment aucun moyen de trouver la solution parfois avec un tel manque de connaissance du domaine, etc.

La chose la plus importante à retenir est la suivante. Ne posez pas de questions lorsque vous "supposez" que vous ne pourrez pas trouver la réponse vous-même. Essayez les choses, fouillez d'abord, examinez le code, essayez de changer certaines choses et voyez ce qui se passe - voyez si vous pouvez faire fonctionner quelque chose en premier. Si vous ne pouvez vraiment pas, posez votre question. Cependant, lorsque vous posez votre question, allez-y avec des exemples de ce que vous avez déjà essayé. Aucun d'entre eux ne veut avoir l'impression que vous lui demandez de faire votre travail pour vous.

Dis: "Hé, j'essaye de faire ça, et j'ai essayé ça, ça, et ça déjà, as-tu des idées?" Cela les aidera à passer moins de temps sur vous et ils seront plus enclins à le faire.

Dans notre entreprise, nous assignons à chaque nouveau venu quelqu'un pour s'occuper de lui pendant les premiers mois. Avec cette affectation formelle, nous nous assurons que le débutant ne consommera qu'une seule personne et que la personne qui "encadre" le nouvel employé a la responsabilité de son développement, donc ce n'est pas un fardeau, juste une responsabilité temporaire. Pour le nouveau mec c'est bien car il apprend plus vite et pour le mec qui est déjà il y a un investissement: en moins de temps il aura quelqu'un pour l'aider.

Le meilleur conseil que je puisse vous donner est de prendre rendez-vous . Tout le monde a des temps d'arrêt pendant la journée, mais si vous venez simplement au hasard, il est très peu probable que vous le frappiez. Dites quelque chose comme: "J'ai des questions sur X, puis-je prendre un peu de temps aujourd'hui pour en parler avec vous?" Ils pourraient décider de vous donner du temps tout de suite, ou plus tard dans la journée, ou peut-être vous référer à quelqu'un qui pourrait être en mesure de répondre à votre question mieux ou plus rapidement. De toute façon, vous allez obtenir une attention plus concentrée. S'ils vous donnent rendez-vous plus tard dans la journée, utilisez le temps qui vous reste pour essayer de trouver la réponse par vous-même, ou du moins pour affiner la question. Même si je reporte la question de quelqu'un pour seulement 15 minutes, le plus souvent, ils le découvrent d'eux-mêmes.

Sachez simplement que pour la plupart d'entre nous, vos questions sont importantes pour nous, elles ne sont généralement pas urgentes . Essayez de ne pas vous offenser de la différence.

Certains des codeurs les plus expérimentés aiment encadrer les jeunes développeurs et en font une priorité. Je le fais, chaque fois que j'en ai l'occasion. Vous pouvez peut-être trouver quelqu'un comme ça dans votre entreprise en demandant à un collègue différent chaque fois que vous avez besoin d'aide, puis en évaluant leur enthousiasme en vous répondant.

Il y a deux façons dont vous pourriez avoir besoin d'aide: s'il s'agit d'un problème avec la langue ou vos outils, vous pouvez souvent trouver les réponses en ligne ou en achetant des livres techniques et en les lisant à votre propre rythme. Alors que vous seriez raisonnable de penser que c'est la responsabilité de l'entreprise de vous former, très peu d'entreprises investissent beaucoup dans la formation. Si vous voulez vous développer en tant que développeur, vous devez investir du temps et de l'argent pour vous former lorsque vous n'êtes pas au travail.

Si votre question concerne le produit de votre entreprise, comme la façon dont quelque chose fonctionne dans le code source, il est plus probable que vous n'aurez qu'à demander de l'aide à l'un de vos collègues. Alternativement, créez une branche du code de votre produit dans votre système de contrôle des révisions, nommez la branche quelque chose comme "learning_new_code" et expérimentez simplement avec.

Enfin, les chefs de projet et les chefs de service sont là pour vous aider avec des problèmes comme le vôtre. Si vous sentez que vous n'avez pas d'autre recours que d'obtenir du temps de vos collègues plus expérimentés, mais qu'ils ne sont pas en mesure de vous le donner, c'est peut-être parce qu'ils ont des délais à respecter. Peut-être que votre manager prolongera ses délais afin de lui donner plus de temps pour vous mettre au courant.

J'ai la chance de travailler actuellement quelque part ce n'est pas un problème. J'ai reçu une bonne dose de mentorat ici, et j'en suis très satisfait.

1. Chaque jour, un développeur de mon entreprise est le développeur "util", à tour de rôle. Le développeur Util est la première ligne de contact lorsque le support doit escalader quelque chose. Fréquemment, Util passe simplement un problème à quelqu'un d'autre. Mais c'est un développeur spécifique et le support sait s'adresser à cette personne. J'ai fait quelques "accompagnements" au début (ils ne m'ont pas mis dans le programme pendant un petit moment) pour voir comment certains problèmes étaient traités. Cela m'a exposé à des portions de code. Lorsqu'ils ont commencé à planifier mes jours d'utilisation habituels, il y avait d'abord quelqu'un "sur appel" pour ajouter une assistance supplémentaire.

2. Nous nous associons. Vous devez planifier le temps de paire, à peu près, mais tout le monde ici est prêt à le faire. De plus, tout le monde sait quel est le calendrier et grâce au point suivant, il a une idée de la progression de chaque individu. Donc, s'il y a un problème, il reçoit l'attention voulue.

3. Chaque jour, nous organisons une réunion debout à 11 h 45. C'est 15-20 minutes. Chaque développeur / personne QA parle. C'est essentiellement une façon de dire "c'est ce que je fais et c'est là que je suis coincé", et si vous êtes coincé, vous êtes généralement pointé dans une autre direction (s'il s'agit d'un problème connu / d'un problème avec le code, quelqu'un est très familier avec) ou le temps de paire est configuré. Parfois, une réunion supplémentaire est prévue.

4. J'ai dû plonger dans du code complètement étranger plusieurs fois ici (comme avec n'importe quel travail). Quelqu'un a toujours été sûr de se rendre disponible pour répondre aux questions, sinon tout de suite.

J'en ferai écho aux autres: prévoyez du temps de réunion pour poser des questions si possible. Identifiant qui n'est toujours pas utile. . . eh bien je ne veux pas devenir extrême ici. Mais je ne considère pas cela comme un lieu de travail idéal. Est-il possible que des gens s'échauffent encore avec vous / maîtrisent vos capacités / etc?

Je soupçonne que le temps supplémentaire passé à mon arrivée à bord était facilement justifié, car une fois que les gens sentaient que j'étais à la hauteur, cela signifiait évidemment moins de travail pour eux. Plus de temps passé à court terme a permis d'économiser beaucoup de temps à long terme, et tout le monde l'a compris là où je travaille. J'ai beaucoup de chance dans mon poste actuel.

Il s'agit souvent plus d'une question de concentration que de temps. Planifiez des réunions de 30 à 45 minutes avec votre chef d'équipe ou votre mentor (avant ou après le déjeuner, c'est toujours ma préférence - mon flux se brise déjà à ce moment-là) quelques fois par semaine et conservez vos questions pour cela.

La plupart des développeurs (ou, du moins, ceux qui sont les plus susceptibles d'être utiles lors de la réunion) seront d'accord avec cela.

S'il y a un détail très spécifique qui bloque votre progression, utilisez l'e-mail.