Vous est-il déjà arrivé de dire quelque chose de complètement normal pour vous, mais tout le monde est très surpris? Cela m'arrive constamment lorsque je décris ce qui était considéré comme normal dans l'entreprise où je travaillais. Pour une raison quelconque, le visage de l'interlocuteur se transforme progressivement d'un sourire agréable en une grimace de stupéfaction extrême. Voici quelques exemples typiques.

Il y a une très bonne entreprise, l'un des endroits les plus agréables où j'ai jamais travaillé, une combinaison de tous les goodies de Valve et Netflix. Les gens ici sont incroyables et ils vous donnent une liberté presque totale de faire ce que vous voulez. Mais comme effet secondaire d'une telle culture, environ 50% des nouveaux employés les quittent la première année, certains volontairement et d'autres non. Absolument normal, hein?

Il y a une entreprise qui est incroyablement secrète au sujet de son infrastructure. Par exemple, il a peur de signaler les bogues au fournisseur d'équipement, car alors les erreurs seront corrigées et les concurrents pourront utiliser les corrections. Cela ne peut pas être autorisé. Solution: demandez le firmware et corrigez vous-même les bugs! D'accord.

Plus récemment, j'ai rencontré des spécialistes qui ont tenté de reproduire l'algorithme publié dans l'article de cette société. Ils n'ont pas pu reproduire le résultat. De plus, l'algorithme de l'article a conduit à un niveau d'instabilité inhabituellement élevé. Lorsque l'un des auteurs a été interrogé à ce sujet, il a répondu: «Eh bien, oui, il y a des astuces qui n'apparaissaient pas dans l'article» et a refusé de partager ces astuces. Autrement dit, la société a publié intentionnellement un résultat improductif afin de ne pas donner de détails, comme elle le faisait habituellement avec les bogues.

L'entreprise menace de licencier instantanément tout employé qui fuit des informations. Cela est dit à chaque nouveau venu avec des exemples de personnes licenciées pour la fuite (par exemple, un gars a divulgué des informations selon lesquelles le concert aurait lieu dans un certain bureau). Chaque licenciement est signalé à haute voix et communiqué à tous les employés. En raison de cette politique, beaucoup ont peur de transmettre des e-mails même avec des informations innocentes telles que la mise à jour des données d'assurance. Au lieu de cela, ils impriment une lettre à partir d'un autre ordinateur - et la transmettent sous forme papier. Ou prenez des photos au téléphone. D'accord.

Dans un bureau, j'ai demandé une fois pourquoi deux employés spécifiques semblent s'éviter. On m'a dit que leur inimitié dure depuis dix ans. En fait, la situation s'est améliorée récemment. Pendant de nombreuses années, ils ne pouvaient littéralement pas être dans la même pièce, sinon l'un d'eux se mettrait trop en colère et ferait quelque chose de malheureux. Mais maintenant, les gars ont refroidi, ils peuvent donc parfois être trouvés dans la même aile du bureau ou même dans la même pièce. Et ce ne sont pas que des gens au hasard. Ce sont les managers des deux seules équipes de cette entreprise. OK!

Il existe une entreprise avec une culture si étrange que vous pouvez écrire un petit livre à ce sujet. En fait, j'ai récemment commencé à écrire un article sur cette entreprise, et j'ai déjà écrit plus de 100 000 mots - plus que tous les articles de mon blog réunis.

Cette entreprise m'a expliqué qu'il vaut bien mieux prendre des décisions non pas sur la base de données, mais sur la base de relations politiques, et que l'idée de prendre des décisions sur la base de données est en tout cas un mythe - personne ne le fait.

Dans cette entreprise, on m'a donné quatre raisons de travailler avec eux. Tous les quatre se sont avérés être un mensonge. En conséquence, mes responsabilités professionnelles se résumaient au fait même que lorsque j'ai embauché, j'ai accepté de ne rien faire.

Lorsque j'ai rejoint cette entreprise, mon équipe n'a pas touché au système de contrôle de version pendant plusieurs mois. J'ai dû me battre pour que tout le monde l'utilise. J'ai gagné cette bataille. Mais il n'a pas réussi à convaincre les employés d'exécuter les tests en premier. Par conséquent, l'assemblage se brise plusieurs fois par jour.

