Le problème

Ce point de méthode donne quelques solutions autant préventives (faire en sorte que cela n’arrive pas) que curatives (gérer une telle situation de crise) au prestataire qui se trouverait face à une situation comme celle-ci : un cahier de charges a été rédigé, et lie le prestataire et le client dans le cadre de la réalisation du projet. Cependant, le client change d’avis sur ce qui doit être réalisé en cours de route, soit par un rajout de fonctionnalités soi-disant “sous-entendues” dans le cahier de charges, soit directement par l’annulation des spécifications du cahier de charges, pour les remplacer par d’autres.

La plupart du temps, ceci intervient pour plusieurs raisons :

• le client n’est pas assez associé au processus de développement, i.e. il prend vraiment connaissance de ce qui a été réalisé quand c’est malheureusement trop tard. Très souvent, l’expérience montre que le client “se réveille” au moment où le projet doit être finalisé, et qu’il doit payer le solde pour finalisation.
• le client a l’impression que sa demande est juste un “petit détail rapide”, alors qu’en réalité cela remet en cause la structure même du projet
• le client est perfectionniste et retarde potentiellement à l’infini la finalisation du projet pour se donner du temps de faire corriger au prestataires tous les petits détails de style, couleur, etc…
• mais aussi, dans un nombre restreint de cas, par … mauvaise foi.

Ce qu’il ne faut surtout pas faire dans cette situation

Le prestataire de bonne foi est fortement tenté d’obtempérer à la demande du client, et de réaliser ce qu’il souhaite. Seulement, comme c’est du travail supplémentaire, cela boulverse le développement et le timing. De surcroît, le projet tend à se perdre dans les détails, ce qui le complique au delà du raisonnable. Le projet prend du retard, sa complexité augmente, et le prestataire n’arrive plus à le gérer. Il est à ce moment-là responsable.

Ce qu’il faut faire dans cette situation

Bien évidemment, il n’y a pas une solution miracle, mais plusieurs réponses possibles, qu’il faut combiner :

• solutions préventives - faire en sorte que cela n’arrive pas :
  • dès le début, lors de la rédaction du cahier de charges, communiquer clairement au client que ce cahier de charges représente le document sur lequel vous vous êtes basé autant pour le tarif et pour l’echéancier, que pour la structure interne du développement. Il ne sera pas possible de le changer en cours de route.
  • faire valider systématiquement au client les étapes intermédiaires dans la réalisation du projet, et faire en sorte qu’il donne son accord formel (signature, email explicite), à chaque étape.
• solutions curatives - c’est arrivé, qu’est-ce que je dois faire :
  • laisser la modification à la toute fin du projet. Cela vous permettra de tenir vos délais de développement, et gagner la confiance du client, car vous avez tenu votre engagement. Il investira un montant supplémentaire pour les modifications plus volontiers s’il est assuré.
  • pour les détails de fin de projet qui n’en finissent plus, proposez contractuellement avec le client un délai pendant lequel il a le droit de signaler ce genre de détails. Quand ce délai est dépassé, toute modification supplémentaire sera payante.

Voilà comment il faut définir un cahier de charges pour une charte graphique de site Internet, pour avoir le maximum de chances de succès. Il faut se poser plusieurs questions et définir son besoin de la manière suivante :

• HTML pur, HTML/Flash mixte, ou Flash pur ?
• à qui s’adresse le site ?
• quelles couleurs/nuances faut-il appliquer ?
• présentez plusieurs sites internet existants, ou templates qui ressemblent plus ou moins, ou “sont dans le genre” de ce que vous cherchez (par exemple, sur templatemonster.com, il y a des dizaines de milliers de templates, certains ressemblent à ce que vous cherchez). Présentez éventuellement plusieurs templates, dont chaqun a une partie qui ressemble à ce que vous cherchez (ex, la bannière d’en haut semblable à celle du template 1, les nuances semblables à celles du template 2, et les photos dans le même style que celles du template 3, etc.).
• si vous avez une idée plus ou moins précise de ce que vous voulez, faites un croquis de ce que vous cherchez sur papier, scannez-le et fournissez-le

Avec ces éléments fournis, client et prestataire peuvent se mettre plus facilement d’accord, et éviter les malentendus liés à la subjectivité (j’aime/j’aime pas), qui interviennent souvent dans le cadre de la réalisation de travaux artistiques.

Progonline vous livre les secrets de la gestion de projet offshore

Cet article représente le premier d’une longue liste de points de méthodologie que Progonline publiera sur ce blog.

Depuis la création de notre société, nous avons suivi de près plus de 300 projets publics réalisés, et un nombre très importants de projets privés. Parallèlement à notre place de marché déjà bien connue, nous avons également participé à la réalisation de projets de grande envergure, représentant plusieurs années-hommes, comme par exemple un progiciel de veille stratégique sur Internet, qui aujourd’hui dessert plus de 200 sociétés, et qui . Ce projet a été intégralement réalisé en offshore, avec une équipe de 5 développeurs roumains pendant plus de 6 mois.

Nous avons donc acquis de solides connaissances en matière de gestion de projet offshore, que nous souhaitons partager avec vous, clients ET prestataires. Nous souhaitons procéder ainsi, car très souvent, les projets avortés ne proviennent pas (que) de mauvaise foi ou manque de compétence, mais surtout à cause d’incompréhensions qui pourraient être évités certaines techniques étaient utilisées.

