Les pompiers pyromanes

L’un des profils de collaborateur les plus difficiles à manager sont les « pompiers pyromanes ». Voyons à quoi on reconnait un tel profil, les dangers qu’ils peuvent représenter et les solutions qui existent pour les gérer.

C’est quoi un pompier pyromane ?

Peut-être que vous vous êtes déjà retrouvés dans cette situation. Vous assignez des tâches à vos développeurs (ou ils se les répartissent eux-mêmes dans le cas d’une équipe auto-organisée) ; ces tâches sont souvent en deux groupes : les nouveaux développements d’un côté, et les débuggages ou micro-évolutions de l’autre.

Pour schématiser, les nouveaux développements prennent du temps, plusieurs jours voire plusieurs semaines, alors que les débuggages ont des durées qui se comptent en heures la plupart du temps. L’investissement nécessaire est donc très différent, que ce soit au niveau de la réflexion technique à mener que dans la durée de concentration à avoir sur son travail.

Un pompier pyromane, c’est avant tout un « pompier », c’est-à-dire quelqu’un qui se sent bien dans le rôle de sauveur. A chaque fois qu’il résout un bug, il est remercié chaudement par la ou les personnes qui étaient impactées au quotidien. Plus il est rapide dans la résolution de problèmes, plus sa valeur semble augmenter aux yeux de ses collègues. C’est normal, il leur facilite la vie, il résout leurs soucis.

Au fur et à mesure, ce genre de personne va vouloir de moins en moins travailler sur de nouveaux développements. Après tout, pourquoi vouloir bosser dans l’ombre pendant plusieurs jours, à se casser la tête à résoudre des enjeux techniquement complexes ? Quand un nouveau projet est mis en production, les développeurs qui ont travaillé dessus sont rarement acclamés ; ils reçoivent peut-être des félicitations par leur hiérarchie, mais pour les collègues des autres services c’est au final assez peu visible. Dans le pire des cas, c’est même une source de nouveaux bugs. C’est tellement mieux d’être vu comme celui qui corrige les bugs plutôt que d’être celui qui les crée, non ? Continuer la lecture de « Les pompiers pyromanes »

De la gestion de projet à la gestion de workflow

Il y a une chose qui me chiffonne lorsqu’on s’intéresse aux méthodologies agiles, telle qu’elles sont définies « by the book », ou telle qu’elles sont enseignées. On y décrit un fonctionnement à base de sprints de développement, qui s’enchaînent les uns après les autres, avec une durée de l’ordre de la quinzaine de jours. Même en décrivant la partie qui se situe en amont du développement (écriture de user stories, gestion du backlog), et celle qui se situe en aval (tests, validation, mise en production), tout reste centré sur le développement.

Au final, dans la vraie vie, ces périodes de conception et de validation finissent par manger sur la période de 2 semaines qui devrait être consacrée au développement. On se rend compte assez vite des limites du système…

De mon point de vue, il faut prendre la gestion de projet à un plus haut niveau. Et il faut définir un workflow global, qui va permettre à tous les intervenants du projet de savoir ce qu’ils ont à faire et pour quand. Je vais illustrer cela en expliquant ce qui est mis en place dan mon entreprise ; c’est le fruit d’un process dérivé de la méthode Scrum, qui est affiné sans cesse depuis plus de 5 ans. Continuer la lecture de « De la gestion de projet à la gestion de workflow »

L’image que les marketeux ont de l’informatique

Cette semaine, j’ai fait partie d’un groupe de réflexion au sein d’une grande entreprise. Ce groupe rassemblait des gens d’horizons différents, et le but était de trouver des solutions pour faire évoluer la culture de cette entreprise. Comme toutes les grosses boîtes, elle est devenu un énorme navire difficile à manœuvrer et qui a du mal à être réactif à cause de toute l’inertie subie en interne.

Pour faire simple, cela tenait en une phrase :

Ramener la culture start-up dans l’entreprise.

