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

From The Joel on Software Translation Project

Jump to: navigation, search
Article original: Painless Functional Specifications - Part 3: But... How?
Date de publication: 04 Octobre
Traducteur: Benoit Brodard
Vérifié par: Non-communiqué
Navigation: Retour à Main Page Retour à French FrenchFlag.png




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 recommande 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 empirât 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 juniors 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é. Finalement, 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. À partir de ce moment, le Manager de Programme détiendrait la conception et les specs du produit.

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'attente 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. À mon époque, les groupes de Microsoft avec de forts Manager de Programme avait d'excellents produits : Excel, Windows 95, et 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 probablement 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, diplomatie, 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 Programme a simplement un profil de carrière bien distinct. Tous les Managers de Programme doivent être très techniques, 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és dans 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é, 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 hypertextes 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.

Personal tools