💻 👩🏽‍🎓 👜 Wie vermeide ich Programmierverbrechen? Integrator-Tipps 👌🏽 👇🏾 🤘

In einem früheren Artikel über die Probleme der Einführung von ERP in Industrieunternehmen wurde als Fallstudie einer der Punkte auf die "programmatische Gesetzlosigkeit" gebracht.

Wir haben einen Kunden, dessen Mitarbeiter uns jetzt zweifelhafte Anforderungen senden und angeben, ob dies eine programmatische Gesetzlosigkeit ist. Und einige geben nicht an, sondern erstellen es.

Das Thema ist relevant und ich habe beschlossen, einen separaten Artikel darüber zu schreiben.

Was ist es?

Welche Art von Gemälden malt Ihre Fantasie, wenn Sie den Satz „programmatische Gesetzlosigkeit“ hören?

Ein bärtiger Mann mit einem nachdenklichen, klugen Blick schlägt den tränenreichen Hauptbuchhalter mit einer Menge Knut und sagt: "Kopek, Sie sagen, Sie haben der Rechnung nicht zugestimmt? Der Empfänger passt nicht in die Zelle? Jetzt werden wir es mit einem Buch stempeln und alles wird passen! “

, - . , : « 10 , ? ? , ?» — , - … : « – : , . : … …»

Dieses Phänomen ist weniger bunt als Sie sich vorstellen können, aber schrecklicher. Am Ende kann der Hauptbuchhalter beruhigt, die Tränen abgewischt und zu einem Psychologen geschickt werden, die Meister können von einem Stuhl gelöst und zur Arbeit geschickt werden. Die Buchungskurven in InventTrans und die inaktiven aufgrund von Fehlkalkulationen in der Lösungsarchitektur und unnötigen Verbesserungen werden vom Psychologen jedoch nicht korrigiert.

Programmatische Gesetzlosigkeit ist eine Situation, in der als Ergebnis der Programmierung, deren Zweck darin bestand, bestimmte Probleme eines Unternehmens zu lösen, andere, häufig schwerwiegendere Probleme für Unternehmen entstehen.

Lassen Sie mich einige Beispiele nennen:

, , . - , .
. , , «» . . , , .

Ich wollte den Artikel „Programmierer-Chaos. Crying Integrator “, erkannte aber, dass sich niemand um unsere Tränen kümmert. Tipps zur Vermeidung solcher Situationen können jedoch hilfreich sein.

Ich werde versuchen, die Grenzen meiner Empfehlungen im Voraus zu skizzieren - wir sprechen über:

Programmierer, die an der Implementierung oder Wartung von ERP-Systemen beteiligt sind. Ich denke, dass sie etwas andere Anforderungen haben als zum Beispiel die Entwickler eines neuen Produkts oder einer neuen Technologie.
Programmierer, die mit dem Client arbeiten. Integrator-Entwickler sind weniger anfällig für "Empörung".

Was sind die Ursachen für dieses Phänomen und was kann dagegen getan werden?

Unwillen oder Unfähigkeit, das Wesentliche des Prozesses zu betrachten

Ich sehe das oft bei unerfahrenen Analysten und Programmierern. Sie beantworten einfach die Frage, die der Kunde ihnen gestellt hat. Sie denken nicht darüber nach - warum hat er danach gefragt, braucht er es wirklich? Mit der Zeit vergeht dies, aber zuerst muss man fangen und erklären.

"Und können Sie die Anzahl der Dezimalstellen für diesen Koeffizienten auf 4 erhöhen?" - "Natürlich". Aber nichts, dass dieser Koeffizient verwendet wird, um den Parameter zu indizieren, der eine Genauigkeit von 1 Dezimalstelle hat und dessen Werte 50 nicht überschreiten? Alle Koeffizientengenauigkeiten werden gerundet. Vielleicht ist es besser, das nicht zu tun?

"Fügen Sie der Nomenklaturreferenz ein neues Feld dieses Typs hinzu" - "Gut. Die Komplexität von 15 Minuten. " Warum brauchen Sie dieses Feld in den Nomenklaturen? Dies ist eine Eigenschaft, die von Partei zu Partei unterschiedlich ist. Vielleicht ist es besser, dieses Feld zum Verzeichnis der Parteien hinzuzufügen?

Ein Entwickler in ERP muss nicht nur ein Implementierer der Änderungen sein, die Benutzer vornehmen. Er muss die Logik des Systems verstehen und als Beschützer gegen jeden Unsinn fungieren. Dazu wäre es schön, Geschäftsprozesse zumindest auf der Ebene des gesunden Menschenverstandes zu verstehen und den Benutzern unangenehme Fragen stellen zu können.

