Comme vous le savez, en 2018, Google a procédé à la plus grande refonte de l'interface de son service de messagerie Gmail. Comme d'habitude, tout le monde n'était pas satisfait - et cette fois, il y a des raisons assez objectives d'insatisfaction à l'égard du service. Pourquoi le chargement de Gmail a-t-il pris autant de temps et des actions telles que la suppression ou l'archivage d'une conversation peuvent prendre de 4 à 6 secondes?
Il y a quelques jours, un
utilisateur de Hacker News a posé une question similaire - et il a reçu une réponse d'un employé anonyme de Google qui a parcouru la culture du développement au sein de l'entreprise et de ses collègues.
Selon lui, tout cela se produit du fait que Google ne prévoit aucune sanction pour de tels «ratés».
À l'intérieur des murs de l'entreprise, ils encouragent activement les lancements - la diffusion publique de quelque chose. Et le fait que les produits ne peuvent contenir que la moitié des fonctionnalités nécessaires, ne fonctionnent pas, ne fonctionnent que sous Chrome et ainsi de suite - cela ne dérange personne, car leurs créateurs ne courent aucun risque. C’est la norme.
Le sens d'une telle action n'est qu'une chose - dans l'avancement professionnel, car sans grands lancements au-delà d'un certain niveau, vous ne pourrez pas y aller. Nous nous retrouvons donc avec des centaines d'applications de chat inutiles, des remaniements et des redémarrages sans fin - sinon les individus ne pourront pas être promus.
Lorsque la direction de l'entreprise a tenté de résoudre le problème en publiant un document interne qui, au lieu de lancements, motive la réussite des «atterrissages» (
atterrissage , lancements réussis) - tout ce que les employés ont changé dans leur vie est
s / lancement / atterrissage / g dans sa revue de performance.
Prenons, par exemple, le messager Allo. Il a fallu deux ans pour le développer, après quoi la société a décidé de suspendre le développement et de geler le projet. Il s'avère que les responsables du messager n'ont pas souffert en même temps - au contraire, certains d'entre eux ont même été promus.
Hélas, apparemment, les problèmes pressants des utilisateurs de l'entreprise ne sont pas trop intéressés aujourd'hui:
Savez-vous combien de bugs vous devez corriger pour obtenir une augmentation? Infiniment. Peu importe le nombre de bugs que vous corrigez - cela ne vous apportera jamais assez de «contribution» pour augmenter, jamais. Mais il suffit d'exécuter une seule refonte - même si c'est pratiquement inutile - et la promotion est dans votre poche.
Naturellement, dans les murs de l'entreprise elle-même, il y a des gens qui avertissent de la possibilité de cela et se plaignent, mettent des bugs de performance dans les trackers - c'est tout ce qui est ignoré; la plupart des travailleurs abandonnent et cessent d'écrire sur les bogues, car la réponse typique est "vous n'êtes pas notre public cible".
Et nous connaissons tous ces problèmes! Nous tous! Certains quittent quand il s'agit d'eux; d'autres commencent simplement à «optimiser» vers le haut - au lieu d'optimiser dans le sens de ce qui est bon pour l'utilisateur ou pour l'entreprise.
Dans ses pensées, le développeur n'est pas seul. Graham Wheeler a partagé une
histoire de sa vie sur Google confirmant sa position.
Une fois chez Google, j'ai reçu une évaluation des performances négative. J'ai décidé que la meilleure façon de passer mon temps serait de refactoriser le code que j'ai obtenu pour amener le degré de couverture de test de 0% à 80%, corrigeant beaucoup de bugs en cours de route. En conséquence, j'ai obtenu une critique merdique sur la revue de performance, et l'auteur du govnokoda original a obtenu une augmentation.
Des histoires sur les problèmes de gestion du développement au sein de Google apparaissent
régulièrement sur le Web. La réaction des utilisateurs ne tarde pas non plus à venir. Les clients commerciaux utilisant Google Apps passent à
FastMail , dont le principe principal est le courrier électronique et rien de plus.
Voilà comment nous sommes et nous obtenons des choses comme le nouveau Gmail. Ce qui, d'une part, a été repensé dans l'esprit de Material Design, un mode hors ligne et de nombreuses autres améliorations mineures qui lui sont transférées depuis la boîte de réception Google, qui commandera une longue durée de vie l'année prochaine. En revanche, il effectue 358 demandes de chargement complet et télécharge 6,3 Mo. À titre de comparaison, le mode «ancien» de l'affichage HTML dans Gmail n'est que de 14 requêtes et 25,3 Ko, ce qui lui a permis de se charger en 2 secondes.
Bien sûr, cette pratique s'applique non seulement à Google, mais aussi à de nombreuses autres grandes entreprises. Nous observons le principe bien connu
«vous obtenez ce que vous mesurez» en action.
Une
histoire similaire
a été racontée par le développeur Steve , qui a travaillé chez Apple sur MacOS X Snow Leopard. Pour la plupart, Steve s'est engagé à corriger les bogues dans tous les principaux systèmes d'exploitation - et à la suite de la sortie, une promotion lui a été refusée en raison du fait que sa présence "n'était critique sur aucun des projets".
L'ironie ici est que cette version du système d'exploitation, basée sur l'idée de la gestion de l'entreprise, était censée être une version dans laquelle tout était destiné à améliorer la stabilité et les performances du système. Cependant, alors que certains d'entre eux devraient travailler sur la stabilité, d'autres ont activement "poussé" de nouvelles fonctionnalités comme le garbage collector pour Objective-C dans la version, ce qui a retardé le travail des autres et rendu Xcode impraticable pendant plusieurs mois.
Mais le travail sur les bugs n'a pas été en vain pour les utilisateurs ordinaires qui se sont souvenus des excellentes performances de Snow Leopard et du Lion suivant - contrairement à Chrome, qui n'a réussi à se figer que quelques fois pendant la rédaction de cet article et à provoquer un crash de l'onglet de projet.