Que se passe-t-il pendant l'automatisation normale? Une tâche technique, des exigences fonctionnelles, une architecture et un tas d'autres morceaux de papier sont élaborés. Il décrit toutes les conditions, limitations, algorithmes de travail selon l'environnement, l'apparence des formulaires, la validation des données, etc. Souvent, la conception et la coordination de ces morceaux de papier prennent plus de temps que l'automatisation elle-même.
Un projet apparaît, un planning, une décomposition des tâches, un certain chef de projet, voire plusieurs. Les formalités prennent le relais, c'est-à-dire forme, pas le contenu.
Il est clair que dans certaines situations, c'est la façon d'agir. Par exemple, si une entreprise externe est engagée dans l'automatisation, elle ne survivra pas sans ces papiers. il ne poursuivra qu'après avoir atteint les exigences de fugue. Les papiers garantissent la stabilité, la prévisibilité des paiements et la livraison du travail. Mais pour le client, ces morceaux de papier ne garantissent qu'une chose: un projet long et ennuyeux qui n'apportera aucun avantage.
En programmation d'entreprise, cette approche n'est pas adaptée. Permettez-moi de vous rappeler que la programmation d'entreprise est un changement complexe, à la fois pour les processus, la motivation, les objectifs, le système de gestion, soutenu par l'automatisation.
Par exemple, vous décidez de modifier le processus. Pas une qui affecte un millier de personnes - il n'y a pas de solution sur votre genou. Le processus, par exemple, concerne cinq personnes d'un même département. Tous ces gens, comme leur chef, sont assis à côté de vous - les voici, à bout de bras. Et vous avez décidé, avec eux, de changer le processus. Ils se sont assis, ont parlé, ont compris, réfléchi et décidé. Par exemple, il vous a fallu un jour pour changer le processus.
Dans la plupart des cas, après avoir changé le processus, vous avez besoin d'une automatisation - vous devez apporter des modifications au système d'information. Si vous dites - vous avez besoin d'une tâche technique, d'un calendrier, d'un projet avec un leader, un conservateur et un sponsor, alors c'est tout. C'est là que vos modifications prendront fin. Un long projet d'automatisation avec des formalités annulera le changement de processus.
Ce qui est particulièrement important: les changements de processus sont des expériences. Vous, même en tant que programmeur d'entreprise sophistiqué, ne pouvez pas savoir avec certitude si votre changement fonctionnera ou non. La méthode choisie pourrait bien se montrer dans un autre processus, ou même exactement de la même façon, mais dans une entreprise différente, mais dans ce contexte, elle pourrait s'avérer inopérante.
Puisqu'il s'agit d'une expérience, elle a des limites de temps - aujourd'hui, elle a été pensée, elle a été lancée demain, nous l'examinons pendant une semaine et prenons une décision. Si tout va bien, partez. Sinon, nous pensons plus loin - soit annuler le changement, soit affiner et l'améliorer.
Qu'adviendra-t-il de l'automatisation cette semaine? Si vous choisissez le chemin traditionnel, dans une semaine, vous n'aurez que la tâche technique, puis dans le meilleur des cas. En conséquence, la mise en œuvre des modifications devra se faire manuellement, sans automatisation. Eh bien, si vous apportez de telles modifications qui ne nécessitent pas d'automatisation - vous pouvez vérifier "à l'œil nu". Et sinon?
C'est là que le principe de l'automatisation rapide est nécessaire. En fait, son essence réside dans le nom - les modifications du système doivent être apportées rapidement, sans coordination ni exigences, exactement dans la mesure nécessaire pour tester l'hypothèse principale que vous avancez en modifiant le processus.
Vous n'avez pas à vous soucier de l'interface, de la vérification des données d'entrée, de l'optimalité du code, de la structure des données et des autres piliers de la «bonne» automatisation. Votre tâche consiste à soutenir rapidement l'automatisation des changements dans le processus pour vérifier s'ils fonctionnent ou non.
Le principe de l'automatisation rapide est connu de tous les programmeurs. Seulement, ils ne le connaissent pas comme un principe, mais comme un grand mal - on pense que l'ignorance, la médiocrité et les débutants sont engagés dans une telle automatisation.
Les programmeurs ont en partie raison. Mais ils ont un contexte fondamentalement différent. Habituellement, comment cela se fait-il? Il existe des «tricheurs» - des analystes commerciaux, des utilisateurs et leurs dirigeants. Ils ont trouvé quelque chose là-bas, et ils disent - alors, faites-moi rapidement une forme / un champ / une fenêtre. Quoi, comment, pourquoi, pourquoi - n'expliquez pas. Ajoutez encore - venez vite, bottes. Que reste-t-il au programmeur? S'il y a une opportunité, il commencera à paver - disons que c'est impossible pour que vous ayez besoin d'une tâche technique, d'une architecture réfléchie, d'une refactorisation, etc. Mais, en règle générale, il n'y a aucune possibilité de tricher, et le programmeur le fait simplement rapidement, «à genoux», en mode de programmation extrême.
Eh bien, en quelque sorte, et d'accord, au diable avec lui, non? J'ai proposé exactement cela - rapidement, sans problèmes, si cela fonctionnait?
Un moment clé survient lorsque les «traîtres» voient le vide de sens du changement. Le programmeur d'entreprise annule simplement ces modifications et lui demande de supprimer les morceaux de code introduits. Et le «tricheur»? Ou, plus précisément, "tricheur de chagrin"?
Il n'annulera rien. Laissez-le tel quel et, au mieux, continuez à apporter des modifications. Tu comprends? Sans annuler les précédents, il en finira de plus en plus de nouveaux.
Il y a un moment politique, surtout si le chef du département a proposé les changements. Il est extrêmement important pour lui de ne pas avoir l'air stupide, donc, peu importe les bêtises qu'il a inventées, il ne les annulera pas. De plus, si vous le poussez contre le mur, il protégera ses changements.
Le plus souvent, il arrive que personne n'utilise les modifications apportées. Si vous êtes programmeur, cette situation peut vous être familière. Ils ont demandé, ordonné, exigé de créer une sorte de système, puis ils ne l'ont pas utilisé. Cela peut même être fait non pas "sur le genou", mais normalement, en conformité avec toutes les exigences et conditions de la "bonne" automatisation, mais ils ne l'utilisent toujours pas. Vous savez maintenant pourquoi. Et pourquoi personne ne supprime cette fonctionnalité du système - vous le savez aussi maintenant.
C'est ainsi que les tartes en couches d'automatisation patchwork insensée se révèlent et se développent. Les programmeurs gloussent, mais font tout ce qu'ils disent. La boue, la non-optimalité, la structure et l'architecture de la courbe poussent comme une boule de neige. Et plus loin, plus il sera difficile d'arrêter ce processus et de l'inverser.
Un autre problème est l’insensibilité des changements proposés dans leur ensemble.
Dans la programmation d'entreprise, tout changement a un objectif que tous les participants comprennent. Le processus devrait devenir plus rapide, plus fiable ou plus contrôlé. Par conséquent, l'objectif des modifications et les critères d'évaluation de leur efficacité sont toujours clairs.
Mais quand les changements sont effectués «juste comme ça», ou «pour que ça me soit plus pratique», ou «enfin, aussi bien!», Il est impossible d'évaluer le résultat. Par conséquent, les changements, aussi insignifiants soient-ils, restent à vivre - à la fois dans le processus et dans l'automatisation.
Vous comprenez maintenant quel est le problème - l'écart entre le changement de processus et l'automatisation. Lorsque certaines personnes proposent des changements dans le processus, puis définissent des tâches d'automatisation à d'autres personnes, sans expliquer le sens et l'essence, nous obtenons un gâchis normal qui ne profite à personne.
Selon les normes de la programmation d'entreprise, le travail est effectué en une seule équipe - il y a à la fois des gens des processus et des gens de l'automatisation. Encore mieux, lorsque ce travail est dirigé par une seule personne - un programmeur d'entreprise. Encore mieux quand il fait lui-même l'automatisation.
Dans ce cas, nous comprenons et gérons le cycle de vie des changements temporaires - pourquoi ils sont apportés, quand ils commencent et, surtout, quand et dans quelles conditions ils se terminent.
Supposons que les changements soient erronés - c'est normal, il n'y a rien de mal à cela. Ensuite, les programmeurs ont un travail inhabituel: supprimer les modifications du système. Bien sûr, ils font parfois un tel travail eux-mêmes - refactorisation, par exemple. Mais dans le cas de la programmation d'entreprise, ce travail doit être effectué périodiquement.
Et si les changements étaient corrects? Ensuite, toutes les compétences de la «bonne» automatisation entrent en jeu, dont les programmeurs sont si fiers. Vous devez estimer l'architecture, la structure des données, les algorithmes, la vérification des données saisies, l'interface, etc. Mais quelle est la différence, tu vois?
La différence dans la forme de l'énoncé du problème. Il s'agit généralement d'une tâche technique, c'est-à-dire d'un morceau de papier. Dans notre cas, la tâche est un prototype. Un travailleur qui a démontré son utilité et son efficacité, a pour ainsi dire testé au combat. Il suffit de le rappeler. Vous n'avez pas vraiment besoin de coordonner et de discuter de quoi que ce soit - il suffit de le prendre et de créer un système selon les règles et les normes de l'environnement dans lequel le programme est créé.
Si vous vous engagez tout le temps dans une programmation rapide, vous acquerrez très rapidement la compétence - faites-la immédiatement afin de pouvoir la corriger plus tard. Ici, la «bonne paresse» du programmeur jouera entre nos mains - il ne sera pas disposé à résoudre le même problème deux fois, et il trouvera comment créer rapidement un prototype et le transformer en une solution complète avec un minimum d'effort. Bien sûr, dans la programmation d'entreprise, il n'y a pas de solutions complètes.
Maintenant, c'est devenu une pratique courante comme le prototypage et la modélisation, quand avant de démarrer un grand projet d'automatisation, rapidement, avec un minimum d'efforts, sans problèmes avec l'interface, ils créent un certain prototype du futur système. Comme vous le savez, cela est très similaire au principe d'automatisation rapide, bien que le point, bien sûr, ne soit pas de savoir comment le prototype a été créé, mais comment il s'adaptera à un environnement en évolution.
Si le prototypage n'est qu'un stratagème marketing d'une entreprise intégratrice, et puis de toute façon un gros morceau de papier apparaît, comme une tâche technique, alors ce n'est qu'une astuce. Cela crée l'illusion du client que "tout sera comme j'ai besoin", mais, hélas, il n'en sera pas ainsi dans la vie. Le prototype ne vivra pas longtemps et disparaîtra dans l'obscurité.
Et maintenant tu comprends pourquoi. L'automatisation est presque toujours un chariot, pas un cheval. Le cheval est un changement de processus et la charrette suit. Mais ne monte que s'il est attaché à un cheval.
Le cheval se retourna, la charrette suivit. Avec un retard, avec des contrecoups et des dérives, mais tourné. Et si chaque cheval et chaque charrette vivent leur propre vie, alors la charrette doit être portée par des programmeurs mécontents. Un grand prototype d'un grand système créé avant un grand projet d'automatisation est un instantané, un instantané d'un cheval attelé à un chariot. Tout est beau, tout le monde est content, tout le monde aime ça, mais un jour, une semaine, voire un mois passent, et le cheval jette la charrette et va où il faut. Et le chariot est beau, élégant, fabriqué selon tous les canons, il reste à se tenir seul dans le domaine.
Par conséquent, le «gros» prototypage n'en vaut pas la peine. Ainsi que la "grande" automatisation. Pour démarrer et réaliser un grand projet d'automatisation, il faut avoir un sacré esprit extraordinaire, une prévoyance et un talent incroyable en gestion. Si ces mots vous concernent, je vous félicite sincèrement et vous souhaite plein succès.
Je recommande au reste d'utiliser le principe de l'automatisation rapide.
Et encore une fois je vous le rappelle: l'automatisation suit le changement de processus. Pas avant un changement, pas au lieu d'un changement, pas séparé du changement. Ils ont changé le processus, rapidement automatisé, ont regardé le résultat. Bon - rappelez-vous rapidement. Pas bon - jetez-le.