Tag Seth Godin

4 liens pour la semaine (2013-17)

Fleid 2 commentaires

Et c’est reparti pour un tour:

  1. David Cain sur la procrastination, ou comment le fait de trainer les pieds n’est pas de la fainéantise, mais bien un mécanisme de self-défense psychologique. Via Hacker News.
  2. Marco Arment sur Google Reader, et plus globalement le problème des solutions gratuites en position de monopole sur les écosystèmes logiciels.
  3. Eric Jackson sur pourquoi les entreprises doivent se prémunir des bozos (les clowns, les gens qui se croient bien meilleurs qu’ils ne le sont et qui écrasent les autres). Cela confirme bien que l’humilité reste une valeur essentielle chez un employé (être humain), et cela renvoie plus globalement au gap entre ceux qui sont sûrs d’eux (et qui n’ont pas forcément raison) et ceux qui doutent (la base de toutes nos démarches scientifiques) mais qui ont du mal à s’imposer dans la conversation.
  4. Enfin, Seth Godin qui nous rappelle que toute initiative humaine est imparfaite. Attention à ne pas oublier la destination à trop vouloir corriger les petits défauts sur la route.

______________________

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

Entourage

Fleid 5 commentaires

Un mot de sagesse qui nous vient de Seth Godin :

Notre entourage provoque des rencontres et nous inspire.

De ces rencontres et ces idées viennent le changement.

Ces changements nous transforment.

Maitrisez votre évolution en choisissant votre entourage.

Soit dit en passant :

  • Afterwork du GUSS en novembre, à priori le 15/11/2012, on en reparle
  • JSS2012 les 10 et 11 décembre 2012, les inscriptions seront bientôt ouvertes

PS: Et oui j’avoue sans honte que je suis un fan d’entourage. J’assume 🙂

Dans l’ordre: David, JP, Alex, Charly et Aurélien. Les Infinites finissent leur bouquin, je prends la photo, Pascale et les autres nous attendent au bistrot… Vous êtes les bienvenus 😉

4 liens pour la semaine (2012-41)

Fleid 2 commentaires

Je triche et j’en mets 5 au lieu de 4 😉

  1. Une grosse discussion chez Kalzumeus sur le pricing des produits et du service. Plein de bons arguments pour augmenter ses prix.
  2. Dans la même veine, on continue sur le service avec un article de Sebastian Marshall qui rappelle qu’un consultant servile ne sert pas vraiment son client.
  3. Encore Sebastien Marshall, avec une excellente remarque sur la documentation interne à l’entreprise: si elle est pénible à lire, c’est qu’elle est ratée!
  4. Seth Godin avec une métaphore pleine de piquants.
  5. Enfin, le point de vue Lean d’Evolving Excellence sur le management de l’innovation.

______________________

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

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 – Méthodes Agiles ou Cycle en V ?

Fleid 32 commentaires

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?

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.