Cajoler les exigences des gens d'affaires?

Quelles méthodes semblent fonctionner le mieux pour convaincre les gens d'affaires non technologiques? Je travaille avec une équipe qui essaie de rassembler une spécification pour un projet. Chaque fois que nous nous rencontrons et que cela se résume aux attentes pour la prochaine réunion, nous demandons aux hommes d'affaires de ramener leurs exigences. Ils répondent généralement quelque chose comme ceci: «Eh bien, pensez-vous que vous pourriez créer un prototype afin que nous puissions voir ce que nous aimons la semaine prochaine… vous savez, pas avec des données ou quoi que ce soit car c'est un prototype, juste la fonctionnalité. est un projet de plus de 6 mois, ce qui est évidemment irréalisable (il faudrait développer le tout!), et nous ne savons même pas quoi prototyper sans une sorte de spécification. Franchement, je pense que comme la plupart des gens, ils ont une idée de ce qu'ils veulent, ils n'y pensent tout simplement pas de la manière ciblée nécessaire pour rassembler les vraies exigences. Au lieu de simplement leur dire, «Donnez-nous ce que vous voulez ou nous ne pouvons / ne ferons aucun travail» (nous voulons qu'ils soient satisfaits des résultats), existe-t-il des moyens de les aider à décider ce qu'ils veulent? Par exemple, nous pourrions leur dire:

«Dessinez quelques écrans (dans Powerpoint, sur une serviette, peu importe) qui montrent l'interface utilisateur que vous souhaitez avec toutes les données que vous souhaitez voir et une description de la fonctionnalité dans les marges. À partir de cela, nous allons le peaufiner et construire le backend en fonction de cet ensemble d'exigences de comportement. »

OU

«Ne vous inquiétez pas de l'apparence actuelle (le numéro 1 raccroche). Donnez-nous simplement une liste de toutes les données que vous voulez sur chaque chose dont le programme garde la trace. Donc, pour «Client», vous pouvez énumérer: nom, adresse, numéro de téléphone, commandes, etc.

L'une ou l'autre de ces approches alternatives pour amener les gens d'affaires à se concentrer sur ce qu'ils veulent a-t-elle un sens? Y a-t-il des alternatives que vous avez vues en action?

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.

Plusieurs leçons que j'ai apprises:

• 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. ;)

Si vous ne pouvez pas en retirer quelque chose, écrivez quelque chose et faites-le approuver. Il est beaucoup plus facile pour les non-techniciens de dire «non, je n'aime pas ça» que «c'est comme ça que vous devez le faire».

Souvent, ce qu'ils veulent et ce qu'ils vous disent sont deux choses très différentes. Prenez le temps de rédiger une première version de la spécification avec les informations que vous connaissez actuellement. Demandez-lui aux parties prenantes de le lire et de l'approuver. Quand ils le liront, ils verront très probablement des choses qu'ils n'aiment pas ou avec lesquelles ils ne sont pas d'accord. Obtenez leurs commentaires, puis révisez.

S'il y a quelque chose sur lequel vous pouvez aller d'une manière ou d'une autre, mettez les deux options en ligne et demandez au décideur de faire un choix. Ne les laissez pas seuls jusqu'à ce qu'ils le fassent.

Quant aux prototypes, faites des maquettes d'écran et expliquez comment les choses fonctionneraient à la place. Encore une fois, voir quelque chose les aide à visualiser ce qui se passe. Emportez de nouvelles maquettes d'écran avec vous lors des réunions et obtenez des réponses.

Dans le passé, j'ai en fait ouvert FireBug et ajouté la modification que le client avait demandée juste en face d'eux afin qu'ils puissent voir à quoi cela ressemblerait. Ils ont donné leur avis, j'ai pris une capture d'écran puis mis en œuvre les changements. Ils ont vraiment aimé pouvoir voir à quoi ressemblerait le changement, et j'ai aimé ça car c'était rapide et j'ai eu ma réponse lors de cette réunion ... pas la suivante.

Demandez-leur de parler davantage de leur entreprise et moins des applications. Découvrez quels sont les vrais problèmes: les rapports de fin de mois prennent trop de temps, les erreurs de saisie de données, ils ont dépassé leur application actuelle, la croissance de l'entreprise devient incontrôlable.

J'imagine que ces réunions sont avec les personnes qui achètent, mais pas avec les personnes qui feront le travail impliquant l'application. Demandez si vous pouvez rencontrer quelques-unes de ces personnes. Ils peuvent vous montrer comment les choses se font vraiment. Assurez-vous de traiter avec des clients qui ont prévu leur temps et leur coût.

