Les pièges du développement logiciel sur mesure : La portée

Certaines entreprises et certains processus ne trouvent pas de solutions dans les logiciels offerts sur le marché. Mon propos ici n’est pas de vous donner les règles de sélections entre l’acquisition de logiciel et le développement sur mesure, mais bien de comprendre les enjeux lorsque vous décidez que le développement d’un logiciel sur mesure est la solution à vos problématiques.

Le développement sur mesure consiste à développer un logiciel selon une série de besoins spécifiques. Cet article s’attardera à la portée du projet. D’autres articles à venir sur le sujet traiteront de l’estimation, de l’importance du PO, de la gestion des budgets et de l’agilité versus le budget d’un projet.

La portée en développement logiciel sur mesure

La portée d’un projet définit les limites de ce dernier, c’est-à-dire qu’elle précise ce qui sera inclus dans la livraison et ce qui sera exclu. Cela semble simple à prime abord, mais il s’agit ici d’un des éléments les plus complexes à gérer dans un projet. Cette étape est inévitable même qu’elle ressort comme le principal objet de conflit et d’insatisfaction.

« La portée est très complexe à définir. C’est d’ailleurs pour cela que les projets Agile définissent un budget fixe et une portée variable plutôt qu’une portée fixe. Cela permet de livrer rapidement au client/utilisateur une ou plusieurs fonctionnalités afin de valider le besoin et réajuster rapidement si nécessaire. Par conséquent, le degré de satisfaction est augmenté. » – Maël Rieussec, Scrum Master chez Askida

Il fut un temps où nous passions des jours, voir des mois à décrire en détail les spécifications et la conception des applications sur mesure que nous avions à développer. Bien que cette méthode eût des avantages tel qu’une plus grande précision, à terme, nous constations que le système développé n’était plus aligné avec les besoins. Le marché de la technologie et des applications étant en évolution rapide, nous devions obtenir la flexibilité de nous ajuster en cours de projet pour éviter d’accumuler une montagne de demandes de changement en fin de mandat.

 

Développement sur mesure – Ne pas sauter d’étape

« Je sais ce que je veux » est sans aucun doute l’affirmation la plus utilisée en démarrage de projet. On sait ce que l’on veut mais le savons-nous précisément? Sans une réflexion préalable, la réponse est très certainement « non ».  J’utilise souvent l’exemple qui suit pour expliquer le niveau de précision dont nous avons besoin pour développer une application sur mesure.

Responsable côté client :
« Je sais ce dont j’ai besoin. J’ai besoin d’une page login. »

Responsable côté fournisseur :
« Ok, je comprends, alors j’ai quelques questions pour vous.
De quoi sera composé le code d’utilisateur?
Est-ce le courriel? Si oui, est-ce que l’on accepte uniquement les courriels d’affaires?
Est-ce un mot? N’importe quel mot?
De quoi sera composé le mot de passe?
La longueur?
On exige une complexité? Quelle est-elle?
À quoi ressemble le processus d’inscription du point de vue administrateur?
Comment je communique avec l’utilisateur?
Est-ce qu’on bloque le compte après un nombre de tentatives invalides? Après combien de tentatives?
Comment le débloque-t-on? »

 

Je m’arrête ici, mais vous comprendrez qu’une série de paramètres devra être discuté pour assurer une expérience utilisateur de qualité et des processus qui suivront vos méthodes de gestions. Même la fonction la plus simple demande un nombre important de précisions et de décisions. On ne peut exiger d’une personne d’avoir en tête l’ensemble des détails techniques composants le développement d’une application sur mesure avant même le début de sa conception. Forcément plusieurs éléments seront précisés au fur et à mesure du développement.

On doit comprendre la portée d’avance pour déterminer la faisabilité technologique, les coûts de développement de la solution, les échéanciers de projet, la taille, la composition de l’équipe, etc…

C’est donc une étape à laquelle nous devons tous être sensibilisés. Nous avons l’expérience et l’expertise pour avoir une bonne idée des livrables souhaités. Avant d’aller de l’avant, un projet demande à connaître les investissements nécessaires et c’est absolument légitime. Mais cela est-il possible?

 

Estimer en mode agile

À travers les années, nos méthodologies d’estimation se sont améliorées et elles continuent d’évoluer. Il y en a des subjectives, des « scientifiques », des ésotériques et aussi des réalistes. De plus, de nombreux outils sont venus simplifier la rédaction des requis.

Mais aucune méthodologie ne pourra extraire ce que le demandeur ne connait pas. C’est là le principal enjeu. Selon Rieussec : « C’est pour cela que la méthodologie Agile recommande de livrer fréquemment afin d’expérimenter, et échouer rapidement, donc découvrir rapidement ce qu’on ne connait pas. »

Qu’arrive-t-il s’il n’y a que quelques détails que je ne connais pas me demanderez-vous? C’est là que l’effet papillon mine le succès de l’opération. Est-ce possible qu’une si petite décision, que cette minuscule précision, que ce microscopique changement ait un impact aussi majeur sur mon système? He bien… Oui! Il arrive qu’on soit incapable d’évaluer l’impact qu’aura une action dans un système complexe. Dans un contexte client-fournisseur, on en vient vite à chercher à qui la faute. Est-ce une demande de changement? Est-ce inclus? Beaucoup d’efforts et de ressources sont alors dépensés sans créer de valeur intrinsèque au projet.

C’est pourquoi il est inévitable de faire appel au professionnalisme, aux méthodes éprouvés, aux outils existants et à l’expérience acquise de part et d’autre pour assurer un alignement clair dans le projet.

Que faut-il en retenir?

 

  1. 1. Maintenant vous le savez. Ça va arriver. Parlez-en immédiatement au démarrage du projet entre client et fournisseur;
  2. 2. Ne prenez aucune action dans le système à la légère;
  3. 3. Le Product Owner ne doit rien demander directement à un développeur en considérant que ce soit une demande mineure;
  4. 4. Les méthodologies Agile permettent de mieux gérer et encadrer ces situations, encore faut-il les utiliser pour vrai;
  5. 5. Ne cherchez pas les coupables, chercher les solutions;
  6. 6. Utilisez la stratégie « MVP » (minimum viable product), c’est encore la meilleure solution pour diminuer ce risque, en travaillant sur les fonctions essentielles et en mettant rapidement l’application dans les mains des utilisateurs finaux.
  7. 7. Suite à la livraison du MVP, de courtes itérations permettront d’identifier rapidement les enjeux reliés à la portée;
  8. 8. De grâce, prévoyez un budget.  En ne le prévoyant pas au départ, question de présenter un budget le plus bas possible, vous vous assurez des conflits, une explosion du budget et une grande insatisfaction;
  9. 9. Développez la confiance.
Image Steeve Duchesne

Steeve Duchesne

PDG à Askida / CEO at Askida