Ergonomie, Rails et Architecture de l'information web (2.0)

Tout projet un tant soit peu sérieux qui se respecte tombe un jour ou un autre sur le bug stupide, ultra bloquant dans certaines circonstances improbables mais fortement susceptibles de se produire par la faute de l’interface chaise / clavier, et tout simplement impossible à corriger. Et qu’il s’agisse de Trac, Bugzilla ou toute autre solution maison, tout projet quelque peu conséquent utilise un outil de rapport de bugs permettant d’en suivre le cycle de vie de l’apparition à la fermeture, et, le cas échéant, de générer de jolis rapports de résolution de bugs à destination du client qui voit ainsi la fiabilité de son application s’accroître avec le temps.

Il y a quatre ans de cela, je travaillais en tant que prestataire sur le logiciel de gestion clientèle de notre principal fournisseur d’énergie. Il s’agissait d’une gigantesque usine à gaz en J2EE dont la moindre page mettait bien 4 ou 5 bonnes secondes à s’afficher. Le changement de valeur d’un menu déroulant permettait de rafraîchir le contenu d’une de ces pages, provoquant la fameuse latence sus citée.

Un jour, j’eus la fâcheuse idée de sélectionner le menu déroulant en question, et de donner un grand coup de roulette sur ma souris. Résultat : plantage pur et simple du serveur d’application Weblogic, et obligés de redémarrer le serveur Sun – une bête de course – sur lequel était hébergé l’application. Plein de zèle, je remplissais donc un rapport de bugs détaillé et circonstancié, niveaus de criticité et d’urgence maximums. Une seule solution pour résoudre ce bug : intercepter ou désactiver la molette de la souris depuis Internet Explorer.

Retour de la fiche une petite heure plus tard au statut “clos rejeté”, avec pour raison de la clôture les postes de travail du client sont équipés de souris à 2 boutons sans molettes, bug inapplicable en grandeur réelle.

Classe, j’te dis classe

Contrairement aux apparences, ce blog n’est pas à l’abandon. J’ai toujours autant de choses à dire, mais entre le bureau et la sortie imminente de la version 4.1 de Typo, je n’ai plus vraiment de temps pour écrire. Retour de notre rythme normal d’activités sous peu.

Quand je ne motive pas les développeurs à la batte à clous afin de terminer les projets dans les temps, une partie de mon travail consiste à préparer de jolies présentations sous Powerpoint, Keynote ou S5 afin de rassurer le client sur l’avancée de sa merveille en devenir. Une présentation efficace ne suffit pas toujours, et il n’est pas facile de la rendre vivante. À contrario, il n’est pas vraiment difficile de la rater complètement. Ce billet vous propose donc cinq choses à éviter à tout prix si vous ne voulez pas perdre toute crédibilité aux yeux de votre auditoire ou le faire mourir d’ennui,

Lire vos slides

Généralement, votre client sait lire, et il ne bloque pas son temps pour vous entendre lire une présentation qu’il pourrait très bien lire le soir dans le métro en rentrant chez lui. Idéalement, vous ne devriez jamais avoir à regarder votre présentation pour savoir de quoi vous allez parler : cela montre que vous ne maîtrisez pas parfaitement votre sujet, et vous courrez le risque d’aborder des points vus plus tard dans la présentation, ce qui fait toujours mauvais genre le moment venu.

J’en profite pour rappeler un point élémentaire, mais trop souvent oublié ou ignoré : les trois ou quatre points abordés dans un slide ne sont en aucun cas le plan de ce que vous allez présenter sur ce slide, mais les trois ou quatre idées principales que vous souhaitez faire ressortir de cette partie de votre présentation. Le point abordé se trouve dans le titre du slide.

Je crois que nous avons…

Mon professeur de go, 7ème dan, nous disait souvent “je crois que c’est le meilleur coup, ou peut-être pas en fait…”. Si ce tic de langage nous poussait à sourire, il n’avait pas tout à fait tort : une partie de go est tellement complexe qu’il est très difficile, même à son niveau, de donner le meilleur coup dans une situation donnée.

