Bataille d’experts : fournir les bons arguments à son DSI pour trancher sur des sujets techniques

Avec la fonction d’architecte, et plus globalement la séniorité (autrement dit la vieillesse, oui, merci…), vient la responsabilité un peu particulière d’arbitrer les désaccords sur des sujets techniques. Si la plupart du temps l’expérience permet de trancher immédiatement une discussion, il apparaît régulièrement des débats où une théorie vaut l’autre. Soit ça, soit un des acteurs fait preuve d’un dévouement sans faille à son idée et refuse la sagesse de ses aînés. Très saine attitude soit dit en passant.

Quand il y a peu d’enjeu, ou que ces débats ont lieu assez tôt dans le projet, on réalise des prototypes, on teste, et si le perdant est un gentleman, toute l’opération prend une tournure sympathique. C’est d’ailleurs plutôt sain de laisser s’exprimer tous les avis, et de tester effectivement où se situe la vérité. Tout le monde apprend énormément, on disperse les mythes issus du culte du cargo, les tensions s’apaisent et j’irais même jusqu’à dire que le respect nait entre les participants.

A l’autre extrême se situent les batailles d’experts sur des sujets ultra pointus, avec toute la direction en arbitrage, des centaines de K€ de facturation dans la balance et des relations client/fournisseur au bord du gouffre, et là on rigole beaucoup moins.

Tableau "Les Sabines" par Jacques-Louis David - Une bataille de l'antiquité avec des gens tout nus

Depuis les consultants portent des costumes, et c’est quand même moins gênant.

J’ai vécu ce type d’escalade plusieurs fois dans ma carrière, et l’une d’elles est suffisamment éloignée dans le temps pour que je puisse en parler sans fâcher personne, surtout qu’aujourd’hui je commence à croire que j’avais tort – je vais y venir.

J’étais donc employé chez un grand nom du BTP, en interne et non comme consultant, et j’étais en charge du pôle de développement pour la plateforme décisionnelle des ressources humaines. En gros je gérais une petite équipe de développeurs en mode projet sur le domaine RH, en tant que manager et chef de projet, et dans mes objectifs j’avais également pour fonction d’assurer la qualité, la maintenabilité et l’évolutivité des applications de mon périmètre.

Une des plus grosses applications de ce dit périmètre était évidemment la plateforme de reporting aux 1’500 responsables de paye du groupe (en SSRS), appuyé sur un datawarehouse (SQL Server) d’un beau gabarit pour suivre les 70’000 collaborateurs du groupe.

L'armée de Terracotta

Heureusement, on ne modélise plus les datawarehouses en 1:1

Il est à noter que cette application m’avait précédée dans la société, elle avait été réalisée par un prestataire que je ne nommerai pas. Moi j’étais arrivé à peu près au moment du passage au lot 2 sur 8, avec un lot 1 globalement validé et déployé en production.

Vous vous doutez bien que si le DSI avait décidé d’internaliser les chefs de projet (moi côté réalisation, un très bon camarade côté étude), c’est que ça coinçait dans son rapport avec le prestataire. Les consultants ayant complétement séduit leur client – la DRH – ils se permettaient des comportements inexcusables vis-à-vis des acteurs de la DSI.

Notre rôle était donc de restaurer l’équilibre dans le projet en apportant la compétence décisionnelle côté DSI. Je n’ai jamais eu le détail du plan de bataille du DSI, mais rétrospectivement je pense que l’objectif était de prouver que la solution n’était pas très propre techniquement, pour décrédibiliser le prestataire auprès de la MOA (la DRH) et le remplacer. Aujourd’hui j’ai appris ma leçon : vouloir régler des problèmes politiques avec des arguments techniques, ça ne marche pas. A l’époque j’étais encore utopiste, donc je me suis lancé.

Un soldat qui utilise une guitare à la place d'un fusil

Bien choisir ses armes, c’est important.

