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

Il en va des projets web comme d’une maison, on n’arrive à rien en commençant par le toit. C’est la raison pour laquelle, qu’on soit face au client ou à ses équipes, un lancement bien ficelé est indispensable à la bonne marche du projet. Où suis-je? Où courre-je ? Dites-moi dans quel état j’erre sont quelques-unes des nombreuses questions auxquelles il vous faudra répondre sous peine de vous offrir un aller simple dans le mur à coté duquel les courses de moto de Tron passeront pour des accidents d’escargots contre des feuilles de salade.

Afin de ne rien oublier au moment de votre lancement, je vous propose une check list en 20 points à valider avant votre kick off. Que vous ayez préparé une Keynote pleine d’effets spéciaux ou que vous ayez opté pour une formule plus informelle, si elle vous répondez à l’ensemble de ces questions, vous pouvez partir l’esprit tranquille.

Après 9 mois de développement intensif, j’ai le plaisir de vous annoncer la sortie de la release 2.0b (pour bébé, pas bêta…) de la famille Villamil, nom de code Timothée. Le lead développeur et l’équipe se portent bien.

Il s’agit d’un exécutable de petite taille (3.170ko) fourni sur un hardware de seulement 50cm, relativement peu autonome, mais présentant cependant un grand nombre de fonctionnalités motrices : bouger, manger, dormir, crier (le son est échantillonné sur 32 bits, malheureusement un bug le force à toujours pousser le même cri). Il est doté de deux caméras multidirectionnelles enregistrant directement ce qui l’entoure sans compression ni perte de qualité. Cependant, on a pas les budgets pour développer les codecs permettant de décoder le son.

La vie d’un projet, de la commande client au déploiement auprès des utilisateurs finaux n’a rien du long fleuve tranquille. Les écueils à un projet “suppositoire” sont nombreux, et, dans des développements au forfait ce sont justement ces difficultés qui justifient le besoin d’un coordinateur qui fasse le lien entre le client et les équipes de production.

Si certains projets peuvent se compliquer pour des raisons techniques, (d’absence) ou de stratégie, il reste cependant possible de discerner à l’avance les signes avant-coureurs de catastrophe. Généralement pas souhaités, ils sont cependant responsables de l’échec cuisant de très nombreux projets, particulièrement en grands comptes.

Je suis tombé un peu par hasard ce matin sur un excellent article – un peu ancien – de Scott Manning intitulé If architects had to work like web designers. L’auteur y transpose ce que nous, chefs de projets en contact direct avec le client, subissons au quotidien à l’aune des architectes, dont le travail produit des résultats beaucoup plus “concrets”. Vous en trouverez ci-dessous la traduction augmentée de mes réflexions sur le sujet.

La traduction

Cher architecte,

Je souhaite vous confier la conception et la construction de ma nouvelle maison. Je ne sais pas encore vraiment de quoi j’ai réellement besoin, aussi vous fais-je entièrement confiance pour élaborer ce qui me conviendra le mieux. La maison devra héberger entre 2 et 45 chambres. Établissez donc les plans de telle sorte qu’on puisse facilement en ajouter ou en retrancher une. Les plans que vous me fournirez me permettront de voir de quoi j’ai vraiment besoin. Aussi, pensez à indiquer les impacts budgétaires de chacune des options de telle sorte que je puisse choisir sur ce seul critère.

Entendons-nous : la maison de mes rêves devra me coûter moins cher que mon habitation actuelle. Assurez-vous cependant d’en corriger toutes les imperfections : le plancher de la cuisine vibre quand je la traverse, et les murs sont insuffisamment insonorisés.

Tant que vous y êtes, diminuez au maximum les coûts de maintenance annuelle, quitte à utiliser dans un premier temps des matériaux plus coûteux comme l’aluminium, le vinyle ou des matériaux composites. Sachez que si vous vous décidez de ne pas utiliser d’aluminium vous devrez justifier ce choix de manière plus que convaincante.

