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.

La R&D : pour ne pas confondre développement et veille techno

Il y a quelques temps, je vous ai parlé de la veille technologique. Je vous ai expliqué en quoi c’est un élément important de nos vies professionnelles.

Je voudrais cette fois-ci vous mettre en garde contre une dérive finalement assez commune chez les jeunes développeurs, qui est d’utiliser les projets professionnels comme un terrain de jeu pour réaliser leurs expérimentations. Ensuite nous réfléchirons aux moyens de canaliser la fougue qui conduit à ces dérapages.

Les expérimentations au boulot

Il y a quelques années, alors que j’étais chef de projet, un de mes développeurs – un prestataire externe, en fait – avait demandé une demi-journée de congé pour assister à une conférence organisée par Google France. J’étais content de voir qu’il prenait à coeur sa veille technologique.
À son retour, je lui ai évidemment demandé de me faire une présentation rapide de ce qu’il avait vu. Il s’agissait des premières versions des toolkits de Google, et ça avait l’air vraiment intéressant.

Nous étions alors en train de démarrer un nouveau projet, et ce développeur était en charge de certaines spécifications techniques. Quand j’ai vu dans ses specs qu’il envisageait d’utiliser les technologies Google qu’il venait d’entrapercevoir, j’ai eu une petite discussion avec lui.

Le message tient en 2 points :

  • Bien qu’absolument nécessaire, la veille technologie est une démarche personnelle. C’est à chacun de se trouver ses propres petits projets qui lui permettront de tester de nouvelles technos ou de nouveaux outils.
  • Un projet mené au sein de l’entreprise répond à des contraintes contractuelles et financières. Vouloir y glisser des technologies qui ne sont encore qu’à l’état de bêta, ou qu’on ne maîtrise absolument pas, est une erreur assez grave.

Canaliser et organiser

Il n’empêche qu’il n’est pas logique d’inciter à la veille tout en la réprimant dans le cadre de l’entreprise. L’entreprise a certains devoirs de formation vis-à-vis de ses employés, il faut s’en occuper de manière raisonnée et planifiée.

Préparer votre évaluation annuelle

La plupart des entreprises effectuent des entretiens annuels ou bi-annuels de leurs collaborateurs. Il sont habituellement réalisés par les managers, parfois avec l’assistance du DRH.

À quoi servent ces entretiens ?

Tout le monde attend ces entretiens avec impatience, mais souvent pour de mauvaises raisons. Un grand nombre de salariés n’y voient que le moment où va leur être annoncée leur augmentation de salaire. C’est évidemment un élément important de ces discussions, mais il ne faut pas que cela devienne une obsession qui occulte les autres aspects.

Les entretiens annuels sont un moment privilégié, pendant lequel on peut prendre un peu de recul par rapport à l’année (ou le semestre) écoulée. Le but est de récapituler les points forts et les points faibles, de revenir sur notre évolution au fil du temps ; comment on a réussi à s’améliorer, à progresser dans l’exécution de nos tâches.

Préparer l’entretien

Quelques jours avant l’entretien, prenez le temps de vous poser ces quelques questions :

  • Où en étais-je il y a un an, il y a 6 mois ? Mes supérieurs étaient-ils satisfait de mon travail ? Pourquoi ?
  • Quelle était l’évolution qu’on attendait de mois durant cette période ? Est-ce que mes objectifs étaient clairement définis ?
  • Quelles sont mes forces et mes faiblesses aujourd’hui ? En quoi sont-elles différentes d’auparavant ?
  • En toute honnêteté, quels sont mes coups d’éclats et mes ratages complets ?
  • Globalement, en suis-je là où je voudrais être ? Ai-je développé les connaissances et les capacités que je voudrais avoir ?

Quand vous avez répondu à ces questions, demandez-vous où vous voulez aller :

  • Suis-je satisfait de l’environnement technique dans lequel j’évolue, des projets sur lesquels je travaille ?
  • Dans quelle direction ma carrière doit-elle évoluer ? Qu’est-ce que je veux faire dans 6 mois, dans 1 an, dans 2 ans ?
  • De quelle aide ai-je besoin pour progresser ?

Une fois que vous avez fait le tour de ces questions (et seulement à ce moment-là), vous pouvez vous poser d’autres questions :

Faire l’évaluation annuelle de votre équipe

La plupart des entreprises font une évaluation annuelle ou biannuelle de tous leurs collaborateurs. C’est un moment important, pendant lequel l’employé et son supérieur hiérarchique font le bilan du travail effectué, redéfinissent la mission et les résultats attendus. C’est souvent le bon moment pour parler ouvertement de ce qui va et ne va pas au niveau de l’entreprise, des méthodes de travail, des relations professionnelles, etc.

Pour un manager

Vous devez faire passer les entretiens d’évaluation des membres de votre équipe. Ils attendent ce moment, peut-être avec plus d’impatience que vous ne pensez, car ils y voient – à juste titre – un moment privilégié pour partager avec vous leurs problèmes et leurs doutes.
Prenez le temps de préparer convenablement chaque entretien. Si vous n’avez vraiment pas de temps à y consacrer, essayez plutôt d’organiser des discussions plus informelles autour d’un café ; vous pouvez même le faire dans un bar ou un restaurant, pour sortir du cadre de l’entreprise ; ce genre de discussion peut se révéler presque aussi productif qu’un entretien carré.

