Voici une blague :

1. Un programmeur écrit du code qu'il croit exempt de bugs.

2. Les tests logiciels trouvent 20 bugs.

3. Le programmeur corrige 10 bugs et dit à l'équipe de test que les 10 autres ne sont pas des bugs.

4. L'équipe de test constate que 5 des correctifs ne fonctionnent pas du tout, et découvre en même temps 15 nouveaux bugs.

5. Répétez les étapes 3 et 4 trois fois.

6. En raison de la pression du marché, et pour respecter le calendrier de sortie trop optimiste fixé à l'origine, le produit a finalement été mis en vente.

7. Les utilisateurs trouvent 137 nouveaux bugs.

8. Le programmeur, qui a déjà encaissé le bonus du projet, est introuvable.

9. L'équipe projet nouvellement formée corrige presque tous les 137 bogues, mais découvre ensuite 456 nouveaux bogues.

10. Le programmeur d'origine envoie une carte postale depuis Fidji à l'équipe de test, qui souffre de salaires impayés. Toute l'équipe de test démissionne en masse.

11. L'entreprise est rachetée de façon malveillante par un concurrent. Au moment du rachat, la version finale du logiciel contient 783 bogues.

12. Un nouveau PDG prend ses fonctions. L'entreprise embauche un nouveau programmeur pour réécrire le logiciel.

13. Le programmeur écrit du code qu'il croit exempt de bogues.

Si vous voulez mon avis, si une telle entreprise existe vraiment, ne pas faire faillite serait un mauvais service rendu aux gens.

Cette blague commence avec un programmeur, se termine avec un programmeur, et blâme les programmeurs du début à la fin. Mais ce que je veux dire, c'est que c'est entièrement l'échec des managers—tout au long du processus, aucun travail de gestion n'est visible du tout. De tels managers sont non seulement ignorants et incompétents, mais aussi sans vergogne—en rejetant la responsabilité de leur propre échec sur les programmeurs.

1. Qu'est-ce qui autorise le programmeur à prouver que son code n'a pas de bogues ? Y a-t-il des cas de test ? Y a-t-il une revue de code ? La gestion est absente à cette phase.

2. Après que les tests ont trouvé des bogues, une gestion des bogues a-t-elle été effectuée ? Y a-t-il eu un suivi ? La gestion est absente à cette phase.

3. Qu'est-ce qui prouve que le programmeur a réellement corrigé ces 10 bogues ? Et pourquoi les 10 autres ne sont-ils pas des bogues ? Le standard d'évaluation des bogues est-il déterminé par la simple parole du programmeur ? La gestion est absente à cette phase.

4. Quelqu'un a-t-il été tenu pour responsable des 5 corrections de bogues qui n'ont pas fonctionné ? L'ajout de nouveaux bogues est inévitable pendant le processus de modification, mais avec un mécanisme efficace de tests unitaires, cette situation pourrait être grandement réduite. La gestion est absente à cette phase.

5. L'itération est normale, mais les problèmes divergent au lieu de converger, ce qui montre qu'il n'y a aucun contrôle de gestion efficace. La gestion est absente dans cette phase.

6. Tant le calendrier trop optimiste que le délai impossible démontrent l'ignorance et l'incompétence du manager. Forcer la sortie du produit dans de telles circonstances n'est rien de moins que « l'ignorant n'a peur de rien ».

7. C'est irresponsable envers les utilisateurs, et le manager en porte la plus grande responsabilité.

8. Pouvoir distribuer des primes de projet dans de telles circonstances montre seulement que ce manager n'est pas d'une bêtise ordinaire.

9. Aucune amélioration n'a été apportée au travail de gestion, et les problèmes restent dans un état d'itération divergente. La gestion n'est toujours pas en place.

10. Retenir les salaires du service de test reflète la négligence du manager envers la gestion de la qualité et son ignorance totale de la gestion des ressources humaines.

11. Deux mots pour l'entreprise acquise : bien fait pour elle. Deux mots pour l'acquéreur : aveugle.

12. Il est clair que le nouveau manager et l'ancien manager, c'est bonnet blanc et blanc bonnet—aucun des deux ne reconnaît la racine du problème. Mais après tout, seul un tel manager prendrait la décision d'acquérir ce genre d'entreprise.

13. La répétition de l'histoire est inévitable.

Pour une entreprise ou un projet normal, son fonctionnement doit se faire dans un cycle ascendant. Le travail qui garantit ce fonctionnement est la gestion. Et le contenu principal de la gestion est le contrôle, y compris le contrôle du rythme du cycle—ni trop rapide ni trop lent ; le contrôle de la direction du développement—seulement vers le haut, jamais vers le bas ; et le contrôle de la stabilité des opérations—pas de hauts et de bas spectaculaires, pas de rassemblements et de dispersions sur un coup de tête.

Et rien de tout cela n'est visible dans cet exemple.

Dans l’exemple de cette blague, tout est piloté par le travail de développement, ce qui est avant tout une erreur d’orientation. Un produit sert les utilisateurs, donc il doit bien sûr être piloté par les utilisateurs et le marché, et l’axe de travail doit en fin de compte être défini en tenant compte de ses propres capacités. Cette erreur montre que le manager ne comprend pas très bien ce qu’il gère, de sorte qu’il ne peut qu’être à la merci des programmeurs qui le comprennent mieux — et en fait, à part la technologie, ils ne comprennent pas grand-chose de plus.

Si un manager ne comprend pas ce qu’il gère, il ne peut pas bien le gérer.

Cela ne fait aucun doute, pourtant l’industrie nationale du logiciel semble toujours refuser d’y croire. L’un des mensonges les plus profondément ancrés dans l’industrie chinoise du logiciel est le suivant : un manager n’a besoin de comprendre que la gestion, pas la technologie.

En fait, cela est purement et simplement inventé par ces managers ignorants, incompétents et sans vergogne afin d’escroquer de l’argent. Ceux qui y croient paieront inévitablement le prix en argent.

Deuxièmement, la gestion de la qualité. Le bon sens élémentaire en matière de gestion de la qualité nous dit qu’avant la fin de chaque cycle, la tâche la plus importante est de capitaliser et de s’améliorer. Ce n’est qu’ainsi que nous pouvons garantir que le fonctionnement cyclique se développe vers le haut, plutôt que de se développer de façon incontrôlée et à la baisse. Seule une gestion de la qualité efficace peut garantir que le processus d’itération converge et atteint finalement son objectif. Mais dans cet exemple, cette partie est clairement absente — bien qu’il existe un service de test, son rôle ne se limite qu’à l’étape de contrôle qualité de la gestion de la qualité ; la partie gestion reste absente.

Vient ensuite la gestion des ressources humaines. Le développement logiciel est un travail intensif ; bien qu'il s'agisse d'un travail intellectuel, cela signifie tout autant que le facteur humain y occupe une position décisive. Dans l'exemple, le programmeur qui n'avait pas terminé de corriger les bugs a reçu la prime du projet, tandis que les testeurs, tout aussi travailleurs, ont vu leur salaire retenu. Cela montre non seulement le manque de compréhension du manager à l'égard de leur travail et son mépris pour la gestion de la qualité, mais aussi qu'il est totalement incapable de gérer des personnes. C'est un acte de meurtre d'équipe — tuer une équipe est bien plus facile que d'en bâtir une.

Finalement, ce manager raté a transformé son expérience en cette plaisanterie, laissant tout le monde voir à quel point il avait été victimisé par les programmeurs et diabolisant les programmeurs comme une bande de menteurs. Mais quiconque possède ne serait-ce qu'un peu de connaissances en management peut constater, par une simple analyse, que seule l'ignorance et l'incompétence de cette personne l'ont conduit à sa situation actuelle, et son comportement consistant à rejeter la faute sur les autres montre encore davantage son impudence. En tant que managers occupant de hautes fonctions, s'ils se dérobent même aux responsabilités qui leur incombent, de quoi d'autre sont-ils capables ?

Source : http://blog.csdn.net/raptor/article/details/727299