De geek à directeur technique

Le blog d'un geek devenu directeur technique

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

Organisation d'équipe

Comprendre les gens pour les faire travailler ensemble. Écouter, collaborer, s'imposer.

À lire en premier :

Si vous cherchez un bon bouquin, jetez vous sur Managing Humans.

 

Fil des billets - Fil des commentaires

mardi 27 juillet 2010

Ma méthode «musicale»

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.

Cette méthode est celle que je pratique depuis plusieurs années. Forcément, c'est plus facile quand on joue avec les mêmes personnes depuis 8, voire 10 ans. J'oscille entre le rôle ingrat habituellement réservé aux bassistes de rock (soutenir le rythme) et mes velléités mélodiques (en mettre plein partout). J'aime la basse car c'est un instrument à la fois harmonique et rythmique − c'est pour ça que la basse 6 cordes me convient si bien.

Bref, je me suis souvent demandé s'il y avait des enseignements à tirer de tout cela, applicables à mes activités professionnelles. Et je me suis rendu compte qu'au final c'est exactement la même chose avec les méthodes de travail.

La partition professionnelle

J'ai déjà dit sur ce blog que les méthodes de travail ne sont que des modèles théoriques, et qu'il faut savoir les adapter à nos besoins. Je me suis aperçu que, pour y arriver, j'utilisais le même cheminement que pour la musique.

  1. Simplifier. Appliquer telle quelle une méthode de travail à une entreprise ou un groupe de projet est quasi-impossible. Le plus important est de comprendre en quoi cette méthode est différente des autres, quels en sont les points spécifiques qui vous ont conduit à vouloir l'utiliser. Retirez le superflu et concentrez-vous sur l'essentiel.
  2. Observer. Mettre en place une organisation de travail, cela ressemble beaucoup à faire une greffe. Un rejet peut survenir à tout moment. Il faut donc observer attentivement, pour voir les points qui ne sont pas suivis, et comprendre pourquoi. Certaines fois, il faudra insister sur ces points-là, d'autres fois vous pourrez finalement les laisser de côté si leur adoption n'est pas générale.
  3. Adapter. Si vous avez pris le soin de bien observer votre entreprise, vos collaborateurs et vos projets, vous devriez sentir les problèmes qui vont apparaître. C'est simple : si vous avez l'impression qu'il manque une procédure ou que quelque chose est mal défini, c'est que la méthode est incomplète dans votre cas spécifique d'utilisation. Ajoutez donc ce qui manque, en vous inspirant de tout ce que vous pourrez trouver (y compris grâce à votre propre imagination). Vous voulez saupoudrer du Scrum sur un cycle en cascade ? Rien de vous en empêche. Vous souhaitez intégrer quelques principes de l'extrem programming sur un process basé sur un cycle en V ? Essayez !

L'improvisation et l'adaptation sont des qualités qui permettent aussi bien de composer une œuvre musicale que d'améliorer l'organisation d'une entreprise. Rien n'est monolithique, contrairement à ce qu'essayent de nous faire croire la plupart des livres qui traitent des méthodes de travail. Chaque situation est différente. En entreprise, l'arrivée d'un nouveau collaborateur ou la signature d'un nouveau client peuvent vous amener à revoir en profondeur vos manières de travailler. Oui, c'est un équilibre aussi précaire que ça.
Mais justement, c'est ça qui est fun. Quand vous avez des responsabilités, vous êtes toujours en train de vous assurer que l'équilibre est respecté, tentant d'anticiper les futures pertes d'équilibre.

Tout cela est évidemment très empirique. C'est ainsi que je fais les choses naturellement, mais c'est intéressant d'étudier la question, non ?

À propos de la théorie et de la pratique

Il y a un autre parallèle à faire entre mon parcours musical et le monde de l'entreprise, celui de la formation.

Quand j'ai commencé la basse, j'ai pris des cours avec un très bon professeur pendant près de 2 ans. Cela m'a permis de prendre de bonne habitudes, de m'améliorer rapidement, d'acquérir un socle solide de connaissances sur la théorie musicale.
À côté de ça, j'ai toujours joué dans des groupes. Le premier groupe dans lequel j'ai joué, cela faisait à peine 2 mois que je pratiquais la basse. Grâce à ça, j'ai pu aborder la musique sous un angle moins intellectuel. C'est ce qui m'a appris la souplesse de la musique : on peut jouer avec les règles, l'important c'est que ça sonne.

