Dilbert du 22/04/2012

Excellent celui là! Il contient tellement de thèmes récurrents sur ce blog en une seule planche 🙂

Traduction Approximative:

Boss: Vous avez des questions concernant le plan projet?

Dilbert: Si on considère toutes les taches ensembles, elles forment un plan rationnel.

Dilbert: Mais si on regarde nos taches individuelles, elles sont tellement loin du plan global qu’elles n’ont plus aucun sens.

Dilbert: Vous avez réussi à éliminer tout sens à ma vie.

Dilbert: Rationnellement, je comprend le bénéfice de découper les taches en petits morceaux.

Dilbert: Mais ça n’a tellement plus de sens qu’émotionnellement vous m’avez détruit. Ma volonté est anéantie.

Boss: Ne pouvez vous pas trouver du sens dans votre vie personnelle?

Tina: C’est un ingénieur.

Dilbert: Ça c’est méchant.

4 liens rapides pour la semaine (2012-16)

Que des classiques cette semaine:

  1. David Heinemeier Hansson de 37 Signals avec un petit rappel de bon sens face aux dérapages de valorisation de certaines start-ups.
  2. Marco Arment d’Instapaper qui commente la récente promesse de Twitter de ne pas faire de bêtises avec ses brevets.
  3. Garrett Murray de Karbon avec une belle satire de l’annonce d’Asus de rattraper le GPS défectueux de leur tablette par un dongle.
  4. Scott Berkun, que je citais encore précédemment, qui nous offre un extrait gratuit de son fameux Making Things Happen. Ça parle gestion de projet et développement personnel.

______________________

<< Semaine Précédente – Semaine Suivante >>

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!

Gestion de Projet Décisionnel – Méthodes Agiles ou Cycle en V ?

Après le choix de la technologie, je continue sur la réflexion lancée plus tôt autour du projet décisionnel. Cette fois-ci j’aimerais aborder la question de l’organisation du projet décisionnel, quelle méthodologie choisir, quel mode d’engagement, pour se garantir de réussir son datawarehouse (ou au minimum d’échouer avec élégance).

Avant de commencer, on peut se demander ce qui distingue un projet décisionnel d’un projet informatique classique. La réponse se limite en fait à un seul élément : la dépendance à une ou plusieurs sources de données externes. Cela peut paraître trivial mais c’est fondamental, car cela implique qu’un élément au cœur du projet n’est pas maîtrisé par les intervenants. Comment garantir un résultat, comment se prononcer sur des deadlines, quand un élément critique du projet n’est pas dans le domaine de responsabilité ? C’est la question qui doit rester dans la tête du chef de projet décisionnel quand il va choisir son organisation projet.

Au-delà de cette dépendance externe, il n’existe pas vraiment de différence avec un projet informatique classique. C’est un mythe qui a la peau dure, on aime tous se sentir un peu spéciaux, mais ça reste un mythe. En décisionnel on voit beaucoup les utilisateurs pour le design du reporting ? C’est pareil sur les applications qui disposent d’une interface – soient quasiment toutes. En décisionnel on gère de la complexité métier dans la modélisation ? C’est pareil pour les applications qui gèrent la production des flux métiers. En décisionnel on est déployé en petites équipes ? Ça arrive tout autant côté applicatif. En décisionnel on gère les sujets transverses de l’entreprise, ce qui est très politique ? Même combat au niveau des ERP, des CRM, du MDM… Non vraiment il n’existe pas vraiment d’autre différence.

Pour en revenir au sujet du jour, l’organisation du projet décisionnel, je vais tenter de faire court et organiser la réflexion autour de 3 questions :

  • Méthodes agiles ou Cycle en V… Comment arriver au but ?
  • Faire ou faire faire, faut-il appeler les consultants ?
  • Forfait ou régie, quel type de garantie fournir?

Pour ce premier article nous allons commencer par le choix de la méthode de gestion de projet : Méthodes agiles ou Cycle en V ?

