Organisation d’équipe

Réduire les goulets d’étranglement

22 mars 201029 juillet 2013 AmauryOrganisation d'équipe3 commentaires

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 :

Déléguer
Communiquer
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.

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

11 février 201029 janvier 2011 AmauryOrganisation d'équipe7 commentaires

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…

Du micro-management jusqu’à la délégation, le long parcours de la confiance

8 février 201029 janvier 2011 AmauryOrganisation d'équipeLaissez un commentaire

Quand on gère une équipe, on se retrouve régulièrement confronté à un dilemme : Quand et comment déléguer ?
Même si on n’est pas un control freak, on ne va pas confier “les clés de la maison” aveuglément ; mais d’un autre côté, il n’est pas possible de demander aux gens de donner le meilleur d’eux-mêmes si on est sans cesse en train de les surveiller. Alors que faire ?

Types de management

La plupart des livres et méthodes de management mettent en avant 2 points qui sont réellement importants (et qui sont liés l’un à l’autre) :

Il faut responsabiliser les personnes que l’on encadre. Ainsi ils gagneront en confiance, prendront des initiatives, réfléchiront par eux-même, travailleront de manière autonome, feront attention à la qualité de leur travail.
Le corollaire : Il ne faut pas faire de micro-management.

Le micro-management consiste à être continuellement sur le dos des membres de son équipe, de surveiller leurs moindres faits et gestes. C’est une mauvaise pratique pour plusieurs raisons :

Une surveillance constante induit un climat pesant et génère du stress. Personne n’aime travailler dans ces conditions, la qualité du travail ne peut pas être optimale.
Quand on est à l’affut de la plus petite erreur, et qu’on signale chaque maladresse, on place la personne dans une situation d’échec continuel qui est fortement démoralisante.
Tous les processus d’apprentissage comportent des cycles erreur-réessai qui ne peuvent pas se faire si on est paralysé par la hantise de l’échec.
Dans une moindre mesure, quand on surveille les autres, on ne fait rien de réellement productif soi-même.

Donc nous sommes d’accord, il faut éviter le micro-management.
Mais l’excès inverse est tout aussi néfaste. Je connais des gens dont la technique de management est «Laisser les gars se débrouiller» ; cela a pour résultat de “laisser les gars dans la merde” et non pas de créer des gars débrouillards.

La confiance

On en vient au point essentiel : la confiance
Il est impossible de confier des responsabilités à quelqu’un si on ne fait pas confiance à cette personne.

L’email n’est pas mort

3 janvier 201029 janvier 2011 AmauryOrganisation d'équipeLaissez un commentaire

Il y a quelques heures, j’ai écrit un commentaire en réponse à un billet du blog Entreprise 2.0. Ce billet, intitulé Peut-on envisager une entreprise sans email ? a pour thème l’abolition de l’usage de la messagerie électronique en entreprise. Son auteur estime que les nouveaux outils et les nouvelles pratiques permettent de se passer de l’email, et qu’il serait plus efficace de se concentrer sur l’emploi de plate-formes collaboratives, de messageries instantanées, de blogs d’entreprise, de micro-blogging, …

J’ai donc écrit un commentaire assez long pour donner mon avis sur la question. Je vais le reprendre ici en le développant un peu, parce que je pense qu’il s’agit d’un débat intéressant, qui est loin d’être clos.

Les outils de communication utilisés en entreprise

Avant de disserter sur l’évolution des communications intra- et inter-entreprises, passons déjà en revue les différents moyens de communication qui sont à notre disposition.

