Sur les projets de développement

Techniques imparables pour faire échouer un projet de développement (et les 10 remèdes correspondants).

Avez-vous déjà vu le projet d’une équipe de développement échouer parce que ses techniques semblaient condamner l’application aux yeux des utilisateurs ? Voulez-vous éviter les mêmes erreurs ? Apprenez à reconnaître – et à éviter – les pièges courants suivants.

Technique 1.
Abordez le développement dans le style « Big Bang ». Tenez quelques réunions pour recueillir les exigences puis enfermez-vous pendant des mois pour pratiquer une conception et un coding diligents. Balancez le code aux utilisateurs lors d’une réunion « d’examen » de deux heures, en espérant qu’ils suggèreront quelques changements mineurs et que vous pourrez procéder au déploiement avec peu d’efforts supplémentaires.

Remède : Pratiquez un développement itératif dans lequel vous travaillez pendant une semaine ou deux (ou un intervalle plus court ou plus long) pour produire une nouvelle version avec des fonctions et/ou des raffinements supplémentaires. Invitez les utilisateurs à essayer chaque nouvelle version et à réagir immédiatement. Ajustez en conséquence vos plans pour la nouvelle itération.

Technique 2.
Imposez votre concept global sur la manière dont l’application devrait fonctionner. Ne recherchez les exigences et les suggestions que dans ce cadre. N’envisagez pas une seconde que vous avez peut-être mal compris la manière dont les utilisateurs conçoivent leur travail et le contexte dans lequel il se déroule – votre expérience de beaucoup d’autres projets fait que votre concept est de toute manière le meilleur.

Remède : Ne perdez jamais de vue le « panorama général » et soyez prêts à repenser votre approche au fur et à mesure que les utilisateurs murissent dans un processus itératif. En recevant des réactions précoces et fréquentes, il est probable que vous n’aurez pas à pratiquer de gros ajustements en matière d’architecture ou de technologie. Mais, si cela s’avère nécessaire, au moins vous le saurez assez tôt.

Technique 3.
N’impliquez surtout pas les utilisateurs dans le travail de conception et de développement quotidien. Ils vous ralentiraient. Espérez qu’ils attendront que vous les contactiez, puis fourniront des réponses immédiates aux questions très précises que vous leur présenterez dans n’importe quel contexte.

Remède : Ayez au moins un utilisateur connaissant bien le sujet dans l’équipe de développement et travaillez avec lui sur une base hebdomadaire ou quotidienne. Développez un groupe de « consultants pairs » – des utilisateurs finaux qui sont bien au courant du projet et susceptibles d’élargir le canal de communication entre l’équipe de développement et le reste de l’entreprise.

Technique 4.
Ne prenez pas la peine d’éduquer ceux qui « s’approprient » l’application avant de leur demander leur opinion ou leur approbation. Partez du principe que les utilisateurs comprendront immédiatement votre modèle applicatif global et tous les éléments techniques intelligents que vous y avez intégrés. Comme votre modèle frôle la perfection, peu importe si les utilisateurs ne comprennent pas complètement ce que vous leur proposez d’accepter. Comptez sur leur foi en l’expert que vous êtes.

Remède : Commencez dès le début et ne vous arrêtez jamais à construire les connaissance de base des utilisateurs à propos de tout ce qui touche à l’architecture et aux fonctionnalités. Quelques-uns des utilisateurs au moins doivent savoir « parler la langue » pour fournir à l’équipe des renseignements informés et constructifs.

Technique 5.
Ne vous souciez pas de l’exactitude ou de la clarté des détails dans la documentation ou les présentations données aux utilisateurs. Vous savez que vous pourrez corriger les erreurs et les incohérences avant ou après le déploiement, donc attendez-vous à ce que les utilisateurs apprécient vos ébauches approximatives sur la manière dont le système fonctionnera.

Remède : Veillez à ce que toutes vos communications avec les utilisateurs soient aussi efficaces que possible : concises, précises, compréhensibles et en temps opportun. La qualité de la réaction des utilisateurs et votre crédibilité dépendent d’une information exacte et précise.

Technique 6.
Ne prévoyez pas beaucoup temps pour les utilisateurs. Accordez-leur quelques minutes de travail pratique avec les prototypes ou les modèles de préproduction. Certes, il faut bien que les utilisateurs « touchent » un peu le système avant de le mettre en production, mais prévoyez une heure environ de formation « approfondie » une fois le système réalisé, et cela devrait suffire.

Remède : Utilisez votre processus itératif pour délivrer des versions incrémentielles de l’application. A chaque étape, laissez aux utilisateurs beaucoup de temps pour travailler « avec un système réel » et pour vous informer en retour. Après chaque itération, ajustez vos délivrables, le planning et le processus de développement.

Technique 7.
Partez du principe que les objections techniques soulevées par les utilisateurs s’expliquent par le seul fait qu’ils ne sont pas assez intelligents ou aussi bien formés que vous, « l’expert » logiciel. Des questions naïves sur la structure de l’application ou sur des détails sur son mode d’utilisation sont dues à la faible compréhension des utilisateurs des systèmes aussi sophistiqués que le vôtre.

Remède : N’ignorez aucun des points qu’un utilisateur soulève. Même si vous avez raison, l’utilisateur doit comprendre pourquoi. Voir Remède 4.

Technique 8.
Passez de longs moments en compagnie de vos copains informaticiens désolés que vous deviez supporter des directeurs de département « idiots » et des utilisateurs « geignards ». Après vous être décarcassé à essayer de créer pour ces ingrats le meilleur système qui soit, vous avez grand besoin de réconfort et de sympathie.

Remède : Quittez votre bureau et passez du temps « sur le terrain » avec des utilisateurs finaux, et pas simplement lors des réunions officielles. Si possible, demandez à des membres de l’équipe d’effectuer quelques-uns des jobs des utilisateurs pour mieux comprendre pourquoi ces derniers ont besoin de cette application.

Technique 9.
Si les utilisateurs rechignent quand vous vous préparez à déployer l’application, expliquez qu’une date butoir menace, que vous avez déjà dépassé le budget, et donc tout changement au système de production prévu causerait de graves perturbations dans l’organisation. Glissez sur le fait que la livraison d’un système défectueux causera encore plus de perturbation, ou que la vraie « perturbation » qui vous préoccupe est les conséquences d’un délai non tenu ou … garder votre emploi.

Remède : Une approche itérative et incrémentielle vous donnera une compréhension réaliste de la manière dont le projet avance et indiquera quels ajustements du programme ou de la livraison seront nécessaires. Evitez les surprises. Si le système est très défectueux, avalez la pilule et replanifiez sa date de livraison.

Technique 10.
Ne tenez aucun compte de ce qui se passe autour de vous. Vous savez déjà comment mener un projet – vous le faites depuis des années. Donc il n’y a rien de vraiment important à apprendre d’un projet de plus finissant en désastre.

Remède : Apprenez de vos erreurs… et de vos réussites. Tenez des réunions « post-mortem » ou de débriefing formelles après chaque itération et après l’aboutissement de chaque projet. Tenez un document « Leçons apprises » informel que vous transmettrez en héritage à la prochaine génération de développeurs logiciels.