Le secret de l'Iceberg révélé

From The Joel on Software Translation Project

Jump to: navigation, search
Article original: The Iceberg Secret, Revealed
Date de publication: 13 février 2002
Traducteur: Pakter
Vérifié par:
Navigation: Retour à Main Page Retour à French FrenchFlag.png




par Joel Spolsky

Mercredi 13 février 2002


« Je ne sais pas ce qui cloche avec mon équipe de développement », se dit le PDG. « Les choses allaient tellement bien quand nous avons démarré ce projet. Les deux-trois premières semaines, l'équipe a turbiné à fond et a réussi à faire marcher un prototype du tonnerre. Mais depuis, les choses ont l'air d'être presque au point mort. Ils ne bossent plus comme avant ». Il choisit un driver de golf Callaway en titane et envoie le caddy chercher une limonade glacée. « Peut-être que si je vire deux ou trois traînards, ça les fera se remuer ! »

Pendant ce temps, bien sûr, l'équipe de développement ne se doute absolument pas qu'il y a un quelconque problème. En fait, il n'y a rien qui cloche. Ils sont dans les temps.

Ne laissez pas ceci vous arriver ! Je vais vous mettre dans la confidence d'un petit secret à propos de ce genre de managers non techniques qui rendra votre vie un million de fois plus facile. C'est tout simple. Une fois que vous connaîtrez mon secret, vous n'aurez plus jamais de problème pour travailler avec des managers non techniques (à moins que vous ne vous embarquiez dans une discussion sur le coefficient de restitution de leurs clubs de golf).

Il est assez clair que les programmeurs pensent dans un langage, et les détenteurs de MBA dans un autre. Cela fait un moment que je réfléchis au problème de la communication dans la gestion de logiciels, parce que j'ai la nette impression que le pouvoir et les avantages affluent vers les rares individus qui savent faire la traduction entre jargon de programmeur et jargon de MBA.