À contrario, le client qui attend de vous une prestation de conseil veut avoir des faits. Toute sanction sera donc impitoyablement sanctionnée par une perte de confiance, dont beaucoup chercheront à profiter, à commencer par ses équipes internes qui apprécient généralement assez peut les interventions externes qui pourraient marcher sur ses plates-bandes. Si vous n’êtes pas certain de vos assertions, c’est soit que vous ne possédez pas les compétences pour la mission que l’on vous a confiée, soit que vous n’avez pas poussé votre travail d’investigation jusqu’au bout. Et dans tous les cas, ça ne passera pas.

Tout le monde a compris ?

Ce qui se conçoit bien s’énonce clairement, et si vous-même vous embrouillez dans vos explications, c’est que quelque-chose ne va pas. Apprenez à connaître votre public, c’est la moindre des choses, et adaptez votre discours à son profil :

• N’exposez pas le fonctionnel à une équipe marketing, mais l’impact que le projet aura sur leurs actions.
• N’exposez pas le technique à une équipe de fonctionnel ; non seulement vous avez 90% de chances qu’ils ne comprennent rien, mais en plus ce n’est pas ce à quoi ils s’attendent.
• Pas la peine de donner des arguments marketing à une équipe de développeurs, cela ne les aidera pas à résoudre leurs problèmes de scalabilité.

Note : il faudra que je m’en souvienne lors de ma prochaine réunion marketing tiens.

… comme nous le verrons un peu plus tard

Si vous n’en parlez pas maintenant, c’est que ça n’a pas sa place ici. Vous n’êtes pas là pour créer du suspens mais exposer des faits. Si le concept est obscure, exposez le en une demi phrase, sinon passez à la suite sans préciser qu’il s’agit d’un point à aborder plus tard.

Rappelez-vous que votre temps est compté. Si vous pouvez vous permettre de revenir sur des points déjà abordés, c’est que vous avez certainement oublié quelque chose d’important quelque part. L’erreur est fréquente chez les débutants, ce qui dénote une présentation mal préparée. Dites vous que si votre discours contient une redondance c’est certainement que les éléments en ont été mal agencés.

Dans la même veine, évitez de passer la moitié de votre présentation à dire de quoi vous allez parler, ce n’est pas cela que vos auditeurs attendent de vous. Je me souviens d’une présentation aux Mobile Monday où l’orateur a passé 6 minutes à nous dire que sa présentation allait parler du futur de la téléphonie, et deux minutes à nous présenter ECS de Las Végas, sans jamais entrer dans le vif du sujet. Dommage, celui ci avait perdu une belle occasion de se taire : quand on n’a rien à dire, autant ne rester à sa place et écouter les autres.

Que nous reste-t-il à voir ?

C’est une bonne question, et je ne vous remercie pas de me l’avoir posée car je n’en sais malheureusement rien du tout. C’est vous qui animez la séance, vous savez ce que vous allez exposer, pas moi, même si j’ai lu le sommaire de votre présentation. Vous tentez de me vendre quelque-chose : un projet, un résultat, une idée, ne me demandez pas de vous mâcher le travail; même si je suis réceptif, il y a des limites à tout.

Préparez votre réunion, maîtrisez votre sujet, si vous le pouvez, répétez devant quelqu’un au fait du projet, mais surtout, surtout, ne montrez jamais à votre client que vous êtes plus perdu que lui.

Et vous, à quoi ressemble votre bureau ?

Ce qui se conçoit bien s’énonce clairement, et les mots pour le dire viennent aisément.

J’aime beaucoup cet extrait de L’Art Poétique, qui résume à lui seul tous les grands principes de la période Classique, et dont j’essaie de me souvenir – pas toujours avec succès – quand je dois intervenir en public.

