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

9

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?

Peter
la source
Tant qu'ils ne disent pas - "ce foutu morceau de # $ @ $ # aurait dû être terminé l'année dernière, qu'est-ce qui vous prend si longtemps?", Et payez à temps, c'est bon.
Coder
En réponse à votre dernière question: cela peut arriver, est-ce normal - non, si vous vous en souciez - oui, si vous essayez d'améliorer la situation - oui. Le succès du projet devrait être important pour toutes les personnes impliquées. Pour savoir comment améliorer la situation - lisez ma réponse ci-dessous.
Danny Varod
Ce serait une très bonne question pour pm.stackexchange.com, les modérateurs pensent-ils que cela devrait être déplacé?
Danny Varod
Désolé, je n'ai
Heinzi
Randall sur xkcd a un organigramme clair qui explique comment faire face aux exigences changeantes: xkcd.com/844
Jason Lewis

Réponses:

6

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.

chooban
la source
Vous l'avez bien compris: n'écrivez pas de logiciel sans exigences. Les exigences sont comme de la nourriture ... Vous pouvez manger sans que quelqu'un les cuisine, mais ce ne sera pas agréable au goût. Si la "gestion" ne met pas les exigences dans une assiette, vous devez aller dans la cuisine et commencer à cuisiner.
mattnz
1
Les exigences sont comme la nourriture? Les exigences sont comme des recettes. En fait, les exigences sont comme un menu ... Les recettes sont des algorithmes, et la nourriture est la mise en œuvre du logiciel lui-même.
Robert Harvey
Je pense que l'utilisation de cette approche aidera également le gestionnaire à croire clairement qu'il a tort lorsque des exigences contradictoires sont fournies, ce qui se produit tout le temps.
Aadi Droid
3

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. .

Daniel Pittman
la source
Le fait que les changements requis soient à mon avis mal pensés est mon plus gros problème. Il n'est pas rare que mercredi je doive changer le code que j'ai écrit lundi - c'est très frustrant pour moi. Pensez-vous que l'ajout d'un temps d'attente à chaque fonctionnalité est une bonne idée? (par exemple , nous attendre deux semaines avant de décider si nous la mettre en œuvre) Il me aiderait à gérer le temps aussi - maintenant j'ai de nouvelles exigences tous les jours sans priorité , etc.
Peter
1
Je suis sérieux: je pense que le processus ad hoc est un problème plus important que les mal pensés. Si, par exemple, le conseiller commercial travaille avec vous pour mettre à jour un document qui répertorie les décisions, il ne peut pas changer d'avis sans voir qu'il révise une décision précédente. Ajouter plus de temps sans résoudre le problème sous-jacent ne va pas aider.
Daniel Pittman
J'ai parlé à plusieurs reprises à un conseiller en affaires - pour lui, la révision de la décision précédente n'est pas un problème du tout;)
Peter
1
@Peter, l'une des choses à propos de Scrum est que vous avez défini des limites d'itération (généralement deux semaines) pendant lesquelles rien n'est changé. Cela pourrait vous convenir très bien.
Karl Bielefeldt
1
... alors, si cela se fait en toute connaissance de cause, cela modifie les exigences, et en toute connaissance de cause du coût de ce changement, ils vous paient pour accepter ces changements. ;)
Daniel Pittman
1

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.

JeffO
la source
1

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!

Cort Ammon
la source
1

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.

Dennis
la source
0

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.

Aucune chance
la source
0

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.

Danny Varod
la source