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

En termes de planification, la maintenance évolutive d’un projet web est toujours la plus délicate à mettre en place. D’abord parce qu’elle ne participe pas du cycle de développement normal de ce dernier, mais de son cycle d’exploitation, elle risque donc interférer avec celui-ci. Ensuite parce qu’elle fait souvent participer de nombreux intervenants de culture différente, aux intérêts parfois divergents au sein d’une même structure. Enfin parce qu’elle répond souvent à des impératifs extérieurs qui la rendent difficile, sinon impossible à planifier.

Après confier la maintenance de ses projets web et Les cycles de maintenance collective, ce troisième volet de notre série sur la mise maintenance des projets web vous invite à vous intéresser à la maintenance évolutive.

La mise en place de la nouvelle version d’une application web nécessite, au moins dans les premiers temps, la mise en place de correctifs pour les bugs d’usage. Ces derniers surviennent sur des zones de l’application testées durant la recette, mais qui peuvent connaître des dysfonctionnements lors de certaines actions d’utilisateurs pourtant considérer normales.
Second volet de notre série sur la maintenance d’un site ou d’une application web, cet article vous propose de voir pourquoi il est important de mettre en place un cycle de maintenances correctives, avant d’en voir la réalisation.

La vie d’un site ou d’une application web ne commence, pas plus qu’elle ne finit le jour de sa mise en production. Faute de conseil et de culture web, nombre d’entreprises ne comprennent toujours pas qu’un site n’est pas un cube de granite voué à rester sur la toile ad vitam eternam. Il doit évoluer dans le temps, et pas seulement au gré des correctifs venant sanctionner la découverte d’un bug passé à travers les mailles du filet d’une recette trop souvent bâclée pour cause de budget.

Cet article est le premier d’une série de trois à travers lesquels je vous invite à découvrir les problèmes induits par le passage d’un projet en mode maintenance :

1. Pourquoi prévoir un budget maintenance et à qui le confier.
2. Mise en place d’un cycle de maintenance corrective.
3. Mise en place d’un plan de maintenance évolutive à long terme.

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.