Je tente de résumer chacun des projets et des concepts que je vais présenter en une phrase claire et concise. Si je n’y parviens pas, j’estime ne pas connaître suffisamment mon sujet, et je me remets au travail afin de m’éclaircir les idées. Mes lacunes comblées, mon discours gagne alors en précision.

Si certains projets sont faciles à formuler de cette manière “un site web permettant à la banque Palatine de présenter l’ensemble de ses offres à ses futurs clients”, d’autres le sont un peu moins, principalement lorsqu’il s’agit de définir un concept en tenant compte du niveau technique de l’interlocuteur. Les Microformats deviendraient donc “une extension du XHTML par lui-même faite pour ajouter des données sémantiques à un contenu web” pour un développeur, et “une manière d’écrire des pages web afin d’optimiser le data mining” pour un directeur marketing. Mais on touche là un autre problème.

L’étape suivante serait – pour moi – de ne plus me faire bouffer par le trac.

Et vous, quel est votre truc pour augmenter l’impact de vos présentations orales sur votre auditoire ?

Je démarre aujourd’hui une série d’articles sur l’accompagnement de projets dans l’univers des technologies de l’information. Je prévois d’en écrire… un certain nombre, probablement jusqu’à ce que je ne trouve plus rien d’intéressant à dire sur le sujet, ce qui devrait prendre un moment. Le but de ces billets pour lesquels j’ajoute une catégorie dédiée est de permettre aux chefs de projets – ou à ceux qui souhaitent le devenir – d’affronter des situations trop fréquentes pour ne pas être abordées comme des cas d’école. Les domaines couverts devraient aller de l’appréhension de l’équipe client à la gestion des canards boiteux en passant par la cohabitation de plusieurs équipes venues de sociétés différentes sur un même projet.

La première impression étant souvent la bonne, dit-on, mieux vaut réussir son entrée, sous peine d’hypothéquer dès le départ une relation qui s’avérait pourtant prometteuse. Il en va de même avec la conduite de projet : du déroulement de la première réunion avec le client risque fort de dépendre la suite des opérations. Les mauvais départs proviennent souvent d’une méfiance mutuelle à la rencontre de deux mondes généralement à des années lumière l’un de l’autre : “le leur”, univers métier régi par des contraintes aux antipodes de nos habitudes et de préoccupations quotidiennes, et “le notre”, marqué par ce travers récurrent chez les informaticiens qui veut que celui qui contrôle les technologies de l’information contrôle le monde et se doit de garder ce contrôle en laissant les autres dans un état d’infériorité. Sophie Januel appelle syndrome du Médecin malgré lui cette pratique qui se traduit le plus souvent par l’utilisation ad nauseam et pas toujours à bon escient de vocabulaire technique volontairement abscons et bourré d’anglicismes barbares de laquelle les gens du sérail semblent tirer une certaine légitimité. Bien que l’information fasse partie des ressources fondamentales du vingt-et-unième siècle, maintenir volontairement le client dans l’obscurantisme le plus complet serait une erreur fondamentale face à un marché très compétitif sur lequel le relationnel joue une part de plus en plus importante, nous menant à notre premier challenge : oublier l’axiome peur et ignorance, ignorance et peur, afin de rassurer le client.

Allez toujours au pas du plus faible

Il existe autant de clients que de projets, et si certains traînent une longue expérience de la mise en place de solutions liées aux NTIC au point de savoir parfaitement où aller et comment y aller, d’autres comprennent simplement l’existence d’un besoin, parfois flou, mais ignorent tout du cheminement, du temps et des coûts nécessaires à sa définition, puis sa satisfaction. Les projets les plus complexes voient même une multiplication exponentielle des intervenants, couvrant tout l’éventail du possible, d’un extrême à l’autre, et devant avancer au même rythme en faisant fi des différences technologiques et des querelles politiques. Et c’est là que les choses se gâtent.

