Le blog d'un geek devenu directeur technique

Billets dans la catégorie Organisation d’équipe

Contre les extrémismes coûteux

fév11
2011 11 Commentaires Par Amaury

Ces derniers temps, j’ai eu plusieurs discussions avec d’autres informaticiens, orientées sur des sujets comme les méthodes agiles en général et plus particulièrement les tests unitaires. C’est toujours intéressant de confronter sa propre vision à celle des autres.

Une des choses qui m’a marqué, c’est que plus de la moitié des gens avec qui j’ai abordé le sujet avaient un raisonnement très binaire. C’est-à-dire que pour eux, 100% du code doit être couvert par des tests unitaires. C’est comme ça, ça ne doit pas être autrement. C’est simple et clair.

Sauf que… Cette vision des choses me gêne pour 3 raisons.

1. Le coût

Écrire des tests unitaires prend du temps. Cela a donc un coût. Tester l’intégralité du code oblige donc à y consacrer beaucoup de temps, ce qui augmente considérablement le budget en développement.

Le contre-argument habituel est de dire qu’en faisant appel au TDD (test driven development, dont je vous ai déjà parlé par le passé), ce coût est réduit. Ceci n’est pas complètement vrai : Le TDD force à commencer par écrire les tests, donc on est certains qu’ils existent. Au passage, on se creuse un peu la tête pour essayer d’imaginer les différents cas d’utilisation (légitimes ou générant des erreurs) dans lequel le code pourrait se retrouver. Mais le principe même des méthodes agiles, c’est de dire qu’on aura plus d’expérience demain ; donc il faudra forcément compléter ces tests au fil du temps. Ce qui ne pourra se faire qu’en cours de développement, voire même après les développements. Je connais beaucoup de développeurs qui utilisent la méthode TDD, et tous confessent devoir compléter leurs tests après coup.

Donc nous sommes d’accord, ça prend du temps, l’air de rien, et donc ça coûte cher. Il est inévitable de confronter ce coût à son utilité. C’est vrai, ça ; à quoi servent les tests unitaires ?

  1. Augmenter la stabilité des développements.
  2. Réduire les bugs de régression.
  3. Rendre le travail des développeurs plus confortable.

Le deuxième point découle du premier. Un code plus stable, qui se vérifie automatiquement, sera plus robuste face à des bugs de régression. Une fonctionnalité qui marche bien à un moment donné, mais qui se met à déconner à cause d’un effet de bord provoqué par un nouveau développement, ça arrive tous les jours. Les tests unitaires permettent de détecter cela au plus tôt et réduisent donc les risques.

Par contre, le troisième point me laisse un peu songeur. Je reste assez froid quand un informaticien me dit «Oui, mais avec 100% du code qui est testé, c’est beaucoup plus confortable pour nous !».
Certes, c’est vrai (encore que, voir plus bas). Mais sincèrement, même si je suis le premier à penser qu’une entreprise doit se soucier réellement du bien-être de ses employés, est-ce que le confort dont on parle vaut automatiquement le coût de l’écriture de tous ces tests ? Une entreprise a pour but de générer des bénéfices ; cela veut dire que chaque investissement doit être jugé à la lumière de ce qu’il va rapporter − ou de ce qu’il permettra de ne pas perdre (car si les tests unitaires ne font pas gagner d’argent, ils peuvent vous éviter d’en perdre beaucoup).

Tout ça pour dire qu’un développeur ne peut pas simplement dire que pour chaque heure de développement effectuée il lui faudra systématiquement une heure d’écriture de tests. Tout dépend du développement en question. En fait, c’est la même chose pour beaucoup d’autres points. Il y a des projets qui ne sont pas critiques pour l’entreprise, et pour lesquels on se permet tous les jours de faire l’impasse sur la qualité globale, la documentation, les tests ou autre chose. Tout simplement parce que l’important est de se confronter rapidement au marché, et que si le coût est élevé, le projet n’a alors plus lieu d’être.

2. La poudre aux yeux

Les tests unitaires ont toujours une part de “poudre aux yeux”. Ils peuvent donner un faux sentiment de sécurité. Le code est testé de manière automatique, alors on se repose sur la certitude que toute régression est impossible.

Oui, mais non. Il ne faut pas oublier que tester 100% du code ne veut pas dire que le code est testé à 100% (subtile nuance).

PLUS »

Classé dans Organisation d'équipe - Libellé , , ,

Les emails en entreprise… encore

fév09
2011 15 Commentaires Par Amaury

J’ai entendu ce matin à la radio une information qui m’a fait bondir (et un peu rigoler). Atos va arrêter l’usage des emails, pour privilégier la communication directe entre ses collaborateurs, tout en mettant en place des outils de communication instantanée. L’argument utilisé est que les collaborateurs reçoivent 200 emails par jour en moyenne, et qu’ils perdent un temps incroyable à les lire (je ne me souviens plus, mais quelque chose comme une vingtaine d’heures par semaine).

