Catégorie Divers

Le changement c’est maintenant!

Fleid 12 commentaires

Rien à voir avec les élections, sauf que pour moi aussi c’est le changement !
Je reviens de vacances, et je reprends la BI ça vous gagne en main, en vous annonçant que j’ai changé de société de conseil pour rejoindre BIOS Consulting. En effet les directeurs associés de BIOS m’ont fait une belle offre pour monter un pôle Tableau Software, j’avais besoin d’air frais, donc j’ai accepté !

BIOS ça peut vous rappeler quelque chose, en effet c’est l’ancienne société d’Aurélien Koppel avant qu’il ne se fasse débaucher par Microsoft. Aujourd’hui c’est Thomas Morisson qui a pris sa place, et moi « j’abandonne » la BI Microsoft pour faire du Tableau. Je mets des guillemets parce que ce n’est juste pas possible, j’aime trop ça pour tout lâcher et  je suis sûr que Thomas saura me débaucher de temps en temps pour lui filer un coup de main 🙂

En attendant me voilà « Chef de pôle – Tableau Software », et je trouve que ça claque bien 😉

On peut se demander pourquoi changer de technologie, surtout alors que SQL Server 2012 déboule avec tous ses nouveaux jouets.

En fait cela vient d’un constat simple : l’offre décisionnelle Microsoft manque vraiment d’un réel outil de visualisation/exploration des données. On en reparlera en détail plus tard – je ferai surement toute une série d’articles sur tous ces produits et Tableau – mais PowerPivot est tout sauf visuel, et Power View est… comment dire ça sans fâcher personne… jeune ?
Donc on a beau faire le plus beau datawarehouse du monde, si le client voit une interface moche, ou ne peut accéder à ses données qu’à travers Excel, c’est difficile de l’en convaincre. Et ça gâche un peu la réussite de la mission. Tout ça Stephen Few en parle bien mieux que moi (et ça dès 2010…), à voir par là.

Et Tableau c’est aussi un produit qui est simple, efficace et puissant, facile à apprendre, et qui permet donc de se consacrer à la problématique du client plutôt qu’à la technique désobéissante. Parfaitement alignée avec ma philosophie tout ça !
Bon bin y’a du boulot, que ce soit sur la montée en compétence ou sur la construction de l’offre. Je vous tiendrai évidemment au courant au fur et à mesure. Souhaitez-moi bonne chance 😉

The Mythical Man-Month – Frederick P. Brooks, Jr.

Fleid 2 commentaires

J’ai profité de mes dernières vacances pour lire « The Mythical Man-Month » (Amazon) de Frederick P. Brooks, Jr. (un des ténors du génie logiciel).

C’est LE livre qui apparaît systématiquement dans les tops 10 des livres à lire pour les ingénieurs logiciels, chefs de projet, développeurs ou encore manageurs de développeurs.

Même si l’édition originale date de 1975, et l’édition anniversaire de 1995, la plupart du contenu reste entièrement d’actualité, puisqu’il s’agit principalement de bon sens. Enfin surement qu’à l’époque beaucoup des choses qu’il raconte étaient nouvelles. Aujourd’hui elles font partie – ou devraient faire partie – de la culture de base de l’informaticien au sens large

Je vous livre quelques idées du bouquin histoire de bien cerner l’ouvrage :

  • (p5,6) On peut étendre un programme en travaillant sur son industrialisation (généralisation, documentation, tests, maintenance…) ou sur son intégration (interfaçages à d’autres systèmes, intégration dans l’écosystème de l’IT), mais pas les 2 en même temps.
  • (p16-19) Ajouter des développeurs à un projet en retard le retardera encore plus, aussi connu sous « 9 femmes enceintes ne font pas un bébé en un mois ».
  • (p32-36) Il propose une méthode d’organisation pour les très gros projets : mettre en place N équipes de 10 personnes chacune centrées autour d’un lead programmer (le chirurgien, un mec ultra talentueux), son copilote (le même en un peu plus junior, qui apprend et vérifie), les 2 seuls à développer et une équipe de support.
  • (p45,46) Définition de l’architecte (il le sous-entend fonctionnel – la MOA quoi) : qui représente l’intérêt de l’utilisateur, qui doit indiquer quel est le résultat attendu mais pas comment cela doit être fait. Par opposition au constructeur (la MOE), qui lui prend en compte les contraintes et le ratio coût/performance, et conçoit  la solution. Ce qui amène un cycle de développement : Architecture (MOA – On définit la fonction d’une boîte noire) > Implémentation (MOE –  On établit le contenu de la boîte) > Réalisation (MOE – On fabrique la boîte). Ne vous offusquez pas sur son choix de vocabulaire, qui diffère de ce qu’on a l’habitude d’employer en France, l’important c’est le découpage des tâches et des responsabilités.
  • (p62) Les spécifications sont le manuel utilisateur.
  • (p116) Le mieux est de toujours commencer par un prototype, jetable ci-besoin, plutôt que de vouloir y arriver du premier coup, puisque la plupart du temps on recommencera plusieurs fois du début.
  • (p117) Tous les besoins utilisateurs ne doivent pas être pris en compte dans le design. Et plus on avance dans le projet, plus c’est vrai.
  • (p142) Il faut tester les spécifications : faire des maquettes, tester les règles de gestion, avant même de commencer le développement.
  • (p143) Le mieux est de faire des programmes modulaires, afin d’augmenter la capacité d’adaptation du système (En 1975 manifestement ce n’était pas évident ;)).
  • (p155) Les jalons sur le planning doivent être clairement identifiés (périmètre et date), afin de ne pas pouvoir se mentir à soi-même par rapport à l’avancement.
  • (p157) Un directeur de projet ne doit pas intervenir dès le premier retard d’un de ses chefs de projet, sans quoi ils arrêteront de rapporter les glissements pour fuir le micromanagement.
  • (p201) Le développement itératif c’est le top (En 1975 ! C’était révolutionnaire !)

