La beauté qui n'a pas sauvé le programmeur

«Pour ce que vous avez été accepté, pour ce que vous serez viré», dit la vieille sagesse. J'ai été appelé dans cette usine pour auditer la comptabilité, le système d'information, le code, les processus, etc. Mais ils ont commencé par dire qu'ils avaient un mauvais programmeur. Standard, usine, terrible.



L'usine a créé de beaux produits. Et lui-même était beau. Vraiment beau - apparemment, les mêmes designers qui dessinent les produits ont participé à la conception du bâtiment. Il y a aussi beauté et harmonie dans les ateliers. Propreté, ordre, tout à sa place. Et surtout, l'ensemble du processus de production est magnifiquement automatisé.



Chaque lot de produits est accompagné d'une feuille de route, qui contient toutes les opérations technologiques nécessaires, que trouver où, où l'envoyer, etc. Sur une feuille de papier - uniquement des codes-barres, avec un minimum de texte.



Le travailleur prend simplement un lot de pièces, prélève avec un scanner - et le système sait immédiatement qu'il a commencé le traitement. Beaucoup de petite taille, pas plus d'un quart de travail est traité, il n'est donc pas nécessaire de le diviser en reflétant le fait de la libération ou le passage de l'opération. Le travailleur, une fois qu'il a fini de traiter le lot entier, effectue simplement un prélèvement avec un scanner, et le système sait que le lot est prêt et peut passer à la personne suivante. Le système sait également que les pièces sont coincées entre les traitements - il y a un pic à la fin, mais il n'y a pas de pic au début de l'opération suivante.



Beauté et harmonie. Le rêve de tout leader. Transparence totale - vous savez toujours quoi, où, quand. Par conséquent, le chef mène l'excursion dans une telle humeur. Il aime la façon dont les choses fonctionnent. Belle automatisation.



J'entrevois que les travailleurs parlent beaucoup de façon suspecte au téléphone. Lorsque nous nous approchons de quelqu'un, que nous nous levons et que nous regardons une belle machine ou le travail agile de nos mains, la personne sourit et travaille. Dès que nous partons, il commence à appeler quelqu'un.



Eh bien, on ne sait jamais, peut-être qu'ils sont sociables ici. Ou est-ce que la culture d'entreprise est comme celle-ci - vous pouvez l'essayer toute la journée. Je n'ai pas le temps - j'ai besoin de savoir où se trouve le squelette dans le placard. Dans tous les cas, après tout, le service comptable se trouve quelque part et conduit une quantité folle de documents résolvant les problèmes, les opérations techniques et le mouvement des produits semi-finis.



Nous allons au service comptable - non, c'est calme là-bas. Ils s'assoient et boivent du thé. Sur les écrans d'ordinateur - oui, bien sûr, le système d'information - mais certainement pas sur l'entrée des problèmes. Travail comptable régulier. Passez.



Probablement un blocage dans le service de planification et d'expédition (PDO). Nous allons là-bas. Eh bien, pas qu'un blocage - juste beaucoup de travail. Le responsable dit honnêtement que le goulot d'étranglement du moment est l'impression d'un grand nombre de feuilles de route - pour chaque lot et commande. Compte tenu de leur petite taille, beaucoup de papier est obtenu - en fait, cela prend la plupart du temps du personnel de l'AOP.



Alors, où est le squelette? Ça ne peut pas être si bon. Bon, quittons le manager, je vais parler au programmeur. Il sait avec certitude.



Le programmeur est assis dans un placard exigu, parlant au téléphone, tout en faisant frénétiquement quelque chose dans le système. J'attends quelques minutes jusqu'à ce que j'aie compris, que j'arrive à me connaître rapidement - et encore une fois le téléphone du programmeur sonne. J'attends encore. Dans la pause suivante, j'insère la question "Puis-je voir comment votre système fonctionne?" - et encore l'appel. En même temps, des messageries instantanées de toutes les couleurs connues - vert, bleu, violet - clignotent sur l'ordinateur du programmeur.



