Beaucoup de gens pensent à leurs problèmes préoccupants avant de s'endormir ou au réveil. Je ne fais pas exception. Ce matin, une idée m'est venue à l'esprit. de Habr :
Un collègue dans le chat a partagé une histoire :
J'ai eu un client incroyable il y a deux ans, c'était encore au moment où je prenais des « crises » pures.
Le client avait deux équipes dans son groupe de développement, chacune s'occupant de sa partie du produit (en gros, le back-office et le front-office, c'est-à-dire le logiciel qui s'occupe de la création de commandes et celui qui gère l'exécution des commandes), s'intégrant occasionnellement.
L'équipe du back-office était complètement au fond du trou : six mois de problèmes en série, les propriétaires menacent de tout licencier, ils ont engagé un consultant, puis un autre (moi). D'ailleurs, la deuxième équipe (front-office) travaillait bien et continuait à bien travailler, c'est vraiment l'équipe du back-office, qui jusqu'alors fonctionnait bien, qui a commencé à faire des erreurs. Les équipes sont dans différents bureaux et ont pris l'habitude de se détester.La raison : le front et le back font partie d'un même système, il y a plein de dépendances, les équipes dans différents bureaux ne communiquaient pas. Les propriétaires surveillent constamment le front-office, d'où viennent de nouvelles fonctionnalités, idées et contrôles. Il y avait un homme à tout faire, un mélange de BA, designer et « apporte-nous du café ». Cet homme, sans que son équipe ne s'en aperçoive, exécutait plein de petites tâches comme « prévenir la seconde équipe du déploiement », « mettre à jour la documentation », etc., allant jusqu'à « ajouter dans Jira toutes sortes de numéros de versions et de composants ». Mais il n’écrivait pas de code et, à un moment, les propriétaires ont décidé de l'optimiser en le licenciant. Pour l'équipe du front, rien n'a changé, ils avaient simplement cessé de soumettre et de mettre à jour la documentation, tandis que l'équipe du back-office s'est retrouvée dans une situation où les déploiements du front cassaient quelque chose chez eux, et c'était leur problème, et si leurs déploiements cassaient quelque chose chez le front, c'était encore leur problème, car le front était sous l'œil des propriétaires 🙂
Ce qui m'a frappé dans ce commentaire et ce que cherchera le chercheur du titre — dans les détails.
Je développe des applications web depuis environ 20 ans, donc pour moi, le front-end et le back-end ne sont pas simplement des mots. Ce sont deux éléments très liés. Par exemple, je ne peux pas imaginer une situation où le front est développé complètement (ou dans une très grande mesure) indépendamment du back. Des données identiques sont utilisées des deux côtés, et des opérations très similaires sont effectuées. J'ai une idée approximative du volume d'informations échangées entre les développeurs des deux équipes pour synchroniser le développement, ainsi que du temps et de la fréquence avec lesquels cela doit être fait. Les équipes doivent maintenir une communication étroite, même si elles se trouvent dans des fuseaux horaires différents. Surtout avec l'utilisation de JIRA.
Je sais qu'il est inutile de prévenir les développeurs back-end d'un déploiement du front. La nouvelle version du front ne peut rien casser côté back, mais l'inverse est possible. Les développeurs du front sont ceux qui ont intérêt à notifier les développeurs du back qu'ils ont besoin de nouvelles fonctionnalités ou de modifications. Le front dépend des déploiements du back, et non l'inverse.
Ce garçon qui "apporte-nous du café", ne peut pas être BA (si par BA on entend "analyste business"), et un BA ne peut pas être "le garçon, apporte-nous du café". Et certainement, "ajouter toutes sortes de numéros de version et de composants dans la JIRA" sans en discuter avec les équipes de développement, ni "le garçon", ni le BA ne peuvent le faire. C'est comme une charrette devant un cheval.
Puisque "le garçon" a été licencié, ces fonctions, de "apporte du café" à "ajoute dans la JIRA", auraient dû être redistribuées entre les autres membres des équipes. Dans un groupe bien établi, les flux d'informations et les rôles sont assignés, et si l'exécutant d'un ou plusieurs rôles quitte la scène, les autres membres du groupe ressentent toujours le besoin de recevoir les informations familières de ces rôles familiers. Ils ne peuvent tout simplement pas ne pas remarquer que les informations nécessaires à leur travail cessent d'arriver. C'est comme un toxicomane qui ne peut pas ne pas remarquer l'absence de drogue. Et tout comme un toxicomane cherche et trouve d'autres canaux, les membres du groupe vont essayer de trouver des sources de l'information dont ils ont besoin de l'autre côté et de nouveaux exécutants des anciens rôles. Et ils vont sûrement trouver. Au minimum, celui qu'ils croient devoir leur fournir l'information nécessaire.
Même si l'on suppose que les canaux d'information habituels ont été interrompus, et que celui qui devrait agir ne le fait pas, les développeurs du backend sous la menace de licenciement ne cacheront pas pendant six mois les raisons de leurs propres échecs au propriétaire, sachant que leurs erreurs proviennent de l'absence des informations nécessaires. Les propriétaires ne resteront pas inactifs pendant six mois en voyant que les informations cruciales n'étaient plus disponibles.était dans le gras", mais maintenant personne ne les y insère. Et le premier consultant n'était probablement pas si peu professionnel qu'il n'ait pas discuté avec les développeurs backend et n'ait pas identifié la source du problème — le manque de coordination entre les équipes. C'est précisément la cause des malheurs décrits, et non le licenciement du "garçon".
L'absence banale de communication entre les développeurs est une cause typique de nombreux problèmes dans le développement et au-delà. Il n'est pas nécessaire d'être un consultant exceptionnel pour la découvrir. Il suffit d'être simplement raisonnable.
Je pense que toute cette histoire est inventée et bien racontée. Eh bien, pas entièrement inventée — tous les éléments sont tirés de la vie (front, back, développement, garçon, café, "gras", …). Mais ils sont assemblés de telle manière qu'une telle construction ne se rencontre pas dans la vie. Chacun de ces éléments peut être croisé dans le monde qui nous entoure, mais dans une telle combinaison — non. J'ai déjà expliqué pourquoi.
Néanmoins, cela est présenté de manière très crédible. Ça se lit avec intérêt et une implication personnelle est présente. De la sympathie pour le "garçon à tout faire", un petit mécanisme sous-estimé d'une grande machine (c'est de moi qu'il s'agit !). De la condescendance envers les développeurs, si intelligents et expérimentés, mais ne voyant pas plus loin que leur nez (ils sont tous autour de moi !). Un léger sarcasme à l'égard des propriétaires, ces riches petits messieurs, qui se sont fait du "bobo" avec leurs propres mains sans comprendre les raisons (c'est exactement ma direction !). Du mépris pour le premier "consultant", qui n'a pas réussi à trouver une source de problèmes aussi simple (oui, récemment, il y en avait un avec des lunettes, qui se pavanait avec un air intelligent), et une admiration enthousiaste envers le "vrai" consultant, qui a été le seul à reconnaître le véritable rôle du garçon à tout faire (c'est-à-dire moi !).).
Ressentez-vous une satisfaction intérieure après avoir lu ce commentaire ? Notre rôle de petites pièces dans un grand mécanisme n'est en réalité pas si petit ! C'est magnifiquement exprimé, même si ce n'est pas vrai. Mais quelle agréable après-goût.
Je ne sais pas qui est ce collègue et dans quel chat il a partagé cette révélation avec un autre collègue. et pourquoi ce collègue mkrentovskiy a décidé de le publier sous l'article "" de cet auteur exceptionnel de Habr. ‘a (qui est d'ailleurs actuellement en première position dans le classement de Habr !), mais je reconnais que ce collègue mkrentovskiy a fait cela de manière particulièrement réussie. Le message du commentaire et le style de rédaction correspondent tellement au message et au style des autres publications nmivan‘a, qu'on pourrait penser que le consultant en crise du commentaire et le héros de nombreuses publications nmivan‘a sont une seule et même personne.
J'ai lu pas mal de publications d'Ivan Belokamencev, depuis que l'auteur a commencé son activité sur Habr (en 2017). Certaines même avec plaisir (, ). Il a un bon style et une présentation intéressante du matériel. Ses histoires ressemblent beaucoup à des histoires de la vie réelle, mais ont pratiquement zéro chance de se produire réellement, dans . C'est comme avec cette histoire dans le commentaire.
Pour être honnête, je ne pense pas personnellement qu'avec les publications d'Ivan, Habr est devenu meilleur. Mais son classement et des autres habitants de Habr parlent dans le sens inverse :
Je ne comprends pas votre plainte. Habr est déjà en déclin depuis longtemps, et l'auteur apporte un peu d'enthousiasme et remonte le moral des lecteurs en tirant la ressource du gouffre.
Oui, Habr n'est pas une œuvre de charité, Habr est un projet commercial. Habr est un miroir qui reflète nos désirs. Pas mes désirs personnels ni ceux de chaque visiteur, mais l'agrégation de tous nos désirs - "la moyenne à l'hôpital". Et Ivan Belokamencev sent mieux que quiconque ce dont nous avons tous besoin dans l'ensemble, et nous le donne.
Peut-être que je n'aurais pas écrit cet article si je n'avais pas commencé à regarder la série "".
"Nous avons perdu Dieu" (c)
C'est tiré de la série. Et c'est à propos de nous.
Nous ne sommes plus fascinés par la réalité créée par le Créateur.
Dieu, la Nature, le Big Bang - comme vous voulez. La réalité est là. Autour de nous et indépendamment de nous.
Nous vivons en accord avec les lois de la nature (la volonté divine). Nous maîtrisons ces lois (la volonté) et apprenons à utiliser la réalité dans laquelle nous vivons pour l'améliorer. Nous mettons nos hypothèses à l'épreuve, écartant les fausses et conservant celles qui sont pertinentes. Nous interagissons avec la réalité et la changeons.
Et nous avons réussi de manière significative dans ce domaine.
Il y a beaucoup d'êtres humains sur la planète. Vraiment beaucoup. Avec la productivité actuelle du travail, nous n'avons plus besoin de survivre — une minorité peut fournir à la majorité tout ce dont elle a besoin. La majorité doit donc se divertir. Historiquement, le surplus de ressources alloué à la créativité était attribué aux plus talentueux (ou aux plus persévérants, ce qui également représente un talent). Actuellement, il y a tellement de ressources disponibles que même ceux qui ont un certain talent, peu importe leur niveau, peuvent en bénéficier. Comparez le nombre de films produits chaque année dans le monde et le nombre qui peuvent être regardés. Combien de livres sont écrits, et combien d'entre eux sont lisibles. Quelle quantité d'informations est déversée sur Internet, et laquelle est utile.
Pourquoi la profession d'informaticien est-elle si populaire ? Parce qu'en informatique, on peut dépenser une infinité de ressources et personne ne cligne des yeux (rappellez-vous du problème de l'an 2000). En effet, en informatique, on peut passer des années à développer des applications qui seront obsolètes même avant leur lancement, on peut tenter d'intégrer des composants incompatibles et finalement les faire fonctionner, on peut réinventer la roue à maintes reprises, ou bien on peut se consacrer tout de suite au support des programmes en Fortran, qui sont tombés en désuétude il y a 20 ans. Il est possible de passer toute sa vie dans l'informatique sans rien faire d'utile. Et surtout — personne ne s'en apercevra ! Même vous-même.
Peu d'entre nous réussiront à laisser une trace dans l'industrie informatique. Et encore moins de personnes réussiront à laisser un bon souvenir. Les résultats de notre travail seront dévalués dans les 10 à 20 prochaines années au mieux, voire plus tôt. Et certainement de notre vivant (si nous atteignons l'âge de la retraite). Nous ne pourrons pas montrer à nos petits-enfants les systèmes informatiques sur lesquels leur grand-père a travaillé dans sa jeunesse. Les gens oublieront simplement leurs noms. Au début de ma carrière, j'ai travaillé avec des stations de messagerie. sous ""J'ai encore 20 ans avant la retraite et 10 ans avant d'avoir des petits-enfants, mais déjà maintenant, la plupart d'entre vous n'ont rien entendu parler de "l'application de messagerie exceptionnelle des années 90" ("meilleur logiciel de messagerie du milieu des années 1990").
Peut-être que nous réalisons mal la futilité de notre fardeau informatique, mais au fond de nous, nous cherchons à fuir vers un endroit où nous nous sentons à l'aise. Dans des mondes imaginaires, où l'utilisation de Scrum et d'Agile conduit inévitablement à la création de produits qui, pendant des décennies, conquièrent le monde par leur utilité. Où nous ne sommes pas de simples petites rouages de grands mécanismes, mais des rouages sans lesquels les grands mécanismes se brisent. Où notre vie ne se déroule pas dans l'exécution sans signification de tâches routinières, mais est remplie de créativité et de construction, des résultats dont nous pouvons être fiers.
Nous fuyons vers ces magnifiques mondes imaginés par quelqu'un pour échapper à notre propre inutilité dans le monde réel. Nous y cherchons du réconfort.
Nous cherchons du réconfort également sur Habré. Et Ivan nous en donne ici.
Source : habr.com