Wenn einer der Benutzer noch nie mit Beschwerden über die Unverschämtheit eines Programmierers auf Sie zurückgegriffen hat, der sich geweigert hat, seine „Wunschliste“ zu implementieren, sollte dieser Entwickler genauer hinschauen. Vielleicht macht er einfach das, was sie sagen. Und das endet selten mit etwas Gutem.

Mangel an Ausdauer im Kampf gegen den Wunsch, alles auf die alte Art zu verlassen

Dies ist der Fall, wenn das Chaos der Programmierer nicht von Entwicklern verursacht wird, sondern mit deren Konnektivität.

Jedes seriöse Produkt enthält nicht nur eine Reihe spezifischer Funktionen, sondern auch eine Ideologie und Best Practices. Und die Leute wollen auf die alte Art arbeiten. Und sie setzen den Programmierer unter Druck, ihm diese Gelegenheit zu geben. Und wenn er nicht beweisen konnte, dass dies nicht getan werden sollte, könnte alles traurig enden.

, , , . . : « 1974 , , ». , , , , . « , , – ». , , , . , . , , . : , , - , . : «».

Was kann man damit machen? Unterordnen Sie den Programmierer zunächst nicht den wirtschaftlichen Dienstleistungen. Er muss in einer anderen Einheit arbeiten und eine gewisse Unabhängigkeit von der Leitung von Abteilungen haben, deren Arbeit automatisiert ist.

Es wäre schön, dieser Kette ein Glied hinzuzufügen: Alle ernsthaften Verbesserungen sollten nicht nur vom Auftragnehmer genehmigt werden, sondern auch von jemandem, der das Geschäft des gesamten Unternehmens versteht und über Macht verfügt. Eine solche Person kann definitiv sagen: "Nein."

Die Gewohnheit, alle Probleme durch Programmierung zu lösen

Die Liebe zur Automatisierung führt zu Fortschritt, schadet aber manchmal. Ich habe gesehen, wie diese Eingabe automatisiert wurde, anstatt die Leute anzuweisen, Daten manuell in das System einzugeben. Automatisiert, wobei alle Details oder Funktionen vergessen werden, die notwendigerweise bemerkt, diskutiert und höchstwahrscheinlich durch manuelle Eingabe korrigiert worden wären. Und so - jeder ist sich sicher, dass es keine Fehler gibt, aber nach einer Weile treten die Konsequenzen massenhaft auf, die bereits viel schwieriger zu beheben sind als die Grundursache.

, , . , , , . . , . , , . : .

Wenn ein Programmierer aufgefordert wird, ein Skript zu schreiben, um 200 Fehler zu beheben, die aufgrund der Tatsache entstanden sind, dass Benutzer nicht gemäß den Anweisungen gearbeitet haben, sollte er nicht kopfüber auf die Tastatur stürzen. Wir müssen abschätzen, wie viel Zeit erforderlich ist, um einen Fehler manuell zu beheben. Wenn die Zeit zum manuellen Beheben aller Fehler die Komplexität des Schreibens eines Skripts nicht um eine Größenordnung überschreitet, müssen Benutzer diese Fehler selbst beheben: Es besteht eine größere Wahrscheinlichkeit, dass sie in Zukunft gemäß den Anweisungen arbeiten. Dies sollte in der Regel an der Wand in der Nähe des Programmierers aufgehängt werden, damit er alle Besucher in dieses Stück Papier stecken kann.

Aus irgendeinem Grund glauben wir außerdem, dass Menschen, die aufgrund der Automatisierung von Routinearbeiten befreit werden, etwas Nützliches tun: Sie werden Ideen zur Verbesserung von Geschäftsprozessen anbieten, die Berichterstellung optimieren und weniger erfahrene Kollegen schulen. Aber höchstwahrscheinlich haben sie einfach mehr Zeit für Tee, Rauchpausen und das Internet bei der Arbeit. Lohnt es sich also?

Selbstvertrauen

Es gibt eine Funktionalität, die nicht geändert werden sollte. In Axapt ist dies beispielsweise eine Masterplanung. In meiner Erinnerung haben wir ihn nur zweimal berührt. Und jedes Mal wurde es nicht in den Code eingebettet, sondern eine Art „Fleck“ - Funktionen, die vor oder nach der konsolidierten Planung ausgeführt wurden. Und trotzdem erinnere ich mich mit Sehnsucht an diese Verbesserungen.

Es gibt weniger offensichtliche Stellen, an denen Sie nicht klettern sollten. Eine gute Möglichkeit, einen erfahrenen Programmierer von einem Anfänger zu unterscheiden, besteht darin, eine solche Funktionalität zu verfeinern: Ein erfahrener Programmierer wird überrascht sein und sich weigern, kann zur Optimierung des Geschäftsprozesses raten, und der Anfänger wird sagen: „Komm schon.“

Hier kann eines empfohlen werden: Leute mit Erfahrung einzustellen, die bereits von anderen Kunden oder bei anderen Projekten alle Unebenheiten bekommen haben, die im Prinzip gefüllt werden könnten.

Fehlende Entwicklungsvorschriften

Wenn wir ein Projekt zur Wartung durchführen, ist eines der ersten Dokumente, die wir den Kunden fragen, die Entwicklungsvorschriften, die die Entwicklungsumgebung beschreiben, Regeln für die Benennung von Objekten, Verbote und Einschränkungen. Das Seltsamste ist, dass es manchmal nicht passiert. Und dies ist ein sicheres Zeichen - es wird Müll im Code geben: ausgehend vom klassischen Mangel an Kommentaren und endend mit Situationen, in denen bestimmte Werte aus Verzeichnissen für verschiedene Zweige des Algorithmus direkt in den Text geschrieben wurden. Und Müll im Code ist der erste Schritt zu Problemen mit dem Geschäft.

Sprechen Sie deshalb nicht darüber, dass „Programmieren eine Kunst ist. Es ist nicht reguliert "," aber was ist mit Agilität? " und das ist alles. Wenn Sie sich entwickeln, sollte es eine Regelung geben. Und das sind nicht 3 Punkte:

Die Entwicklung wird für die Entwickleranwendung durchgeführt.
Die Prüfung wird an der Prüfanwendung durchgeführt.
Der Code muss Kommentare enthalten.

Dies sollte ein vollwertiges Dokument mit zehn Seiten mit Abschnitten sein:

Anforderungen für Entwicklungsanwendungen.
Voraussetzungen für das Schreiben der Problemstellung.
Voraussetzungen für das Schreiben von Code.
Testanforderungen.
Migrationsanforderungen zwischen Anwendungen.

In der Regel wird der gesamte Hardcode nach dem Prinzip „Lass es uns schnell und dann normal machen“ erstellt. Es ist schnell erledigt und wird dann vergessen ... Und wenn es ein signiertes Dokument gibt, das besagt, dass dies nicht möglich ist, können Sie jederzeit darauf zugreifen und dem Benutzer sagen: "Es wird nicht schnell funktionieren, es ist mir verboten, so zu arbeiten." Entschuldigung, Alevtina Svetozarovna, ich würde mich freuen, alle Schecks direkt am Arbeiter zu kommentieren, aber dann werden sie mich entlassen. "

Einsamkeit und mangelnde Kontrolle

Ein einsamer Programmierer ist böse. Es sollte immer jemanden geben, der sagt: "Nun, was hast du, ein Dummkopf, getan?" - Ansonsten entspannt sich der Entwickler, vergisst die Regeln, vergisst die Verantwortung. Hier beginnt der Hardcode, zweifelhafte Architekturentscheidungen, Fehler, die das Geschäft betreffen.

Auf clevere Weise wird dies als „Codeüberprüfung“ bezeichnet, und dies sollte immer mit den Entwicklungsvorschriften einhergehen. Nach jeder Überarbeitung sollte vor dem Testen überprüft werden, ob der Code den Entwicklungsvorschriften und Best Practices entspricht. Eine Codeüberprüfung ermöglicht:

Kontrolle der Entwicklungsqualität;
weniger erfahrene Programmierer ausbilden.

Daher sollten Entwickler mindestens 3 Teile umfassen (zwei sind sich immer einig, dass Sie nichts tun können, ein Dritter des Systems verringert die Wahrscheinlichkeit von Absprachen erheblich). Und sie müssen gemäß den internen Vorschriften arbeiten, von denen einer der wichtigsten Punkte die obligatorische Überprüfung des Codes ist.

Fazit

Um die Wahrscheinlichkeit einer "programmatischen Gesetzlosigkeit" zu verringern, ist es daher erforderlich, eine eigene interne Entwicklungsabteilung gemäß den folgenden Regeln zu bilden:

Dies muss ein Team von mindestens 3 Personen sein.
Mindestens eines dieser Teams muss Erfahrung in der Implementierung oder Wartung eines ERP-Systems haben. Es sollte sein n-tes Projekt sein, bei dem n> 3 ist.
Die Entwicklungsabteilung sollte idealerweise direkt an den CEO berichten.
Endbenutzer müssen sich manchmal beschweren, dass Programmierer sich weigern, einige ihrer Anforderungen umzusetzen.
Selbst für eine so kleine Abteilung müssen Vorschriften entwickelt werden, deren Verletzung bestraft werden muss.

Das ist natürlich meine Vision. Es kann argumentiert werden, dass ich zu jedem dieser Punkte sogar Gegenbeispiele aus meiner Erfahrung geben kann, wenn die Anforderung nicht erfüllt wurde, aber alles perfekt war. Diese Empfehlungen können jedoch als Ausgangspunkt für die Bildung ihrer Prinzipien zur Bekämpfung der programmatischen Gesetzlosigkeit verwendet werden.

Wie vermeide ich Programmierverbrechen? Integrator-Tipps