Établissez Vos Priorités

From The Joel on Software Translation Project

Jump to: navigation, search
Article original: Set Your Priorities
Date de publication: 12 octobre 2005
Traducteur: Vianney Lecroart
Vérifié par: Non-communiqué
Navigation: Retour à Main Page Retour à French FrenchFlag.png




Il était temps d’arrêter de perdre du temps sur FogBugz 4.0 et de commencer à travailler sur la version 5.0. Nous venons juste de livrer un gros service pack, qui corrige un zillion de tout petits bogues que personne ne devrait jamais rencontrer (et introduit une poignée de nouveaux petits bogues que personne ne rencontrera jamais) et il était temps d’ajouter de nouvelles fonctionnalités originales.

Au moment où nous étions prêts à commencer le développement, nous avions listé assez d'idées d'améliorations pour occuper 1700 programmeurs pendant quelques décennies. Malheureusement, nous n'avons que trois programmeurs, et nous voulions livrer avant l’automne prochain : il a donc fallu établir des priorités.

Avant que je vous dise comment nous avons priorisé notre liste de fonctionnalité, laissez-moi vous raconter deux mauvaises manières de le faire.

Numéro un. Si jamais vous vous trouvez à implémenter une fonctionnalité simplement parce qu'elle a été promise à un client, les VOYANTS ROUGES "DANGER" devraient s’allumer dans un coin de votre tête. Si vous faites des choses pour un client, soit vous avez un vendeur qui déconne, soit vous glissez la pente dangereuse qui mène vers le consultingware. Et il n'y a rien de mal avec le consultingware ; c'est une pente très douce à descendre, mais ce secteur n'est simplement pas aussi profitable que le logiciel préemballé.

Le préemballé est le modèle de développement logiciel à-prendre-ou-à-laisser. Vous développez le logiciel, l’emballez dans du plastique, et les clients l'achètent, ou pas. Ils ne proposent pas de l'acheter si vous ajoutez juste une fonctionnalité en plus. Ils ne vous appellent pas pour négocier l'ajout de fonctionnalités. Vous ne pouvez pas appeler Microsoft et leur dire, "hé, j'aime bien la fonction BAHTTEXT que vous avez dans Excel pour écrire en toutes lettres des nombres en thaï, mais ce dont j'aurais besoin c'est d'une fonction équivalente pour l'anglais. J'achèterais Excel si vous implémentiez juste cette fonction." Parce que si vous appeliez vraiment Microsoft, voici ce qu'ils vous diraient :

"Merci d'avoir contacté Microsoft. Si vous appelez avec un code promotionnel à 4 chiffres, faites le 1. Pour le support technique sur tous les produits de Microsoft, faites le 2. Pour l'autorisation pré-vente Microsoft ou des informations sur le programme, faites le 3. Si vous connaissez la personne à Microsoft à qui vous souhaitez parler, faites le 4. Pour répéter, appuyez sur la touche étoile."

Vous avez remarqué ? Il n'y a pas de choix "pour négocier quelles fonctionnalités doivent être ajoutés à nos produits avant que vous les achetiez, appuyez sur la touche 5."

Le développement fait sur mesure est ce monde sombre où un client vous dit ce qu’il faut faire, et vous dites, "en êtes vous sûr?" et ils disent oui, et vous faites des spécifications parfaites, et vous redemandez, "c'est bien ce que vous voulez?", et ils disent oui, et vous leur faites signer les spécifications à l'encre indélébile, non, avec leur sang, et ils le font, et alors vous fabriquez cette chose qu'ils ont signé, sur le champ, avec précision et exactitude, et ils la voient et sont horrifiés et choqués, et vous passez le reste de la semaine à vous documenter pour savoir si votre assurance en responsabilité civile professionnelle va couvrir les frais du procès que vous vous êtes collé, ou juste le coût d'un règlement à l'amiable. Ou, si vous avez vraiment de la chance, le client vous fera un beau sourire et mettra votre code dans un tiroir et ne l'utilisera jamais et ne vous rappellera jamais.