Le programmeur, continuant à parler, m'ouvre le système et les sources sur un ordinateur à proximité. Il recule, ouvre des discussions, regarde des images, enfonce rapidement quelque chose dans le système.



N'ayant rien à faire, je regarde le système. Je génère des rapports - sur les ventes, la production, les coûts, les prix, etc. Tous les rapports sont beaux comme un. Le minimum de paramètres disponibles - seulement de beaux commutateurs, tels que par région, groupe de produits, etc. Vous cliquez et profitez de la vue magnifique - tout est soigné, léché, peigné.



Cela n'est généralement pas fait dans les systèmes d'entreprise, pour un usage interne. Là, l'approche est technologiquement avancée - il y a une certaine forme universelle, et seulement la demande qui extrait les changements de données d'un rapport à l'autre. Ensuite, le moteur les fait tourner selon les besoins, donne les paramètres utilisateur - regroupements, filtres, tri, coloration, etc. Comme dans les systèmes de BI, mais plus simple, sans cubes et autres beautés. Étrange, vous devez regarder le code.



Je regarde le code - mes pieds sont dans ma bouche ... 4-5 mille lignes de code pour générer un rapport de version. À titre de comparaison - généralement 50-100 lignes suffisent, et toutes sont le texte de la demande, le reste est fourni par la plate-forme. C'est étrange, que fait-il ici, dans ces 4 à 5 000 lignes?



Je regarde les noms des procédures et des fonctions - encore une fois une sorte de folie. Ils sont lisibles par l'homme, et déjà par les noms c'est clair - lui, bon sang, a sa propre procédure pour chaque unité. L'un affiche les données de l'atelier 1, le second de l'atelier 2, etc.



Non, d'accord, cela arrive - la déclaration de bénéfices sera pire. Je déplie les textes, je regarde. Combien de différences voyons-nous? Un - le paramètre de demande change. Au lieu du magasin 1 - magasin 2.

Partager quelques modules supplémentaires - les mêmes déchets. Des kilotonnes de code qui dessinent de beaux rapports. Bien que, maintenant, les rapports ne semblent plus si beaux. J'ai hâte de déjeuner. Le déjeuner est sacré.



Et voici. À exactement 12h00, le programmeur met fin à la conversation, jette le téléphone sous le moniteur, se lève et sort du bureau. Je le suis. Heureusement, il est tellement en colère qu'il est prêt à parler.



Eh bien, il s'est avéré. J'ai travaillé comme programmeur dans une usine, je n'ai touché personne. Lentement, il a aidé les utilisateurs, ajouté quelque chose, entretenu le système et les serveurs, rechargé les cartouches. Normalement.



Mais ensuite, le chef de l'entreprise est parti en voyage d'affaires à l'étranger - il a vu comment les gens vivent. Et les gens à l'étranger vivent à merveille.



Et il a apporté l'idée d'une belle automatisation. J'ai demandé au programmeur, il a répondu - une sorte de non-sens. Faible. Le chef a trouvé des entrepreneurs, ils s'intègrent - pourquoi ne pas s'intégrer, alors? Les principales exigences fonctionnelles sont que tout le monde dans les magasins doit choisir des scanners et ne pas travailler avec un ordinateur avec ses mains, et les données sur les versions, les opérations et les mouvements apparaissent instantanément, après la mise en œuvre d'événements réels.



À peine dit que c'était fait. Plusieurs mois de tourments, et les ateliers étaient remplis de pics magiques de scanners de codes-barres, comme un véritable hypermarché. Le directeur a été appelé à remettre le travail pour voir personnellement la beauté de l'automatisation. Ils ont apporté une grande télévision, ont sorti une pancarte montrant la vie de l'atelier en temps réel.



Nous l'avons passé avec un bang. Le travailleur ramassait avec un scanner - le résultat était immédiatement affiché sur le téléviseur. Le deuxième pic, le troisième, le dixième - la vie a commencé à bouillir, à la fois dans le magasin et à la télévision. Le directeur était content. J'ai signé les actes, les entrepreneurs sont partis.



