Prototype d'un projet foireux

Quel développeur un jour ne s'est pas trouvé sur un projet qui dès le départ s'est révélé " foireux "...

Les conditions d'un projet foireux :
1°/ Pas d'utilisateur
Un projet sans utilisateur, c'est un peu comme un avion sans pilote. Mes meilleures réussites en termes de développement informatique ont toujours été lorsqu'un utilisateur était impliqué dans l'équipe de développement. Et pourtant il n'est pas rare de voir des projets où aucun utilisateur n'est connu des développeurs.

2°/ Specs mouvantes ou inexistantes
Lorsqu'un projet a la chance d'avoir des spécifications écrites, rien n'est pire que de les faire évoluer en cours de développement. Rare sont alors les mises à jour du document...
Qui a écrit ces spécifications ? Un chef de projet ? Un utilisateur ? L'utilisateur les a-t-il validées ? On n'en sait rien !

3°/ Pourquoi faire simple quand on peut faire compliqué ?
Il est déjà suffisamment compliqué d'écrire des logiciels, pour ne pas rajouter une couche de complexité fonctionnelle. En effet, pourquoi vouloir intégrer toutes les règles fonctionnelles dans le logiciel ? Pourquoi au contraire ne pas le simplifier afin que 80% du boulot soit fait, et que les 20% les plus compliqués à développer soit mis de coté ? 80/20, c'est bien la loi de Pareto, mais pourquoi justement l'utiliser à des fins de simplifications, en retirant les fonctionnalités les plus compliquées, comme les exceptions à la règle fonctionnelle. Diminuer la complexité fonctionnelle, c'est diminuer le risque du projet.

4°/ Tir au pigeon
Vous êtes attendu au tournant au moindre bug, ou à la moindre erreur pour qu'une partie "adverse" fasse couler le projet. Un projet sans bug est une utopie. Un projet réussi nécessite beaucoup de bonne volonté.

5°/ Architecture bancale
Le développement est déjà démarré, et l'architecture est bancale, voire même parfois le code est pourri. Et il faut faire avec le code déjà existant. Impensable de jeter tout ce travail…

6°/ Turn-over dans les équipes
Rajoutez à cela de l'instabilité dans les équipes. Des personnes partent et vous avez été choisi pour remplacer justement un développeur qui avait des compétences fonctionnelles indispensables pour la suite…

Conclusion :
Malheureusement, ce genre de situation arrive trop souvent... Alors que faire ? Et bien je vous répondrais ceci : Appréciez la chance que vous avez d'avoir un boulot, bien rémunéré et à l'abri des intempéries !!!