Ergonomie des Portails d’entreprise : une conception modulaire… et ludique

Posted by jc-Qualitystreet on 3 décembre 2009

Le rôle d’un portail d’entreprise est de fournir un point d’interaction unique et homogène à toutes les applications du Système d’information.

Aujourd’hui le portail d’entreprise doit répondre à de nouvelles exigences … mais seule une conception modulaire peut les satisfaire et garantir une expérience utilisateur riche et réussie.

La modularité  se mesure dans la capacité qu’ont les composants du portail d’entreprise d’être séparés et recombinés, tant d’un point de vue fonctionnel qu’ergonomique. Elle confère au portail à la fois simplicité, cohérence, flexibilité et évolutivité, attributs attendus des portails nouvelle génération.

Certes, la conception ergonomique et fonctionnelle d’un portail d’entreprise reste avant tout centrée sur l’activité des utilisateurs finaux, mais se transforme, dans une approche hautement modulaire, en un véritable jeu de construction hiérarchisé et fondé à la fois sur un système de BLOCS et de CONNECTEURS.

 DES BLOCS …

Les blocs sont de taille différente et intègrent en leur sein contenus et fonctionnalités.

Unité de base du système et intégré à la page Web, le bloc simple est l’élément dont l’utilisateur final est le plus familier. De hauteur et de largeurs variées, il se découpe en trois zones et possède :

• une zone d’en tête «Header» laissant apparaître un titre et diverses fonctionnalités, le plus souvent de contrôle du bloc (maximiser, réduire, fermer, afficher, masquer …)
• une zone centrale composée d’une grande variété de contenus (texte, tableaux, graphiques, vidéos, cartes interactive, et widgets en tout genre)
• une zone Footer, facultative, dont le traitement visuel et fonctionnel diffère très largement selon les contextes.

Les blocs simples peuvent être ou non regroupés (en Vue et/ ou en Groupe de blocs ).
Leur association donnera ensuite naissance aux pages web, qui elles-mêmes associées, constitueront les rubriques qui au final formeront le PORTAIL D’ENTREPRISE (BLOC le plus élaboré). 

ET DES CONNECTEURS

Les connecteurs permettent quant à eux d’agir et de lier les blocs entre eux. On peut les regrouper pour l’essentiel en trois catégories:

• Éléments de contrôle et d’interface : Il s’agit d’actions portant sur le bloc lui même (maximiser, réduire, fermer, désactiver et d’autres actions plus évoluées relatives à l’apparence et au positionnement), de fonctionnalités de confort (imprimer, télécharger, envoyer à un ami, créer un PDF…), de paramètres d’affichage du contenu, depuis le nombre d’items à afficher jusqu’au sélecteur de date et de produits
• Éléments de navigation : Il s’agit essentiellement des barres de navigation principale et secondaire permettant de naviguer de rubriques en rubriques et de pages en page au sein de l’arborescence. Les items de la zone « utilitaires » (affichés le plus souvent en haut de page) relèvent de cette catégorie, tout comme la navigation contextuelle (entre pages et / ou blocs), les onglets intrapage, et les différentes vues d’une même page…
• Éléments sociaux et collaboratifs : Il s’agit de fonctionnalités permettant d’engager des utilisateurs avec d’autres autour d’une thématique donnée affichée par exemple sur un bloc simple (annoter, commenter, tagger, voter, recommander…)

 Bref, choisissez, déclinez et arrangez vos blocs, liez-les par les connecteurs les plus appropriés, et surtout AMUSEZ-VOUS !

Transformation agile : comment choisir ses projets pilote ?

Posted by jc-Qualitystreet on 18 novembre 2009

Même si  de (rares) exemples d’adoption agile  « Big Bang » existent, notamment celle de Salesforce en 2007 (sans pilote mais non pas sans préparation),  je reste persuadé qu’une transformation agile réussie passe par l’expérience de deux ou trois (max.) projets Pilotes.

PROJET REEL - EQUIPE REELE : ça c’est la base, mes deux prérequis. Le projet pilote doit être représentatif même s’il reste tourné vers l’apprentissage!

NE PAS TESTER CE QUE POURRAIT DONNER l’AGILITE DANS LA VRAIE VIE ET DANS SON PROPRE CONTEXTE ORGANISATIONNEL EST SELON MOI UNE ABERRATION. C’est de surcroit se priver d’une source de connaissance et d’amélioration non négligeable (approche KAiZEN) ainsi que d’un bon levier d’accompagnement au changement.

Mais comment sélectionner les bons projets pilote ?

Voilà une question ô combien cruciale, tant ces projets seront sous le feu des projecteurs, une question que nous sommes tous amenés à nous poser et sur laquelle est revenu dernièrement  Mike Cohn, grand gourou US de l’agilité.

Ces 4 critères me vont plutôt bien :

• Durée: Le projet pilote ne doit être ni trop court (pour être crédible et source d’apprentissage) ni trop long (pour capitaliser au plus vite et adopter dans la foulée).
  Bref : Entre 2 et 5 mois (max) avec par exemple entre 4 et 7 itérations de trois semaines
  
• Taille: Le projet pilote doit pouvoir être commencé par une seule équipe (petite) colocalisée. Une équipe distribuée ou plusieurs petites équipes ajoutent une complexité inutile en phase de pilote sauf si le mode distribué est la norme dans l’organisation.
  Bref : Une seule équipe colocalisée
  
• Importance: peu d’importance, peu d’enjeux, c’est à coup sûr moins d’engagement, pas de crédibilité … Oubliez surtout les projets pour du beurre! A l’inverse, trop d’importance, c’est une trop forte pression, inutile à ce stade, qui pèsera sur les équipes. Il faut trouver le juste milieu. A cela, mon ami bloggeur Claude ajouterait sans doute la notion de «non criticité»…
  Bref: Importance moyenne, non critique mais source de valeur pour l’entreprise
  
