Comment gérer les changements fréquents des exigences?

Je fais face à une situation assez stressante (à mon avis) dans mon lieu de travail actuel.

Nous avons commencé à développer un nouveau projet, à obtenir certaines exigences, à le mettre en œuvre, puis à montrer à quelqu'un que vous pouvez appeler un «conseiller commercial» (personne qui connaît les exigences commerciales mais n'utilisera pas le programme). Cette personne est censée évaluer l'application du point de vue des clients, la tester, etc.

Voici à quoi ressemble le «processus»:

1. Le conseiller d'affaires parle le soir avec mon patron pendant une heure ou deux sur Windows Messenger
2. le lendemain, je reçois un e-mail avec une copie de cette conversation. Je suis censé choisir des tâches à partir de cela, vérifier les bogues signalés (qui ne sont souvent pas des bogues, juste de mauvais tests et oublier les établissements passés)
3. J'implémente des changements, l'implémentation est acceptée et puis dans une semaine ou deux, il s'avère que ce n'est pas ce qu'ils veulent (ils ont parlé avec un client potentiel qui a vu un logiciel pendant 5 minutes et il a suggéré des changements) - Je dois faire de nouveaux changements

Ne vous méprenez pas, je comprends que parfois les exigences changent. Ce qui me dérange, c'est la fréquence à laquelle le changement se produit sur mon lieu de travail et la facilité avec laquelle la «gestion» donne deux nouvelles exigences ou parfois des changements fondamentaux aux fonctionnalités existantes.

En même temps, nous travaillons sur des délais serrés et j'ai l'impression qu'au lieu d'aller de l'avant avec notre logiciel, nous courons des cercles.

Je demande conseil auprès de vous sur la manière de faire face à cette situation? Est-ce une situation normale et je suis juste hypersensible à ce sujet?

Si possible, prenez la conversation qui vous est envoyée par e-mail et transformez-la en document d'exigences. Énumérez les tâches que vous pouvez en tirer et triez-les selon ce que vous percevez comme la priorité et attribuez une estimation à chacune. Demandez ensuite quelles fonctionnalités ils souhaitent pour la prochaine version.

Fondamentalement, forcez une sorte de boucle de rétroaction où la direction sait ce que vous allez créer. Écrivez vos propres documents d'exigences jusqu'à ce qu'ils reçoivent le message.

Cartes d'histoire

Je pense que votre situation est bien adaptée pour introduire des user stories . Ils sont vraiment utiles pour fournir à votre gestionnaire un moyen continu et interactif de définir des priorités et il peut même les jeter lorsqu'il reviendra sur l'idée une semaine plus tard et réalisera que cela ne fonctionne pas.

Dans le monde réel, les exigences changent régulièrement. Du côté positif, vous le découvrez avant de terminer la construction du logiciel et de l'expédier - vous avez un cycle de rétroaction serré de l'utilisateur direct du logiciel, ce qui est en fait génial.

Il semble que le plus gros problème ici soit la manière très ponctuelle de gérer le changement. Vous avez ce que Agile / Scrum considère comme un «propriétaire de produit», qui donne des commentaires, mais le processus est mal documenté et mal pensé.

Vous voudrez probablement regarder les modèles dans Scrum , et leur vision de ce qu'est un propriétaire de produit efficace , pour aider à informer vos prochaines étapes.

Donc, au lieu d'avoir ce processus ad-hoc, visez à passer à un monde où vous avez une relation plus étroite et plus utile avec le "conseiller commercial", et où tout le monde est sur la même longueur d'onde à propos des résultats des changements dont ils discutent. .

Votre processus actuel rend trop facile pour ces personnes de simplement réfléchir à des idées sans aucune réserve pour les ressources et l'argent que cela consommera. S'ils veulent toutes ces fonctionnalités, ils ont besoin d'un "skin dans le jeu".

Prenez cet e-mail de la conversation et mettez-le dans une sorte d'application de suivi des fonctionnalités / bogues, même s'il ne s'agit que d'une feuille de calcul. Renvoyez les nouveaux ajouts au conseiller en affaires et demandez-lui de signer chaque élément ou d'apporter des corrections. Parallèlement à l'approbation, ils doivent établir des priorités (lesquelles voulez-vous en premier?).

Une fois qu'ils ont approuvé, renvoyez-leur votre calendrier lorsque les éléments seront terminés pour les tests et demandez-leur de s'engager à un moment pour effectuer les tests / l'approbation de l'achèvement.

Je sais que la création de ce type de documentation n'est pas la raison pour laquelle vous êtes devenu programmeur, mais vous pouvez soit risquer de jeter ces listes, soit continuer à jeter votre code durement gagné.

Repousser. Les responsables doivent voir combien ces demandes coûtent.

Les changements d'exigences ne sont pas toujours mauvais. L'essentiel est de se souvenir de votre client. Votre patron est probablement votre client dans ce cas. Vous devez informer votre patron que vous pensez que ces changements constants des exigences limitent votre capacité à produire le produit qui lui est le plus utile. Il est tout à fait possible que l'entreprise profite de votre réaction constante aux changements. Si c'est le cas, c'est leur modèle commercial, et vous ne faites rien de mal, bien que je recommande de courir pour les collines dans ce cas!

