• Accueil / Salesforce / Comment rassembler les…
, Comment rassembler les exigences (et dire « non »)<span class="wtr-time-wrap after-title"><span class="wtr-time-number">1</span> minutes de lecture</span>

Comment rassembler les exigences (et dire « non »)1 minutes de lecture


Savoir rassembler les exigences est une compétence clé dans tout rôle Salesforce, en particulier pour les analystes commerciaux, les administrateurs Salesforce, les architectes et les consultants. Pour étendre votre organisation Salesforce d’une manière qui servira votre organisation à long terme, vous devez collecter les exigences pour les projets Salesforce majeurs, jusqu’aux mises à jour opérationnelles mineures.

Ce sont ces exigences des parties prenantes, lorsqu’elles ne font pas partie d’un projet formel, qui peuvent souvent « passer à travers », submerger l’équipe de mise en œuvre et compromettre l’intégrité de l’organisation elle-même (par exemple en générant une dette technique). Aussi dur que cela puisse paraître, parfois repousser, dire « non », est la bonne réponse.

, Comment rassembler les exigences (et dire « non »)<span class="wtr-time-wrap after-title"><span class="wtr-time-number">1</span> minutes de lecture</span>

De toute évidence, il y a du tact et du jugement en jeu. En comprenant 5 techniques de base, un administrateur peut apprendre l’art de dire « non » tout en établissant des exigences commerciales à toute épreuve.

Le processus de collecte des exigences est simple, n’est-ce pas ?

Cela devrait être simple, non? Vous vous asseyez, sirotez un café glacé et écoutez quelqu’un expliquer ce qu’il veut pendant une demi-heure, puis retournez à votre bureau. Si le processus de collecte des exigences est si simple, alors pourquoi tant d’entre nous ont-ils autant de difficultés à bien le faire ? Aussi cliché que cela puisse paraître, la raison en est que la collecte des exigences est une tâche qui peut être facile à faire mais difficile à bien faire.

Dans un rôle Salesforce, rendre les gens heureux est gratifiant. L’automatisation d’un processus ou la réponse à une demande peut conduire à un e-mail de félicitations ou à un cri. Ce désir peut amener les individus les plus juniors et même les plus âgés à éviter de reculer.

Comme je l’ai mentionné, il y a du tact et du jugement en jeu. Les utilisateurs finaux doivent vous considérer comme un partenaire, pas comme un obstacle, et il y a un équilibre à trouver. Continuer à refuser ou à repousser les demandes à l’extrême peut amener les membres de l’équipe à aller chercher leurs solutions ailleurs.

1. Testez les hypothèses, renforcez les besoins de l’entreprise

Bien que la réunion puisse se dérouler rapidement, le fait de noter rapidement les exigences et de partir causera plus de problèmes qu’il n’en résoudra. Poser de bonnes questions peut mettre à l’épreuve ces hypothèses et renforcer le besoin de l’entreprise. Cela peut prendre plusieurs formes telles que : Qu’arrive-t-il à ce processus lorsqu’une opportunité se retire au stade de la vente ? Avons-nous besoin de plus de membres qu’un simple Sales Leadership ?

Le but ici n’est pas de bloquer les utilisateurs finaux et de refuser leur demande, mais de les amener à réfléchir et à élargir leur réflexion. Sans dire « non » mot pour mot, vous commencez à prendre des mesures pour contester et repousser de manière collaborative. Si une personne est incapable d’exprimer son point de vue et d’ajouter de la clarté, cela peut être le signe qu’elle doit affiner davantage sa demande.

La réalisation de cet exercice ajoute le tendon et la fibre nécessaires à ce qui serait autrement des exigences creuses. Une fois définis, pensez à ajouter ces raffinements dans la description de votre code ou des outils d’automatisation de processus pour permettre aux autres administrateurs d’être au courant.

2. Soyez transparent avec les efforts que les changements nécessiteront

Chaque administrateur a eu une expérience similaire lors de la collecte des exigences. Pendant que l’utilisateur parle, vous êtes peut-être déjà en train de définir des solutions simultanément. Finalement, cet utilisateur dira quelque chose qui arrêtera votre construction architecturale. Bien que sourire et hocher la tête soient des réactions courantes, il peut parfois être utile d’être franc avec votre utilisateur final.

Même si ce n’est pas immédiat, revenir en arrière et dire quelque chose comme : Toutes ces exigences sont bonnes, mais sur les 15 changements, cette configuration spécifique va prendre 10 fois plus de temps que tous les autres changements combinés. Si cela est essentiel à la mission, heureux de l’appliquer, mais voici quelques solutions alternatives. En traitant votre équipe comme des adultes, ils commenceront à mieux comprendre le processus, ce qui conduira à des solutions plus efficaces.

