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.
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.
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.
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é):
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é:
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!
La BI ça vous gagne! 
Je suis flatté mon petit poulet. Tu seras le meilleur ############ de tout Paris, que dis-je de la France, de l’Europe et du monde j’en suis sûr! Pour le reste très bon post, qui met bien en lumière les interrogations existentielles auxquelles nous avons tous fait ou auront à faire face.
Nice Post ! Une idée sur la notion de temps ?
Combien de temps (si tout se passe bien ) reste t’on à un poste ?
Les reconversions sont ils possibles ?
En conclusion j’aurais aimé savoir où vous vous situez M. Eiden ? Et je suis pas complétement sur le template Wow utilisé ! Les wawa c’est pour les filles.
L’article est difficile à aborder au début mais au fil de la lecture tout devient clair.
Ca te tente de venir présenter ça dans les écoles / sessions pour étudiants ?
Merci les gens 🙂
@Thomas : Difficile de parler de notion de temps, ça dépend beaucoup de chacun. La règle veut qu’on soit sénior dans un domaine en 5 ans, à raison de 2 expériences significatives par an (au moins 2 contextes différents de plus de 3 mois). Maintenant ça s’optimise, si tu as de la chance et que tu arrives à faire 4 missions différentes et passionnantes par an, ou encore si tu arrives dans une équipe compétentes qui te transmettra toutes les facettes dans la durée.
@Charles-Henri : Comme le souligne François, moi je suis ############! Plus sérieusement je ne fais pas de mystère, je suis juste en phase de transition. Je la termine et on en reparle. Pour mon passé: je suis parti de développeur junior et j’ai fait un peu de tout. Je pense pas être vraiment bleu foncé dans un domaine, je suis plutôt bleu moyen dans pas mal de disciplines, y compris hors mission. Enfin demande à David Joubert et il te dira que je suis rien du tout. Verre vide, verre plein… 😉
@Djeepy : Je me suis battu avec du tr/td pour faire la mise en forme des tableaux des compétences, mais ils restent quand même difficiles à aborder. J’avais une version toute jolie dans Excel mais j’ai préféré ne pas la mettre en image, histoire que le texte soit copiable/collable. Pas de problème pour présenter ça en école, ça peut servir de base à une série de questions/réponses. D’ailleurs n’hésite pas à repomper le truc si tu en as besoin.
j’aurai mis « Comment » sur l’aspect technologie et pas « quoi », car on est sur la maitrise de l’utilisation des outils et comme tu le dis ça permet d’avoir une capacité à réaliser, mais bon je chipotte
Romu tu as raison, je change 🙂
En parlant de changement, David Tang me propose d’inclure le Formateur comme expert de la relation utilisateur, je trouve ça excellent. J’essaye de mettre à jour le tableau rapidement!
Un truc étonnant signalé dans le post et avéré, c’est que le développeur junior entre par la techno sans connaissance du décisionnel. C’est un peu les temps modernes. J’ai l’impression que les projets et les carrières gagneraient à avoir des juniors avertis.
Thomas merci pour cette très bonne remarque! Je suis entièrement d’accord avec vous, sauf sur le fait que cet état de fait soit étonnant 😉
Comme pour toutes les compétences, ce qui est facile à apprendre ce sont les outils et leur utilisation – ceci est un marteau, ça se tient par le manche – par contre savoir quand et où planter un clou pour construire une maison ça vient plus avec l’expérience.
C’est d’ailleurs un peu antinomique puisque j’appelle ça la « théorie du décisionnel », et qu’ensuite je viens dire que ça s’apprend sur le tas… Mais à mon sens, et ça s’applique plus largement à n’importe quel domaine du software engineering, la réflexion de « pourquoi on fait ce qu’on fait » vient à la fois d’une base théorique apprise tôt et d’un allez/retour permanent entre le vécu et la littérature.
Beaucoup plus qu’avec les outils, où la pratique suffit souvent, pour la théorie il faut se poser des questions pour avancer.
Tout ça pour dire que oui, les juniors doivent connaître les bases, que ce soit pour leurs carrières et nos projets, et que oui je participe à l’effort de guerre en insistant lourdement pour que sur mes projets tout le monde ait lu les premiers chapitres d’au moins 1 des ouvrages de références (Datawarehouse Toolkit, SQLBI Methodology…).
Encore une fois merci pour cette très bonne remarque 😉
Bonjour,
Et si par exemple vous rajoutez les meilleurs références (livres, WebSite, Blogs …) qui conviennent pour s’améliorer dans chaque activité?
Enfin, j’en ai besoin, c’est pour ça je le propose 🙂
Iliyas,
En version courte, lisez la BI ça vous gagne, allez voir les vieux articles 😉
Et en plus:
– Technologies : tous les blogs BI que je link à droite. Sur Microsoft: les bouquins de certifs, pour Tableau, le bouquin de Freakalytics
– Théorie du décisionnel : Datawarehouse Toolkit de Kimball et SQLBI Methodology de Russo et Ferrari.
– Fonctionnel : Sur le tas
– Gestion de Projet : Making Things Happen de Scott Berkun, le Mythical Man Month dont je parlais tantôt. Sur le tas.
– Relation utilisateur : Sur le tas
– Dev Business : Il faut pratiquer
– Management et stratégie : confère les liens Business Strategy à droite
Bonne lecture!
Excellent article ! très bonne représentation des différents rôle !
J’aurais eu tendance à inverser la couleur : plus la maîtrise est faible, plus on est considéré comme bleu ! mais ça rendrait quand même le schéma beaucoup moins lisible.
ce que j’apprécie dans votre analyse, c’est la prise en compte du facteur temps : une carrière ne se construit pas en 1 ou 2 ans, l’expérience s’acquiert par la diversité des missions et surtout la capacité à « sortir de son ordinateur » pour comprendre son rôle dans le projet et le rôle du projet dans l’entreprise et pour l’utilisateur
le second point intéressant est le côté « proactif » : il ne faut pas attendre mais être acteur de son évolution professionnelle
Post clair et simple pour bien appréhender les différents métiers ! je recommande +1 !
Bonjour,
Merci pour cet article, très utile pour un consultant en début de carrière 🙂
Peut-on généraliser la matrice fonction/compétences aux carrières des autres consultants SI ?