Et sur le plan technique, il y avait beaucoup à dire sur cette solution. Modélisation dimensionnelle déplorable (200+ dimensions, en flocon et en étoile en même temps, SCD implémentés dans la table de fait…), ETL en procédures stockées (100+), plus de 150 tables d’agrégats, bugs de sécurité critiques sur SSRS, etc. etc. J’ai monté un dossier de 50 pages sur le sujet et évidemment on a convoqué le directeur technique du prestataire, responsable de l’architecture, pour discuter de tout ça.

Ce qu’il en ressort, c’est qu’avec beaucoup d’assurance, voire d’arrogance, on fait avaler n’importe quelle couleuvre technique à un décideur. Et c’était à prévoir : un DSI comprend des questions de performance, de fonctionnalités, de livraison et de MOA satisfaite. L’élégance du code, la beauté d’une normalisation, le respect des bonnes pratiques, ce n’est pas vraiment son problème tant qu’ils ne s’illustrent pas par des jours-hommes, à travers une facturation qui explose ou des retards incontrôlés. Donc oui, il était d’accord avec nous sur le principe, mais nos arguments techniques ne lui ont jamais permis de gagner l’avis du DRH face à la solution effectivement déployée, effectivement accessible aux utilisateurs et à peu près performante.

Et c’est là que tient la réponse à la question posée par cet article : comment fournir des bons arguments à son DSI pour l’aider à trancher un sujet technique ?

  1. Illustrez vos arguments techniques par des impacts projets forts. Donnez des chiffres (performances, coût de maintenance à N+1, coût des régressions, coût du support, surcharges sur les développements, effondrement du ROI…), rappelez les risques sur l’évolutivité, la difficulté à trouver un prestataire de remplacement qui s’engagera à cause de la spécificité des développements… Et illustrez tout ça, faites des prototypes, calculez les performances, faites des plannings qui prouvent ce que vous avancez. Apportez des éléments concrets qui ont du poids dans le référentiel de valeur de votre décideur.
  2. Et attendez votre heure. Cela ne sert à rien d’avoir raison trop tôt. Choisissez vos batailles, ne partez pas en croisade contre la terre entière, soyez patient. Il vous faudra attendre qu’on vienne vous chercher, qu’on ait besoin de vous, pour avoir un impact quelconque sur la situation. Par contre soyez prêt quand le moment viendra (confère point 1). Attention, je ne dis pas de rester en sous-marin et de ne pas lever d’alertes, au contraire : donnez votre avis franc, honnête et informez votre hiérarchie de ce que vous percevez. Mais sachez accepter votre destin, jusqu’au moment où l’opportunité de faire changer les choses apparaîtra. On ne sait jamais la carrière de qui, là-haut dans la direction, dépend de la réussite ou de l’échec du projet…

Et si vous n’arrivez vraiment plus à supporter votre quotidien, comprenez que c’est vous qui n’êtes pas à la bonne place, et pas l’inverse.

Pour conclure, pourquoi ai-je dit qu’aujourd’hui je pensais avoir eu tort à l’époque? Parce qu’au final : ok le prestataire était 2 fois plus cher que les prix du marché (vraiment fois 2), ok la modélisation était inacceptable, ok la qualité de données n’aurait jamais réussi à dépasser 90% de précision et ok les coûts de maintenance étaient partis pour exploser, mais le reporting sortait et la MOA était satisfaite du deal. Tout est là : je suis parti en croisade avec des arguments purement techniques (point 1) alors qu’à cet instant t, le système donnait satisfaction à ses utilisateurs (point 2), et trop contents d’avoir enfin un vrai reporting automatisé, ils n’étaient absolument pas concernés par le moyen terme. C’était donc perdu d’avance.

Aujourd’hui ce que je me dis c’est qu’il y a suffisamment de gens qui ont besoin d’aide et qui le demandent, pour ne pas vouloir aller aider ceux qui estiment ne pas en avoir besoin. Tout du moins pour un consultant décisionnel hein, si vous êtes médecin ou pompier ce n’est pas la même histoire…

MàJ 16/10/2012 : Si vous avez lu jusqu’à la fin, vous serez surement intéressé de savoir que j’ai écrit depuis l’article symétrique: Savoir trancher un sujet technique lorsqu’on est DSI.