Je connais des musiciens qui ont appris uniquement par eux-même. Certains ont développé de mauvaises habitudes : des guitaristes qui ne savent pas faire autre chose qu'un accord en quinte, des batteurs qui ne savent pas accorder leur batterie (oui, les batteries s'accordent) ni battre une mesure en 16/8. D'autres ont atteint une très bon niveau, mais cela leur prend plus de temps que s'ils avaient suivi une formation factuelle.
Je connais aussi des musiciens qui ont fait un parcours très complet en conservatoire, sans jamais sortir des «sentiers battus». Certains sont incapables de composer, ou même de participer à une composition. Beaucoup n'en ont même pas envie, ayant été formatés par des années à jouer une musique dite parfaite dont les œuvres ont plus de 200 ans (vision sclérosante des choses, non ?).

Les meilleurs musiciens avec qui j'ai joué ont suivi des cours, parfois en conservatoire, parfois pendant plus de 10 ans, mais toujours associés à des activités de composition seul et en groupe.
J'ai tendance à voir les choses un peu de la même manière concernant la formation des informaticiens. Faire des études longues, c'est bien ; y associer des stages, c'est mieux.

L'informatique est encore une sorte d'El Dorado ; chacun peut s'y lancer, développer ses propres compétences et en faire une activité commerciale. Ce n'est pas réglementé comme certaines professions (médicales, notamment).
J'ai rencontré pas mal d'autodidactes complets qui avaient un niveau technique incroyable. Mais il leur manquait souvent la capacité à analyser un problème jamais rencontré jusque là. Lorsqu'il fallait raisonner au niveau algorithmique, trouver par eux-même des solutions innovantes, ce n'était pas toujours évident.
J'ai connu aussi de jeunes informaticiens particulièrement brillants, des cerveaux qui avaient fait de longues études théoriques. Il leur manquait souvent la vision réaliste des choses qui leur permettrait de faire les bons choix. Par exemple, j'ai connu un gars très intelligent, qui voulait développer un code basé sur un algorithme génétique ; mais ce qu'on lui demandait, c'était juste un parseur (un peu compliqué comme parseur, certes ; mais il lui a fallu moins de temps pour tester et comparer les 3 ou 4 algorithmes possiblement utilisables que pour de mettre en place son algo génétique).

Il y a toujours des gars qui font des études purement théoriques et qui deviennent de vraies machines à apprendre. En sortant d'école ils ne savent rien faire, mais donnez-leur un peu de temps et d'expérience et ils atteignent des sommets. Ça existe, mais ce n'est pas courant.
De la même manière, rien n'empêche un autodidacte d'atteindre un niveau exceptionnel en prenant en main sa propre formation. Là aussi, c'est rare mais ça arrive.

Pour se donner les meilleures chance, il faut donc associer les aspects théoriques et pratiques. Mais j'espère que c'était déjà évident pour tout le monde.

jeudi 13 mai 2010

Améliorer les flux d'information

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.

Le pire, c'est qu'on a tous fini par s'habituer à cet état de fait. On a l'impression que c'est comme ça depuis toujours, et il n'y a aucune raison pour que ça change.

Mais on peut éviter ça

Toutes les entreprises devraient pourtant essayer de contrer cette vague incontrôlée de communications inutiles. Parce que le temps perdu par le traitement de ces informations finit par générer des coûts injustifiables.

La bonne nouvelle, c'est qu'il n'y a pas obligatoirement besoin d'une politique d'entreprise globale. Chacun peut commencer par mettre en place des habitudes différentes avec juste ses collègues les plus proches ou son équipe de projet.

La méthode tient en quelques points simples :

  1. Avant de transmettre une information, demandez-vous :
    1. Est-ce le destinataire en a vraiment besoin. S'agit-il d'une information nécessaire pour accomplir son travail ?
    2. Est-ce que le vecteur d'information est le plus adapté ? Les échanges d'emails ne sont pas adaptés aux assignations de tâches ni aux partages de documents.
  2. Faites ce qu'il faut pour que l'information soit rapidement identifiable par son destinataire :
    1. S'il s'agit d'un email, donnez-lui un titre explicite, et préfixez-le avec le nom du projet concerné. Sur d'autres systèmes d'information, utilisez intelligemment les labels ou tags disponibles.
    2. Synthétisez le contenu de ce que vous voulez transmettre. N'imposez pas aux autres de devoir lire une prose de trois kilomètres de long, ou de devoir relire un échange de 25 emails pour comprendre de quoi il en retourne.

Mon expérience

Évidemment, ce n'est pas toujours facile de simplifier les échanges. On se retrouve parfois dans des situations cocasses, avec des personnes qui se sentent offensées de ne pas avoir été mises en copie d'un email qui ne leur servait à rien, ou d'autres qui déploient des trésors d'ingéniosité pour couvrir leurs arrières de manières nouvelles et originales (comme par exemple en utilisant la "politique de réduction" pour justifier l'absence d'information sur le retard pris par leur projet, alors que plusieurs réunions auraient permi de le faire de toute manière).

De mon côté, je demande à ce que les emails qui me sont envoyés soient préfixés par le nom de projet entre crochets (c'est une convention très répandue). Quelques exemples :

  • [IT] Problème serveurs résolu
  • [ComprendreChoisir] Ajout fonctionnalité de tri sur page produits ?
  • [corporate] On n'a plus de PQ

Je préviens régulièrement mes interlocuteurs qu'un message mal titré sera lu avec beaucoup de retard. Ce n'est pas une volonté de ma part, c'est juste que j'ai au final assez peu de temps à consacrer à mes emails, et je me retrouve parfois plongé dans du boulot jusqu'au cou pendant plusieurs heures. Un message mal titré n'éveillera pas ma curiosité, et risquera d'être lu seulement en fin de journée.

Par ma place de directeur technique, un grand nombre de messages "informatifs" me sont envoyés, qui ne sont là que pour me permettre de garder un œil sur la progression des projets. Je n'y vois pas d'inconvénient, dans la mesure où ces messages ne sont pas prioritaires (ils ne seront peut-être pas lus) et que les mêmes informations arrivent jusqu'à moi lors des réunions quotidiennes que je fais chaque matin avec mon équipe.

Mais j'essaye d'inciter l'ensemble des personnes de mon équipe à réduire la quantité de messages échangés, et à se poser les quelques questions que j'ai cité plus haut. Cela prend du temps, mais c'est utile.

lundi 26 avril 2010

Encore un peu de délégation

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.

3. Les grands couturiers sont connus pour leurs "petites mains" qui cousent à leur place. C'est assez logique : Ce qu'on leur demande, c'est de dessiner de beaux modèles, de choisir de beaux tissus, de sentir les tendances, de créer ce qui va être la mode de demain.
On ne s'attend pas à ce que Jean-Paul Gaultier ou Christian Lacroix cousent eux-même les vêtements qu'ils vendent. Par contre, ceux qui mettent le prix y voient des garanties quant à la qualité factuelle de ce qu'ils achètent et y sentent la "patte" du maître.

Concrètement, ça donne quoi ?

Pour bien me faire comprendre, je fais un petit parallèle entre une entreprise et un orchestre philharmonique.
Imaginons 3 professions d'un côté : violoncelliste, violoniste soliste, chef d'orchestre.
Imaginons 3 autres professions : développeur, architecte logiciel, chef d'entreprise.
N'y a-t-il pas une certaine similitude ? Certains chefs d'orchestre sont tellement talentueux que les gens viennent spécifiquement à leurs concerts. Pourtant, le chef d'orchestre ne peut rien faire tout seul (à part faire un long solo de triangle très ennuyeux, peut-être).

Je suis persuadé que c'est la même chose pour une entreprise. Déléguer tous les projets ne veut pas dire de ne pas s'en occuper. Au contraire, ça veut dire qu'on se donne les moyens pour pouvoir agir dessus quand il le faut, dès qu'il le faut, sans être pollué par le "quotidien" des projets − et sans que les projets ne prennent de retard dès qu'on doit consacrer toute son énergie à l'un d'eux.

En déléguant la gestion des projets, ils continueront à vous phagocyter autant qu'avant, dans un premier temps. Puis vos collaborateurs monteront en compétence, ils essaieront de traiter eux-même les problèmes, parce qu'ils se sentiront attachés aux projets dont ils auront la responsabilité. Plus le temps passera, plus ils seront compétents. Parce qu'ils seront responsabilisés.

Et surtout, c'est aux chefs de projet de faire avancer les projets. C'est à eux d'identifier les soucis et d'aller voir leur boss pour faire appel à son expertise. C'est à eux de détecter les points de blocage, même si c'est leur responsable qui a la légitimité de choisir les solutions de déblocage. Évidemment, c'est au chef d'entreprise de surveiller de près si tout se passe bien, si les délais sont respectés et que la qualité est bonne.

Et ça, vos clients sont prêts à l'entendre. Ils ne s'attendent pas à ce que le patron soit le seul à travailler sur leur projet. Ils s'attendent à ce qu'il garantisse le résultat, et qu'il soit leur interlocuteur en cas de besoin.

mardi 20 avril 2010

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

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).

dimanche 28 mars 2010

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

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.

- page 1 de 8