Accueil > Divers, Humeur, Humour, MMIT > [MMIT] Vocabulaire

[MMIT] Vocabulaire

BSODDans ce premier billet (introduction ici) , on va voir un peu de vocabulaire pour comprendre ce qui sera dit dans les suivants.

Il faut savoir qu’en France (je ne sais pas pour les autres pays), mais le modèle qui a été choisie (à tort ou à raison) pour l’organisation dans un Système d’Information est un modèle calqué sur le bâtiment et les travaux publics.
Pourquoi ? Bonne question (j’y reviendrais une autre fois)…


 
SI : Système d’Information.
Grosso modo, c’est tout ce qui a trait, de près ou de loin, à l’informatique.
Donc, dans le tas, on retrouve les gars qui installent les machines auprès des utilisateurs (service informatique), les gars qui sont en charge des postes de travail (différents de ceux qui les installent, administrateurs système), les gars qui sont en chargent des serveurs (exploitation, la majeure partie du temps (dé)centralisée), ceux qui gèrent les bases de données (DBA), ceux qui font les logiciels (développeurs, dépendent souvent de services divers et variés), ceux qui pondent des socles pour les développeurs mais qui les utiliseront jamais (architectes), ceux qui décident, ceux qui planifient, ceux qui gèrent, ceux qui font des graphiques (PMO :p)…
Bref, y a du monde.
Pour comprendre l’organisation et comment les uns discutent avec les autres, il suffit de regarder un plat de spaghettis. Ce n’est souvent pas très loin de la réalité.
Chaque entité étant un bloc indépendant, une « boîte noire » qui jalouse scrupuleusement son domaine d’action (souvent plus scrupuleusement qu’elle ne fait son travail).
Chaque boîte noire communiquant avec les autres selon des processus qui ont été créés par des gens qui ne vont jamais les utiliser (mais ils savent parfaitement que c’est le meilleur processus possible). Des fois avec des boîtes mail de service (le premier qui répond à perdu) ou via une application (le premier qui la regarde a perdu).
Plus une organisation est complexe, plus il y aura de strates hiérarchiques, plus il y aura de responsables et chefs.
Ainsi, toute responsabilité sera de plus en plus diluée et au final, aucune personne n’aura à prendre de décision utile et pertinente. Le premier qui en prendra une aura donc perdu.
Note : la DSI n’est pas une agence gouvernementale (quoique…) mais la Direction du Système d’Information.

Les personnes.

 
Client.
C’est celui pour qui on fait l’application.
Attention, le client n’est pas forcément le futur utilisateur de l’application, ce peut être deux entités très différentes.
Du coup, on a deux cas de figures.
Le premier : le client est différent des utilisateurs. Là, c’est souvent le drame, à la fin (voir "Utilisateurs").
Le second : le client est l’utilisateur. Là, ça peut être le drame, ou pas. Ça dépendra beaucoup de son implication.

 
Les utilisateurs.
En général, personne ne leur demande rien (dans le cas ou client =/= utilisateurs).
On leur fourgue un truc dans les pattes, qu’ils aiment ou non.
Personne ne les consulte avant, pendant ou après.
Ils ne voient l’ampleur du désastre qu’une fois le projet terminé ou un peu avant, dans des séances de formation indispensables tellement les applications sont mal pensées.
Il est fort probable que dans les contacts avec une administration ou service client quelconque, vous ayez pu entendre « ah, excusez-moi, mon informatique plante/à des problèmes/est lent » ou « attendez, je ne sais plus où on trouve/renseigne cela ». C’est typiquement l’effet d’un utilisateur qui n’a pas eu son mot à dire.

 

Hiérarchye (by Koreus)

Hiérarchie (by Koreus)

Hiérarchie.
Entité un peu étrange, groupement de personnes qui commencent souvent à partir du n+2 (le chef du CDP). Souvent indistincte et peu connu. Il est cependant possible de trouver leurs photos dans le trombinoscope de la société, car étant souvent internes, ils ont leur photos de grands winners bien habillés (costards hors de prix), dent blanche, œil qui brille, un goût certain pour le golf ou le tennis.
C’est en général des gens pour qui le MOE travaille mais qu’il ne voit jamais, donc il ne connait pas forcément le visage voir même le nom.
En effet, la hiérarchie ne doit pas se mêler à la plèbe. Dire bonjour à un MOE est passible de flagellation.
La hiérarchie voit au-delà du projet, elle voit l’avenir de la société.
C’est elle qui planifie, qui édicte les actions à réaliser pour que les simples exécutants que nous sommes puissent avoir un chemin lumineux à suivre (bon, après, y a parfois des pannes d’électricité…).

 
MOA : maître d’ouvrage.
Les MOA, c’est les gars habillés façon Men In Black.
Ils sont payés à réfléchir et pondre des documents comme les poules pondent des œufs (ou comme certains multiplient les pains). Certains sont mêmes payés en fonction du nombre des dits documents.
Le costume est parfois utilisé pour justifier à priori de compétences qui ne sont pas présentes (l’habit et le moine, toussa toussa). Mais parfois, on trouve des perles (c’est pas utile d’ouvrir les MOA, hein, c’est une métaphore !).
Les documents se doivent donc d’être écrits dans un style pompeux, les mots doivent faire référence aux activités métiers du client, y compris si les mots en question sont peu usités en langue française, incompréhensible au commun des mortels, avec des phrases très longues pour marquer des idées complexes mais sans pour autant les décrire de façon claire afin de laisser une marge d’erreur non négligeable afin de pouvoir rejeter la faute sur les MOE avec des arguments du type « le MOE n’a point fait ce qui était spécifié, c’est donc une anomalie des plus grave qui doit être traitée en premier lieu, avant toutes les autres priorités ! ».
Vous voyez l’idée ?…
Parfois, les MOA sont d’anciens MOE. Là, il y a deux cas de figure :
Le MOA qui a une haute opinion de ses talents de MOE : le pire, il sait ce qui doit être fait, il sait comment ça doit être fait. Il est reconnaissable au fait qu’il se vante d’avoir été MOE.
Le MOA qui facilite le travail des MOE : le meilleur. Il connait les contraintes et essaye d’arrondir les angles. Il travail AVEC le MOE et ça, ça change tout. Les MOE savent qu’il a été MOE, mais il ne s’en vante pas.

 
CDP : Chef de Projet(s).
Le fusible, le punching-ball, celui qui s’en prend plein les dents. Celui qui va sauter au moindre problème important (que ce soit de sa faute ou nom).
Le chef de projet est une espèce à part au sein de la MOE.
Ces outils de travail sont Word, Excel, Visio et MS Projects (ou assimilables, suivant le budget bureautique de l’entreprise).
Il fera donc également des documents parmi les suivants : planning de projet (qui ne sera pas respecté), répartition des charges (avec une charge entre 150 et 200%), compte rendus de réunions (que personne ne lit), rapport d’avancement (dont les indicateurs passent miraculeusement de rouges à verts dans les différentes strates hiérarchiques).
Lui-même ayant un panel de projets allant de 1 (« je m’emmerde ») à 1024 (« je suis sous l’eau, je me noie, mais y a encore des projets qui arrivent »).
C’est un boulot ingrat, je trouve. Le CDP n’a pas forcément tout le pouvoir qui devrait aller avec son titre. Les projets sont souvent décidés par la hiérarchie et le CDP n’est donc là que pour veiller à ce que tout se déroule comme le plan établit le voulait (ce qui est rarement le cas).
C’est aussi le gars qu’un MOE a pour responsable, le gars qui doit lui donner son travail (comme d’autres donnent le pain quotidien, même vidéo qui pour les MOA) mais c’est aussi et surtout le gars que le MOE ne voit jamais. En effet, le CDP est souvent une chaise vide avec un manteau dessus et à la question « il est où le CDP ? » il convient de répondre non pas DTC (passez-moi l’expression), mais « en réunion ». Si ce n’est pas le cas, il y va ou en revient, ce qui est plus ou moins la même chose.
Le CDP doit également avoir un don très évolué d’ubiquité afin de toujours être sur plusieurs tâches à la fois sans faire trop d’heures supplémentaires (des fois qu’elles soient facturées).
En somme, CDP, c’est pour les gens qui aiment le conflit, se faire taper dessus de tous les côtés, être assis sur un siège éjectable, de préférence qui n’ont ni famille ni vie privée (pour ne pas les déconcentrer) et qui sont joignables 24h/24 7j/7 et qui peuvent revenir au bureau en un instant (y compris s’il est en vacances à l’autre bout du monde).
De là à ce qu’un pré requis soit d’aimer le fouet…

 
MOE : maîtrise d’œuvre.
Les MOE sont ceux qui font.
Ceux qui mettent les mains dans le cambouis (bah oui, mettre les mains dans le code et faire, c’est sale…).
En général, c’est ceux qui savent le plus comment fonctionne les différentes applications.
Il y a souvent une très forte tradition orale qui rend chacun des MOE dépositaire d’un savoir très ancien/volatil (aussi volatil qu’un MOE, en fait).
Mais c’est également le trouffion de base qui est considéré trop souvent comme un exécutant, une ressource qu’il est possible de changer comme d’une pièce mécanique défectueuse (et parfois avec le même respect…d’où la référence au mécanicien ?).
Accessoirement, c’est aussi les gens qui n’en ont rien à faire (pour rester poli) de la société car leur mission dure entre 3 mois en 3 ans (en moyenne) et qu’ils sont avant tout payé pour faire ce que le client dit de faire (et pas pour le faire bien).
Les premiers mois, ils ne font rien. Ah, pardon, ils prennent connaissance des méthodes de l’entreprise et des applications sur lesquelles ils devront intervenir.
Les trois derniers mois, ils ne font rien. Ah, pardon, ils préparent leur départ avec une passation de connaissances et mise à jour documentaire.
Et entre les deux ? Ils ne font rien. Mais faut trop pas que ça se voit !
Et puis bon, l’ingénieur, c’est un peu le méchant de l’histoire, le grognon qui va dire « non » à la moindre occasion (sauf pour les pauses café/clopes).
Alors, pourquoi est-il si méchant ? Des indices ici (attention, c’est en anglais et assez long, mais TRÈS pertinent) ou dans les billets qui vont suivre #teaser.

 
Exploitation.
Les gens qui se font exploiter. Ah non, pardon.
Plate-forme magique qui, à chaque fois qu’on l’appelle, permet de raconter son histoire à une personne nouvelle et inconnue qui ne connait pas l’application (puisqu’étant nouvelle) et tente désespérément (ou pas) de comprendre ce qui est dit et de paraître sûre d’elle (ou pas, si elle cède à la panique).
Le contact avec l’exploit est très binaire : soit tout va bien, soit tout va mal.
Etant donnés les processus imposés, le turn over très important, le fait que certains sont parachutés dans le domaine sans réelle compétence, qu’ils soient souvent sous l’eau et conscient d’être…exploité, il y a quand même plus de chances que ça se passe mal.

 
DBA : DataBase Administrators
Des gens qui administrent les bases de données, qui surveille que tout va bien, que la base est paisible et ronronne comme un chaton sous tranquillisants.
En théorie, les MOE peuvent leur demander de l’aide quand ils ont un problème avec une requête.
En pratique, les DBA n’ont pas forcément obligation de répondre.
Par contre, ils peuvent gueuler très très fort quand la base de données tombe (du serveur, en effet, ça lui arrive de rater une marche).

 
Architectes
Rôle très important chez certains clients, inexistant chez d’autres.
S’il existe un socle à respecter, c’est qu’en général il y a (eu) des architectes. Ils sont en effet supposés apporter un support et aider les MOE en cas de problèmes.
En pratique, s’ils existent, ils imputent leur temps sur le projet sans pour autant avoir une obligation de réponse.

 

