Dilbert du 26/10/2010

Fleid à lui même : « Y’a du retard à rattraper, va falloir augmenter le rythme mon pti’vieux! »

Dilbert.com

Traduction Approximative:

Dibert : Notre plan projet est tellement compliqué que nous sommes garantis de nous planter.

Dilbert :Mais vu que la complexité est une notion vraiment trop abstraite pour vous, je sens que vous allez m’entrainer sans pitié dans le vortex de l’échec.

Dilbert : Go!

Boss : J’ai besoin que vous finissiez 6 semaines plus tôt pour un congrès!

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 03/10/2010

Désolé de concentrer les posts le dimanche, mais la semaine dernière a été tendue, comme la sera la prochaine.

Le point positif, c’est que c’est la dernière fois que je vous embête aujourd’hui!

Dilbert.com

Traduction approximative:

Dilbert: … et biensur nous mesurerons l’avancement au fur et à mesure du projet.

Membre du comité: Utiliserez vous une méthodologie de mesure avancée?

Membre du comité: (Il pense) J’espère que ça veut dire quelque chose. J’ai juste mélangé des mots que j’ai entendu plus tôt dans le couloir.

Dilbert: Euh… J’estimerai l’avancement… en mesurant… et… euh…

Boss: (Il pense) Je ferais bien de m’en méler

Boss: Je ne validerai pas ce projet tant que je ne verrai pas la planification de votre méthodologie de mesure avancée.

Dilbert: Je l’aurai dans 5 minutes, en supposant que vous ne savez pas à quoi cela doit ressembler.

Boss: Très bien!

//

Dilbert: Je vais dans la douche… nettoyer mon âme.

Dilbert du 19/09/2010

Tant qu’on est dans les bêtises, Civilization V est sorti hier aux USA. Désolé pour votre vie de famille…

Et voilà le strip, qui est tellement vrai:

Dilbert.com

Traduction approximative:

Boss: Je ne comprends rien à vos deux propositions techniques, et il faut que j’en choisisse une.

Boss: Normalement je fais ça au favoritisme, mais je ne vous apprécie ni l’un ni l’autre.

Boss: Donc je vais tester votre intelligence, et je choisirai la proposition du plus malin.

Boss: Si vous tirez une flèche depuis un avion vers un singe…

Boss: … et que le singe jette une noix de coco en direction de la flèche pour l’arrêter, mais la rate…

Boss: … comment pouvez vous deviner l’heure?

Dilbert: On n’a pas assez de données.

Collègue de Dilbert: On regarde notre montre?

Boss: La bonne réponse est: « Demander au singe en espérant qu’il n’est pas rancunier »

Comment bien choisir son équipe de développement

Un très bon article de Juin 2010 de l’excellent Derek Sivers: comment recruter un programmeur pour être sûr de terminer son projet, via 37 Signals (Rework bla bla).

Traduit à l’arrache et transposé à notre domaine ça donne:

  1. Réduire sa grande idée à une version 1.0, une version réduite au strict minimum des fonctionnalités. On met le reste de côté pour plus tard.
  2. Écrire un résumé de ce que cette version 1.0 est censée faire. Essayer de faire le plus court et précis possible, utiliser des scénarios d’usage écrit en vrai français et/ou des maquettes visuelles
  3. Préciser les actions et chemins de navigation jusqu’au moindre clic (ne pas oublier que c’est uniquement pour la version 1.0!). Cela devrait ressembler à une longue liste simple et claire d’actions.
  4. Regrouper les fonctionnalités et actions en une série de jalons. Il peut être difficile de définir un ordre, mais c’est comme pour construire une maison, d’abord les murs, ensuite le papier peint.
  5. Faire de son premier jalon un projet à part entière. C’est à dire préparer une feuille de mission qui comporte les activités de ce premier jalon, et n’en mentionner aucune autre. Rien des autres jalons, rien de la version 1.0, rien de la version complète.
  6. Faire un appel d’offres sur ce mini projet, et strictement sur ce mini-projet (étape 5). Envoyer l’AO à une dizaine d’acteurs du marché, de types différents  (petite société de conseil spécialisée, grande SSII internationale, freelances, réalisation web…), des boîtes dont vous connaissez la réputation de précédentes missions si possible.
  7. Ne visez pas le prix le plus bas, en tout cas si le but c’est de finir le projet avec succès, l’objectif ici est de recruter au minimum 2 équipes et les mettre en concurrence. Il vaut mieux ne pas prévenir les équipes qu’elles ne sont pas les seules à être retenues, donc ne pas les staffer en interne dans la même pièce…
  8. A ce point de l’aventure, il suffit d’attendre le résultat et de choisir celui que l’on a préféré pour réaliser le reste de la version 1.0, puis de l’application complète, si tout va bien.

Excellent non? Avec ça finis les concours de beauté, que le plus efficace gagne! D’autre part le surcoût financier est minime, le mini-projet devrait se résumer à 5 jours de travail, et il est largement compensé par le gain en terme de risque prestataire.

J’en profite pour copier l’équipe de 37 Signals et mettre l’emphase sur la méthode de Derek Sivers pour optimiser le filtrage des réponses à l’appel d’offre lors de l’étape 6. Au milieu de l’appel d’offre, insérer une note qui indique que pour que la réponse soit prise en compte, il est nécessaire d’inscrire « Je suis réel » en gros et gras sur sa première page. Évidemment, au moment du dépouillage, éviter consciencieusement toutes les réponses qui ne comporteraient pas cette mention 😉

NB : Concernant le blog de Derek, soyez sûr de repasser la langue du traducteur automatique à anglais si vous voulez profiter correctement du contenu. Je ne sais pas ce qu’il donne dans les autres langues, mais en français c’est pitoyable.

Mais où est Charlie?

Thomas Larock pose une bonne question: mais où sont donc passé les bons managers?

Il pose la question en réponse à l’éternelle questionnement dans le monde des bases de données: mais où sont donc passés les bons dBa? (database administrators, administrateurs de bases de données).
Pour la faire courte: pour reconnaître un dBa qui a du potentiel, l’accompagner dans son chemin d’expertise et lui poser des challenges qui le motiveront à s’investir, et bien il faut un bon manager.

Pas de bon manager, pas d’expert SQL Server. On peut même élargir: pas de bon manager, pas de bon rien du tout. Une évidence qu’il fait du bien de rappeler sous la forme d’un auto-diagnostic: si vous vous plaignez du manque de compétence de vos experts, il existe une forte chance que ce soit avant tout un problème de management, et non d’expertise technique ou de recrutement.

Pourquoi j’ajoute recrutement dans la dernière phrase? C’est David Heinemeier Hansson de 37 Signals qui nous en rappelle la raison: le talent ne s’achète pas. Et comme à chaque fois qu’on parle de 37 Signals, j’en profite pour en remettre une couche: lisez ReWork, ça change la vision du monde professionnel, il n’y a pas que moi qui le dit.