Quelque part entre les deux, il y a le consultingware, où vous faites comme si vous produisiez du préemballé tout en produisant en réalité du développement sur mesure. Voici comment le consultingware fonctionne :

  1. Pour vous faire de l'argent, vous pissez du code à la demande pour le compte d'une société de chaussures, et
  2. la société a besoin d’un logiciel pour cirer des chaussures, donc
  3. vous développez votre logiciel à cirer les chaussures en VB 3.0 et en utilisant des bouts de Javascript, de Franz LISP, et une base de données FileMaker fonctionnant sur un vieux Mac connecté au réseau au moyen d'AppleScript, puis
  4. tout le monde pense que c'est le top du top, et, ayant toujours rêvé de démarrer votre propre maison d'édition de logiciels et de devenir peut-être Bill Gates ou peut-être même juste Larry Ellison,
  5. vous achetez les droits de CireChaussure 1.0 à votre ancienne société et trouvez un capital-risqueur pour mettre sur pied votre propre société, CireChaussure SARL, qui vend un logiciel à cirer les chaussures, mais
  6. aucun de vos bêta-testeurs n'arrive à le faire marcher en raison d'obscures dépendances avec AppleScript et avec des adresses IP codées en dur dans le programme, ce qui fait que ça prend un mois à installer sur chaque site client, et
  7. vous peinez à trouver des clients, parce que votre produit est très cher quand on compte tous les coûts d'installation, surtout en y incluant le vieux Macintosh IIci sous System 7, qui ne se fait plus depuis longtemps et que vos clients doivent acheter sur eBay dans le musée des ordinateurs ; donc votre capital-risqueur commence à devenir vraiment nerveux,
  8. ce qui met la pression sur les vendeurs,
  9. dont l'un découvre qu'un de vos clients potentiels n'a pas besoin d'un logiciel à cirer les chaussures mais qu'il aurait par contre bien besoin d'un logiciel à repasser les pantalons, et
  10. le vendeur, en bon vendeur qu'il est, lui fourgue pour 100'000 dollars de logiciels à repasser les pantalons,
  11. et maintenant vous passez 6 mois à écrire un "module de repassage de pantalons" à usage unique pour ce client, dont
  12. aucun autre client n'aura jamais besoin. Ainsi,
  13. en tout et pour tout, vous avez juste passé une année à lever des fonds d'investissement pour vous retrouver à pisser du code pour une compagnie de pantalons ; GOTO 1.

Mon gros malin, je vais devoir fortement te recommander de t’accrocher aussi fortement que possible du côté préemballé de l'équation. C'est parce que le préemballé n'a aucun coût marginal pour chaque client supplémentaire, et donc que tu peux essentiellement vendre la même chose à plusieurs reprises, plein de fois, et dégager beaucoup plus de bénéfices. Non seulement ça, mais tu peux baisser le prix, parce que tu peux répartir les coûts de développement sur beaucoup plus de clients, et l'abaissement du prix te donne plus de clients parce que plus de personnes trouveront tout à coup que le logiciel en vaut la peine une fois qu'il sera bon marché, et la vie est belle et tout marche comme sur des roulettes.

Donc. Si jamais vous vous trouvez à implémenter une fonctionnalité simplement parce que ça a été promis à un client, vous dérivez vers le pays du consultingware et du développement sur mesure, ce qui va bien si c’est ce qui vous plaît, mais ça n'a pas le même potentiel de bénéfice que du logiciel commercial préemballé.

Attention, je ne suis pas en train de dire qu'il ne faut pas écouter ses clients. Moi par exemple, je pense qu'il serait vraiment grand temps que Microsoft fasse une version de la fonction BAHTTEXT pour ceux qui n'ont pas encore rejoint l'économie mondialisée et appris le thaï et qui écrivent encore des chèques dans d'autres devises. Et en fait, si vous voulez vous laisser aller à penser que la meilleure manière d'allouer vos ressources de développement est effectivement de laisser vos plus grands clients vous faire des "demandes" de fonctionnalités, bon, vous pouvez aussi faire ça, mais vous constaterez bientôt que le genre de fonctionnalités que les gros clients bien riches veulent ne sont pas les mêmes que le genre de fonctionnalités que le grand public veut, et cette fonctionnalité que vous avez ajouté pour gérer la devise Baht ne vous aide pas vraiment à vendre Excel aux établissements de balnéothérapie de Scottsdale en Arizona, alors qu'en réalité ce que vous êtes vraiment en train de faire c'est de laisser votre force de vente prostituer vos développeurs dans l’unique but de maximiser leurs commissions personnelles, un peu comme des maquereaux.

