mardi 27 août 2013

Les récompenses sont démotivantes

Dans une conférence TED, j'ai appris que les récompenses, financières ou autre, n'était pas un facteur de motivation :




On m'aurait menti depuis tout ce temps ? Alors que l'on m'a poussé à faire un bac générale, puis une prépa, puis une école d'ingénieur, pour gagner un maximum d'argent, je découvre aujourd'hui que c'était un mensonge ? L'argent ne fait pas le bonheur ? Mince alors !

En fait si, l'argent fait le bonheur, jusqu'à un certain point. Une fois comblé les besoins naturels : habitation, alimentation, sécurité, (on parle de besoins physiologiques) le reste ne sert pas à s'épanouir plus. Au mieux, il permet d'accéder à un confort supérieur. Au pire, il est un frein à un développement plus personnel : de meilleurs horaires, un travail moins loin, un travail plus intéressant, un mi-temps...

Mais ce n'est pas tout. Non seulement l'argent n'est pas motivant, mais devient même un excellent démotivant. Dans l'étude dont parle la vidéo, on a assigné une énigme à deux groupes. Le premier le faisait pour la science, le deuxième pour une maigre somme d'argent. Le premier groupe a été plus efficace que le deuxième. L'argent nous motive pour travailler plus vite, mais il ne nous permet pas de travailler mieux. Hors pour la résolution d'une énigme, ou tout autre tâche qui requiert de l'intelligence, l'argent devient un frein.

Un autre exemple est l'éducation des enfants. Vous souhaitez que votre enfant teste un nouveau sport comme le judo alors qu'il n'est pas très motivé. Pourtant vous pensez que ça pourrait l'aider à se développer et à le rendre moins timide. Si vous lui proposez une récompense comme une glace ou un ballon, la prochaine fois qu'il devra allez au judo, il désirera une récompense. Il ne souhaiteras plus y aller sans contrepartie, et il ne prendra pas réellement plaisir à ce sport, car le judo sera lié à un mécanisme de récompense. Je ne prend pas plaisir à pratiquer le judo, je le fais pour la récompense.
Une meilleur façon de s'y prendre est de fournir des raisons intrinsèques. Tu me feras plaisir si tu vas au judo. Je serais vraiment fier de toi. L'enfant se sentira réellement motivé, car il aime faire plaisir, et il y retournera volontiers, et peut être même qu'il se mettra à aimer ça.

On peut aisément transférer cette situation dans le monde professionnel. Si vous souhaitez assigner une nouvelle tache à l'un de vos employés, ne parlez pas de récompense. Cela ne motivera pas votre employé, et il risque de devenir complètement improductif. L'employé doit être motivé par des raisons intrinsèques : Autonomie, Maîtrise et Pertinence. Faire ce qu'on veut, le faire bien, et parce que on y croit.

Si un beau poster et une jolie phrase est tout ce qu'il te faut pour être motivé,
tu as probablement un boulot très simple, le genre que les robots feront bientôt


mercredi 14 août 2013

Dilemme de la reprise de projet : tout détruire ou pas ?

Durant ma carrière, j'ai souvent été confronté à la même question. En face d'un projet biscornu, quel était la meilleure solution ?
Le dilemme de la reprise de projet sur CommitStrip
Soit on appelle la boule de démolition, soit on rénove. Qu'est ce que prendra moins de temps ? Qu'est ce qui est le mieux ?

Le jeune stagiaire plein de bonne volonté n'a pas très envie de reprendre du code existant. Il est toujours plus agréable de repartir de zéro, de tout reconstruire. Au moins, ce sera notre logiciel, pas celui d'un autre.

Mais attention, la plupart du temps, repartir de zéro est une très mauvaise idée. C'est très séduisant, les développeurs vous vanteront les défauts du code existant, les mérites des nouvelles technologies, et puis que les vieux n'y comprennent rien, ou que le stagiaire a fait n'importe quoi.

Dans l'article Les choses que vous ne devez jamais faire, l'auteur Joel Spolsky préconise de ne jamais repartir de zéro. Repartir de zéro implique de ne plus avoir un produit livrable. Et perdre le potentiel d'avoir un produit livrable, c'est perdre un marché. On perd aussi des informations précieuses que les anciens développeurs ont déjà découverts : bugs de compatibilité, règles fonctionnelles biscornues... Il faut tout reprendre, tout revoir, êtes vous sûr que cela ne vas pas prendre plus de temps ?