Le téléphone. Parfait pour les échanges rapides d’information entre deux personnes, il remplace la discussion en face-à-face en éliminant les barrières géographiques. Les discussions orales ont le grand avantage d’être rapides, contrairement aux échanges écrits − qu’ils soient instantanés ou non.
Le courrier postal et le fax. Encore très largement utilisés pour les échanges de documents écrits ayant une signification juridique, particulièrement lorsqu’il faut y apposer une signature. Je ne connais pas d’entreprise qui envoie ses contrats par email.
Les emails. C’est un moyen simple et très généralisé d’envoyer des messages textuels à des individus ou des groupes d’individus. La réception de messages se fait de manière non intrusive (contrairement au téléphone), même si cela peut être modifié par divers alertes visuelles et/ou sonores.
Les blogs d’entreprise. Ils permettent aux collègues d’une même structure d’échanger des idées utiles à l’avancement de leur travail ou de l’entreprise elle-même, dans un cadre où la réactivités des réponses aux idées n’est pas une nécessité forte. Ils permettent de suivre les différentes idées au fil du temps.
Lespartages de fichier (au sens NFS ou Samba/CIFS). Ils servent à stocker et partager tous types de fichiers, avec deux buts différents mais pas antinomiques : 1) la pérennité des données, 2) l’édition par plusieurs personnes.
Les wikis. Servent à stocker des données textuelles, avec les mêmes buts qu’un partage de fichiers (pérennité et accès multiple), en y ajoutant une facilité d’accès et des capacités d’édition collaborative accrues (historique des modifications, gestion des révisions).
Les forums d’entreprise et les messageries instantanées (ou les outils similaires comme Campfire). Ils sont utiles pour une collaboration orientée temps réel. Surtout utile pour les équipes qui sont “éclatées” géographiquement, comme succédané aux discussions de travail habituelles au bureau.
Le micro-blogging (popularisé par Facebook et Twitter). Sert à donner fréquemment des informations succinctes quant à l’avancement de ses projets.
Les outils de liste (todo-list, buglist). Ils servent à gérer les tâches à traiter.
Les lecteurs de flux RSS. Ils facilitent la veille technologique en permettant un accès centralisé rapide à un grand nombre de sources d’information.

On peut remarquer que j’ai aussi bien listé les moyens de communication stricto sensus (comparables au rôle de la voix dans une conversation entre deux personnes), que les moyens d’archivage des communications et des idées (comparable au rôle que les livres tiennent depuis qu’ils ont remplacé les traditions de mémoire orale).

Certains outils regroupent de manière centralisée certains de ces moyens de communication. La plupart des «logiciels de gestion de projet» intègrent au minimum un wiki et une liste de tâches, parfois en y ajoutant un forum et un partage de fichiers.

Les premiers enseignements de Rework

12 décembre 200929 janvier 2011 AmauryOrganisation d'équipe4 commentaires

J’ai déjà parlé plusieurs fois de l’entreprise 37signals, de ses logiciels de gestion de documentation et de projet, et de sa méthode Getting Real. Actuellement, ses membres travaillent au successeur de leur livre, dont le nom sera Rework. Ils ont présenté quelques bribes d’information sur le livre, et je me suis arrêté sur le quatrième de couverture :

Je trouve que le texte qui s’y trouve est très intéressant, un brin controverse, et mérite qu’on s’y attarde. Voici une traduction très libre de son contenu, et ce que j’en pense.

“Dès que possible” est un poison

Il est vrai qu’en entreprise, on rencontre bien souvent ce genre de situation : On essaye de se mettre d’accord sur la spécification d’une nouvelle fonctionnalité, et quand vient le moment d’en définir la date de livraison, on se voit répondre “Dès que possible”. Cela peut sembler la réponse la plus honnête, la plus simple à comprendre de tous et la plus facile à gérer ; mais en fait il s’agit souvent d’un pis-aller qui démontre que le projet n’est pas réellement pris en main.

Quand on demande un développement ASAP (as soon as possible), on abdique sur tous les facteurs qui définissent un projet :