La différence élémentaire entre les 2 vous la connaissez :

  • Les méthodes agiles sont itératives et participatives, on développe des petits morceaux d’application qui apportent de la valeur, qu’on fait valider par l’utilisateur avant de passer aux suivants. C’est l’utilisateur qui pilote au fur et à mesure le développement  à travers le choix des fonctionnalités qu’il souhaite voir développer. Un cycle de développement, une itération, prend 1 à 3 semaines.

Cycle de développement Agile

  • Le cycle en V repose lui sur un développement de bout en bout, c’est donc une délégation totale de la fabrication de l’application jusqu’à la livraison finale (lever de rideau !). Je veux un résultat, peu m’importe la route pour y arriver. Un cycle de développement prend plusieurs mois.Cycle de développement en V

Jusqu’à présent je pensais que cette dichotomie représentait bien l’écart entre les deux philosophies. Pourtant quand on y pense, et si on se concentre sur l’organisation projet et pas les valeurs que véhicule l’Agilité, une itération agile n’est rien d’autre qu’un mini cycle en V non ? On a une mini-spécification – la description de la fonctionnalité attendue – et toutes les phases classiques du cycle en V (conception, réalisation, recette, livraison). La différence entre les 2, encore une fois si on retire les valeurs de l’Agilité de l’équation, ne serait donc qu’un niveau de zoom sur l’échelle temporelle ?

Cette réflexion, et la réponse à cette question, m’est venue suite à la lecture de cet article d’un designer de 37 Signals : le dilemme de la documentation. L’idée principale de ce monsieur c’est que la volonté de créer, de changer, est un flux d’idées qui s’écoule comme une rivière. Si la productivité est suffisante, si la capacité à réaliser les idées est adaptée au volume du flux d’idées, tout va bien, la rivière s’écoule correctement. Par contre si la productivité est insuffisante, un goulet d’étranglement se forme, un lac de stockage apparaît.

Un océan de spécifications!

Deux possibilités existent alors :

  1. Soit on arrive à faire coïncider le volume du flux d’idées et la capacité de production pour retrouver un équilibre,
  2. Soit on stocke les idées sous la forme de documentation, de spécifications, dans l’attente de l’allocation de moyens de production.

Avec les méthodes agiles, on est dans la première possibilité. Le cycle en V correspond à la seconde.

Par rapport à votre projet, la vraie réflexion à avoir est donc : vais-je avoir une adéquation entre le flux de besoin et la capacité de production ?

Autrement dit : Mes utilisateurs sont-ils prêts à participer de manière active et régulière à mon projet ? Avec cette question on retombe sur nos pattes par rapport aux prérequis classiques de l’agilité. Les réponses :

  • Oui, je suis dans le cas 1, je peux faire de l’itération rapide sur le besoin > Méthode Agile
  • Non, je suis dans le cas 2, je vais devoir documenter mon besoin pour ne pas le perdre > Cycle en V

Un argument qui revient souvent en faveur du cycle en V, c’est que les spécifications sont un engagement sur le livrable qui permet de contourner le problème de confiance qu’on peut avoir avec l’exécutant. En effet : ne pas avoir confiance dans les moyens de production contribue au goulet d’étranglement, c’est un frein à l’innovation, le flux des besoins ne s’écoule pas correctement : il faut documenter pour stocker les idées.

J’ai déjà entendu que l’absence de maturité des utilisateurs était un obstacle à l’Agilité. Je ne suis pas d’accord, dans cette situation c’est le flux d’idées qui est contraint. J’aurai donc même tendance à penser l’inverse : un flux de besoin faible nécessitera une faible capacité de production, on pourra donc facilement arriver à une adéquation (solution 1). Par contre l’absence de maturité de l’équipe de développement est définitivement un frein à l’Agilité puisqu’on diminue la capacité de production, on rejoint le problème de confiance (solution 2).

Enfin, des sources de données de faible qualité sont un frein majeur à la capacité de production. Si vous savez que les auteurs des sources sont réactifs : privilégiez l’Agilité, dans tous les autres cas, commencez à spécifier…

