Meta – Rythme d’écriture

Certains le savent déjà, certains l’apprendront avec cet article, d’autres n’en auront rien à faire, mais je change de job le mois prochain. C’est une super bonne nouvelle, je quitte un système dysfonctionnel pour intégrer une équipe avec laquelle je partage des valeurs cruciales. J’en reparlerai sans doute plus tard 🙂

Je suis donc en train de transmettre mes dossiers à mon remplaçant, et ça nous demande beaucoup d’énergie pour être bien fait.

Tout ça pour dire que dernièrement mon rythme d’écriture a été erratique, et qu’il le sera encore la semaine prochaine, j’en suis désolé. Tout devrait rentrer dans l’ordre après, puisque j’aurai quelques jours de vacances bien mérités 😉

4 liens rapides pour la semaine (2010-43)

Et hop:

  1. La courte éloge de Mandelbrot par Planet Money. C’est une très bonne introduction à l’idée principale du bonhomme.
  2. Comment l’impuissance corrompt: un excellent article qui explique bien le malaise du middle management.
  3. La sensibilité du commerçant, l’autre manière d’analyser son business (sans calculette ni tableau Excel).
  4. Le dernier article de Mike Masnick de Techdirt sur l’économie digitale, incontournable, comme d’habitude.

<< Semaine PrécédenteSemaine Suivante >>

Un peu de lecture pour le dBa qui sommeille en vous

Si vous ne connaissez pas le terme, pas de panique, un dBa ce n’est pas quelque chose de vulgaire. L’acronyme signifie database administrator, ou administrateur de bases de données en français. C’est le compère éternel du consultant décisionnel: si le consultant utilise les bases de données, le dBa lui les maintient en vie! On en avait déjà parlé un petit peu avant.

Pour revenir au sujet de cet article, Paul Randal (In Recovery / SQL Skills) nous avait fait en avril un marathon sur son blog en postant un article chaque jour qui clarifiait un des mythes de SQL Server. J’avais d’ailleurs déjà fait un lien vers son article sur le Data Shrink (c’est le mal).

Pour bien terminer les choses, ce monsieur a décidé de regrouper tous ces articles dans un seul PDF librement téléchargeable par ici. C’est évidemment avant tout destiné aux dBa, mais c’est de la culture « générale » bien utile pour un consultant décisionnel.

Et si vous n’avez jamais ouvert SQL Server Management Studio de votre vie, j’avoue, cet article ne sert à rien 🙂

Wesabe vs Mint : les vraies raisons de l’échec

C’est toujours intéressant de connaître l’histoire des vainqueurs, d’essayer de lire dans cette histoire pour comprendre quels ont été les critères de succès. Mais très souvent ça ne sert à rien, à cause de la fâcheuse tendance de l’être humain à voir des causes là ou n’y en a pas.

Ce qui est bien plus intéressant c’est de connaître l’histoire des perdants. Surtout quand ils arrivent à prendre suffisamment de recul pour comprendre d’où est venu l’échec. Et le dernier en date à se livrer à cet exercice publiquement est Marc Hedlund, co-fondateur de Wesabe (aujourd’hui l’appli a disparu, il ne reste « que » la communauté). A la base, Wesabe était la première application en ligne de gestion de compte, un type d’application désormais défini comme Mint-like. Le principe: on upload ses extraits de compte et l’application génère automatiquement du reporting financier mignon qui permet de comprendre pourquoi on est toujours à découvert dès le 15 du mois.

L’article en question est vraiment à lire, il se trouve par là.