Depuis mes début dans l'industrie du logiciel, j'ai presque toujours travaillé sur du logiciel qu'on pourrait qualifier de « spéculatif » - au sens où le logiciel n'est pas créé pour un client particulier : il est créé dans l'espoir que des milliards de gens l'achèteront. Mais nombreux sont les développeurs de logiciel qui ne jouissent pas d'un tel luxe. Cela peut être des consultants qui développent un projet pour un seul client, ou bien des programmeurs internes qui travaillent sur un truc d'entreprise compliqué pour la comptabilité (ou quoi que ce soit que fassent vos programmeurs internes ; c'est assez mystérieux pour moi).

Avez-vous déjà remarqué que dans ces projets sur mesure, la cause la plus fréquente de dépassements, d'échecs et d'affliction générale se résume toujours au fond à « le (insérer l'injure ici) de client ne savait pas ce qu'ils voulait ? »

Voici trois versions de la même pathologie :

  1. « Le foutu client n'a pas arrêté de changer d'avis. D'abord, il voulait du client / serveur. Puis il a lu un article à propos de XML dans le magazine offert sur les vols de Delta Airlines, et a décidé qu'il lui fallait du XML. A présent nous en sommes à réécrire le truc pour utiliser des flottes de mini-robots Lego Mindstorms. »
  2. « Nous l'avons construit exactement de la façon dont ils le voulaient. Le contrat spécifiait l'intégralité du truc dans les moindres détails. Nous avons livré exactement ce que le contrat indiquait. Mais quand nous l'avons livré, ils sont tombés de haut. »
  3. « Notre pathétique commercial a accepté un contrat à prix fixe pour construire quelque chose de fondamentalement non spécifié, et les avocats du client ont été assez malins pour faire insérer une clause dans le contrat indiquant qu'ils n'ont pas à nous payer jusqu'à « acceptation par le client », donc on a dû mettre une équipe de neuf développeurs sur leur projet pendant deux ans, pour toucher seulement 800 $. »

S'il y a une chose que chaque consultant junior doit se faire injecter dans la tête avec une perceuse professionnelle à 2500 tr / min, c'est ceci : Les clients ne savent pas ce qu'ils veulent. Arrêtez d'attendre des clients qu'ils sachent ce qu'ils veulent. Ca n'arrivera jamais. Oubliez ça.

A la place, dites-vous que vous allez devoir créer quelque chose de toute façon, et qu'il faut que ça plaise au client, mais qu'ils seront un petit peu surpris. C'est à VOUS de faire la recherche. C'est à vous d'imaginer une conception qui résolve de façon élégante le problème rencontré par le client.

Placez-vous dans leur situation. Imaginez que vous venez de gagner 100 000 000 $ en vendant votre entreprise à Yahoo!, et que vous avez décidé qu'il était temps de rénover votre cuisine. Alors vous prenez un architecte expert avec mission de la rendre « aussi cool que la cuisine de la série Will et Grace ». Vous n'avez aucune idée de comment y parvenir. Vous ne savez pas que vous voulez une cuisinière Viking et un réfrigérateur Subzero - ce ne sont pas des mots de votre vocabulaire. Vous voulez que l'architecte fasse quelque chose de bien, c'est pour ça que vous l'avez embauché.

Les tenants de l'Extreme Programming disent que la solution est d'avoir le client dans la pièce et de l'impliquer dans le processus de conception à chaque étape du parcours, en tant que membre de l'équipe de développement. C'est, je crois, un peu trop « extrême ». C'est comme si mon architecte me faisait venir pendant qu'ils conçoit la cuisine et me demandait de fournir des commentaires sur chaque petit détail. Je trouve ça rasoir ; si j'avais voulu être architecte, je serais devenu architecte.

Quoi qu'il en soit, vous ne voulez pas vraiment un client dans votre équipe, n'est-ce pas ? Il y a de grosses chances que le candidat du client s'avère être un pauvre bougre de la Compta fournisseurs qu'on a envoyé travailler avec les programmeurs parce qu'il était le plus lent du service, et qu'ils remarqueraient à peine son absence. Et vous allez simplement passer tout le temps consacré à la conception à expliquer les choses en mots d'une syllabe.

Partez du principe que vos clients ne savent pas ce qu'ils veulent. Concevez-le vous-même, sur la base de votre compréhension du domaine. Si vous avez besoin de passer un peu de temps à vous informer sur le domaine ou si vous avez besoin d'un expert du domaine pour vous aider, très bien, mais la conception du logiciel est votre boulot. Si vous vous renseignez bien sur le domaine et que vous créez une bonne interface utilisateur, le client sera content.

Maintenant, j'ai promis de vous révéler un secret concernant la traduction entre le langage des clients (ou des managers non techniques) de votre logiciel, et le langage des programmeurs.

Vous savez que 90 % d'un iceberg est sous la surface de l'eau? Eh bien, la plupart des logiciels sont comme ça aussi - il y a une jolie interface utilisateur qui prend environ 10% du boulot, puis 90% du travail de programmation est caché en-dessous. Et en prenant en compte le fait qu'environ la moitié de votre temps est consacré à la correction des bugs, l'interface utilisateur ne prend que 5% du travail. Et si vous vous limitez à la partie visuelle de l'interface, les pixels (ce que vous verriez dans PowerPoint), alors là on parle de moins de 1%.

Ce n'est pas le secret. Le secret est que Les gens qui ne sont pas programmeurs ne comprennent pas ça.

Il y a plusieurs corollaires très, très importants au secret de l'Iceberg.

Corollaire important n°1. Si vous montrez à un non-programmeur un écran qui présente une interface utilisateur qui est 90% pire, ils vont penser que le programme est 90% pire.

J'ai appris cette leçon en tant que consultant, lorsque j'ai fait une démo d'un important projet web pour l'équipe de direction d'un client. Le projet était pratiquement 100% achevé au niveau du code. Nous attendions encore que le graphiste choisisse des polices et des couleurs et dessine les onglets tendance en 3D. Dans l'intervalle, nous utilisions simplement des polices ordinaires et du noir et blanc, il y avait un tas d'espace gaspillé sur l'écran ; en gros ça n'avait rien d'agréable à l'oeil. Mais il y avait 100% des fonctionnalités et ça faisait des trucs assez incroyables. Qu'est-ce qui s'est passé pendant la démo ? Les clients ont passé la réunion entière à gémir sur l'aspect graphique de l'écran. Ils ne parlaient même pas de l'interface utilisateur. Juste de l'aspect graphique. « Ça ne fait pas lisse » se plaignait leur chef de projet. C'est tout ce qu'ils pouvaient en penser. Nous ne pouvions pas les amener à réfléchir sur les fonctionnalités réelles. Evidemment, corriger la conception graphique a pris environ une journée. C'était pratiquement comme s'ils pensaient avoir embauché des peintres.

Corollaire important n°2. Si vous montrez à un non-programmeur un écran avec une interface utilisateur superbe à 100%, il va penser que le programme est quasiment fini.

Les gens qui ne sont pas programmeurs regardent juste l'écran et voient des pixels. Et si les pixels ont l'air de constituer un programme qui fait quelque chose, ils se disent « mince, qu'est-ce qu'il faut de plus pour le faire marcher réellement ? » Le gros risque ici est que si vous commencez par une maquette de l'interface utilisateur, a priori pour amorcer les discussions avec le client, alors tout le monde va s'imaginer que vous avez presque fini. Et quand vous passerez la prochaine année de travail « sous le capot », pour ainsi dire, personne ne verra vraiment ce que vous êtes en train de faire, et les gens penseront que rien ne se passe.

Corollaire important n°3. La startup Internet qui a un site web élégant et tendance avec environ quatre pages web obtiendra une valorisation supérieure à la startup Internet totalement opérationnelle avec 3700 années d'archives et le fond gris par défaut.

Maintenant que j'y pense, les startups Internet ne valent plus rien du tout. Peu importe.

Corollaire important n°4. Lorsque des considérations politiques exigent que différents managers ou clients non techniques valident un projet, donnez-leur plusieurs versions du graphisme entre lesquelles choisir.

Faites varier le placement de certaines choses, changez l'aspect et les polices, déplacez le logo et rendez-le plus grand ou plus petit. Donnez-leur le sentiment d'être importants en leur donnant un bout d'os non crucial à ronger. Du coup ils ne pourront guère mettre à mal votre planning. Un bon décorateur d'intérieur apporte sans arrêt des échantillons, des exemples et autres trucs parmi lesquels faire un choix. Mais ils n'iraient jamais discuter de l'emplacement du lave-vaisselle avec le client. Il se met à côté de l'évier, peu importe ce que le client veut. Pas la peine de perdre son temps à discuter de l'endroit où se met le lave-vaisselle, il faut qu'il soit à côté de l'évier, ne soulevez même pas le sujet ; laissez les clients se piquer de conception sur quelque chose d'inoffensif, comme changer d'avis 200 fois entre utiliser du granit italien, de la céramique mexicaine ou du billot norvégien pour les comptoirs.

Corollaire important n°5. Quand vous voulez frimer, la seule chose qui compte, c'est la capture d'écran. Débrouillez-vous pour qu'elle soit superbe.

Ne pensez pas un instant pouvoir vous en sortir en demandant à quiconque d'imaginer à quel point ça serait cool. Ne croyez pas qu'ils regardent la fonctionnalité. Pas du tout. Ils veulent voir de jolis pixels. Steve Jobs a compris ça. Oh que oui il a compris. Les ingénieurs d'Apple ont appris à faire des choses qui donnent de superbes copies d'écran, comme les somptueuses icônes 1024x1024, même si elles gaspillent une place précieuse. Et les adeptes de bureau Linux sont dingues des fenêtres xterm semi-transparentes, qui donnent de bonnes copies d'écran mais sont généralement pénibles à l'utilisation. Chaque fois que Gnome ou KDE annonce une nouvelle version je vais droit aux captures d'écran et je dis : « Oh, ils ont mis la planète Saturne au lieu de Jupiter. Cool. » Peu importe ce qu'ils ont réellement fait.

Vous vous souvenez du PDG au début de cet article ? Il était mécontent parce que son équipe lui avait montré de superbes PowerPoints au début - des maquettes faites avec Photoshop, même pas VB. Et maintenant qu'ils font effectivement des choses sous le capot, on dirait qu'ils ne font rien du tout .

Que pouvez-vous faire ? Une fois que vous comprenez le secret de l'Iceberg, il est facile de s'en servir. Comprenez que n'importe quelle démo que vous ferez dans une pièce sombre avec un projecteur ne traitera que de pixels. Si vous pouvez, construisez votre interface de telle sorte que les parties inachevées aient l'air inachevées. Par exemple, utilisez des icônes griffonnées jusqu'à ce que la fonctionnalité soit présente. Pendant que vous construisez votre service web, vous pouvez envisager d'omettre des fonctions de la page principale tant que ces fonctions ne sont pas réalisées. De cette façon, les gens peuvent voir la page d'accueil passer de 3 à 20 commandes au fur et à mesure de la construction.

Plus important encore, assurez-vous de contrôler ce que les gens pensent du planning. Fournissez un plannning détaillé au format Excel. Chaque semaine, autocongratulez-vous par courrier électronique sur votre passage de 32% d'avancement à 35%, et sur le fait que vous être sur les rails pour livrer le 25 Décembre. Assurez-vous que des faits tangibles contrecarrent toute interrogation quant à savoir si le projet avance à la bonne vitesse ou non. Et ne laissez pas votre patron utiliser des drivers Callaway en titane, peu m'importe à quel point vous voulez le voir gagner, la fédération américaine les a interdites et ce n'est tout simplement pas franc-jeu.

Personal tools