Joel on Software

Joel on Software   Joël à propos de logiciel

 

D'autres articles de "Joel on Software" en Français

D'autres articles de "Joel on Software" en Anglais

Contacter l'auteur (En Anglais uniquement)

 

Les spécifications fonctionnelles sans peine - 3ième partie: Mais... Comment?


Par Joël Spolsky
Traduit par Benoit Brodard
4 octobre 2000

Maintenant que vous avez tout lu quant à pourquoi vous avez besoin de specs et ce que contient une spec, parlons de qui doit les écrire.

Qui écrit les specs?

Laissez moi ici vous conter une petite histoire relative à Microsoft. Quant Microsoft a commencé à grossir sérieusement dans les années 80, tout le monde là-bas avait lu The Mythical Man-Month , un des classiques de la gestion de projets informatiques. (Si vous ne l'avez pas lu, je vous le recommende vivement.) La conclusion essentielle de ce livre est que lorsque vous ajoutez des programmeurs supplémentaires à un projet en retard, il prend encore plus de retard. Parce que lorsque vous avez n développeurs dans une équipe, les chemins de communication sont au nombre de n(n-1)/2, qui croît en O(n 2).

Donc, les programmeurs chez Microsoft s'inquiétaient de pouvoir écrire des programmes de plus en plus gros, quand la sagesse ambiante voulait qu'ajouter des programmeurs empirait juste la situation.

Charles Simonyi, "chef architecte" chez Microsoft de longue date, suggéra le concept de maîtres programmeurs. L'idée de base était qu'un maître programmeur serait responsable d'écrire tout le code, mais il ou elle se reposerait sur une équipe de programmeurs junior comme "esclaves à coder". Au lieu de s'inquiéter de debugger chaque fonction, le maître programmeur prototyperait juste la fonction, créant une carcasse vide, et la jetterait à un des développeurs junior pour l'implémenter. (Naturellement, Simonyi serait le Maître Maître Programmeur.) Le terme "Maître Programmeur" était un peu trop médiéval, et Microsoft choisit  plutôt "Manager de Programme."

Théoriquement, cela devait résoudre le problème du Mythical Man-Month, parce que personne n'a à parler à personne d'autre -- chaque programmeur junior parle seulement au Manager de Programme, et la communication croit en O(n) au lieu de O(n2).

Bon, Simonyi doit connaître la  Notation Hongroise , mais il ne connait pas Peopleware . Personne ne veut être un esclave de code. Le système n'a pas du tout fonctionné. Finallement, Microsoft a découvert qu'en dépit du soi-disant Mythical Man Month, vous pouvez toujours ajouter des gens intelligents à une équipe et obtenir des résultats améliorés, bien qu'à valeur ajoutée marginale décroissante. L'équipe Excel avait 50 programmeurs quand j'y étais, et elle était marginalement plus productive qu'une équipe de 25 l'aurait été -- mais pas deux fois plus productive.

C'en était fini de cette idée de programmation maître/esclave, mais Microsoft avait toujours de ci de là ces personnes appelées Manager de Programme. Un homme intelligent du nom de Jabe Blumenthal a tout simplement réinventé la fonction de  Manager de Programme. A partir de ce moment, le Manager de Programme détiendrait la conception et les specs du produits.

Depuis lors, les Managers de Programme de Microsoft réunissent les besoins, conçoivent ce que le code est supposé faire et écrivent les specs. On compte habituellement 5 programmeurs pour chaque Manager de Programme. Ces programmeurs sont responsables de l'implémentation sous forme de code de ce que le Manager de programme a implémenté sous forme de spec. Un manager de programme doit également coordonner le marketing, la documentation, les tests, l'internationalisation, et tous les autres détails ennuyeux sur lesquels les programmeurs ne devraient pas passer de temps. Enfin, les Managers de Programmes de Microsoft sont censés avoir en tête la vue d'ensemble de l'entreprise, tandis que les programmeurs sont libres de se concentrer sur la perfection de leurs morceaux de code.

Les Managers de Programme sont d'une valeur inestimable. Si vous vous êtes déjà plaints que les programmeurs s'inquiètent plus de subtilités techniques que de l'attentte du marché, vous avez besoin d'un Manager de Programme.  Si vous vous êtes déjà plaints de ce que les personnes qui peuvent écrire un excellent code ne font jamais l'affaire pour écrire correctement français, vous avez besoin d'un Manager de Programme. Si vous vous êtes déjà plaints que votre produit semble dériver sans direction très claire, vous avez besoin d'un Manager de Programme .

Comment embaucher un Manager de Programme

 

La plupart des entreprises n'ont pas même pas le concept de Manager de Programme. Je pense que c'est très dommage. A mon époque, les groupes de Microsoft  avec de forts Manager de Programme avait d'excellents  produits : Excel, Windows 95, and Access me viennent à l'esprit. Mais les autres groupes (tels que MSN 1.0 et Windows NT 1.0) étaient conduits par des développeurs qui généralement ignoraient les Managers de Programme (qui n'étaient pas très bon de toute façon,  et méritaient probblement d'être ignorés), et leurs produits n'étaient pas aussi renommés.

Voici trois choses à éviter :

1. Ne faites pas évoluer un codeur vers le poste de Manager de Programme. Les qualités qui font un bon manager de programme (écriture fluide, diplomacie, sensibilité au marché, empathie envers l'utilisateur, bonne conception d'interface) sont très rarement les qualités d'un bon programmeur. Bien sûr, certaines personnes peuvent faire les deux mais elles sont rares. Récompenser les bons programmeurs en les faisant évoluer à une position différente , une qui requiert d'écrire du français, pas du C++, est un cas classique du Principe de Peter : les gens finissent par être promus à leur niveau d'incompétence.

2. Ne laissez pas les gens du marketing être Manager de Programme. Sans vouloir offenser personne, je pense que mes lecteurs conviendront que les personnes compétentes du marketing ont rarement la compréhension technologique nécessaire pour concevoir de bons produits.

Le Manager de Program a simplement un profil de carrière bien distinct. Tous les Managers de Programme doivent  être très technique, mais ils n'ont pas besoin de bons programmeurs. Les Managers de Programme étudient les interfaces utilisateurs, rencontrent les clients, et écrivent les specs. Ils doivent pouvoir s'entendre avec une grande variété de personnes -- des clients bougons aux irritants programmeurs hermites qui viennent travailler en tenue de Star Trek, en passant par les commerciaux sophistiquésdans des costumes à 2000 Euros. D'une certaine façon, les Managers de Programme sont le ciment des équipes de développement. Le charisme est capital.

3. Ne faites pas rendre aux programmeurs des comptes au Manager de Programme. C'est une erreur subtile. En tant que Manager de Programme chez Microsoft, j'ai conçu la stratégie Visual Basic (VBA) pour Excel et j'ai complètement spécifiée, dans les plus petits détails, comment VBA devait être implémenté dans Excel. Ma spec a atteint les 500 pages. Au niveau de développement atteint pour Excel 5.0, j'estimais que chaque matin, 250 personnes venaient travailler, et travaillaient à partir de cette énorme spec que j'avais rédigée. Je n'avais aucune idée de qui étaient tous ces gens, mais il y avait une douzaine de personnes dans l'équipe Visual Basic seule juste pour rédiger la documentation de cette chose (sans parler de l'équipe rédigeant la documentation pour la partie Excel, ou la personne à plein temps responsable des liens hypertexte dans le fichier d'aide.) Bizarrement, j'étais tout en bas de l'arbre de la hiérarchie. Exactement. PERSONNE ne me rendait des comptes. Si je voulais que les gens fassent quelque chose, je devais les convaincre que c'était la bonne chose à faire. Quand Ben Waldman, le programmeur en chef, ne voulait pas faire quelque chose que j'avais spécifié, il ne le faisait pas, tout simplement. Quand les testeurs se plaignaient que quelque chose que j'avais spécifié était impossible à tester complètement, je devais le simplifier. Si l'une ou l'autre de ces personnes m'avaient rendu des comptes, le produit n'aurait pas été aussi bon. Certains auraient pensé qu'il n'était pas approprié de contredire un supérieur. En d'autres temps, je les aurais juste écrasés du pied et leur aurais ordonné de le faire à ma façon, sans souci ???. Mais là, je n'avais pas d'autre choix que d'atteindre un consensus.Cette façon de prendre les décisions était le meilleur moyen d'arriver au bon résultat. 

Le dernier article  de cette série sur les specs explique comment rédiger de bonnes specs que les gens veulent lire.



Cet article est paru en version originale anglaise sous le titre Painless Functional Specifications Part 3  

Joël Spolsky est le fondateur de Fog Creek Software, une petite société éditrice de logiciel située à New York. Il est diplômé de l'Université de Yale et a travaillé comme programmeur et manager chez Microsoft, Viacom et Juno.


Le contenu de ces pages représentent l'opinion d'une personne.
Contenu protégé par le copyright ©1999-2005 par Joël Spolsky. Tous droits réservés.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky