La MOA pragmatique du SI (Business Analysis, Analyse d'Entreprise, Maitrise d'Ouvrage)

Aller au contenu | Aller au menu | Aller à la recherche

mercredi, octobre 2 2013

Ecrire un livre via Leanpub - Maîtrise d'Ouvrage du Système d'Information en pratique

Attention, auto-promo à l'intérieur de ce billet :) !

Cela faisait longtemps que je n'avais pas écrit sur ce blog ! Je vais essayer de contribuer plus régulièrement.

J'ai profité de cette absence sur ce blog pour co-écrire un livre sur la maitrise d'ouvrage du SI. Pour cela, nous avons utilisé la plateforme Leanpub qui permet d'écrire un ouvrage de manière collaborative, en suivant les principes du Lean. L'idée c'est donc d'écrire une première version du livre que l'on publie assez tôt afin d'obtenir un retour rapide des lecteurs.

Donc si vous êtes intéressés par les sujets évoqués sur ce blog, vous aimerez ce livre qui présente des techniques très utiles pour réussir en tant que MOA. Il y est notamment question de : gestion des exigences, valeur métier, Minimum Viable Product, vision, business case, modélisation UML, story-board, maquette, user story, Behavior Driven Development, Acceptance Tests Driven Development, conduite du changement, rétrospective... En téléchargeant ce livre maintenant, vous pourrez l'avoir pour 0€ et en plus vous pourrez influencer son contenu en nous faisant vos commentaires sur ce qu'il faut étoffer, ajouter ou corriger. 

Si vous souhaitez plus d'information, c'est par ici :


lundi, juin 11 2012

Comment la MOA peut-elle obtenir l'adhésion des utilisateurs sans vendre son âme au diable ?

L'accompagnement du changement (plutôt que la conduite) n'est pas l'épilogue d'un projet. C'est une démarche qui s'exécute sur toute la durée d'un projet. Comment la MOA peut-elle obtenir l'adhésion des utilisateurs sans vendre son âme au diable ?

Définir sa stratégie, ses objectifs

En fonction de la dimension du changement (à l'échelle d'une application, d'un process, d'une organisation, de l'entreprise) et en fonction de la criticité de l'adhésion des utilisateurs finaux pour la réussite du projet, les exigences de l'accompagnement du changement ne seront pas les mêmes. Il est donc important de bien identifier la nature du changement pour identifier la bonne stratégie à adopter. Le déploiement worldwide d'une nouvelle application métier dans le but d'améliorer la qualité d'un processus ou la modification d'un processus métier pour optimiser les coûts avec des réductions d'effectifs ne seront pas gérés de la même manière.

Impliquer les utilisateurs en amont

L'accompagnement du changement ne se fait pas à la fin du projet, comme une cerise sur le gâteau. C'est un facteur clé de la réussite qui se négocie dès le début du projet. Plus les utilisateurs sont inclus tôt dans le projet, moins vous risquez le syndrome du "NIH". Pour cela, certains utilisateurs clés, appelés parfois les "champions", doivent être embarqués afin de convaincre les autres utilisateurs de l'intérêt du changement. Ces "champions" aiment le risque et prendre des responsabilités supplémentaires ou ont un intérêt personnel à ce que le projet réussisse. Il ne faut pas passer à côté de cette opportunité, un "champion" charismatique permettra de convaincre bien plus de monde que la meilleure des présentations par une équipe projet. 

Utiliser les technologies du 21ème siècle

Pour la phase de formation, pensez à utiliser les outils les plus efficaces : visioconférences, webinar... En ces temps difficiles, oubliez La Première et les grands hôtels. 

Enfin, conservez une fois de plus votre bon sens et vos qualités humaines. Je citerai cet utilisateur qui m'a dit aujourd'hui : "Vous facilitez la communication entre les systèmes, c'est très bien, mais n'oubliez pas de faciliter la vie des humains !". Heureusement, même si je ne suis pas parfait, je suis humain et comprend ses problématiques... tant qu'on ne me remplace pas par un avatar robotique humanoïde...

jeudi, août 25 2011

Comment la MOA peut dépasser la dépression post projet ?

Le baby blues survient entre le deuxième et le quatrième jour après l'accouchement, dure en moyenne deux jours. Une fois l'euphorie de l'aboutissement passée, et les premières mises en pratiques approximatives, on y est. Le projet est terminé. Alors que le stress redescend, comment dépasser la dépression post projet ?

 

Identifiez les réussites et les échecs de ce projet

Indépendamment de l'aspect affectif, cherchez à identifier les réussites et les échecs de ce projet. Pour la MOA, en premier lieu il faut identifier si les exigences ont été remplies. Si vous avez les outils adéquats, vous pouvez analyser les caractéristiques des exigences : ont-elles été volatiles ? combien ont été créées en cours de projet ? est-ce que les priorités ont beaucoup changé ? Et comme les parents trouvent toujours leur progéniture merveilleuse, vous pouvez essayer d'obtenir la perception des utilisateurs sur la réussite du projet. C'est moins quantitatif, mais finalement beaucoup plus objectif ! Attention, si vous recherchez le retour des utilisateurs, attendez que s'écoule quelques jours ou semaines. Les projets débutant en production avec quelques couacs (problèmes lors du déploiement, forte résistance au changement...) peuvent se transformer en réussite totale une fois les tensions des premiers jours passées.

Obtenez des retours sur votre travail

Profitez en également pour identifier comment vous avez participé à ces réussites et ces échecs. N'hésitez pas à solliciter vos sponsors ou vos responsables pour avoir un retour sur votre travail. Quand le projet a atterri, il est plus facile d'obtenir un retour objectif car les différentes parties prenantes ont tous les éléments pour juger votre travail, et ils auront la distance nécessaire. Pensez également à faire un point sur vos méthodes de travail et les techniques de la MOA. Avez vous trop voulu formaliser ? Ou au contraire avez-vous manqué de formalisme ? Étiez-vous à l'aise avec la méthode employée sur le projet ?

Capitalisez sur votre travail

Vous avez réalisé un manuel utilisateur de qualité ? Vous avez amélioré la description de vos use case ? N'hésitez pas à reprendre vos documents afin d'en faire des templates ou des exemples en corrigeant leurs défauts. Cela vous permettra d'une part d'améliorer la qualité de vos livrables au fil du temps et d'autre part de gagner du temps sur votre prochain projet. Vous pouvez ensuite partager vos templates avec les autres MOA de votre société.

Cherchez les projets suivants

Faites un point avec vos sponsors habituels pour voir quels sont les besoins stratégiques qui ne sont pas encore couverts. Faites le tour des utilisateurs également, afin d'identifier des problèmes opérationnels qui ne seraient pas encore remontés.  Le meilleur moyen de travailler sur un projet intéressant, c'est encore d'aller le chercher.

 

La fin d'un projet n'est jamais simple. C'est souvent une phase fortement chargée pour la MOA qui doit gérer la conduite du changement. Il faut être très présent. Et assez rapidement, tout s'arrête. Il faut alors savoir gérer la transition avant le ou les projets suivants. Soyez fort, on passe tous par là, surtout lorsque le projet est une réussite. Bizarrement, plus le projet est un échec, moins on a de mal à s'en défaire...


jeudi, mars 17 2011

MOA et Scrum : Quels retours d'expériences ?

Cela fait quelques mois que je travaille sur un projet utilisant la méthodologie Scrum. Cette méthodologie dite "agile" bouleverse le travail de la MOA dans les organisations classiques où les rôles MOA et MOE sont gérés par des personnes distinctes, voire des équipes distinctes. Après vous avoir expliqué quelques bases sur l'agilité et la MOA dans un précédent billet (Le rôle de MOA est-il compatible avec les méthodes agiles ?), je me propose ici simplement de vous livrer mon retour d'expérience sur l'impact d'une telle méthodologie pour la MOA.

Ce qu'on a dit sur le rôle de la MOA dans les méthodes agiles...

On a beaucoup parlé des méthodes agiles depuis quelques années. Et on peut avoir l'impression par exemple que Scrum a été conçu par des développeurs, pour des développeurs. Je dis cela car la communauté agile s'est très vite rendue compte du problème que posait la MOA pour mettre en œuvre Scrum :

Scrum, Agilité et Rock'n roll : Se passer de la MOA ou se passer de l'agilité ?

J'ai dit à N. qu'une meilleure solution serait de supprimer la MOA. MOA et MOE c'est fait pour les travaux publics, pas pour le développement de logiciel. C'est le bon moment en période de crise pour éliminer les gaspillages...

Bon, c'était une boutade, on ne peut pas supprimer la MOA du jour au lendemain.

OCTO Talks! : Installer Scrum sur une organisation existante

L’autre population qui est mise en porte-à-faux lors du déploiement de SCRUM : la MOA. Là aussi, le rôle de MOA tel que nous le connaissons est en grande partie absorbé par l’équipe : clarification du besoin, qualification des demandes, tests, … Quelle position la MOA peut-elle alors adopter pour continuer à apporter de la valeur à un projet ?

La solution en laquelle nous croyons aujourd’hui est que la MOA soit partie intégrante de l’équipe.

Et ce n'est pas seulement un problème franco-français ou un problème de la métaphore MOA/MOE issue du BTP. C'est simplement que les méthodes agiles veulent mettre le client au cœur du process de développement d'un système informatique, en limitant les gaspillages : documentation inutile, intermédiaires superflus entre le développeur et le client. Ces sujets touchent principalement les activités de la MOA.

... et ce que j'ai expérimenté : User stories et storyboards,

Sur mon projet actuel, nous avons donc mis en place Scrum. En tant que MOA, on m'a dit : "Maintenant, tu rédiges des user stories.". Ok. J'ai en fait pris le rôle de Product owner, délégué. Avant cela, j'ai quand même fait une étude préalable qui a abouti sur la rédaction d'un cahier des charges chargé d'une étude de l'existant et d'une liste d'exigences. J'ai ensuite décliné ces exigences en user stories. Ces user stories sont un outil très pratique pour planifier les sprints. Au départ j'ai simplement accompagné ces user stories d'un storyboard et de maquettes réalisées via Axure.

quelques spécifications fonctionnelles "old school"

Pas suffisant. J'ai rapidement bifurqué vers une spécification fonctionnelle détaillée ! Aïe, de la documentation ? Mais pourquoi ? C'était impossible d'avoir une vision globale du système sans cela. Et la traçabilité n'était pas suffisante, j'avais toujours l'impression d'aller à l'encontre d'un choix de conception fonctionnel fait plus tôt dans le projet, faute de me rappeler des motifs de ce choix. De plus il était très difficile de discuter avec les projets non Scrum sans un document de spécifications fonctionnelles. J'ai donc décidé de maintenir ce document, enrichi au fil des sprints en essayant d'avoir toujours un ou deux sprints d'avance. De plus certaines réglementations demandent que le système d'information soit documenté, donc impossible de passer outre une documentation fonctionnelle.

et les critères d'acceptation !

Oops, malgré cela, je me suis rendu compte que j'avais oublié un élément capital dans les user stories : les critères d'acceptation ! Pour faciliter la recette au fil de l'eau, il est important d'avoir ces critères d'acceptation au niveau des users stories, même si ceux-ci font souvent référence aux spécifications fonctionnelles. Je pense aussi qu'une automatisation des tests fonctionnels est capitale pour tirer tous les bénéfices d'un mode de développement avec des itérations courtes.

Au final, un bilan positif ?

Finalement, nous avons mis en place Scrum, mais j'ai quand même gardé certains outils propres aux cycles en V. Pourquoi ? Surement parce qu'on ne peut pas changer ses habitudes aussi facilement, mais aussi parce que Scrum ne se suffit pas à lui-même. Comme toute méthodologie, il faut l'adapter au contexte. Tous les développeurs ne sont pas capables de gérer les aspects fonctionnels, les clients ne sont pas forcément prêts à rédiger des users stories, et les équipes avec lesquelles vous devez interagir ne sont pas forcément "agiles". Les itérations courtes, les démos, la collaboration, la recherche du consensus, le pilotage par la valeur ajoutée sont par contre autant d'éléments très positifs de la méthodologie.

Je pense donc que le rôle de MOA ou AMOA s'inscrit parfaitement dans cette méthodologie du moment que l'on accepte que le product owner puisse être en fait une équipe composée d'un sponsor métier, d'utilisateurs clés et d'un ou plusieurs MOA. Dans ce cas,  la ou les MOA doivent clairement avoir la délégation et la capacité pour arbitrer les points en temps réel, quitte à remonter ensuite les points les plus problématiques lors des comités de pilotage du projet. La MOA peut alors apporter toute son expertise en terme d'analyse, de modélisation et de construction de lien fort entre le SI et le métier.

samedi, janvier 1 2011

Que faut-il souhaiter à la MOA du SI pour 2011 ?

Pour 2011, la croissance sera globalement faible en France (Croissance 2011 : le scénario de Bercy fragilisé par les prévisions de l'Insee). Mais certaines industries auront de belles perspectives de d'évolutions voire transformations de leur business (et si Apple achetait facebook ?). Alors pour commencer, je souhaite que votre entreprise - SSII, cabinet de conseil, éditeur de logiciel ou client final - puisse vous proposer des projets ambitieux de transformation de leurs métiers.

Indépendamment de ces projets business, cette année sera rythmée par la percée de nombreuses technologies dans l'environnement professionnel : tablettes, mobilité accrue, cloud computing privé (voir Les dix prédictions d'IDC pour 2011 sur fond d'expansion numérique)... Cela amènera de nouvelles réflexions sur la stratégie IT et de beaux projets à mener pour 2011. 

Mon dernier souhait pour 2011 est que la Maitrise d'ouvrage soit reconnue comme un métier à part entière qui demande des compétences particulières qui ne sont pas celles d'un chef de projet, pas celles d'un architecte, ni celles d'un expert métier. C'est un rôle qui demande des techniques d'analyse, de formalisation, de management transverse qui sont propres à ce rôle. On peut souhaiter que les formations en informatique intègrent cette dimension de manière plus explicite. Même la terminologie n'est pas claire. Par exemple la définition du France IIBA chapter est différente du terme Maitrise d'ouvrage:

Nous traduisons ici business analysis par « analyse d’entreprise ». En fait, c’est le domaine d’application de l’approche qui dira comment le traduire exactement : métier, marché, affaire etc.

En ce qui me concerne, je vais continuer à promouvoir ce métier au travers de ce blog, et comme bonne résolution 2011 : participer davantage aux communautés qui traitent de ce sujet !


mardi, novembre 16 2010

La MOA doit-elle être un expert fonctionnel monomaniaque ?

La MOA doit-elle être un expert fonctionnel ? Est-il bon d'être spécialisé sur un seul domaine ? Voilà une idée de sujet pour mon blog que l'on m'a soufflée aujourd'hui. La personne qui m'a posé cette question n'est pas la seule à se la poser ! Michelle Swoboda répondait à une question similaire sur le blog de Bridging the Gap : Help a BA! What is the difference between a subject matter expert and a business analyst?

Oui, la MOA peut être un expert fonctionnel...

Les MOA peuvent être au départ un expert fonctionnel qui est monté en compétences sur les aspects projet et les techniques de la maîtrise d'ouvrage. Par exemple, en finance de marché, un ancien opérateur Front ou Middle Office peut devenir maîtrise d'ouvrage sur un projet SI (comme Jérôme Kerviel : "consultant informatique" au revenu de "2.300 euros"). Dans ce cas c'est un expert fonctionnel et métier qui est monté en compétences pour apprendre ce qu'était un projet SI et quelles étaient les activités d'une MOA et les livrables à fournir dans le cadre d'un projet SI. Plus souvent les MOA acquièrent l'expertise fonctionnelle avec le temps, en restant plusieurs années dans le même domaine fonctionnel. Elle devient alors un expert fonctionnel.

... mais être un expert fonctionnel ne signifie pas qu'on est une bonne MOA...

Être un expert fonctionnel ne signifie pas que l'on est une bonne MOA. La maîtrise d'ouvrage est un domaine fonctionnel à part entière. Il y a énormément de compétences à acquérir propres à ce domaine, les process de développement informatiques sont spécifiques à cette industrie. De plus quand on est MOA sur des projets SI, il faut avoir une culture informatique importante pour pouvoir comprendre les enjeux IT.

... alors finalement faut-il changer de domaine fonctionnel ?

Recrutez des gens d'autres industries ! Je vous invite à lire cet article Why Innovation Is Beginner's Luck qui parle des défauts que l'on peut avoir lorsqu'on est depuis trop longtemps dans une même industrie (The Myopia of Experts). Il est vrai qu'un regard neuf amène toujours des solutions qu'on n'arrive pas à faire émerger quand on est depuis trop longtemps sur le même sujet. Mais si vous choisissez de recruter une MOA qui n'est pas un expert du domaine, il vous faudra quelqu'un d'autre pour remplir ce rôle ! Donc cela ne fonctionnera que si vous avez des utilisateurs expérimentés et disponibles avec qui travailler ou alors si votre organisation a la maturité nécessaire pour formaliser ce type de rôle.

Finalement, en tant que MOA, je pense qu'il vaut mieux être spécialisé dans un domaine plutôt que d'être complétement généraliste. Il est important d'être passionné par le domaine dans lequel on travaille et d'essayer d'en apprendre un maximum afin d'être critique vis à vis des demandes des sponsors et des utilisateurs. Mais pourquoi ne pas construire sa carrière sur deux ou trois domaines de prédilection ? Cela permet de garder de la fraicheur et de rester innovant. L'inconvénient c'est que cela demande de se remettre en cause et de prendre des risques...

vendredi, octobre 15 2010

Lean, Six sigma, Kanban... la MOA peut-elle rester un artisan du SI ?

Lean, Six sigma, Kanban... les méthodes et outils de l'industrie "lourde" ont débarqué sur le front du SI. Avez-vous déjà visité une usine de production ? Il n'y a que peu de similitudes avec un open space où l'on fait évoluer un système d'information. C'est une critique assez souvent entendue de ces méthodes appliquées à l'informatique : "Un développeur n'est pas un ouvrier sur une chaîne de production, c'est un artisan.". Et la maitrise d'ouvrage du système d'information ? Elle travaille sur des sujets qui sont tous différents, impossible de reproduire une méthode à l'identique, chaque projet a ses contraintes et ses spécificités, aucune solution ne marche deux fois. Alors, comment conserver un esprit créatif quand ces méthodes poussent à l'uniformisation et à la rationalisation ?

Conserver son esprit critique

Un cadre méthodologique permet d'avoir des repères et d'être opérationnel plus rapidement. Mais si cela nous semble nécessaire, il ne faut pas hésiter à sortir de ce cadre. Il n'y a pas de vérité absolue sur la manière de recueillir un besoin ou de modéliser un processus métier. Il faut absolument conserver son esprit critique et remettre en cause le process si celui-ci ne semble pas efficace. D'ailleurs le Lean se base sur le principe Kaizen (amélioration continue)  pour atteindre ses objectifs de performance.

Prendre son temps

Certaines activités intellectuelles ne sont pas compatibles avec le micro management. Parfois, seul le temps permet de démêler des sujets complexes, et une méthode centrée sur le "à faire" / "fait" ne prends pas forcément bien en compte ces temps de réflexion. Il faut apprécier le temps où l'on ne réalise rien comme un temps nécessaire et non pas du temps perdu.

Utiliser les outils de la créativité

Brainstorming, veille concurrentielle, cartes heuristiques... Il existe plein d'outils pour catalyser la créativité. Une ambiance d'équipe sereine permet aussi de laisser libre cours à l'initiative et la créativité, alors qu'une ambiance tendue risque de freiner les propositions de peur d'être rabroué.

Je suis convaincu que l'utilisation de méthodologies et d'outils adéquats permettent de faciliter le travail de la MOA et d'augmenter les performances d'une équipe projet. Mais il ne faut pas agir sans comprendre, et il ne faut pas oublier que ce n'est pas aux équipes projet de s'adapter aux méthodes, mais que ce sont les méthodes qui doivent être adaptées aux équipes. 

L'ordre est le plaisir de la raison, mais le désordre est le délice de l'imagination.
Paul Claudel.

vendredi, août 27 2010

La MOA doit-elle donner du relief ?

Nous avons vécu beaucoup d'innovations dans les interfaces homme-machine ces dernières années : terminal tactile multipoint, moniteurs informatiques et téléviseurs en 3D relief, réalité augmentée (pour faire son shopping par exemple), retour des "tablettes"... Mais est-ce que la MOA doit s'intéresser à ces technologies ?

Pas de Système d'Information sans technologie...

Sur ce blog, je traite plutôt du rôle de MOA vis à vis du système d'information. Il est de plus en plus difficile de trouver un processus métier dans une entreprise qui n'utilise pas l'informatique. Et le premier contact des utilisateurs avec leur SI, c'est via les interfaces graphiques des systèmes. Il est donc très important d'être curieux dans ce domaine : essayer les dernières versions des navigateurs Internet, suivre l'évolution des applications open source majeures... et également assurer une veille technologique ! Même si la MOA analyse le fonctionnel ou le métier, il est bon de savoir ce qu'il est possible ou sera possible de faire avec l'outil informatique. Par exemple, la puissance des téléphones portables permet aujourd'hui de développer de nouvelles interfaces en 3D plus immersives (voir cette news sur pcinpact .com : Intel et Nokia travaillent sur des téléphones à interface 3D). Ne voyez-vous pas des applications possibles dans votre domaine ?

... mais n'oublions pas nos objectifs

Mais attention, on croit que les rêves, c'est fait pour se réaliser. C'est ça, le problème des rêves : c'est que c'est fait pour être rêvé (Coluche). Car vous avez un budget à tenir, et les stratégies IT des grands groupes ne doivent pas simplement suivre les modes. Inutile donc de lancer des POC (Proof Of Concept) à tout va, il faut savoir cibler en fonction de la stratégie du SI. N'oubliez pas également que vos utilisateurs sont toujours réfractaires au changement. Alors, évitez les interfaces trop éloignées des standards de fait.

Vidéo : Hiro III, un robot hyptique et une interface tactile en trois dimensions

samedi, août 7 2010

Comment la MOA peut tirer parti des réseaux sociaux ?

Twitter, LinkedIn, Viadeo, Facebook... Les réseaux sociaux sont aujourd'hui bien implantés dans notre quotidien en France. Près de 20,3 millions de Français sont inscrits à un réseau social (type Facebook ou Twitter). Dans un article du nouvelobs.com, on nous alerte : Réseaux sociaux : engouement en France, un danger pour les entreprises ?. Car aujourd'hui les réseaux sociaux sont beaucoup utilisés à titre personnel et assez peu à titre professionnel. Beaucoup de gens actifs sur Facebook, mais beaucoup moins sur LinkedIn ou Viadeo. Pourtant tout le monde parle de l'entreprise 2.0, qui amène une nouvelle manière de communiquer dans l'entreprise, entre entreprises et entre clients et fournisseurs. Doit-on alors avoir peur de ces réseaux sociaux dans l'entreprise ? Non, surement pas. Et en tant que MOA vous devez même en tirer profit.

Maintenir son réseau professionnel

Maintenir son réseau professionnel est devenu une nécessité. Fini le temps où l'on faisait carrière au sein de la même entreprise pendant 40 ans. Que vous soyez consultant AMOA ou MOA en interne, vous devez utiliser ces outils pour vous aider à maintenir votre réseau professionnel. Ce n'est pas magique, il faut d'abord travailler le relationnel avec des vrais gens ! Soyez reconnu pour votre expertise et la qualité de votre travail. Ensuite, un outil comme LinkedIn vous permet de conserver un carnet d'adresse toujours à jour et toujours accessible.

Gérer son e-réputation

L'e-reputation c'est un terme à la mode qui désigne la réputation d'une personne physique ou morale (professionnel, marque, produit...) sur internet. Présenter son profil complet sur LinkedIn permet aux autres personnes d'avoir directement accès à votre expertise, et vos contacts sont la caution de ce profil. Essayez également d'obtenir des recommandations de clients ou de vos supérieurs, cela "prouve" que les gens avec qui vous avez travaillé reconnaissent votre valeur. Pensez également à publier vos connaissances ou des informations concernant votre secteur d'activité sur un blog ou via Twitter. Cela permettra aux gens qui ne vous connaissent pas encore de se faire une idée précise sur vos connaissances. Dernier conseil, créez-vous un profil personnel anonyme et un profil professionnel nommé. Le but est de maitriser votre réputation sur le web.

Profiter de la connaissance des communautés

Utilisez les communautés des réseaux sociaux pour faire de la veille "technologique" sur votre secteur d'activité, pour obtenir des réponses aux questions que vous vous posez, pour obtenir un avis sur un fournisseur... les occasions ne manquent pas ! Par exemple sur Twitter, vous pouvez trouver des Business Analyst qui publient des informations ou des articles concernant notre travail. Pour cela, effectuez une recherche sur le tag #baot (Business Analysis On Twitter). Une fois que vous avez trouvé des gens sur Twitter qui vous intéressent, surveillez leurs "retweet" et suivez les gens qui ont été cités et qui vous ont intéressés. Enfin, les sites communautaires comme LinkedIn proposent des groupes dans lesquels vous allez retrouver des forums de discussions : ModernAnalyst.com - Business Analyst Community, Business Analyst Professional...

Et pourquoi pas même utiliser les principes de ces réseaux sociaux, mais en interne ? Cela permet d'effacer la distance (géographique et hiérarchique) en ayant accès à toutes les informations et donc de fluidifier la communication. Il est fini le temps où l'on avait le pouvoir car on détenait l'information. Les gens performants sont maintenant ceux qui diffusent le mieux l'information. Tout du moins, c'est ce qui me semblerait le plus optimal dans une organisation, et ce qui faciliterait le plus mon travail de coordination en tant que MOA. Mais c'est encore très loin d'être le cas partout !

vendredi, avril 30 2010

La carte heuristique peut-elle aider la MOA à organiser ou communiquer ses pensées ?

Une carte heuristique [...] est un diagramme qui représente les connexions sémantiques entre différentes idées, les liens hiérarchiques entre différents concepts intellectuels.

Contenu soumis à la licence CC-BY-SA. Source : Article Carte heuristique de Wikipédia en français (auteurs)

Comment cet outil peut être utile pour une MOA ? Ce type de schéma permet d'organiser ses pensées sous une forme hiérarchique et synthétique. De plus il existe des outils qui permettent de créer et éditer ces cartes assez facilement, comme par exemple Mindomo. Voici donc quelques exemples de cas où l'on y trouvera un intérêt en tant que MOA.

Présenter ses compétences

Décrire son savoir-faire sous forme de carte heuristique permet de faire le point sur ses compétences en les catégorisant. Une fois la carte réalisée on a en un coup d'œil le périmètre de son savoir-faire. Cela peut être utile pour identifier ses manques et ses points forts à titre personnel. Mais cela peut aussi servir à accompagner son CV "classique" pour présenter de manière transverse et non chronologique ses compétences. Présenter ses compétences ainsi montre aussi sa capacité à synthétiser et prendre du recul, qualités requises pour la MOA. Voilà un exemple de carte du savoir-faire d'une MOA (limitée aux deux premiers niveaux) :

Présenter les exigences

Les exigences sont très souvent gérées de manière hiérarchique. Plutôt que de présenter un long document de description d'exigences, il peut être intéressant de synthétiser ces exigences via une carte heuristique. Ceci peut par exemple servir à présenter les exigences aux différentes parties prenantes du projet en une réunion rapide.

Voilà deux exemples mais en réalité on peut utiliser ce type de schéma très souvent dans des cas très variés. Mais attention de ne pas tomber dans l'excès avec ce genre d'outils. Un schéma vaut mieux qu'un long discours, mais parfois l'action vaut mieux qu'un lourd schéma conceptuel, comme en témoigne cet article lu sur Le Figaro, Le Pentagone a un ennemi intérieur : le PowerPoint.

- page 1 de 2