Ce n’est pas comme ça que vous allez devenir Bill Gates.

Maintenant, laissez-moi vous conter la deuxième mauvaise manière de décider quelles fonctionnalités implémenter. Ne faites pas les choses juste parce qu'elles sont inévitables. L'inévitabilité n'est pas un critère assez discriminant. Laissez-moi vous expliquer.

Une fois, pendant la première année à Fog Creek’s, alors que je classais quelques papiers, je me suis rendu compte que je n’avais que des chemises de rangement bleues.

Maintenant, j'ai un système. Les chemises bleues sont pour les clients. Les chemises beiges sont pour les employés. Les chemises rouges sont pour les reçus. Tout le reste est en jaune. J'ai eu besoin d'une chemise bleue et je n’en avais plus.

Je me suis alors dit, "oh et puis tiens, je vais bien finir par avoir besoin d'une chemise bleue à un moment, je n'ai qu'à aller à la papeterie et en acheter maintenant."

Ce qui était, naturellement, une perte de temps.

En fait, en y repensant plus tard, je me suis rendu compte que pendant longtemps, j'avais fait plein de trucs débiles parce que je me disais qu'un jour ou l'autre, je finirais bien par devoir le faire, donc je pouvais tout aussi bien le faire maintenant.

J'utilisais cette excuse pour désherber le jardin, pour boucher les trous dans les murs, pour trier les disques MSDN (par couleur, langage de programmation, et numéro), etc., etc., alors que j'aurais dû programmer ou vendre, les deux seules choses qu’une start-up a vraiment besoin de faire.

En d'autres termes, je me retrouvais à faire comme si toutes les tâches non facultatives étaient d'égale importance, et donc, puisqu'elles étaient de toute façon inévitables, elles pouvaient être faites dans n'importe quel ordre ! Tada !

Mais pour être honnête, je ne faisais que remettre le boulot au lendemain.

Qu'est-ce que j'aurais dû faire ? Bon, pour commencer, je pourrais apprendre à vivre sans ma manie d'avoir des dossiers de la bonne couleur. Ca ne fait absolument aucune différence. On n'est pas obligé d'avoir un code couleur pour ses dossiers.

Ah, et tous ces CD-ROMs MSDN ? Les jeter dans une grande boîte. Par-fait.

Mais surtout, j'aurais dû me rendre compte que l'"importance", ce n'est pas une notion binaire, c’est analogique. Il y a toutes sortes de nuances au mot important, et si vous essayez de tout faire, vous n’accomplirez jamais rien.

Donc si vous voulez accomplir des choses, vous devez vraiment bien comprendre, à tout moment, quelle est la chose la plus importante à faire maintenant, là, tout de suite, celle qui fait que vous progressez le plus rapidement.

Petit à petit, je me détourne de ma tendance à reporter les choses. Je le fais en laissant des choses moins importantes non faites. Il y a une gentille dame de la compagnie d'assurance qui m'avait agacé pendant deux mois pour obtenir quelques données pour renouveler notre police d’assurance, et je ne lui ai pas réellement fourni les données avant qu’elle ne me les demande pour la cinquième fois avec un avertissement sévère que notre assurance allait expirer dans trois jours. Et c'est une bonne chose, je pense. J'en suis venu à penser que maintenir son bureau en état de propreté est probablement, en fait, un signe d'improductivité.

Je suis terrorisé rien que d'y penser, tiens !

Donc. Ne choisissez pas les fonctionnalités à implémenter en fonction de ce que les vendeurs ont, par inadvertance, promis à un unique client, et ne commencez pas non plus par les fonctionnalités sans importance / amusantes en vous disant que "vous allez devoir les faire par la suite de toute façon".