3. Méfiez-vous des « cas extrêmes »

Maintenant que nous avons parlé du « comment » de repousser, commençons à discuter du « quand » pour décider d’employer certaines techniques.

Lorsque vous posez des questions sur un processus métier et les mots ‘parfois’ ou alors ‘pas toujours’ commencer à ramper, il est peut-être temps de faire une pause et d’analyser les drapeaux rouges potentiels. Ces exceptions/cas extrêmes peuvent nuire à l’automatisation des processus ou aux projets de développement et entraîner une spirale de problèmes.

Faire de votre mieux pour faire une pause et pousser sur ces termes peut vous éviter des heures de maux de tête sur la route. L’élimination de ces poches d’ambiguïté peut conduire à des processus améliorés. Le résultat peut augmenter la complexité pour prendre en charge les branches dans la logique métier ou introduire des étapes manuelles pour réduire la configuration.

4. Équilibrer les demandes de plusieurs parties prenantes

Maintenant que nous nous sentons bien dans les composants « comment » et « quand », nous pouvons explorer ‘Pourquoi’ un peu plus.

Il y a de fortes chances que vos projets impliquent des parties prenantes de plusieurs équipes. Ainsi, même si vous obtenez des exigences importantes, claires et concises d’un groupe de parties prenantes, cela pourrait potentiellement effacer les processus d’une autre équipe. Cette équipe devrait être en mesure d’informer ou même de refuser une construction potentielle.

Un exemple peut être un processus qui libère du temps de dix minutes pour un acteur financier mais entraîne des heures de travail supplémentaires pour un membre de l’équipe de vente.

Pour parvenir à cette harmonie et permettre la discussion, les parties prenantes de toutes les équipes doivent être incluses.

Avant une réunion, idéalement, passez en revue un mémoire ou obtenez un résumé général de ce que les exigences vont impliquer. Essayez d’inclure les parties prenantes des équipes concernées dans la réunion ou faites de votre mieux pour communiquer après la réunion et dans plusieurs formats par la suite, qu’il s’agisse de conversations informelles, de plusieurs e-mails, de newsletters, etc.

Selon la structure de votre organisation, il peut y avoir des mécanismes plus formels en place, mais pensez à la structure opérationnelle. Définissons-nous les principales parties prenantes de chaque groupe ? Sont-ils en pleine connaissance des implications ? Existe-t-il une documentation de flux de travail qui a été développée pour informer le processus actuel ainsi que le processus révisé ? Ces types de stratégies de communication aident les utilisateurs finaux à permettre à chacun de quitter une réunion avec une compréhension et un intérêt égaux dans ces changements organisationnels.

, Comment rassembler les exigences (et dire « non »)<span class="wtr-time-wrap after-title"><span class="wtr-time-number">1</span> minutes de lecture</span>

5. La documentation est-elle cohérente ?

Comment pouvons-nous arriver à « non » plus rapidement ? La réponse réside dans la documentation et le processus.

Si un administrateur fait partie d’une petite équipe, il peut documenter les besoins de l’entreprise pour une version qu’il supervisera du début à la fin. Si l’équipe est plus importante, les exigences peuvent être utilisées par d’autres analystes ou développeurs pour les informer de ce qu’il faut construire. Cela pourrait signifier que vous soumettez de la documentation avec de nombreux autres administrateurs simultanément. Si les destinataires doivent passer au crible les nombreuses touches personnelles de la structure, du ton, de la terminologie, etc. du document, vous allez perdre du temps et retarder la mise en service pour vos utilisateurs finaux.

Idéalement, l’équipe devrait développer un format modélisé pour éviter le potentiel de collecte d’exigences fragmentées. La collaboration entre les administrateurs, les développeurs, les architectes et les individus à travers les opérations devrait éclairer la mise en page et la conception de ce modèle d’admission. Le travail initial portera ses fruits car cela permettra aux utilisateurs finaux de préremplir certains documents avant la réunion et permettra une montée en puissance accélérée des membres de l’équipe plus juniors.

, Comment rassembler les exigences (et dire « non »)<span class="wtr-time-wrap after-title"><span class="wtr-time-number">1</span> minutes de lecture</span>

Résumé

Si un administrateur dit simplement « oui » à chaque demande, il ne remplit pas ses fonctions de véritable responsable Salesforce. Pour une gratification à court terme, ils mettent simplement en œuvre des changements sans se soucier d’une stratégie ou d’une vision. En incluant davantage le « non » dans votre vocabulaire avec tact, un administrateur peut équilibrer et améliorer ceux qui l’entourent en incitant les utilisateurs finaux à réfléchir et à prendre en compte leurs besoins commerciaux.



Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Vous utilisez Pardot depuis un certain temps mais vous n'êtes pas sûr d'en
exploiter tout le potentiel

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer