Accueil |  Humour | Macintosh | Print66 | Sélection | Éditeur 

Il y a les über-geeks et les autres

Comment motiver des programmeurs ?

Question posée sur Slashdot : comment motiver les autres développeurs d'une équipe ?

3flp demande: «nous avons tous entendu parler de ces projets de développement où 90% du code est écrit par une personne. Malheureusement, sur le projet sur lequel je travaille actuellement, c'est moi :-(. C'est un projet de télécoms impliquant des DSP avec beaucoup de C et un peu d'assembleur. Mon équipe de 4 produira si tout va bien environ 20k de lignes de code. Voilà maintenant le problème : nous venons d'arriver à notre première petite étape d'intégration (nous essayons de les faire tôt et fréquemment), et il s'avère que les autres types n'ont rien produit. Aucun code. Je voudrais demander aux Slashdotters, aux gens qui ont l'expérience de petits projets de logiciel, comment aborderiez-vous cela ? Comment emmener d'autres développeurs moins expérimentés jusqu'à votre niveau et au-delà ? Ou au moins comment les inciter à être moins nuls, et si ils bloquent sur quelque chose, à venir simplement demander de l'aide ?» C'est quelque chose que presque tout développeur a dû traiter. Parmi ceux qui ont connu cette expérience, qu'avez-vous fait et comment les choses ont-elles tourné ?

«Les dates-limites sont super-serrées (rien de neuf sous le soleil)... mais toutes "mes" parties sont dans les temps, et j'aime ce que je fais. Après environ un mois de conception et deux semaines de codage, j'ai réalisé environ 50% de mes fonctionnalités logicielles. Les autres certainement comprennent les spécifications et la conception, parce que nous avons eu beaucoup de discussions. "Bien, voyons ce que vous avez jusqu'ici, nous essayerons juste les interfaces, même si votre code ne fait encore rien d'autre". "Je n'ai pas encore essayé de le compiler." Alors j'ai regardé le peu de code qu'ils ont produit, et c'est un désastre (style de codage abominable, sérieuses erreurs logiques, etc..). De toutes évidences, ces types comprennent la problématique "métier" (je penserais que c'est la partie la plus difficile), mais sont nuls en ce qui concerne le codage (qui est apparemment la partie vraiment dure pour eux). »

«Engager de nouvelles personnes aussi tard dans le projet ne marchera pas, comme n'importe qui qui a lu "le mythique mois-homme" le sait. Sur ce projet, j'ai un rôle de-facto de chef de projet logiciel. Avant, j'ai toujours été un simple développeur, non responsable des autres. Alors ok, je fais très bien ma partie de codage, mais pour l'instant c'est inutilisable. Si les autres ne rattrapent pas rapidement, nous aurons des problèmes sérieux pour livrer à temps. Je dois cesser de perfectionner "ma" partie de code, et aider ailleurs. Ils comprennent certainement les spécifications techniques et la conception, parce que nous avons eu d'abondantes discussions. "Bien, voyons ce que vous avez jusqu'ici, nous essayerons juste les interfaces, même si votre code ne fait encore rien d'autre". "Je n'ai pas encore essayé de le compiler." Alors j'ai regardé le peu de code qu'ils ont produit, et c'est un désastre (style de codage abominable, sérieuses erreurs logiques, etc..). De toutes évidences, ces types comprennent la problématique "métier" (je penserais que c'est la partie la plus difficile), mais sont nuls en ce qui concerne le codage (qui est apparemment la partie vraiment dure pour eux). »

«Évidemment, je dois trouver une certaine manière d'aider ou de motiver, mais sans les abattre. Je pourrais juste prendre en main le module d'un autre et le coder en un rien de temps. Mais si quelqu'un me faisait ça à moi... ce serait inadmissible. »

Une remarquable leçon de management me semble être contenue dans ce message de réponse :

Après 15 ans dans l'industrie, je dirais qu'il y a trois classes de réalisateurs de logiciel:

  1. Le codeur né. C'est la personne avec une connaissance intuitive de la technologie, qui voit immédiatemment les similitudes dans des architectures logicielles et réutilise des concepts à travers des technologies disparates. Hélas elles sont rares, peut-être 1 développeur sur 10 peut être traité ainsi.
  2. Le programmeur "Gérard le régulier". La grande majorité du personnel de helpdesk, d'auteurs de documentation, etc. sont du type "Gérard le régulier". Ils font le travail, ils respectent les instructions et les spécifications, mais ne sont pas nécessairement créatifs ou intuitifs à propos de leur travail. Ils forment la population qui constitue l'infrastructure des entreprises, et environ 7 programmeurs sur 10 tombent dans cette catégorie. Ils sont beaucoup plus lents que les codeurs nés, mais arrivent à ce que le travail aboutisse.
  3. Ceux qui essayent mais n'y voient goutte. Heureusement il n'y a pas eu un trop grand nombre de ces derniers sur les projets sur lesquels j'ai travaillé, mais il restent plus nombreux que les codeurs nés -- je dirais environ 2 sur 10.

Le texte à l'origine de cette discussion indique que son auteur est un programmeur relativement jeune ou naïf, qui est soit un codeur né, soit un "Gérard le régulier" avec un ego surdimensionné. Qu'il soit l'un ou l'autre, je devine qu'il est rapide à saisir des concepts et des idées, et devient facilement frustré face à des personnes qui sont moins rapides que lui -- et le montre. Même si de telles personnes essayent d'être compréhensives, ou sont "ouvertes" aux questions, la manière dont elles expriment leurs réponses intimide souvent leurs collègues.

Vous devez vous assurer que les gens comprennent que le projet est vraiment un effort d'équipe, pas un jeu de blâme, et encourager les questions. Si personne ne pose des questions, vérifiez avec eux chaque jour comment ça avance, mais présentez cela comme une proposition d'aide ou un moyen de clarifier les spécifications plutôt qu'une simple requête sur l'avancement du projet.

Apprenez les qualifications de votre personnel. Ceux qui ne peuvent pas coder sont souvent bons à d'autres choses -- tests et corrections, dessin d'écran, gestion de versions, etc... Rares sont les personnes vraiment inutiles, elles ne sont tout simplement pas nécessairement adaptées à ce qui leur a été assigné.

En travaillant avec une équipe de jeunes, commencez d'abord par créer le contour du code -- fichiers makefile, en-têtes d'interface, et squelette de code. N'entrez pas dans les détails de votre code -- assurez-vous que le projet global a été décrit. Cela aide beaucoup les jeunes d'avoir une interface solide sur laquelle ils doivent s'appuyer pour développer, et cela facilite la modularité du code.

Quand les gens posent des questions, ne leur donnez pas la réponse, même si vous savez. Je suis sérieux ! Guidez-les avec des questions qui mènent à la réponse, mais laissez-les fournir la solution si c'est possible. Ceci les aide à apprendre comment penser (vos questions indiquent ce qu'ils devraient se demander et penser), et en trouvant les solutions "par eux-mêmes", ils gagnent en confiance.

Ignorez tous les messages que vous avez vus au sujet de la fourniture de bière, des pizza parties, et des menaces de licenciement ou de retrait du projet. Vous ne réussirez jamais un projet en gaspillant votre temps et votre budget sur des excitations ou en transformant votre personnel en épaves stressées.

Si vous tombez sur un "développeur" qui n'y voit goutte et qui devient véritablement inutile ou qui juste "n'y arrive pas", assurez-vous qu'il travaille à quelque chose de non critique et que son accès est restreint. Si vous devez le garder sur le projet, essayez de l'employer sur les tests ou sur le "travail de grognement" comme la gestion de versions. Même les personnes qui n'y voient goutte peuvent suivre une liste de contrôle pour tester un logiciel ou compiler du code, et parfois ils peuvent devenir réellement bons à cela. Croyez-le ou non, vous avez besoin de personnes qui aiment faire du travail peu exigeant intellectuellement -- l'essentiel du travail sur un grand projet est peu exigeant intellectuellement.

Ne bâtissez pas votre planning en pensant que chacun va coder aussi rapidement que vous. Soyez réaliste et doublez le temps estimé. C'est triste à dire, j'ai souvent trouvé que cela ne suffisait pas à certains.

Si vous trouvez n'importe qui dans l'équipe qui joue le jeu de blâme, cassez cette spirale. Si quelqu'un se plaint de spécifications imprécises, réorientez la discussion sur les suggestions de la manière d'améliorer les spécifications. Si quelqu'un accuse d'autres d'être en retard sur des interfaces dont elles "ont besoin", réorientez vers une discussion sur la programmation modulaire et comment les interfaces peuvent être dessinées sans que l'ensemble de leur implémentation soit faite. Quoi qu'il en soit, ne laissez pas les personnes s'en sortir en blâmant les autres à propose de leurs propres carences.

Ce qui importe peut-être le plus, n'utilisez pas la "massue" des licenciements et de la fin de contrat pour encourager des personnes à travailler. Si elles sont bonnes à quoi que ce soit, vous ne ferez que les effrayer au point qu'elles aillent chercher un autre travail en vous laissant sans ressources. Si elles sont vraiment inutiles, la menace n'améliorera pas leurs qualifications et vous allez transformer l'équipe en rassemblis de personnes tremblantes qui s'arracheraient plutôt leurs propres bras plutôt que de vous demander de l'aide ou des conseils.

Si rien de tout cela ne marche, assurez vous que la direction se rende compte tôt des difficultés d'avancement et des changements potentiels de planning. Même si vous pensez pouvoir récupérer le temps perdu, assurez vous que la direction sache que du temps a été perdu de sorte que ce ne soit pas une surprise si les choses ne tournent pas comme vous l'espérez. Assurez-vous que vous avez une prioritisation des fonctionnalités de sorte que vous sachiez quelles fonctions sacrifier s'il est critique de livrer "quelque chose" à une date donnée.

Finalement, continuez à sourire et à prendre les choses du bon coté. Quand tout est dit et fait, ce n'est qu'un projet, non votre vie, et vous obtiendrez seulement des ulcères en stressant excessivement. Le plus souvent, les choses ne marchent pas tout à fait comme vous le voudriez, aussi apprennez à les diriger dans la direction dont vous avez besoin.

Étant moi-même un arrogant fils de p..., cela m'a pris des années à apprendre à être plus doux avec mes collègues. Plutôt que d'énoncer brutalement mes déceptions, je trouve bien plus efficace de leur fournir des fichiers en-têtes d'interface (si possible avec des squelettes de code), et de les laisse coder à partir de là.

© 2002 Barijaona Ramaholimihaso
Dernière mise à jour : 30/07/02; 21:17:52