La réunion de travail a été démarrée par le directeur technique de cette société. Un gars très intelligent qui a déjà travaillé dans plusieurs startups. Dans toute son analyse, je vais juste vous citer quelques points, car ils sont importants pour la suite :

  • Les effectifs techniques sont constitués de plus de chefs de projets et assimilés (MOA et MOE confondues) que de développeurs.
  • Les développeurs sont majoritairement des prestataires.
  • La communication est difficile entre les différents métiers (technique, marketing, commercial).

Le but de l’exercice était donc de définir les grandes lignes de ce qu’il fallait faire pour casser les « silos », afin de rétablir de la transversalité dans les projets. Tout le monde connait ce phénomène : les marketeux définissent une offre ou une fonctionnalité, les commerciaux déterminent comment ils vont la vendre, et les techniciens développent. Sauf que tout le monde sait que ça ne fonctionne pas. Enfin, tous les informaticiens le savent.

Pourquoi cela ne marche pas ? Simplement parce que le développement informatique n’est pas une commodité (pour faire un barbarisme à partir du terme anglais commodity). À ce sujet, je vous conseille de lire cet article (en anglais). Continuer la lecture de « L’image que les marketeux ont de l’informatique »

Les tâches « gazeuses »

Est-ce que vous connaissez la particularité fondamentale de l’état gazeux ? Wikipédia le dit très bien :

Dans l’état gazeux, la matière n’a pas de forme propre ni de volume propre : un gaz tend à occuper tout le volume disponible.
 

Ce que j’appelle les « tâches gazeuses », ce sont les projets − ou les éléments d’un projet − qui ont la capacité de durer aussi longtemps que vous le permettez. Quel que soit le temps que vous pouvez y passer, ça ne sera jamais terminé ; il y a toujours un dernier truc à fignoler, quelque chose sur lequel il faut réfléchir, un point important qui nécessite d’y consacrer encore un peu de temps.

J’ai tendance à séparer ces tâches en 3 types : celles qui sont intrinsèquement gazeuses, celles qui ont été mal préparées, et celles qui sont mal gérées.

Les tâches intrinsèquement gazeuses

Il existe tout un tas de tâches dont la nature même implique qu’elles ne se terminent jamais. Il s’agit principalement de celles qui nécessitent du jus de cerveau, de la réflexion, de la cogitation. On peut passer un temps infini à réfléchir à une spécification, à penser une ergonomie, à échafauder des méthodes de travail.

Mais cela peut aussi concerner des choses qui sont plus concrètes, mais qui n’ont pas forcément une ligne d’arrivée bien visible : écrire une documentation la plus complète possible, chercher un code coverage de 110% sur ses tests unitaires, optimiser du code pour grappiller un dixième de seconde supplémentaire.

Dans ces cas-là, il existe deux solutions :

  • Se créer des objectifs atteignables et s’en satisfaire. Un design peut toujours être amélioré, mais il faut être capable de converger vers une version « suffisamment » bonne.
  • Se donner un budget-temps. Quoi qu’on en dise, une tâche possède toujours une valeur spécifique. Si on y passe plus de X heures, son coût devient trop élevé pour qu’elle vaille la peine d’être réalisée.

Les tâches mal préparées

Ça paraît super-évident. Quand une tâche ou un projet a mal été préparé, on est certain de générer de l’effet tunnel. Même avec de bonne spécifications fonctionnelles, il est assez facile de croire qu’on maîtrise techniquement son sujet, et qu’on peut se jeter dans le code de manière rock’n roll. C’est le meilleur moyen pour ne pas anticiper d’éventuels problèmes, voire simplement des choix techniques qui devraient être pensés en amont.

Fatalement, ce n’est qu’une fois qu’on est face aux questions techniques qu’on commence à y réfléchir. Ça fait perdre un temps précieux.
Mais surtout, on se retrouve ainsi à résoudre les points bloquants au fur et à mesure qu’ils apparaissent. On se dit tout le temps « Je résous ce truc, et après c’est bon !« , mais l’ennui c’est qu’on va ensuite tomber sur un autre truc à résoudre, puis un autre, etc. Aucune visibilité sur l’étendue du travail à réaliser, on nage en plein brouillard.