Dans une conversation avec la direction, j'ai laissé entendre que je considère cela comme un problème de productivité de notre département. On m'a dit que c'était normal. C'est la situation de tous les employés, donc tout le monde est sur un pied d'égalité. Ma tâche est de les classer, donc si le problème affecte tout le monde de la même manière, il n'y a aucune raison de s'inquiéter.

Une autre entreprise a lancé de nombreuses initiatives à grande échelle pour attirer les femmes développeurs, mais les femmes sont toujours sélectionnées pour des entretiens avec des questions comme «Avez-vous eu de l'expérience avec les algorithmes ou seulement le codage?» Je pensais que mon candidat avec une très bonne recommandation passerait par cet obstacle mais j'ai oublié à quel point l'entreprise était normale.

Dans une autre entreprise, j'ai travaillé en équipe de quatre sur un projet avec un budget de plusieurs centaines de millions de dollars et un effet annuel d'un milliard de dollars. Dans le même temps, les demandes de biens d'une valeur de centaines de dollars ont été examinées pendant des mois ou rejetées.

Il peut vous sembler que je n'ai travaillé que dans des entreprises exceptionnellement mauvaises. Mais non, ils ont une bonne réputation, et deux d'entre eux sont considérés comme l'une des meilleures entreprises pour l'emploi. Et j'ai entendu des histoires similaires de la part d'employés d'autres sociétés, même avec une excellente réputation d'ingénieur. La seule différence est que maintenant j'étais sous le choc et l'interlocuteur pensait que tout allait bien.

De nombreuses entreprises utilisent la bibliothèque Flaky , qui ajoute des annotations python aux tests non fiables qui réussissent ou échouent. J'ai demandé aux employés de trois entreprises différentes ce que fait Flaky. Tous ont suggéré qu'elle répète à plusieurs reprises le test et signale en cas d'échec. Fermer, mais pas tout à fait. Techniquement, il peut être utilisé de toute façon, mais en pratique, il redémarre à plusieurs reprises le test et signale la réussite. Flaky a été développé par une entreprise qui s'occupe de l'infrastructure de stockage de données, tandis que la bibliothèque utilise activement son plus grand concurrent. Marquer comme des tests réussis avec des bogues potentiels est tout à fait normal .

Il existe une entreprise connue pour ses bonnes pratiques d'ingénierie. Lors de ma dernière vérification, elle avait un temps de disponibilité de 99,99%, ce qui s'explique pleinement par les pratiques d'ingénierie adoptées là-bas. Si une startup ressemble à Twitter ou Reddit, alors seulement un neuf suffit, mais nous parlons d'une plate-forme d'infrastructure qui en a vraiment besoin de deux. De nombreuses entreprises qui construisent l'infrastructure pour deux neuf considèrent que leurs pratiques qui conduisent à une telle fiabilité sont tout à fait normales.

Pour autant que je sache, bon nombre de ces entreprises ont parcouru un long chemin. Au début, ils se concentraient uniquement sur la croissance des produits. C'est tout à fait raisonnable, car initialement la valeur de l'entreprise est d'environ zéro. Elle ne met pas en place une administration système compétente ou une véritable sécurité, car elle n'a rien à perdre. Eh bien, à l'exception des données utilisateur, lorsqu'elles sont inévitablement piratées, et si vous parlez aux responsables de la sécurité dans les grandes startups privées (elles sont appelées «licornes», licorne), cela se produit tout le temps.

Il en résulte une culture trop centrée sur la croissance sans risque. Cette culture est souvent préservée même lorsque l'entreprise a atteint un milliard de dollars et qu'elle a déjà quelque chose à perdre. Si une personne travaillait pour Google, Amazon ou une autre entreprise avec des procédures solides, la situation le choquera. Souvent, il essaie de réparer quelque chose, mais ne peut rien faire et démissionne.

Probablement, Google a aujourd'hui les meilleures pratiques opérationnelles et méthodes de sécurité parmi toutes les entreprises informatiques du monde. Il est facile de dire que nous devons en prendre un exemple. Mais il est instructif de voir comment ils y sont parvenus. Et ce qui s'est passé avant. Si vous regardez la base de code, vous verrez de nombreux services dont les noms se terminent par z, ainsi qu'un nombre étonnamment élevé de variables. Un des anciens employés a dit qu'il était une fois quelqu'un qui voulait ajouter une surveillance. Il n'était pas très sûr de configurer google.com/somename à surveiller. Ils ont donc ajouté z, c'est-à-dire google.com/somenamez , pour des google.com/somenamez de sécurité. C'est dans l'entreprise, qui est maintenant considérée comme la meilleure au monde en matière de sécurité.

Maintenant, elle est allée si loin dans la sécurité que les nouveaux employés nient avec véhémence de telles pratiques dans le passé. Dans le même temps, des raisons sont invoquées qui n'ont pas vraiment de sens (par exemple, pour éviter les collisions de noms).

Les énormes progrès de Google en matière de sécurité - de l'ajout de la lettre z aux meilleures pratiques du monde en matière d'IB - ne se sont pas produits parce que quelqu'un a prononcé un discours enflammé ou écrit un essai convaincant. Cela a commencé après plusieurs «fakap». Ce n'est qu'à ce moment-là que les agents de sécurité ont été autorisés à résoudre des problèmes fondamentaux. Pour les bonnes et les bonnes entreprises, les réformes commencent presque toujours de cette façon. On a ri de Microsoft pendant de nombreuses années, mais ensuite plusieurs exploits catastrophiques les ont forcés à changer leur attitude envers la sécurité. Cela semble simple. Mais des témoins oculaires disent que le changement a été cruel. Bien qu'indiquée par le haut, l'inertie est restée très forte. Pourquoi changer ce qui a fonctionné? Par conséquent, il y avait une très forte pression de la part de gens qui avaient l'habitude de tout faire à l'ancienne.

De telles choses peuvent être vues dans n'importe quelle industrie. Un exemple classique souvent cité par les techniciens est le lavage des mains par les médecins et les infirmières. Il est bien connu que les microbes existent et se laver les mains avec du savon réduit considérablement la probabilité de transmission microbienne et réduit ainsi considérablement le taux de mortalité dans les hôpitaux. Malgré cela, même les médecins et les infirmières expérimentés ne le font souvent pas. Intervention requise. Des signes rappelant le lavage des mains sauvent des vies. Et encore mieux, ces personnes vivantes se sont levées et ont exigé de se laver les mains: de cette façon, encore plus de vies sont sauvées. Les gens peuvent ignorer les panneaux, mais ils ne peuvent pas passer devant le responsable.

Quelque chose comme ça, les entreprises informatiques essaient de mettre en œuvre les meilleures pratiques. Si vous dites aux employés quoi faire, cela aide un peu. Si vous implémentez la vérification de code, l'effet est immédiatement apparent.

Les statistiques montrent clairement que les gens maîtrisent vraiment mal les habitudes de routine qui ne donnent pas d'effet visible, mais réduisent irréversiblement le risque d'événements rares mais catastrophiques. Il semble à une personne que tracer un chemin soit la bonne voie raisonnable. Il existe un terme spécial pour cela: «normalisation de la déviance». Il a été bien étudié dans un certain nombre d'autres contextes, y compris les soins de santé, l'aviation, l'ingénierie, le génie aérospatial et le génie civil, mais n'a pas encore été discuté dans le contexte logiciel.

Est-il possible d'apprendre des erreurs des autres et non des vôtres? L'état de l'industrie ne donne pas de raison de compter là-dessus, mais essayons. John Banya a rédigé un court rapport sur la normalisation de la déviance des soins de santé , dont les résultats peuvent être appliqués au développement de logiciels. On peut noter que le traitement des patients peut être comparé aux actions des devops. Cependant, la normalisation de la déviance se produit également dans un contexte culturel où l'analogie n'est pas si évidente.

La première section de l'article décrit en détail un certain nombre de situations catastrophiques, tant dans les soins de santé que dans d'autres domaines. Voici un exemple typique:

