Comment convaincre un client non technique que ses spécifications d'application doivent être simplifiées?

Souvent, je suis confronté à la situation où un nouveau client vient me voir avec une application qui a littéralement des centaines de fonctionnalités inutiles et il est assez clair que les choses doivent être considérablement simplifiées pour que le projet ait une chance de réussir. Comment convaincre le client d'adopter une approche de produit minimum viable (MVP) plus simple et de simplifier?

Éditer:

Donc, la meilleure réponse actuelle est de fournir au client une estimation de temps / coût pour l'énorme application. Je n'aime pas trop cette réponse car elle ne résout pas le vrai problème de cette situation. Et c'est - c'est une mauvaise pratique de spécifier une application massive, puis d'essayer de la construire dès le départ. Je me sens beaucoup plus à l'aise au départ pour construire une petite fondation MVP simple. Et puis ajouter de petites fonctionnalités à cette fondation une par une. Alors, comment puis-je convaincre le client d'approcher le logiciel de construction de cette manière?

En estimant combien d'argent / temps cela coûtera pour faire ces centaines de fonctionnalités de haute qualité. Très, très peu de clients mettront leur argent là où se trouve leur bouche.

Deux mots: User Stories.

Je l' ai appris que le meilleur moyen d'aider un client Get A Clue® est d'avoir les me parler à travers une histoire d'utilisateur pour chaque fonction ou d'une page qu'ils veulent. Plusieurs choses se produisent, notamment:

1. Ils doivent penser à ce que la page / fonctionnalité est censée faire.
2. Alors que vous demandez de plus en plus de détails ("et puis? ... et ensuite? ..."), ils commencent à comprendre que le tout ne va pas voir le jour en faisant voler Magic Space Monkeys ™ et faire au cours du week-end.
3. Ils deviennent de véritables partenaires dans le processus de création. Ce qui signifie qu'ils comprendront pourquoi le fait de changer d'avis sur quelque chose qui est déjà terminé à 80% entraînera a) un retard dans le calendrier et b) une augmentation des coûts.

Sérieusement. Les témoignages d'utilisateurs par les propriétaires sont l'un des meilleurs outils que je connaisse pour apporter au moins un peu de raison au processus.

Tout en discutant du coût et de la durée de production, demandez un classement des exigences («doit avoir», «devrait avoir» et «agréable à avoir») afin que l'ensemble minimum viable de fonctionnalités essentielles du produit soit "must have" dans la version 1, puis placez le reste des exigences dans des ensembles de backlogs qui pourraient être réalisés sous forme de sprints après la première version. Avec un peu de chance, ceux qui ne sont pas essentiels "agréables à avoir" iront à l'arrière du pack et au moment où vous arriverez à ces sprints, de nouveaux plus essentiels (d'après l'expérience réelle avec le produit) auront flotté vers le haut.

Le client doit comprendre que vous tenez compte du coût de son entreprise et de l'importance d'obtenir un produit rapidement et que vous ne rejetez pas directement son "bien d'avoir" en le mettant dans l'arriéré.

Modifier pour répondre à la modification OP: Pour convaincre le client pourquoi c'est une bonne idée de publier tôt un produit minimum viable, expliquer que tant que le produit n'est pas utilisé par de vrais utilisateurs, il est difficile de savoir s'il réussira (en particulier en termes de convivialité). Si le client hésite à proposer un produit précoce à l'ensemble de sa base d'utilisateurs, recommandez de faire une "version bêta limitée" où il n'est disponible que pour un sous-ensemble ciblé de leurs clients. Dites-leur que le revers de cette approche est un cycle de développement long et coûteux avec une détermination tardive que le produit est inutilisable. 37 Signals a produit quelques bonnes références à ce sujet: devenir réel et retravailler . The Getting Real est disponible gratuitement sur le Web.

La cause principale de votre frustration face à la situation est probablement la perception et les termes trompeurs / erronés utilisés par le client. Le client ne vient généralement pas vers vous avec une liste d' exigences , mais une liste de souhaits de tout ce à quoi il pourrait penser pourrait lui être utile. Ce ne sont pas toutes des exigences, car le client n'a pas encore passé le temps de vraiment penser si chaque fonctionnalité est vraiment requise .