Dans ce cas-là, il n’y a pas tente-six solutions : Il faut se pencher sur la tâche et la décortiquer méthodiquement avant de commencer à travailler réellement dessus.

Les tâches mal gérées

Vous vous souvenez du triangle qualité-coût-délai ? L’enseignement principal qu’il nous apporte est qu’on peut fixer deux des trois paramètres d’un projet, et que le troisième en découle forcément.

Lorsqu’un projet est mal géré, cela provient rarement de la qualité du travail effectué dessus ou de la précision des spécifications fournies. Non, trop souvent le problème réside dans l’impulsion initiale du projet, dans la manière dont le client appréhende ses objectifs et qu’il les communique.

Si on veut faire un POC, on voudra créer un prototype rapidement et à faible coût. Mais trop souvent, le prototype donne satisfaction et se retrouve en production. Il faut alors gérer des contraintes qui avaient été laissées de côté. Au lieu de tout redévelopper (comme il aurait fallu le faire avant de mettre en production, c’est pour ça que ça s’appelle un prototype), on passe son temps à maintenir en vie le projet, qui devient alors gazeux : on ne sait pas combien de temps chaque évolution prendra à être ajoutée, car la base même n’est pas prévue pour recevoir ces évolutions.

Autre exemple, le projet qui a été fait dans les règles de l’art au niveau de sa réalisation, mais sur lequel on a pris quelques raccourcis pour réduire les délais de livraison. Tout va bien jusqu’au jour où le projet interne est ouvert à des partenaires, et qu’on s’aperçoit qu’aucune interface n’est prête. On se dépêche de les ajouter, pour se rendre alors compte que la documentation nécessaire n’a pas été écrite. Et ainsi de suite…

Il est donc important de communiquer avec son client (qu’il soit interne ou externe), pour s’assurer que sa vision des choses est suffisamment pragmatique pour éviter les déconvenues et les déceptions.

Rachat par une grosse entreprise

L’entreprise dans laquelle je travaille, que j’ai participé à créer il y a près de 5 ans, a été rachetée l’été dernier par un grand groupe français. Je me suis souvent demandé comment je pouvais en parler sur ce blog de manière intéressante. Je me lance.

Le passé

C’est en fait la troisième fois que je vis un rachat de l’intérieur.

La première fois, j’étais dans une petite boîte qui s’est fait rachetée par une société de taille équivalente, mais filiale d’un plus grand groupe. Les choses ne se sont pas très bien passées ; nous avions été absorbés, nous avons emménagés dans leurs locaux, dans l’idée de tout migrer de notre plate-forme technique vers la leur (ce qui se justifiait pour certains projets, mais pas pour tous). Je pense qu’en fait, c’est notre porte-feuille clients qui les intéressait, et éventuellement le positionnement de certains de nos sites mobiles. Par contre, les hommes et la technologie ne semblaient pas peser lourd dans la balance, à part deux des trois créateurs de la boîte.

La deuxième fois, j’étais dans une entreprise de taille plus importante, qui s’est fait racheter par le plus grand cabinet de conseil au monde. Nous étions leader sur le marché de la musique numérique sur mobile. Le repreneur n’avait pas pour habitude de racheter des entreprises « média », mais nous avions d’importants projets avec les plus grandes majors, ce qui lui permettait de prendre pied dans cet univers. Nous gardions notre indépendance théorique, mais au moment où je suis parti (pour créer mon entreprise actuelle), les employés commençaient tout juste à ressentir l’invasion des décideurs/chefs de projets externes. La technologie était gardée, c’était un actif fondamental. Par contre, je n’ai pas eu l’impression que les ressources humaines valorisaient le personnel en place.

Le présent

Donc, ma boîte a été rachetée. Il y a des choses que je ne peux évidemment pas raconter ici. Soit parce que je n’en ai pas le droit (on a été racheté par une société cotée en bourse), soit parce que je n’en ai pas envie.