Soyez certain d’utiliser des méthodes de conception de pointe et des matériaux d’avant-garde, je veux en effet que cette maison soit un exemple de ce qui se fait de plus innovant dans le métier. N’oubliez cependant pas que la cuisine hébergera – entre autres choses – mon réfrigérateur Gibson de 1952 sans dépareiller du reste de la maison.

La maison devra convenir à ma famille. Dans ce but, prenez contact avec chacun de mes enfants et de mes gendres. Contactez également ma belle-mère : ses visites annuelles lui donnent une opinion très juste et très précise de la manière dont cette maison doit être conçue.

Pesez attentivement tous les éléments afin de prendre la bonne décision, que je me réserve le droit de contester et modifier sans justification ni préavis.

Vous serez gentil de ne pas m’ennuyez avec les détails pour l’instant. Vous devez concevoir les plans généraux de cette maison, ce n’est donc pas encore le moment de choisir la couleur des tapis. Ceci dit, n’oubliez pas que ma femme aime le bleu.

Pas la peine de mobiliser les ressources pour la construction elle-même. Votre priorité absolue est de créer des plans détaillés. Je compte cependant voir la maison sur pieds 48 heures après les avoir validés.

Bien que vous conceviez cette maison à ma seule intention, dites vous bien que je la vendrai tôt ou tard. Elle devra donc plaire au plus grand nombre d’acheteurs potentiels possible.

Avant de terminer les plans, assurez-vous que le consensus se fasse dans le voisinage. Je vous conseille d’aller vois la maison que mes voisins ont fait construire l’an dernier, nous l’aimons beaucoup. Elle présente beaucoup d’agréments que nous souhaitons voir figurer dans notre nouvelle maison, particulièrement la piscine de 25 mètres. Je suis certain qu’une réflexion poussée permettra de l’ajouter à notre nouvelle maison sans modifications budgétaires.

Préparez un jeu de plans complet. Ce n’est pas encore la peine de faire le design définitif, nous les utiliserons uniquement pour négocier les coûts de construction avec d’autres entrepreneurs. Veuillez toutefois noter que vous nous serez redevable de tous les surcoûts liés à des changement de design postérieurs.

Vous devez être particulièrement excité de travailler sur un projet aussi intéressant ! Disposer d’une telle liberté créatrice dans l’utilisation de techniques et de matériaux d’avant-garde ne doit pas arriver tous les jours.

Revenez vers moi avec vos idées et vos plans aussi vite que possible.

PS : ma femme vient juste de me dire qu’elle est en désaccord total avec la majorité des instructions que je viens de vous transmettre. Il est de votre devoir d’architecte de résoudre ce différend. J’ai tenté de le faire par le passé, mais sans parvenir à un quelconque résultats satisfaisant. Si vous ne pouvez pas prendre cette responsabilité, je me verrai dans l’obligation de m’adresser à un autre architecte plus compétent.

PPS : peut-être n’ai-je finalement pas besoin d’une maison, mais d’un camping car. Si c’est le cas, merci de me le dire le plus rapidement possible.

Signé : le client

Le commentaire

Saisissant, n’est-ce pas ? Pour un peu on pourrait presque croire qu’il s’agit d’une situation vécue, et nombreux sont ceux d’entre vous qui se retrouveront dans ce texte.

À mon sens, le problème vient clairement d’une méconnaissance flagrante du travail nécessaire à la réalisation d’un site ou d’une application web de la commande à la livraison. Autant pour une maison, il est possible de s’imaginer la quantité de travaux nécessaires pour telle ou telle amélioration, ne serait-ce que parce que la pierre est “réelle”. À cette réalité vient s’opposer le “virtuel” du web – le travail pour y parvenir est lui, bien réel – donc une fausse idée de rapidité et de facilité, que ce soient dans la réalisation ou dans des “modifications mineures” de dernière minute.

Outre l’opposition entre le concret et le virtuel, on peut attribuer cette méconnaissance du métier à plusieurs autres facteurs :