Vérifiez s'ils disposent de rapports qu'ils utilisent ou souhaitent utiliser. De toute évidence, vous ne pouvez pas créer le rapport si vous ne collectez pas correctement les données. Ils doivent faire quelque chose à moins que ce soit un secteur d'activité qu'ils n'ont pas encore commencé.

Beaucoup ont ces notions générales que vous êtes le programmeur, vous savez donc comment construire tous les programmes. Les sites de commerce électronique sont tous les mêmes, non?

Commencer petit. Malheureusement, jusqu'à ce que vous ayez quelque chose devant eux, le processus ne s'enregistre tout simplement pas. Si vous n'avez rien à faire, alors fausses.

Beaucoup de cela a à voir avec les compétences interpersonnelles génériques et comment vous communiquez avec le client en premier lieu. Il n'y a pas grand-chose que je puisse dire à ce sujet, au-delà - assurez-vous d'expliquer le processus de manière interactive, où vous attendez également des commentaires et des efforts de la part des clients.

Spécifiquement pour le scénario que vous avez décrit, voici quelques conseils supplémentaires: Commencez par décrire ce que vous trouveriez utile d'avoir, et fournissez des véhicules pour décrire les informations en termes qui ne nécessitent pas de spécialisation technique ou de savoir-faire:

• Histoires d'utilisateurs / cas d'utilisation Demandez des descriptions détaillées de ce que les utilisateurs s'attendent à faire, des informations dont ils ont besoin pour le faire et de ce que vous devez et pouvez attendre des utilisateurs eux-mêmes. Une fois que vous avez ces informations, parcourez-les avec elles et assurez-vous que tout est couvert d'histoires - il ne devrait y avoir rien qui va entrer dans l'application, où vous n'avez pas d'histoires couvrant ce que l'utilisateur y fera.

• Des démonstrations convaincantes Quoi de plus important pour gagner des clients? Quelles parties du programme ou des fonctionnalités doivent se démarquer et doivent être complètement peaufinées? Pouvez-vous me fournir une démo de maquette, en utilisant des notes post-it ou des boîtes en carton ou d'autres remplaçants, sur lesquels vous aimeriez travailler?

• Informations sur le marché / la concurrence Pour chaque user story, que faisons-nous qui ressemble à nos concurrents? Différent? Quelle histoire nos concurrents racontent-ils et essayons-nous de copier / émuler / améliorer / innover / être délibérément différent?

• Questions ouvertes En quoi consistent les exigences et la conception, quelles sont les informations dont vous êtes certain et qu'est-ce qu'une expérience? Où allons-nous essayer des alternatives pour voir laquelle fonctionne? Si vous cherchez plusieurs alternatives et que vous ne nous en avez indiqué qu'une, quelles sont les autres que vous envisagez?

Ensuite, tracez quelques limites:

• Merci de ne pas m'imposer de restrictions techniques . Un homme d'affaires ne devrait pas vous dire "utilisez Windows car c'est mieux que Linux". Ils peuvent cependant fournir des instructions dans le sens de «tous nos marchés cibles utilisent des fenêtres, notre application devra fonctionner sur des fenêtres pour réussir»

• Ne vous inquiétez pas pour le design Surtout si vous traitez avec des gens orientés vers la vente ou le marketing, ils auront tendance à s'enliser avec des problèmes de design. Encore une fois, restreindre la portée de l'information à ce qu'ils se spécialisent - «le bleu est plus beau ici» n'est probablement pas approprié. "Notre concurrent utilise un thème de couleur bleue, et existe depuis les années 80, pour des parties de notre programme où nous n'innovons pas, nous devrions utiliser un schéma bleu pour communiquer que nous ne sommes pas nouveaux", est probablement approprié. "Le nom doit être en haut de l'écran" n'est probablement pas approprié, mais "les informations les plus importantes sur cette page sont le nom de l'utilisateur et le solde du compte bancaire", probablement. Assurez-vous qu'un concepteur est impliqué dans la traduction de ces exigences en interface utilisateur.

• Notez les décisions de préférence Intégrez-les dans les contrats ou autres engagements que vous prenez. N'oubliez pas, cependant, qu'une décision que le client ne comprend pas ne vaut pas le papier sur lequel il est écrit. Un client qui se déconnecte "l'application s'exécutera sur le port 1521" ne vaut pas autant que le client qui se déconnecte "l'application s'exécutera sur un port personnalisé et configurable, qui peut nécessiter une configuration spéciale pour le pare-feu et la sécurité lors du déploiement "

De votre point de vue, afin d'encourager la poursuite du processus:

• Fournir une rétroaction au même niveau d'abstraction C'est le cas partout, par exemple, pour les unités - si le client parle de volume mensuel d'utilisateurs, ne répondez pas en gigabits de bande passante. Ou, pour les cas d'utilisation - décrivez les fonctionnalités en termes de cas d'utilisation, plutôt que les modules ou les corrections de bogues ou les fonctionnalités.

• Fournissez une communication significative Formulez les questions que vous avez et les informations supplémentaires que vous avez découvertes ou que vous recherchez, en termes d'informations qui vous ont été fournies. «Nous allons avec linux» est probablement un commentaire mal écrit, tandis que «nos tests montrent que l'application fonctionne plus facilement lorsqu'elle est hébergée sur des machines linux et accessible avec IE sur Windows» pourrait être plus approprié.

• Itérer rapidement Pour garder le client engagé, fournissez des mises à jour et des itérations rapides et significatives. Les spécifications et les informations qui n'étaient pas disponibles ou faciles à obtenir au début du processus peuvent nécessiter beaucoup d'efforts de la part de votre client, qui vous paie probablement pendant que vous ne les payez pour aucun de leurs travaux. Amener le client à s'impliquer et à s'investir dans le processus peut aider lorsque le travail finit par être quelque chose sur lequel il doit consacrer du temps et des efforts.

Vos clients, les gens d'affaires, peuvent avoir une sorte de problème, désirer une sorte de solution technique, mais ont peu d'idée de la façon dont la solution pourrait fonctionner, et ont donc peu d'idée de comment spécifier une solution potentielle. Si tel est le cas, le rôle manquant est celui d'un analyste de solutions commerciales, qui peut étudier le client, ses problèmes, ses flux de travail, etc., et comment les solutions possibles pourraient s'adapter à ses procédures d'entreprise, sa culture, etc., ainsi que une solution particulière peut être envisageable à mettre en œuvre à temps, en deçà du budget, etc. Il peut s'agir d'un rôle hautement interdisciplinaire, nécessitant une certaine connaissance des pratiques commerciales (droit, comptabilité, logistique, etc.), de la psychologie de l'utilisateur et de la technologie logicielle.

Il semble que vous vouliez forcer le client à être son propre analyste de solutions commerciales. Ce n'est peut-être pas un rôle dans lequel ils ont suffisamment d'expertise pour garantir une spécification raisonnable. Et il semble que vous ne vouliez pas non plus jouer ce rôle. Si ni vous, ni votre client n'a l'expertise pour remplir ce rôle, vous n'avez peut-être pas toutes les personnes nécessaires pour réussir un projet.

Parfois, un tas de prototypes rapides avec lesquels le client peut jouer pourrait être le seul moyen de découvrir expérimentalement et de converger vers une sorte de solution utilisable pour les besoins du client (exprimés et non exprimés). Cela peut ou non convenir à tout type de contrat à durée indéterminée.

AJOUT: Si vous essayez de forcer un document d'exigences à des clients qui n'ont pas l'expertise requise, cela pourrait potentiellement être un énorme drapeau rouge indiquant une catastrophe imminente.

Ne demandez pas les exigences d'interface utilisateur ou de données, demandez les exigences de fonctionnalité.

Demandez-leur ce qu'ils veulent que l'application fasse. Demandez-leur d'expliquer comment ils aimeraient utiliser l'application. Laissez les détails tels que l'interface utilisateur, les données, etc. au début.

J'ai découvert que souvent les utilisateurs ne savent pas ce qu'ils veulent en termes d'interface utilisateur ou de données, mais ils savent ce qu'ils veulent en termes de fonctionnalité. Par exemple, ils me diront "Je veux me connecter et voir toutes les informations client". N'entrez pas dans la présentation des écrans ou dans les données qu'ils recherchent, obtenez simplement les fonctionnalités d'eux.