Le cas de négligence catastrophique, que l'auteur a observé en tant que témoin expert, était lié au fait que l'anesthésiste a éteint l'appareil de ventilation pulmonaire artificielle à la demande d'un chirurgien qui voulait faire une radiographie de la cavité abdominale du patient (Banya, 2005, p. 87-101). Le ventilateur était censé s'éteindre pendant seulement quelques secondes, mais l'anesthésiste a oublié de le rallumer ou a pensé qu'il s'allumait, mais ne l'a pas allumé. La patiente était sans oxygène assez longtemps pour qu'une anoxie complète commence, ce qui l'a plongée dans un état végétatif. Elle n'a jamais récupéré. Après 9 jours, elle a été déconnectée de la ventilation mécanique, et après 2 jours, elle est décédée. Il a été découvert plus tard que les alarmes d'anesthésie et l'équipement de surveillance dans la salle d'opération étaient intentionnellement programmés pour «suspendre indéfiniment» de telle manière que l'anesthésiste ne reçoive pas d'avertissement concernant un problème avec le ventilateur. L'alarme elle-même était en place, mais s'est éteinte, peut-être parce que le personnel d'exploitation a trouvé l'appareil grinçant de façon agaçante.

Désactiver ou ignorer les notifications car elles sont trop nombreuses et trop ennuyeuses? Agir manuellement avec le risque de faire une erreur? Oui, je peux nommer quelques entreprises à la fois, où le débriefing après une catastrophe commence précisément à partir de ces points, à moins qu'au final personne ne meure, et que seulement quelques millions de dollars soient perdus. Si vous lisez beaucoup d'analyses de tels incidents en informatique , alors chaque exemple de l'article de Bunny vous semblera familier, même si les détails sont différents.

La section se termine par cette conclusion :

En règle générale, ces catastrophes s'expliquent par «une longue violation des règles, des événements contradictoires qui se sont accumulés sans être détectés et une idée culturelle incorrecte des dangers. Ensemble, ces facteurs ont empêché une intervention qui aurait pu empêcher les effets nocifs. » Il est particulièrement frappant de voir comment de nombreuses violations des règles et des erreurs sont combinées pour créer des risques de catastrophe.

Encore une fois, le texte semble provenir d'un article sur les défaillances techniques. Par conséquent, la section suivante sur les causes de ces échecs mérite l'attention. Et les raisons sont les suivantes.

Des règles stupides et inefficaces

L'article fournit un exemple de l'administration de médicaments aux nouveau-nés. Pour éviter la «fuite de médicaments», l'infirmière doit saisir un mot de passe sur l'ordinateur. Elle a accès à la boîte de médicaments et prend la bonne quantité de médicaments. Pour s'assurer que la première infirmière n'a rien volé, la deuxième infirmière doit surveiller le processus. Ensuite, elle doit entrer son mot de passe dans l'ordinateur pour confirmer qu'elle a observé la bonne procédure de manipulation du médicament.

Cela semble familier. De nombreux rapports d'incidents commencent par le fait que "quelqu'un a sauté certaines étapes parce qu'elles sont inefficaces". Par exemple, "un programmeur a lancé une mauvaise configuration ou un mauvais code parce qu'il en était sûr et ne voulait pas passer de temps à tester ou à tester". La fameuse fermeture d'Azure en novembre 2014 s'est produite précisément pour cette raison.

À peu près au même moment, l'un des concurrents d'Azure, les développeurs ont annulé une règle interdisant de pousser une configuration qui échoue aux tests dans la branche Canaries. Les développeurs étaient sûrs que la configuration était en ordre. Lorsque Canary a commencé à échouer, ils ont annulé la règle interdisant le déploiement de Canary vers Staging avec une erreur. Ils étaient sûrs que la configuration était en ordre et que l'échec était dû à autre chose. Une analyse ultérieure a montré que la configuration était techniquement correcte, mais avec elle un bug s'est manifesté dans le logiciel principal. Heureusement, le bogue caché révélé par la configuration n'était pas aussi grave que le bogue Azure.

Les gens comprennent mal comment les erreurs se chevauchent. Par conséquent, nous acceptons les règles pour un déploiement sûr. Mais pour la même raison que les gens ont une mauvaise compréhension de la façon dont les erreurs se chevauchent, ces règles semblent stupides et inefficaces!

La connaissance est imparfaite et inégale

Le concept de norme n'est pas inné. Lorsque de nouvelles personnes arrivent dans l'entreprise, elles absorbent facilement les processus déviants qui sont devenus la norme.

Julia Evans m'a décrit comment cela se produit:

nouveau venu
Débutant : WTF WTF WTF WTF WTF
Vétéran : Oui, nous le savons, nous le faisons.
débutant : WTF WTF wTF wtf wtf w ...
débutant s'habitue
le deuxième débutant arrive
recrue n ° 2 : WTF WTF WTF WTF
débutant : oui, nous le savons, nous le faisons.

La chose la plus insidieuse est que les gens acceptent vraiment l'idée de WTF, puis ils peuvent la diffuser eux-mêmes à d'autres endroits de leur carrière. Une fois, j'ai travaillé avec un projet open source qui plantait régulièrement. On m'a dit que c'était normal et que leur produit était meilleur que la moyenne. J'ai vérifié et j'ai découvert qu'il était le pire de sa classe à presque tous les égards. Et il a esquissé l'idée de comment publier des builds avec relativement peu d'efforts, qui passeront presque toujours des tests. La réponse la plus courante était: «Wow, ce type doit travailler avec des programmeurs superstars. Mais nous serons réalistes. L'assemblée de chacun se brise au moins plusieurs fois par semaine. " Comme si exécuter des tests (ou même essayer de compiler) avant de vérifier le code exigeait des efforts surhumains. Mais dès que les gens croient qu'une sorte de déviation est normale, ils absorbent souvent vraiment l'idée.

Je brise la règle pour le bien du patient

L'article fournit un exemple de médecin qui enfreint la règle selon laquelle des gants doivent être portés lors de la recherche d'une veine. Il pense que le port de gants rend difficile la recherche d'une veine, il devra donc piquer plusieurs fois un enfant avec une aiguille. Il est difficile de contester cela. Personne ne veut blesser un enfant!

Le deuxième plus grand échec de tout ce que j'ai vu dans ma vie s'est produit pour cette raison. Quelqu'un a remarqué un ralentissement de la base de données. Ils ont rapidement écrit un correctif et pour empêcher la dégradation de se propager davantage, ils ont ignoré la règle d'un déploiement lent et progressif. Au lieu de cela, ils ont déployé le patch sur toutes les machines. Il est difficile de contester cela. Personne ne veut que les clients subissent une dégradation du service! Malheureusement, le correctif a détecté une erreur qui a provoqué un arrêt global du service.

Les règles ne s'appliquent pas à moi / vous pouvez me faire confiance

La plupart des gens se perçoivent comme bons et décents, ils peuvent donc considérer leur violation des règles comme une réponse tout à fait rationnelle et éthiquement acceptable aux situations problématiques. Ils sont sûrs de ne rien faire de mal et seront indignés et se défendront souvent farouchement s'ils sont confrontés à des preuves du contraire.

À mesure que l'entreprise grandit, il est nécessaire d'introduire un système de sécurité qui ne permet pas à chaque employé d'avoir accès à presque tout. Et lorsque cela se produit, dans la plupart des entreprises, certains employés sont vraiment contrariés: «Vous ne me faites pas confiance? Si vous faites confiance, alors pourquoi refusez-vous l'accès à X, Y et Z? »

Il est connu que Facebook offre depuis longtemps aux employés l'accès au profil de tout utilisateur. Certains recruteurs ont même mentionné cela comme un avantage de travailler sur Facebook. Et je connais plus d'une startup respectée, où, comme auparavant, chaque employé a accès à presque toutes les informations, même après une ou deux fuites d'informations. Une certaine volonté politique est nécessaire pour limiter l'accès des personnes à ce qu'elles considèrent comme nécessaire ou habituel par la loi. De nombreuses startups à la mode ont déclaré les valeurs fondamentales de «confiance» et de «transparence», ce qui rend difficile la justification des restrictions d'accès.

Les travailleurs ont peur de performer

Je ne veux pas exprimer mon opinion à certaines personnes, car elles peuvent le rencontrer avec hostilité et ne peuvent pas rendre les mots prononcés. Dans l'article scientifique mentionné, l'auteur donne un exemple de médecin avec une mauvaise écriture. Il se met en colère quand quelqu'un demande de clarifier ce qu'il a écrit. En conséquence, les gens se demandent, ne demandent pas.

La plupart des entreprises ont développé une culture où le feedback est difficile. De nombreux projets ont été retardés de plusieurs mois, puis arrêtés, car chaque collaborateur avait peur d'exprimer son opinion dès le départ, par peur des critiques. Le problème est présent même dans les cultures qui encouragent la politesse: il est également difficile d'y exprimer des critiques sincères. Il s'avère que dans certaines entreprises, les gens ont peur de parler, car ils sont attaqués par quelqu'un de mal. Dans d'autres, ils ont peur de parler, car ils sont eux-mêmes considérés comme mauvais. Problème difficile.

Problème de masquage manuel

Un article scientifique explique comment les informations sur un problème sont éliminées lors de leur remontée dans la chaîne. Un exemple est la façon dont un manager prend des mesures non optimales afin de ne pas mal paraître devant ses supérieurs.

J'ai été choqué quand j'ai vu cela pour la première fois. Les gens comprennent qu'ils font clairement quelque chose de mal. Mais si vous optimisez, il y a une probabilité d'échec non nulle, et ce sera très embarrassant. Par conséquent, il est plus facile de le laisser tel quel. Avec des années d'expérience professionnelle, je comprends mieux comment et pourquoi les gens jouent à ce jeu, mais je le trouve toujours absurde.

Des solutions

Supposons que votre entreprise ait un problème typique: les gens sont récompensés pour leur héroïsme dans l'extinction des incendies, et non pour les prévenir. Et les gens sont promus pour avoir publié de nouvelles fonctionnalités, pas pour faire de la maintenance critique et des corrections de bugs. Comment changer ça?

L'option la plus simple consiste à faire la bonne chose par vous-même et à ignorer ce qui se passe autour de vous. Vous apporterez certains avantages, mais l'étendue de votre influence est limitée. Ensuite, vous pouvez convaincre votre équipe de faire la bonne chose: je l'ai fait plusieurs fois pour mettre en œuvre des pratiques qui me semblent vraiment importantes.

Mais si des incitations sont dirigées contre vous, il faudra des efforts constants et irréguliers pour amener les gens à faire la bonne chose. Dans ce cas, le problème est de persuader quelqu'un de modifier les incitations, puis de s'assurer que les changements fonctionnent comme prévu. Comment convaincre la direction de changer les incitations est le sujet d'un article séparé. Concernant la mise en œuvre des changements, j'ai vu beaucoup d'erreurs «évidentes» qui se répètent dans différentes entreprises.

Les petites entreprises trouvent cela facile. Lorsque je travaillais pour une entreprise de cent personnes, il y avait une hiérarchie simple: participant individuel (IC) -> chef d'équipe (TL) -> directeur général (PDG). C’est tout. Le directeur n'est pas intervenu particulièrement, mais s'il a dit quelque chose, il a été implicitement exécuté. Il est important qu'il sache ce que fait chaque employé et qu'il puisse généralement réguler la rémunération en temps réel. Si vous avez fait quelque chose de bien pour l'entreprise, vous pouvez vous attendre à une augmentation. Pas neuf mois plus tard, lorsque le prochain cycle d'analyse de l'efficacité du personnel est apparu, mais presque immédiatement. Pas pour toutes les petites entreprises, cela fonctionne efficacement, mais avec le bon leadership, cela est possible. Dans les grandes entreprises, rien.

Une grande entreprise a eu un tel problème. La direction a ordonné de récompenser les employés pour avoir effectué un travail critique mais discret. Il y avait trop d'employés pour distribuer immédiatement les bonus, mais le responsable pouvait analyser les rapports, prendre des décisions sur les contrôles ponctuels et donner des bonus, de sorte qu'au fil du temps, les bonnes incitations feront partie de la culture. À mon avis, l'entreprise n'a pas atteint la parité entre les travaux d'entretien ennuyeux et les nouveaux projets brillants. Mais les gens ont au moins commencé à travailler sur les infrastructures et à corriger les bugs sans trop endommager leur carrière.

Dans une autre grande entreprise, les employés de base ont convenu qu'il était mal de récompenser plus généreusement pour la création de nouvelles fonctions que pour un travail critique. Lorsque je parlais avec des managers, ils étaient souvent d'accord. Néanmoins, l'augmentation a été reçue principalement par les développeurs de nouvelles choses brillantes. La direction a tenté un changement culturel et technologique. Fondamentalement, sous la forme de déclarations inspirantes de personnes ayant des postes de fantaisie. Pour des choses vraiment importantes, vous avez dû regarder la vidéo et passer le test requis avec plusieurs options de réponse après avoir regardé la vidéo. Le seul résultat de cette campagne a été l'opinion générale selon laquelle la direction est très éloignée de la vie des employés ordinaires.

C'est un peu drôle qu'en fin de compte, tout se résume au problème des incitations. Dans l'industrie, nous réfléchissons beaucoup à la manière d'encourager les consommateurs à faire ce que nous voulons. Mais au sein de l'entreprise, nous créons un système d'incitations qui nous pousse aux mauvaises choses. Une sorte de mélange de téléphone gâté et de culte du cargo. Autrefois, Microsoft était un modèle - nous avons copié leurs méthodes et posé des puzzles d'entrevue. Maintenant, Google est devenu un modèle - et nous posons des questions sur les algorithmes. Si vous regardez les entreprises de mode plus jeunes que Google, la plupart d'entre elles copient essentiellement le système de publication Google, avec quelques modifications mineures. La bonne nouvelle est que Google a bien pensé la plupart de ses processus et que les décisions sont prises en fonction des données. La mauvaise nouvelle est que Google est à bien des égards une entreprise unique. Leurs pratiques ne fonctionnent souvent pas pour le reste, donc les gens pratiquent simplement le culte du fret. Et pendant longtemps après que Google a déjà abandonné cette pratique .

Une telle diffusion se produit également dans les solutions techniques. Stripe a construit une file d'attente de messages robuste au-dessus de Mongo , nous allons donc également créer des files d' attente de messages robustes au-dessus de Mongo ¹ .Le culte du cargo descend la chaîne ² .

L'article médical comporte des sections spéciales sur la façon de prévenir la normalisation de la déviance.

• Faites attention aux signaux faibles.
  
• Résistez au désir d'être indûment optimiste.
  
• Enseignez aux employés comment mener des conversations émotionnellement inconfortables.
  
• Les opérateurs de système doivent se sentir en sécurité lorsqu'ils expriment une opinion.
  
• Sachez que la surveillance et le suivi ne s'arrêtent jamais.

Voyons comment fonctionne le premier principe lorsqu'un nouveau venu arrive dans l'entreprise et commence à crier «WTF WTF WTF».

Lorsqu'un vice-président exprime son opinion, les gens l'écoutent généralement. C'est un signal fort. Sinon, le vice-président sait toujours comment mettre en œuvre sa décision. Le débutant ne sait pas quel levier tirer, avec qui parler. Ils produisent des signaux faibles faciles à ignorer. Au moment où il a suffisamment étudié le système pour émettre des signaux forts, il est déjà en train de s'acclimater.

«Faites attention aux signaux faibles» sonne bien, mais comment faire? Les signaux forts sont rares et rares, il est donc facile de faire attention. Il y a trop de signaux faibles. Comment filtrer le bruit? Et comment faire en sorte que l'ensemble de l'équipe ou de l'organisation le fasse? Il n'y a pas de réponse simple à de telles questions, il faut y prêter une attention considérable.

Malheureusement, les entreprises le font rarement. Les startups pensent beaucoup à la croissance. Bien que tout le monde se dit très préoccupé par la culture d'ingénierie, en pratique, ce n'est pas le cas. À quelques exceptions près, les grandes entreprises ne sont pas très différentes. Dans l'une de ces entreprises, j'ai vu des diapositives d'analyse concurrentielle, et elles sont incroyables. Les plus petits détails sont étudiés dans des centaines de produits pour garantir que les utilisateurs recevront une qualité parfaite à tous égards, de la mise en œuvre à l'interaction avec des produits concurrents. Si même un paramètre est plus compliqué ou déroutant que celui de n'importe quel concurrent, les gens se fâchent et essaient de régler la situation. C'est très impressionnant.

Ensuite, l'entreprise accepte de nouveaux employés, et chaque tiers n'a ni compte dans le système, ni place au bureau, ni ordinateur - et cette condition peut persister pendant des semaines ou des mois. Les diapositives d'analyse concurrentielle indiquent que vous n'avez qu'une seule chance de faire une première impression, puis les employés ont l'impression que l'entreprise n'est pas en mesure de prendre soin d'eux. Et que perturber constamment les processus de travail est normal.

L'entreprise ne peut même pas comprendre les bases de l'intégration, sans parler de choses vraiment complexes comme l'acculturation. Les raisons sont claires. Les indicateurs externes, tels que la croissance ou la diminution de l'audience, sont mesurables, contrairement à l'acculturation des nouveaux arrivants, afin qu'ils n'ignorent pas les signaux faibles. Mais cela ne signifie pas que ce dernier est moins important. Beaucoup disent comment de nouveaux langages ou méthodes, tels que TDD ou Agile, augmentent la productivité, mais avoir une forte culture d'ingénierie est un animateur beaucoup plus puissant.

---

1. Les gens semblent penser que je plaisante. Et essayez de le google mongodb message queue. Vous trouverez des instructions comme «les jeux de répliques dans MongoDB fournissent très bien la redondance et le basculement automatique». Presque toutes les entreprises que je connais qui l'ont essayé à grande échelle ont trouvé le système sous-optimal, c'est le moins qu'on puisse dire. Mais vous n'y trouverez rien. Seuls les articles et présentations d'entreprises qui ont essayé et fasciné par ce SGBD. Ceci est commun à de nombreuses technologies. Il y a des recommandations brillantes en public et en privé, les gens vous parleront de tous les problèmes. Si vous exécutez une telle requête de recherche aujourd'hui, vous trouverez une tonne d'articles admiratifs sur la façon dont il est cool de créer une file d'attente de messages au-dessus de Mongo, vous trouverez cet article et peut-être plusieurs articles sur le blog de Kyle Kingsbury, selon l'expression de recherche spécifique.[]

En cas de dysfonctionnement grave, vous verrez un débriefing avec une description technique. Mais nous aimons faire cette analyse pour les accidents comme «Le site a été fermé pendant 30 secondes», mais rarement nous analysons des situations comme «Cela prend 10 fois plus d'efforts que l'alternative, et c'est la mort de mille coupures» ou «Nous avons mal conçu le système, et maintenant, il est très difficile de faire des changements qui devraient être insignifiants "ou" Notre concurrent a pu faire de même, dépensant un ordre de grandeur moins d'efforts ". Je mène parfois un débriefing informel, posant toutes les questions impliquées aux personnes impliquées, mais c'est plus pour moi, car je ne suis pas sûr que les gens veulent vraiment entendre la vérité. Surtout si plusieurs employés ont reçu une promotion pour le développement de ce projet. Il semble que plus le projet est endommagé, plus il est attribué. Plus le projet est grand,plus il est visible et plus il y a de bonus, même si cela peut être fait avec beaucoup moins d'efforts.

2. J'ai souvent posé cette question dans des entreprises prospères, et dans d'autres, où tout va mal. Là où tout va mal, tout le monde a des idées. Mais là où tout va bien, personne ne sait pourquoi tout fonctionne, comme dans la petite entreprise précitée avec un directeur qui n'intervient pas particulièrement en la matière. Incroyable Les gens disent littéralement que tout ressemble à une autre entreprise où ils travaillaient, sauf que tout était mauvais là-bas, mais ici, c'est magiquement bon. Pour des raisons qu'ils ne comprennent pas. Mais ce n'est pas magique. C'est un travail difficile que peu connaissent. Plusieurs fois, j'ai vu le vice-président partir et il devient désagréable pour l'entreprise de travailler. Peu à peu, il s'agit de personnes: le vice-président s'est assuré que tous les employés étaient satisfaits de leur lieu de travail. C'est difficile à comprendre tant que la situation ne va pas mal. Si vous ne voyez rien de mal,soit vous n'y prêtez pas attention, soit quelqu'un a fait beaucoup d'efforts pour que tout se passe bien.[]