1. La grande majorité des équipes projet côté client sont composées exclusivement de personnes issues du marketing, ou, dans le cas d’applications web, de spécialistes métier sans aucune connaissance technique, sans pour autant qu’il soit fait appel aux équipes IT – ce qui n’est souvent pas plus mal – ni à une assistance à maîtrise d’ouvrage. Ce point fera d’ailleurs l’objet d’un billet dédié.
   Quelles que soient les raisons de cet ostracisme de la technique – incompatibilités culturelles, guerres de prérogatives en interne – ce dernier est souvent la cause de nombreux problèmes dans un projet web, charge au prestataire de démêler, puis de gérer à l’avantage du projet les querelles politiques de son client.
2. Enfin, le web se remet à peine de la première bulle, et il doit maintenant conquérir, si ce ne sont ses lettres de noblesse, au moins une certaine crédibilité aux yeux des décideurs, face aux applications clients lourds et aux coûteux systèmes d’informations propriétaires qui semblent nettement plus “rassurants” et “crédibles” qu’un site ou une application web, lesquels gardant une réputation de logiciels futiles et jetables.

Dans tous les cas, la méconnaissance est telle qu’une relation de travail, peut-être un futur collaborateur, me confiait récemment qu’un client lui avait demandé combien de “pages” il lui avait vendu. En 2007.

La première fois que j’ai du organiser le planning d’un projet web, personne ne m’avait jamais dit comment faire. J’ai tenté de faire fonctionner mon bon sens. J’ai pris les différentes étapes du projet en évaluant bon an mal an combien de temps chacune d’entre elles allait prendre. À l’arrivée, je dépassais la date de livraison d’un bon mois, aussi ai-je tenté de compresser les délais comme je pouvais pour tenir dans la fourchette temporelle impartie. Je me suis évidemment planté dans les grandes largeurs. Certes, j’étais fautif, mais pas entièrement. En alignant les taches les unes à la suite des autres, il me manquait clairement une vision d’ensemble du projet qui m’a mené droit dans le mur. À ma décharge, l’entreprise avait vendu un nombre conséquents de jours / homme pour un projet complexe, en fournissant un tiers des ressources nécessaires – et vendues – pour le réaliser. À la fin de ce billet, vous devriez pouvoir établir un planning de projet sensé, la seule condition étant de pouvoir disposer des ressources nécessaires au bon moment.

Un bon planning commence toujours par la fin, et on appelle d’ailleurs cela un rétroplanning. Une fois fixée la date de mise en production du projet, il ne vous reste plus qu’à remonter le temps jusqu’au jour présent. On a étonnamment une bien meilleure vue d’ensemble du planning en remontant le temps, et les délais semblent tout de suite beaucoup plus serrés. Faites vous un rétroplanning relativement général, reprenant les grandes étapes du projet, c’est à dire :

• Mise en production finale.
• Recette du projet (c’est à dire phase de tests).
• Réalisation. À cette étape, n’hésitez pas déjà à diviser les développements en grandes étapes fonctionnelles : front office et back office, par exemple. Vous gagnerez du temps et de la visibilité.
• Conception.

Durant la planification de ces quatre étapes, énumérez dans un coin toutes les taches qu’elles englobent. Même si vous ne les planifiez pas immédiatement, elles vous permettront d’en oublier un peu moins durant la seconde étape de la mise en place de votre planning.

Une fois votre rétroplanning fini, on prends les mêmes, et on recommence, mais dans le sens inverse en partant d’aujourd’hui pour aboutir à la livraison du projet. Si vous avez préparé votre chiffrage correctement, vous devriez avoir affecté des jours aux différentes taches du projet, et la suite devrait donc être facilitée.

Divisez chacune des grandes étapes citées plus haut en unités les plus petites possibles, principalement pour la phase de développement. En effet, faire de petites unités permet de poser des jalons de validation intermédiaires. Si ces derniers sont recommandés dans un projet de courte durée, ils deviennent indispensables pour tout projet un tant soit peu sérieux. Une fois ces unités définies, il ne vous reste qu’à leur attribuer les ressources nécessaires en vous basant sur votre chiffrage.

Dans la pratique, j’utilise généralement une feuille de calcul de ce style :

Étape	Début	Fin	Ressources affectées	Intervenants
Conception	01/01/2007	05/01/2007	15 j/h	Le concepteur chez nous
Développements	08/01/2007	31/01/2007	75 j/h	Les développeurs
…	…	…	…	…

Pour vous aider, vous pouvez vous appuyer sur les quelques trucs suivants, toujours pratiques.

• Pour chacune des étapes de validation par le client, prévoyez toujours au moins une itération pour les projets les plus serrés, deux pour les autres.
• Le client mettra généralement deux à trois fois plus de temps pour les validations que vous ne le feriez vous-même. Intégrez cette donnée dans votre planning, surtout si vous devez traiter avec le service juridique.
• Quand les délais exigés par le client sont vraiment serrés, spécifiez bien que le non respect des dates de validation décalera le planning d’autant, et que ce retard est imputable au seul client. Cela vous évitera de nombreuses nuits blanches, et des pénalités financières aussi.
• N’hésitez pas à donner une heure maximum de validation et à l’inclure dans le contrat pour ne pas être décalé de 24 heures par une autorisation qui n’arrive pas.
• Refusez les projets “impossibles”
• N’oubliez pas les étapes de validation. Elles sont vraiment importantes à toute les étapes du projet.

Une fois terminé ce planning somme toutes relativement général, il est temps pour vous de réaliser le micro planning qui sera remis à vos développeurs. Pour cela, vous allez créer une nouvelle feuille de calcul dans votre tableur préféré.

• En abscisse, détaillez au maximum toutes les étapes fonctionnelles du projet : écran de login, mot de passe perdu, page d’accueil… le tout dans un ordre logique. On ne construit pas une maison en commençant par le toit.
• En ordonnée, toutes les dates affectées au projet, jour par jour.

Il ne vous reste plus qu’à colorier en rose les jours et semaines qui correspondent à ces étapes. Ce la sorte, en arrivant le matin, vos développeurs sauront immédiatement sur quoi ils devront travailler ce jour là. Quant à vous, vous aurez une vue des plus précises sur les éventuels risques de glissements de planning.

Il est 19 heures 30, vous rentrez tranquillement chez vous quand un partenaire vous appelle sur votre portable. Votre mission si vous décidez de l’accepter – avez vous vraiment le choix ? – chiffrer dans l’urgence le tout nouveau projet web ultra stratégique de Megaclient© Inc. Et là, castastrophe, tous vos commerciaux sont intouchables, il vous faut le faire de A à Z. Par où commencer, et où finir, pour être certain de ne rien oublier, mais aussi pour éviter de perdre un marché fructueux en surestimant les coûts ?

Avez-vous bien compris le projet ?

Commencez donc par vous demander si vous avez bien compris les tenants et les aboutissants du projet. Il s’agit là d’objectifs et non de fonctionnalités, celles-ci viennent après. Si l’on vous dit qu’il vous faut réaliser un site pour la banque Root, vous n’êtes pas bien avancé. Si l’on vous parle de site événementiel, vous en savez déjà un peu plus. N’hésitez donc surtout pas à poser des questions à votre interlocuteur : ce n’est pas parce qu’il est dans la mouise avec son projet qu’il doit vous y mettre aussi avec un chiffrage bancal qui vous fera perdre de l’argent. L’avantage, c’est qu’une fois que vous savez où vous allez, vous avez répondu à presque la moitié des questions qui ne manqueront pas de surgir dans la suite de ce billet. Restent cependant les deux plus importantes : quoi, et surtout comment ?

Quel est votre domaine d’intervention ?

À quel stade du projet devrez-vous intervenir ? Votre mission couvrira-t-elle l’ensemble du projet, ou bien un travail a-t-il déjà été effectué en amont ? Partez-vous de zéro où s’agit-il de reprendre une application existante ? Vous ne pouvez pas commencer votre chiffrage si votre rôle n’est pas clairement borné : conception, réalisation, assistance à maîtrise d’ouvrage ? Devez-vous prévoir des réunions avec le client ? Une fois trouvées les réponses à ces questions, vous devriez en savoir assez pour sortir votre tableur favori et commencer à affecter les différents postes qui interviendront durant le projet.

