Travailler en période de rush

AmauryOrganisation d'équipe10 commentaires sur Travailler en période de rush

Depuis deux semaines, mon entreprise est en train de traverser une période de rush. Nous finalisons un gros projet, qui doit être déployé en production très bientôt. Cela s’est ressenti sur le nombre de posts sur ce blog, qui a drastiquement diminué.

Voilà le topo : Nous sommes en train de conclure le travail de ces 2 derniers mois, et qui va relancer le travail de ces 2 prochains mois. Comme pour tout projet d’importance, il y a un peu de retard, mais surtout un risque de retard. Il a donc fallu mettre les bouchées doubles pour s’assurer que le projet sorte dans les temps.

Mais comment faire pour que toute une équipe réussisse ce qui ressemblait un peu à un tour de force ? Comment s’assurer que tout le monde réponde présent au moment où il le faut ? Comment garder intacte la motivation alors qu’on va passer une semaine longue et difficile ?

Expliquer la situation

Tout le monde a connu des périodes de rush. Ce n’est pas agréable pour personne de faire des horaires 08h30-20h30 pendant plusieurs jours d’affilée, mais parfois il faut le faire.

Le pire des scénarii possibles, c’est lorsque les patrons mettent de plus en plus de pression au fil du temps ; ils s’énervent parce qu’ils voient le retard s’accumuler. Résultat, tout le monde commence à bosser un peu plus, par peur des éclats de nerf du boss plutôt que par envie de voir le projet aboutir.

Nous avons choisi l’optique inverse. En début de semaine, nous avons réuni l’équipe.

  1. Nous avons expliqué les raisons pour lesquelles il était important – pour l’entreprise mais aussi pour les employés – que le projet sorte dans les temps. Un projet stratégique est souvent susceptible de générer un chiffre d’affaires vital au développement de l’entreprise. La croissance de l’entreprise est synonyme de vitalité pour les emplois, de perspectives d’évolution pour les employés.
  2. Nous avons rappelé qu’après 2 mois durant lesquels tout le monde s’est investi dans le projet, nous étions maintenant dans la dernière ligne droite. Ce n’est pas le moment de ralentir ; il faut au contraire accélérer le rythme, concrétiser ce travail intensif en réussissant à le mettre en production.
  3. Nous avons présenté l’horizon des prochains mois, et comment le projet actuel conditionne directement les futures tâches de chacun. Si le projet se conclut de manière satisfaisante, ce sera un tremplin formidable qui donnera le tempo à la suite ; si par contre les choses tournent mal, tout le monde en souffrira.
  4. Nous avons demandé à tous les intervenants de jouer le jeu, de se « sortir les doigts du cul », de faire tout ce qu’ils peuvent pour faire en sorte que le projet sorte dans les temps et avec la qualité qu’on en attend. La durée de l’effort (une grosse semaine) est assez courte pour qu’on puisse y arriver.

Et vous savez quoi ? Tout le monde a répondu présent.

Faire l’évaluation annuelle de votre équipe

AmauryOrganisation d'équipe4 commentaires sur 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

AmauryOrganisation d'équipe3 commentaires sur 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

AmauryOrganisation d'équipe12 commentaires sur 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

AmauryOrganisation d'équipeLaissez un commentaire sur 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.

L’encadrement des juniors

AmauryOrganisation d'équipeLaissez un commentaire sur 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.

Le nocif

AmauryOrganisation d'équipeLaissez un commentaire sur Le nocif

Dans la série des billets consacrés aux types de collègues, et pour faire la suite à ceux consacrés aux affectifs et aux revendicateurs, je vais aujourd’hui vous parler des « nocifs », c’est-à-dire des personnes qui – pour une raison ou une autre – sont réellement néfastes pour une équipe ou une entreprise. Nous allons voir comment reconnaître un nocif, et quelles sont les solutions qui s’offrent à vous pour traiter leurs cas.

À quoi reconnaît-on un nocif ?

Nous avons tous cotoyé au moins une personne dont le comportement ne semblait pas correspondre à celui attendu. Cela peut toucher un assez grand nombre d’attitudes :

  • Connaissances techniques trop faible. Un développeur qui est tellement mauvais techniquement qu’il produit systématiquement du mauvais travail.
  • Problèmes d’horaires. Quelqu’un qui arrive à 11h00 le matin et part à 17h30 le soir, ou qui se prend 20 minutes de pause toutes les 45 minutes.
  • Non-implication dans son travail. Une personne qui se met dans un simple rôle d’exécutant, au lieu d’utiliser ses compétences et son imagination pour faire réellement avancer ses projets.
  • Mauvaise volonté systématique. Quelqu’un qui réfute par principe toutes les idées qui lui sont soumises, ou qui ne prend en compte que les choix qui l’arrangent.
  • Problèmes de communication. La personne qui reste dans son coin en parlant le minimum possible. La personne qui n’arrive pas à avoir un débat constructif, et s’énerve dès que ses idées ne sont pas suivies. Celui qui ramène toutes les discussions à ses propres problèmes immédiats.
  • Problèmes avec l’autorité. Quelqu’un qui n’accepte pas qu’une autre personne puisse décider de ses priorités et de son planning.
  • Comportement non professionnel. Une personne qui se permet d’insulter ses collègues. Un commercial qui tutoies les clients. Un chargé de clientèle qui n’offre pas toute l’écoute qu’li devrait.

Test Driven Development

AmauryOrganisation d'équipe2 commentaires sur Test Driven Development

Je vous parlais récemment des tests unitaires. Je vous parlais entre autre de la difficulté d’imposer la discipline nécessaire à la réalisation de tests unitaires corrects et de leur maintien opérationnel.

Il existe une méthode de travail qui permet de forcer l’écriture des tests unitaires (tout au moins au début des développements). Il s’agit des développements guidés par les tests (ou Test Driven Development en anglais).
Cette méthode est toute simple à comprendre : Avant d’écrire un bout de code, on commence par écrire les tests qui vont vérifier la conformité du code.

Prenons l’exemple d’un code orienté objet. Imaginons que nous nous préparons à écrire une nouvelle classe.

  • On modélise l’objet, donc on connait ses méthodes publiques. On sait quelles entrées doivent produire quels résultats.
  • On écrit des tests pour vérifier les méthodes de l’objet.
  • On écrit le squelette de l’objet, avec juste les déclarations des méthodes.
  • On exécute les tests unitaires, qui tombent évidemment en échec.
  • On écrit le code de l’objet, en vérifiant que les tests passent un à un.

L’avantage avec cette manière de faire, c’est qu’au moment où le code est écrit, on est quasi-certain qu’il est conforme au comportement qu’on attend de lui. Pour peu qu’on ait pris soin de lancer régulièrement les tests unitaires au cours du développement, le code est rapide à valider.

Par contre, il va sans dire que si le TDD permet d’avoir des tests unitaires corrects pour de nouveaux développements, le problème reste entier pour l’évolution de code existant. La vigilance habituelle reste donc de mise, pour que les tests ne prennent pas la poussière. Mais il est possible de respecter cette démarche pour toutes les évolutions de code : On commence par modifier les tests unitaires existants, ou les compléter ; puis on effectue les développements qui valideront ces tests.

Mon expérience

Le TDD est ce que je qualifierais de vraie fausse bonne idée. En fait, j’ai vu plusieurs fois le même cheminement intellectuel être suivi par des équipes qui mettaient en place cette méthode :