Bon, vous connaissez déjà un peu mon avis sur la question (voir aussi cet article).

Oui, devoir lire plusieurs centaines d’emails par jour empêche de travailler efficacement. Mais le problème vient de l’utilisation qui en est faite. Comme je le disais dans un précédent article, les emails ne doivent pas servir de support de gestion de projet, ni de partage de fichiers, ni de liste de tâches. Je ne peux pas concevoir de travailler correctement en étant noyé sous 200 emails quotidiens. Impossible. C’est pour ça qu’on utilise dans mon entreprise des outils correspondant à chaque usage (et c’est pour ça que ceux qui s’amuse à spammer inutilement se font rappeler à l’ordre).

À la radio ce matin, quelqu’un expliquait à un moment qu’il se retrouvait parfois à envoyer des emails à des gens qui sont dans le même bureau que lui, parfois qui sont assis en face de lui. Hum… Il faudrait peut-être commencer par là ? Non quand on a un truc à se dire, on commence par lever notre cul de notre chaise. Ça a l’air bête, hein, mais c’est tellement plus productif !

La réponse technologique m’étonne aussi. Vouloir remplacer les emails par des «outils sociaux» me laisse songeur. La messagerie électronique et la messagerie instantanée sont complémentaires, mais pas en concurrence ; ils correspondent à des usages et des besoins différents. Les forums de discussion peuvent être très utiles en entreprise, pour mener à bien des prises de décision par des équipes projet qui sont dispersées géographiquement. Est-ce pour autant qu’il faut abandonner les emails ?
En plus, j’espère que vous serez d’accord avec moi : la plupart du temps, il est plus rapide et efficace d’avoir une bonne discussion en face à face ou par téléphone, plutôt que de perdre du temps à taper au clavier. Cette remarque est valable aussi bien pour les emails que pour le “tchat” ou les forums de discussion.
Vouloir remplacer l’email, qui est non-intrusif, par de la visio-conférence ou par la messagerie instantanée  ? Cela restera un effort aussi vain que d’avoir voulu remplacer le téléphone par ces mêmes outils. Ils sont tous voués à se développer en parallèle, s’enrichissant les uns les autres sans pour autant se remplacer les uns les autres.

Je me pose une question : Comment les commerciaux et les chefs de projets d’Atos vont faire pour discuter avec leurs clients ? Ils vont systématiquement imposer leurs outils de communication ? Sans rire ?

Alors évidemment, il y a des choses à améliorer dans le courrier électronique. Aussi bien dans son aspect technique que dans son utilisation :

  • Le simple fait de voir les messages comme une discussion, tel que le fait Gmail, évite les redites inutiles.
  • Les entreprises peuvent définir des règles d’écriture des messages internes, avec des normes concernant les titres des messages, pour s’y retrouver plus facilement.
  • Et évidemment, il faut mettre en place des passerelles entre les différents moyens de communication, pour aider les utilisateurs à monter en compétence sur les outils les plus adaptés à chaque besoin.

Ça vaut ce que ça vaut, mais j’ai travaillé dans des entreprises qui ont fait des tentatives d’utilisation de messagerie instantanée. Le résultat était simplement que 80% des messages échangés n’avaient absolument rien de professionnels, et que ces outils étaient majoritairement utilisés pour prolonger les discussions entamées durant la pause-café sans se faire attraper par la hiérarchie. Un peu comme ceux qui gardent une fenêtre ouverte sur Facebook dans un coin pour discuter tout au long de la journée…

Classé dans Organisation d'équipe - Libellé , ,

Faut-il embaucher des geeks ?

nov24
2010 9 Commentaires Par Amaury

Je réfléchis à cet article depuis quelque temps. En fait, depuis un échange de commentaires dans l’un de mes précédents articles.
La question concernait le fait d’embaucher (ou non) des développeurs qui codent pendant leur temps libre. Est-ce une bonne chose ?

Naturellement, j’aurais tendance à préférer un gars (ou une fille, mais ne m’en voulez pas si je parle au masculin) qui développe le soir et le week-end. C’était un feeling plus qu’un raisonnement réfléchi, alors je me suis creusé un peu la tête sur le sujet.

Pourquoi préférer un geek ?

Si on essaye d’être rationnel, il y a plusieurs aspects positifs dans le fait d’embaucher quelqu’un qui passe une partie de ses soirées et de ses week-ends sur son ordinateur :

  • C’est un passionné : Quand on se cogne 8 à 12 heures de développement par jour au boulot et qu’on vous demande de l’implication et de l’imagination, on peut vite être «usé» par le temps. Ce qui fait souvent la différence, c’est la passion qu’on éprouve pour l’informatique en général et le développement en particulier. Ce n’est pas pour rien que la passion est un critère fréquemment cité par tous les recruteurs.
  • Il fait une veille techno active : J’ai déjà parlé de l’importance de la veille technologique. Un développeur passionné, c’est bien ; un développeur qui explore de nouveaux horizons, c’est mieux. En prenant du temps personnel pour faire du développement, il essaiera des techniques différentes de celles dont il a l’habitude, et cela pourra n’être que profitable pour l’entreprise sur le long terme.
  • Il accorde peu d’importance à la politique : Ce n’est pas évident pour tout le monde, mais le monde de l’entreprise est un terreau fertile pour l’apparition de comportements «politiques». Et il n’y a rien de plus désagréable et improductif que d’avoir des guéguerres de pouvoir. Un vrai geek, passionné par l’informatique au point de développer sur son temps personnel, s’attachera le plus souvent à bien faire son travail sans s’occuper des manigances des uns et des autres. Dans une entreprise bancale, ça pourrait jouer en sa défaveur, mais dans une entreprise “normale”, ce sont les politiciens qui sont mis à l’écart.

Pourquoi faudrait-il éviter un geek ?

D’un autre côté, il existe aussi des raisons pour ne pas souhaiter embaucher un codeur fou :

  • Il n’est intéressé que par le défi technique : Nous avons tous connu des informaticiens qui changent régulièrement d’entreprise parce qu’ils s’ennuient rapidement. Dès qu’ils ont l’impression d’avoir fait le tour de ce qu’ils pouvaient apprendre et de ce qu’ils pouvaient apporter, ils ressentent le besoin irrépressible de partir ailleurs. Et même si pendant l’entretien d’embauche ils vous disent «Votre annonce correspond précisément à ce que j’ai toujours recherché !», vous ne savez absolument pas quels seront leurs moteurs internes dans 6 mois.
  • Il peut s’essouffler rapidement : Si l’usure du temps le rattrape plus vite que ne le fait avancer sa passion, il risque d’en avoir plus rapidement assez du développement que vous n’auriez pensé. Et le jour où votre développeur de génie vous dire «J’en ai marre du développement, je veux devenir chef de projets / faire du décisionnel / faire du référencement / devenir commercial», vous allez faire une drôle de tête.
  • Il peut avoir un déséquilibre social : Même si tous les geeks ne répondent pas aux clichés que l’on s’en fait, certains restent toutefois des asociaux ou des autistes latents. Le fait de développer le soir et le week-end n’est alors qu’un indicateur de leur incapacité à avoir une vie sociale équilibrée. Et cela voudra dire que les mêmes difficultés de communications les gêneront dans l’accomplissement de leur travail (à moins de les faire bosser tous seuls au fond d’une grotte, sans interaction avec qui que ce soit, mais c’est assez rare).
  • Il peut privilégier ses projets personnels : C’est le revers de la médaille qui est habituellement passé sous silence. Les gens ont des passions, c’est normal et souhaitable pour maintenir un équilibre personnel. Mais à l’inverse de la plupart des passions qui ne peuvent pas se pratiquer au travail (sport, musique, tricot, élevage d’alligators nains), le développement informatique est une activité à laquelle les développeurs peuvent s’adonner même quand ils sont au boulot. On ouvre juste un fichier supplémentaire, on se connecte par SSH à un autre serveur… et on passe 4 heures à développer un petit-truc-qui-prendra-5-minutes.

Conclusion

Comme souvent, on se retrouve là sans avoir une grande vérité unique et absolue. Chaque situation est différente, chaque personne est spéciale.

Il y a des avantages et des inconvénients. Mais en fait il s’agit de risques plutôt que d’inconvénients réels. En tout cas, rien qui ne soit détectable et rectifiable avec un management efficace.

Pour ma part, je valorise le codage personnel chez les jeunes informaticiens, pour deux raisons :

  1. Ils n’ont pas encore l’expérience et les habitudes nécessaires à la mise en place d’une veille technologique correcte. Leurs projets personnels peuvent en tenir lieu pendant un certain temps, et les aidera à trouver leur propre méthode de veille.
  2. L’expérience est une chose très importante. On l’oublie parfois, mais il y a une vraie différence de qualité et de rapidité entre un développeur junior et un informaticien qui a plusieurs années de travail derrière lui. Les projets personnels sont un moyen efficace pour engranger rapidement de l’expérience supplémentaire. On réussit mieux ses études d’informatique quand on développe des projets personnels en plus de ceux imposés par le cursus. Il en est de même avec l’expérience professionnelle.

Par contre, chez des informaticiens expérimentés, je privilégie ceux qui savent faire une vraie veille techno et qui ont une vie personnelle équilibrée. Ce sont ceux qui ont la meilleure expérience professionnelle et qui savent le mieux en faire profiter l’entreprise.

Classé dans Organisation d'équipe

Ma méthode «musicale»

juil27
2010 9 Commentaires Par Amaury

