Définition des utilisateurs cible
psouquet opened this issue · comments
Des profils d'utilisateurs ont été définis, puis étendus. (cf: utilisateurs cible)
Il faut fixer cette liste afin de pouvoir répondre à tous les besoins. Il serait peut être intéressant de fournir des exemples afin d'avoir une meilleure vue des rôles cibles.
Pour l'instant les cibles sont les suivantes :
- consultants
- exploitants
- novices
- développeurs
- MOA/métier
Pour commencer il serait bien de :
- Trouver de meilleurs termes que consultants et exploitants
- Préciser (ou donner des exemples) pour les MOA/métier
Les utilisateurs cibles devraient être définis non pas par un niveau de compétence mais par leur fonction. On ne peut pas demander à un chaudronnier de ce débrouiller avec Petals Cockpit. Un certain nombre de pré-requis de compétence sont nécessaires, par exemple la SOA.
Les utilisateurs cibles seraient:
- le développeur: en charge de développer les SU/SA,
- l'architecte: en charge de définir les topologies,
- l'exploitant, opérateur ou administrateur technique : ayant en charge le déploiement, l'administration et la supervision technique des logiciels 'Petals' (Petals ESB avec SL, BC/SE et SU/SA, Petals-Cockpit, ...),
- l'administrateur métier : en charge de superviser une partie fonctionnelle de bus,
Je résume les discussions de ce matin.
Christophe a cité des acteurs projets. On peut estimer qu'il existe un profil utilisateur pour chaque acteur, avec un prérequis, à savoir qu'ils ont suivi une formation Petals.
Ce sont tous des profils qui sont impliqués dans un projet.
Mais il existe au moins un profil qui ne rentre pas dans ce cadre : on peut l'appeler « novice Petals ». C'est par exemple quelqu'un qui teste Petals sans avoir suivi de formation Petals, soit pour le tester seul dans son coin, soit pour l'évaluer (exemple : veille technique). Ce profil pourrait presque se décliner en deux, à savoir « novice Petals mais déjà habitué aux ESB » et « novice Petals et novice sur les ESB ». Nous pouvons éliminer cette deuxième déclinaison en disant qu'elle ne correspond pas à notre cible. La première l'est : on les voit parfois arriver en formation.
Ce profil additionnel (« novice Petals ») peut nécessiter certains ajustements. Ce sont les mêmes écrans pour tout le monde, mais il doivent être évalués pour chaque type d'utilisateur. Cela peut impacter par exemple l'utilisation de cadre informatifs, d'infobulles, ou encore l'intitulé des labels (connecteurs VS. Binding Component, moteur VS. Service Engine, etc). Ce sujet peut être abordé de manière plus large, puisque la question du vocabulaire (et donc des labels) se retrouve aussi dans la documentation. Même si en tant que développeur, on sait qu'il y a des BC et des SE, doit-on continuer d'utiliser ces termes dans la documentation utilisateur ? Est-ce que cela n'allonge pas la courbe d'apprentissage de Petals ? Y compris pour des gens déjà expérimentés avec d'autres ESB ?
Je pense qu'on peut valider les utilisateurs cible de Christophe:
développeur: en charge de développer les SU/SA
architecte: en charge de définir les topologies
opérateur de production : ayant en charge le déploiement, l'administration et la supervision technique des logiciels 'Petals' (Petals ESB avec SL, BC/SE et SU/SA, Petals-Cockpit, ...)
administrateur métier : en charge de superviser une partie fonctionnelle de bus
Le novice n'est pas une cible à proprement parler, petals cockpit et ses fonctionnalités s'adressent à des utilisateurs compétents connaissant les principes d'un ESB et la terminologie de Petals. Parallèlement à cela, un soin particulier peut être apporté à l'accessibilité à des fins de formation, d'apprentissage ou de demonstration.
Ces modifications facilitant l'accès à cockpit (et pétals en général) seront traités au cas par cas avec une priorité de l'ordre du "nice to have".
Ca convient à tout le monde ?
Je reste convaincu que vous n'avez pas saisi la notion de profil d'utilisateur. Mais bon, peu importe, allons de l'avant... 😔
Le novice n'est pas une cible à proprement parler, petals cockpit et ses fonctionnalités s'adressent à
des utilisateurs compétents connaissant les principes d'un ESB et la terminologie de Petals.
Les termes peuvent se lire dans la documentation.
Connaître les principes d'un ESB, c'est déjà plus compliqué. Au-delà d'un nom, un profil inclut aussi une description. Poser comme prérequis qu'il « travaille sur une problématique au niveau Système d'Information » et « qu'il (ou elle) a lu dans la documentation de Petals ce qu'est un composant (moteur et connecteur), une unité de service (SU) et une archive de déploiement (SA) » est tout à fait plausible. On pourrait ajouter qu'il « utilise Cockpit et Petals dans le cadre d'une évaluation et qu'il est à la fois développeur, architecte, etc ». Mais il les assure dans un cadre et avec des objectifs qui diffèrent de ceux d'un projet.
Après, admettons et oublions le novice, sur le papier.
OK pour clore ce ticket avec la conclusion que tu proposes.
Je fais un petit aparté sur le contexte Petals, qui me semble important.
Et sur pourquoi il ne faut pas sous-estimer l'importance du côté "novice".
- Quand on tape "ESB open source" sur Google, Petals n'est même pas sur la première page.
- Sur LinkedIn, si je cherche "ServiceMix", j'ai 4 000 personnes qui l'ont mis dans leur CV. A peine une centaine pour "Petals ESB".
- Je rappelle aussi que Linagora assure du support sur la concurrence (comme Service Mix, entre autres).
Conclusion intermédiaire mais cruelle : Petals fonctionne super bien, mais énormément de choses dans le projet le font paraître vieillot, ce n'est pas le plus simple à utiliser, et sa place sur le marché est loin d'être extraordinaire - il est plus choisi par défaut qu'autre chose, et encore, parce que nous assurons une partie commerciale. L'enjeu du projet sur les années à venir, c'est de gagner des utilisateurs, de la visibilité, et des clients. Et dans cette optique, Cockpit sera une vitrine, majoritairement utilisée par des "novices" sur Petals, plutôt que par des gens que l'on aura formés. Donc, même si on ne met pas ce profil sur le papier, il faut garder en tête que le vivier d'utilisateurs (et donc de feedback) est de ce côté-là.
Bien entendu, tous les éléments cités plus haut ne sont pas le fait de Cockpit. Il y a, je pense, des évolutions à apporter à Petals lui-même, et à tout son écosystème. D'où l'intérêt du prochain « feu de camp », pour parler de l'avenir du projet.
Je me suis mal exprimé, je considère le novice comme un profil utilisateur mais au vue de nos discutions il ne va pas faire partie des utilisateurs cible de Cockpit.
Je vais quand même demander à Bertrand de confirmer, il me semble me souvenir qu'il voulait que Cockpit puisse être utilisé par la direction ou les commerciaux de Linagora, en plus des formations.