Dès la première réunion, appréhendez le degré de compréhension du projet de chacun de vos interlocuteurs afin de vous mettre tout de suite au pas du plus faible. Cela pourrait bien pour éviter de vous réveiller un matin avec une sacré gueule de bois. Cet exercice particulièrement difficile m’avait été expliqué par une professeur de danse à la fin des années 90, et j’avais tenté pas toujours avec succès de l’intégrer à mes formations. Il s’agissait de faire avancer le cours – ou le projet dans notre cas – à un rythme raisonnable en ramenant les plus faibles à un niveau de compréhension globale du projet suffisante tout en ne ralentissant pas trop les plus rapides à comprendre.

Cette démarche aura trois impacts importants :

1. Vous assurez la cohésion de l’équipe client en intégrant vraiment les plus faibles au projet (et ils vous ouvrent parfois des portes bien utiles).
2. Vous ne donnez pas aux plus expérimentés l’impression de perdre leur temps.
3. Même si vous avancez un peu moins vite que vous ne pourriez idéalement le faire, vous ne prenez pas de retard sur le planning.

Concrètement, cela passe par une phase de définition de termes qui peuvent vous sembler naturels : le directeur de publication d’un éditeur de bandes dessinées n’est pas sensé savoir ce qu’est un serveur, ni même une base de données. Vous devrez aussi décrire des processus dont les étapes intermédiaires vous semblent aller d’elles-mêmes : la directrice marketing d’un fabriquant de shampooings ne sait pas forcément comment des pages dynamiques sont générées à partir des données stockées dans une base de données avant d’être mises en cache pour pouvoir resservir sans pour autant devoir être regnénérées à chaque visite…

En un mot, le niveau technique du client est une contrainte projet comme une autre, pouvant avoir un important impact budgétaire, et qu’on a trop souvent tendance à oublier.

Laissez venir à moi les petits clients

Celui qui débarque chez un client comme un empereur romain en pays conquis, en y imposant sa langue, ses us et ses coutumes n’a visiblement rien compris à la notion de relation au client. Vous êtes là pour offrir un service, en l’occurrence accompagner une société ou une association afin de lui permettre de mener un projet à bien, et non pour vider ses caisses. Un client qui ne se sent pas considéré finit par partir. L’idée me parait simple, mais on me souffle dans l’oreillette que de nombreux éditeurs de logiciels ne semblent pas l’avoir comprise.

Au travers des réunions de définition et de conception, intéressez vous à votre client, faites lui parler de sa manière de travailler, de ses attentes, des processus internes. Tout ceci risque d’avoir un impact réel sur le projet à venir, que ce au niveau fonctionnel ou ergonomique : vous aurez beau livrer un parfait cas d’école, s’il ne correspond pas à la réalité, personne ne l’utilisera. Vous devriez en plus rapidement comprendre les problématiques résolues par la mise en place de votre oeuvre, et surtout ses implications politiques pas toujours évidentes à première vue. En appliquant cette démarche, comprendre l’environnement du client, vous y gagnez en terme de connaissances métier tout en le faisant passer d’une position attentiste ou réceptive à une attitude participative.

Retenez bien que vous avez plus à apprendre du client que lui de vous. Il pourra utiliser votre produit au quotidien sans en connaître les rouages internes, tandis que vous n’arriverez nulle part sans lui.

Recueillir, formaliser, reformuler

Une grande partie de votre travail consistera souvent à recueillir, formaliser, puis réaliser un besoin émis de manière plus ou moins claire par un client qui ne sait pas toujours de quoi il a vraiment besoin, tout en évitant les écueils de l’application surestimée (autrement appelée usine à gaz), ou sous-estimée (donc inadaptée au besoin réel).

Votre tâche ne s’arrête pas là, et outre la documentation très formelle que vous devrez fournir (documents de conception le cas échéant, suivis de projets…), vous devrez de nouveau formuler ce que vous avez formalisé dans un langage adapté à votre interlocuteur. Il ne s’agit pas de lui redire ce qu’il vous à dit mais de lui faire comprendre où vous en êtes arrivé. Une fois de plus, cette démarche n’a rien de gratuit, elle vise à deux choses :