PS : Salut aux camarades tombés pour la cause, ils se reconnaitront 😉

Les différentes carrières du consultant décisionnel

Je vous parlais précédemment du métier de consultant et de la veille technologique associée, et cela m’a lancé sur une réflexion autour des différentes facettes que l’on regroupe sous ce titre.

L’objectif de cet article est plutôt simple : mieux percevoir l’activité du consultant, savoir quelles sont les compétences à travailler pour progresser et également quelles sont les possibilités d’évolutions qui s’ouvrent à ceux qui prennent leur carrière en main.

Cette vision de la chose est issue de mon expérience personnelle. Je suis donc évidemment preneur de votre retour sur le sujet, d’autant plus si vous utilisez une grille de lecture précise qui diffère de celle qui suit.

Pour faire simple je vais découper l’activité du consultant sur 5+2 domaines de compétences, 5 qui s’appliquent en mission, 2 en dehors. Je regrouperai ensuite ces domaines en 8 carrières classiques, ce qui permettra à chacun d’identifier son positionnement et le titre qui lui convient.

Choix de carrière sur les SIMS Social

On commence donc avec les domaines de compétences en mission:

En Mission


Technologies

Activités Connaissance des outils. Capacité à réaliser.
Question associée Comment faire
Progression Par techno, niveau de 1 à 5 : SSIS / SSAS / SSRS / SQL / DAX / MDX …

Théorie du Décisionnel

Activités Capacité à concevoir des solutions. Connaissance des techniques, de la modélisation.
Question associée Quoi faire
Progression Compréhension de l’activité, qualité des modèles, justesse des propositions et remarques…

Fonctionnel

Activités Connaissance des problématiques clients (RH, Finance, Retail, Industrie…).
Question associée Pourquoi le faire
Progression A travers les projets, en diversité, nombre et profondeur…

Gestion de Projet

Activités Faciliter le quotidien, gérer la logistique dans la mission, suivre l’avancement.
Question associée Quand / Combien
Progression Nb et type de projet (forfait / régie), méthodologies (V, Agile), outils planning et budget…

Relation Utilisateur

Activités Recueil du besoin, conduite du changement, assistance à la recette.
Question associée Qui
Progression Aisance générale, qualité des livrables, forme des presentations…

Plus 2 domaines de compétence hors mission:

Hors Mission


Développement du Business

Activités Avant ventes, construction de l’offre, contribution à l’image publique (blog, whitepaper…)
Périmètre Extérieur à l’entreprise
Progression Réussite des A/V, qualité de l’offre, qualité de l’image (appels entrants, canditatures spontanées…)

Management

Activités Gestion du groupe, formation, logistique entre les missions, accompagnement dans la carrière.
Périmètre Dans l’entreprise
Progression Qualité de la vision à long terme, Satisfaction des consultants, faiblesse du turnover, cooptation

Maintenant qu’on a identifié les compétences, on va pouvoir positionner notre premier métier de consultant : le développeur junior, sur la grille.

Les compétences du Développeur Junior

Son premier chemin d’évolution naturel est de monter en compétence sur les technos, de prendre du recul et commencer à penser solution (théorie du décisionnel) et d’apprendre le fonctionnel à travers ses missions. Plus le bleu est sombre et plus la maîtrise est grande.

Compétences des Développeurs

Mais devenir développeur sénior n’est pas sa seule option, il peut choisir d’évoluer vers les autres métiers du décisionnel, qu’on identifiera à partir de leur compétence majeure (bleu foncé):

Métiers du Décisionnel

On peut noter l’absence d’un expert de la relation client, qui à mon sens est en dehors du périmètre du consulting décisionnel et plus dans l’organisationnel. (Update 18/04/2012) David Tang me propose d’inclure le Formateur comme expert de la relation utilisateur, je trouve ça excellent, l’article est mis à jour en conséquence.