Commençons par détendre l’atmosphère : Non, je n’ai malheureusement pas fait fortune. J’ai participé à la création de ma boîte, mais elle ne m’appartenait pas. Mes quelques stock-options m’ont permis d’obtenir une prime qui ne change pas ma vie (je ne peux pas arrêter de travailler, je ne peux pas rembourser mon prêt immobilier). Ça fait juste de l’argent sur un compte, qui m’aidera un jour à payer une partie des études de ma fille ; c’est déjà ça.

Je n’ai pas participé aux discussions qui ont amené au rachat, ni au négociations concernant la valorisation de notre entreprise. Je ne peux malheureusement pas en parler (sinon je raconterais de conneries). Tout ce que je peux dire, c’est que les premières rencontres avaient pour but de réfléchir à des partenariats commerciaux ; de fil en aiguille, on s’est rendu compte qu’un partenariat « avancé » aurait du sens.

Contrairement aux précédents rachats que j’ai connu, les choses se sont passées (et se passent encore) de manière intelligente et sensée. Nous n’avons pas été absorbés, nous sommes une filiale indépendante, avec toujours nos propres projets, nos propres objectifs, notre propre équipe, notre propre budget.
Évidemment, nous avons des nouveaux projets, menés en collaboration avec notre « maison mère » (ça fait bizarre à dire quand a toujours baigné dans la culture start-up). Il faut bien comprendre et prendre en compte que nous avons été racheté pour de bonnes raisons, et que cela peut impliquer de mettre en place des passerelles techniques entre les plate-formes. Dans notre cas, nous fournissons des contenus à travers des webservices, et nous utilisons des applications fournies de l’autre côté, là encore à travers des webservices.

Les observations

Quand une grosse boîte en rachète une petite, il y a forcément une période d’adaptation. Je pense que nous n’avons pas encore fini d’apprendre et de comprendre comment ils fonctionnent.

Continuer la lecture de « Rachat par une grosse entreprise »

Trello : Todo-list, checklist, organisation d’idées, outil de collaboration

J’ai découvert hier le logiciel Trello, qui a été rendu public il y a seulement 3 jours par Joel Spolsky, le créateur de Fog Creek Software et de Stack Overflow (et dont je vous conseille chaudement la lecture de son blog, Joel On Software).

Les fonctionnalités

Trello est un outil déconcertant tant il est simple à comprendre et facile à utiliser. C’est comme avoir un tableau de post-it, mais à la puissance vingt mille. Une petite image vous aidera à comprendre :

Le principe est limpide :

  • Vous vous créez des “boards”, c’est-à-dire un panneau d’affichage.
  • À l’intérieur, vous créez des listes (les colonnes verticales que vous pouvez voir sur l’image ci-dessus).
  • Dans une liste, vous créez des cartes (les rectangles blancs dans les listes).
  • Vous invitez d’autres utilisateurs, avec qui vous voulez collaborer en utilisant le board comme support.

À la base, les cartes sont constituées d’un simple titre :

Il est possible de déplacer latéralement les listes les unes par rapport aux autres. On peut aussi déplacer les cartes pour changer leur ordre dans une liste, ou pour les déplacer d’une liste à une autre :

Déjà, rien qu’avec ça, on aurait un bon petit outil simple de gestion de tâches et d’organisation des idées. Mais là où ça devient intéressant, c’est qu’en cliquant sur une carte, on a accès à beaucoup d’autres informations. La métaphore utilisée est que l’on “retourne” la carte pour y ajouter toutes sortes de choses :

Continuer la lecture de « Trello : Todo-list, checklist, organisation d’idées, outil de collaboration »

Qu’est-ce qui cloche avec le travail à distance ?

Depuis plusieurs années, le travail à distance semble être une sorte de remède miracle à la plupart des maux rencontrés dans les entreprises high-tech. Si, comme moi, vous lisez des blogs de développeurs, freelancers, graphistes, créateurs d’entreprises et autres donneurs de bons conseils (en majorité anglo-saxons, mais pas seulement), vous pourriez avoir l’impression que la Terre entière a compris les avantages de faire travailler les gens de chez eux.