Je n’en ai jamais parlé sur ce blog, mais j’ai quelques activités en dehors de l’informatique et de l’entrepreneuriat. L’une d’elles est la musique. Je joue de la basse depuis l’âge de 16 ans, de la basse 6 cordes depuis 10 ans, et de la basse fretless depuis 2 ans. J’ai joué dans plusieurs groupes ; mon groupe actuel − Perpetual (e)motion − existe depuis 2002 et a sorti son premier album il y a peu de temps. C’est du métal progressif : l’énergie du métal avec une vraie recherche musicale.

Si, si, je vous jure, c’est vrai. La preuve en image :
Concert

Il existe grosso modo deux manières d’aborder la musique : soit on rejoue la musique des autres, soit on invente la notre. Ce n’est pas antinomique ; la plupart des groupes, amateurs ou stars mondiales, jouent des reprises au milieu de leurs propres compositions.

J’ajouterais un cas supplémentaire auquel on ne pense pas forcément, celui de la composition en groupe. On se retrouve forcément à devoir jouer certaines parties qui ont été composées par un autre membre du groupe, et d’autres parties qui sont de notre propre fait.

Tout l’intérêt de la création de groupe, c’est justement l’équilibre et la mise en danger que l’on ressent quand on essaye de créer une œuvre qui transcende les individualités, tout en exprimant la créativité de chacun.

Les principes

Pour ma part, j’ai toujours abordé la musique en appliquant la même méthode. Elle tient en 3 principes simples :

  1. Simplifier. Quand il s’agit de musique, je suis un peu fainéant. Travailler une partition à la note près, je l’ai fait assez souvent pour savoir que j’en suis capable. Mais c’est fatiguant et castrateur. Alors la première chose que je fais − qu’il s’agisse d’une reprise ou d’une composition du groupe − est de simplifier les lignes de basse qui ont été écrites. J’en extraite la substance fondamentale, qui peut être la mélodie principale ou le groove de base de la chanson.
  2. Écouter. La simplification permet d’ajouter de l‘espace, qui m’offre des options pour m’exprimer, composer mes propres variations sans dénaturer le morceau. Mais le seul moyen d’apporter ma pierre à l’édifice musical, c’est de trouver la bonne mélodie, de placer la note juste au bon moment. Et pour y arriver, je prend le temps d’écouter l’ensemble du morceau, j’essaye de sentir ce qui lui manque. En abordant une chanson avec une oreille neuve, en écoutant tous les instruments en même temps, on peut apprécier ce qu’on peut lui apporter.
  3. Improviser. Je n’ai malheureusement pas le temps de travailler longuement nos morceaux. Quand j’étais plus jeune, je travaillais mes lignes de basse tous les soirs, mais maintenant c’est bien plus difficile. Je répète toutes les semaines avec mon groupe. Je mets ce temps à profit pour expérimenter, pour essayer de nouvelles choses. Je me laisse aller à l’improvisation, mais ce n’est possible que parce que j’ai d’abord épuré les lignes de basse, puis pris le temps d’écouter. Quand une mélodie intéressante se dessine, je la ciselle en l’améliorant à chaque répétition.

PLUS »

Classé dans Organisation d'équipe - Libellé , , , , , ,

Améliorer les flux d’information

mai13
2010 Laisser un commentaire Par Amaury

J’ai entendu récemment un échange qui m’a amusé, entre un oncle et une tante.
Elle de dire :

Mais tu ne m’écoutes pas ?

Et lui de répondre :

Je ne peux pas, tu parles tout le temps !

Derrière cette blague potache, on peut toutefois discerner une vérité universelle. Dans un flot incessant de communication, il devient difficile de faire le tri entre les informations pertinentes et celles qui ne le sont pas.

Dans le monde de l’entreprise, cela est d’autant plus vrai que le nombre d’interlocuteurs est souvent bien plus grand que dans le cadre plus restreint de la sphère familiale proche. Chaque nouvel intervenant sur un projet communique à son tour en direction de toutes les autres personnes concernées, ce qui démultiplie les échanges.

C’est toujours pareil

J’imagine que cela a dû vous arriver, d’effacer plusieurs dizaines d’emails que vous aviez reçu dans la même journée, et qui ne véhiculaient aucune information réellement utile pour vous. Et si vous réfléchissez bien, vous vous souviendrez que vous en avez vous-même envoyé un certain nombre dans la même journée.

Pourquoi envoie-t-on ce genre d’email ? Les raisons habituelles sont, en vrac :

  • Pour transmettre l’information à tous ceux qui pourraient en avoir besoin.
  • Pour élargir une discussion, s’assurer que notre désaccord avec Untel sera connu de tous.
  • Pour faire passer ses choix en douce («Comment ça tu n’es pas au courant ? Je l’ai proposé dans un email il y a 3 semaines et tu ne m’as pas dit non !»).
  • Pour se couvrir, en rejetant la faute sur les autres («Ça fait 2 mois que je vous préviens qu’on n’y arrivera pas, à raison de 15 emails par jour !»).

Et quand ce n’est pas par email, ça peut prendre la forme de blogs ou de forums d’entreprise dont le rapport signal/bruit décroit au fur et à mesure que la quantité d’information échangée augmente.

PLUS »

Classé dans Organisation d'équipe - Libellé , ,

Encore un peu de délégation

avr26
2010 Laisser un commentaire Par Amaury

Il y a quelques temps, je vous parlais d’un lecteur de ce blog que j’ai aidé à identifier comment il pouvait ne plus être un goulot d’étranglement (j’ai tenté, en tout cas). Un des points les plus importants de mes conseils − le premier de tous, en fait − concernait la délégation.

Nous avons échangé quelques emails par la suite, et je voudrais vous en rapporter la teneur. Pour simplifier, disons que j’ai voulu le convaincre de la réelle nécessité de confier ses tâches.

Quelques morceaux choisis :

  • «Le message n’est pas “tu ne dois pas être seul responsable d’un projet”, mais plutôt “tu ne dois jamais être le responsable d’un projet”. Ça me semble vraiment important si tu veux pouvoir apporter ton expertise sur un projet qui le nécessite, sans pour autant stopper tous les autres projet pendant ce temps.»
  • «Ton entreprise cherche à gérer un nombre de projets croissant au fil du temps. Ce développement (commercial) ne peut pas être lié uniquement à l’augmentation de tes heures travaillées. Une fois que tu bosseras 24h/24, tu feras comment pour traiter de nouveaux clients ?»
  • «La confiance des clients repose sur toi, oui. Et pour garder cette confiance, il faut qu’ils sachent que tu peux intervenir sur leur projet à tout moment si c’est nécessaire. Mais ça ne veut pas dire que l’intégralité des aspects de tous les projets doivent être gérés par toi au quotidien.»

Quelques exemples de délégation

1. Quand Alain Prost a créé son écurie de Formule 1 (ce n’est pas un très bon exemple, vu qu’elle a coulé, mais vous voyez ce que je veux dire), tout ça reposait sur son nom et son image. Mais il ne pouvait pas s’occuper en même temps de la recherche de sponsors, des stratégies de course, du développement de la voiture en cours d’utilisation, du programme de création de celle de l’année suivante, du recrutement du personnel, du remplacement du papier-toilette, …
Même si c’était lui qui était « à la barre », tout le monde sait qu’il avait un directeur commercial, un directeur de course, un responsable des essais, un directeur technique, …

2. Un grand chef cuisinier ne peut pas être tout le temps derrière les fourneaux. Ne serait-ce que parce qu’ils ont souvent plusieurs restaurants. On sait pertinemment qu’ils ont plusieurs sous-chefs dans chaque restaurant, et que ce sont eux qui gèrent en direct les cuisiniers et les commis en cuisine. L’important, c’est que le nom des grands chefs est un gage. Un gage de quoi ? De sérieux dans la formation des cuisiniers, d’expertise dans le choix des aliments, d’originalité dans les recettes des menus proposés. On estime qu’ils suivent d’assez près ce qui se passe dans leurs cuisine, pour garantir que les plats qui en sortent sont tous quasiment-comme-s’il-l’avait-cuisiné-lui-même.

PLUS »

Classé dans Organisation d'équipe - Libellé , ,

Si on ne peut pas l’imprimer, ça n’existe pas

avr20
2010 1 Commentaire Par Amaury

J’ai entendu cette réflexion («Si on ne peut pas l’imprimer, ça n’existe pas») durant une réunion qui avait pour thème les nouveaux tableaux de statistiques que nous sommes en train de mettre en place dans mon entreprise. Elle m’a semblé assez intéressante pour la partager ici.

Nous réfléchissions aux différentes statistiques dont nous avions besoin pour suivre efficacement l’évolution de la communauté formée par les visiteurs des sites Web que nous éditons. Nous pensions à plusieurs moyens d’organiser les choses et les chiffres, en nous demandant comment nous pourrions les exploiter au mieux.
L’un des points de discussion sur lequel nous butions était la manière de présenter les données au fil du temps. Sur des périodes glissantes ou calendaires, avec des chiffres découpés ou cumulatifs, à partir d’une date modifiable ou de la date courante….

L’une des propositions était de récupérer des chiffres relativement bruts, avec plusieurs critères de choix qui nous permettraient de croiser les recherches. Cela peut sembler assez séduisant : ainsi, il serait possible d’obtenir toutes les informations que l’on pourrait souhaiter, sans pour autant tout redévelopper à chaque fois.
Le problème avec une solution de ce type, c’est que les données doivent être consolidées « à la main ». L’opérateur humain se retrouve obligé de devoir choisir lui-même différentes périodes pour obtenir les chiffres correspondant, puis porter tous ces chiffres sur des tableaux synthétiques. C’était donc clairement une mauvaise idée.

