J'ai passé les 3 derniers mois dans une phase exhaustive - et épuisante - de collecte des exigences d'un grand projet et j'ai appris, par-dessus tout, qu'il n'y a pas de solution unique . Il n'y a aucun processus, aucun secret, qui fonctionnera dans tous les cas. L'analyse des exigences est une véritable compétence, et juste au moment où vous pensez avoir enfin tout compris, vous êtes exposé à un groupe de personnes totalement différent et devez jeter tout ce que vous savez par la fenêtre.
Différentes parties prenantes pensent à différents niveaux d'abstraction.
Il est facile de dire «parler au niveau de l'entreprise, pas technique», mais ce n'est pas nécessairement aussi simple à faire . Le système que vous concevez est un éléphant et vos parties prenantes sont les aveugles qui l'examinent . Certaines personnes sont si profondément plongés dans le processus et la routine qu'ils ne réalisent même pas qu'il y est une entreprise. D'autres peuvent travailler au niveau d'abstraction que vous souhaitez, mais être enclin à faire des affirmations exagérées ou même fausses, ou à faire des vœux pieux.
Malheureusement, vous devez simplement apprendre à connaître tous les individus en tant qu'individus et comprendre comment ils pensent, apprendre à interpréter les choses qu'ils disent et même décider quoi ignorer.
Diviser et conquérir
Si vous ne voulez pas que quelque chose soit fait, envoyez-le à un comité.
Ne rencontrez pas les comités. Gardez ces réunions aussi petites que possible. YMMV, mais d'après mon expérience, la taille idéale est de 3-4 personnes (y compris vous-même) pour les sessions ouvertes et 2-3 personnes pour les sessions fermées (c'est-à-dire lorsque vous avez besoin d'une réponse à une question spécifique).
J'essaie de rencontrer des gens qui ont des fonctions similaires dans l'entreprise. Il y a vraiment très peu à gagner et beaucoup à perdre en jetant les gens du marketing dans la pièce avec les compteurs de haricots. Recherchez les personnes qui sont des experts sur un sujet et demandez-leur de parler de ce sujet.
Une réunion sans préparation est une réunion sans but.
Quelques autres réponses / commentaires ont fait référence à la technique de l'homme de paille, qui est excellente pour ces gens gênants dont vous ne semblez pas pouvoir obtenir de réponses. Mais ne comptez pas trop sur les hommes de paille , sinon les gens commenceront à se sentir comme si vous les cheminiez. Vous devez pousser doucement les gens dans la bonne direction et les laisser proposer les détails eux-mêmes, afin qu'ils se sentent comme s'ils les possédaient (et dans un sens, ils les possèdent).
Ce que vous devez avoir, c'est une sorte de modèle mental de la façon dont vous pensez que l'entreprise fonctionne et comment le système devrait fonctionner. Vous devez devenir un expert du domaine , même si vous n'êtes pas un expert de l'entreprise en question. Faites autant de recherches que possible sur votre entreprise, ses concurrents, les systèmes existants sur le marché et tout ce qui pourrait même être lié à distance.
Une fois à ce stade, j'ai trouvé plus efficace de travailler avec des constructions de haut niveau, telles que les cas d'utilisation, qui ont tendance à être agréables pour tout le monde, mais il est toujours essentiel de poser des questions spécifiques. Si vous commencez par "Comment facturez-vous vos clients?" , vous êtes dans une très longue réunion. Posez des questions qui impliquent un processus au lieu de couronner le processus dès le départ: quels sont les éléments de campagne? Comment sont-ils calculés? À quelle fréquence changent-ils? Combien de types de ventes ou de contrats différents existe-t-il? Où sont-ils imprimés? Vous avez eu l'idée.
Si vous manquez une étape, quelqu'un vous le dira généralement. Si personne ne se plaint, alors donnez-vous une tape dans le dos, car vous venez de confirmer implicitement le processus.
Reportez les discussions hors sujet .
En tant qu'analyste des exigences, vous jouez également le rôle de facilitateur, et à moins que vous n'aimiez vraiment passer tout votre temps aux réunions, vous devez trouver un moyen de garder les choses sur la bonne voie. Ironiquement, ce problème devient plus pernicieux lorsque vous faites enfin parler les gens. Si vous ne faites pas attention, cela peut faire dérailler le train pour lequel vous avez passé tant de temps à poser les voies.
Cependant - et j'ai appris cela à la dure il y a longtemps - vous ne pouvez pas simplement dire aux gens qu'un problème n'est pas pertinent . C'est évidemment pertinent pour eux , sinon ils n'en parleraient pas. Votre travail consiste à amener les gens à dire «oui» autant que possible et à mettre en place une barrière comme celle-ci vous fait simplement tomber en territoire «non».
Ceci est un équilibre délicat que beaucoup de gens sont capables de maintenir des « points d'action » - essentiellement une file d' attente générique des discussions que vous avez promis de revenir à quelque temps , normalement étiquetés avec les noms de ces intervenants qui pensaient qu'il était vraiment important. Ce n'est pas seulement pour la diplomatie - c'est aussi un outil précieux pour vous aider à vous souvenir de ce qui s'est passé pendant les réunions et à qui parler si vous avez besoin d'éclaircissements plus tard.
Différents analystes gèrent cela de différentes manières; certains aiment le tableau blanc très public ou le journal du tableau de conférence, d'autres le tapent silencieusement dans leurs ordinateurs portables et se connectent doucement à d'autres sujets. Tout ce avec quoi vous vous sentez à l'aise.
Vous avez besoin d'un agenda
C'est probablement vrai pour presque n'importe quel type de réunion, mais c'est doublement vrai pour les réunions d'exigences. Au fur et à mesure que les discussions avancent, l'esprit des gens commence à s'éloigner et à se demander quand vous allez en arriver aux choses qui leur tiennent vraiment à cœur. Avoir un ordre du jour fournit une certaine structure et vous aide également à déterminer, comme mentionné ci-dessus, quand vous devez reporter une discussion qui devient hors sujet.
N'y entrez pas sans avoir une idée claire de ce que vous voulez couvrir et quand . Sans cela, vous n'avez aucun moyen d'évaluer vos propres progrès et les utilisateurs vous détesteront toujours pendant longtemps (en supposant qu'ils ne vous détestent pas déjà pour d'autres raisons).
Mock It
Si vous utilisez PowerPoint ou Visio comme outil de maquette, vous allez souffrir du problème de son aspect trop poli . C'est presque une vallée étrange d'interfaces utilisateur; les gens se sentiront à l'aise avec les dessins de serviettes (ou les dessins générés par ordinateur qui ressemblent à des dessins de serviettes, en utilisant un outil comme Balsamiq ou Sketchflow ), car ils savent que ce n'est pas la vraie chose - même raison pour laquelle les gens peuvent regarder des personnages de dessins animés. Mais plus cela commence à ressembler à une véritable interface utilisateur, plus les gens voudront s'y attarder et plus ils passeront de temps à discuter des détails qui sont finalement insignifiants.
Alors, faites des maquettes pour tester votre compréhension des exigences ( après les premières étapes de l'analyse) - elles sont un excellent moyen d'obtenir des commentaires très rapides et détaillés - mais gardez-les en lo-fi et ne vous précipitez pas dans la moquerie jusqu'à ce que vous '' re à peu près sûr que vous voyez en face-à-face avec vos utilisateurs.
Gardez à l'esprit qu'une maquette n'est pas un livrable , c'est un outil pour aider à la compréhension. Tout comme vous ne vous attendriez pas à être captif de votre maquette lors de la conception de l'interface utilisateur, vous ne pouvez pas supposer que la conception est OK simplement parce qu'ils ont donné le feu vert à votre maquette. J'ai vu des simulacres utilisés comme une béquille, ou pire, une excuse pour contourner complètement les exigences; assurez-vous que vous ne le faites pas. Revenez en arrière et transformez cette maquette en un véritable ensemble d'exigences.
Sois patient.
C'est difficile à croire pour beaucoup de programmeurs, mais pour la plupart des projets non triviaux, vous ne pouvez pas vous asseoir une seule fois et élaborer une spécification fonctionnelle complète. Je ne parle pas seulement de patience lors d'une seule réunion; l'analyse des exigences est itérative de la même manière que le code. Le groupe A dit quelque chose, puis le groupe B dit quelque chose qui contredit totalement ce que vous avez entendu du groupe A. Ensuite, le groupe A explique l'incohérence et il s'avère que c'est quelque chose que le groupe C a oublié de mentionner. Répétez 500 fois et vous avez quelque chose qui ressemble à peu près à la vérité .
À moins que vous ne développiez une petite application CRUD (dans ce cas, pourquoi vous embêter avec les exigences?), Ne vous attendez pas à obtenir tout ce dont vous avez besoin en une ou deux ou cinq réunions. Vous allez écouter beaucoup, parler beaucoup et vous répéter beaucoup. Ce qui n'est pas une chose terrible, remarquez-vous; c'est une chance de tisser des liens avec les gens qui vont inévitablement approuver votre livrable.
N'ayez pas peur de changer votre technique ou d'improviser.
Différents aspects d'un projet peuvent en fait nécessiter différentes techniques d'analyse. Dans certains cas, l'UML classique (diagramme de cas d'utilisation / activité) fonctionne très bien. Dans d'autres cas, vous pourriez commencer avec des KSI d'entreprise, ou réfléchir à une carte mentale, ou plonger directement dans des maquettes malgré mon avertissement précédent.
L'essentiel est que vous devez comprendre le domaine vous-même et faire vos devoirs avant de perdre le temps de quelqu'un d'autre. Si vous savez qu'un département ou composant particulier n'a qu'un seul cas d'utilisation, mais que c'est incroyablement compliqué, alors ignorez l'analyse de cas d'utilisation et commencez à parler des flux de travail ou des flux de données. Si vous n'utilisez pas le même outil pour chaque partie de la mise en œuvre d'une application, alors pourquoi utiliseriez-vous le même outil pour chaque partie des exigences?
Gardez l'oreille au sol.
De tous les trucs et astuces que j'ai lus pour l'analyse des exigences, c'est probablement celui qui est le plus souvent négligé. Je pense honnêtement que j'ai appris plus d'écoutes et d'écrasements occasionnels de conversations sur des refroidisseurs d'eau que lors des réunions prévues.
Si vous êtes habitué à travailler de manière isolée, essayez de trouver un endroit où se situe l'action afin que vous puissiez entendre le bavardage. Si vous ne le pouvez pas, faites des tournées fréquentes, dans la cuisine ou la salle de bain ou n'importe où. Vous découvrirez toutes sortes de choses intéressantes sur le fonctionnement réel de l'entreprise en écoutant ce que les gens se vantent ou se plaignent pendant leurs pauses café et fumée.
Enfin, lisez entre les lignes .
L'une de mes plus grosses erreurs dans le passé a été d'être tellement concentré sur le résultat final que je n'ai pas pris le temps d' entendre ce que les gens disaient . Parfois - la plupart du temps - cela peut sembler que les gens se moquent de rien ou se moquent d'une procédure qui vous semble totalement inutile, mais si vous vous concentrez vraiment sur ce qu'ils disent, vous vous rendrez compte qu'il y a vraiment une exigence enfouie là-dedans - ou plusieurs.
Aussi ringard et insipide que cela puisse paraître , le Five Whys est une technique vraiment utile ici. Chaque fois que vous avez cette réaction "stupide" (pas que vous le diriez jamais à voix haute), arrêtez-vous et transformez-la en une question: pourquoi? Pourquoi ces informations sont-elles retapées quatre fois, puis imprimées, photocopiées, numérisées, imprimées à nouveau, épinglées sur un panneau de particules, prises avec un appareil photo numérique et finalement envoyées par e-mail au directeur des ventes? Il y a une raison , et ils ne savent peut-être pas ce que c'est, mais c'est votre travail de le découvrir. Bonne chance avec ça. ;)