Ces articles seront mentionnés à chaque fois avec “Point de méthodologie : …”. Nous vous recommandons fortement de les lire, pour une réalisation de projets à distance toujours plus performante, rapide, et de bonne qualité.

Point de méthodologie : comment assurer un suivi de projet performant ?

La méthode itérative et en cascade

La théorie du génie logiciel propose 2 modalités principales de développement informatique : la méthode itérative et la méthode en cascade. La méthode itérative suppose des itérations (cycles de développement, ç’est à dire versions progressives fonctionnelles du projet) courtes et fréquentes. La méthode en cascade suppose au contraire des itérations majeures et rares.

Pour simplifier, on dira que la méthode itérative suppose une application fonctionnelle (de manière limitée immédiatement), donc “on voit” l’application se développer au fur et à mesure, alors que la méthode en cascade suppose un développement de l’application qui sera uniquement visible à la toute fin.

La méthode itérative est un peu plus lente, car elle suppose la réecriture du code source sans cesse, pour y greffer les nouelles fonctionnalités. Par contre, elle a l’avantage de permettre au client une observation continue de l’avancement. La méthode en cascade a l’avantage d’être mieux écrite, plus performante, car tout est pris en compte dès le début. Par contre, l’application n’est présentable qu’à la fin du développement, n’étant pas fonctionnelle avant.

Le travail à distance : appliquer toujours la méthode itérative !

Lors de la réalisation des projets à distance pour de nombreuses raisons, vous devez systématiquement utiliser la méthode itérative :

• le travail à distance suppose une communication plus pauvre entre client et prestataire. De surcroît, le prestataire n’a probablement pas les même références culturelles et linguistiques que vous (même s’il est francophone). De nombreux de ce fait se créer, dûs tout simplement au fait que le prestataire ne comprend pas la même chose que le client. Une application que le client voit avancer au fur et à mesure réduit les risques de malentendus, car si le prestataire a mal compris une requête, le client le verra tout de suite et le réorientera. A l’opposé, si le client ne peut pas voir l’application, il se rendra compte du malentendu à la fin du projet, quand ce sera trop tard (ou en tout cas quand le coût de la correction sera bien plus grand).
• le travail à distance suppose très souvent une attitude exploratoire dans les relations entre client et prestataire. Un client qui travaille la première fois avec un prestataire souhaite être rassuré au fur et à mesure du développement, et non pas attendre “dans le noir” le résultat d’une expérience risquée. Ceci sera bénéfique pour le client autant que pour le prestataire, qui sera sur la même longueur d’onde que le client. Si le projet n’avance pas pour des raisons de compétence du prestataire, le client le verra rapidement, durant les premiers jours.
• les applications informatiques sont toujours plus difficiles et longues à réaliser qu’initialement prévu. Ceci est une réalité statistiquement prouvée (pas à 100%, mais pas loin ). Systématiquement, clients et prestataires la sous-estiment. Une obligation de réaliser à des intervalles très courts des fonctionnalités supplémentaires oblige le prestataire à prendre en compte la compléxité du développement, et avoir un indicateur fiable de l’avancement du travail. Trop souvent des prestataires, même très bons, ont l’impression qu’ils vont réaliser tel projet en 3 jours, et s’y mettent pendant le week-end qui precède la date de livraison. Même s’ils mettent toute la bonne volonté du monde, ils seront en retard, et le client sera lésé.

Aspects pratiques : comment travailler avec la méthode itérative ?

Décomposez votre application en de nombreuses petites ou très petites fonctionnalités, de manière à ce que chaque fonctionnalité prenne un jour ou moins de développement. Le prestataire doit alors vous tenir au courant, par écrit, mais également par l’application qu’il a réalisé et qui doit être fonctionnelle, tous les jours ou tous les 2-3 jours, de ce qui a été réalisé durant ce laps de temps. Il ne doit pas seulement vous dire que c’est fait, vous devez pouvoir vous en rendre compte vous même par test de l’application.

Sur un graphique sur lequel vous avez le temps en abscisse et le nombre de fonctionnalités en ordonnée, la courbe représentant les fonctionnalités réalisées en fonction du temps doit être approximativement une droite (et non pas une exponentielle ou une parabole). Vous n’êtes pas obligé d’aller jusqu’à ce niveau de détail, mais vous pouvez faire des petits calculs par vous même (ex. on est arrivé à la moitié du délai prévu, combien de fonctionnalités restent à implémenter) ?

Grâce à un suivi régulier et pratiquement en temps réel du projet, ce dernier aura plus de chances de se solder par un succès.

Pour en savoir plus : http://fr.wikipedia.org/wiki/Cycle_de_d%C3%A9veloppement

Ces temps-ci, comme vous l’avez peut-être déjà vu par vous même, il y a eu moins de projets et moins de réponses de prestataires. L’ambiance d’été, la mer et le beau temps imposent leurs règles

Progonline s’y met aussi : du 8 au 23 août, Progonline tournera au ralenti…

Nous resons joignables par mail, mais nous serons peut-être moins réactifs que d’habitude.

Merci de votre compréhension.