1. Maintenir le client à flot dans le projet et le rendre plus efficace à accomplir ses tâches.
2. Faire comprendre au client pourquoi telle ou telle partie qui lui semble simplissime prend en fait trois mois à réaliser.

Pour cela, vous disposez du début de chaque réunion durant lequel vous validerez avec le client ce qui a été décidé ou réalisé la semaine précédente. Vous pourrez aussi revenir sur les points de la réunion précédente qui pourraient rester obscurs.

“Non” n’est pas une réponse suffisante

Il existe grosso modo trois manières différentes de dire “non” à un client quand sa demande risque de trop lourdement grever le projet, deux mauvaises et une bonne.

La première consiste à dire “non”, et s’il demande des précisions à lui rétorquer que “c’est très compliqué”. Face à un client faible et peu sûr de lui, ça peut marcher. Jusqu’à ce que quelqu’un de confiance lui démontre le contraire, bien entendu, et là, les choses risquent fort de se gâter franchement.

La seconde consiste à expliquer que vous aimeriez bien, mais que cela coûterait beaucoup trop cher ou prendrait beaucoup trop de temps pour être réalisable dans des délais raisonnables. Veillez à donner un délai ou un coût à la fois suffisamment et raisonnablement élevé. Dans un cas, vous risquez de devoir développer quelque chose de vraiment infaisable dans des délais ridicules pour peu que le client tienne vraiment à son idée. Dans l’autre, vous risquez tout simplement de passer pour un incompétent et un voleur.

La troisième consiste à vous armer de patience afin d’expliquer au client avec ses mots à lui la raison pour laquelle ce n’est pas faisable. Le mieux pour lui faire oublier sa lubie est encore de lui donner les armes pour comprendre en quoi elle est déraisonnable. Et si il y tient vraiment, et qu’il peut y mettre les moyens, pourquoi ne lui feriez vous pas ce plaisir, après tout, il en a tellement envie !

Planifiez

Fournissez des plannings le plus à l’avance possible pour chacune des grandes phases du projet, quitte à les réviser à mesure que vous avancez dans le temps. Et surtout, détaillez tout point par point. Ce qui peut vous sembler évident ne l’est pas forcément pour tout le monde.

Planifiez notamment les réunions en y détaillant l’ordre du jour prévisionnel. J’utilise toujours le même modèle :

• Intitulé de la réunion.
• Date prévisionnelle.
• Récapitulatif des points abordés / livrables / taches actées lors de la réunion précédents (en dresser la liste).
• Premier point à aborder
  • Sous point 1…
  • Sous point 2…
• …
• Liste des livrables et des tâches à accomplir d’ici à la réunion suivante.

Cela peut sembler fastidieux, et pourtant…

• Vous êtes sensés avoir jeté la même chose sur un coin de cahier, de TODO ou de fichier Excel.
• Le client est rassuré car il sait où il va, et vous aussi.

Gardez toujours une trace écrite

Après chaque réunion, envoyez un compte rendu d’une à deux pages à votre client. Pas tant pour l’amour de la paperasse ou pour la postérité que pour lui donner une occasion de revenir sur ce qui s’est dit, et éventuellement comprendre, sans qu’il ait besoin de s’abaisser à vous le demander. Sauf cas exceptionnel de réunion débat un peu houleuse ou de demandes précises de fonctionnalités de la part d’un nombre important d’intervenants, il n’est pas toujours nécessaire de conserver pieusement ce que chacun a dit, et mon modèle de compte rendu ressemble à s’y méprendre à mon modèle de planning.

• Intitulé de la réunion.
• Date de la réunion.
• Intervenants projet.
• Intervenants clients.
• Récapitulatif des points abordés / livrables / taches actées lors de la réunion précédents (en dresser la liste).
• Premier point abordé
  • Sous point 1…
  • Sous point 2…