• Sponsor: Le projet devra bénéficier d’un (business) sponsor. L’engagement et le soutien de celui-ci sont des éléments clés pour lever les éventuels obstacles ou bien communiquer. Il sera par la suite votre meilleur ambassadeur.
  Bref: Un sponsor engagé et plutôt bien placé

En résumé selon moi, un bon projet pilote pour adopter les méthodes Agiles, c’est à la fois :

1. Un projet réel

2. Avec une Equipe réelle

3. Un projet qui dure entre 2 et 5 mois (max) avec, entre 4 et 7 itérations de trois semaines

4. Un projet mené par une seule équipe, restreinte et colocalisée

5. Un projet d’une importance moyenne, non critique mais source de valeur pour l’entreprise

6. Un projet qui bénéficie d’un sponsor engagé (et bien placé )

Mais avant de mesurer, capitaliser et de s’améliorer, le plus important RESTE DE SE LANCER !

Un Backlog priorisé pour le Père Noel … Acte 2

Posted by jc-Qualitystreet on 13 novembre 2009

Noel approche et les enfants le savent, du coup voilà  à quoi j’ai eu droit le weekend dernier…

Mes enfants : « Papa … papa … pour Noel on fait le jeu des post it »
Moi : « D’accord les enfants mais cette fois on va faire un petit peu différemment … »

Car depuis ce billet « Des priorités pour le Père Noel », j’ai bien évidemment eu le temps d’améliorer le process , même si côté contraintes, c’est toujours plus ou moins la même chose :

• Le temps du Père Noel est compté
• Son traineau n’est pas extensible
• Les délais sont serrés
• La date de livraison ne peut pas bouger
• Le Père Noel a un grand nombre d’enfants à satisfaire

En outre, mes enfants, en bons Product Owner qu’ils sont, ont compris qu’ils ne pouvaient pas tout avoir (même s’ils en veulent toujours plus), et que le fait d’avoir été sage (ou non) pouvait « potentiellement » avoir un impact sur ce qu’ils allaient recevoir… d’où la nécessité pour eux de fixer des priorités !

SCRUM / XP depuis… la maison !

Ou comment nous fixons des priorités pour la lettre au Père Noel

Temps 1 (Optimisé) : Brainstorming et collecte des données
Lecture passionnée depuis quelques semaines, et recherche intensive dans plusieurs sources,  interview du petit frère et découpage des cadeaux potentiels.

Temps 2 : Initialisation du (ou des) Backlog(s)
Les images sont découpées : une enveloppe pour chaque enfant. Je colle chaque image cadeau sur 1 post it. 1 cadeau par Post it.
Le backlog est alors initié.

Temps 3 : Priorisation du (ou des) Backlog(s)
Les post it sont posés sur le sol. J’ai demandé à mes enfants de les classer par ordre de préférence « à la file indienne » : en haut, ceux dont ils ont le plus envie, les plus importants pour eux …

…..

….

Temps 4 : Affichage du (ou des) Backlog(s)
Les post it sont priorisés sur le sol. Il nous restait à trouver un petit coin de mur ou de porte pour les mettre à la verticale (management visuel…). Un peu de patafix et le tour est joué.

Pour la grande (pas trés raisonnable):

Pour le petit frère (beaucoup plus raisonnable …):

BILAN: On a passé un bon moment et  les enfants sont contents

Ma femme et moi nous chargeons de l’estimation en points-euros :)

User story : la forme c’est important !

Posted by jc-Qualitystreet on 9 novembre 2009

Les  « User Stories » sont de plus en plus utilisées sur les projets Agiles, et c’est une très bonne chose.

Leur simplicité,  leur orientation à la fois « But Utilisateur » et « Valeur Business », ainsi que le focus immédiat sur les critères d’acceptation les rendent en effet terriblement efficaces pour les projets de conception.

Une fois la règle des 3 C assimilée (Carte, Conversation et Confirmation) et les critères INVEST bien décrits, quand les équipes et le Product Owner commencent à découvrir les stories, ils me demandent souvent si le format « User Voice » doit être respecté …
Ce format c’est le fameux :

En tant que  < Rôle d’utilisateur >,
Je peux  < But >,
Si bien que  < Justification >

Un format au sein duquel,

• Le rôle représente celui qui fait l’action et qui en bénéficie
• Le but représente l’action accomplie
• La valeur Business représente les bénéfices qui se dégagent de l’action

Alors, doit-on utiliser ce format ? Ma réponse est sans équivoque OUI !

• Le format “User Voice” donne du sens à la fonctionnalité… pour qui et pourquoi l’équipe va la développer
• Il permet de se rapprocher d’une démarche expérience utilisateur, et notamment Personas. Le rôle c’est notre Persona, une vision concrète, réaliste et partagée de l’utilisateur final.
• Il est clairement orienté ACTION et BUT (démarche de conception le plus efficace)
• Il justifie toutes les fonctionnalités d’un point de vue Business, et oblige le Product Owner et les équipes à s’interroger systématiquement sur la valeur de chaque fonctionnalité

Mon conseil : Donnez un titre à la User Story (court et signifiant), et décrivez là ensuite au format « User Voice » !

Toujours plus agile - Vers de nouveaux challenges

Posted by jc-Qualitystreet on 19 octobre 2009

Une page se tourne…

puisque j’ai démissionné de mon poste de Consultant senior chez SQLI Paris.
Une expérience humaine et professionnelle enrichissante qui me conduit aujourd’hui vers de nouveaux challenges…

Un bon break d’une semaine, et c’est donc parti, début novembre, pour PLUS D’AGILITE et de CONSEILS chez Valtech Technology.