C’est finalement évident quand on y pense : un outil de statistiques doit permettre de suivre des tendances, des évolutions au fil du temps. Pour y arriver, il faut que l’information soit visible d’un coup d’œil, elle ne devrait pas nécessiter des traitements supplémentaires. Sinon, autant donner directement un accès à la base de données et laisser les opérateurs saisir des requêtes SQL !

J’en parle ici parce qu’il me semble que c’est une idée qui peut être généralisée. Tous les supports qui nous servent à travailler devraient être imprimables et collables au mur.

Dans mon entreprise, les statistiques de visites de nos sites sont imprimées et collées à un mur. Tout le monde peut voir l’évolution de notre trafic et ces courbes rattachent à la réalité, apportent un côté concret qu’il n’est pas toujours évident de percevoir quand on travaille sur des sites Web.

J’ai un ami qui me racontait que, dans son entreprise, ils ont un grand panneau sur lequel ils collent des post-it correspondant aux bugs, aux développements en cours et aux futures fonctionnalités, avec des couleurs différentes. Ça a l’air un peu idiot, très « low-tech », mais il semblerait que c’était assez efficace. Dès qu’un développeur se pose une question, il lui suffit d’aller dans la salle de réunion et de jeter un œil sur la représentation géante de l’état du projet.
L’idée est intéressante et mérite d’être creusée.

Quand on réfléchit à l’ergonomie d’un logiciel ou d’un site Web, on peut assez vite se perdre dans les méandres d’une spécification textuelle dont il est difficile de se faire une représentation en tête, et encore plus difficile à faire évoluer. J’ai vu des situations se débloquées en imprimant le wireframe d’une pages Web, permettant à tous de discuter en se basant sur une représentation partagée par tous.

J’hésite à multiplier les impressions d’indicateurs diverses. La principale raison est écologique (pour tout dire, je suis un gros consommateur de papier de brouillon, et je traque la moindre feuille à recycler ayant encore un verso blanc).

Classé dans Organisation d'équipe

Citation : «Vendredi 17h, ça veut dire lundi»

mar28
2010 Laisser un commentaire Par Amaury

Vendredi matin, un de mes collègues est venu me voir pour qu’on planifie une petite réunion de travail plus tard dans la journée. Si vous avez lu mon billet sur le harcèlement positif, vous savez déjà comment je travaille : Lorsque quelqu’un a besoin de moi pour accomplir une tâche urgente, j’impose à cette personne de rester avec moi pendant que je m’en occupe, même si elle ne fait que me regarder. Par contre, lorsqu’une tâche « externe » (comprendre : qui n’est pas une de mes tâches) n’est pas urgente, j’ai un peu tendance à la repousser jusqu’à ce qu’elle devienne plus importante que mes projets en cours − parce que sinon je ne fais que traiter les problèmes des autres, jamais les miens (et vous pouvez imaginer qu’on me confie des problèmes assez importants).

Donc là, sans réfléchir, j’ai eu le mauvais réflexe de lui proposer de venir me voir à 17h00. Et il m’a répondu très intelligemment : «Vendredi 17h, ça veut dire lundi»

Son point de vue est assez juste. Connaissant les risques de voir des choses urgentes surgir du néant le vendredi soir, qu’on est obligé de régler avant de partir en week-end (loi de Murphy, quand tu nous tiens…), placer une réunion de travail à cet horaire n’était pas très judicieux.

En plus, si ça n’allait pas être traité ce vendredi soir, cela n’aurait pas été le cas non plus le lundi matin (à cause des divers réunions hebdomadaires). Donc lundi après-midi ? Wow, ça commence à faire un gros décalage.

La solution ? On a placé la réunion à 16h30. Les urgences du moment nous ont fait commencer à 16h40, et tout s’est bien passé.

De manière plus générale, il faut toujours envisager le pire. Je reparlerai sûrement de ce sujet dans un autre billet, parce que c’est important. Mais prenons un autre exemple : comme beaucoup d’entreprises, nous ne faisons jamais de mises en production le vendredi. Le risque est trop grand qu’une évolution introduise un bug qui ne soit pas visible immédiatement, ou qu’un « retour-arrière » soit très délicat. Se donner au moins une journée de tampon est une bonne pratique.

Pour tout dire, dans les premiers mois de mon entreprise, nous nous sommes permis quelques fois de passer en production des développements le vendredi, un peu «à l’arrache». À chaque fois, nous pensions que le risque était limité, parce qu’il s’agissait d’évolutions mineures, qui touchaient une partie bien définie du code. Et pourtant, la première version était quasi-systématiquement bugguée − rien de vraiment grave, mais suffisamment pour imposer une révision correctrice.
À bien y réfléchir, on a quand même connu une ou deux sueurs froides à cause de ces mises en production mal maîtrisées et mal planifiées.

