Tag Joel Spolsky

Partenaire Microsoft : plus qu’un choix, un métier!

Fleid 7 commentaires

Via Chris Webb, un article de Frans Bouma sur l’évolution de la relation partenaire/éditeur avec Microsoft. Si l’article est récent le sujet ne l’est pas, Joel Spolsky en avait déjà parlé tantôt (il y a 12 ans !), et même moi par ici.

L’article est un peu long, je vous le résume (même s’il vaut le coup d’œil) :

Microsoft développe des logiciels. Pour rester dans le business l’éditeur crée beaucoup de nouveaux produits, sur des nouveaux périmètres ou en remplaçant des softs existants (qui marchaient ou pas). Nous, partenaires (consultants ou éditeurs à notre tour), faisons le choix d’utiliser ces produits, d’investir dans ces produits, et de là découle une dépendance à la technologie de Microsoft. Et si de tout temps, via cette dépendance, Microsoft nous faisait subir ses ruptures technologiques sans que nous ayons trop le choix (cela faisait partie du deal), désormais des alternatives existent et nous pouvons/devons-nous interroger sur l’opportunité de changer complétement d’environnement lorsqu’une nouvelle rupture survient.

Un très bon exemple de ça actuellement est la BI avec SQL Server, puisque nous sommes en train de subir une rupture technologique entre l’offre traditionnelle (SSIS/SSAS/SSRS) et la nouvelle génération d’outils (Power BI/HDInsight/Azure).

En tant que consultants, nos connaissances techniques sur les « anciens » produits ne se transposent au final que très peu sur les nouveaux produits (DAX, Hive, Pig). Au moment de dégager du temps de formation, on doit donc s’interroger, quitte à repartir de 0, sur l’opportunité de passer à une autre stack technologique : QlikView, Tableau, MicroStrategy… Voire carrément un domaine connexe : Machine Learning et Big Data via la stack Hadoop, statistiques via R ou Python, etc…

Bien choisir son outil de travail c'est crucial!

Bien choisir son outil de travail c’est crucial!

Dans le deux cas (autre éditeur, autre domaine) on ventile les risques : dans le premier on ventile ses dépendances sur 2 éditeurs,  dans le second on investit sur l’open source, qui traditionnellement véhicule des écosystèmes moins tyranniques que ceux reposant sur un éditeur unique.

Si de mon côté le choix est fait, je pense que tous ceux qui prennent leur carrière au sérieux doivent se poser sérieusement la question, autant d’un point de vue personnel (quel sera le prochain livre que vous allez ouvrir) que stratégique (quelle offre de service construire pour mon pôle décisionnel).

Par contre, si ici je mentionne les risques d’un partenariat avec Microsoft, il fallait également que je mentionne les avantages énormes qui en découle: entre autres, l’ensemble des Microsofties dont le métier à temps plein c’est de nous aider (merci les gens!),  le programme MVP dont je profite, ou encore les avantages en licences via le Microsoft Partner Network. Comparé aux autres éditeurs, nous sommes choyés!

Alors oui, je vous dis que pour moi le choix est fait, mais je fais monter le suspens, on en reparle plus tard 😉

Suspens!

Commencer la gestion de projet en décisionnel

Fleid 1 commentaire

Je profite d’avoir rédigé cette petite liste pour un consultant de mon équipe pour la publier ici. Rien de mystique, juste une liste de lecture pour se lancer dans la gestion de projet en décisionnel.

La base, c’est évidement de Joel Spolsky sur son blog Joel On Software :

Puis pour s’y mettre pour de vrai :

  • En mode pratique, c’est évidemment Kimball et Ross avec The Datawarehouse Lifecycle Toolkit (2nd edition – à ne pas confondre avec le DWH Toolkit). Non seulement ils sont forts en modélisation, mais ils font aussi la gestion du projet décisionnel. Malheureusement non traduit en français. Notez pour ceux qui l’ont qu’on peut trouver un avant-gout sur le sujet dans le Datawarehouse Toolkit (3rd edition).
  • En mode théorique, c’est Scott Berkun avec Making Things Happen, il définit bien l’idéologie du chef de projet orienté facilitateur. Mais c’est déjà plutôt du niveau 2. Le niveau 3 étant le Mythical Man-Month de Brooks.

En terme d’approche, le Kimball Group est plutôt orienté itératif, et les théoriciens sont plus classiques (V, waterfall). Si vous voulez creuser le côté Agile appliqué au décisionnel, je vous renvoie aux articles que j’avais écrit tantôt.

Et voilà, avec les bons outils, rien d’impossible !

Avec les bons outils...

N’hésitez pas si vous en avez d’autres (des bonnes ressources pour débuter, pas de gifs hein…) 😉

Consultants Juniors, Confirmés, Séniors, quels critères pour quantifier l’expérience?