• …
• Liste des livrables et des tâches à accomplir d’ici à la réunion suivante.

SBAM !

SBAM est un acronyme bien connu des hôtesses de caisses et des démarcheurs à domicile, souvent un peu moins des préposés aux guichets des services publics – exception faite du préposé à l’accueil des ASSEDIC de Villejuif, super sympa. SBAM signifie tout simplement Sourire Bonjour Au revoir Merci.

• Sourire tout au long de la réunion, sauf quand devenir sérieux, voir contrit est de mise.
• Bonjour à chacun des intervenants, personnellement. Serrez la main de tout le monde, jamais de bise trop familière.
• Au revoir à chacun aussi.
• Merci à chacun de vos interlocuteurs, pour leur attention et le temps qu’ils vous consacrent.

Une attitude polie est accueillante – sans tomber dans la basse flagornerie – est non seulement une manière de rassurer le client qu’une simple question de savoir vivre, donc la moindre des choses.

J’ai eu l’occasion ces dernières années d’assister à pas mal de réunions, quand je ne les organisais pas. Certaines se sont bien passées, d’autres ont tourné à la catastrophe. Si on ne peut pas être certain de réussir un tel événement, certains comportements peuvent aussi les faire rater à coup sûr. Je vous laisse donc 10 trucs à faire et ne pas faire pour assurer que votre réunion ne sera pas un fiasco.

En manque de lecture pour mes trois jours de vacances – plus le week-end de Paques – j’ai fini par céder à la tentation et à m’offrir Getting Real, The smarter, faster, easier way to biuld a successful web application de 37 Signals.

Définir les besoins des utilisateurs tient souvent plus du parcours du combattant dans la jungle de Cayenne et du dressage de crocodile affamé que de la réunion corporatiste entre gens de bonne compagnie.

On tombe souvent sur l’un des cas extrêmes que j’abordais dans mon billet sur la typologie des émetteurs d’appels d’offres, le client qui se retrouve face à un problème non métier dont il cerne les effets les plus visibles, sans pour autant en saisir les tenants et les aboutissants. Si le client ne cherche pas à étaler sa méconnaissance des nouvelles technologies sous la forme d’une bouillie de mots lus dans le dernier 01 Informatique, il se peut que cela se passe bien et qu’il exprime les besoins sous une forme simple :

Dans mes réponses à appels d’offres, je tombe généralement sur deux types d’organismes émetteurs.

Les premiers se trouvent devant un problème aux enjeux et à la problématique circonscrits soit en interne soit à l’aide d’un consultant externe. L’appel d’offres exprime clairement les besoins du client, délimite le périmètre d’action de l’intervenant et la tranche budgétaire minimum et maximum allouées à la résolution du problème rencontré. Ces organismes externalisent sa résolution par absence de compétences métier en interne ou par le caractère éphémère du problème. Il arrive aussi que l’appelant possède les compétences en interne, mais que la mise en place d’une solution en interne coûte plus cher que l’externalisation sur une plate-forme existante.

J’ai récemment eu de gros problèmes de DNS sur mon serveur personnel sans que je puisse en déterminer la cause. Des adresses ajoutées à des zones que j’administre ne résolvaient qu’une fois sur deux ou trois sans que je parvienne à comprendre pourquoi. Un dig ou un nslookup sur le serveur primaire de la zone ne m’indiquait aucune erreur ; cependant les serveurs DNS des principaux FAI français ne parvenaient pas à résoudre les demandes.

On pourrait penser – à tort – que la plus grande partie du temps passé à répondre à un appel d’offre réside dans la rédaction de la partie technique. C’est évidemment faux, sauf dans le cas très précis d’appels d’offre exigeant la conception complète d’une application ou d’une architecture en guise de pré requis. Je passe habituellement 80% de mon temps à lire les Conditions de Rendu un marqueur fluo à la main.