Bref, revenons-en au sujet du choix des fonctionnalités pour FogBugz 5.0. Voici comment nous avons obtenu notre priorisation initiale.

D'abord, j'ai pris une pile de bristols, et j’ai écrit une fonctionnalité sur chaque. Ensuite, j'ai appelé l'ensemble de l’équipe. D'après mon expérience, cette méthode fonctionne jusqu'à environ vingt personnes, et c'est une bonne idée d'avoir autant de visions différentes dans la pièce que possible : programmeurs, concepteurs, les gens qui parlent aux clients, vendeurs, manageurs, auteurs de documentation et testeurs, et même (!) des clients.

J'ai aussi demandé à chacun d’apporter sa propre liste d'idées de fonctionnalités à la réunion. La première partie de la réunion consistait à parcourir chaque fonctionnalité très, très rapidement et à s'assurer que l’on avait une compréhension commune très, très approximative de ce qu'était la fonctionnalité, et que chaque fonctionnalité était bien sur une carte.

À ce stade, l'idée n'était pas de débattre du mérite des fonctionnalités, de prototyper la fonctionnalité, ou même d'en discuter : juste d’en avoir une vague idée approximative. Les fonctionnalités pour FogBugz 5.0 étaient des choses comme :

  • Page d’accueil personnalisable
  • Planning de développement sans douleur
  • Suivi du temps à facturer aux clients
  • Passer un bogue sur une autre branche
  • (et 46 autres...)

Des trucs très vagues. Rappelez-vous que nous n'avons pas eu besoin de savoir à ce moment comment chaque fonctionnalité allait être réalisée, ou ce qu'elle impliquait, parce que notre seul but est d’obtenir une priorisation grossière qui pourrait être utilisé comme base pour commencer le développement. Ceci nous a donné une liste d'environ 50 fonctionnalités principales.

Dans la deuxième partie, nous sommes passés sur toutes les fonctionnalités et tout le monde a voté pour chaque fonctionnalité : juste un rapide vote à main levée. Pas de discussion, rien : un pouce vers le haut ou vers le bas sur chaque fonctionnalité. Ceci a révélé qu’environ 14 des fonctionnalités proposées n'avaient pas beaucoup de soutien. J'ai jeté toutes les fonctionnalités qui ont seulement obtenu une ou deux voix, ce qui nous a laissé 36 fonctionnalités potentielles.

Ensuite, nous avons assigné des coûts pour chacune de ces fonctionnalités, sur une échelle de 1 à 10, avec 1 pour une fonctionnalité rapide et 10 pour une fonctionnalité monstre. Ici il est important de se rappeler que le but n'était pas de planifier les fonctionnalités: juste de séparer les fonctionnalités minuscules des fonctionnalités moyennes des fonctionnalités énormes. Je suis juste passé par chacune des fonctionnalités et ai demandé aux développeurs de dire "petit," "moyen," ou "grand." Même sans savoir combien de temps une fonctionnalités va prendre, il est facile de voir que passer un bogue sur une autre brancheest une "petite" fonctionnalité tandis que la grosse, vague fonctionnalité "Page d’accueil personnalisable" était grande. Basé sur l'évaluation commune des coûts et de mon propre jugement, nous avons apposé des prix à toutes les fonctionnalités :

Coûts
Page d’accueil personnalisable$10
Planning de développement sans douleur$4
Suivi du temps à facturer aux clients$5
Passer un bogue sur une autre branche$1

De nouveau, c’est vraiment grossier, ce n'est pas exact, et ça n'a pas d’importance. Vous n'en êtes pas encore au planning : vous vous donnez juste les priorités. La seule chose qui doit être approximativement correcte est que grosso modo, vous pourrez faire deux fonctionnalités moyennes ou une grande fonctionnalité ou dix petites fonctionnalités dans une période de temps à peu près identique. Elle n'a pas besoin d'être précise.

La prochaine étape était de faire une "carte" avec les trente fonctionnalités proposées et leur "coûts". Chacun dans l'équipe a obtenu une copie du menu et a eu $50 pour jouer avec. Ils pouvaient affecter leur argent de n'importe quelle manière, mais ils avaient seulement $50 à dépenser. Ils pouvaient acheter des moitiés de fonctionnalité, s'ils voulaient, ou acheter des fonctionnalités deux fois. Quelqu'un qui voulait beaucoup la fonctionnalité "Suivi du temps à facturer aux clients" pouvait dépenser $10 ou $15 dessus ; quelqu'un qui la voulait seulement un petit peu pouvait dépenser $1 et espérer que d'autres personnes l’aient financées.

Ensuite, nous avons fait le total de ce que les uns et les autres ont dépensé sur chaque fonctionnalité :

CoûtsDépense
Page d’accueil personnalisable$1012
Planning de développement sans douleur$46
Suivi du temps à facturer aux clients$55
Passer un bogue sur une autre branche$13

Pour finir, j’ai divisé la somme dépensée par le coût :

CoûtsDépense
Page d’accueil personnalisable$10121.2
Planning de développement sans douleur$461.5
Suivi du temps à facturer aux clients$551.0
Passer un bogue sur une autre branche$133.0

Et alors, trié par ce nombre pour trouver quelles sont les fonctionnalités les plus populaires :

CoûtsDépense
Passer un bogue sur une autre branche$133.0
Planning de développement sans douleur$461.5
Page d’accueil personnalisable$10121.2
Suivi du temps à facturer aux clients$551.0

Tada ! Une liste de toutes les fonctionnalités que vous pourriez vouloir faire, dans un ordre approximatif de l'importance que le groupe de personnes dans la salle leur attribue.

Et maintenant vous pouvez commencer à raffiner. Par exemple, vous pouvez regrouper ensemble les fonctionnalités qui se regroupent naturellement : par exemple, faire le planning de développement rend le suivi du temps de facturation plus facile, alors peut-être que nous devrions faire soit les deux soit ni l'une ni l'autre. Et parfois, en regardant la liste de priorités, on voit de façon réellement évidente quelque chose de pas net. Alors, on change ! Rien n'est gravé dans la pierre. Vous pouvez même changer le priorisation pendant que vous êtes en cours de développement.

Mais ce qui m'a le plus étonné est que la liste finale que nous avons produite était vraiment une priorisation très bonne pour FogBugz 5.0, et a vraiment reflété notre consensus collectif au sujet des priorités relatives de diverses fonctionnalités.

Une fois cette liste des priorités en main, nous visons à travailler plus ou moins jusqu'à mars, et puis nous cesserons normalement d'ajouter de nouvelles fonctionnalités et commencerons l'intégration et la phase de test. Nous écrirons les spécifications de chaque fonctionnalité (du moins, pour celles qui ne sont pas évidentes) avant de l'implémenter !

(Les pipelettes qui comptent les points dans le concours de beauté entre BDUF et Agile sont maintenant complètement perplexes. "Etait-ce un vote pour BDUF ? Ou Agile ? Que veut-il ? Ne peut-il pas juste se choisir un côté pour une fois ? !")

Le procédé de planification a pris en tout trois heures.

Si avez la chance de pouvoir sortir des logiciels plus fréquemment que nous, (voir "Picking a Ship Date"), vous devez toujours travailler la liste dans l'ordre, mais vous pouvez vous arrêter en chemin et publier de nouvelles versions plus souvent. Ce qui est bien avec ça, c'est que vous pouvez reprioriser la liste régulièrement en fonction des retours réels de la clientèle, mais tous les produits n'ont pas ce luxe.

Mike Conte m'a enseigné ce système pendant la planification de Excel 5, où il a seulement pris quelques heures même avec quelques douzaine de personnes dans une salle de conférence. Ce qui est super, c'est qu'approximativement les 50% de fonctionnalités que nous n'avons pas eu le temps de réaliser étaient des fonctionnalités vraiment stupides, et qu'Excel était meilleur sans.

Ca vaut ce que ça vaut, mais en tout cas, je vais vous dire une chose : c’est toujours mieux que d’aller à la papeterie pour acheter ces dossiers bleus.

Personal tools