Méthode standard de communication et de documentation pour les analystes commerciaux, les concepteurs et les développeurs
J'ai travaillé sur un projet personnel pour normaliser la façon dont les analystes commerciaux, les concepteurs et les développeurs communiquent dans les projets les problèmes et les solutions qu'ils doivent résoudre. Même si UX Design a été question de trouver un équilibre viable entre les entreprises, la technologie et les personnes (n'hésitez pas à insérer votre diagramme Venn préféré ici), je n'ai pas trouvé de moyen commun pour les analystes, les concepteurs et les développeurs de partager des informations.
Nous n'avons pas besoin d'entrer trop dans les détails sur la façon dont les concepteurs UX capturent les informations, mais il suffit de dire que nous produisons plus d'artefacts que les analystes commerciaux et les développeurs de logiciels réunis. Je tiens donc à souligner certaines des choses que les analystes commerciaux et les développeurs utilisent comme arrière-plan pour expliquer pourquoi je pose cette question.
Développeurs de logiciels
La plupart de la conception et du développement d'applications logicielles frontales semblent s'orienter vers des cadres de développement prédéfinis ou d'autres bibliothèques javascript pour le Web, par rapport à une partie de la conception d'applications dorsales ou d'entreprise qui utilise un mélange de fonctionnalités (C, C++) et les langages de programmation orientés objet (Java, C #).
Les langages de programmation orientés ou basés sur les objets essaient de modéliser des entités du monde réel afin de pouvoir reproduire numériquement les propriétés et le comportement. Ce n'est pas différent des mathématiques qui tentent de modéliser des scénarios du monde réel pour résoudre des problèmes. Bien qu'il ne soit pas limité aux langages orientés objet uniquement, UML ( nified Modeling Language ) est un moyen standard de capturer des informations de manière standard pour modéliser l'espace de problème et aider à développer une solution de programmation.
Fait intéressant, il y a une question précédente sur le choix du langage de programmation et de l'expérience utilisateur également, mais traitant de quelque chose de légèrement différent: choix des langages de programmation et de l'expérience utilisateur
Analystes d'affaires
Traditionnellement, la Notation de modélisation de processus métier (BPMN) a été utilisée pour spécifier les processus métier dans un modèle de processus métier. Mais comme nous le savons, l'environnement commercial actuel tend largement vers un marché axé sur l'expérience utilisateur et, par conséquent, de nombreux produits et services se concentrent principalement sur l'élément `` personnes '', et cela se reflète également dans la façon dont la dernière version du langage BPMN (2.0 ) a été utilisé.
Étant donné qu'il existe déjà des conventions dans la programmation orientée objet comme UML et BPMN dans l'analyse commerciale, pourquoi n'y a-t-il pas un moyen standardisé pour les analystes commerciaux, les concepteurs et les développeurs de communiquer le problème et la solution sur lesquels ils travaillent? Ou existe-t-il réellement des exemples d'UML, de BPMN ou d'une autre convention qui ont été utilisés avec succès?
Question - Existe-t-il une norme utilisée par les analystes, les concepteurs et les développeurs?
Je n'ai pas rencontré quelque chose comme ça, et la raison pour laquelle je pense que c'est le cas est une combinaison de:
- Il n'y a pas vraiment de "standard" dans la conception UX comme il en existe pour les BAs ou les devs
- Il n'y a aucun avantage à maintenir une seule norme par rapport à la gestion de trois normes différentes (car il n'y a pas de solution appropriée qui convienne aux trois), et vous vous retrouvez avec quatre au lieu d'une.
- Il y a trop de différence entre les disciplines pour justifier une norme unique
- Personne ne l'a tenté ou aucune tentative réussie n'a été faite
[~ # ~] mise à jour [~ # ~] : Je pensais que cette question récente à propos de OOP = (Programmation orientée objet) et UX Design qui a suscité beaucoup d'intérêt indique que cela vaut peut-être la peine d'être exploré davantage, d'où une deuxième prime (la première n'a pas été réclamée) est offerte.
TLDR;
BPMN 2.0 semble être un bon candidat pour une norme qui comble l'écart entre les normes plus spécialisées.
Je ne peux répondre que de mon propre point de vue, en faisant partie d'une organisation qui utilise les workflows BPMN (2.0) pour les processus automatisés et humains. Il est encore en développement mais les bénéfices sont déjà visibles. Il communique tout ce que l'entreprise représente, ce qui est excellent pour la vision globale et pour l'expérience utilisateur. Prenons par exemple une commande en cours de traitement par une machine qui est programmée pour suivre un workflow (BPM/RPA), il faut quelques minutes avant que l'utilisateur ne puisse utiliser le produit. Ce flux de travail peut également être utilisé par l'équipe de conception pour voir où (et pourquoi) le retard a lieu (et décider d'envoyer des notifications par exemple). Un autre flux de travail BPMN existe pour le parcours client de ces processus de commande qui montre ce retard et peut zoomer sur le processus automatisé si nécessaire. Il existe d'excellents documentation et outil d'édition BPMN pour cela qui, lorsqu'ils sont intégrés dans l'organisation comme le ferait un système CRM ou HRM, stimuleraient les équipes à créer les workflows qui ont besoin de transparence pour les autres équipes, et à automatiser les systèmes à l'aide de workflows. Par exemple, l'équipe de conception peut avoir un flux de travail pour les demandes de conception entrantes et toute l'entreprise sait où le trouver, comment le lire et donc comment ce processus fonctionne (et peut-être suggérer des améliorations, etc.).
Pourtant, chaque discipline a ses propres moyens spécialisés pour documenter, communiquer et automatiser les choses. BPMN ne va pas changer cela, mais il semble approprié de combler l'écart entre eux. Cela ne peut pas être dit pour (les idées de) programmation orientée objet et UML (sauf peut-être les diagrammes d'activité). Même si cela est possible, les concepts sont très orientés sur les aspects techniques et ont une courbe d'apprentissage élevée pour les personnes non techniques, il serait difficile d'obtenir un soutien.
Parce qu'il existe de nombreuses formes de documentation, à partir de votre question, je suppose que nous parlons uniquement de documenter les processus.
A Organigramme est une norme utilisée par les analystes, les concepteurs et les développeurs.
- Il est utilisé par programmeurs pour noter les algorithmes .
- Il est utilisé par concepteurs pour noter les interactions des utilisateurs .
- Il est utilisé par analyste s pour noter les processus métier .
BPMN est basé sur les organigrammes et très similaire aux diagrammes d'activités en UML. Les diagrammes BPMN et d'activité sont des extensions d'un organigramme. Il n'y a pas d'extension standard de diagramme de flux pour UX, donc les concepteurs l'étendent généralement par eux-mêmes.
Un organigramme étant davantage une chose abstraite et de haut niveau, il est utilisé avec succès pour la collaboration entre les trois rôles.