Dans mon projet actuel, on est parti de très loin. Le logiciel était en ruine, programmé de la pire des manières : variables globales, aucune instance d'objet, code non optimisé (pour les connaisseurs, le tri à bulle était utilisé de partout), non hiérarchisé, environ 100.000 lignes de code répartit dans une vingtaine de fichiers, sans aucun dossier. On m'a embauché pour remettre de l'ordre, allais-je repartir de zéro ?

Le logiciel était utilisé par trois personnes de manière intensive. Ils avaient besoin de correction, maintenant, pas dans un an. Réécrire de zéro m'aurait pris au moins une année pleine, et encore, c'est optimiste. Les utilisateurs ne pouvaient pas rester avec un logiciel inefficace pendant toute une année, car cela allait impacter directement sur la production de l'entreprise.

J'ai choisi de faire une rénovation complète du logiciel, en conservant constamment une version livrable et fonctionnelle, moins pire que la précédente. Cela a été difficile et compliqué. Il a fallut se battre contre la médiocrité, corriger les aberrations, être confronté au jour le jour à des absurdités. Il est plus difficile de lire du code que de l'écrire. C'est éprouvant émotionnellement de reprendre le code d'autrui, d'autant plus quand il est mauvais. Imaginez-vous lire `Les misérables` en langage sms.

Cependant, les bénéfices ont été innombrables. Les utilisateurs ont pu voir au cours de l'année des améliorations visibles et décisives. Les temps de calculs fondaient à vue d’œil, les bugs devenaient de plus en plus rares, le logiciel devenait fiable, robuste et performant. Et le plus important, les utilisateurs reprenaient confiance dans le logiciel. Ils n'en avaient plus peur, ils avaient envie de l'utiliser, la productivité devenait meilleure.

Bien sur, la taille du projet rentre en compte. Si vous avez quelques centaines de lignes de code, il vaut peut être mieux tout reprendre de zéro. Mais rapidement, si vous commencer à dépasser quelques milliers de lignes, réfléchissez bien à l'impact de repartir de zéro.

lundi 12 août 2013

Combien de temps ?

Dans mon métier, on me demande souvent combien de temps cela va prendre pour développer telle ou telle fonctionnalité, ou pour résoudre tel ou tel bug.

Dans ces cas là, voici ce qu'il y a dans mon cerveau :

La roue du chiffrage sur CommitStrip

Quel idée de demander à un écrivain combien de temps cela lui prendra pour écrire son prochain roman. Ou combien de temps cela prendra à un peintre de sortir son prochain tableau.

Certains chef d'oeuvre ont pris des années, d'autre quelques minutes. Certains me diront que comparer l'écriture d'un logiciel à de la peinture, c'est exagéré. Et pourtant, les deux sont des activités créatives.

Pour un bûcheron, couper un arbre n'est pas créatif. C'est procédurale. On peut facilement calculer le temps exact que mettra le bûcheron à abattre une dizaine d'arbres.

Un travail de création demande de l'imagination, de l'innovation, des choses incalculables et non mesurables. Quand on me demande le temps que je mettrais à faire une tâche, je réponds le plus honnêtement possible. Des fois ça prend deux fois plus de temps, des fois deux fois moins de temps. Un manager m'a dit un jour que mon manque d'expérience m’empêchait d'établir un chiffrage précis. Evidemment, ce manager n'avait jamais touché une ligne de code, considérait les développeurs comme des ressources interchangeables, et l'informatique comme une chaîne de montage industrielle.

Il existe tout de même des solutions pour permettre des chiffrages plus justes. De nouvelles méthodes de management de projet, comme les méthodes agiles, préconisent par exemple de réévaluer en cours de route les chiffrage horaires. Cela parait plus juste, car au fil de l'avancement d'un projet, on sait de mieux en mieux combien de temps nous prendra ce qu'il reste. Du côté des mauvaises nouvelles, cela empêche d'avoir un budget précis avant le début du projet. Et ça les décideurs n'aiment pas ne pas savoir. Pourtant, combien de projets ont été abandonnés parce que les chiffrages étaient coulés dans le marbre ? Trop en retard, trop cher, trop mal conçu, trop mal managé. L'agilité permet de la souplesse dans les plannings. Avec l'expérience acquise au fil des ans, on sait que le chiffrage d'un projet au départ ne correspondra pas au temps que cela coûtera réellement. Il faut prendre ces paramètres en compte lors d'un chiffrage, et garder en tête que ce ne sont que des prévisions, qu'il faudra sans cesse réévaluer.