Il est assez classique d’utiliser 2 indicateurs pour évaluer les personnes : le Skill et le Will. Ces deux barbarismes sont assez simples à comprendre :

  • Skill : les connaissances, les capacités, ce que sait faire le collaborateur.
  • Will : la volonté, l’implication du collaborateur, ainsi que son ambition.

Quand remettre les gens à leur place

J’ai souvent parlé du comportement en entreprise, en insistant sur l’aspect humain que doivent avoir les relations professionnelles. L’empathie – la capacité de comprendre les gens – et la politesse – se mettre à la place des autres – sont des qualités plus qu’appréciables dans la vie de tous les jours, mais aussi au travail. L’ère des chefs d’entreprise-dictateurs est révolue. Le meilleur moyen de faire travailler une équipe est de faire en sorte que ses membres se sentent bien et apprécient de travailler en commun.

Toutefois, il existe un cas (un seul !) où l’on peut sortir de ses gonds. C’est quand on a en face de soi une personne qui, justement, n’en a rien à faire des autres. C’est un comportement détestable, qui pourtant se rencontre de temps en temps.

Commençons par analyser le cas. De manière générale, les gens sont relativement civilisés et polis. Parfois, certaines discussions peuvent s’envenimer un peu, mais les choses restent globalement à un niveau acceptable. Mais certaines personnes utilisent cet état de fait, la plupart du temps de manière inconsciente, pour s’affirmer par la force ; ces personnes savent pertinemment qu’elles prennent peu de risques à se montrer odieuses.
Prenez par exemple ceux qui mettent de la musique à fond dans les transports en commun. Ils gênent à eux seuls plusieurs dizaines de personnes, mais ils s’en moquent. Consciemment, ils se disent juste « Je fais ce que je veux » ; mais surtout, leur subconscient leur susurre « C’est bon, tu peux y aller, de toute façon personne ne va oser bouger le petit doigt ! ». Et finalement, c’est bien ce qui arrive ; tout le monde se laisse emmerder, se disant qu’il vaut mieux supporter ça 15 minutes que de chercher le conflit.
Autre exemple : Un enfant chahuteur ira chercher la bagarre avec les plus petits que lui, parce qu’il sait qu’ils ne répliqueront pas.

Dans le monde de l’entreprise, c’est pareil.

Scrum : introduction

Scrum est une méthode de gestion de projet très intéressante. Pour mon premier article à son propos, je vais vous la présenter rapidement, et vous parler de l’un de ses concepts-clés : les sprints.

Scrum est une méthode agile qui ne se focalise pas spécialement sur les techniques de développement, mais plutôt sur l’organisation de projet et la gestion d’équipe. C’est une méthode moderne qui a fait ses preuves dans de nombreuses circonstances.

Présentation des rôles

L’image suivante présente d’une manière assez synthétique les différents rôles qui interviennent dans une équipe Scrum :

(image © Avangel, Wikipedia)

  • Le directeur de produit : Je préfère utiliser le terme de chef de projet fonctionnel. Son rôle est de présenter à l’équipe les fonctionnalités qu’elle devra développer, et de transmettre l’ordre de priorités. Il opère un suivi régulier avec l’équipe de développement, et remonte régulièrement les informations d’avancement au client.
  • Le Scrum Master : C’est un personnage très spécial qui prend en charge tous les aspects non techniques pour « protéger » l’équipe, particulièrement pendant les périodes de sprint (voir plus bas). Toutes les requêtes doivent passer par lui, pour s’assurer du respect de la méthode. C’est un rôle qu’on pourrait approcher de celui que je tiens – en temps que directeur technique – vis-à-vis de mes développeurs (hormis que je gère en plus des aspects techniques comme la validation des spécifications techniques).
  • L’équipe de développement : La théorie voudrait que l’équipe soit auto-gérée, et que ses membres prennent eux-mêmes leurs décisions de manière collégiale. D’expérience, j’ai rarement vu une équipe fonctionner correctement quand on la laisse faire ce qu’elle veut. Pour que ça fonctionne, il faut avoir des développeurs très compétents, avec de l’expérience, et surtout qui apprécie les contacts humains. Et malheureusement, toutes les équipes ont leurs stagiaires, leurs pas-très-bons-techniquement ou leurs autistes…

Les sprints

Au coeur de Scrum, il y a la notion de sprint. Le principe est de définir un lot de fonctionnalités à développer, puis de partir dans une phase de développement de durée « raisonnable » (2 à 4 semaines). Évidemment, l’ensemble des fonctionnalités doit avoir été prévu pour pouvoir être développé dans ce laps de temps.

L’important dans cet exercice, c’est de bien comprendre – et surtout faire comprendre aux autres acteurs – qu’une fois qu’on a défini la liste des fonctionnalités et qu’on a écrit les spécifications fonctionnelles, on entre dans une phase de quelques semaines pendant laquelle il est absolument interdit de changer les objectifs de développement. Cela a pour effet de pousser les clients à bien spécifier leurs besoins, car une fois que le sprint est lancé, il n’est pas possible d’ajouter de nouvelles fonctionnalités ni de changer l’ordre de priorité.

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.