«Rien de sert de courir, il faut partir à point.» Dans certains cas, il vaut mieux devancer la planification pour réduire les risques. Et quand ce n’est pas possible, il ne faut pas hésiter à reporter. Mais dans tous les cas, il faut penser avec sa tête, pas avec sa montre.

Classé dans Organisation d'équipe - Libellé ,

Réduire les goulots d’étranglement

mar22
2010 3 Commentaires Par Amaury

Un lecteur de ce blog a fait appel à moi récemment pour l’aider à améliorer l’organisation de son entreprise. Je ne suis pas consultant et je ne cherche pas à l’être, mais j’ai grandement apprécié l’expérience. Je ne vais évidemment rien divulguer de confidentiel à ce propos, mais j’ai quand même envie de partager avec vous quelques éléments fondamentaux de notre discussion.

Il s’agit presque d’un cas d’école : Une petite entreprise qui existe depuis assez longtemps, et avec juste assez de turn-over, pour qu’une partie non négligeable de la connaissance d’entreprise (expérience des clients, expertise technique, gestion des projets) soit concentrée sur le patron. Certains projets ont beau être gérés par d’autres personnes, il continue à jouer un rôle central qui finit par ralentir l’ensemble de l’activité.

Je lui ai proposé un plan de bataille en trois étapes :

  1. Déléguer
  2. Communiquer
  3. Définir un référentiel

Déléguer

Il me semblait important de commencer par imposer une nécessité : Déléguer tous les projets. Quand on est patron d’une entreprise, il faut pouvoir avoir un œil sur l’ensemble des projets, pouvoir intervenir dessus quand il le faut ; mais il ne faut pas être la personne qui a la responsabilité de la réussite du projet.

En déléguant chaque projet, on responsabilise les membres de l’équipe, et on se ménage la possibilité d’aider chaque projet au mieux en fonction des besoins.

Pour résumer, lorsqu’une personne concentre ainsi une majorité de connaissances, elle ne peut pas se consacrer à un projet − cela aurait un impact trop négatif sur tous les autres. Il faut prendre de la hauteur.
Être un manager et non un leader.

Par contre, il faut bien comprendre que la délégation des responsabilités ne veut pas dire qu’on se lave les mains des projets. Il faut au contraire forcer les collaborateurs à découper leurs tâches le plus finement possible. Ainsi il sera facile de définir les priorités entre les tâches, d’évaluer leurs durées, bref de combattre l’effet tunnel.

Communiquer

C’est bien beau de tout déléguer, mais cela fait prendre des risques. Et quand on a pris l’habitude d’être au centre de tous les projets, c’est forcément un peu effrayant.

La plupart des entreprises organisent une réunion hebdomadaire de suivi de projets. Sauf qu’il est difficile de passer le reste de la semaine sans avoir une vision précise de l’avancement des projets, et en cas de soucis on peut rapidement se prendre une semaine entière de retard. C’est ce qui amène souvent à faire du micro-management : on passe son temps à regarder au-dessus de l’épaule des autres, pour savoir où ils en sont ; c’est inefficace et désagréable.

PLUS »

Classé dans Organisation d'équipe - Libellé , , ,

Le «harcèlement positif» comme méthode de travail

fév11
2010 7 Commentaires Par Amaury

Il y a environ un an, je vous parlais du logiciel Action Method. Il propose une fonctionnalité «nagging», qui permet de rappeler au responsable d’une tâche que celle-ci réclame une attention particulière ou une exécution rapide.
J’aime bien cette fonction toute simple mais très utile. J’ai implémenté la même chose dans l’outil de gestion de projets qu’on utilise en interne dans mon entreprise, et je pense l’inclure au projet Skriv.

Les leviers de productivité

Avec le temps, je me suis rendu compte que je me servais − et je ne suis pas le seul − du «harcèlement» comme d’une manière normale de travailler. Non pas que je harcèle les gens avec qui je bosse (c’est puni par la loi !), mais je les incite à me harceler.

Je m’explique : De par mon poste de directeur technique, je suis amené à réaliser un certain nombre de choses par moi-même, mais une part importante de mon travail est de permettre aux autres de travailler. Que ce soit en débloquant un développeur qui reste scotché sur un bug, en aidant l’administrateur sur des tâches IT, en discutant de spécifications avec un chef de projet, en organisant les procédures d’une équipe, … je passe plus de la moitié de mon temps à “mettre de l’huile dans les rouages“.
C’est un calcul simple à faire : Cette vingtaine de personnes, si je peux faire quelque chose pour la rendre plus productive, elle générera plus de résultats que si je me concentre uniquement sur mes tâches. Et même si je ne réussis qu’à améliorer la productivité de 3 personnes, ça en vaudra la peine.