Pourtant, on assiste récemment à un lent glissement vers une perception un peu différente des choses, comme relaté récemment par Eli White sur son blog (Where has all the remote work gone?). J’aurais tendance à dire que les gens reviennent à la raison après une période d’euphorie irrationnelle.

Essayons d’analyser tout cela posément.

Les avantages du travail à distance

Il est indéniable que le fait de faire travailler ses salariés de chez eux comporte un certain nombre d’aspects positifs. Habituellement, les défenseurs de cette pratique en mettent trois en avant :

  • Productivité. En étant physiquement éloignés les uns des autres, les collaborateurs sont moins enclins à se déranger les uns les autres. Une fois la principale source de distraction éliminée, il est plus facile de se concentrer sur les tâches qui réclament de l’attention, et on abat plus de travail.
  • Organisation. À partir du moment où plusieurs personnes doivent travailler sans être physiquement au même endroit, il faut pallier à toutes les interactions non formelles qui servent habituellement à faire avancer le travail. En supprimant les fameuses «discussions à la machine à café», on est forcé de documenter correctement toutes les prises de décisions et on est obligé de mettre en place des outils de communication efficaces.
  • Flexibilité. Quand une entreprise s’organise de manière à permettre le travail à distance, ses employés peuvent adapter leurs horaires en fonction de leurs besoins et de ceux de l’entreprise. Peu importe quand le travail est fait tant que le résultat est là, non ? Les collaborateurs sont plus heureux, donc ils sont plus efficaces.

On peut toujours ajouter d’autres avantages, qui sont peut-être moins évidents au premier abord mais qui peuvent être importants dans certains contextes : Réduction (ou élimination) des locaux, simplification des questions de cantine/chèque-restaurant, économies sur les besoins matériels.

Les origines du travail à distance

Je n’ai aucunement la prétention d’avoir fait des recherches poussées au sujet des origines du travail à distance. Je ne livre ici que la perception − très très subjective − que j’en ai. Continuer la lecture de « Qu’est-ce qui cloche avec le travail à distance ? »

Skriv : Droits utilisateurs

(ce billet fait partie d’un ensemble consacré au projet Skriv)

Ça fait un bout de temps que je n’ai pas parlé de Skriv, mais je continue à travailler dessus (c’est une des raisons de ma faible productivité sur ce blog).

J’avais écrit un article concernant l’organisation de l’information. C’était intéressant, mais j’étais parti dans une direction bien trop complexe pour être envisageable ; je m’empêtrais dans un système de tags tentaculaire. J’ai continué à réfléchir à tout ça, cette fois-ci en partant du besoin fonctionnel pour aller jusqu’aux droits d’accès des utilisateurs. L’air de rien il s’agit d’un point très important, qui influe directement sur la philosophie de l’outil.

Organisation de l’information

Pour commencer, parlons du découpage des données :

  • Il existe des projets, auxquels les utilisateurs ont accès.
  • Les utilisateurs possèdent des groupes de projets, dans lesquels ils peuvent placer leurs projets. Ainsi, j’imagine que je mettrai le projet «IT» dans le groupe «Professionnel», alors qu’un de mes collègues le mettra peut-être dans son groupe «Informatique».
  • Les projets contiennent des sous-projets. Chaque sous-projet peut contenir un ensemble de listes, de fichiers, de documents écrits, etc. C’est LE moyen de regrouper des informations connexes (par exemple une spécification fonctionnelle, des maquettes graphiques, une spécification technique, une liste de tâche et une liste de bugs) au sein d’un même ensemble logique.

L’idée est de permettre à chacun d’organiser les données de la manière qui lui convient le mieux. Habituellement, les logiciels de gestion de projet sont assez binaires : Ils servent à gérer les projets de l’entreprise, et donc les projets qu’on y crée sont visibles par les membres de l’entreprise ; les systèmes de gestion des droits empêchent d’ailleurs souvent de créer des projets quand on n’est pas soi-même un administrateur ou un chef de projet. Pour ma part, j’ai une vision très différente des choses. Continuer la lecture de « Skriv : Droits utilisateurs »

