BPMN

Voilà que, dans le cadre d’un boulot, je commence à m’initier au Business Process Modeling Notation (BPMN). Ouais, z’allez dire qu’il était peut-être temps, ou bien carrément: «kossé ça?»… Je vais tenter de répondre aux deux commentaires!


Quoi que pas très sexy à première vue, le BPMN est un outil fort intéressant pour modéliser des processus.

Le syndrôme du «Kossé ça?»

Le BPMN, c’est ni plus ni moins une manière de codifier visuellement les processus d’affaires qui sont en place dans une organisation. Ironiquement, c’est pas quelque chose qu’on avait tendance à faire dans le cadre de nos projets. Traditionnellement, quand j’aborde un développement de site ou de système, je me colle plus à une approche comme le User centered Design (UCD).

Généralement, tout designer qui se respecte fait quelque chose qui se rapproche de près ou de loin à du UCD, étant donné notre formation. Comment? on tente de comprendre les processus, les besoins, les volontés et les limitations liés à l’utilisation d’un produit. Je ne suis pas certifié en la matière, mais plutôt un autodidacte, donc pas un spécialiste à proprement parler. Alors, que fait le BPMN là dedans?

Le BPMN permet de codifier visuellement (et textuellement) les processus d’affaires d’une entité, ainsi d’avoir un diagramme qui explique comment sont faites les choses par étape, un workflow, en bon français. Je dirais que c’est un bon complément à une approche centrée utilisateur car ça vient compléter l’analyse que l’on fait du besoin.

Pourquoi maintenant?

On a eu droit à une petite présentation d’introduction au BPMN au bureau et ça m’a accroché. J’ai tout de suite trouvé un lien direct avec le boulot de Web designer. Nous devons à tout moment modéliser des processus et on utilisait parfois tant bien que mal le UML. Encore une fois, j’ai appris sur le tas et, dans ce cas, j’ai toujours trouvé ça laborieux. BPMN est nettement plus près de mes besoins et connaissances!

Il est certain que le BPMN n’est pas la panacée, mais disons que c’est un outil de plus dans notre arsenal.

Ok, on fait ça comment?

C’est assez simple. Si ça vous intéresse, je vous invite à aller chercher l’aide mémoire (qui s’apparente à un cheat sheet) de BPMN. En parallèle, vous pouvez vous initier par l’utilisation d’un outil fort simple comme Aris Express.

Bon, l’outil est simple, mais difficile à installer dans un environnement comme celui de mon bureau!

Pour ceux qui ont Visio, des versions récentes, il y a plein de plug-ins BPMN que l’on peut installer gratuitement. Petit hic, par contre, ces plug-ins sont des banques de visuels pour les diagrammes, mais il n’y a pas les règles de positionnement (ou semblent incomplètes) telles que dans Aris Express, car des «erreurs de notification» sont possibles (des trucs que BPMN ne permet pas sont possibles dans Visio, et non dans Aris).

Sinon, il y a toujours le bon vieux papier et crayon 😉

Et alors?

Je commence à m’y mettre tranquillement. Comme bien des trucs, j’apprends sur le tas et je fais des lectures sur le sujet. Heureusement, c’est assez simple, logique et facile d’utilisation.

Si vous avez à travailler auprès de clients pour informatiser certains aspects de leurs processus, je vous conseille fortement de vous y mettre. Et si vous êtes Web Designer, il y a fort à parier que vous y trouviez votre compte.

Design centré utilisateur vs design centré sur l’activité (ACD)

Je viens de visionner une très bonne conférence de Larry Consantine où il est question du UCD (User centered design) versus le ACD (Activity centered design).

Dans le fond, diverses choses sont à retenir… entre autre que l’approche UCD a ses limites et qu’il faut éviter certains pièges, comme celui de demander à l’utilisateur ce qui désire. Bon… élémentaire, direz-vous…

Il donne de bons exemples, principalement de la firme de Redmond. Ses instantanés de Office sont assez… comiques!

Je n’ai jamais été en mesure de mettre en place une vraie approche UCD dans mon environnement de travail, par faute de moyens, de temps et une manque de compréhension de mes collègues. Qu’à cela ne tienne, il semblerait que ce que l’on fait, selon la présentation, soit plus du ACD! Amusant, non?

En fait, c’est un hybride entre les deux approches, il faudrait mettre les dossiers fonctionnels au régime et avoir une approche par prototypage plus élaborée, mais des mentalités, ça ne se change pas facilement…

Dans le fond, ce que je comprends du ACD, tel que présenté par m. Constantine, c’est qu’il est préférable de découper en petits morceaux digestibles plutôt que de tout vouloir faire dans de gros modèle obèse…

If it doesn’t fit on a single card, you’re wrong!

Trois choses à connaître: les utilisateurs, leurs tâches et leurs besoins.

Pas besoin de pousser loin la connaissance, pas besoin de faire de grosses enquêtes, il suffit de comprendre l’utilisateur et la tâche, et ce dont ils ont besoin pour effectuer la tâche. C’est tout.

Oh, et j’aime bien son histoire d’éléphant pour parler d’UML. Écoutez-le jusqu’au bout, ça vaut la peine!!

Alors, UCD? ACD? dans le fond… ce que l’on veut, c’est concevoir le meilleur système, non? pas être fidèle à un dogme!

Expérience utilisateur pour les nuls

Quel superbe article! L’expérience utilisateur pour les nuls, 101, démystifié… nommez ça comme vous voulez, mais c’est enfin un condensé de l’ensemble des théories, vues, visions et autres idées des grands penseurs de l’expérience utilisateur: Garrett, Nielsen, Morville

J’apprécie l’ensemble de l’oeuvre, mais tout particulièrement la portion où il est question de gestion de projet et de biens livrables. Effectivement, trop souvent, on se fait dire que d’implanter une approche centré utilisateur est difficile:

  • Quand doit-on faire des prototypes?
  • Quand doit-on faire des testes d’utilisabilité?
  • Quelles sont les étapes de réalisation?

L’auteur présente un schéma qui résume l’ensemble des tâches, biens livrables et les moments où on devrait faire des preuves de concept (prototypes). Juste ce petit diagramme vaut l’article au complet, pour mes besoins, du moins!

Je travaille dans un monde d’informaticiens qui sont habitués à travailler avec une méthode traditionnelle (voire rétrograde), ce qui, selon l’auteur de l’article, n’est pas adapté à une approche d’expérience utilisateur.

Effectivement, si on réfère à son avant-dernier diagramme, on voit bien vite que les méthodes dites agiles sont nettement plus adaptées!

N’allez pas croire que je renie le début de l’article, au contraire! il démystifie et explique ce qu’est le champ de travail de l’expérience utilisateur, les composantes, les théories…

Bref, pour ceux qui veulent faire comprendre que l’utilisateur est au centre du développement et que l’on devrait peut-être s’en soucier plus, histoire d’éviter des développements pathétiques d’applications telles que des SAGIR…

C’est quoi mon job?

Ce matin je présente à différents collègues et chefs d’équipe c’est quoi mon job, mon travail quotidien.

Dans les faits, mon travail consiste en deux branches principales, soit le design de sites Web et le design d’applications Web. Je traite surtout du second sujet. Pour arriver à présenter le sujet, j’ai travaillé avec MindMeister et pondu un genre de carte heuristique, une arborescence des différentes tâches quotidiennes d’un Web designer impliqué dans le développement d’applications Web.

Carte heuristique de mon travail quotidien comme Web designer en développement d'applications Web

Ça peut vous sembler ridicule comme idée, de présenter c’est quoi mon job à mon patron et mes collègues, mais il n’en n’est rien. Cet automne, je discutais avec Daniel Lafrenière qui me disait justement qu’une bonne proportion de notre travail consiste en de la formation, de l’enseignement sur ce qu’est notre rôle dans un projet. Étant donné que mon chef de service est relativement nouveau dans l’organisation, il est donc normal (voire habituel) de faire ce type de présentation.

Il y a aussi un autre facteur, soit l’organisation gouvernementale elle-même. Peut-être ceux qui sont dans un autre secteur, ou même une autre province / pays ont de la difficulté à comprendre, mais ici, tout est sectorisé, tranché au couteau. Un analyste fonctionnel fait les écrans. Un programmeur fait le code. Point. Or, la venue de Web designers dans cette structure vient brouiller les cartes légèrement.

Nous faisons tant les écrans que du code. Mais nous faisons aussi bien plus que ça, vous n’avez qu’à jeter un oeil sur la portion du haut de la carte! Tout le volet que j’ai nommé «design centré sur l’utilisateur» ou celui sur les design patterns…

Je tenais à présenter ici le schéma, je trouve que ça présente assez bien ce que je fais dans un développement de projet. À titre indicatif, les petits drapeaux rouges indiquent des «biens livrables» (ils aiment bien qu’on parle comme ça en gestion).

Séance de prototypage papier

Je travaille présentement sur un projet de développement d’un système de mission pour un organisme. Un assez gros système, avec pas mal d’intervenants et, surtout, un impact majeur sur les façons de faire actuelles.

Présentement, tout est géré «à la mitaine», «full» années ’80, avec des listes (imprimées) sorties d’un système développé dans les années ’70-’80 (via une interface en terminal genre «ambre sur noir»). Bref, plusieurs personnes qui ont à gérer plusieurs feuilles de papier et une autre qui collige le tout dans des fichiers Excel®.

La principale tâche consiste à sélectionner des éléments à mettre dans un calendrier. Simple en apparence, ces éléments, des audiences, peuvent jouer dans le temps, la durée, la salle… bref, tout un casse tête.

Nous avons trouvé une piste de solution, une méthode pour permettre une utilisabilité intéressante, tout en limitant la charge de dévelppement (le projet doit être livré assez rapidement). Bref, on avait une bonne piste, mais il fallait lui faire passer un test de réalité (reality check).

C’est alors que j’ai proposé une petite séance de prototypage papier. Nous nous sommes installés, une collègue, un anaylste et moi, dans une petite salle, avons pondu un scénario simple (fidèle à la grille que j’ai déjà présenté dans ce blog) et avons pondu notre «interface» en moins d’une heure.

Une fois le tout terminé, «l’ordinateur» a été démarré (l’analyste) et on pu procéder au test de réalité. Le pilote, l’architecte fonctionnel et, en ce moment même (en mon absence), un utilisateur du système, ont tous été confrontés au module que nous comptions intégrer dans le système.

En deux heures, conception du prototype inclus, nous avons été en mesure de réaliser des tests et s’assurer que notre idée était effectivement une bonne approche.

Le module a tellement été jugé utile qu’il sera élargi et sera intégré dans d’autre contextes du système, histoire de conserver un fonctionnement cohérent d’un bout à l’autre.

C’était un plaidoyer en faveur des prototypes basse fidélité!

Note: si je le puis, je publierai une photographie du prototype basse (très basse) fidélité éventuellement…