Combien d'employés de Microsoft faut-il pour changer une ampoule ?

**Katleen Erna** · 21/10/2010, 21h03

Combien d'employés de Microsoft faut-il pour changer une ampoule ? Les développeurs de la firme ont de l'humour

Sur le blog de Microsoft, un développeur a posté une entrée plutôt originale où, s'inspirant du message de l'un de ses collègues décrivant le fonctionnement de l'entreprise, il expose la manière dont les équipes de Microsoft s'y prendraient théoriquement pour changer une ampoule, en parallèle de leur processus de développement interne.

Alors, combien d'employés de Microsoft faut-il pour changer une ampoule ?

- Un développeur passera 5 minutes à implémenter ChangeLightBulbWindowHandleEx.
- Un program manager écrira la spécification
- Un expert en localisation l'examinera
- Un expert en matière d'utilisation l'examinera également pour pallier à d'éventuels soucis d'accessibilité ou pratiques
- Au moins un développeur, un testeur et un program manager se réuniront pour réfléchir aux problèmes de sécurité
- Un program manager ajoutera les recommandations de sécurité à la spécification
- Un testeur préparera les étapes du test
- Un responsable du test programmera son passage
- Un tester rédigera les cas à étudier et il les ajoutera à l'automatisation nocturne
- Trois ou quatre testeurs participeront au processus et rechercheront les failles
- Un rédacteur technique réalisera la documentation
- Un rédacteur technique relira la documentation et la corrigera
- Un éditeur approuvera la version finale de la documentation
- Un responsable de la documentation l'intégrera dans le corps de texte déjà existant et mettra à jour l'index, etc.
- 25 traducteurs traduiront la documentation et les messages d'erreur dans tous les langages pris en charge par Windows
- Une équipe de responsables senior s'occupera de la coordination de toutes ces personnes, leur versera leurs salaires, et en réfèrera au Vice-Président pour justifier les coûts du projet

Source : Le blog de Microsoft

**zandru** · 21/10/2010, 21h17

Et l'ampoule n'est toujours pas changé

**Neko** · 21/10/2010, 21h27

Oui, enfin le but du billet est pour expliquer pourquoi il n'implémentait pas des trucs simples qui prennent que 5 lignes de code dans VBScript.

**FaridM** · 21/10/2010, 23h21

Si il faut toutes ces personnes juste pour (un jour peut-être) changer une ampoule, combien ils sont pour développer leur OS???

**cs_ntd** · 22/10/2010, 00h06

[TROLL]A peine un peu plus, c'est pour ça que ça marche si mal[/TROLL]

**Droup** · 22/10/2010, 00h17

Le pire dans cette histoire, c'est que plus de la moitié de ces personnes existent aussi dans les autres entreprises.
Le simple fait de changer un néon, ou remettre en place une plaque du faux plafond (Ayant bougé avec un courant d'air), et il faut appeler une personne habilitée à faire le boulot, qu'on pourrait faire en 30 sec.

Et je ne vous parle même pas de demander d'acheter quelque chose.

**deverdeb** · 22/10/2010, 09h58

Ils commencent par l'implémentation, avant de faire études et spécifications...
C'est pas bien ça !

**Floréal** · 22/10/2010, 10h56

C'est un listing de personne pas l'ordre d'intervention

**tsunamichups** · 22/10/2010, 13h04

On dirais le mode de fonctionnement de l'administration Française

**Marco46** · 22/10/2010, 13h54

Il manque la bonne réponse : Zéro.

Ben oui, une ampoule grillée c'est une fonctionnalité d'économie d'énergie.

**bubulemaster** · 22/10/2010, 14h53

Envoyé par tsunamichups

On dirais le mode de fonctionnement de l'administration Française

Vous n'avez pas travaillé dans des grandes entreprises (sans lien avec l'état), c'est parfois pire !

Ca montre que plus il y a de monde, plus l'organisation est complexe même pour une chose simple.
Est-ce justifié ou non, je ne sais pas.

En tout cas, ça montre une certaine capacité auto-critique et c'est plutôt bien.

**Thes32** · 22/10/2010, 15h44

Quand on pense que cela doit être réfait à chaque bug !

**Hellwing** · 22/10/2010, 16h01

Envoyé par bubulemaster