D’une manière générale, chaque contrainte de votre projet doit être classée entre « frein à l’innovation » ou « frein à la capacité de production ». En fonction de l’équilibre vous saurez quelle méthode choisir.

Wow, j’écris sans trop regarder et je me rends compte que c’est déjà beaucoup trop long… Je coupe donc cet article ici, il me restera quelques points à traiter sur l’Agilité (les valeurs, comment découper son datawarehouse en fonctionnalités unitaires) et le cycle en V (positionnement MOA vs MOE), et on pourra passer aux questions suivantes :

  • Faire ou faire faire, faut-il appeler les consultants ?
  • Forfait ou régie, quel type de garantie fournir?

En attendant j’espère vous avoir donné une clef de lecture actionnable pour que vous puissiez répondre à la question : Cycle en V ou Méthodes Agiles pour mon projet décisionnel?

Dilbert du 22/11/2011

Comme à l’armée, quand il y a plus de chefs que de soldats, c’est qu’il y a un problème!

Dilbert du 22/11/2011

Traduction approximative:

Dilbert: Maman, la bonne nouvelle que je voulais t’annoncer c’est que j’ai été promu chef de projet.

Sa maman: Ne le dis à personne, j’ai raconté à tous mes amis que tu étais serrurier.

Dilbert: C’est toi qui invite!

Le serveur: Bonjour, je suis Ed, je serai votre chef de projet ce soir.

Gestion de projet décisionnel : gardez vos utilisateurs proches de vous!

Entendu par un camarade consultant la semaine dernière dans l’open-space chez son client, c’est le directeur des études qui s’adresse à la chef de projet MOA : « Il faut arrêter de mettre tout le monde dans vos mails! Si vous parlez au métier, ne mettez pas la MOE en copie et inversement. Il ne faut pas qu’ils communiquent directement! ».

Mes dents grincent…

J’insiste lourdement sur ce point dans ma session sur la modélisation dimensionnelle, construire un datawarehouse sans les utilisateurs, sans les métiers, c’est le chemin direct vers les projets les plus frustrants qu’il soit.

Mais d’abord un peu de vocabulaire. Notez que ce ne sont pas des définitions absolues: c’est ma vision de la chose, et cela nous permettra juste de ne pas discuter pendant 3h pour se rendre compte à la fin qu’on était d’accord depuis le début:

  •  Côté Cycle en V (on spécifie un sujet de bout en bout, on développe tout d’un coup, on livre tout d’un coup – échelle temporelle : le mois)
  • Métier / Utilisateur : Au sens strict, les gens qui utiliseront le système. Donc ça exclut les sponsors, les acheteurs, et tous les gens qui passent leur temps en réunion mais qui ne produisent rien.
  • MOA : Maîtrise d’Ouvrage. Les métiers passent commande auprès de la MOA d’une solution à un de leurs problèmes. La MOA va écrire un cahier des charges qui décrit la solution le problème et les attributs essentiels de la solution (MàJ 26/12/11 – précision). Ils connaissent bien les problèmes que les métiers ont l’habitude de rencontrer et les solutions usuelles qui y répondent. Ils savent quelle(s) MOE impliquer pour chaque solution.
  • MOE : Maîtrise d’Œuvre. Réalise les solutions. Plusieurs MOE aux capacités distinctes peuvent intervenir sur une même solution.
  • AMOA : Assistance à la MOA. En informatique, unité spéciale de la MOE qui à force de réaliser des solutions commence à bien connaître les problèmes. Va filer un coup de main à la MOA quand les sujets deviennent complexes.
  • PMO : Projet Management Office. Les gens qui suivent les plannings et les budgets au niveau global. Ils ne produisent rien au niveau projet.
  • Côté Agile (on définit un besoin unitaire, on le développe, on livre uniquement la solution locale, on itère – échelle temporelle : la semaine), les termes correspondent ici à la méthodologie SCRUM:
  • Product Owner : Son nom est écrit sur le produit. Son activité principale c’est la bonne tenue du backlog au niveau produit – la liste ordonnée par priorité des fonctionnalités qu’on veut voir apparaître. Notez qu’il ne doit pas forcément écrire lui-même toutes les users stories (la description des fonctionnalités), mais il doit travailler à ce qu’elles soient le plus clair possible et que leur ordre corresponde effectivement à la valeur métier qu’elles apportent.
  • SCRUM Master (ou équivalent) : Garant de la bonne application de la méthodologie. Son but à terme c’est de ne plus avoir de boulot! En effet si tout le monde joue bien le jeu, plus besoin de lui 😉
  • Equipe de développement : Tous les contributeurs qui permettent la livraison des besoins unitaires.

