La compassion au travail

Je suis récemment tombé sur l’émission Brain Games, et l’expérience que j’ai vue m’a semblé intéressante à partager. L’épisode tournait autour de la compassion.

L’expérience se déroulait en trois parties.

Première partie

La première partie avait pour but de définir si les êtres humains sont compatissants de nature.

Des candidats sont conviés un à un dans une pièce. Une fois assis, le candidat peut voir une autre personne assise dans la pièce d’à côté, à travers une glace sans tain. Un scientifique lui explique d’un ton neutre (c’est-à-dire froid, factuel, «scientifique» ; c’est important pour la suite) que la personne en face recevra une somme d’argent s’il peut manger un bol de soupe en entier. Le bol de soupe en question est posé devant le candidat, qui doit y ajouter une sauce ; il a devant lui trois flacons de sauce, étiquetés « doux », « moyen » et « mortel ».

Sur un échantillon assez large pour être représentatif, la grande majorité des candidats choisissent la sauce douce. Par défaut, ils font preuve de sympathie et d’empathie pour la personne qu’ils ont en face d’eux, et même si cette personne ne peut pas les voir à travers le miroir, ils n’ont pas de raison de lui faire un coup vache. Continuer la lecture de « La compassion au travail »

Le vocabulaire teinté

J’ai déjà parlé des problèmes liés aux noms de code (à la con) donnés aux projets.
Là, je partage avec vous une anecdote assez marrante, mais au final assez crispante quand elle se renouvelle tous les jours. Elle date d’il y a 3 ans, mais reste complètement d’actualité.

Je vous fait grâce du contexte. Mais, dans l’entreprise qui nous a rachetés, il y a des webservices qui permettent d’accéder à différents types de données. Il y a plusieurs webservices différents, avec pour chacun des versions différentes, tout ça étant très bien géré (on sait jusqu’à quelle date une version spécifique sera supportée, on est accompagné quand il faut migrer de version).
Ce sont des webservices comme on les faisait partout il y a quelques années, à base de SOAP, sûrement écrits en Java.

Il a été décidé que les nouveaux webservices devraient être plus souples d’utilisation − ce qui est une très bonne chose évidemment − et cela passe notamment par une communication REST-like : les paramètres sont envoyés en GET ou en POST, et les résultats sont récupérés en XML ou en JSON.
Bref, l’évolution technique n’est pas fondamentale.

Au fil du temps, les gens ont développé un vocabulaire assez étrange et amusant. Ils parlent du webservice pour parler des anciens webservices, et de l’API pour parler des versions plus récentes.
En soi, c’est marrant. De mon point de vue, les termes “webservice” et “API” sont plus ou moins interchangeables. Un webservice expose une API ; une API repose sur une solution technique (bibliothèque de fonction, webservice, CORBA, …).

Il y a 3 ans, j’avais donc reçu un email qui m’avait vraiment fait rire. Petit extrait :

Au même titre qu’aujourd’hui vous récupérez (…) via un WS, demain vous récupéreriez via une API (vu que les WS ne sont plus en vogue il me semble)

Bon, c’est un peu méchant de se moquer de personnes non techniques, lorsqu’elles doivent manipuler du jargon technique.

Ce que tout ça montre, c’est que toute entreprise développe son propre vocabulaire. C’est normal. Et la plupart du temps, certains termes ou expressions sont utilisés avec une signification particulière, parfois très éloignée de leur définition initiale. Ceci s’explique souvent par des raisons historiques : quelqu’un a utilisé un terme dans un contexte donné, et d’autres personnes l’ont réutilisé pour parler de la même chose, mais dans un contexte différent qui aurait dû en changer le sens.

C’est d’ailleurs un fait connu en linguistique.

De manière générale, il faut accepter la chose et apprendre ce vocabulaire qui est teinté par la vie de l’entreprise. Avant la création de mon entreprise actuelle, j’ai travaillé dans une société où la multiplication des acronymes et des contre-sens avait poussé à écrire un lexique pour regrouper tous les termes propres au secteur industriel concerné en général, et à cette entreprise en particulier ; très bonne initiative, confiée au département juridique…

Je dis ça mais, il n’en reste pas moins que j’ai du mal à dire « webservice » et « API » comme si c’était des termes complètements antinomiques.

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 »

Non, mais… Oui, si…

En entreprise, on se retrouve fréquemment à avoir des discussions au cours desquelles on finit par devoir répondre par « oui » ou « non ». Je vais présenter un petit truc qui permet d’améliorer les interactions dans ces moments-là ; ce n’est pas grand-chose, mais ça peut être utile.

Le problème

On hésite beaucoup, parce qu’on sait qu’on va se retrouver dans une situation délicate.