Et le programmeur est resté. Il a essayé de dire au directeur que ce qui était fait était, pour le moins, pas ce qu'il fallait. Le fait qu'une simple table plate à laquelle les lectures de codes à barres sont ajoutées séquentiellement ne reflète pas le problème. Il ne s'agit que d'un travail de laboratoire sur la connexion de scanners en mode clavier - lecture de données, écriture sur une table, décryptage d'un code barre - c'était long, composite, avec des numéros de commande, de lot, d'opération technique, de nomenclature, etc. cousus à l'intérieur.



Mais le chef n'a pas voulu écouter ces absurdités. C'était beau dans l'atelier. Vous ne savez jamais ce que porte ce nerd du village. Gauche sans recul, probablement - et lui sert bien.



Eh bien, alors l'enfer a commencé, pour le programmeur. Il a travaillé sans relâche pendant plusieurs jours pour assurer au moins un certain fonctionnement du système. Jugez par vous-même: plus tôt, bien que par un seul endroit, avec un retard, mais les données de publication sont arrivées là où elles sont nécessaires. Il y avait des morceaux de papier standard avec des numéros de version, qui ont été traînés de l'atelier au service comptable ou PDO, et ces numéros ont été introduits dans le système, le roulement interne a fonctionné, les soldes étaient corrects, le coût a été pris en compte.



Désormais, il n'y a qu'une table plate avec des codes-barres scannés et décodés. Eh bien, le mécanisme à cheval pour la formation et l'impression de ces codes-barres à partir de plans de production. Les données de sortie n'allaient tout simplement pas aux parties du système où elles étaient nécessaires - ni dans la gestion, ni dans le chiffre d'affaires comptable. Une table plate se tenait à proximité et accumulait simplement les données de numérisation de codes à barres.



Dans un premier temps, le programmeur, sous la pression du service comptable, a imprimé sur son genou l'empreinte de cette table très plate - à peu près sous la forme de ce à quoi ressemblaient les papiers manuscrits de la boutique. J'ai imprimé ce tableau pour eux une fois par jour, des bukhs étaient introduits dans le système.



Ensuite, avec un chagrin de moitié, j'ai écrit du code qui transférait les données de la table plate vers les informations d'identification système normales. Et il semblait possible de se calmer, mais ce n'était pas là. Le directeur s'est de nouveau rendu dans une entreprise et a appris que de beaux rapports peuvent être reçus du système.



Auparavant, comme dans la plupart des usines, les rapports destinés au directeur étaient préparés par des personnes spéciales - comptables, économistes, financiers, etc. Ils ont pris des données du système et les ont présentées sous une forme concise, compréhensible et belle. Désormais, le responsable voulait recevoir des rapports directement du système.



Le deuxième cercle de l'enfer a commencé. Les délais, bien sûr, étaient extrêmement serrés - le programmeur était déjà considéré comme un gadget sabotant les progrès, et personne ne le laisserait se détendre. C'est ainsi qu'apparaissent des kilotonnes de code copier-coller, écrit à la hâte et sur le genou. Et des dizaines de beaux rapports.



Le troisième cercle de l'enfer est venu de là où personne ne s'attendait - d'une table plate avec des codes-barres. Cela avait l'air bien comme stand de démonstration, mais dans le travail réel, toutes les erreurs de conception ont été très rapidement résolues, à la fois en termes de technologie et de processus d'utilisation.