Les personnes frustrées par les changements d'exigences sont souvent appréciées par la façon dont elles gèrent chaque changement. Cette mesure du «nombre de modifications suffisamment gérées» est probablement la source de votre véritable problème. Envisagez de discuter de meilleures mesures avec votre patron. Lorsque je suis confronté à des exigences en constante évolution, je m'efforce d'écrire du contenu qui me permette de m'adapter à des exigences en constante évolution. Au lieu d'exécuter une simulation et d'analyser les données tous les jours, j'écrirai des outils qui rendent le processus d'exécution de la simulation et de l'analyse des données moins coûteux, et récolteront les fruits au fil du temps. Si c'est encore trop fou, je pourrais même écrire un outil pour écrire des outils!

Votre processus peut bénéficier de certains principes agiles, comme les itérations verrouillées. Je pense qu'une semaine est raisonnable avec des changements aussi rapides que vous décrivez. 2 semaines pourraient éventuellement fonctionner mieux.

Une fois que les exigences suffisamment importantes ont été identifiées, demandez à la personne qui occupe le Project Ownerrôle de les signer et de les verrouiller pendant une période d'une semaine pendant que vous les construisez. Allouez suffisamment de travail pour vous-même où vous serez occupé et laissez les pouvoirs connaître votre allocation. c'est-à-dire que si par semaine vous pouvez produire un travail de 16 points et que vous avez 16 points de travail, alors vous êtes pleinement utilisé pour cette semaine. (Le concept de points provient d'un flux de travail agile)

Si des changements surviennent au milieu de la semaine, prononcez ces mots magiques:

Je peux le faire [cette nouvelle fonctionnalité], [ce nouveau changement], [etc.], mais qu'est-ce que vous voulez pas fait ?

C'est-à-dire que vous êtes une ressource limitée, vous ne pouvez accepter que trop de travail. Si un nouvel élément de travail arrive, vous êtes autorisé à être la ressource limitée que vous êtes et à attribuer des points au nouvel élément et à supprimer / modifier d'autres éléments à la place de ce nouveau changement entrant. Redéfinissez la priorité de votre liste d'itérations avec le propriétaire du projet et vous devriez mieux gérer le changement.

Si les exigences changent plus fréquemment que cela, vous devrez peut-être négocier plus de stabilité dans votre environnement.

L'expression «les exigences changent» est parfois utilisée abusivement par les informaticiens. Ce que vous décrivez est en effet un changement d'exigences, mais cela peut être dû à un ou plusieurs des éléments suivants (je ne connais pas suffisamment votre cas, donc les éléments suivants peuvent ou non s'appliquer):

1. L'ambition de la direction de faire plaisir à l'utilisateur final le plus rapidement possible et de progresser rapidement.

2. Absence d'analyse détaillée. N'oubliez pas que les analystes doivent poser des questions sur pourquoi non seulement quoi. Les analystes doivent "penser" avec l'utilisateur final à une "solution" non seulement prendre des commandes.

3. Absence de processus officiel de vérification et de confirmation des exigences, suivi de l'approbation.

4. Demander à la personne incorrecte d'exécuter un ou plusieurs rôles pour lesquels elle n'est pas nécessairement formée, comme les rôles Business Analyst ou Systems Analyst.

5. Prototypage limité.

6. L'hypothèse / la peur que cela doit être fait rapidement et sinon son informatique à blâmer.

À moins que l'on aborde correctement tout ce qui précède, la relation entre l'informatique et l'entreprise / l'utilisateur final sera stressante. Veuillez noter que cela ne signifie pas que les points ci-dessus sont concluants. Il existe d'autres facteurs qui conduisent à des situations stressantes similaires à votre situation, mais je pense que cette liste devrait vous aider à démarrer.

Je pense que vous devriez aborder cela sous plusieurs directions:

1. Demandez à toutes les parties prenantes (y compris toute l'équipe de développement) de rencontrer (hors ligne / en ligne) le conseiller commercial et d'essayer de comprendre le domaine, la vision, puis de réfléchir ensemble aux exigences.

2. Formaliser les exigences / récits d'utilisateurs, en notant chacun:
   a. Priorité (urgence / importance)
   b. Maturité (dans quelle mesure elle est bien définie - comprise et acceptée par la majorité des parties prenantes *)
   c. Complexité (estimation approximative)
   
   Lors du choix de l'exigence / de l'utilisateur sur lequel travailler, tenir compte des trois facteurs. Si l'exigence a une faible maturité, ajoutez une mission de recherche avant celle-ci, dans laquelle vous contactez tous les intervenants, étudiez le raisonnement derrière l'exigence et mieux définir l'exigence (écrire des cas d'utilisation et / ou créer des filaires et les présenter) avant d'agir dessus.

3. Essayez de penser à quelques pas avant de concevoir avant chaque implémentation - concevez une architecture flexible qui a de la place pour s'adapter aux changements.

4. Essayez d'adapter un processus de développement agile, par exemple SCRUM ou Kanban - cela vous fournira une boîte à outils pour développer un produit avec des exigences changeantes.

Vous devriez également envisager de demander aux modérateurs de déplacer cette question vers PM.stackexchange.com (en la signalant) car même si cette question tient ici, elle y irait mieux.

(*) Parties prenantes pour accord: business, marketing, gestion de projet, développement et QA.