Quelles sont vos libertés technologiques ?

Les choix technologiques auront un impact important sur votre budget, aussi ne les négligez surtout pas. Un site web en PHP et une application en J2EE ne demanderont pas les mêmes ressources ni les mêmes temps de développements. De même, à périmètre fonctionnel égal, le nombre de jours / homme à affecter à votre développement variera s’il vous faut reprendre des CGI en C ou créer une application en Ruby on Rails.

Si vous n’avez pas le choix des technologies employées, et que vous les connaissez peu ou mal, une seule solution, demandez à ceux qui savent. Et c’est là qu’un carnet d’adresses bien rempli est utile : non seulement y puiserez-vous certainement les réponses aux questions que vous vous posez mais encore devriez-vous y dénicher les compétences propres à intervenir sur le projet.

Si vous disposez d’une très grande liberté de choix, n’hésitez pas à vous faire plaisir, après tout, cela n’arrive pas tous les jours. Mais avant de vendre un site web entièrement développé en fortran 77, vérifiez que vous disposez bien des ressources en interne, ou de ressources externes disponibles.

Quel est le périmètre du projet ?

Dans le meilleur des mondes, Megaclient© Inc. vous ferait parvenir un dossier de spécifications fonctionnelles générales, à moins de devoir assurer la conception de l’application. Ce dernier énumère de manière exhaustive l’ensemble des fonctionnalités que devra posséder l’application et leurs interactions. Bien évidemment, les choses ne se passent jamais comme ça, et dans le meilleur des cas recevrez-vous un document d’une quarantaine de pages pompeusement intitulé expression des besoins. Sous ce nom pompeux se cache généralement un cahier des charges pas toujours très bien ficelé, et majoritairement à des années lumières des besoins réels du client. Mais s’il a envie de se faire plaisir et qu’il alloue le budget nécessaire à son caprice, pourquoi le contrarier ? Malheureusement, là non plus ça n’arrivera pas tous les jours, et vous recevrez le plus souvent une liste de fonctionnalités vague sous la forme d’une listes à puce du genre :

• Ça doit faire ça.
• Et puis ça.
• Et ça ce serait pas mal.
• Et si ça faisait le café, ça le ferait bien.
• Sans oublier ça.

Et maintenant, c’est comme avec la Twingo : à vous d’inventer la vie qui va avec.

Et mon chiffrage, il arrive ?

Maintenant que vous vous êtes posé les bonnes questions, vous allez – enfin – pouvoir faire votre chiffrage. Ressortez votre tableur, il va vous être utile.

Commencez par séparer le projet en grandes phases :

1. Conception.
2. Réalisation.
3. Recette.
4. Mise en production.

Conception

La conception se divise généralement en trois phases :

1. Les réunions avec le client.
2. La rédaction des documents de spécifications.
3. La prise en compte des retours du client.

En ce qui concerne les réunions avec le client, j’ai tendance à prévoir une journée et demi deux journées travail par réunion, divisés tels quel :

• Préparation de la réunion + réunion : une demi journée, pour des réunions de 2 à 3 heures.
• Rédaction du compte-rendu de la réunion : variable.
• Mise à jour des documents de conception : variable selon le projet.

En fonction des projets, les postes que j’attribue à cette phase sont généralement :

• Chef de projets.
• Directeur artistique.
• Concepteur fonctionnel.
• Concepteur technique.
• Ergonome.

Il peut également arriver que des profils spécialisés interviennent à ce stade du projet : DBA, architecte…

Réalisation

Pour chiffrer la réalisation, je pars des fonctionnalités attendues que je divises en unités fonctionnelles les plus petites possibles. Pour chacune d’entre elle, j’évalue le temps passé par les postes suivants :

• Développeur web.
• Intégrateur.

