De geek à directeur technique

Le blog d'un geek devenu directeur technique

Aller au contenu | Aller au menu | Aller à la recherche

samedi 12 décembre 2009

Les premiers enseignements de Rework

J'ai déjà parlé plusieurs fois de l'entreprise 37signals, de ses logiciels de gestion de documentation et de projet, et de sa méthode Getting Real. Actuellement, ses membres travaillent au successeur de leur livre, dont le nom sera Rework. Ils ont présenté quelques bribes d'information sur le livre, et je me suis arrêté sur le quatrième de couverture :

Je trouve que le texte qui s'y trouve est très intéressant, un brin controverse, et mérite qu'on s'y attarde. Voici une traduction très libre de son contenu, et ce que j'en pense.

“Dès que possible” est un poison

Il est vrai qu'en entreprise, on rencontre bien souvent ce genre de situation : On essaye de se mettre d'accord sur la spécification d'une nouvelle fonctionnalité, et quand vient le moment d'en définir la date de livraison, on se voit répondre “Dès que possible”. Cela peut sembler la réponse la plus honnête, la plus simple à comprendre de tous et la plus facile à gérer ; mais en fait il s'agit souvent d'un pis-aller qui démontre que le projet n'est pas réellement pris en main.

Quand on demande un développement ASAP (as soon as possible), on abdique sur tous les facteurs qui définissent un projet :

  • La définition exacte du projet n'a pas été faite correctement. On sait bien qu'on n'a pas pris le temps de réfléchir à tous les cas limites, à penser à toutes les situations. On sait − mais on ne le dit pas ouvertement − que les développeurs devront affronter tous ces culs-de-sac fonctionnels au fur et à mesure qu'ils se casseront les dents dessus, ce qui empêche d'apporter une quelconque valeur aux estimations qu'ils peuvent faire de leurs développements.
  • À partir du moment où la seule contrainte exprimée est celle du temps passé sur le projet, on accepte implicitement que des raccourcis soient fait pour atteindre l'objectif au plus vite. Un aspect en pâtira forcément, qu'il s'agisse de la qualité générale de la réalisation, de la maintenabilité du code, des tests, du débuggage, ...
  • À l'inverse, l'absence de deadline réaliste autorise les développeurs à se lancer dans des développements inutiles (je ne parle même pas de ceux qui se tournent les pouces). On arrive ainsi à des situations où on découvre au bout de 2 semaines que le développement “ASAP” aurait pu durer 4 jours si on avait pris le temps de dimensionner et budgéter le projet correctement ; mais si on en fait la remarque au(x) développeur(s), on obtient une réponse du genre «Ah, moi j'estime que tout ce que j'ai fait était nécessaire pour que le projet fonctionne correctement. Il fallait me prévenir si c'était plus urgent que ça !».

Lire la suite...

samedi 19 septembre 2009

Et si Gordon Ramsay était informaticien ?

Depuis quelques temps je ne rate pas un épisode de l'émission Cauchemar en cuisine, qui est diffusée sur plusieurs chaînes télévisées françaises de la TNT ou du câble.

Le concept de cette émission est assez simple : Gordon Ramsay, un chef cuisinier écossais renommé, vient en aide à des restaurateurs au bord de la faillite. Là où ça devient amusant, c'est que Gordon n'a vraiment pas sa langue dans sa poche ; il n'hésite pas à s'énerver très fort quand il le faut, pour faire prendre conscience aux gens qu'il sont sur la mauvaise voie.
Bon, la traduction française a tendance à édulcorer son langage. Ainsi, la phrase «I will smash this plate on your fuking head» est devenu «Je vais casser cette assiette sur ta tête de bois»...

Au fil des épisode, on peut voir des cuisiniers sans talent, des gérants à l'égo stratosphérique, des restaurants complètement vides, des engueulades à côté des clients, ...
Gordon goûte les plats, regarde comment fonctionne l'organisation du personnel, étudie les comptes financiers. Il met ensuite les responsables − le propriétaire, le gérant de salle, le chef cuisinier − face à leurs lacunes, leurs faiblesses, leur fainéantise, leur désorganisation. Quand les problèmes ont été compris (au bout de quelques bonnes engueulades hautes en couleur), il met en place un plan de bataille qui permet de remonter les résultats du restaurant.

Il utilise souvent les mêmes recettes (au sens figuré du terme, désolé je n'ai pas pu m'en empêcher) d'un restaurant à l'autre, mais à chaque fois avec des résultats différents. Ce qui est vraiment intéressant, c'est qu'il met en application des principes qui tiennent plus de l'entrepreneuriat que de la restauration. Il y a beaucoup d'inspiration à trouver là pour une équipe technique.

L'étude de marché

À chaque fois, Gordon fait un petit tour dans la ville où il est tombé. Il fait attention aux autres restaurants existants, et essaye de trouver le type de restauration qui n'est pas représenté. Il regarde aussi la clientèle existante (ou ce qu'il en reste), et à partir de tout ça il invente un nouveau visage au restaurant pour lui faire trouver une nouvelle clientèle.
Cette nouvelle identité est souvent mal vécue par les patrons qui voient leurs habitudes remises en question. Le menu est complètement revu (je vais y revenir), le restaurant est redécoré, parfois même renommé. Mais ce nouveau positionnement est gagnant, et l'augmentation des bénéfices lui donne toujours raison.

Lire la suite...

mercredi 13 mai 2009

Lenny's golden rule of management

Dans mon dernier billet, je vous parlais de la règle d'or du management de Loïc. Je vais maintenant vous parler d'une autre règle qui, sous son aspect - et son origine - humoristique, possède une réelle profondeur :

« Tout le monde peut faire des erreurs, c'est pour ça qu'il y a des gommes au bout des crayons »

Cette phrase est prononcée par Lenny, dans l'épisode L'ennemi d'Homer, dans le dessin animé "The Simpson". Ah oui, dit comme ça, ça ne fait pas très sérieux. Mais réfléchissez-y bien.

J'ai vu trop de personnes qui ne pardonnaient aucune faute à leurs collègues. La moindre erreur devenait synonyme de débilité profonde de la part de celui ou celle que l'avait commise. Et non content de ne rien laisser passer ces personnes sont quasi-systématiquement blessantes dans leurs propos. Sans chercher à humilier les gens en public, elles y arrivent quand même.

Quand quelqu'un fait une erreur, il faut plutôt se faire rapidement une petite checklist mentale :

  1. Est-ce uniquement de sa faute ?
  2. Lui ai-je donné la formation nécessaire ? Lui ai-je consacré le temps et l'aide dont il/elle avait besoin ?
  3. Ne m'est-il pas arrivé de faire le même genre d'erreur ?

Sincèrement, on fait tous des erreurs ; c'est humain. Ne pas être capable de reconnaître cette réalité chez les autres démontre un manque de maturité. Évidemment, on peut s'énerver un peu quand quelqu'un fait plusieurs fois la même erreur, et qu'on est certain que cette personne bénéficiant de bonnes conditions pour réaliser son travail convenablement.

Mais la prochaine fois que vous sentirez la moutarde vous monter au nez, demandez-vous : est-ce que je n'ai jamais utilisé la gomme qui est au bout de mon crayon ?

vendredi 8 mai 2009

La diplomatie au travail

Quand on travaille en équipe, on doit apprendre à gérer les rapports humains. Nous ne sommes pas tous égaux face aux relations humaines. Certaines personnes se sentent à l'aise, d'autre non. Certaines personnes n'hésitent pas à imposer leurs vues, d'autres se mettent en retrait.

L'essentiel est de garder, en toute circonstance, un comportement qui permette de travailler efficacement. Si on peut se faire des amis au boulot, c'est la cerise sur le gâteau ; mais il ne faut pas se faire d'ennemis.

Les désaccords

Il existe un principe fondamental en entreprise : Critiquer les idées, pas les personnes

Quand on n'est pas d'accord avec les propositions de quelqu'un, il semble parfois plus facile de chercher à démolir la personne elle-même, plutôt que d'expliquer en quoi on est en désaccord. Ce n'est pas constructif, et vous attirera les inimitiés de vos confrères.

Lire la suite...

jeudi 30 avril 2009

L'encadrement des juniors

L'encadrement de juniors (stagiaires et jeunes diplômés) est un sujet assez vaste, et je vais juste aborder ici un point de détail qui concerne la manière dont les entreprises abordent leur productivité.

Il existe un principe de base qui est valable pour tout le monde :
« Comprendre ce qu'on fait et ce sur quoi on travaille »

Quand on embauche une personne qui a de l'expérience, c'est souvent pour la faire travailler sur des projets assez pointus. Dans ce cas, on s'attend communément à ce que la complexité de la tâche implique un "temps de démarrage" conséquent.

Il est assez logique que les juniors, pour leur part, se voient affecter des tâches plus accessibles d'un point de vue technique. Mais de nombreuses personnes voudraient qu'un junior soit immédiatement opérationnel. La réflexion qui est faite est du style : "Ce n'est pas bien compliqué, franchement, il devrait avoir terminé dans 2 jours, non ?".
Le problème, c'est que n'importe quel travail doit se faire en ayant une maîtrise de son environnement et de ses impacts potentiels.

On ne peut pas demander à un jeune embauché de faire du bon boulot, si on n'a pas pris le temps de le former correctement sur les méthodes et outils spécifiques employés dans l'entreprise. Même si le travail demandé semble mineur, il faut se souvenir que l'expérience du collaborateur est limitée elle aussi. Un défaut d'encadrement peut conduire à des situations désagréables. La plus commune est que le junior, après avoir travaillé 3 jours sans avoir reçu de formation interne, doit recommencer tout le travail parce qu'il n'a pas respecté les directives qu'il n'a pourtant pas eues. On voit aussi fréquemment des personnes qui commencent à modifier du code sans le comprendre, générant un nombre incroyable de bugs de régression.

La pire situation que j'ai vue, c'est une entreprise qui formait ses jeunes "à la dure" : aucune formation, directement affectés aux débuggages ! Autant vous dire que ce n'était pas très efficace...

Si vous encadrez un junior

Vous devez lui fournir toutes les informations nécessaires. On ne laisse pas les gens se débrouiller tous seuls ; cela revient à les laisser dans la merde. Prenez le temps d'expliquer les méthodes, outils et usages qui ont cours dans votre entreprise. Faites leur faire un premier projet pour se faire la main, sur lequel vous les encadrerez de très près.

Lire la suite...

- page 1 de 3