La définition exacte du projet n’a pas été faite correctement. On sait bien qu’on n’a pas pris le temps de réfléchir à tous les cas limites, à penser à toutes les situations. On sait − mais on ne le dit pas ouvertement − que les développeurs devront affronter tous ces culs-de-sac fonctionnels au fur et à mesure qu’ils se casseront les dents dessus, ce qui empêche d’apporter une quelconque valeur aux estimations qu’ils peuvent faire de leurs développements.
À partir du moment où la seule contrainte exprimée est celle du temps passé sur le projet, on accepte implicitement que des raccourcis soient fait pour atteindre l’objectif au plus vite. Un aspect en pâtira forcément, qu’il s’agisse de la qualité générale de la réalisation, de la maintenabilité du code, des tests, du débuggage, …
À l’inverse, l’absence de deadline réaliste autorise les développeurs à se lancer dans des développements inutiles (je ne parle même pas de ceux qui se tournent les pouces). On arrive ainsi à des situations où on découvre au bout de 2 semaines que le développement “ASAP” aurait pu durer 4 jours si on avait pris le temps de dimensionner et budgéter le projet correctement ; mais si on en fait la remarque au(x) développeur(s), on obtient une réponse du genre «Ah, moi j’estime que tout ce que j’ai fait était nécessaire pour que le projet fonctionne correctement. Il fallait me prévenir si c’était plus urgent que ça !».

Communication et productivité : synonymes ou antonymes ?

15 novembre 200929 janvier 2011 AmauryOrganisation d'équipe2 commentaires

Je suis assez étonné et amusé de remarquer qu’il existe des « courants de pensée » assez contradictoires concernant les méthodes à employer pour maximiser sa productivité personnelle. Certaines solutions proposées sont un peu extrêmes dans leur propos et revendiquent leur manque de nuance. Qu’elles soient le résultat d’une démarche personnelle et la dernière méthode à la mode, il semblerait que leur adoption doit être obligatoirement sans demi-mesure…

La sur-communication

Je vais commencer par vous parler de ce qu’on appelle l’«Entreprise 2.0». Derrière ce terme un peu brumeux (et repompé du «Web 2.0») se cache un ensemble de pratiques qui ont pour but d’amener les plate-formes de travail en entreprise vers des pratiques plus participatives, plus “organiques” − quoi que cela veuille dire.

Si on regarde bien, cette démarche a été entamée il y a un bon nombre d’années déjà, lorsque les entreprises ont commencé à migrer leurs gestions documentaires simplistes (partage de documents en réseau) ou difficiles d’accès (GED de premières générations) par des intranets intégrant wikis, blogs et bookmarks partagés. Et il faut bien avouer qu’en procédant ainsi, l’accès à l’information est devenu plus facile et leur mise à jour est plus fréquente.
Rapprocher l’information de ceux qui en ont besoin, tout en leur permettant de la modifier facilement, permet de rendre celle-ci moins « monolithique ».

C’est un bon exemple de cas où ce sont les outils qui ont amené un changement d’utilisation en douceur, ce qui n’aurait pu être fait par un changement d’organisation et de process.

Certains partisans de l’«Entreprise 2.0» veulent pousser ce concept beaucoup plus loin. Pour faire simple, Facebook et Twitter sont des outils super géniaux (et surtout particulièrement à la mode en ce moment), il faut à tout prix généraliser et codifier leur utilisation. Ils théorisent donc sur le fait que la prochaine étape est d’avoir des collaborateurs qui communiquent de manière proactive, informent leurs collègues de ce qu’ils font et à quoi ils réfléchissent, en utilisant des canaux de micro-information propres à l’entreprise.

La sous-communication

A contrario, un bon nombre de méthodes d’organisation personnelle obligent à fermer les vannes de l’information entrantes. Qu’il s’agisse du téléphone (toujours laisser le répondeur gérer les appels), des emails (à ne lire qu’une à deux fois par jour) ou des réunions (à éviter comme la peste), l’idée est la même : Ce sont des sources de distraction qui empêchent de se concentrer sur les tâches qui réclament notre attention. Éliminer les sources de distraction permet donc, par un effet mécanique, de consacrer plus de temps à faire du travail « utile », et donc de devenir plus productif.

Et si Gordon Ramsay était informaticien ?

19 septembre 200929 janvier 2011 AmauryOrganisation d'équipe17 commentaires

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

31 août 200929 janvier 2011 AmauryOrganisation d'équipeLaissez un commentaire

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.

La refactorisation

26 août 200929 janvier 2011 AmauryOrganisation d'équipe4 commentaires

La refactorisation est un exercice qui devrait être maîtrisé par tous les développeurs, encadré par tous les chefs de projets et encouragé par tous les directeurs techniques.

Le refactoring, qu’est-ce que c’est ?

Derrière cet affreux anglicisme se cache le fait de réécrire du code qui a déjà été développé. Le but n’est donc pas d’ajouter de nouvelles fonctionnalités, mais plutôt d’assurer un suivi de l’existant, de faire un ménage qui en facilitera la maintenance.

Nous nous sommes tous retrouvés un jour ou l’autre devant des bouts de code sans queue ni tête, manifestement écrits à la va-vite, ne respectant aucune norme, avec une documentation périmée, sans commentaire, ou truffés de code mort. À chaque fois, nous sommes horrifiés. Dans le meilleur des cas, on se souvient des raisons historiques qui ont conduit à cela (« Ah oui, ça date du projet X, qu’on avait dû faire à toute vitesse il y a 2 ans ») ; dans le pire des cas, on va retrouver le responsable de cette horreur pour lui passer un savon.

Mais la bonne attitude, c’est d’organiser l’amélioration de ce code. Il faut garder en tête qu’on ne travaille pas continuellement sur les mêmes fichiers. Ce qu’on est en train de développer un jour sera utilisé pendant des mois voire des années sans qu’on revienne dessus. Mais au fil du temps, le code ancien devient « friable » : chaque correction de bug devient plus délicate et sujette aux bugs de régression ; chaque ajout de fonctionnalité prend de plus en plus de temps et devient plus difficile.

Je vais faire un parallèle avec la construction immobilière. Quand on construit une maison, on commence par faire les fondations, puis on monte les murs extérieurs, puis le toit et enfin les cloisons intérieures. Quand on développe un logiciel, c’est un peu la même chose ; chaque développement, chaque ajout de fonctionnalité, s’appuie sur des objets ou des librairies qui doivent rester fiables dans le temps. Il faut donc pouvoir revenir à tout moment sur n’importe quel bout de code, accéder à sa documentation, lui ajouter de nouvelles capacités, voire résoudre des bugs qui ne s’étaient encore jamais déclarés.
Parce que le jour où vous faites tomber des cloisons, vous ne devez pas devoir refaire les murs extérieurs ; et si vous ajoutez une étage à votre maison, vous devez pouvoir faire confiance à la chape de béton de vos fondations.

Comment s’y prendre

On peut découper un refactoring en 4 étapes précises. Les trois premières sont importantes et nécessaires, alors que la dernière est à mettre en oeuvre si le besoin s’en fait sentir uniquement.

Le triangle Qualité, Coût, Délai

10 juillet 20092 mai 2018 AmauryOrganisation d'équipe14 commentaires

Quand on doit choisir la manière d’aborder un projet, il existe 3 notions fondamentales qu’il faut connaître et évaluer : la qualité, le coût et le délai.

Triangle Qualité, Coût, Délai

Comprendre le triangle

Qualité : Il s’agit du soin qui est apporté à la réalisation fonctionnelle et technique du projet. Un projet de médiocre qualité remplira les besoins immédiats du client, en s’autorisant un certain nombre de raccourcis. Un projet de bonne qualité aura été spécifié pour couvrir certains besoins futurs identifiables, et offrira une ergonomie adaptée, des performances homogènes, une évolutivité étudiée, une documentation complète.
Coût : Un client est prêt à dépenser une certaine somme pour un projet donné. La valeur du projet peut éventuellement s’adapter à un certain nombre de critères, mais il y a forcément un seuil au-delà duquel il est impossible de le rentabiliser. La notion de coût englobe aussi bien les frais d’étude (en fonction du temps passé aux spécifications fonctionnelles et techniques) et de réalisation (suivant le nombre de développeurs nécessaires, le matériel mis à leur disposition, la présence d’une équipe de test et de validation, …), que les frais d’exploitation (matériel nécessaire pour faire tourner le projet en production, salaire de l’opérateur de maintenance, …).
Délai : Savoir combien de temps doit durer la réalisation d’un projet n’est pas aisé, même si cela fait partie du travail d’un ingénieur. Certains projets ne sont pas urgents, ni même importants, mais ils comportent forcément une deadline à partir de laquelle ils deviennent caducs.