Je rajoute ensuite les jours de chef de projet, plus un à deux jours de mise en place et de prise en main de l’environnement de développement et du projet par les intervenants techniques.

La recette

J’ai tendance à diviser la recette en quatre phases :

1. Rédaction des cahiers de recette.
2. Recette interne.
3. Accompagnement du client durant sa recette.
4. Corrections et retours sur recette.

Il est particulièrement difficile de quantifier ce quatrième poste. En effet, s’il est possible de chiffrer le nombre de jours assignés à la correction des hypothétiques bugs de l’application, il est pratiquement impossible de deviner quelles seront les demandes du client après avoir testé l’application.

La mise en production

Il est facile de penser qu’une mise en production revient à déposer un PHPBB sur un compte free. Les exigences des applications d’entreprise sont bien plus importantes, et je n’ai encore jamais vu de mise en production qui ne se heurte pas à l’un ou l’autre obstacle :

• Mauvaise version du langage.
• Problèmes de droits.
• Librairies manquantes.
• Problèmes de chemins d’accès…

Je compte donc généralement une journée de mise en production, et une journée destinée à tester la prod’ à fond. Cette estimation varie évidemment en fonction du projet.

Et maintenant ?

Eh bien maintenant, il ne me reste plus qu’à chiffrer. Pour cela, j’additionne le nombre de jours / homme prévu sur chaque poste : chef de projets, développeur, intégrateur, concepteur… et je multiplie par le tarif journalier de chacun de ces postes, et j’applique les grands principes du chiffrage :

1. Tout se calcule hors taxe.
2. Dans le cadre d’une prestation sur la durée, le récurrent s’impute autant de fois que nécessaire. Pas juste une seule.

Durée de l’opération : une heure, itérations et rédaction du document compris.

Les petits plus qui cassent tout

Certains postes spécifiques font généralement l’objet d’un chiffrage à part tant ils relèvent d’un coeur de métier différent du mien. Même si l’habitude me permet d’évaluer à la louche ce qu’ils vont coûter, je suis cependant régulièrement dans la nuit. Parmi ces postes, on trouve notamment :

• L’hébergement. C’est pour moi le poste le plus facile à évaluer en fonction des besoins : serveur mutualisé ou dédié, nombre de machines, architecture logicielle ou matérielle, plate-forme infogérée ou low cost, bande passante… Le fait d’avoir travaillé dans l’hébergement y est peut-être pour quelque chose.
• Importation / exportation de données. Délicat, principalement si la reprise se fait à partir d’un outil propriétaire. Le devis du spécialiste est nécessaire.
• Direction artistique.
• Film, musique créée à l’occasion. Autant vous dire que pour ce poste là, le chiffrage à la louche est des plus oiseux.

Et vous, comment vous y prenez-vous pour chiffrer vos projets ?

On n’a pas toujours le temps de prendre en charge tous les projets que l’on vous propose, particulièrement quand on travaille en indépendant. Pourtant, l’habitude de traiter seul les projets de A à Z se perd difficilement, et il n’est pas toujours évident de déléguer une partie du travail à quelqu’un. Quelques précautions élémentaires permettent pourtant de se lancer sans trop de tracas.

Assurez-vous que votre collaborateur ait le profil idéal pour la mission

Mieux vaut être seul que mal accompagné, dit-on. Aussi, assurez-vous que la personne pressentie pour vous assister conviendra parfaitement pour la mission, sous peine de perdre plus de temps que vous en gagnerez. Choisissez quelqu’un possédant à la fois le profil métier adéquat, et un solide sens de l’autonomie. Cette personne devra travailler seule sur une partie précise de la mission, et vous ne devriez avoir de contact avec elle qu’au moment des points projet et des rendus de livrables.

Définissez clairement le scope de la mission

Déterminez très clairement le contexte, les objectifs, le périmètre et les étapes de la mission afin de lever toute ambiguité sur les tâches à réaliser.