Dans la première partie de son analyse, Mister Hedlund explique les raisons, souvent évoquées par la presse, qui selon lui ne sont pas à la base de leur échec:

  • Que Mint soit sorti en premier. C’est faux: c’est Wesabe qui est sorti en premier, et ils ont même réussi à prendre une bonne longueur d’avance en terme de nombre d’utilisateurs. Mais Mint a profité des débuts de Wasabe pour observer dans l’ombre et comprendre ce qu’il fallait faire, et ne pas faire. Le premier n’est donc pas toujours le gagnant.
  • Wesabe n’a jamais fait d’argent. C’est faux mais pas vraiment pertinent par rapport à cet article 🙂
  • Mint a un meilleur nom et un meilleur design. C’est vrai, mais Marc Hedlund ne pense pas que ça ait été un point déterminant dans la victoire de Mint. J’ai tendance à penser que si, tout du moins pour le design. Pour viser le grand public, il vaut mieux une appli belle mais un peu foireuse sur les bords que l’inverse, contrairement aux professionnels, qui sacrifieront la beauté pour les fonctionnalités. Pour moi, il faut d’abord que (1) l’appli fonctionne et fonctionne rapidement, ensuite (2) qu’elle soit belle, enfin (3) qu’elle couvre l’intégralité du périmètre fonctionnel. Mint a les deux premiers, Wesabe a tenté le premier et le dernier.
  • Wesabe n’a pas été viral alors que Mint oui. Faux: les deux l’ont été plus ou moins.

Mais alors, si ce ne sont pas ces raisons qui ont provoqué la chute de Wasabe, quelles sont les vraies raisons? Pour Marc Hardlund c’est:

Une erreur d’exécution : Ils ont eu un choix difficile à faire pour une fonctionnalité clef de l’application: le moteur de conversion automatique des fichiers uploadés provenant de la myriade de banques des utilisateurs dans leur modèle de stockage unique. Honnêtement, j’aurai fait le même choix qu’eux: re-développer en interne plutôt que d’utiliser celui de l’unique fournisseur à la réputation plus que sulfureuse. Mint a eu moins de scrupule, ça a payé: ils ont eu accès à la fonctionnalité d’upload automatique (sans retravail des utilisateurs donc) avant Wasabe qui avait été lancé 6 mois plus tôt.

Une erreur de design :  Mint part du principe que l’utilisateur ne doit rien faire, le moteur va donc essayer de ranger automatiquement les dépenses qui apparaissent sur les relevés de compte de l’utilisateur dans des catégories type loisir, restaurants, loyer… Évidemment ça donne des résultats bien foireux, mais ça donne des résultats. L’utilisateur de Mint a donc accès à un graphique de ses comptes dès les premières minutes de l’utilisation de l’application. A côté de ça, l’utilisateur Wasabe devait saisir et saisir et corriger et saisir et trier et saisir avant d’avoir le même résultat. Ok Mint n’est précis qu’à 80%, mais il donne un résultat quand Wasabe ne donne rien.

Ce qu’il faut retenir de cette aventure c’est que l’équipe de Wasabe a fait tous les bons choix par rapport à l’inscription du business dans le long terme: un moteur développé en interne, des résultats d’une grande qualité. Mais ils étaient placés face à des concurrents prêts à choisir des solutions court termes pour gagner absolument et tuer la concurrence. C’est ce qu’il s’est passé. C’est triste, mais certainement pas incontournable.

Le fait d’inscrire son business dans une stratégie long terme n’implique pas de renoncer à employer des tactiques court termes. C’est même strictement nécessaire pour lutter contre des business qui eux ne vivent qu’autour de leur stratégie court terme.

Comment cela s’applique pour Wasabe? Si la fonctionnalité d’import automatique était tant critique ils auraient dû lancer les 2 efforts en parallèle: développer leur propre moteur en interne, au calme, pour le long terme, et utiliser celui du fournisseur foireux à court terme pour gagner le sprint initial. Si les utilisateurs voulaient avoir un premier rapport rapidement après s’être inscrit, alors il fallait le leur offrir, même s’il était incomplet voir faux. Ensuite, rien n’empêchait d’éduquer progressivement ses utilisateurs (tout du moins la partie réceptive), en utilisant un bon design, pour les encourager à aller plus loin et faire mieux, et à ce moment leur offrir les outils pour le faire.

Et comme d’habitude, je conclue en faisant le lien par rapport au métier de consultant, où là aussi il faut savoir utiliser des tactiques à court terme pour faire progresser ses clients sur le long terme. Parce qu’il ne faut pas oublier que lorsqu’on se fait sortir d’un compte par des concurrents qui utilisent des techniques court terme, ça rend la tâche difficile pour faire progresser ses clients… qu’on a plus…

Utilisateurs et clients, ce n’est pas la même chose!

Via Daring Fireball et Manton Reece, un commentaire qui résume très bien l’état du business sur Internet, et plus globalement en IT:

« If you are not paying for it, you’re not the customer; you’re the product being sold. »

En français: « Si vous ne payez pas, c’est que vous n’êtes pas le client, mais le produit vendu à un tiers. »

Comme dirait mon prof de math de terminal, ça c’est un beau morceau de bon sens paysan (au contraire d’être péjoratif pour les paysans, le meilleur bon sens étant selon lui issu de la ferme).

Cette petite phrase je me la rappelle pour me raisonner à chaque fois que je m’énerve contre Google ou Viadeo/Linkedin pour des questions de protection de la vie privée. Elle met bien en exergue la différence entre les utilisateurs et les clients.

Cette différenciation des rôles s’applique bien évidemment aussi en consulting. Bien souvent quand on intervient, c’est que l’on est missionné par un manager qui se fait le relais du besoin d’un opérationnel.

  • Le manager et l’acheteur sont les clients. Ils payent. Ce sont eux qu’il faudra convaincre pour signer, et re-signer plus tard.
  • L’opérationnel sera l’utilisateur. C’est lui qui « souffrira » avec l’application au quotidien.

Malheureusement, l’opérationnel n’a que rarement son mot à dire dans le choix du prestataire. Je dis malheureusement parce que c’est lui qui aura à subir le plus les conséquences de ce choix. C’est un déséquilibre flagrant du couple pouvoir/responsabilité, une problématique chère à Spiderman ainsi qu’à tout plein de philosophes, évidemment.

Le seul moyen, en tant que consultants, pour aider les utilisateurs à restaurer l’équilibre,  c’est de casser et refaire complétement l’organigramme et les processus de décisions chez les clients…. euh non, c’est pas ça, je me trompe de fiche… c’est de savoir séduire les clients aussi efficacement qu’on sait réaliser des applications qui couvrent le besoin des utilisateurs.

Comment ça se traduit en terme opérationnel? Recruter des commerciaux de qualité, les former techniquement, valider que leurs valeurs sont en adéquation avec celles de la boîte, bien penser leur rémunération (vidéo à absolument voir) pour éviter les mauvais incentives, et les faire accompagner en avant-vente par des consultants techniques qui savent de quoi ils parlent, qui savent s’exprimer, qui font réver en somme (mais pas trop).

Avec ce genre de duo de choc, tout ne peut que bien se passer!

Enfin… c’est en négligeant le fait que le directeur chez les clients sort de la même promotion de l’X que le président de la boîte de conseil concurrente… Ça c’est difficile à gérer, même pour Spiderman…

Ps: si vous êtes côté utilisateur, un bon moyen de s’en tirer c’est d’utiliser ce genre de technique pour sélectionner vos prestataires. Bon courage pour le faire passer auprès de vos managers!

Dilbert du 13/10/2010

J’adore cette définition de ce qui est éthique:

Dilbert.com

Traduction approximative:

Titre: Dogbert consultant

Dogbert : Les données personnelles de vos clients sont une ressource que vous pouvez vendre.

Dogbert: C’est totalement éthique puisqu’ils feraient pareil à votre place.

Boss: Ça semble juste.

Dogbert: Dans la phase 1, nous déshumaniserons l’ennemi en l’appelant juste  » les données »

PS: Encore une nouvelle catégorie, cette fois-ci c’est comics, toujours sous Divers.