Pour commencer, les performances d'écriture sur la table ont terriblement diminué. Puis la vitesse de lecture a chuté. Les blocs ont commencé. Nous avons trouvé des demandes écrites par un entrepreneur, qui ont été exécutées à chaque pic du scanner 1,5 mille (!) Fois. Il y avait des lieux avec une récursion sans fin, qui a été interrompue au dix millième pas par un effort de volonté, exprimé par le commentaire «// nous nous limiterons à la démonstration». D'une manière ou d'une autre, de nombreux utilisateurs ont soudainement trouvé le droit de modifier manuellement les données, dont certains n'ont pas manqué de profiter. Le contrôle de la séquence d'opérations effectuée par le numéro de la ligne dans la fiche technique, et non par le numéro de l'opération technique (ce sont des colonnes stupidement différentes du tableau, et elles ne doivent pas nécessairement coïncider), à la suite de quoi les gens ont reçu un message informatif "La séquence des opérations a été violée." Utilisation des feuilles de routage du papier,sans corriger le fait de la livraison au magasin et le contrôle des changements, a conduit à des échecs de numérisation constants - les changements dans les données dans le système ont bêtement changé la composition du code à barres, et celui imprimé n'était plus reconnu. Etc.



Naturellement, le programmeur est allé voir le gestionnaire avec ces informations, et plus d'une fois. Naturellement, personne ne l'a écouté. Par conséquent, le programmeur est entré dans le problème de temps le plus grave.



D'une part, il était nécessaire d'assurer le fonctionnement actuel du système. Cela s’exprimait dans le fait de rester constamment assis au téléphone et de modifier manuellement les données dans une table plate - c’est banal pour que le magasin ne trébuche pas. Par contre, lentement, tant qu'il y avait du temps, j'ai essayé de tout arranger. L'usine fonctionnait 24 heures sur 24, mais le soir et la nuit, ils appelaient moins, alors le programmeur a utilisé cette fois pour réparer la belle automatisation.



Cependant, le négatif accumulé par le leader ne pouvait plus être contenu. Ils voulaient renvoyer le programmeur. En fait, c'était l'une des raisons de la vérification, sur laquelle je me suis appuyé.



Quelques jours plus tard, lorsque le rapport était prêt, j'ai passé deux heures à les persuader de ne pas renvoyer le programmeur. J'ai recommandé qu'il soit promu et qu'il commence enfin à écouter ce qu'il a à dire. Prévoyez du temps pour la refactorisation et le rangement. Nous avons réussi à les convaincre que le programmeur ne devrait pas être expulsé au moins aujourd'hui. Nous avons convenu de tenir plusieurs autres réunions, incl. - avec un programmeur. Et c'était mon erreur.



Le lendemain, tout le monde s'est réuni. Des cadres de tous bords ont commencé à dresser la liste des problèmes que le programmeur ne pouvait pas résoudre. Il a répondu avec confiance à toutes les questions. En règle générale, avec la même phrase - «Je l'ai déjà fait, je vous ai montré», sur laquelle l'interlocuteur est resté silencieux. Dans la plupart des cas, j'ai confirmé que le programmeur disait la vérité.



Pour une argumentation plus efficace, ils ont sorti un ordinateur et ont commencé à montrer sur le pouce ce que «le programmeur ne peut en aucun cas faire». Nous avons trouvé presque tout "qui nous manquait tant pour un travail normal". Et tout est assez beau. Au moins ça marche.



À la fin de la réunion, personne ne comprenait quel était son objectif. Le programmeur, plein d'espoir, s'est rendu sur son lieu de travail. Les dirigeants se sont également dispersés, laissant quelques-uns des principaux. Je me suis assis et j'ai attendu le verdict - en espérant, bien sûr, une seconde chance pour le programmeur et en suivant mes recommandations ("vous avez tout ce dont vous avez besoin, vous ne savez tout simplement pas comment l'utiliser").



Mais le verdict a été prononcé différemment - "vous voyez, il doit être renvoyé". Pour quoi?! Bien sûr, parce que le système est beau. Mais ça ne marche pas. Et le programmeur est à blâmer pour cela.



PS Le programmeur était content d'avoir été renvoyé. Il ne s'est pas quitté, car il se sentait responsable, voire hyper-responsable de ce qui se passait à l'usine. Une semaine plus tard, il occupait un nouvel emploi avec un salaire plus élevé.