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

Le client modifie les specs en cours de développement

En théorie, la signature des spécifications gèle celles-ci pour le lancement des développements. Tout changement dans ces dernières devrait donc être synonyme d’évolution validée et facturée à part. Dans la plupart des cas, ce seront des changements à prendre en compte durant la recette, à condition de ne pas remettre en cause les fondamentaux du projet.

Attendez-vous à trois genre de demandes :

1. Les remises en cause de fond, qui modifient soit le fonctionnement global du projet, soit ses objectifs initiaux. À proscrire, évidemment, puisque vous changez littéralement de projet. Vous risquez cependant le plus souvent de tomber sur un nombre de petits changements minimes pris individuellement, mais dont la somme sera souvent catastrophique.
2. Les ajouts de fonctionnalités, normalement du ressort de l’évolution, à évaluer, coter, et traiter une fois les développements terminés afin de ne pas mettre en danger le reste du projet.
3. Les modifications graphiques. Ces dernières peuvent d’ailleurs aller jusqu’à une remise en cause globale de la charte qui avait été précédemment validée. Le jour où cela vous arrive, quels que soient les impératifs du client, refusez de développer en blanc, vous courrez au désastre.

D’une manière générale, il est fortement déconseillé de vouloir modifier ce qui avait été validé durant les spécifications tant que les développements ne sont pas terminés et que l’application n’est pas stabilisée. Afin d’éviter la majorité des risques de régressions et d’effets de bord incontrôlés, optez pour une méthodologie de développement conduits par les tests (TDD, test driven developments), dans laquelle le résultat recherché, à travers des tests automatisés, conditionne les développements.

Les processus de validation exigent l’unanimité

Imaginez un projet dans lequel le comité de pilotage serait composé d’une vingtaine de personnes issues de sept sociétés et de cinq pays différents, et éventuellement de départements d’une même entreprise ouvertement en guerre, exigeant l’unanimité pour toute prise de décision la plus bénigne soit-elle. Imaginez maintenant qu’en plus de cela, le processus de validation finale soit soumis à toutes les entreprises du groupe – sans prise en compte aucune de leurs spécificités culturelles, par exemple les codes graphiques en France et au Danemark ne sont pas du tout les mêmes – et à tous les employés ayant affaire de près ou de loin au projet. Imaginez enfin que tout ou partie des spécifications graphiques et fonctionnelles du projet soient soumis en plus à la validation d’un panel de clients triés sur le volet de votre commanditaire. Le cauchemar.

Vous allez me dire que ça n’existe pas, que ça ne peut pas arriver, que j’ai trop lu Crozier, que j’ai du manger un truc trop lourd hier soir… la réponse est non, ça existe, et ce genre de client est tout à fait le genre à immobiliser sine die un projet pour lequel vous aviez par ailleurs mobilisé des ressources en prévision des développements à venir. Parce que le projet était stratégique, et urgent. Si, si, urgent.

Veillez donc particulièrement à votre planning de validations. Celui-ci doit prendre en compte les éventuels aller-retours internes de votre client, mais sans tomber dans l’ubuesque. Dans tous les cas, votre projet ne doit pas pâtir des problèmes structurels de votre client, ou de ses petites curiosités locales. Si votre client n’a pas su harmoniser ses processus et son esprit groupe au cours de ses différentes fusions et acquisitions, ce n’est pas à vous d’en faire les frais. Dans de pareils cas, le meilleur moyen d’éviter les dérapages est probablement de faire développer le projet en régie chez le client.

Le projet est hautement politique

Rien de pire que d’entendre en début de projet “vous comprenez, c’est un projet très politique” ; problèmes assurés. En même temps, ce sont les meilleurs.

Un projet très politique, cela signifie au choix que :

• Le projet émane d’un dirigeant très haut placé qui le considère comme particulièrement stratégique. Dans la réalité, le projet est inopportun, mal ou pas étudié et ne sortira jamais en production. Cela implique généralement un manque de motivation certain de la part de la maîtrise d’ouvrage avec pour effet la non transmission d’informations importantes, et des retards à toutes les étapes.
• Le projet est nécessaire, mais totalement explosif, avec risques de grève générale, de paralysie de l’entreprise, voir pire. Sa mise en place nécessite donc à la fois des prouesses de communication et des négociations à tous les échelons avec les syndicats, sans compter une qualité irréprochable des livrables fournis.
• Le projet est bon, mais pour des raisons diverses, la moitié des collaborateurs de l’initiateur souhaitent le voir finir au placard, et ce dernier décapité.
• Le projet s’intègre dans un contexte social, financier ou politique précis. Le moindre changement dans le contexte risque donc de le voir partir à la poubelle.

Dans la majorité des cas, les projets politiques finissent au placard ou sont retardés jusqu’à ce que tous les obstacles aient été levés. J’ai ainsi appris jeudi dernier que les deux projets “hautement politiques” que j’avais développé en 2005 lors de ma mission BNP avaient été déployés au mois de novembre. Et pour le coup, ils étaient à la fois utiles et utilisables.

Le client vous demande des reports d’échéances

Votre client n’a visiblement plus de quoi financer le projet. Si vous avez opté pour une facturation progressive, vous pouvez mettre le projet en sommeil jusqu’à ce que votre client soit à nouveau en mesure de payer, et peut-être le sera-t-il rapidement. Si vous avez choisi le mode acompte / livraison, les choses sont plus délicates, surtout si les développements sont déjà bien avancés. Et j’entends déjà résonner le fatidique “Nous vous avons déjà largement assez payé, vous devriez être satisfaits de nous avoir dans vos références”. Classique, mais inacceptable.

L’initiateur du projet quitte la société mais le laisse “entre les meilleures mains possibles”

Quelques semaines après le lancement du projet, votre commanditaire vous invite à une réunion au sommet durant laquelle il vous annonce son départ de la société, et vous présente, dans le meilleur des cas son remplaçant, dans le pire un remplaçant par intérim, le temps pour la société de trouver la perle rare.

Et là, on a au choix :

• Un remplaçant pas ou peu au courant du projet, de ses tenants et de ses aboutissants.
• Un remplaçant ne disposant pas des appuis et de l’influence en interne de son prédécesseur. Cf. le paragraphe sur les projets politiques.
• Un intérimaire dont ce n’est pas le métier, ou qui n’a pas le temps.

Conclusion

Il existe évidemment bien d’autres raisons pour lesquelles un projet pourtant bien parti risque de capoter, et les lister toutes ici serait beaucoup trop long. C’est la raison pour laquelle j’ai choisi d’aborder des problèmes inhérents au client, et rencontrés dans ma carrière à un moment ou un autre. Ayez toujours en tête que les projets les mieux ficelés en apparences ne sont jamais à l’abri d’un coup dur. Prévoyez-les, mais ne vous laissez pas bloquer par ce qui pourrait arriver, sinon vous ne sortirez jamais rien.