En tant que développeurs, nous sommes régulièrement confrontés à des situations difficiles et des fois il n’est pas évident de trouver des échappatoires. Ici nous en avons recensé quelques unes et comment s’en sortir.
Débloque les + belles offres tech en 10 mins
L’idée est ici que bien souvent en entreprise des points chauds (« hotspots ») se créent en terme de pression, pendant que les autres personnes continuent de vous charger car elles ne mesurent rien, étant plutôt en mode « cool ». Il s’agit ici d’apprendre à diminuer la pression sur vous tout en l’augmentant sur d’autres personnes/équipes, afin que chacun ait davantage conscience des enjeux et qu’au final la pression globale diminue, tout en étant bien plus supportable !
Contrairement à ce qu’on pourrait penser, le rôle de point chaud de pression échoit souvent à la personne/aux personnes qui sont pleines de bonne volonté et qui veulent faire avancer les choses, et qui sont pour cette raison considérées comme des pigeons par le reste du monde. C’est triste mais c’est une réalité fréquente.
Vous êtes nommé responsable d’une release du logiciel
Autant dire que c’est la poisse, car le reste du monde va s’orienter vers vous. D’un autre côté dans ce cas les autres équipes vont se dire « bon je m’en fous un peu, au pire c’est le responsable de la release qui va prendre ». Bref il est fort tentant de prendre sur vous et de corriger/niveler le travail des développeurs pour tenter de lisser le tout.
En fait c’est une énorme erreur : d’une part vous allez travailler jusqu’à des heures impossibles pour tenter de tout niveler, d’autre part s’il y a le moindre problème sur la release les développeurs n’hésiteront pas à dire que c’est de votre faute alors qu’en fait ce sont eux les vrais responsables. Il existe pourtant un moyen simple de s’en sortir, même si cela est contre-intuitif pour vous, qui êtes plein de bonne volonté.
Régler, du moins en bonne partie, ce problème
Premièrement, augmentez votre niveau d’exigence vis-à-vis des développeurs. Ceux-ci doivent vous fournir une documentation sur comment déployer leur morceau d’application et comment le tester. Si en appliquant cette documentation ça ne fonctionne pas, n’hésitez pas à leur renvoyer leur travail en mettant en copie dans le mail le monde extérieur. En appliquant cette recette plusieurs fois les choses vont changer, même si au début vous risquez des engueulades. Tenez position, c’est très important.
Deuxièmement, dans le cas où votre organisation dispose d’un outillage spécifique (ou s’il y a des questions récurrentes), documentez l’ensemble au maximum. L’idée est que si on vient vous demander du support, vous pourrez renvoyer les gens vers la documentation, vous épargnant ainsi une somme de travail conséquente. De même dans le cas d’un outil interne, rendez les messages d’erreur lisibles, de façon à ce que les gens ne se posent pas de question. Aussi, dans la documentation fournissez une FAQ du type « je rencontre tel message d’erreur, voici la marche à suivre ». Faire tout ceci peut sembler être un investissement conséquent, mais il s’agit bien d’un investissement qui vous libèrera.
Pour pouvoir travailler, vous avez besoin de l’outil XXX
Pour imager le problème, on vous donne un marteau et votre mission est d’installer des vis. Le premier réflexe (et ce que tenteront de vous dire vos chefs) est tant pis, essayez de vous battre avec le marteau pour planter les vis. Et comme ça ne va pas marcher la pression augmentera sur vous, alors qu’au final le responsable est l’équipe qui ne veut pas vous fournir le tournevis. (Ne riez pas, dans mon expérience professionnelle à une époque j’ai eu le cas, j’avais besoin de 2 Go de RAM supplémentaires et il m’a fallu faire une quête pour les obtenir car mon chef de l’époque ne voulait rien entendre…)
Si la gêne occasionnée est légère ou lourde
Il existe deux possibilités : soit la gêne est légère et vous pouvez tout de même continuer à travailler dans des conditions acceptables, c’est-à-dire sans être bloqué des heures pour attendre qu’une tâche se termine, soit la gêne est lourde ou vous devez transgresser un interdit de l’entreprise pour travailler.
Si la gêne est acceptable, vous pouvez vous contenter d’envoyer des mails en mettant suffisamment de monde en copie pour pousser les gens à réagir. En effet dans nombre d’organisations si vous ne mettez pas tel ou tel grand chef en copie les gens ne bougeront pas.
Maintenant si le problème est bloquant, par exemple vous ne pouvez travailler sans un nouveau serveur pour telle ou telle raison, ou vous devez contourner la sécurité, arrêtez de travailler sur la tâche tant que le problème n’est pas réglé. Par exemple si vous avez besoin davantage d’espace disque sur un serveur, levez un ticket de support chaque fois que vous êtes confronté au problème en mettant les chefs en copie. Ne tentez pas de jouer la conciliation, ça se retournera contre vous. Là encore ça peut être un moment difficile à passer mais au final vous serez le gagnant.
Dernier point à ne pas oublier : l’employeur est tenu de vous fournir le matériel adéquat pour travailler. Ce n’est pas moi qui le dis, mais des experts juridiques et donc probablement le code du travail derrière.
Vous êtes le superman de l’organisation
Vous êtes la personne reconnue techniquement et qu’on appellera à chaque urgence. Bref dans ce genre de cas, c’est vous qui devrez faire des heures impossibles pour corriger les problèmes pendant que les vrais responsables pourront se la couler douce. Il s’agit d’une position très inconfortable car l’organisation ne vous utilise pas pour les sujets les plus intéressants : vous nettoyez les égouts et en prime, à la fin de l’année, on vous reprochera les fois où vous n’avez pas pu corriger entièrement le problème pour vous refuser des augmentations. Et pour la petite histoire : oui, dans bien des organisations si vous avez un niveau bien meilleur que le reste des gens dans neuf cas sur dix ça vous desservira, car vous serez là pour passer le balai…
Le gestionnaire de versions est votre ami
Soyez intraitable : vous voulez bien aider, mais pas être le pigeon. Ici le gestionnaire de versions (SVN, Git, …) est votre allié. Il ne faut pas hésiter à faire rester toutes les personnes qui auront travaillé sur tel ou tel sujet, ainsi que les chefs qui vous ont demandé de rester. Pour ce dernier point c’est très simple : si le chef s’en va prétextant une quelconque obligation, indiquez vous aussi un empêchement et partez au même moment, on ne vous aura pas deux fois. Certes vous aurez deux ou trois soirées qui vont sauter à cause de ça, mais les gens à terme deviendront bien plus responsables et n’attendront pas le dernier moment pour corriger le problème.
Pour la petite histoire j’ai connu une organisation où il y avait toute une équipe de supermen/women qui devait rester tous les soirs jusqu’à minuit pour corriger les problèmes récurrents de l’application qui en gros détruisait ses propres données. Et quand ils demandaient à vraiment corriger l’application, on leur répondait qu’il n’y a pas le budget, encore une organisation qui ne voit pas plus loin que le bout de son nez… Bref le matin ils arrivaient naturellement plus tard. Et un jour ils ont été convoqués car ils n’étaient pas au bureau à 9h30 et que c’était inadmissible car ils désorganisaient tout. Au final 80% de l’équipe est partie dans l’année.
Le mot de la fin !
Ces petites recettes sont contre nature, elles vous vaudront sûrement quelques engueulades pour essayer de vous faire céder, mais ne cédez en aucun cas. Pour la petite histoire les méthodes agiles ont justement pour but de diminuer la pression sur les gens et d’éviter d’avoir des points chauds. De même, adopter le continuous delivery peut vraiment aider sur le long terme, mais là encore ça dépend de la personne qui est en face. Et les tendances court-termistes actuelles n’aident pas vraiment…
Cet article vous a plu ? Vous aimerez sûrement aussi :
- La démarche devops
- Le métier de chef de projet technique par rapport au métier de développeur
- Soyez (vraiment…) agiles
- Les tests automatisés
Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.
Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