• Le contexte : dans quel cadre plus général la mission se positionne-t-elle ? Pour quelles raisons a-t-elle été lancée ? Quelles ont été et sont les grandes étapes planning ?
• Les objectifs : quels sont les objectifs précis de la mission ? Les objectifs plus généraux dans le cadre d’un projet global ? Les objectifs en termes de délais à tenir, de livrables ?
• Le périmètre : quelles sont les limites de la mission en termes de temps, de budget, de ressources ? Quelles sont ses limites fonctionnelles, techniques ? Quelles contraintes externes s’imposent-elles à vous ?
• Les étapes : quelles sont les étapes de développement et de livraison s’il y en a ? Quelles réunions ou point de contrôle sont prévus ? Un processus a-t-il été mis en place ? Si oui, lequel ? Quelles en sont les grandes dates ?

Définissez, ensemble, les responsabilités de chacun

Un partage des tâches efficace ne s’envisage pas sans partage des responsabilités, et c’est souvent là que le bât blesse. Il vous faudra apprendre à faire confiance à votre partenaire… au moins jusqu’à un certain point. Déléguer implique d’accepter de se reposer partiellement sur une tierce personne, pas simplement une redistribution de tâches.

Déchargez-vous des tâches chronophages, puisque c’est à cause d’elles que vous déléguez une partie de votre travail. Établissez la répartition ensemble, afin d’éliminer toutes les questions qui pourraient venir à l’esprit de votre collaborateur.

Établissez une check-list des points à réaliser, et partagez-vous les tâches et les livrables en fonction du temps que chacun a prévu de passer sur la mission. Établissez un document énumérant :

• Les tâches à réaliser.
• Les dates de rendu.
• La liste des livrables.
• À qui elles sont assignées.

Intégrez votre partenaire dès le début du processus

N’attendez-pas le dernier moment pour inclure votre partenaire, mais intégrez le au contraire dès le début de la mission, en fonction de ses responsabilités. Dans la mesure du possible, laissez lui les décisions en amont pour toute la partie le concernant. Non seulement il aura une bien meilleure vue du projet, mais en plus il pourra apporter son expertise dans ses domaines d’intervention.

Définissez des itérations

Établissez un processus itératif. Pour chaque étape de la mission, prévoyez des dates de livraison des livrables, des périodes de validation, de retour sur livrables, et de modifications. Comme pour tout projet utilisant une gestion de ressources, commit early, commit often, vous perdrez moins de temps en détectant les problèmes à la source. N’attendez pas, surtout si la suite du travail de votre collaborateur est subordonnée à votre validation.

Communiquez, communiquez, et communiquez encore… à double sens

Communiquez souvent, régulièrement, et à double sens. Faites des points projet réguliers, et à double sens. Exposez votre avancement à votre partenaire, et envoyez-lui l’ensemble des livrables préparés afin qu’il se tienne au courant de l’avancement du projet. Déléguer le travail peut être un véritable plaisir, si les affaires sont rondement menées.

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.

Ce billet fait suite à un certain nombre d’expériences malheureuses et conversations survenues ces deux dernières années, dont les plus récentes entre autres avec Mathieu Pillard. Rendons à César ce qui est à César, je râle suffisamment quand on ne me le fait pas.

Je ne sais pas si vous avez remarqué la quantité de gens qui se présentent à des entretiens d’embauche – ou que des sociétés de service peu scrupuleuses vous présentent comme les plus fines gâchettes de la profession – sans avoir jamais développé une ligne du langage dont ils se prétendent pourtant spécialistes. Je me souviens un jour avoir entendu un commercial tentant de vendre un stagiaire technicien réseau au CV maquillé comme une voiture volée en tant que développeur PHP expérimenté. Il clamait à qui voulait bien l’entendre : “Il a déjà fait un site perso en HTML, le PHP c’est facile, n’importe quel imbécile peut en faire, il y a suffisamment de documentation et d’exemples sur Internet, il fera l’affaire”. Deux semaines plus tard, le garçon se faisait dégager de la mission avec pertes et fracas.