« Non » : Ais-je envie de passer pour l’empêcheur de tourner en rond ? Si je répond systématiquement par la négative, je serai vu comme quelqu’un qui se couvre, qui ne pense pas au bien collectif, qui ne prend jamais le moindre risque. Quand je dis « non », l’aspect absolu de ma réponse ferme toute discussion et empêche d’envisager des solutions alternatives, de faire preuve de créativité.

« Oui » : Dans quelle galère vais-je me retrouver si je dis oui ? Mon interlocuteur prendra ça comme un engagement formel, alors que je ne donne qu’une information de faisabilité. Répondre par l’affirmative est dangereux car perçu comme une acceptation inconditionnelle de tout ce qui pourra se passer par la suite. Dire « oui », c’est devenir responsable − dans le mauvais sens du terme − de conséquence impossibles à imaginer.

La solution

Pour aplanir les choses, faire en sorte que ça se passe mieux, il suffit de commencer ses phrases de manière légèrement différente.

« Non, mais… » : On reste dans la négation, mais on ouvre la discussion sur autre chose. Non seulement les interlocuteurs perçoivent cette volonté d’être constructif, mais en se forçant à entamer sa phrase de cette manière on s’oblige à garder l’esprit ouvert. On évite ainsi de s’enliser dans une guerre de tranchées, où chacun reste sur ses positions.

« Oui, si… » : Pour ne plus avoir peur de répondre favorablement aux questions, il suffit d’exprimer clairement les conditions nécessaires à cet acquiescement. En faisant comprendre qu’on ne peut pas attendre de vous des prises de décision aveugles, vous envoyez un message fort qui fait qu’on vous prendra au sérieux.

Les emails en entreprise… encore

J’ai entendu ce matin à la radio une information qui m’a fait bondir (et un peu rigoler). Atos va arrêter l’usage des emails, pour privilégier la communication directe entre ses collaborateurs, tout en mettant en place des outils de communication instantanée. L’argument utilisé est que les collaborateurs reçoivent 200 emails par jour en moyenne, et qu’ils perdent un temps incroyable à les lire (je ne me souviens plus, mais quelque chose comme une vingtaine d’heures par semaine).

Bon, vous connaissez déjà un peu mon avis sur la question (voir aussi cet article).

Oui, devoir lire plusieurs centaines d’emails par jour empêche de travailler efficacement. Mais le problème vient de l’utilisation qui en est faite. Comme je le disais dans un précédent article, les emails ne doivent pas servir de support de gestion de projet, ni de partage de fichiers, ni de liste de tâches. Je ne peux pas concevoir de travailler correctement en étant noyé sous 200 emails quotidiens. Impossible. C’est pour ça qu’on utilise dans mon entreprise des outils correspondant à chaque usage (et c’est pour ça que ceux qui s’amuse à spammer inutilement se font rappeler à l’ordre).

À la radio ce matin, quelqu’un expliquait à un moment qu’il se retrouvait parfois à envoyer des emails à des gens qui sont dans le même bureau que lui, parfois qui sont assis en face de lui. Hum… Il faudrait peut-être commencer par là ? Non quand on a un truc à se dire, on commence par lever notre cul de notre chaise. Ça a l’air bête, hein, mais c’est tellement plus productif !

La réponse technologique m’étonne aussi. Vouloir remplacer les emails par des «outils sociaux» me laisse songeur. La messagerie électronique et la messagerie instantanée sont complémentaires, mais pas en concurrence ; ils correspondent à des usages et des besoins différents. Les forums de discussion peuvent être très utiles en entreprise, pour mener à bien des prises de décision par des équipes projet qui sont dispersées géographiquement. Est-ce pour autant qu’il faut abandonner les emails ?
En plus, j’espère que vous serez d’accord avec moi : la plupart du temps, il est plus rapide et efficace d’avoir une bonne discussion en face à face ou par téléphone, plutôt que de perdre du temps à taper au clavier. Cette remarque est valable aussi bien pour les emails que pour le “tchat” ou les forums de discussion.
Vouloir remplacer l’email, qui est non-intrusif, par de la visio-conférence ou par la messagerie instantanée  ? Cela restera un effort aussi vain que d’avoir voulu remplacer le téléphone par ces mêmes outils. Ils sont tous voués à se développer en parallèle, s’enrichissant les uns les autres sans pour autant se remplacer les uns les autres.

Je me pose une question : Comment les commerciaux et les chefs de projets d’Atos vont faire pour discuter avec leurs clients ? Ils vont systématiquement imposer leurs outils de communication ? Sans rire ?