Ce n'est pas nécessairement toujours un problème

Si votre client a l'argent pour toutes ces fonctionnalités et est prêt à s'en séparer, et que vous ne vous souciez pas vraiment de résoudre les problèmes réels et réels du client, cela pourrait être un projet très lucratif. Cela arrive, juste très, très rarement, et pour la plupart des développeurs, c'est un travail qui tue l'âme parce que vous pouvez sentir à l'avance que le projet ne réussira pas pour le client à la fin (même s'il est financièrement réussi pour vous en tant que développeur). C'est également un risque élevé, car vous risquez de vous retrouver avec un projet à coût fixe avec beaucoup d'incertitude, et il est vraiment difficile de mal évaluer le risque sur les grands projets.

Et si c'est un problème?

Supposons que vous n'êtes pas dans cette situation rare. Dans ce cas, vous souhaiterez combler les deux principales lacunes de la liste de souhaits comme indiqué:

1. Il est peu probable que le client ait une idée correcte des coûts de développement d'une telle liste d'exigences, il est donc peu probable d'obtenir le contrat pour le montant d'argent dont vous avez réellement besoin pour le faire.
2. Il est peu probable que cette liste de souhaits décrive avec précision et succinctement le véritable problème que le client a et veut résoudre.

D'après mon expérience, vous devez aborder 2 pour corriger 1. L'exploration du problème réel signifie que vous, le développeur, avez maintenant les informations nécessaires pour faire des sauts créatifs dans la résolution du problème d'une manière à laquelle le client lui-même n'a jamais pensé. Ces solutions sont susceptibles d'être beaucoup moins chères et plus rapides que la mise en œuvre de la liste de souhaits complète.

Comment corrigez-vous cela?
Comme Matthew Flynn le dit dans sa réponse - commencez par faire en sorte que le client priorise les exigences. Ce n'est pas toujours facile, mais forcez-les à le faire. Si nécessaire, utilisez la phrase "Si quelqu'un tenait une arme à feu sur votre tête, quelle seule exigence maintiendriez-vous?". Au cours de ce processus, vous constaterez souvent que le client n'a pas vraiment une idée très claire de la signification des exigences individuelles. Dans ce cas, faites ce que Peter Rowell suggère et demandez au client de parcourir les User Stories. Vous et le client commencerez à mieux comprendre le problème et les exigences, puis vous pourrez revenir à la priorisation. Répétez ces étapes aussi souvent que nécessaire jusqu'à ce que vous vous sentiez à l'aise d'en savoir suffisamment pour résoudre le problème du client .

Comment cela répond-il à la question du développement d'une solution? Une fois que vous avez une liste d'exigences priorisée, vous disposez des informations dont vous avez besoin pour suggérer un processus de développement incrémentiel à votre client. Vous n'avez pas à l'appeler Agile, mais vous pouvez suggérer de diviser le contrat en petits morceaux pour chaque exigence (ou ensemble indivisible d'exigences) et de les livrer un par un avec validation par le client. Ou vous pouvez tout faire et utiliser les nombreuses ressources disponibles en ligne et hors ligne pour convaincre le client qu'il est dans son intérêt de coopérer dans l'un des styles de développement Agile. Dans tous les cas, vous pouvez fournir votre proposition de contrat / projet sous une forme qui suggère clairement ces blocs de construction d'exigences par ordre de priorité, chacun avec son propre coût et sa propre conclusion. Tenez cette carotte devant le client,

J'essaierais d'abord d'expliquer à ce moment-là que leurs exigences ne sont pas réalistes et je leur présenterais un ensemble d'exigences de compteur. Expliquez que cela résoudra leur problème plus simplement et plus rapidement, donc avec moins de coûts et de risques. N'essayez pas d'en faire une discussion technique, le client s'en fiche. Le client se soucie d'obtenir un bon produit à temps, de résoudre son analyse de rentabilisation. Si le client ne bouge pas, acceptez le contrat et faites le travail, ou rejetez et expliquez au client pourquoi vous ne pouvez pas prendre la responsabilité du projet sous cette forme.

Semblable à ce que les autres ont suggéré, mais légèrement différent, je suggérerais que tout ce que le client peut être valide, mais qu'ils doivent PRIORISER. Quel élément doit être fait en premier. Quel élément doit être fait en deuxième. Plus important encore, si vous manquez de temps, quels éléments seront les moins douloureux à ne pas avoir. Priorisez chaque élément de 1 à 732 (ou autre) et complétez-les dans cet ordre.

Un exemple historique d'une application qui s'est retrouvée au-dessus du budget et en retard en raison d'exigences excessives est le fichier de cas virtuel du FBI. Il était destiné à remplacer plusieurs dizaines d'applications existantes, et elles devaient toutes fonctionner complètement, à la fois, lors du basculement. Le projet a finalement été annulé. Ce qui aurait été couronné de succès était d’architecturer un cadre et de remplacer progressivement les applications individuelles dans le nouveau système. Au lieu de cela, la politique et les luttes intestines conduisent chaque partie prenante de l'application à déclarer que son application était la plus importante, et tout le monde a choisi ses spécifications avec des "incontournables" de toutes les fonctionnalités qu'ils souhaitaient ajouter à l'application existante. À la fin, le volume de demandes de changement écrites chaque jour dépassait la quantité de code réellement écrite chaque jour.

J'ai vu le travail "Je dois tout avoir" fonctionner dans 2 cas. Dans l'un, le grand client financier (utilisant toutes sortes de cascades), a fait remplacer 40 systèmes différents (notre entreprise en a fait l'un des 40) et les a rendus opérationnels d'un seul coup. Les tests d'intégration et la communication étaient des problèmes majeurs. Mon estimation est qu'ils ont brûlé environ 100 000 $ / jour en conférence téléphonique (lorsque vous comptez le taux de facturation de tout le monde sur les appels). Dans les deux cas, il a fallu de solides négociateurs pour dresser une liste de ce qui allait être livré, puis cloué les pieds de tout le monde au sol. Il n'y a eu aucun déplacement des poteaux de but, aucune renégociation. Les deux emplois ont fini à l'heure et selon les spécifications. L'un était largement supérieur au budget, l'autre respectait le budget. Pour cela, vous avez besoin de très bons chefs de projet qui savent ce que leurs équipes peuvent offrir (le genre qui peut dire que la fonctionnalité Q prend 3.

En l'absence des excellents PM, négociateurs et métriques, je conseillerais de pousser le client vers des livraisons incrémentielles. S'ils veulent toujours la brique d'or entière à la fois, ils pourraient être mieux servis en les aidant à trouver un autre consultant. Parfois, la meilleure réponse est «nous ne pouvons pas vous aider».

Réponse courte: j'écouterais mon client et je trouverais l'approche à mi-chemin avec lui.

Je proposerais d'écouter le client et en fonction de son budget et de son timing, de diviser le projet en phases (release, release2, etc.).

Ensuite, vous pouvez continuer l'estimation de chaque phase du livrable, du budget et de la hiérarchisation des fonctionnalités requises que l'application doit fournir.

Ainsi, définir la portée du travail et les livrables est la voie à suivre :)

Comme d'autres réponses l'indiquent, la priorisation est très importante. Un moyen pratique de le faire consiste à utiliser la méthode MoSCoW . Mais vous voudrez peut-être commencer par diviser la liste entière, sinon la liste des fonctionnalités elle-même vous posera des problèmes de compréhension (ou à votre client) :)

À côté de cela, vous avez le problème de regarder le problème dans son ensemble. Vous pouvez probablement résoudre ce problème en vous asseyant avec votre client et en suivant les étapes suivantes:

• Parcourez le monde à travers les fonctionnalités et en distiller les catégories
• Prioriser (en utilisant MoSCoW) les catégories, et peut-être définir une hiérarchie (une catégorie de base avec des fonctionnalités par défaut, des catégories pour les sujets principaux, des catégories pour des variations spécifiques des sujets principaux). Cela pourrait modifier les catégories que vous avez définies à l'étape précédente (grâce à de nouvelles informations).
• Parcourez chaque fonctionnalité une par une et affectez-les à une catégorie
• Prioriser (en utilisant MoSCoW) les éléments dans les catégories top-x.

Cela donnera une vue descendante agréable et condensée de vos fonctionnalités demandées, et vous donnera un guidon pour définir différentes itérations pour commencer avec une base et l'étendre avec d'autres fonctionnalités.