Maintenant que c’est clair, on peut revenir au sujet du jour. L’étape n°0 pour la modélisation de son datawarehouse c’est identifier ses utilisateurs clefs, et se garantir un accès direct à leur calendrier. Pour moi c’est juste indispensable. C’est la raison pour laquelle j’aime beaucoup la philosophie Agile. Peu importe la méthodologie Agile choisie (la plupart du temps je n’utilise qu’un mini SCRUM à ma sauce), ce qui compte c’est de délivrer de la valeur, rapidement. Certes ça a un coût sur l’emploi du temps du Product Owner, mais on obtient des solutions qui répondent beaucoup mieux aux besoins des utilisateurs.

Mais quand on est en cycle en V, on n’accède pas directement aux utilisateurs, on doit passer par la MOA. Et là il faut que les rôles de chacun soient clairs : la MOA n’est pas là pour faire écran entre les métiers et la MOE.

Dans un premier temps, la MOA est là pour comprendre le besoin métier et choisir la MOE qui saura réaliser la solution.

Une fois ce choix fait, elle est là pour faciliter les échanges entre les métiers et la MOE. C’est un rôle d’interprète et de diplomate. Interprète pour que tout le monde se comprenne – expliquer le métier aux techniques et les contraintes techniques aux métiers. Diplomate pour faire coïncider les objectifs de tout le monde: un besoin théorique parfait pour les utilisateurs VS la dure réalité technique imparfaite de la MOE.

De la même manière qu’un interprète ne remplace pas un interlocuteur dans un dialogue, la MOA ne doit pas occulter la MOE. D’où mes dents qui grincent quand j’entends un directeur des études dire l’inverse…

En tant qu’architecte j’ai un problème supplémentaire pendant les cycles en V (en plus des problèmes habituels des architectes). Je m’occupe de l’architecture technique, activité clairement MOE, mais également de l’architecture fonctionnelle, à savoir la modélisation dimensionnelle à proprement parler. Je réponds entre autres aux questions suivantes:

  • Quelles sont mes dimensions?
  • Quelles sont mes mesures?
  • Quel processus métier modéliser dans la table de fait?

Et ça ce sont des questions qui ont souvent déjà des réponses dans le cahier des charges rédigé par la MOA. Si les MOA sont éclairées, les réponses sont bonnes, ou au minimum elles ne sont pas figées dans le marbre. Le problème survient quand les réponses ne sont pas optimales et qu’elles ont déjà été promises à l’utilisateur. Là pas de remède miracle à part une bonne dose de diplomatie et pédagogie.

L’autre problème c’est quand une technologie est choisie par la MOA: « Mon utilisateur veut un cube pour faire des tableaux croisés dynamiques sur les 500’000 clients dans les 100’000 portefeuilles et afficher le détail »… Pour ceux qui ne connaissent pas les technos, c’est l’équivalent de choisir un semi-remorque pour rouler en ville parce qu’on aime bien la taille du coffre. Le choix d’une technologie pour un projet décisionnel n’est pas une décision anodine. Inclure la MOE dans ce choix est une évidence qu’il faut malheureusement souvent rappeler.

Désolé pour le pavé, mais il fallait que ça sorte 😉

Prochains sujets : choisir la bonne gestion de projet pour son projet décisionnel (Agile vs Cycle en V), et choisir la bonne technologie dans l’écosystème Microsoft.