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

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

vendredi, avril 30 2010

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

Par Olivier Durand le vendredi, avril 30 2010, 10:15 - Etudier

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.

jeudi, mars 25 2010

Comment découvrir les besoins ?

Par Olivier Durand le jeudi, mars 25 2010, 17:20 - Etudier

Recueillir les exigences des différentes parties prenantes d'un projet, c'est comme construire les fondations de votre projet. C'est sur ces exigences que l'ensemble du projet va reposer. Dans le billet "Comment améliorer l'alignement IT/métier en utilisant un outil de gestion des exigences ?", j'ai essayé d'expliquer l'intérêt d'un outil pour gérer ces exigences. Mais avant de les formaliser un minimum, il faut déjà les découvrir.

Organisez des entretiens Top-Down

Je conseillerai plutôt de commencer par rencontrer les personnes ayant une vision plus globale du processus concerné pour finir par les utilisateurs clés des systèmes supportant le processus (par exemple dans une salle des marchés commencer par s'entretenir avec un directeur de l'exploitation ou un directeur d'une ligne métier, ensuite voir un responsable de table pour finir par un opérateur de marché et enfin un assistant). Cela permet de commencer par découvrir les exigences stratégiques pour finir par les exigences fonctionnelles et non fonctionnelles. Je pense également que le temps à passer doit être moins important avec le top management qu'avec les opérateurs au cœur du processus.

Préparez vos entretiens

Une réunion demande toujours d'être préparée, d'être conduite, puis il faut en rédiger un compte-rendu. Le compte-rendu d'un entretien de recueil de besoins est la matière première qui va permettre de construire le référentiel des exigences. Le point clé de la préparation de la réunion, afin d'avoir un compte-rendu copieux, c'est de prévoir les questions qui vont cadencer l'entretien. Ces questions doivent être adaptées à votre interlocuteur et suivre une évolution du plus global au plus précis. Vous trouverez des idées de questions génériques dans cet article de Mr. Monteleone lu sur modernalyst.com : Generic Questions for Interviewing Stakeholders.

Pensez processus métier et architecture orientée service (et non pas système)

On ne cherche pas encore à spécifier un système ou une solution même si les utilisateurs auront tendance à se rattacher à du concret. Posez vos questions afin qu'elles soient le plus possible absolue vis à vis des solutions (pour caricaturer, demandez quelles sont les informations nécessaires pour remplir un dossier plutôt que de demander quel écran de saisie est nécessaire). Gardez également toujours en tête comment cette partie s'inclut dans un processus métier complet. Voir par exemple cet article sur business analyst times qui décrit cette approche avec une jolie métaphore du temple grec : Breaking Down the Silos for Better Requirements Elicitation. Et comme je le disais déjà dans mon billet précédent La MOA doit elle comprendre SOA ?, penser "services" vous permettra de poser les bonnes questions pour identifier les réutilisations possibles. Certaines MOA vont jusqu'à prôner une approche où l'on va tenter de conformer les besoins aux services existants comme dans cet article de John Moe lu sur modernalyst.com : Service Oriented Analysis. J'ai un peu de mal avec cette approche car tordre ainsi le besoin c'est risquer d'aboutir sur une solution qui ne saura satisfaire votre sponsor.  Mais dans certains cas ça pourrait marcher, si le SI est déjà organisé en SOA d'un bon niveau, comme le dit l'auteur de cet article.

Une exigence n'est donc pas simplement une information qui est venue à nous sans aucun travail. Le recueil des besoins est une phase clé du projet. Se contenter d'un mail succinct (le fameux Post-it) envoyé par le sponsor pour se lancer dans une phase de spécification fonctionnelle n'est pas suffisant. Il est vrai que cette phase de projet n'est pas "technique" mais exploite plutôt les compétences d'analyse et le relationnel de la MOA, et on peut donc parfois la sous-estimer sur un planning. Mais attention alors au risque de retard, car entre la préparation, la planification des entretiens, et l'analyse des résultats, cette phase peut être très consommatrice de temps.

jeudi, mars 11 2010

La MOA doit elle comprendre SOA ?

Par Olivier Durand le jeudi, mars 11 2010, 20:38 - Etudier

L'architecture orientée services (SOA en anglais) est un ensemble de concepts aujourd'hui matures. Cette démarche est souvent poussée par les acteurs "techniques" du SI. Pourtant un des points clés de la mise en œuvre devrait être selon moi à la main de la MOA : la décomposition en services.

Les services définis doivent être réutilisables, c'est tout l'intérêt de l'architecture SOA. Mais ce ne sont pas de simples composants réutilisables. Un service doit être autonome, remplir une fonction dans sa globalité et être utilisable (ou mieux, utilisé) par plusieurs consommateurs. Différents niveaux de service peuvent être définis : données (services "simples" permettant par exemple de récupérer des clients, d'en créer, d'en rechercher...), métiers (un service complexe qui remplira des fonctions métiers comme calculer le chiffre d'affaire par comptes clients), applicatifs (par exemple un service qui permettra notamment de récupérer tous les chiffres d'affaires agrégés par comptes clients qu'un collaborateur gère afin de l'afficher dans la CRM). On parle de service composite lorsqu'il utilise plusieurs autres services de niveaux inférieurs.

Certaines méthodologies combinent une approche SOA & MDA, par exemple Praxeme. Dans ce cas la définition et la découverte des services va se faire par des itérations de modélisation. Que ce soit dans l'aspect sémantique, pragmatique ou logique, la MOA a un très grand rôle à jouer.

Pour le métier la SOA peut n'être qu'une tactique permettant d'atteindre un objectif d'agilité dans les processus métiers. La mise en place du BPM sera un objectif atteignable et intéressant uniquement si les services sont réutilisables d'un point de vue métier. Et pour cela la MOA a une forte valeur ajoutée afin de déterminer les frontières des différents services et pour anticiper sur les réutilisations métiers possibles.

En tant que MOA nous avons souvent tendance à penser directement à la solution. Il est vrai qu'il est plus naturel de parler des écrans d'une application, d'un batch qui va effectuer des traitements car on se raccroche alors à du concret, de l'existant. Mais c'est aussi rester un peu terre-à-terre. Quitte à prendre de la hauteur, autant essayer de penser services. Par exemple si vous être déjà habitués à travailler sur des exigences et des cas d'utilisation, vous pouvez très bien proposer dans une spécification détaillée un découpage du système en services métiers. Et dans un projet qui porte sur un processus métier, il est encore plus naturel d'identifier les services métiers qui correspondent souvent à une activité de ce processus (en tout cas dans une vision purement métier). Connaître ces services permet à la MOA de dynamiser la réutilisation au sein du SI et de comprendre les problématiques engendrées par la maintenance d'un service qui est utilisé par plusieurs consommateurs et donc de faire les bons choix dans l'utilisation des budgets.

mardi, mars 2 2010

La MOA est-elle une hôtesse de l'air ?

Par Olivier Durand le mardi, mars 2 2010, 08:20 - Supporter

Le support applicatif métier est difficilement externalisable, contrairement au support sur les applications dites "bureautiques" (gestion des courriers électroniques, traitement de texte...). Plus les applications métiers sont critiques pour l'entreprise, plus l'équipe support applicative doit avoir des profils de haut niveau et des compétences pointues. Ce sont parfois directement les maîtrises d'ouvrage qui exercent le rôle de support applicatif ou support fonctionnel, alors que d'autres organisations mettent en place des équipes dédiées à ce support très proche du métier (équipes que l'on peut considérer alors comme assistance à MOA). La MOA doit donc avoir le sens du service ?

Dans l'article Le « sens du service », une question d'organisation sur scienceshumaines.com l'auteur évoque les travaux d'Arlie Russel Hochschild qui dès 1983, dans The Managed Heart, définit le concept de travail émotionnel pour les hôtesse de l'air consistant à réélaborer leur ressenti et à influer sur celui des passagers, notamment en diffusant un sentiment de sécurité. La maîtrise d'ouvrage serait en fait un steward ou une hôtesse de l'air ? Il est vrai que face à un problème de production important ou face à une forte réticence au changement, la MOA peut avoir ce rôle de travail émotionnel : calmer l'utilisateur si ses craintes ne sont pas fondées, communiquer les informations nécessaires sans créer de panique, et éventuellement expliquer comme accéder aux toboggans de secours si le crash est inévitable !

Ensuite l'auteur de cet article parle des travaux du sociologue américain Ervin Goffman (Asile, 1968) pour définir la compétence de service : la capacité de prendre une décision non prévue par une procédure impérative et de la présenter comme professionnellement justifiée. Une telle décision n'est jamais facile à prendre car elle se prend toujours dans un contexte délicat. Donc plus qu'un sens du service commun une MOA doit avoir cette "compétence de service" afin d'être capable de réagir à des problèmes variés qui attendent des solutions spécifiques.

La notion de support informatique est souvent mal perçue car caricaturée en un centre de service outsourcé en Inde, en Afrique du Nord ou en Irlande, où les opérateurs de ces helpdesks sont notoirement incapables de résoudre un problème, ni même souvent de le comprendre. La faute sûrement aux grands opérateurs télécoms qui ont souvent eu des démarches assez radicales en terme d'outsourcing de ces services. Pourtant faire du support applicatif ou fonctionnel sur des applications très critiques demande des compétences pointues sur le domaine géré et également une grande compétence de service. Il me semble également qu'il est toujours bon pour une MOA même si elle est orientée projet d'être au contact de la production et de ses réalités de terrain, cela permettant de concevoir des solutions fonctionnellement adaptées à la réalité.

mercredi, février 17 2010

Le rôle de MOA est-il compatible avec les méthodes agiles ?

Par Olivier Durand le mercredi, février 17 2010, 07:17 - Piloter

Les méthodes agiles telles que Scrum et Extreme Programming ne sont pas adaptées à tous types de projets et demandent une organisation bien différente de la classique organisation verticale. De grands penseurs (Ward Cunningham inventeur du Wiki, Kent Beck fondateur de l'extreme programming...) se sont réunis en 2001 et ont publié le manifeste des méthodes agiles qui met en avant les quatre valeurs fondamentales des méthodes agiles :

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Le troisième point place le client au centre de ces méthodes. Terminée la relation client vs fournisseur, MOA vs MOE... Le client doit faire partie de l'équipe projet. Un des douze principes de ce manifeste est :

Business people and developers must work
together daily throughout the project.

On comprend donc que la MOA doit être très impliquée et collaborer très étroitement avec les autres intervenants du projet. Voici pour exemple un schéma expliquant le fonctionnement d'une des plus connues des méthodes agiles, SCRUM :

En plus de l'équipe qui va réaliser les développements, Scrum définit deux rôles que pourraient jouer une MOA "classique".

Le Product Owner. C'est celui qui va définir le Product Backlog composé des demandes des parties prenantes du projet, priorisées d'un point de vue business. Dans une organisation classique, sur une application qu'on fait évoluer en mode catalogue, la MOA fait déjà souvent ce travail via un outil comme JIRA par exemple. Là il s'agit de le faire avec une terminologie et une finalité différentes. A partir de ce Product Backlog le Product Owner va définir le contenu de la prochaine itération (le sprint) avec l'aide de l'ensemble de l'équipe : c'est le Sprint Backlog.

Le Scrum Master. C'est celui qui aura pour rôle de faciliter le travail de l'équipe. Ce n'est pas un chef, il n'y a pas de notion de hiérarchie dans ce process. Ce rôle consiste à faciliter la résolution d'éventuels conflits, rappeler les principes de Scrum lorsqu'un membre de l'équipe s'en écarte... Et en tant que MOA on joue déjà le rôle de facilitateur. Par contre je connais peu de MOA ayant des compétences sur ces méthodologies.

En plus de cette organisation, Scrum propose d'utiliser des outils tels que le daily scrum ou daily standup meeting, le burn down chart, les post-it et les grands tableaux blancs pour concevoir... Tous ces éléments font que l'organisation du travail est assez différente d'une organisation classique. Il n'y a pas de chefs, il faut s'auto-gérer, s'auto-motiver... C'est un mode de fonctionnement que tout le monde ne voudra/pourra pas accepter. Et cette terminologie et organisation assez spécifique peut créer un effet de communautarisme dès lors que cette organisation n'est pas celle de toutes les équipes de votre service.

Depuis quelques années on essaie d'utiliser des méthodes adaptées à l'industrie "lourde" comme Lean ou Six Sigma pour des projets SI. Or la maturité de l'industrie informatique est très loin de celle d'autres industries plus anciennes comme l'automobile. De plus, le travail d'un développeur informatique n'est en rien comparable aux tâches effectuées par des opérateurs d'une chaîne de production. C'est pourquoi les méthodes agiles me semblent plus pertinentes. Mais encore faut il trouver sa place en tant que MOA dans ces organisations parfois mises en place par des nerds. Il faut également savoir rester pragmatique pour ne pas adopter n'importe quelle méthode, n'importe comment. On doit s'approprier une méthode publique pour construire sa propre méthode qui sera acceptée par tous les intervenants.

Modernanalyst.com - How new are all those "new" methodologies really?

dimanche, février 7 2010

Comment améliorer l'alignement IT/métier en utilisant un outil de gestion des exigences ?

Par Olivier Durand le dimanche, février 7 2010, 17:44 - Etudier

L'informatique ne doit plus simplement suivre le métier. On attend aujourd'hui d'un SI qu'il soit capable de s'adapter à toutes les évolutions du business même ceux qui n'ont pas été anticipés par les opérationnels. Dans une étude concernant l'état de l'art de l'aligement IT / Métier en France publiée en 2008 par le cabinet PAC - Pierre Audoin Consultants, on apprend que La collaboration entre maîtrises [maîtrises d'ouvrage et maîtrises d'œuvres] est un point crucial, qui pourrait être le fil rouge de cette étude. Elle est jugée critique à 94%. On note également dans cette étude que l'intégration MOA/MOE est le deuxième levier juste derrière le projet stratégique au niveau de l'entreprise pour améliorer l'alignement IT / Métier.

Il existe des outils qui peuvent aider à plusieurs niveaux sur ce sujet. Ce sont les outils de gestion des exigences (requirements management). Une exigence fait référence à un besoin d'une des parties prenantes du projet. Une exigence peut être fonctionnelle ou non fonctionnelle. Concernant les outils, on peut par exemple citer Entreprise Architect. Dans leur document Requirements Management with Enterprise Architect, ils expliquent comment UML est utilisé pour modéliser les exigences. Dans un autre style, moins graphique, IBM propose DOORS. Dans leur livre blanc Ten steps to better requirements management, IBM nous explique ce qu'une exigence doit être :

  • Correcte (techniquement et juridiquement possible) ;
  • Complète (exprime une idée ou un fait dans sa totalité) ;
  • Claire (sans ambiguïté) ;
  • Non contradictoire (pas en conflit avec une autre exigence ) ;
  • Vérifiable (il est possible de définir si le système répond à cette exigence) ;
  • Traçable (identifié de manière unique et tracé) ;
  • Faisable (peut être accompli dans les coûts et délais prévus) ;
  • Modulaire (peut être changé sans impact excessif) ;
  • Indépendant de la conception (ne parle pas de solution concernant la conception).

(la traduction est un métier)

Une fois que les exigences sont exprimées, tout l'intérêt d'un outil de gestion des exigences est de permettre la traçabilité afin de pouvoir répondre aux questions suivantes :

  • Est-ce que tous mes besoins ont été couverts par le système ?
  • Quels besoins étaient mal exprimés et donc volatiles ?
  • Quel est l'impact si je modifie une exigence ?

C'est en étant capable d'analyser ces points qu'on pourra ensuite améliorer l'alignement IT / Métier. Par exemple si un des besoins était trop volatile, l'IT ne pourrait pas s'aligner. Il peut donc être nécessaire par exemple de chercher une autre organisation qui permette d'avoir une expression des besoins plus pérenne. Un besoin peut-être exprimé sur un Post-It  (heu pardon je voulais dire papillon adhésif amovible) par une des parties prenantes du projet, mais la MOA se doit ensuite de formaliser ces besoins sous forme d'exigences. Un bon outil permettra de tirer profit d'une telle démarche.

Modernanalyst.com - There's an app for that!

samedi, janvier 30 2010

Comment améliorer la qualité des données de référence ?

Par Olivier Durand le samedi, janvier 30 2010, 20:47 - Etudier

On parle très souvent de Système d'Information en oubliant parfois le terme information qu'il contient. Et si les technologies utilisées sont souvent très volatiles par rapport à la durée de vie de l'entreprise, les données de référence existent du début à la fin de la vie de l'entreprise. Référentiel des clients, des produits... quasiment aucune application du SI ou projet ne peut s'en passer.

Le concept de Master Data Management (ou Gestion des Données de Référence en français) regroupe toutes les problématiques associées aux données de référence. Comment construire "one version of the truth", objectif du décisionnel  ? L'acquisition des données, les contrôles de qualité, la diffusion des données peuvent être industrialisés via des outils de MDM :

Certains prônent même le MDM comme élément fondateur du système d'information durable. C'est le cas du groupe Sustainable IT Architecture (groupe créé par Pierre Bonnet, co-fondateur d'Orchestra Networks) via son Agility Chain Management System :

Il est clair que commencer un projet sans savoir où récupérer une liste de clients, sans savoir comment trouver les caractéristiques d'un produit, ce n'est pas commencer sous les meilleures auspices ! Et si finalement on trouve ces données mais qu'au moment de démarrer en production on se rend compte que les clients ne sont pas dans le référentiel et que les caractéristiques des produits sont erronées, c'est la catastrophe. True story. Et quand vous parlez décisionnel, avant de vouloir construire des reportings, il faut déjà avoir des données à jour et de qualité. Pour éviter les pièges, ces quelques conseils peuvent être utiles :

  • La sémantique des objets métiers doit être documentée et connue de tous ;
  • Une donnée doit être gérée (créée, modifiée, supprimée) à un seul endroit du SI ;
  • Des contrôles de qualité doivent être appliqués automatiquement (même s'ils paraissent basiques) ;
  • Une donnée doit être mise à disposition de tout composant du SI via un unique composant (via des canaux de communication différents si nécessaires pour répondre à tous les besoins) ;
  • Des campagnes de nettoyage doivent être lancées périodiquement (le grand nettoyage de printemps).

Finalement, même si ces outils de MDM commencent à devenir plus accessibles avec l'apparition de solutions open source, ils restent complexes et globalement coûteux à mettre en œuvre. Si la qualité des données doit être un vrai sujet SI, on ne peut pas réussir simplement en mettant en place une solution IT miracle sans une organisation qui permette de gérer ces données avec la rigueur et le contrôle qu'elles méritent. Et pour convaincre les sponsors, il est surement bon de commencer par les 20% d'effort qui apporteront les 80% de résultat visibles par le business, comme toujours.

dimanche, janvier 24 2010

Comment spécifier une interface graphique sur un terminal à écran tactile multipoint ?

Par Olivier Durand le dimanche, janvier 24 2010, 22:20 - Spécifier

L'informatique est un secteur où les technologies évoluent très rapidement. Et en ce moment, la mode est aux terminaux à écrans tactiles multipoints : Apple iPhone, Palm Pixi, Microsoft Surface...

Selon le grand dictionnaire terminologique de l'office québécois de la langue française une écran tactile multipoint est un

Écran qui possède le matériel nécessaire pour détecter simultanément à plusieurs points de sa surface les pressions ou les déplacements des doigts, des mains ou des stylets, et qui est relié à un système informatique capable d'interpréter ces actions séparément et en même temps tout en coordonnant l'information.

Avec ces technologies, la sémantique de l'IHM est forcément différente. Si vous utilisez la tableau ICAR (Intention, Contrôle, Action, Réponse), vous devez oubliez les classiques Cliquer, Double cliquer...

Toucher
Cette action reste valable pour tout écran tactile. L'action de base c'est donc de toucher l'écran pour lancer une commande.

Pincer / Ecarter
Sur l'iPhone pour zoomer ou dézoomer, il suffit de pincer virtuellement avec deux doigts ou d'écarter ces mêmes doigts.

Secouer
Ces nouveaux terminaux mobiles amènent également des fonctions annexes comme un accéléromètre. Ainsi, secouer son terminal peut permettre de retourner à l'écran d'accueil par exemple.

Pencher
En penchant son terminal on va également pouvoir activer des commandes. Par exemple en penchant à droite ou à gauche, on va contrôler un personnage dans un jeu de plateforme pour le faire aller à droite ou à gauche.

A peine commençons-nous à nous faire à ces nouvelles interfaces que les chercheurs sont déjà sur des nouveaux systèmes de "pointage" comme par exemple le "Vision-based Input interface" qui consiste à reconnaitre les mouvements du doigt afin de permettre un pointage en "3D". Gageons que l'informatique ambiante (Ubiquitous computing) saura utiliser ces nouvelles technologies.

dimanche, janvier 17 2010

Quels sont les cinq points clés pour réussir une recette ?

Par Olivier Durand le dimanche, janvier 17 2010, 21:56 - Recetter

1) Définissez la stratégie de la recette.

En plus de la description de l'organisation et des moyens mis en œuvre pour la recette, n'oubliez pas de décrire l'objectif de cette recette. Recetter une application, ce n'est pas vérifier que l'application n'a pas de bug. Recetter, c'est vérifier que le système répond aux exigences fonctionnelles et non fonctionnelles par rapport aux coûts et à la qualité attendue. Définissez donc en amont quelle est la criticité des fonctionnalités du système et le niveau d'acceptabilité pour chaque criticité. Par exemple, on acceptera peut-être un bug bloquant sur une fonctionnalité "cosmétique" alors que pour une fonctionnalité très critique, aucun bug bloquant ou majeur ne sera toléré. 

2) Pensez aux tests avant tout.

Test Driven Development, Behavior Driven Development, Acceptance Test Driven Development... Beaucoup de méthodes prônent la conception par les tests. Sans forcément passer par des concepts complexes, penser "tests" dès la conception fonctionnelle permet souvent d'expliciter sa pensée et de se concentrer sur les objectifs du système.

3) Coordonnez et planifiez la recette.

Même si tous les tests ne sont pas exécutés par la MOA, coordonnez. De la mise à disposition des environnements de test, à l'exécution de tests de performance, en passant par les tests utilisateurs, vous devrez coordonner des équipes aux contraintes très différentes. La recette est souvent un projet en elle même.

4) Outillez vous.

Que ce soit pour la description des plans de test et le suivi de l'exécution des campagnes, utilisez des outils pour industrialiser vos tests (du classique avec HP Quality Center, ou du plus original comme FitNesse à base de Wiki). Au minimum, utilisez un fichier Excel pour décrire vos scénarios et cas de test ainsi que pour en suivre l'exécution.

5) Soyez pugnace.

La recette n'est pas une activité simple. Bien que souvent pénible et répétitive dans son exécution, c'est un moment clé du projet. On est souvent tenté de rogner sur la charge prévue pour cette activité car à la fin d'un projet, il ne reste plus grand chose à arbitrer ! Et pourtant, c'est le dernier rempart avant la mise en production. La négliger pourrait être une erreur fatale.

mardi, janvier 12 2010

Management transverse, comment vaincre les clivages ?

Par Olivier Durand le mardi, janvier 12 2010, 23:32 - Piloter

En tant que MOA, on est souvent amené à travailler en réseau, à utiliser le management transverse. Et quand l'organisation de notre entreprise est très hiérarchisée, ce travail en réseau n'est pas facilité. Autre contrainte au niveau SI, l'architecture orientée service a souvent été mise en place sans refonte de l'organisation. Voilà les pire cas que l'on peut rencontrer et quelques idées pour les gérer au mieux.

Gérer le clivage MOA/MOE

  • La caricature :

Il vaut mieux être au courant : La MOA pense que les MOE sont des "pisseurs de code", la MOE pense que la MOA sont des "pisseurs de slides".

  • Les solutions du point de vue de la MOA pour éviter d'en arriver là :

Utilisez le plus souvent possible un style de management participatif. Demandez "quel est le plan d'action à mettre en œuvre pour tenir la date de livraison ?" plutôt que d'imposer une échéance.

Utilisez également un style autocratique lorsqu'il le faut. La MOA a son expertise, les décisions en relevant doivent être clairement prises et actées de tous. Ceci n'empêche pas d'expliciter les tenants et les aboutissants bien sur.

De la même manière, ne remettez jamais en cause les décisions prises par la MOE qui relèvent de leur expertise. Par exemple, une MOA ne doit pas remettre en cause le chiffrage fourni par la MOE, même si elle est en droit de demander des détails ou des explications.

Gérer le clivage MOA/Sponsor

  • La caricature :

Le Sponsor n'a pas de temps à accorder à  la MOA. Pour lui, la MOA est un "informaticien" comme un autre. La MOA pense que son sponsor ne s'implique pas assez dans le projet.

  • Les solutions du point de vue de la MOA pour éviter d'en arriver là :

Usez de vos qualités relationnelles. Sachez apporter légèreté et humour quand les conditions sont réunies, soyez toujours d'humeur égale, traitez parfois de hors sujets...

Adaptez votre style à votre interlocuteur. Certains interlocuteurs peuvent faire attention aux détails : ponctualité, look, sachez vous adapter.

Optimisez votre temps. Organisez des réunions courtes (30 minutes sont souvent suffisantes) mais régulières. Préparez les en utilisant un support optimal (type "Flash report"), conduisez les réunions en évitant les écarts, rédigez et diffusez toujours le compte-rendu dans la foulée pour mettre noir sur blanc les résultats de ces réunions.

Gérer le clivage intergénérationnel

  • La caricature :

La différence essentielle entre un jeune con et un vieux con réside dans le temps qu'il leur reste à être cons. - Jean Dion.
En tant que MOA vous serez amener à travailler avec des gens qui ont des rôles bien différents, vous amenant à réaliser un grand écart générationnel.

  • Les solutions du point de vue de la MOA pour éviter d'en arriver là :

Soyez ouvert. Vous allez être tantôt le jeune, tantôt le vieux. Sachez rester ouvert aux points de vue de tous les intervenants. Un utilisateur qui a 30 ans d'expérience sur son poste ne vous fera pas les mêmes retours qu'un utilisateur qui sort de l'école. Mais tous sont bon à prendre.

Acceptez la critique. On vous prendra un jour pour un jeune prétentieux aux dents longues parce que vous souhaitez bouleverser un processus métier qui fonctionne très bien depuis 15 ans, et le lendemain pour un vieux de la génération X parce que vous ne pratiquez pas le twittering et que vous avez aimé connu le doux chant du modem 56K. Acceptez de recevoir toutes les critiques, vous n'avez rien à prouver.


- page 3 de 4 -