Cette liste je la reprends ici:

  • Développeur : Il a déjà de nombreux projets derrière lui, il connaît les produits, les technos, il sait industrialiser les solutions, il développe en solo ou en équipe. Dans tous les cas, dans toutes les situations, il livre.
  • Expert Technique : Il connaît les produits par coeur, toutes les astuces, tous les bugs classiques, toutes les optimisations. C’est lui qu’on appelle pour décoincer une production récalcitrante ou réussir à implémenter cette fonctionnalité qui nous résiste.
  • Architecte : Il voit la solution de bout en bout, fabrique les prototypes, modélise le datawarehouse. C’est lui qui fait la jointure entre la technique et le fonctionnel, le guerrier du « Many to Many », c’est l’évangéliste de Kimball 😉
  • Consultant AMOA – Assistance à Maîtrise d’Ouvrage: Lui sa spécialité c’est les problématiques des clients. Il connaît les métiers (la RH, le retail…), il sait parler aux utilisateurs pour extraire et transmettre les spécificités de leurs besoins aux autres membres de l’équipe.
  • Chef de Projet : J’ai une notion très « Berkunienne » du chef de projet. Pour moi ce n’est pas un manageur, il ne dirige pas des hommes. C’est plutôt un facilitateur, qui fait tout pour que le projet se déroule sans accroc, pour que les autres membres puissent bosser tranquillement. C’est lui qui surveillera les plannings et les rapportera à qui de droit.
  • Formateur : C’est lui qui répand la bonne parole, et les bonnes pratiques, à travers les centres de formation. C’est également lui qui met en place les événements, prépare les présentations et animation, et entretient l’effort de veille technologique au niveau du pôle.
  • Ingénieur Avant Vente : Il accompagne les commerciaux en avant-vente, c’est lui qui gagne les missions et qui prépare l’arrivée de l’équipe projet. Evidemment il connaît le domaine décisionnel puisqu’il répond aux appels d’offres et participe aux chiffrages, qu’il anime des séminaires et qu’il représente l’équipe sur les salons. Il faut l’aimer, puisque c’est lui qui empêche les commerciaux de dire oui à tout 🙂
  • Chef de Pôle : Le vrai manageur de la troupe, il accompagne les consultants dans leur carrière sur la durée.

Évidemment ces rôles ne sont pas exclusifs, on assume tous très souvent plusieurs casquettes en même temps, lorsque le périmètre est petit ou que les compétences manquent. Typiquement: le chef de projet / expert technique, qui encadre les juniors et répond à leurs questions techniques tout en remplissant les plannings quand il a le temps. On a aussi le chef de pôle / ingénieur avant-vente, tant que le pôle fait moins de 20 personnes. Et toutes les autres combinaisons qu’on peut imaginer.

Cela dit, et pour éviter de se diluer, il est bon de donner une orientation majeure à sa carrière, et donc de choisir un titre de prédilection dans la liste. Une fois qu’on a ce point de départ, on peut se projeter et choisir où l’on souhaite se retrouver dans 5 ans.

La progression s’effectue alors sur 2 axes: le premier c’est ajouter du bleu clair dans de nouvelles cases, et donc potentiellement agrandir sa collection de titre comme on collectionne les pokémons. Le second c’est foncer le bleu dans une case, et donc gagner en expertise sur un sujet. De cette manière on retrouve aussi les pokémons, sauf que cette fois ils évoluent:

  • Le développeur s’endurcit, il sait réaliser tous les caprices exprimés dans les spécifications et jongle avec les 35 étapes requises pour la montée en production
  • L’expert technique gagne en reconnaissance: confère Marco Russo, Chris Webb ou François Jehl, pour rester en Europe
  • L’architecte se séniorise, et invente de nouveaux frameworks… Certainement l’évolution la plus casse gueule
  • Le consultant AMOA devient directeur d’étude
  • Le chef de projet devient directeur de projet
  • Le formateur devient évangéliste, que ce soit auprès de l’éditeur ou pour sa société
  • L’ingénieur avant-vente devient responsable commercial
  • Et le chef de pôle grandit avec sa troupe. Diriger 100 personnes ce n’est pas la même chose qu’en diriger 5.

Faîtes le bilan d’où vous en êtes, choisissez votre chemin de progression, et le tour est joué! Vous ne sécherez plus lors du prochain entretien quand on vous demandera « vous vous voyez où dans 5 ans? », votre arbre de compétences sera déjà tout tracé:

Arbre de compétences - World of Warcraft

Apprendre un nouveau langage de programmation ou lire un bouquin de méthodologie? Choisissez l’option qui correspond à votre plan de carrière. On vous propose 2 missions, l’une orientée AMOA et l’autre gestion de projet? Même combat: choisissez la compétence qui est sur votre chemin de croissance. Formez vous en ligne, montrez votre travail à travers un blog ou une contribution Open Source… Soyez actifs, décidez de votre avenir et vous arriverez au but 🙂

Pour conclure sur ce sujet je m’adresse aux chefs de pôle et/ou aux responsables RH. Si vous en utilisez un, je pense qu’il est très bon de coupler le référentiel de compétences avec votre grille de rémunération pour obtenir des salaires distribués de manière objective (cf Joel Spolsky). Rien de tel pour motiver vos collaborateurs à prendre en main leur carrière. Tout le monde est gagnant!

Un beau métier? Architecte des étoiles!

La base de cet article est un pavé écrit par Venkatesh Rao de Ribbonfarm: celui-ci.

Pour moi c’est à lire absolument, et d’autant plus si vous êtes dans un de ces deux cas:

  • Vous travaillez avec un architecte des étoiles,
  • Vous êtes en train de modéliser la réalité pour en faire une application, et ça commence à faire mal à la tête.

Qu’est ce que j’appelle un architecte des étoiles? C’est un architecte perdu pour la cause dans son délire mégalo-maniaque de modéliser le monde entier dans son application.

Les symptômes?

  • Le modèle de l’application qui comporte trop de niveaux d’abstractions (faire un ETL avec un ETL, redévelopper SSAS dans SQL Server…),
  • Le modèle que plus personne ne comprend de bout en bout à part l’architecte des étoiles,
  • Le projet qui inclut le développement d’un framework (alerte rouge),
  • La documentation qui fait plus de 200 pages…
  • Le fait que les développeurs passent plus de temps à coder des « corrections » des outils de dev que pour implémenter l’application

Ce qui nous ramène à l’article de Ribbonfarm, qui vient nous expliquer comment naissent ces délires étoilés:

  1. Tout commence quand on regarde une réalité complexe et déroutante, avec pour volonté de l’analyser,
  2. Cette réalité étant complexe, on échoue à répétition à intégrer toutes les subtilités dans son analyse,
  3. On attribue alors cet échec (et la frustration qui va avec) à une irrationalité supposée de ce qu’on analyse plutôt qu’à ses propres limites,
  4. On invente alors une version de la réalité telle qu’elle devrait être,
  5. On impose ensuite cette vision comme vérité, quitte à détruire la réalité qui existait avant,
  6. Enfin on regarde l’impossible utopie élaborée avec amour échouer lamentablement

Toutes ces étapes sont naturelles, humaines, il ne sert à rien de vouloir les éviter absolument.

Ce qui est important, c’est que lorsque ça commence à faire mal (étape 3, étape 6), on arrive à mettre son amour propre de côté et repartir de 0. A force d’itération la connaissance et la compréhension vont s’améliorer, un modèle correct finira donc bien par émerger tôt ou tard. Bien évidemment, une itération prenant du temps, il faut donc mieux itérer sur des maquettes, voir des prototypes, pendant une grosse phase de conception, plutôt qu’itérer sur des cycles de développements complets à 200 jours-hommes pièce…

Vous pouvez maintenant vous demander qu’est ce qui différencie l’architecte étoilé de ses pairs, si la nature humaine force tout le monde à suivre le même chemin de croix? C’est son manque définitif de remise en question lorsque tout s’écroule qui l’identifie clairement: son modèle était parfait, ce n’est quand même pas de sa faute si les développeurs étaient si bêtes!