Les notions utiles.

 
Documentation.
Série de livrables qui ne sont jamais livrés. Documents sous divers formats (souvent improbables) qui ne sont jamais mis à jour une fois créés.
La documentation peut être au choix : un cauchemar ou un élément salvateur.
Suivant les méthodes de gestion de projets, il peut y avoir un certain nombre de documents obligatoires. Dans ce cas, la forme prime au fond. Notamment quand des gens qui n’y connaissent rien vont les relire et dire « là, il manque un retrait de 1.5pt sur la marge ! » alors que le nom du projet n’est pas le bon.
Elle peut également être sujette à gage. Ainsi, c’est souvent le MOE qui s’en va qui doit s’y coller, un peu comme une punition de ses forfaits (définition 1) ou simplement pour meubler ses derniers jours.
Elle est aussi sujette à plaisanterie : « mais regarde dans la doc, c’est marqué. » Suivit d’un gros « LOL ».
Ceci dit, si elle est bien réalisée, pertinente et mise à jour (trois conditions peu souvent remplies), elle est d’une utilité sans faille et d’une aide sans borne.
Mais une documentation bien fait est une légende urbaine.

 
Gestion de projet.
Moyen pudique de dire que le projet est géré sans réelle méthode, ou en utilisant la méthode éprouvée (et éprouvante) de la Rache avec un Cycle en V.
Chose qui peut également justifier l’échec de projets et leur non aboutissement.
Je reviendrais sur la gestion de projet à l’occasion d’un autre billet, il y a, en effet, beaucoup à dire…

 
Jalons.
Les jalons sont des étapes, prenant souvent la forme de réunions (des comités de pilotages [copil] par exemple).
Au début du projet, les réunions sont relativement bon enfant, tout le monde il est beau, tout le monde il est gentil.
Au fil du temps, les réunions deviennent le lieu d’échanges de plus en plus appuyés puisque le projet « dérape » (comprendre qu’il n’est pas dans « les clous », qu’il est grave à la bourre, quoi).
Rapidement, l’incendie devient non maitrisable mais à force de sueur et de sang versés durant une gestation difficile, le projet arrive tout de même à son terme : soit abandonné, soit livré.
Dans le premier cas, il y a une phase de recherche de coupables ressemblant à une chasse aux sorcières qui finit le plus souvent par la crémation en place publique du CDP qui est (avec une hypocrisie remarquable) remercié pour ses « bons et loyaux services » (comprendre viré du jour au lendemain).
Si le projet a grave merdé, il est possible que des MOE fassent également partis du débarquement massif sous des arguments divers et variés (non productif, trop lent, mauvaise compréhension…).
Dans le second cas, la hiérarchie fait la fête car « ils » ont livrés dans les temps.
Le CDP reste en place, les MOE aussi. Ils ont parfois le droit à une petite tape sur la tête pour les féliciter.

 
Planning et fonctionnalités.
Au début d’un projet, des fonctionnalités sont définies (formant un périmètre).
D’après ses fonctionnalités, un délai est établit avec la méthode consommée du doigt mouillé.
Une date de début et surtout de fin sont donc fixées.
Des jalons sont posés de façon régulière le long de ce délai.
Cela donne le planning.
Il est admis que le planning ne sera que très peu souvent respecté ou, s’il est respecté, que le périmètre a été retaillé (à la hache à deux mains) pour que l’un (périmètre) rentre dans l’autre (planning). Un peu comme un enfant essaye de faire rentrer un carré dans un rond. En forçant, ça peut passer.

 
Projet.
Entité quasi vivante qui a une gestation toujours plus longue et difficile que prévu (bah oui, l’avant-projet, c’est has been…).
S’il est, sur un coup du sort ou sur un malentendu, mené plus ou moins à bien, il pourra avoir une vie longue (avec un nombre de MOE qui passe dessus conséquent), une vie courte (car ne répondant tellement pas au besoin que ça se voit) voir une vie totalement ignorée (y a des gens qui l’ont commandé, mais personne ne l’utilise, ce cas de figure est souvent utilisé pour "cramer le budget" ou plus communément "jeter l’argent par les fenêtres").

 
Réorganisation.
Faculté que possède la hiérarchie à jouer aux chaises musicales, à intégrer de nouveaux participants afin de diluer encore plus les responsabilités.
Une bonne réorganisation consiste également à traquer et chasser (parfois au sens littérale) les plus compétents pour, au choix : les placer à un poste où ils ne seront plus compétents du tout ou les remercier pour mettre une personne moins compétente à la place (mais dont le supérieur aura moins peur pour sa place).
Il est parfois possible que des chaises soient retirées et que le nombre de participants augmente. Cela donne la même impression qu’un grand magasin à l’ouverture des soldes.

Catégories:Divers, Humeur, Humour, MMIT
  1. 22/06/2012 à 12:59

    Très pratique ce vocabulaire ! Surtout pour s’y retrouver avec tous ces acronymes… Au début j’en perdais la tête !

    • 22/06/2012 à 13:41

      J’en rajouterais peut-être, à terme, mais à trop vouloir tout catégoriser…ça devient un peu le bordel… D’autant plus qu’il y en a beaucoup d’autres : EDB, GCL, IHM, RSSI, TMA, TRA et les variantes CDP = CP, IHM = GUI… et des approchants SSII, SSI, SI…
      Wikipédia en liste quelques uns.

  1. 21/06/2012 à 19:27

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 56 autres abonnés

%d bloggers like this: