Comment déplacer un client des maquettes d'interface utilisateur vers un ensemble d'exigences réelles?

Supposons que l'on vous donne une maquette de 25 écrans des états visuels de votre application. L'attente est que cela nous suffit pour être sûrs que nous pouvons le développer et le remettre à la partie prenante ou au client d'origine en tant qu'application terminée, et ils seront satisfaits. Naturellement, vous allez finir par poser à nouveau aux parties prenantes de nombreuses questions qui ont été utilisées pour créer l'interface utilisateur, ce qui est un gaspillage.

Cependant, j'ai constaté à maintes reprises que cela ne suffit pas, au cours du développement de l'application, les exigences deviennent floues du fait que nous répliquons une interface et, en fin de compte, le client n'est pas aussi satisfait qu'il le semblait lorsque nous leur avons demandé toutes les informations pour créer l'interface utilisateur.

Je ne sais tout simplement pas quoi demander d'autre, j'ai essayé d'être précis et de demander des exigences et une compréhension de l'objectif global, mais je ne sais pas ce que je dois demander. Si je commence juste maintenant, beaucoup de temps va être gaspillé à hacher toutes les informations qui mènent à l'interface utilisateur et pendant cette phase, de nombreuses raisons importantes pour le client à l'origine seront perdues.

Comment puis-je faire comprendre aux gens que nous ne pouvons pas verrouiller les exigences basées sur des maquettes d'interface utilisateur en demandant quelque chose de concret qu'ils peuvent créer pour moi?

Par quoi commenceriez-vous idéalement afin d'exécuter correctement la tâche de développement d'une application pour les utilisateurs finaux?

D'autres choses dont vous pourriez avoir besoin sont:

• Cas d'utilisation ou descriptions de workflow: simplement parce que vous savez à quoi ressemble un écran, savez-vous comment les mauvaises entrées sont gérées? Savez-vous comment faire la transition entre les écrans dans TOUS les cas? Vous pouvez également inclure la gestion des erreurs ici.

• Description du système de haut niveau: quelque chose explique à quoi sert tout le système pour ces 25 écrans et à quoi ils servent.

• Modèle de données: est-il possible d'inférer un modèle de données à partir de ces écrans? Existe-t-il un modèle de données à utiliser ou êtes-vous libre de concevoir le vôtre pour faire le travail?

• Exigences techniques: les technologies spécifiques doivent-elles être utilisées pour des raisons de licence ou d'intégration?

• Exigences de performance: s'il y a un écran de recherche, y a-t-il une attente de ce qui peut être recherché et à quelle vitesse la réponse devrait être? Qu'en est-il des réponses pour d'autres types d'actions? Certains d'entre eux peuvent-ils ou doivent-ils être asynchrones (l'utilisateur soumet le travail et revient plus tard)?

• Exigences de sécurité: l'application stocke-t-elle des données potentiellement sensibles / personnelles et, dans l'affirmative, quels types de données et que faut-il faire pour les sécuriser? Avez-vous besoin de respecter un certain niveau de conformité (comme la conformité PCI pour effectuer des paiements par carte de crédit)?

En outre, existe-t-il des connaissances particulières dans le domaine des affaires pour lesquelles vous pourriez avoir besoin de vous aider? Certaines industries comme l'assurance, la banque, les dossiers médicaux, etc. ont toutes sortes de logiques commerciales complexes. De tels projets ne devraient pas être tentés sans l'aide d'un analyste d'entreprise qui connaît ce domaine. Mais s'il ne s'agit que d'un panier / site d'informations pour des widgets génériques, vous n'aurez peut-être pas besoin d'un tel membre de l'équipe.

Comment faire comprendre aux gens que les simulations d'interface utilisateur ne suffisent pas pour créer un programme de travail:

Je gérerais cela avec une analogie. Puisque je suis un peu fou de la voiture, je vais dans cette voie.

"Imaginez que je ne connais rien aux voitures. Vous me donnez quelques photos d'une Ferrari. Un couple de l'extérieur et une de l'intérieur de la voiture (prises depuis le siège du conducteur pour que je puisse voir les commandes de la voiture). Maintenant, vous me demandez pour vous construire une Ferrari. Je reviens avec une chose qui ressemble aux photos et qui a toutes les commandes. Malheureusement, ces commandes ne sont reliées à rien parce que (puisque je ne sais rien sur les voitures) je ne sais pas ce que ces les commandes devraient faire. Je ne peux même pas faire une supposition parce que je ne sais même pas ce que les voitures sont censées faire. Alors nous avons une conversation comme celle-ci:

"Alors, que fait une Ferrari?" "Cela me permet de me déplacer rapidement d'un point à un autre." "OK. Alors qu'est-ce que ce truc de cercle fait?" "Oh, c'est le volant. En le tournant, vous pouvez changer la direction dans laquelle pointent les roues à l'extérieur de la voiture. Cela changera la façon dont la voiture se déplace." "D'accord, et qu'en est-il de cette pédale?" "C'est la pédale d'accélérateur. Elle accélère le moteur, ce qui accélère la voiture." ... quelques minutes plus tard ... "D'accord, alors de quel type de moteur a-t-il besoin? J'ai fait des recherches et j'ai trouvé des moteurs pour des voiturettes de golf et d'autres pour des voitures de sport. Lequel devrais-je utiliser?" ... etc. ..."

Ensuite, vous pouvez expliquer l'analogie. Remettre aux développeurs des maquettes d'écrans ne leur dit que ce à quoi il ressemble, pas ce qu'il fait. Les développeurs doivent savoir quel problème le programme résout ou comment il sera utilisé (comme savoir ce que fait une voiture, il est plus facile de concevoir la voiture et de faire des suppositions éclairées sur ce que les choses devraient faire). Ils doivent savoir quels types de choses ils sont censés utiliser (par exemple, le moteur de la voiturette de golf par rapport au moteur de la voiture de sport) et quelles sont les autres exigences non liées à l'interface utilisateur (la voiture devrait aller vite).

Choses que je demanderais:

Description générale / de haut niveau du problème

Cas d'utilisation / user stories

Exigences de performance

Technologies / plate-forme requises (Windows, Linux, Web)

Tout ce que FrustratedWithForms a dans sa réponse

Quelque chose à l'effet de 80% des efforts de développement va vers 20% des cas d'utilisation marginaux. Les captures d'écran ne vous informeront pas sur les cas d'utilisation, vous serez donc dans le noir pendant 80% de votre développement actif.

Il est bon que vous essayiez d'en savoir plus et que vous essayiez de communiquer à quel point il est important que le client soit plus impliqué dans les exigences du projet, mais s'il ne le fait pas, il configure le projet en échec, et ce n'est pas de ta faute.

La majorité des projets logiciels échouent car le client n'est pas suffisamment impliqué dans le processus de développement logiciel. Ce n'est pas un nouveau problème et ce n'est certainement pas un mystère pour expliquer pourquoi les projets logiciels échouent, mais cela se produit continuellement dans l'industrie à cause de situations comme celle-ci.

Vous ne pouvez pas simplement jeter un filet d'informations sur un mur et vous attendre à retrouver tous vos espoirs et vos rêves sous la forme d'un progiciel. Le développement logiciel ne fonctionne tout simplement pas de cette façon. Que vous soyez un magasin Agile ou Waterfall, une solide direction client est nécessaire à la réussite ou à l'échec d'un projet.

Une chose que les gens semblent oublier de demander, à quoi serviront les données après leur saisie? Avez-vous besoin de rapports? Avez-vous besoin de générer un bon de livraison et de l'envoyer à l'entrepôt pour l'expédition, etc. Si des données sont utilisées pour prendre des décisions de gestion et des rapports sont nécessaires, cela peut changer la conception de la base de données. Cela peut également ajouter beaucoup de temps au développement en fonction de la complexité des rapports.

Vous devez également vous assurer qu'il existe un chemin pour chaque décision possible. Donc, si quelque chose doit être approuvé par la direction - que faites-vous si est refusé et que faites-vous s'il est approuvé. S'il n'est pas approuvé ou refusé dans X laps de temps, que se passe-t-il alors? S'ils sélectionnent un produit et qu'il est en rupture de stock, qu'advient-il de la commande? Ce genre de questions.

Vous devez également savoir s'il existe des limites spécifiques concernant les données à mettre dans chaque champ. Y a-t-il des valeurs requises. D'où voulez-vous les obtenir? Comment seront-ils mis à jour? Vous devez savoir comment gérer les erreurs. Vous devez savoir si la base de données doit faire l'objet d'un audit ou si vous devez être en mesure de recréer des données à partir d'une perspective historique (retour à ces rapports embêtants).

Une autre chose que je vois se produire est que les applications peuvent être conçues juste pour arriver à la version sans tenir compte de la façon dont les données seront conservées par la suite. Avez-vous besoin d'une page d'administration pour vous assurer qu'ils peuvent mettre à jour leurs listes de valeurs requises? Avez-vous besoin d'envoyer des données dans les deux sens vers d'autres systèmes. Comment allez-vous obtenir les données initiales dans la base de données?

Personnellement, je demanderais une réunion d'une demi-journée à une journée avec le client pour parcourir sa conception de l'interface utilisateur et ses objectifs et m'assurer que tout est aligné.

Commencez simplement. Faites-leur comprendre qu'avec les informations qui vous ont été fournies, aucun de ces écrans ne ferait quoi que ce soit . Aucun détail sur les cas d'utilisation, le mauvais comportement d'entrée, etc. Cela ne fonctionnera tout simplement pas. Expliquer une généralisation brutale est plus facile que d'expliquer les détails, car le point ne peut pas être perdu. Essayer de leur donner une justification plus compliquée pour expliquer pourquoi les maquettes d'écran ne suffisent pas leur donne la possibilité de chicaner vos définitions au lieu de reconnaître le problème. Demandez-leur d'imaginer que le développeur principal ne parlait pas anglais (ou quelle que soit la langue dans laquelle les écrans sont présentés). Demandez ensuite à quel point cette situation est différente d'un développeur qui n'a aucune connaissancede leurs processus d'affaires. Construisez-vous ensuite à l'exemple le plus réaliste de vous-mêmes, qui avez des connaissances, mais avez raison de croire qu'il n'est pas approprié de décider de leur logique métier pour eux.

Les personnes qui n'ont pas développé de logiciel ne savent pas ce que les développeurs de logiciels doivent savoir. On ne peut pas attendre d'eux qu'ils produisent eux-mêmes les spécifications des exigences et les cas d'utilisation. Vous devez appliquer des techniques d' élicitation des exigences pour obtenir les informations dont vous avez besoin. Travaillez avec le client (et, espérons-le, un échantillon d'utilisateurs de divers rôles) pour déterminer ce dont ils ont besoin ou ce qu'ils veulent. Les techniques courantes à cet effet sont les entretiens et / ou l'observation des utilisateurs, l'identification des cas d'utilisation et des histoires d'utilisateurs, et le prototypage.

Je recommanderais fortement d'appliquer des techniques de développement itératives et incrémentielles dans ce cas, car vous avez des exigences vagues, incomplètes ou mal comprises. Regardez les différentes méthodologies agiles ainsi que le modèle en spirale pour aborder la planification du cycle de vie.

Commencez par atteindre l'objectif commercial qui anime le développement de ce logiciel. Interviewez le client et les utilisateurs, et si vous le pouvez, regardez-les au travail. Essayez de déterminer quel problème ils essaient de résoudre. Découvrez quels outils ils utilisent actuellement et comment ils les utilisent afin que vous puissiez améliorer leur façon de faire actuelle. Profitez de cette occasion pour apprendre le domaine et sa langue - il deviendra infiniment plus facile de communiquer si les développeurs de logiciels et les clients / utilisateurs parlent tous la même langue (et ne s'attendent pas à ce que les clients / utilisateurs parlent en termes de logiciels).

Une fois que vous comprenez quels sont les objectifs, vous pouvez commencer à travailler avec les maquettes de conception d'interface utilisateur que vous avez et "rétroconcevoir" les cas d'utilisation et les user stories à partir d'eux en fonction de la façon dont les différents écrans s'assemblent. Le format de la user story conviendrait probablement bien à un public non technique. Le format de As a <user type>, I want to <action> so that <reason>fonctionne en termes de faire en sorte que les développeurs et les clients / utilisateurs parlent la même langue. Une fois que vous pouvez vous lancer dans les histoires d'utilisateurs, j'adopterais une approche de prototypage pour le développement.

Je pense que j'aborderais cela avec l'utilisation du prototypage. Vous pouvez aborder cela dans une perspective de prototypage évolutif ou de prototypage jetable , mais je considérerais d'abord une approche de prototypage évolutionnaire. Commencez par les user stories avec lesquelles vous êtes le plus à l'aise et que vous avez validées, et commencez à les mettre en œuvre. Au fur et à mesure que vous les implémentez, obtenez des commentaires du client et développez de nouvelles histoires d'utilisateurs, utilisez des cas et résolvez les malentendus.

De plus, ne pensez pas à cela comme "implémentant une interface utilisateur avec des fonctionnalités en dessous". Au lieu de cela, pensez-y comme de fines tranches verticales. N'implémentez pas toute l'interface utilisateur en même temps et ne vous inquiétez pas des fonctionnalités. Utilisez plutôt les maquettes de l'interface utilisateur pour identifier les fonctionnalités et autres exigences, puis implémentez une tranche verticale de l'interface utilisateur vers la logique métier et le stockage des données. Répétez cette opération pour chaque tranche verticale. N'hésitez pas à faire des suggestions pour améliorer l'interface utilisateur en fonction des exigences et des principes d'utilisation.

Je recommanderais de lire deux livres de Karl Wiegers - Software Requirements et More About Software Requirements . Je pense que ceux-ci vous aideront avec l'ingénierie des exigences et les meilleures pratiques dans ce domaine.

Eh bien, c'est une référence de départ embarrassante, mais Wikipedia pourrait être un endroit pour vous et les utilisateurs pour commencer. Le fait qu'il y ait une entrée à ce sujet pourrait aider à les convaincre que c'est un vrai problème, pas que vous soyez une douleur.

Plus précisément, êtes-vous simplement déconcerté par ce que fait l'application, même après avoir parcouru les maquettes? Si oui, admettez-le et essayez d'expliquer que vous n'avez aucune idée des données que chaque formulaire devrait afficher, ni d'où elles proviendraient, proviennent-elles d'autres écrans ou de données externes?

Si vous avez une idée, essayez de trouver des exemples de choses que vous ne savez pas comment faire ("la liste des modèles à sélectionner sera-t-elle une liste globale ou y en aura-t-il par l'utilisateur, ou autre chose? pas par l'utilisateur, dois-je laisser deux personnes le modifier en même temps? Que doit montrer l'interface utilisateur si quelqu'un d'autre le modifie? Y a-t-il un écran pour cela? Une fois que quelqu'un a utilisé un modèle pour tous les modèles utilisés, puis le modèle est modifié ce changement doit-il être propagé à ce qu'ils ont fait avec le modèle? ").

Expliquez clairement qu'avec votre niveau actuel de connaissances, vous devrez répondre aux questions toutes les 90 secondes environ pendant le reste du cycle de développement, et que la plupart du temps, vous ne pourrez pas continuer à travailler jusqu'à ce que vous obteniez une réponse. Le but devrait être de montrer clairement pourquoi avoir une sorte de processus rendra tout plus facile. Mentionnez également que le contrôle qualité aura besoin des mêmes informations que vous, il sera donc plus facile de tout écrire afin qu'elles soient disponibles pour tout le monde et que personne n'oublie quoi que ce soit.

Il peut être utile de mentionner qu'une partie du code que vous écrivez affecte plus d'un écran à la fois, donc si vous obtenez autant de réponses à l'avance que possible, il pourrait être plus facile d'écrire ce code de manière appropriée et de ne pas avoir à le changer plus tard.

Si vous ne parvenez toujours pas à obtenir les exigences et que vous ne savez vraiment pas comment procéder, envoyez des e-mails chaque fois que vous avez besoin de plus d'informations (c'est-à-dire les exigences) et si vous ne pouvez pas continuer à travailler sans ces informations, indiquez clairement que vous sont, malheureusement, incapables de continuer à travailler, car le code que vous devez écrire sera très différent selon la ou les réponses à vos questions. Ne vous plaignez pas, faites-leur juste savoir très professionnellement que vous ne pouvez pas écrire le programme avant de savoir ce qu'il doit faire.

Vous devez connaître les limites et les plages pour chaque champ de l'application. Par exemple, si le champ est numéro de téléphone, s'attendent-ils à ce que vous gériez +1? Quels champs sont obligatoires? Que veulent-ils que l'application fasse si l'utilisateur tape "abc" dans le champ # de téléphone? Les 25 écrans sont-ils tous dans l'ordre dans lequel tous les utilisateurs doivent procéder?

Sinon, créez tout simplement sous forme de champs de texte et vous avez terminé! Voulez-vous parier que cela passera comme un ballon en plomb?