Alors évidemment, il y a des choses à améliorer dans le courrier électronique. Aussi bien dans son aspect technique que dans son utilisation :

  • Le simple fait de voir les messages comme une discussion, tel que le fait Gmail, évite les redites inutiles.
  • Les entreprises peuvent définir des règles d’écriture des messages internes, avec des normes concernant les titres des messages, pour s’y retrouver plus facilement.
  • Et évidemment, il faut mettre en place des passerelles entre les différents moyens de communication, pour aider les utilisateurs à monter en compétence sur les outils les plus adaptés à chaque besoin.

Ça vaut ce que ça vaut, mais j’ai travaillé dans des entreprises qui ont fait des tentatives d’utilisation de messagerie instantanée. Le résultat était simplement que 80% des messages échangés n’avaient absolument rien de professionnels, et que ces outils étaient majoritairement utilisés pour prolonger les discussions entamées durant la pause-café sans se faire attraper par la hiérarchie. Un peu comme ceux qui gardent une fenêtre ouverte sur Facebook dans un coin pour discuter tout au long de la journée…

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.

Continuer la lecture de « Améliorer les flux d’information »

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 »

Les clés de la réussite

Je n’aime pas le titre de cet article, il est assez pompeux et ressemble à une « formule miracle ». Mais je n’en ai pas trouvé de meilleur.

Je me suis déjà retrouvé plusieurs fois à tenter d’expliquer à de jeunes informaticiens (hum, même à des moins jeunes, d’ailleurs) les divers principes à appliquer au quotidien pour faire avancer leur carrière ou améliorer la manière dont ils gèrent leur travail. Et avec le temps, je me suis rendu compte que ces principes peuvent au final être résumés en 3 points clés :

  1. Simplicité
  2. Communication
  3. Passion

Évidemment, ils ne suffisent pas à donner toutes les directions à suivre. Mais si, jour après jour, chaque action est guidée par ces 3 principes, on se rend compte que l’on fait naturellement de bien meilleurs choix. Je me suis surpris moi-même récemment, au moment de prendre certaines décisions, à me demander «N’est-ce pas trop compliqué ? Qui dois-je en avertir et avec quel niveau de détail ? Ai-je vraiment envie de faire ça de cette manière, y ai-je consacré l’attention nécessaire ?». Et cela m’a permis de revoir certains choix de façon éclairée.

Voyons voir en quoi tout cela consiste.

Simplicité

La simplicité est un concept important mais trop souvent sous-estimé. Pourtant, il est valable à tous les niveaux.

Quelques exemples qui seront plus parlant :

  • La modélisation d’un composant logiciel, d’une base de données, d’une API gagne toujours à être la plus simple possible. L’histoire est jonchée de technologies diverses, de protocoles réseaux, qui ont disparu par « sélection naturelle ». À chaque fois que quelque chose est trop compliqué, d’autres technologies plus simples à mettre en œuvre apparaissent. Alors réfléchissez à vos propres développements : s’ils ne sont pas aussi simples qu’ils le pourraient, c’est vous qui allez souffrir à l’avenir.
  • L’offre de produits/services de votre entreprise doit être aussi facile à comprendre que possible pour vos futurs clients. Les offres à tiroirs et les options complexes n’inspirent pas confiance, ils ne donnent pas envie d’acheter. Assurez-vous d’avoir un discours clair et limpide.
  • Vous n’arrivez pas à faire en sorte que votre équipe utilise correctement le coûteux logiciel de gestion de projet que vous avez mis en place, malgré toutes les fonctionnalités hyper-géniales qu’il offre ? Incitez-les à utiliser correctement des outils simples, pour commencer ; donnez-leur un bloc-note à chacun pour noter leurs todo-lists, et gérez vos projets à coups de post-its collés sur un mur visible par tout le monde. Puis introduisez graduellement les outils plus structurés.
  • Vous n’arrivez pas à vous faire comprendre en réunion, vos idées sont systématiquement mises de côté ou on ne vous accorde pas tout le crédit que vous méritez ? Peut-être êtes-vous un peu trop brouillon, vous n’arrivez pas à agencer votre discours. Simplifiez-le ! Ne laissez pas les idées se précipiter toutes en même temps, prenez soin de les trier dans votre tête avant d’en exprimer les grandes lignes avec des phrases courtes.

Vous connaissez l’adage : on n’a pas atteint son but quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retirer. Adoptez une approche zen.

Communication

Une bonne communication est nécessaire en toutes circonstances. Quelques exemples :

Continuer la lecture de « Les clés de la réussite »

L’email n’est pas mort

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.

Continuer la lecture de « L’email n’est pas mort »

Les premiers enseignements de Rework

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 !».

Continuer la lecture de « Les premiers enseignements de Rework »