C’est sans doutes à cause de ce genre d’anecdote que je crois fermement qu’un simple entretien technique ne suffit pas à déterminer le niveau réel d’un développeur. Un test pratique représente la solution à la fois la plus efficace et la plus intéressante, pour peu, évidemment, qu’il soit mené intelligemment.

Il y a deux ans, j’avais assisté à la mise en place d’une batterie de tests techniques à destination des postulants avec la philosophie de laquelle j’avais du mal à m’accorder.

Dans un premier temps, le candidat devait, en deux heures de temps, développer une petite application simple en PHP, comme un carnet d’adresses, une interface de vente de voitures, ou un annuaire simple. Il s’agissait avant tout de tester ses capacités de “machine à pisser du code”, plus que son degré de réflexion et d’abstraction. Curieusement, sur parfois une trentaine de candidats présentés par des sociétés de service, seuls deux ou trois pouvaient prétendre à passer la seconde partie du test. Seconde partie qui consistait en l’intégration d’un nouveau module dans une application effroyablement compliquée, bourrée de bugs aléatoires, codée avec les pieds par un unijambiste parkinsonien, et reposant sur un moteur de template interne non documenté. Pendant ce temps, certains membres de l’équipe passaient derrière le courageux postulant, regardaient son travail et émettaient des réflexions pas toujours très agréables à son propos. Après ma sortie, je me suis sincèrement demandé s’ils cherchaient un développeur ou un mélange entre Mac Gyver et un bonze tibétain pour les capacités de concentration en milieu particulièrement hostile.

Je trouvais cette manière de faire critiquable sur deux points :

Le premier projet était un exercice d’école basique, sans aucun lien ni dans l’esprit ni dans le domaine fonctionnel avec ce que le postulant aurait à développer par la suite. Malgré le peu de réussite, j’aurais aujourd’hui tendance à dire qu’il était trop facile, et ne correspondait pas aux contraintes techniques de la mission (php objet, javascript omniprésent, ajax partout pour des contraintes de bande passante). Le second projet était particulièrement difficile, trop même, et l’application à reprendre très loin de la moyenne des projets développés au sein de cette équipe. D’autant que l’utilisation du template maison nécessitait quelques jours de formation et d’adaptation en internet.

En un mot, le test visait à recruter des techniciens purs, capables de pondre, de lire et de reprendre du code très rapidement, mais sans aucune méthode ni réflexion, même si les développeurs rapides savent aussi souvent réfléchir à leur code. Cela va bien pour des applications simples, jetables, mais en aucun cas pour des projets complexes et destinés à évoluer dans le temps.

Plus le temps passe, et plus j’envisage le test d’embauche pour les développeurs comme un mélange intelligent de plusieurs éléments avec des coefficients différents :

• Une partie purement technique, afin d’évaluer la connaissance du langage, sur 10 points. Le candidat doit développer quelque chose de simple, mais avec des contraintes particulières, notamment en termes de sécurité, de rapidité ou d’utilisabilité, toutes ces contraintes étant clairement exprimées dans l’énoncé de l’exercice.
• Une partie méthodologie et compréhension sur 20 points. Celle-ci se traduit par une revue de code. Le code est revu avec le candidat qui explique sa démarche, et justifie ses choix.
• Une partie “freestyle”, sur 5 points, qui récompense les candidats ayant dépassé les consignes de base afin d’offrir une application plus sexy, plus agréable à utiliser, ou fonctionnellement plus riche.

L’idée derrière cela est de laisser leur chance à des éléments parfois moins bons techniquement, mais intelligents, capables de réfléchir et d’évoluer avec une bonne tournure d’esprit, pour de les mélanger à des équipes plus expérimentés et leur permettre de parfaire leur technique. Parce qu’une équipe projet n’est pas seulement un investissement pour l’immédiat.

On dit toujours les cordonniers plus mal chaussés que leurs concitoyens. Je jugez donc pas ce qui suit à l’aune de ce site, peut être aurai-je un jour le temps d’en faire quelque chose d’acceptable. Et puis de toute manière, un blog se lit via son flux XML, pas directement.