Évidemment il y a plein d’autres choses très intéressantes, et à chaque fois il développe et justifie ses idées, mais pour moi le top est dans cette liste.

Vous faut-il le lire ?  Je dirais oui si :

  • Vous vous devez d’avoir de la crédibilité en tant que bloggeur qui ramène sa fraise sur la gestion de projet (mon cas ;)).
  • Vous êtes ou aspirez à devenir chef de projet et que vous voulez comprendre le pourquoi de ce que vous appliquez.

Dans le cas contraire, votre bon sens, l’expérience personnelle et suivre la « BI ça vous gagne » suffiront largement à faire votre culture 🙂

Dilbert du 22/04/2012

Fleid Laisser un commentaire

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)

Fleid 2 commentaires

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

Fleid 25 commentaires

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!

Petite réflexion autour de l’accélération des technologies

Fleid 4 commentaires

En ce moment l’écosystème décisionnel Microsoft est en ébullition. Avec la sortie de SQL Server 2012, c’est tout un camion de nouvelles technologies qui débarque dans notre petit jardin: le DAX, SSAS Tabular, PowerPivot, Power View, Data Explorer, des gros morceaux de SharePoint qui s’incrustent, Windows 8, les évolutions SSIS, le T-SQL version 2012… On a un peu l’impression d’avoir un nouveau langage / environnement à apprendre tous les 3 jours.

Même en dehors de Microsoft le décisionnel bouge beaucoup, et on commence à parler Tableau, Qlikview, SpotFire, qui eux aussi requièrent une certaine expertise voir une expertise certaine.

Et si on revient chez Microsoft mais qu’on sort de la BI, on voit que ça bouge beaucoup, et que ça en fait s’interroger plus d’un !

Oh mon Dieu, du DAX!!!

Oh mon Dieu, du DAX!!!

Alors je crois que c’est le bon moment pour un petit rappel qui nous vient de 2002, de chez Joel Spolsky :

When I was an Israeli paratrooper a general stopped by to give us a little speech about strategy. In infantry battles, he told us, there is only one strategy: Fire and Motion. You move towards the enemy while firing your weapon. The firing forces him to keep his head down so he can’t fire at you.

Traduit approximativement :

Pendant mon service militaire, un général s’est adressé à nous pour un petit cours de stratégie. Dans les batailles d’infanteries, nous disait-il, il n’y a qu’une stratégie: tirer en mouvement. C’est à dire se déplacer vers l’ennemi tout en tirant dans sa direction. Le fait de tirer lui fait baisser la tête, ce qui permet de se déplacer sans qu’il vous tire dessus.

Qu’il applique à la technologie, quelques paragraphes plus loin:

Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.

De nouveau traduit approximativement:

Pensez à l’histoire des protocoles d’accès aux données issus de Microsoft. ODBC, RDP, DAO, ADO, OLEDB, ADO.NET – tous tout neuf ! Etaient-ils technologiquement incontournables ? Ou le résultat de l’incompétence du groupe de design concerné ? Peu importe, le résultat c’est un tir de couverture : pendant que la compétition passe son temps à adapter son code elle n’a pas le temps d’écrire de nouvelles fonctionnalités.

Et nous autres, les utilisateurs de ces technologies, on est pris au milieu de la bataille.

Les juniors sont découragés par le nombre de technos à apprendre, les séniors s’offusquent d’avoir à apprendre encore un nouveau langage.

Tout ça c’est du « Fire & Motion » de l’éditeur, il est important de ne pas y succomber, car ce n’est pas notre guerre. Pour l’éviter : déterminer quel est votre objectif – réaliser des projets ? – et accomplissez le sans vous inquiéter de ne pas maîtriser l’ensemble des technologies de l’offre.

Ce qui est important c’est :

  • d’avoir les bases, la théorie essentielle indépendante de la techno : parler à un client de ses besoins, la modélisation dimensionnelle, de la gestion de projet élémentaire…
  • de maîtriser au moins une technologie, et connaître ses limites,
  • de savoir apprendre les autres, uniquement au moment où vous avez besoin d’elles et uniquement ce dont vous avez besoin
  • de savoir demander à l’aide.

Pour tous ces points, il y a la communauté. Abonnez-vous aux blogs, participez à FrenchConnection.BI et au GUSS, contactez les experts, bref, ne restez pas tout seul dans le noir 😉

Jusqu’à la fin de votre vie, plus vous apprendrez, plus vous réaliserez à quel point vous en savez peu. C’est de la philosophie de bas étage, mais c’est à garder en mémoire devant l’énormité du travail de veille technologique qui attend tout développeur / consultant qui se respecte.

Bon courage ! 🙂