Was passiert während der normalen Automatisierung? Eine technische Aufgabe, funktionale Anforderungen, Architektur und eine Reihe anderer Papierstücke werden erstellt. Es beschreibt alle Bedingungen, Einschränkungen, Arbeitsalgorithmen in Abhängigkeit von der Umgebung, dem Erscheinungsbild von Formularen, der Datenvalidierung usw. Oft dauert das Design und die Koordination dieser Papierstücke länger als die Automatisierung selbst.
Ein Projekt wird angezeigt, ein Zeitplan, eine Zerlegung von Aufgaben, ein bestimmter Projektmanager oder sogar mehrere. Formalitäten übernehmen, d.h. Form, nicht Inhalt.
Es ist klar, dass dies in einigen Situationen die Art zu handeln ist. Wenn sich beispielsweise ein externes Unternehmen mit Automatisierung befasst, wird es ohne solche Papiere nicht überleben. Er wird erst jagen, wenn er die außer Kontrolle geratenen Anforderungen erreicht hat. Papiere garantieren Stabilität, Vorhersehbarkeit von Zahlungen und Arbeitsleistung. Für den Kunden garantieren diese Zettel jedoch nur eines - ein langes, langweiliges Projekt, das keinen Nutzen bringt.
In der Business-Programmierung ist dieser Ansatz nicht geeignet. Ich möchte Sie daran erinnern, dass Business Programming eine komplexe Änderung ist, die gleichzeitig Prozesse, Motivation, Ziele und Managementsysteme unterstützt und von der Automatisierung unterstützt wird.
Sie entscheiden sich beispielsweise, den Prozess zu ändern. Keiner, der tausend Menschen betrifft - es gibt keine Lösung für Ihr Knie. Der Prozess betrifft beispielsweise fünf Personen einer Abteilung. Alle diese Leute sitzen wie ihr Anführer neben dir - hier sind sie auf Armeslänge. Und Sie haben gemeinsam mit ihnen beschlossen, den Prozess zu ändern. Sie setzten sich, redeten, fanden heraus, dachten nach und entschieden. Sie haben beispielsweise einen Tag gebraucht, um den Prozess zu ändern.
In den meisten Fällen benötigen Sie nach einer Änderung des Prozesses eine Automatisierung - Sie müssen Änderungen am Informationssystem vornehmen. Wenn Sie sagen - Sie brauchen eine technische Aufgabe, einen Zeitplan, ein Projekt mit einem Leiter, Kurator und Sponsor, dann ist das alles. Hier enden Ihre Änderungen. Ein langes Automatisierungsprojekt mit Formalitäten wird Prozessänderungen negieren.
Was besonders wichtig ist: Prozessänderungen sind Experimente. Selbst als erfahrener Business-Programmierer können Sie nicht sicher wissen, ob Ihre Änderung funktioniert oder nicht. Die gewählte Methode könnte sich in einem anderen Prozess oder sogar in genau demselben, aber in einem anderen Unternehmen gut zeigen, aber in diesem Zusammenhang kann sie sich als unwirksam herausstellen.
Da dies ein Experiment ist, hat es zeitliche Grenzen - heute wurde es ausgedacht, es wurde morgen gestartet, wir schauen es uns eine Woche lang an und treffen eine Entscheidung. Wenn alles in Ordnung ist, gehen Sie. Wenn nicht, denken wir weiter - entweder brechen Sie die Änderung ab oder verfeinern und verbessern Sie sie.
Was wird diese Woche mit der Automatisierung passieren? Wenn Sie den traditionellen Weg wählen, haben Sie in einer Woche nur die technische Aufgabe und dann im besten Fall. Dementsprechend muss die Implementierung der Änderungen manuell und ohne Automatisierung erfolgen. Wenn Sie solche Änderungen vornehmen, die keine Automatisierung erfordern, können Sie dies "per Auge" überprüfen. Und wenn nicht?
Hier ist das Prinzip der schnellen Automatisierung gefragt. Tatsächlich liegt sein Kern im Namen - Änderungen am System müssen schnell, ohne Koordination und Anforderungen vorgenommen werden, genau in dem Umfang, der erforderlich ist, um die Haupthypothese zu testen, die Sie durch Ändern des Prozesses aufgestellt haben.
Sie müssen sich nicht viel um die Benutzeroberfläche, die Überprüfung der Eingabedaten, die Optimalität des Codes, die Datenstruktur und andere Säulen der „richtigen“ Automatisierung kümmern. Ihre Aufgabe ist es, die Automatisierung von Änderungen im Prozess schnell zu unterstützen, um zu überprüfen, ob sie funktionieren oder nicht.
Das Prinzip der schnellen Automatisierung ist allen Programmierern bekannt. Nur sie kennen es nicht als Prinzip, sondern als großes Übel - es wird angenommen, dass Unwissenheit, Mittelmäßigkeit und Anfänger an einer solchen Automatisierung beteiligt sind.
Teilweise haben Programmierer recht. Aber sie haben einen grundlegend anderen Kontext. Normalerweise geht es ja doch so. Es gibt einige „Betrüger“ - Geschäftsanalysten, Benutzer und deren Führungskräfte. Sie haben sich dort etwas ausgedacht und sagen - also mach mir schnell eine Form / ein Feld / ein Fenster. Was, wie, warum, warum - nicht erklären. Noch hinzufügen - schnell komm schon, Stiefel. Was bleibt dem Programmierer übrig? Wenn es eine Gelegenheit gibt, wird er anfangen zu pflastern - sagen Sie, dass es unmöglich ist, so dass Sie eine technische Aufgabe, durchdachte Architektur, Refactoring usw. benötigen. In der Regel gibt es jedoch keine Möglichkeit zu betrügen, und der Programmierer erledigt dies einfach schnell „auf dem Knie“ im extremen Programmiermodus.
Na ja, irgendwie und okay, zur Hölle mit ihm, oder? Ich habe genau das vorgeschlagen - schnell, ohne Probleme, wenn es nur funktioniert?
Ein entscheidender Moment entsteht, wenn die „Verräter“ die Sinnlosigkeit des Wandels erkennen. Der Business-Programmierer bricht solche Änderungen einfach ab und fordert den Programmierer auf, die eingeführten Codeteile zu löschen. Was ist mit dem "Betrüger"? Oder genauer gesagt "Trauerbetrüger"?
Er wird nichts absagen. Lassen Sie es einfach so wie es ist und nehmen Sie bestenfalls weitere Änderungen vor. Verstehst du Ohne die vorherigen zu stornieren, werden immer mehr neue erstellt.
Es gibt einen politischen Moment, insbesondere wenn der Abteilungsleiter die Änderungen vorgenommen hat. Es ist äußerst wichtig für ihn, nicht dumm auszusehen, egal welchen Unsinn er erfunden hat, er wird ihn nicht aufheben. Wenn Sie es gegen die Wand drücken, schützt es außerdem seine Änderungen.
Meistens kommt es vor, dass niemand die vorgenommenen Änderungen verwendet. Wenn Sie ein Programmierer sind, ist Ihnen diese Situation möglicherweise vertraut. Sie fragten, befahlen, verlangten, eine Art System herzustellen, und benutzten es dann nicht. Es kann sogar nicht "am Knie" durchgeführt werden, sondern normalerweise in Übereinstimmung mit allen Anforderungen und Bedingungen der "richtigen" Automatisierung, aber sie verwenden es immer noch nicht. Jetzt weißt du warum. Und warum niemand diese Funktionalität aus dem System entfernt - das wissen Sie jetzt auch.
So entstehen und wachsen vielschichtige Kuchen sinnloser Patchwork-Automatisierung. Programmierer kichern, aber tun, was sie sagen. Dreck, Nichtoptimalität, Kurvenstruktur und Architektur wachsen wie ein Schneeball. Und je weiter, desto schwieriger wird es sein, diesen Prozess zu stoppen und umzukehren.
Ein weiteres Problem ist die Sinnlosigkeit der vorgeschlagenen Änderungen insgesamt.
In der Business-Programmierung hat jede Änderung ein Ziel, das alle Teilnehmer verstehen. Der Prozess sollte schneller, zuverlässiger oder kontrollierter werden. Daher sind sowohl der Zweck der Änderungen als auch die Kriterien für die Bewertung ihrer Wirksamkeit immer klar.
Aber wenn Änderungen "einfach so" oder "um es für mich bequemer zu machen" oder "gut, genauso gut!" Vorgenommen werden, ist es unmöglich, das Ergebnis zu bewerten. Daher bleiben Änderungen, egal wie bedeutungslos sie sind, bestehen - sowohl im Prozess als auch in der Automatisierung.
Jetzt verstehen Sie, wo das Problem liegt - die Lücke zwischen Prozessänderung und Automatisierung. Wenn einige Leute Änderungen im Prozess einfallen lassen und dann anderen Leuten Automatisierungsaufgaben übertragen, ohne die Bedeutung und das Wesentliche zu erklären, kommt es zu einem normalen Durcheinander, von dem niemand profitiert.
Nach den Standards der Business-Programmierung wird in einem Team gearbeitet - es gibt sowohl Mitarbeiter aus Prozessen als auch Mitarbeiter aus der Automatisierung. Noch besser, wenn diese Arbeit von einer Person geleitet wird - einem Business-Programmierer. Noch besser, wenn er die Automatisierung selbst macht.
In diesem Fall verstehen und verwalten wir den Lebenszyklus vorübergehender Änderungen - warum sie vorgenommen werden, wann sie beginnen und vor allem wann und unter welchen Bedingungen sie enden.
Angenommen, die Änderungen waren falsch - das ist normal, daran ist nichts auszusetzen. Dann haben die Programmierer eine ungewöhnliche Aufgabe - Änderungen im System zu löschen. Natürlich erledigen sie solche Arbeiten manchmal selbst - zum Beispiel Refactoring. Bei der Business-Programmierung müssen diese Arbeiten jedoch regelmäßig durchgeführt werden.
Und wenn die Änderungen korrekt waren? Dann kommen alle Fähigkeiten der „richtigen“ Automatisierung ins Spiel, auf die Programmierer so stolz sind. Sie müssen die Architektur, Datenstruktur, Algorithmen, Überprüfung der eingegebenen Daten, Schnittstelle usw. schätzen. Aber was ist der Unterschied?
Der Unterschied in der Form der Problemstellung. Normalerweise ist dies eine technische Aufgabe, dh ein Stück Papier. In unserem Fall ist die Aufgabe ein Prototyp. Ein Arbeiter, der seine Nützlichkeit und Effektivität gezeigt hat, hat sozusagen im Kampf getestet. Es ist nur notwendig, sich daran zu erinnern. Sie müssen nichts wirklich koordinieren und diskutieren - nehmen Sie es einfach und erstellen Sie ein System gemäß den Regeln und Standards der Umgebung, in der das Programm erstellt wird.
Wenn Sie ständig schnell programmieren, erwerben Sie die Fertigkeit sehr schnell - tun Sie dies sofort, damit Sie sie später beheben können. Hier spielt uns die „richtige Faulheit“ des Programmierers in die Hände - er wird nicht bereit sein, dasselbe Problem zweimal zu lösen, und er selbst wird herausfinden, wie man schnell einen Prototyp erstellt und ihn mit minimalem Aufwand in eine Komplettlösung verwandelt. Obwohl es in der Business-Programmierung natürlich keine vollständigen Lösungen gibt.
Jetzt ist es gängige Praxis wie Prototyping und Modellierung, wenn vor dem Start eines großen Automatisierungsprojekts schnell, mit minimalem Aufwand und ohne Probleme mit der Schnittstelle ein bestimmter Prototyp des zukünftigen Systems erstellt wird. Wie Sie wissen, ist dies dem Prinzip der schnellen Automatisierung sehr ähnlich, obwohl es natürlich nicht darum geht, wie der Prototyp erstellt wurde, sondern wie er sich an eine sich ändernde Umgebung anpassen wird.
Wenn Prototyping nur ein Marketingtrick eines Integratorenunternehmens ist und trotzdem ein großes Stück Papier erscheint, wie eine technische Aufgabe, dann ist dies nur ein Trick. Es schafft die Illusion des Kunden, dass "alles so sein wird, wie ich es brauche", aber leider wird es im Leben nicht so sein. Der Prototyp wird nicht lange leben und in der Dunkelheit verschwinden.
Und jetzt verstehst du warum. Automatisierung ist fast immer ein Karren, kein Pferd. Das Pferd ist eine Veränderung in den Prozessen, und der Wagen folgt. Aber reitet nur, wenn es an ein Pferd gebunden ist.
Das Pferd drehte sich um, der Karren folgte. Mit einer Verzögerung, mit Rückschlägen und Verwehungen, aber gedreht. Und wenn jedes Pferd und jeder Karren sein eigenes Leben führt, muss der Karren von unglücklichen Programmierern getragen werden. Ein großer Prototyp eines großen Systems, das vor einem großen Automatisierungsprojekt erstellt wurde, ist eine Momentaufnahme, eine Momentaufnahme eines Pferdes, das an einem Karren befestigt ist. Alles ist schön, jeder ist glücklich, jeder mag es, aber ein Tag oder eine Woche oder sogar ein Monat vergeht, und das Pferd wirft den Karren und geht dorthin, wo es sein muss. Und der Wagen ist schön, elegant, nach allen Kanonen gefertigt, es bleibt allein auf dem Feld zu stehen.
Daher lohnt sich „großes“ Prototyping nicht. Sowie die "große" Automatisierung. Um ein großes Automatisierungsprojekt zu starten und durchzuführen, muss man einen verdammt außergewöhnlichen Verstand, Weitsicht und unglaubliches Talent im Management haben. Wenn diese Worte über Sie sind, dann gratuliere ich Ihnen aufrichtig und wünsche Ihnen viel Erfolg.
Ich empfehle den Rest, das Prinzip der schnellen Automatisierung anzuwenden.
Und noch einmal erinnere ich Sie daran: Automatisierung folgt dem Prozesswechsel. Nicht vor einer Änderung, nicht anstelle einer Änderung, nicht getrennt von der Änderung. Sie änderten den Prozess, automatisierten ihn schnell und betrachteten das Ergebnis. Gut - schnell in Erinnerung rufen. Nicht gut - wirf es weg.