Vous n'avez pas travaillé dans des grandes entreprises (sans lien avec l'état), c'est parfois pire !

Ca montre que plus il y a de monde, plus l'organisation est complexe même pour une chose simple.
Est-ce justifié ou non, je ne sais pas.

Je pense surtout que dans les grandes entreprises il y a un seul processus à respecter à chaque fois, plutôt qu'un par projet, et tous les projets sans exception y passent, les gros comme les petits.

Donc en terme d'organisation ce n'est pas si déconnant que ça. Après reste à savoir si c'est toujours justifié...

**thelvin** · 24/10/2010, 19h39

Si on raisonne en termes de résultat final, ça n'a pas franchement l'air justifié :

à force, j'imagine, de devoir passer l'analyse de tant de gens chacun y apportant sa petite pierre et n'osant pas trop contester l'intervention de ses collègues parce qu'ils savent certainement ce qu'ils font...

On se retrouve donc avec des trucs bien plus compliqués que ce qui aurait été fait autrement, bien moins universel que ce qui aurait été fait autrement, et bien plus buggé que ce qui aurait été fait autrement.
L'idée de départ ayant été, je le rappelle, de pas impacter le monde entier avec une solution mal fichue parce qu'on se serait lancé tête baissée là-dedans. Super réussite.

**wiztricks** · 24/10/2010, 21h40

Salut,

Ca montre que plus il y a de monde, plus l'organisation est complexe même pour une chose simple.
Est-ce justifié ou non, je ne sais pas.

Plus le projet est "complexe", plus il sera coûteux et risqué....
Et le mener à bien dans des délais raisonnable rendra nécessaire de faire bosser nombre de personnes ensemble i.e. organiser leurs activités, formation, remplacement,...

Faire voler un 747 de Paris à New-York sans frêt ni passagers sera probablement aussi coûteux et compliqué que s'il était plein.

Là ou les choses peuvent devenir "discutables", c'est lorsqu'on ne sait plus réaliser de petits projets i.e. les coûts de structure, d'organisation sont tels que le projet qui coûterait moins de NN K€ n'a plus aucun intérêt et possibilités d'être réalisé "simplement".

C'est juste un problème de "coût de structure" inadapté à la mission.
La solution est de pouvoir mettre en place des chemins de traitements "adaptés". Mais c'est souvent plus facile à dire qu'à faire.

- W

**captainKirk** · 27/10/2010, 14h11

Moi je dirais AUCUN : c'est un problème hardware, Microsoft le fera sous-traiter

**Kikuts** · 27/10/2010, 15h51

MDR Marco46

Ba après ils disent ça, mais moi quand j'ai rapporté un bug sur le site silverlight.net, il a été corrigé l'après midi même ! Donc soit les employés sont ultra disponibles et n'ont rien à foutre, soit ils adaptent les processus aux projets

**wiztricks** · 27/10/2010, 17h18

Envoyé par Kikuts

Ba après ils disent ça, mais moi quand j'ai rapporté un bug sur le site silverlight.net, il a été corrigé l'après midi même ! Donc soit les employés sont ultra disponibles et n'ont rien à foutre, soit ils adaptent les processus aux projets

L'avantage de travailler sur des produits à grande diffusion, c'est que vous n'êtes probablement pas le seul client à vous plaindre, ou que le lourd processus de revue du code ou des plans de tests qui vise à s'améliorer dans le temps à découvert la chose.

Dans les deux cas, vous aurez une mécanique d'allocation des ressources pour définir l'ordre de traitement des "bugs": la criticité, le chiffre d'affaire réalisé avec le client, les projets en cours, la complexité du code à ré-écrire, les évolutions prévues, ...

Une fois que la correction aura été construite, validée et testée elle ne sera pas nécessairement diffusée à l'ensemble des clients. Seulement à ceux qui posent de réels soucis, les autres devant se contenter d'un "merci de nous avoir rapporté ce problème, il sera corrigé avec le prochain service pack".

Ce type d'organisation corrige des bugs tous les jours et produit de nouvelles versions en intégration continue. Ces nouvelles versions ne sont généralement pas rendue "publiques" au fil de l'eau mais en fonction de la criticité des corrections ou de la proportion de clients impactés.
- W