La collecte des besoins est l’étape la plus importante dans le Cycle de vie de Développement Logiciel.

Requirements Hurried . . . Project Buried (exigences précipitées, projet enterré) de G Chandrashekar

Analyse des besoins : Tout semble si simple au départ. Mais ensuite, que vous construisez un nouveau système à partir de zéro ou achetiez un système et l’adaptiez pour répondre au modèle économique spécifique de société, vous devez traverser une phase d’analyse des besoins. Ce n’est pas tâche facile. L’estimation budgétaire peut aller dépasser des sommets et c’est assez dur. Mais la question la plus difficile est comment vous assurez que le nouveau système fait ce à quoi les utilisateurs (et bien sûr les clients) s’attendent. Si vous remplacez un système existant, le nouveau système devrait faire que le système ancien fait au moins aussi effectivement et efficacement, sinon mieux. C’est un énorme défi.

Voici une douzaine de recommandations pratiques qui seront utiles pendant cet exercice :

1. Ne pas bousculer cette étape

Des études innombrables ont montré que la collecte des besoins est l’étape la plus importante dans le Cycle de vie de Développement de Logiciel. Il est beaucoup plus onéreux de réparer une erreur sur le besoin qu’une erreur de programmation. Mais d’une manière ou d’une autre chacun semble croire qu’un document de spécification des exigences est la partie la plus facile à réaliser et la partie de conception/développement la plus difficile. Cela ne peut pas être vrai. Personne n’a jamais construit une bonne structure sans bonnes fondations. Assurez-vous que vous prenez du temps pour entièrement rassembler les besoins et les analyser en profondeur. Budgétisez le temps suffisant pour rassembler et analyser les besoins avec suffisamment de détail. Ne bousculez pas cette étape à moins que vous ne vouliez enterrer le projet.

2. Détails. Vous ne pouvez pas en avoir trop

Les besoins décrits sur une seule ligne de mots (« one liners ») n’aident pas à concevoir et développer un système. Mais c’est souvent ce que vous obtenez. Et chacun l’interprétera en fonction de leur propre connaissance et expérience. Vous ne pouvez pas acheter d’assurance contre une mauvaise interprétation. Vous devez obtenir une bonne vue d’ensemble, mais vous devez aussi entrer dans les détails infimes. Demandez des détails, même quand la question semble mineure. Vous pouvez y découvrir quelque chose de vraiment critique.

3. Comprendre le business, pas les besoins exprimés

Ne regardez pas de besoin en isolation. Les besoins existent pour supporter une exigence business. Parvenez à connaître ce qu’est ce business- tout aspect de celui que vous essayez de supporter. Une fois que vous avez cela, les liens entre les diverses pièces du puzzle commencent à apparaître. Les besoins tombent simplement à leur place. Vous savez ce qui est critique et pourquoi. La bonne solution apparaît quand vous retournez à la planche à dessin.

4. Tout documenter

Pendant que vous rassemblez les besoins, vous obtenez une quantité énorme de données, souvent sous formes disparates. Des textes, des feuilles de tableur, des présentations PowerPoint, des graphiques et images. La liste est infinie. Documentez, indexez et conservez chaque morceau d’informations que vous rencontrez par hasard et utilisez un bon outil logiciel. Demandez à chacun dans le projet de tout documenter dans une base de données centralisée, pas sur leurs bureaux. Gardez-les à jour. Il n’y a aucun doute que le contexte et la compréhension qui vient avec un document ne peut pas toujours être traduit en besoins. Mais, quand une personne quitte le projet ou l’organisation, vous ne pouvez pas vous permettre de perdre quoi que soit des informations qui existent dans ses cellules grises. Documentez. Quelqu’un regardant les besoins n’aura pas besoin de réinventer plus tard ce que l’on connaît déjà.

5. Impliquer les utilisateurs. Les utilisateurs réels

Les utilisateurs réels sont ceux qui savent le mieux, mais souvent ce sont leurs patrons qui viennent aux réunions avec les analystes (« busines analysts ») et l’équipe de développement. Les hommes en costumes sombres ont probablement la vue d’ensemble et peuvent probablement définir les besoins plus clairement, mais les utilisateurs réels du système sont ceux qui connaissent les éléments clefs et les points de douleur. Impliquez-les chaque fois que vous le pouvez. Particulièrement quand la rentabilité et les flux de travail qui sont clefs au succès du système.

6. Aller les voir travailler

Souvent ce que disent les utilisateurs n’est pas ce qu’ils veulent dire en réalité. Les raisons sont multiples. Ce pourrait être à cause d’un écart de communication, parce qu’ils supposent que de certaines choses sont juste trop basiques pour être mentionnées, ou simplement oubliées. Observez-les dans l’action. Ne vous contentez pas de regarder, observez! Vous serez agréablement surpris des résultats. Le flux de processus est souvent le facteur le plus critique au succès du système en construction. Malheureusement la plupart des collectes de besoins se passe entre les quatre murs d’une salle de conférence ou sur des conférences téléphoniques, pas sur place. Voyez les choses dans l’action, pas dans votre imagination. Souvent, j’ai constaté qu’une heure passée sur place valait plus qu’un jour entier de discussion.

7. Chercher le « chemin malheureux »

Trop souvent nous finissons par construire un système qui traite parfaitement bien le flux normal. Chacun peut vous dire ce qu’est le « chemin heureux »; mais seuls ceux qui utilisent le système dans un contexte business réel peuvent vous dire tout ce qui peut mal tourner. Et si vous ne construisez pas votre système pour traiter les choses qui « peuvent aller mal », vous avez construit un château de cartes. Ne demandez pas simplement aux utilisateurs le « chemin heureux » », encouragez les à vous parler du « chemin malheureux ». Mais souvenez-vous; demandez aux vrais utilisateurs.

8. Aller dans les coulisses

Avec des systèmes multiples mis en œuvre dans l’environnement de travail de nos jours, souvent les utilisateurs ne savent plus quel le système fait quoi. C’est totalement transparent pour eux. La transparence est bonne du point de vue des utilisateurs, mais pas pour ceux qui cherchent à construire un nouveau système. Les utilisateurs vous diront ce qu’ils pensent que fait leur système existant. Efforcez-vous de connaître la portée du système que vous essayez de construire ou remplacer. Impliquez les gens techniques qui peuvent fournir ces informations pour éviter de devoir refaire.

9. Trouver les documentations

Cherchez le manuel système et guide utilisateur. Vous en trouverez beaucoup prenant la poussière dans un coin oublié. Alors que les utilisateurs peuvent vous parler de choses qu’ils font souvent, il y a des choses dont ils ne se rappellent pas – ou ne comprennent pas. Un document correctement approuvé peut être une mine d’or d’informations. Il pourrait vous dire non seulement ce que le système fait, mais aussi pourquoi. Le pourquoi peut être décisif quand vous devez prendre certaines décisions sur inclure ou pas une fonctionnalité spécifique dans le nouveau système.

10. Construire un nouveau système, ne pas copier l’ancien

Souvent les utilisateurs veulent que le nouveau système fasse les choses exactement de la même façon que le système précédent. Les personnes au sommet seraient aussi heureuses puisque cela diminuerait le coût de formation et éviterait des erreurs. La plate-forme technologique que vous utilisez pour le nouveau système pourrait être bien meilleure, mais faire les choses d’une manière peu familière aux utilisateurs. Obtenez l’engagement de la direction. Faites que les utilisateurs sachent qu’il va être différent. Après tout, vous construisez un nouveau système, vous ne produisez pas une copie de l’ancien !

11. Construire des besoins ou des limitations ?

Il n’est pas rare que des utilisateurs demandent quelques fonctionnalités dans le nouveau système basées sur ce que fait leur ancien système. Ils peuvent sincèrement croire que c’est le besoin business alors que c’est en réalité une limitation du système existant. Personne ne se rend compte que c’est une limitation parce que c’est ce qu’ils ont toujours fait. Ne finissez pas par intégrer ces limitations.

12. Voir les rapports et les gens qui les utilisent

Vous pensez que les rapports sont la partie plus facile ? Repensez-y. Ce sont les rapports qui fournissent une vue de ce qui se passe dans l’organisation aux gens qui prennent toutes les décisions critiques. Faites une gaffe sur les rapports et vous avez fait tout ce qu’il faut pour la perte de l’organisation. À propos, l’organisation peut avoir un stock énorme de rapports qui sont produits dans le système existant, mais quelqu’un les utilise-t-il ? La construction d’un nouveau rapport coûte de l’argent. Pas seulement l’effort premier de les construire et les tester, mais ensuite le coût pour l’impression, la diffusion, le stockage et la destruction. Et oui, vous augmentez aussi votre empreinte carbone. La diminution du nombre de rapports de moitié quand un nouveau système est introduit n’est pas rare du tout. Regardez-le comme une opportunité de nettoyer l’inventaire de rapports.

La bonne équipe avec le bon niveau de temps investi peut être la clé du succès de la phase la plus critique de construction d’un nouveau système. Prenez votre temps, tout à fait littéralement. Cela peut faire la différence entre un projet réussi et un échec.