Mener des sessions de capture des besoins
L’architecte de la solution dirige généralement les sessions de capture des besoins. Le but de ces sessions vise à transformer les besoins généraux en besoins réalisables. Si le même architecte de solution était impliqué pendant la phase de pré-vente, il peut déjà comprendre les besoins des clients et les facteurs de réussite. Sinon, l’architecte de la solution doit s’assurer qu’il est bien informé avant la première session. Ces informations doivent être utilisées pour animer la discussion avec les participants.
Au fur et à mesure que vous allez acquérir de l’expérience dans la conduite de ces réunions, vous adopterez une méthodologie préférée. Soyez prêt à vous adapter aux besoins d’un projet ou d’un client particulier. Arrivez à ces sessions avec un plan, des modèles et les résultats souhaités ; cependant, évitez d’être rigide au point d’empêcher conversation, créativité et solutions.
À quoi ressemble un besoin
La manière spécifique dont un projet documente un besoin peut être spécifique à une méthodologie choisie. Cependant, dans tous les cas, les exigences doivent indiquer qui, quoi et pourquoi. Ces paramètres peuvent être capturés dans les récits utilisateur ou ils peuvent être des besoins d’éléments de campagne, mais ils doivent être testables et responsables. Un besoin sérieux tient compte des facteurs suivants :
Qui a ce besoin
Ce dont le client a besoin
Pourquoi le client fait ce qu’il fait
Les besoins ou les récits plus importants doivent être décomposés en parties gérables. Différentes méthodologies utilisent des termes différents pour ces parties, par exemple, les approches agiles les appellent généralement des épopées. Quel que soit le nom, l’architecte de la solution doit être vigilant et s’assurer que ce processus s’exécute.
Hiérarchisation
Chaque projet dispose d’une quantité limitée de temps et de ressources qui peuvent être utilisés pour mettre en œuvre les besoins. L’architecte de la solution, ainsi que l’équipe de projet et souvent le client, doivent hiérarchiser la liste de besoins/le backlog.
Du fait que les projets d’applications de gestion se prêtent bien aux déploiements incrémentiels, les équipes hiérarchisent souvent d’abord un produit minimum viable (MVP). Un MVP identifie les besoins à satisfaire pour être initialement mis en service. Ensuite, les éléments restants se retrouvent dans les futures itérations ou sprints.
L’architecte de la solution doit utiliser les principaux objectifs commerciaux identifiés pour évaluer les besoins. La priorité doit être accordée aux besoins qui aident à atteindre les objectifs. Cette approche peut également permettre d’identifier une déconnexion des principaux objectifs si vous identifiez un besoin clairement important mais qui n’aide pas à atteindre les objectifs clés.
Faisabilité
L’architecte de la solution doit évaluer les besoins pour s’assurer qu’ils sont réalisables. Recherchez les besoins qui, tout en étant attrayants, ne sont pas réalisables pour un certain nombre de raisons, telles que celles qui nécessitent :
Des données que vous ne possédez pas.
Des mises à jour d’autres systèmes qui ne sont pas possibles dans le délai d’exécution.
Pour cela, l’architecte de la solution peut se poser la question suivante : « Quels seraient les freins à la satisfaction de ces besoins ? »
Gestion des participants
Les attentes doivent être définies avant les sessions pour s’assurer que les participants concernés y assistent. Vous voulez vous assurer que vous disposez de personnes expérimentées qui comprennent les domaines cibles. Des sessions multiples, plus petites et plus courtes peuvent être plus ciblées et productives. Il est utile d’inviter différentes personnes à gérer différentes parties d’un processus, car cela vous permet d’obtenir une image complète du fonctionnement de cette partie du processus. Souvent, cette approche vous évitera d’avoir à effectuer un suivi pour combler les lacunes du fonctionnement d’un processus.
Il peut être utile d’inviter la direction à participer, car vous recevez souvent des informations plus décisives. Cependant, gardez à l’esprit que la présence d’un cadre supérieur peut avoir un effet sur la volonté de son personnel de participer. Dans de nombreux cas, le personnel sera plus silencieux et s’en remettra au cadre pour obtenir des réponses afin d’éviter de mal s’exprimer. Si vous trouvez que ce scénario se produit de manière négative, vous devrez peut-être y remédier en effectuant un suivi séparément ou en demandant au responsable de ne pas assister à toutes les sessions.
Travail de préparation avant les sessions
Avant la session, l’architecte de la solution doit essayer d’obtenir autant d’informations que possible sur la solution actuelle et ses processus. Ces informations peuvent être étudiées à l’avance pour permettre de formuler des questions pouvant être utilisées pour faire avancer la discussion. La préparation peut également permettre aux participants de rassembler des documents et des exemples à apporter aux sessions.
N’oubliez pas non plus de rassembler ce que l’équipe de prévente a collecté. Évitez de faire recommencer les clients et répéter les mêmes informations qui ont déjà été traitées. Déterminez si des enregistrements de démonstration ont été effectués pour vous permettre d’être plus informé.
Insister sur la clarté des besoins
Souvent, l’énoncé des besoins initiaux d’un utilisateur professionnel ne sera pas le véritable besoin. Il faudra un travail d’investigation de la part de l’architecte de la solution pour guider l’utilisateur ou la communication avec les autres pour arriver au besoin réel. L’architecte de la solution doit apprendre à demander « Pourquoi ? » sans contrarier l’utilisateur ou lui faire croire
qu’il est incapable de faire son travail. La vraie raison des questions est de comprendre le problème central afin que la meilleure solution puisse être conçue.
La préparation de questions courantes peut vous aider à obtenir des informations :
Pouvez-vous décrire une journée de la vie de ce processus ?
Qui d’autre est impliqué dans ce processus ?
D’où proviennent ces informations ?
Pouvez-vous m’aider à comprendre pourquoi ce processus est nécessaire ?
Si vous commencez par des questions ouvertes pour connaître les exigences et les besoins réels, vous pouvez vous diriger vers une question fermée pour confirmer votre compréhension. L’exemple suivant est un simple échange entre un architecte de solution et des utilisateurs professionnels :
Utilisateur : Nous avons besoin d’un rapport imprimé de toutes les transactions échues au cours des 30 derniers jours.
Architecte de solution : Qui utilise le rapport ?
Utilisateur : Il est utilisé par les responsables.
Architecte de solution : Madame ou monsieur le responsable, comment utilisez-vous le rapport ? Doit-il s’agir d’un rapport, ou la vraie demande est-elle simplement de consulter les transactions échues du mois dernier ?
Responsable : Nous n’examinons le rapport qu’une fois par mois, ce serait donc bien.
Architecte de solution : Que recherchez-vous lorsque vous examinez les données ?
Responsable : Nous recherchons toute transaction supérieure à 50 000 dollars, puis nous procédons à un examen plus approfondi.
Architecte de solution : Serait-il donc utile que le système ne présente que les transactions échues de plus de 50 000 dollars pour révision ?
Responsable : Oui ce serait parfait.
Besoin révisé : Les responsables doivent examiner les transactions échues de plus de 50 000 dollars par mois.
Si l’architecte de la solution ne s’était pas suffisamment renseigné, l’équipe aurait créé un rapport papier. Demandez toujours « Pourquoi ? » pour arriver à un point où vous sentez que vous comprenez vraiment le besoin.
Résolution de besoins contradictoires
Fréquemment, différents utilisateurs professionnels créent des besoins conflictuels. Il est essentiel que le client dispose de quelqu’un de décisionnaire. L’architecte de la solution peut aider à guider les parties vers une conclusion en proposant des idées et des compromis ; cependant, il ne doit pas s’impliquer dans la politique de l’entreprise.
Défendre votre point de vue
Un architecte de solution doit être capable de repousser respectueusement des besoins. Une partie de cette responsabilité consiste à communiquer clairement la vision de la solution que vous avez élaborée et à aider le client à voir comment cette vision lui permettra d’atteindre ses objectifs. Les architectes de nouvelles solutions rencontrent souvent des problèmes lors de cette phase en se montrant condescendants. Assurez-vous que lorsque vous dirigez le client vers votre vision, vous évitez de montrer du dédain concernant leurs idées.
Exercice : planification de vos sessions de capture des besoins
Passez en revue les équipes de la banque Woodgrove. Déterminez laquelle de ces équipes vous regrouperiez pour la collecte des besoins. Décidez quelles équipes vous ne regrouperiez pas pour la collecte des besoins. Expliquez pourquoi vous prendriez ces décisions.