Dans l’article ‘Le client : Maïeutique mode d’emploi’, je me permets de remarquer que l’utilisateur évoque systématiquement les cas nominaux et ne se préoccupe pas des cas à la marge de son métier. De cette situation découle un dilemme connu de tous les développeurs : dois-je creuser le besoin du client ?
Si on est dans le cas d’un projet un peu complexe, la question ne devrait pas se poser aux développeurs. En effet, ceux-ci sont présents pour réaliser les demandes définies dans le cahier des charges ou dans les dossiers de spécifications. Concrètement, le développeur code l’application. Le reste ce n’est pas à lui d’y penser.
Pourtant, il est le premier à s’apercevoir des manques. En effet, un développeur consciencieux s’apercevra des situations oubliées dans les spécifications. Une application doit gérer le suivi au sein d’un établissement scolaire. Si un élève ne suit pas le circuit traditionnel (redoublement, changement d’établissement, …), que fait-on ?
Ne pensez pas que mon exemple est caricatural. Il est issu d’une situation réelle où malgré mes remarques, il fut impossible de faire comprendre à la chef de projet que ces cas pouvaient se produire. Cette dernière, plus occupée à ces bénéfices qu’à ceux du client, rejetta mes alertes et préféra me menacer. Tout ceci n’était qu’un projet étudiant.
Dans le monde professionnel, les comportements le sont moins. Le développeur est vu comme un simple exécutant. Alors son avis … Pourtant, plus un oubli est détecté tardivement et plus la correction est coûteuse. Lorsque les utilisateurs finaux réceptionnent l’outil, le projet est déjà ‘terminé’. Il entre dans une nouvelle phase : la maintenance.
Le dilemme du développeur est donc le suivant :
- S’il fait remonter rapidement les cas absents dans les dossiers de spécifications à ses collègues analystes, le planning risque d’être décalé. Les retards seront alors imputables à l’employé zélé, qu’il ait tort ou raison.
- S’il prend en compte dans ses programmes les cas non décrits dans les dossiers, rien n’assure que ces choix soient corrects par rapport aux attentes des utilisateurs finaux. Il devient responsable de la baisse de la qualité du code en cas de mauvaise interprétation.
- S’il ne fait rien, s’il réalise la demande exprimée à la lettre, c’est l’utilisateur final qui se plaindra … ou pas. [Sarcasme-On]Avec un bon commercial, ces corrections peuvent même être facturées plus tard comme des évolutions.[Sarcasme-Off]
C’est ce dernier comportement qui est le plus apprécié en entreprise. Le développeur ne remet pas en cause le travail de ses collègues. Il est donc bien intégré à l’équipe. Et tant pis pour le sentiment de travail mal fait et pour les problèmes engendrés pour l’utilisateur final. Si cela travaille la conscience du développeur, il peut toujours monter sa boîte.
Méfiez-vous donc des grandes ESN qui affichent sur le papier de magnifiques Plans d’Assurance Qualité (PAQ) ou des certifications ISO 27001. Rien n’indique que les professionnels affectés à votre projet aient les moyens de mettre en œuvre les méthodes présentées dans les brochures.
Bien sûr, on n’imagine pas ce type de situation dans un autre domaine. Prenons le cas du bâtiment, une entreprise de BTP réagira si les plans de l’architecte ne respectent pas les contraintes mécaniques des équipements attendus. Un plombier fera remarquer si la pièce d’eau ne dispose pas d’évacuations adaptées ou d’une ventilation suffisante avant d’entreprendre des travaux.
Dans le même genre d’idée, on n’imagine pas des professionnels de santé mettre en place un plan de vaccination sans se préoccuper des risques allergiques, des antécédents médicaux des patients ou du recul sur les effets du nouveau vaccin. C’est impensable !
Mais le développeur, lui, n’a rien à dire. “Je décide, il exécute” dira son responsable.