Une fois que vous avez cela, faites une maquette rapide (j'aime Balsamiq ). Supposez simplement quelle sera l'interface utilisateur / les données et ne passez pas beaucoup de temps dessus. Rapportez ensuite cette maquette au client. À partir de là, ils peuvent vous dire "nous n'avons pas besoin de ces champs" ou "Nous voulons en fait une liste de numéros de téléphone, pas un seul", ou "cela devrait être une liste déroulante, pas une liste".

Une fois que vous avez le point de départ, il est beaucoup plus facile d'étoffer les données et l'interface utilisateur, et je trouve que déterminer la fonctionnalité est le meilleur point de départ.

Je vous suggère d'essayer de les concentrer sur le processus opérationnel avant tout. Demandez-leur de définir, dans un document ou une discussion, comment ils effectuent actuellement les tâches qui seraient gérées par votre logiciel. Ensuite, concentrez-vous sur les parties du processus qu'ils aimeraient voir changer (la raison pour laquelle ils veulent votre logiciel). Utilisez-le comme point de départ pour discuter des autres parties du processus qui pourraient être améliorées, voire supprimées, en utilisant votre logiciel.

Si votre client n'est pas habitué à fournir des exigences logicielles, votre équipe doit rédiger les exigences pour eux. Attendez-vous à passer par plusieurs révisions, mais vous devez au moins leur fournir un document initial pour aider à communiquer ce que vous recherchez.

Une fois que vous avez une bonne idée des exigences fonctionnelles du processus de résultat final attendu qui incorporera votre logiciel, vous pouvez commencer à rédiger des maquettes des interfaces. Si vous souhaitez les laisser essayer d'abord, vous le pouvez, mais généralement vous feriez mieux de fournir les idées initiales et de les laisser les modifier. Vous n'avez pas besoin de code fonctionnel pour cela. Des captures d'écran des interfaces utilisateur en cours de développement, des représentations HTML des mises en page à l'aide de texte de remplissage statique ou même des dessins (si vous avez un artiste décent sur le personnel) pourraient être utilisés pour les discussions initiales sur l'interface utilisateur.

Une fois que vous avez effectué quelques révisions et que tout le monde est d'accord avec ce qui est présenté, obtenez l'approbation écrite du client! Peu importe combien ils résistent, cette étape est cruciale. Vous devrez peut-être les rassurer sur le fait que la signature des exigences ne signifie pas qu'ils ne peuvent pas participer davantage au projet (selon la nature de votre relation avec le client), auquel cas vous devez décrire comment les révisions des exigences seront traitées (par exemple, sous réserve de révision et d'approbation, transférées vers une version ultérieure, tarifées séparément en tant qu'amélioration, etc.).

Je leur dirais que vous développerez le programme fonctionnalité par fonctionnalité. Jusqu'à une prochaine réunion, disons que dans 1-2 semaines, vous allez travailler X nombre de fonctionnalités. Cela peut être 1, 2, 3 ou plus.

Disons que vous commencerez par développer la fonctionnalité la plus importante en premier. Vous devez commencer par les fonctionnalités de base. Disons que vous fabriquez un guichet automatique (pour les besoins de l'argument). Dites-leur, ok la première (ou la suivante) dans la liste des fonctionnalités les plus importantes est de demander la date de naissance de l'utilisateur comme confirmation lors d'un retrait important (remplacez une fonctionnalité de votre projet que vous savez ne pas être l'une des principales fonctionnalités de base qui serait mis en œuvre ensuite).

Cette affirmation naïve devrait susciter une réaction du client. Quand il leur demande ce qu'ils feraient ensuite? Quelle est la fonctionnalité la plus importante qui n'a pas encore été effectuée sur le projet et meilleure que celle que vous avez mentionnée.

En réutilisant l'exemple précédent, le client peut vous dire qu'il valide la carte de l'utilisateur ou effectue des dépôts, etc. Ensuite, demandez-lui de le définir pour vous. N'ayez pas peur de poser beaucoup de questions, même des questions naïves si besoin est.

Après avoir discuté de cela avec le client, vous devriez avoir certaines exigences pour cette seule fonctionnalité. Vous pourriez définir plus d'un élément de fonctionnalité mais je garderais le nombre très bas.

Dans 1 à 2 semaines, retrouvez le client pour lui présenter ce que vous avez fait et obtenir son avis. Présentez-le au client et obtenez son avis si quelque chose doit être changé ou ajouté.

Répétez ensuite l'exercice précédent pour le prochain ensemble de fonctionnalités. Continuez ce processus de manière itérative pour le reste du projet, en vous assurant de rester en contact avec le client et de vous réunir à intervalles réguliers pour montrer votre travail et planifier ce qui sera fait ensuite (en restant toujours avec de petits morceaux).

Vous parlez d'ingénierie et ils s'en fichent, d'après mon expérience; ils ne veulent pas non plus s'engager à faire quoi que ce soit (en particulier par écrit) et ils ne veulent pas vraiment faire de travail, bien que cela ne soit pas particulier aux types d'entreprises - personne ne veut faire un tas de travail dans un domaine qu'ils ne sais pas et ne se soucie pas de savoir. C'est votre travail (dans leur esprit).

Ce que je fais, c'est ceci: leur parler de ce qu'ils veulent, dans leur langue de domaine. Ils ne pourront pas ou ne voudront pas être précis comme vous l'espérez (cas d'utilisation, conception par contrat, etc.) mais vous pouvez être précis en traduisant leur type de liste vague et aérée de desiderata en conception réelle, et , par conséquent, un document de conception. S'ils vous budgétisent le temps de le faire officiellement, tant mieux. Sinon, créez-en une informelle impromptue sur laquelle vous pouvez répéter.

Ce n'est pas une réponse super heureuse, je sais, mais j'ai trouvé la vie plus facile quand j'ai arrêté d'essayer d'amener les clients (ou n'importe qui, vraiment) à entrer dans mon univers et à parler ma langue. Même si je finis par poser les mêmes questions encore et encore au fur et à mesure que j'accepte le domaine et les exigences (qui ne sont souvent que vaguement comprises par le client), la chose contre-intuitive est que les discussions ne sont pas frustrantes. En fait, les relations avec les clients ont tendance à se renforcer, je suppose parce que les gens aiment parler de ce qu'ils savent, et vous finissez par comprendre leur PDV plus rondement que vous ne le feriez si vous laissiez à une approche design plus rigoureuse.

Sans un gestionnaire qui connaît la programmation, je n'ai jamais eu un seul succès. Au contraire, la seule approche que j'ai trouvée qui fonctionne est d'observer ce qui se passe réellement.

Je suppose que les programmeurs ont une meilleure capacité à imaginer à quoi ressemblera un programme avant sa construction. Prototypage papier peut être une technique efficace pour surmonter ce problème. Les prototypes en papier sont relativement «bon marché» à construire. En guidant vos clients à travers un simple prototype papier, vous démontrez le besoin de penser "de la manière ciblée nécessaire pour rassembler les vraies exigences". Et cela donne un moyen spécifique de se concentrer: en fait, essayer d'utiliser l'application qui est dans votre tête!

De plus, vous pouvez répéter très rapidement de votre meilleure estimation de ce que le client veut à l'application que le client veut vraiment, mais a des difficultés à transmettre. Il est plus facile d'examiner un prototype et de décider pourquoi il ne correspond pas à l'application idéale dans votre tête que de répertorier toutes les exigences de cette application.

J'ai travaillé sur un site web où les autres partenaires étaient plus orientés métier. J'ai continué à demander des exigences spécifiques de différentes manières. Leur réponse a été essentiellement: "Vous êtes un informaticien, nous attendons de vous que vous trouviez ces trucs. Nous préférons faire les trucs d'affaires." Ils n'étaient pas concernés par les détails spécifiques ... jusqu'à la sortie de la première version! Ils étaient beaucoup plus enthousiastes à propos des exigences après la sortie, donnant toutes sortes de commentaires qui m'auraient fait gagner beaucoup de temps dès le départ.

J'ai donc décidé que l'itération était la clé: construire la version minimale viable et l'améliorer en fonction des commentaires. Si les exigences sont trop vagues et générales, prenez des décisions basées sur "Quelle est la mise en œuvre la plus simple et la plus rapide?" (sauf conception / architecture fondamentale du système). Ne pesez pas trop sur des hypothèses basées sur ce que vous pensez être «juste». Cela finira par perdre du temps, car il est fort probable que votre processus de réflexion soit différent de celui de vos clients.

Par exemple: le client demande une fonction de téléchargement d'images; n'élaborera pas d'exigences plus spécifiques. Construisez-le aussi naïvement que possible. Même si vous pensez que c'est ce que le client voudra, n'ajoutez pas de fonctionnalités de recadrage, de redimensionnement et de vignette automatiques. Laissez le client voir la version viable minimale (que vous pouvez développer beaucoup plus rapidement que la version non naïve), et les exigences commenceront à apparaître comme "C'est ce qui ne va pas avec la version actuelle." Consignez chacune de ces nouvelles exigences en tant que «bogues». Vous pouvez hiérarchiser les options les plus faciles / les plus avantageuses.

En fait, cela m'est arrivé: Formulaire de demande d'inscription avec code d'invitation spécial. L'idée était de créer un processus d'enregistrement viral où chaque nouvel utilisateur a reçu quelques invitations. J'ai passé beaucoup de temps à m'assurer que les codes étaient uniques et ne pouvaient être utilisés qu'une seule fois. J'ai également déployé beaucoup d'efforts pour rendre le processus aussi fluide que possible en rendant facultatifs les champs du prénom et du nom. Au final, les partenaires ont demandé ces changements: prénom et nom obligatoires, "code" d'inscription valable si quoi que ce soit était entré dans le champ ... soupir ~