Petit aparté : Cette manière de faire peut être dangereuse si on ne la maîtrise pas. Il ne faut pas devenir le point de passage obligatoire pour toutes les réalisations, sinon on se transforme en goulot d’étranglement. Au lieu de rendre les gens plus productifs, on ralentit au contraire leur travail.

Priorités vs réactivité

Malheureusement, devenir un tel «point central» fait qu’il y a souvent un défilement incessant de personnes qui viennent me demander quelque chose. Parfois c’est juste pour avoir une info ou pour me demander mon avis avant de prendre une décision, d’autres fois c’est pour me demander de réaliser une opération qui va prendre plus de temps.

Au début, je notais les requêtes au fur et à mesure qu’elles arrivaient, en utilisant ma todo-list personnelle, ou notre buglist ou notre logiciel de gestion des tâches. Mais ça ne fonctionnait pas. Les requêtes s’empilaient sans que les demandeurs ne fassent l’effort de réfléchir aux priorités de leurs demandes. Je les traitais suivant leur ordre d’arrivée et non pas suivant leur importance ; j’étais dans la réaction et pas dans la planification.
Évidemment, j’aurais pu simplifier les choses en répondant à chaque demande «Tu as créé un ticket dans la buglist ?», et attendre le lendemain pour revoir l’ordre de priorité de toutes les tâches en attente. Mais perdre en réactivité n’est pas la bonne réponse à un problème d’identification des priorités.

Le harcèlement positif

Au final, quand quelqu’un a besoin de moi, il y a 3 scénarii :

  1. Je suis occupé à faire quelque chose d’important et long. Je demande de revenir plus tard, mais je m’informe quand même de l’importance de la demande (au cas où).
  2. Je suis occupé, mais je n’en ai plus que pour 2 minutes. Je demande à la personne de s’asseoir à côté de moi et d’attendre que j’ai fini. Quand les demandes ne sont pas si importantes que ça, les gens n’ont naturellement pas la patience d’attendre. Ils agissent comme si j’allais systématiquement m’arrêter de travailler pour traiter leurs requêtes dans la seconde ; mais si on leur demande à eux d’attendre, ils y réfléchissent à 2 fois.
  3. Il y a déjà plusieurs personnes qui font le pied de grue pour utiliser mon «temps machine». Dans ce cas, on évalue collégialement les priorités. Mais il y a un effet naturel qui s’ajoute : Lorsque quelqu’un attend depuis longtemps, il fait ce qu’il faut pour ne pas continuer à attendre ; soit il finit par abandonner (ce n’était pas si important finalement), soit il réussit à nous convaincre de l’importance de sa demande.

Quand quelqu’un a réussi à m’atteindre (si je puis dire), je lui demande de rester assis à côté de moi pendant tout le temps que je vais prendre pour réaliser ce qu’il me demande. Ceci est valable pour toutes les tâches «normales». Si une tâche va me prendre plusieurs heures, je l’intègre à ma todo-list globale.
On pourrait s’étonner du fait que je force des non-techniciens à rester près de moi, même quand je ne fais qu’exécuter des actions techniques. Pourtant, c’est justement ce qui fait que cela fonctionne :

  • Si la personne s’en va, il y a de gros risques que quelqu’un d’autre arrive juste derrière et me fasse travailler immédiatement sur une tâche plus urgente. Cela a moins de chances d’arriver si je suis visiblement occupé avec une autre personne.
  • Si la personne qui me demande quelque chose ne peut pas rester avec moi, si elle a plus important à faire que de s’assurer que je m’en occupe rapidement, c’est sûrement que ce qu’elle me demande n’est pas très important. Ou en tout cas, cela veut dire que j’ai moi aussi d’autres tâches plus importantes dont il faut que je m’occupe.
  • En gardant les requérants auprès de moi, je peux leur donner les informations qui leur permettront d’être indépendants la prochaine fois. Si par contre je m’en charge toujours de A à Z, tout seul dans mon coin, il n’y a aucune chance qu’ils montent en compétence.
  • Au moment où la tâche est terminée, ils en ont aussitôt un statut exact et complet. Il n’y a pas de tergiversation, il n’y a pas de perte d’information à cause d’une communication incomplète.

Qu’en penser ?

Je suis conscient de l’aspect complètement empirique de cette manière de travailler. Peut-être qu’elle ne peut pas s’appliquer à toutes les personnes ni à toutes les situations. Mais je l’ai vu fonctionner à maintes reprises, et ça fonctionne dans mon entreprise.

D’une certaine manière, cela me rappelle certains aspects de la méthode Getting Real de 37signals. Entre autres son paragraphe Start With No. On peut y retrouver des notions similaires :

  • On doit parfois ajouter des contraintes pour devenir plus efficace.
  • Les idées importantes finissent toujours par se faire entendre. Sans système de filtrage, c’est la cacophonie.
Classé dans Organisation d'équipe - Libellé , ,
← Older Entries Newer Entries →