Dans la première partie, nous avons parlé de la vertical slice : le premier chemin étroit à travers le système est en place, la technologie fonctionne.
Et maintenant ? On code simplement le reste ?
Si seulement c'était aussi simple.
La réalité est la suivante : les exigences changent dès le moment où les utilisateurs cliquent pour la première fois. Ce qui semblait logique sur le papier hier paraît faux dans l'application aujourd'hui.
C'est pourquoi le Requirements Engineering n'est pas un événement ponctuel au début d'un projet. C'est un cycle continu qui ne s'arrête que lorsque le projet passe en production, et souvent même pas à ce moment-là.
Le cycle : découvrir, construire, apprendre
Classiquement, on apprend des modèles comme : Elicit -> Analyze -> Specify -> Validate.
Cela sonne propre et linéaire, mais en pratique c'est souvent plus chaotique. Et ce n'est pas un problème.
Nous le voyons plutôt comme ceci :
- Comprendre le problème (Elicit et Analyze)
- Construire une solution (Specify et Implement)
- La montrer à l'utilisateur (Validate)
Et ensuite ? On recommence.
Chaque tour affine l'image. Au début, tout est flou. Après trois tours, on voit les contours. Après dix, les détails.
Si vous essayez d'obtenir quelque chose de parfait dès le premier passage, vous resterez bloqué dans la théorie pour toujours.
La connaissance implicite : ce que personne ne vous dit
Le plus grand risque dans la phase "Elicit" : les gens ne vous disent pas tout.
Non pas par malveillance. Mais parce que beaucoup de processus leur paraissent évidents. "Bien sûr que la facture doit être approuvée, Karen fait toujours cela le vendredi." Ce n'est écrit dans aucun document de processus. Tout le monde le sait, sauf vous.
C'est pourquoi il ne suffit souvent pas d'interroger les gens ou de lire la documentation.
Notre conseil : allez là où le travail se fait.
Passez une matinée à côté du collaborateur qui traite les demandes. Regardez par-dessus l'épaule du magasinier. Nous appelons cela le "shadowing".
Vous découvrirez des choses qui n'ont jamais été mentionnées en réunion. Des contournements, "je clique toujours trois fois sur Retour, sinon cela ne marche pas", des pense-bêtes collés sur les écrans, ou des accords informels.
Cette connaissance implicite fait souvent la différence entre un logiciel qui "fonctionne techniquement" et un logiciel qui aide réellement les gens.
Méfiez-vous du "Big Design Up Front"
Même avec le cycle en place, la tentation est énorme de tout planifier à nouveau dès le départ.
"Nous devons finaliser tout le modèle de données avant de continuer à construire."
Non, vous n'en avez pas besoin.
Vous devez seulement en savoir suffisamment pour franchir l'étape suivante.
La planification donne un sentiment de sécurité. Mais trop de planification en amont n'est souvent qu'une illusion de sécurité. Vous planifiez sur la base d'hypothèses, pas de connaissances.
Ayez le courage de laisser des zones ouvertes. Marquez consciemment certains sujets comme "Non clair" au lieu de les remplir avec des exigences inventées juste pour fermer un ticket.
Une zone ouverte, "nous ne savons pas encore comment fonctionne l'annulation", est honnête. Une mauvaise spécification, "l'annulation passe toujours par le manager", coûte cher lorsqu'il faut tout arracher plus tard.
Ce cycle de compréhension, de construction et d'apprentissage est exigeant. Il vous force à prendre des décisions en permanence et à remettre en question vos propres hypothèses.
Mais c'est la seule manière de construire un logiciel qui ne soit pas simplement terminé, mais réellement juste.
Besoin d'aide ?
Le cycle semble pertinent, mais le quotidien finit toujours par reprendre le dessus ? Nous aidons votre équipe à instaurer ce processus itératif, de manière pragmatique et sans lourdeur théorique. Parlons-en.
Dans la dernière partie, nous verrons comment les outils IA et les défis spécifiques des petites et moyennes entreprises influencent ce processus aujourd'hui.