Application concrète des méthodes agiles

J’ai déjà parlé de plusieurs méthodes de travail sur ce blog, depuis le cycle en cascade jusqu’aux méthodes agiles en passant parle cycle en V et les cycles itératifs. Pour illustrer tout ça, je vais vous parler de la manière dont nous gérons les projets dans mon entreprise.

Le contexte

Pour situer un peu les choses, il est nécessaire que je vous parle un peu de l’entreprise elle-même.

Fine Media est éditeur de sites Web ; ce n’est pas une «web agency», nous sommes notre propre client. L’entreprise a officiellement commencé son activité en septembre 2007, elle existe donc depuis plus de 3 ans et demi. Nous sommes actuellement une trentaine de personnes.

Les deux premières années se sont déroulées dans un climat classique de start-up à la française, dans un joyeux mélange d’élaboration de process, de développements itératifs rapides, de recrutements stratégiques et de bonne humeur. Le cap des deux ans d’existence et de la vingtaine de personne s’est passé naturellement, l’entreprise quittant d’ailleurs à ce moment ses premier locaux (sous les toits et un peu serrés) pour un immeuble plus confortable.

L’équipe technique a évolué lentement mais sûrement. J’ai immédiatement embauché un administrateur système et une infographiste. Au départ, je réalisais l’intégralité des développements. Avec l’arrivée successive de nos développeurs, j’ai pu me recentrer sur les projets cruciaux. Nous avons désormais une équipe constituée d’un administrateur, de trois développeurs, de deux infographistes/intégrateurs et de moi-même (directeur technique). Cela reste une équipe réduite, mais qui représente quand même un quart des effectifs. Le reste de l’entreprise est constitué de référenceurs, de rédacteurs, de community managers, et de commerciaux. Les référenceurs ne sont pas considérés comme faisant partie de l’équipe technique, car ils ont un rôle très transverse, à la fois actif au niveau de la technique et de la rédaction.

Comme je le dis plus haut, nous avons longtemps abordé les développements de la même manière que dans la plupart des start-ups. En privilégiant la réactivité, nous avons réussi à mettre en place des choses relativement complexes dans un laps de temps assez court. Quand il le fallait, j’avais l’autorité nécessaire pour faire des choix structurels, soit pour réclamer plus de stabilité dans les développements, soit pour lancer les refactoring qui s’imposaient.

Ceux qui suivent le blog savent que la fin de l’année dernière a été une période un peu mouvementée, avec un énorme refactoring. En 4 mois, on a remis à plat et recodé l’ensemble de tout ce qu’on avait développé en 4 ans sur notre plate-forme principale. Le problème avec ce genre de situation, c’est qu’il est très difficile d’établir un plan de marche : On a beau tronçonner les projets en tous petits bouts, il reste toujours des zones d’ombre. Les projets développés durant la «période start-up» manquaient évidemment de spécifications, et cela s’est fait sentir le jour où on a voulu lister toutes les fonctionnalités qu’il fallait remettre au propre.
Ces 4 mois de travail ont donc été réalisés sur un mode «best-effort» qui ne peut pas durer très longtemps. Cela consiste à faire de son mieux, donc à se mettre une pression relativement forte en continu, avec les horaires et le stress qui vont de paire. Au final, cela a généré beaucoup de frustrations dans l’entreprise ; chez les informaticiens qui en faisaient beaucoup sans jamais avoir l’impression que c’était suffisant ; chez les «fonctionnels» qui avaient peur que la refonte prenne un retard incommensurable.

Refonte organisationnelle

Une fois cette période passée, le risque était grand de «rester» sur le même rythme de travail… c’est-à-dire sans revenir à de vraies méthodes de travail. Il était donc important de mettre en place une organisation stable.

Continuer la lecture de « Application concrète des méthodes agiles »

Réduire les goulets d’étranglement

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.

Continuer la lecture de « Réduire les goulets d’étranglement »