Fleid 6 commentaires

On avait déjà évoqué ensemble les différents choix de carrière pour un consultant décisionnel – ou plus généralement pour n’importe qui travaillant dans l’IT – et j’étais passé assez rapidement sur la montée en séniorité.

Je reviens donc sur le sujet, pour clarifier ma vision de ces différents sous-titres qui ornent nos cartes de visite.

Petit consultant deviendra grand…

Par niveau, je vois les choses comme ça :

> Débutant / Stagiaire

  • 0 expérience
  • En cours d’apprentissage
  • Contre-productif, coûte du temps sans en rapporter avant 3 mois d’activité

> Junior

  • 1 à 2 ans d’expérience
  • Est capable d’exécuter le travail unitaire qui lui est demandé
  • Quasiment aucune autonomie, doit être piloté quotidiennement

> Confirmé

  • 3 à 4 ans d’expérience
  • Est autonome dans son propre travail de bout en bout
  • Nécessite un point de référence quand les choses se corsent

> Sénior

  • 5 à 10 ans
  • Pilote les travaux unitaires des autres pour l’élaboration d’une solution complète
  • Connaît à l’avance les points durs et sait les contourner

> Vieux de la vieille

  • 10 ans et +
  • Plutôt rares, en général on évolue vers du management, de la direction ou on change de domaine d’activité (séniors multi domaines)
  • Il ne craint personne, on ne la lui fait plus, mais attention à ne pas trop s’aigrir!

Combien d’XP pour le prochain niveau?

Notez que pour moi l’expérience se calcule à la mode Joel Spolsky, et que la durée nécessaire varie évidemment d’une personne à l’autre. Pour les anglophobes, les critères du père Spolsky sont les suivants :

  • On compte toutes les activités de développement, le design d’interface, le QA (les testeurs), les taches d’administration et production…
  • Pour les fonctions méta, le management, le marketing et la vente, on les compte si elles sont précisément dans le secteur que l’on veut qualifier (édition, décisionnel, webdev…)
  • On ne compte pas ce qu’il se passe pendant l’école. Exception de mon côté pour les apprentis dont je compte à 50% le temps passé en entreprise.
  • Pénalité sur les tâches répétitives qui sont ramenées à 1 année (3 ans en régie à faire la même chose ce n’est pas 3 ans d’expérience mais 3 fois la même unique année).
  • J’ajoute également un facteur sur la qualité de la veille technologique du collaborateur. Un développeur abonné à des flux RSS de bloggeurs, ou bloggeur lui-même, qui participe à la communauté, gagnera forcément un bonus par rapport à celui qui subit sa carrière.

Notez également qu’au-dessus de Sénior je ne mets pas Manageur. En effet Manageur est un type d’activité, dans lequel on peut être junior, confirmé ou sénior (confère encore les carrières).

Ce message s’adresse en partie aux consultants, pour savoir se situer en dehors de la surenchère des SSII dont c’est un levier pour faire grimper le taux de facturation (ainsi que compenser l’absence d’augmentation de salaire), mais également aux clients.

Pour ces derniers, ne vous attendez pas à ce qu’un consultant avec 2 ans d’expérience vous implémente une solution de bout en bout s’il est laissé tout seul sans encadrement. Soyez dubitatifs si c’est un confirmé qui est sensé encadrer 2 développeurs juniors. A force de vouloir tirer les prix vers le bas, vous voilà sous-équipés pour réussir.

La Dream Team, Basketball USA aux Jeux Olympiques de 1992

A vous de savoir assembler la dream team (ça ne nous rajeunit pas) !

Si votre projet est relativement simple, vous pourrez complétement vous appuyer sur des confirmés à la tête bien faite. Mais si le périmètre est suffisamment large pour nécessiter le déploiement de juniors, ou si le sujet fonctionnel est reconnu comme complexe, vous ne pourrez pas vous passer d’un sénior.

Même si ça paraît cher, il vaudra toujours mieux intégrer un sénior au 2/5ème à votre dispositif plutôt que prendre 6 mois de retard et livrer une solution de mauvaise qualité qui ne satisfera pas le besoin.

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 ! 🙂

4 liens rapides pour la semaine (2012-07)

Fleid 3 commentaires

Encore une super sélection cette semaine, que du lourd 🙂

  1. Jeff Atwood (Coding Horror) qui nous donne son avis sur les réunions.
  2. Joel Spolsky chez Fred Wilson sur l’organisation de sa société. Ça me travaille de voir comment appliquer ça à une SSII.
  3. Seth Godin qui nous rappelle de bien savoir qui sont nos clients.
  4. Enfin, DHH de 37 Signals sur le mythe des startups, suivi de l’excellente réaction de Bryce Roberts qui souligne l’émergence des indépendants.

______________________

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

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

Fleid 6 commentaires

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.