Voici la troisième et dernière partie de cette catharsis sous forme humoristique. Les intégrateurs et les développeurs ont déjà fait les frais, au tour des gestionnaires.
En terme de gestion, l’exemple de Michael Scott est aussi valable pour un projet web. La toxicité de l’environnement de travail va permettre au projet de s’enliser mais également de faire partir les meilleurs éléments vers un environnement moins toxique. Si un employé peut emmener de la toxicité, la meilleure personne pour le faire reste un manager.
Gestion de l’équipe
Si vous êtes manager et que vous avez atterri ici par accident, voici quelques conseils pour minimiser les gains de votre e-commerce grâce à des performances exécrables. Il faut savoir que tous les développeurs se valent. Un stagiaire avec ChatGPT (voire CoPilot si l’entreprise est prête à faire des efforts financiers conséquents) doit pouvoir faire la même chose qu’un développeur sénior pour 4 à 5 fois moins cher. N’oubliez pas que la précarité financière permet de garder la mainmise sur un junior. Ne le formez surtout pas, il vaut mieux le laisser galérer quelques mois sur Magento 2 que de lui payer une formation puisqu’il va partir très vite.
Viser le turnover le plus rapide
Afin d’être sûr d’avoir un turnover qui permette d’atteindre vos buts en termes de pauvreté des performances, gardez les salaires au plus bas de ce que permet la convention collective. Si vos activités sont multiples, n’hésitez pas à prendre la convention collective la plus désavantageuse pour vos développeurs (et vos salariés en général). Un turnover élevé évite d’avoir des personnes qui gardent l’historique du projet. L’historique du projet permet à l’équipe d’être plus efficace et ce n’est absolument pas le but. Ne permettez que le présentiel ou le distanciel. Soyez à cheval sur les horaires de travail (enfin surtout celles d’arrivée). Une mauvaise politique salariale groupé à un environnement de travail rigide est un bon moyen d’augmenter votre turnover. Cela permet également de se couper de certains profils intéressants.
Pour le on-boarding, il est nécessaire de ne prévoir aucune ressource pour accueillir la recrue. Le mieux est que la personne remplacée soit déjà partie. Cela permet une césure et évite que la recrue ne sache trop de choses qui lui permettent d’être efficace. Le mieux est de prévoir un document de quarante pages sur son bureau afin de le faire patienter deux jours en attendant que le poste de travail soit mis en place.
A ce sujet-là, il faut essayer d’avoir une gestion des droits très complexe afin que la recrue ne puisse pas avoir accès au dépôt ou au gestionnaire de tickets avant plusieurs jours. Dans les meilleures équipes, la personne en charge de la gestion des droits arrive à les ouvrir après que la recrue soit partie voir ailleurs. Ca parait un peu bizarre comme approche mais ça permet de ne garder que les plus motivés.
Créer un environnement exécrable
Les blagues sexistes, racistes ou les deux sont un bon ciment pour l’équipe. Attention quand même à ne pas viser trop souvent la même personne pour ne pas vous retrouver au tribunal pour harcèlement. Vous pourrez toujours argüer qu’on ne peut plus rien dire si un membre de l’équipe vous fait remarquer que vos propos sont déplacés.
Organisez des journées de team building qui vous correspondent. Vous adorez le golf ? Quoi de mieux qu’un 18 trous pour montrer votre swing devant des débutants qui s’ennuient. La haine commune du manager peut également être une façon de souder l’équipe. Ne la consultez pas en amont pour juger de leurs goûts et proposer différentes activités qui pourrait fédérer. C’est vous le chef, faites-leur comprendre.
Gestion de projet
Préférez toujours les demandes du marketing à celle de l’équipe technique. Ce chaton qui apparait en bas de l’écran quand on clique sur « ajouter au panier » devrait permettre d’augmenter les ventes de manière considérable. Certes, il faudrait comprendre pourquoi ledit panier met deux minutes à s’afficher mais le petit chaton permet de patienter de manière conviviale.
L’assurance qualité coute cher. Il n’est que rarement nécessaire d’avoir recours à une équipe spécialisée pour tester. Cela peut être fait par n’importe qui. D’ailleurs qui de mieux que le demandeur pour tester la fonctionnalité ? Bien sûr, la personne ne devra tester que sa fonctionnalité. Cela a un effet bénéfique en terme de perte de performance car elle ne verra pas ce nouveau bug dans le panier qui fait bouger le bouton « passer la commande » au survol. Ce n’est qu’au bout de deux jours de pertes de chiffres d’affaire qu’il faut s’intéresser à tester le site.
Les réunions
Faites un maximum de réunions ! Le temps que les développeurs passent en réunion, ils ne le passent pas à développer. Les réunions impromptues sont les meilleures car elles coupent efficacement la concentration. N’hésitez d’ailleurs pas à leur mettre la pression en comptant le temps de réunion comme du temps de développement. Les réunions doivent vous permettre de justifier votre salaire de chef de projet, pas de faire avancer le projet.
Ne préparez surtout pas la réunion en amont et évitez de donner un ordre du jour car cela pourrait permettre à certains d’éviter la réunion en disant que ça ne les concerne pas. A ce sujet, il est important de convoquer un maximum de personnes à n’importe quelle réunion.
Michael Scott’s tip : débarquez dans l’open space et demandez l’attention de toute l’équipe sur n’importe quel sujet.
Si un jour vous vous embêtez, une bonne façon de passer le temps est de faire une présentation en PowerPoint. Le sujet importe peu mais faites des petites animations rigolotes.
Les deux façons d’externaliser les échecs
La plus simple reste d’avoir recours à cet indien qui vous a contacté sur LinkedIn un dimanche soir dans un anglais approximatif. Cette personne n’a pas besoin de parler anglais mais de faire du développement. Vous verrez très vite qu’il est à la tête d’une équipe de développeurs qui ne parlent ni anglais, ni PHP. Le Java adapté au PHP donne de très bons résultats en terme de perte de performances. C’est notamment vrai dans la gestion de tableaux complexes. Une bonne occasion pour augmenter significativement le temps d’importation des produits.
Si vous suivez une équipe de sport, vous devez penser « on a gagné » quand vos favoris gagnent et « ils ont perdus » quand c’est le contraire. Vous devez faire de même dans votre gestion au quotidien. Le mieux est encore d’être agressif dans le cas où un bug apparaitrait en production et de vous attribuer personnellement n’importe quel succès en oubliant totalement le travail de l’équipe. En appliquant cela à n’importe quelle circonstance, vous devriez rapidement réussir à faire partir les développeurs les plus investis pour ne garder que ceux qui n’en ont rien à foute.
Agile
Un tournevis pour enfoncer un clou reste l’outil le plus efficace si vous voulez passer l’après-midi à enfoncer ledit clou. Il en est de même pour n’importe quel outil de gestion de projet.
Jira (ou n’importe quel autre outil de gestion de tickets).
« Bientôt, on pourra décrire ce qu’on veut et l’intelligence artificielle créera le programme ».
Quand un développeur entend cette phrase, il se dit qu’il a encore de beaux jours devant lui. Un ticket ne doit surtout pas être pensé comme une explication claire du problème rencontré ou de la fonctionnalité à ajouter. Un titre doit être largement suffisant pour qu’un développeur comprenne ce qu’il faut faire. N’hésitez pas à mettre des captures d’écran d’une page blanche en commentant : « ça marche pas ». Votre travail en tant que gestionnaire de projet pourrait être de qualifier les tickets mais le team building à la machine à café est nettement plus intéressant. Il est donc préférable de permettre à n’importe qui de créer et d’affecter les tickets sans passer par vous. C’est aussi ça être agile, supprimer les intermédiaires. Enfin, n’hésiter pas à râler dès que l’estimation originale est dépassée.
Un tableau kanban doit être le plus complexe possible et l’explication du flux de production doit être décrit dans le document dont j’ai parlé dans la première section. N’hésitez pas disqualifier un ticket qui ne se trouve pas dans le bon statut. Ca fait perdre du temps à tout le monde sauf à vous qui justifiez votre salaire grâce à cette gestion de projet.
Maquettes
Le but d’une organisation agile est de faciliter les échanges entre donneurs d’ordres et exécutants. Quoi de mieux que le design pour pouvoir discuter. L’idée doit être claire dans votre tête mais ne la posez pas sur papier (façon de parler). Expliquez les grandes lignes dans un ticket ou mieux, de vive voix. Si vous êtes magnanime, vous pouvez mettre vos idées en forme en choisissant l’outil adapté.
PowerPoint est un outil pour faire des présentations mais il remplace efficacement Canva ou InDesign. Il permet de faire perdre du temps à n’importe quel intégrateur qui voudrait savoir quelle couleur utiliser, connaître la taille exacte d’un élément ou savoir quelle animation mettre sur un bouton. Par ailleurs, votre entreprise vous fourni la suite office, ce n’est pas pour rien. Mettez des slides dans les tickets les plus simples pour montrer votre bonne volonté.
Scrum
Ne me demandez pas pourquoi mais quand j’entends Scrum, je pense à Gruumsh, le dieu chaotique mauvais des orcs dans Donjons et Dragons. Cela vient sans doute du fait que la première fois qu’un scrum master a su m’expliquer clairement quel était son travail, c’était en janvier dernier. D’ailleurs, ce n’était pas son rôle principal. Il était lead dev.
Ne comptez pas sur moi pour vous expliquer en quoi consiste la méthode Scrum, ça vous ferez gagner du temps et ce n’est clairement pas le but de cet article. Cependant, je suis quelqu’un de plutôt sympa et pour vous éviter d’aller sur wikipedia, voici la définition qui y est donné de scrum.
Scrum est un framework ou cadre de développement de produits complexes. Il est défini par ses créateurs comme un « cadre de travail holistique itératif qui se concentre sur les buts communs en livrant de manière productive et créative des produits de la plus grande valeur possible ».
Si comme moi avant cette rencontre, vous n’avez rien compris à ce qu’était scrum n’hésitez pas à faire perdre du temps à votre équipe grâce à cela. Vous sentez que c’est un framework indispensable dans une gestion de projet cool et, à l’instar de Michael Scott, vous êtes quelqu’un de cool. Multipliez les réunions pour expliquer ce que vous n’avez pas compris vous-même. Utilisez les termes « holisme« , « sprint » ou « méthode RAD » sans avoir vraiment compris ce qui se cache derrière ces termes. Pour vous aider, je vous donner la définition de holisme de wikipedia.
Le holisme est « la tendance dans la nature à constituer des ensembles qui sont supérieurs à la somme de leurs parties, au travers de l’évolution créatrice ».
Conclusion
Depuis les quelques années que je bosse sur des projets web, j’ai vu beaucoup de choses mais pas toutes au même endroit. J’aurais aussi pu parler de l’abus d’anglicismes et d’acronymes mais je trouve que Kevin Duval le fait beaucoup mieux que moi.
Laisser un commentaire
Vous devez vous connecter pour publier un commentaire.