Ich glaube ich habe vor einigen Stunden die Klimax bezüglich einer weiteren Episode meines Lebens überschritten. Nachdem sich meine berufliche Entwicklung über die letzte Monate in verschiedenen Akten voran gekämpft hat, ist es nun zur Katastrophe gekommen. Schon seit einiger Zeit, bemerke ich an mir deutliche Zeichen von Überlastung und ständigem Stress. Spätestens wenn meine Haut beginnt sich mit Veränderungen zu äußern, weiß ich, dass ich etwas langsamer machen sollte oder gerade mal wieder eine stressige Phase ist. Das ist für mich nichts Neues, aber wenn es über mehrere Wochen anhält und partout nicht besser wird, dann ist wirklich etwas faul.
Doch zurück zum Thema, was genau ist das Problem? Als ich vor etwas mehr als zwei Jahren meinen Job begonnen habe, war bereits klar: Es geht um eine webbasierte Datenbank. Also durchaus ein Thema in dem ich schon Erfahrungen sammeln konnte – angefangen mit den ersten Schritten in PHP und Administration zu Schulzeiten, bis hin zur intensiven beruflichen Verwendung im zweiten Praxis-Semester. Abgerundet natürlich durch immer weitere Verfeinerungen und Lerneffekte aus Fehlern oder anderen Entwicklungen.
Erste Aufgabe war es eine bestehende Datenbank für den Übergang ins Netz vorzubereiten. Soweit halb so wild, nur sollte sie ja auch insgesamt besser werden. Also habe ich mir mit allem Sachverstand und logischer Analytik das bestehende System vorgenommen und bin fast aus allen Wolken gefallen. Das System war völlig ausgereizt und bestand aus mehr Flicken und Workarounds als ich es mir zu träumen gewagt hatte. Mit jedem weiteren Analyseschritt wurde mir klarer, dass die bestehenden Performance-Probleme kein Problem des Datenbankservers oder der verwendeten Programmiersprache (Access und VBA) waren, sondern das hier ein wesentlich grundlegenderes Problem bestand: Die Modellierung war im besten Falle unpräzise oder sehr ungeschickt ausgeführt (Entitäten nicht getrennt oder über die Anfangsbuchstaben in einem varchar-Feld unterschieden => warum die Performance hier mau ist, sollte klar sein: Wenn ich erst jedes Teil in einer Kiste untersuchen muss um festzustellen ob es aus Holz oder Stein gemacht ist, dann dauert es länger, als wenn man von Beginn an Stein und Holz in getrennte Kisten packt).
In den vergangenen Jahren habe ich also nichts anderes gemacht als die Datenbank von Grund auf neu zu entwickeln. Dabei habe ich alle Register meines Könnens gezogen, sicherlich nicht an jeder Stelle sofort mit den brilliantesten Ideen.
Leider musste ich feststellen, dass analytische und logische Arbeitsweise nicht immer das sind, was der Anforderer eigentlich möchte. Aber ich kann da nicht so ganz raus aus meiner Haut: Ich bin stets darum bemüht ein möglichst gutes und langlebiges Produkt zu entwickeln. (Das heißt nicht, dass ich nicht auch mal für eine kleine Arbeit oder automatisierte Korrektur ein Quick’n’Dirty-Skript schreibe – passendes Werkzeug für die jeweilige Aufgabe – auch das ist eine Kunst). Durch die Analyse und meine Stärken im organisatorischen Bereich (ja es zahlt sich gelegentlich auch aus, in der Jugendarbeit tätig gewesen zu sein) in Kombination mit den Erfahrungen und Techniken die ich während der Diplomarbeit entwickelt habe (ja GQM klingt zwar hoch gestochen, aber es ist ein sehr schöner Ansatz), stand relativ schnell eine grundlegende Struktur fest: Einerseits sollte das System überwachen, welche Aufgaben/Arbeiten zu erledigen sind, andererseits diese auch mit den notwendigen Details wie Arbeitszeit, Materialverbrauch, Erkenntnisse usw. dokumentieren. Für mich eine klare Sache: Vom Symptom oder der Aufgabe in mehreren, wohl dokumentierten Schritten. Ein absoluter Standardablauf wie er in jedem CRM/ERP-System tagtäglich mehrere Milliarden Mal auf der Welt gelebt wird.
Wichtiges Kennzeichen dieses Ablaufs ist die Orientierung an der Kostenrechnung – zu Beginn erstellt man einen Plan, in diesem sind geplante/abgeschätzte Werte zu finden. In der Dokumentation findet sich dann was tatsächlich passiert ist – und man erhält einen Einblick ob man gut geplant hat, oder ob man möglicherweise Korrekturbedarf hat.
Soweit die graue Theorie wie man sie aus der Hochschule bereits kennt oder auch in der Literatur des häufigeren findet. Die Realität ist leider etwas anders als man sich das vorstellt. Zum einen sind die Zusammenhänge oftmals nicht wie im Lehrbuch sondern etwas verzwickter. Klar, denn im Lehrbuch geht es um das Konzept im Ganzen, da sollen die Beispiele auf möglichst wenigen Seiten möglichst klar und gut verständlich sein. Die Ideen und Prinzipien dann zu erweitern ist für den Fachmann dann nur ein kleinerer Schritt in die entsprechende Richtung.
Richtig problematisch wird aber der Faktor, den man bis dahin als Techniker überhaupt nicht berücksichtigt hat – auch als Layer 8 oder HAF (human acceptance factor) genannt. Nun war ich eigentlich der Meinung (und habe das auch so vielfach erlebt) dass man es in der Geschäftswelt und bei den Vorgesetzten mit entsprechend fähigen (größtenteils ja sogar studierten) Menschen zu tun hat. Denen sollte eine gewisse Abstraktionsfähigkeit und die Fähigkeit logisch zu denken und strukturiert zu arbeiten doch eigentlich nicht fremd sein. Sicherlich, es gibt auch Studiengänge im künstlerischen Bereich, aber dieser Menschenschlag ist seltener in einem technisch ausgerichteten Unternehmen zu finden. Im konkreten Fall weiß ich sogar, dass es nicht zutrifft, sondern eine technische Ausbildung und ein Studium vorliegt.
Leider scheint logisches und strukturiertes Denken, Handeln und Arbeiten aber nicht mehr so recht in Mode zu sein – über viele Dinge macht man sich heute keine Gedanken mehr, weil man es nicht mehr muss – teilweise ist das von Vorteil (wer schleift heute noch ein papiernes Telefonbüchlein mit sich herum – im Handy ist doch alles gespeichert). Allerdings verleitet das Ganze auch an anderer Stelle zu einer gewissen Schludrigkeit, es ist ja eben alles on-the-fly möglich, das macht man dann halt irgendwie nebenher mit. Vorbereitung und Planung von Arbeiten ist heute nicht mehr en vogue oder es gibt im produzierenden Gewerbe mittlerweile Spezialisten die sich minutiös um die Gestaltung von Abläufen vorab kümmern und alle Möglichkeiten ausloten (z.B. bei der Optimierung der Arbeit am Band bei den Automobilherstellern). Im Service-Umfeld ist das meist etwas schwieriger zu leisten, aber auch hier kann man durchaus mit klaren Abläufen und sauber definierten Schnittstellen die Arbeit effektiver gestalten – immer unter der Bedingung, dass man das auch möchte. Denn eine vorgegebene Struktur (und in gewisser Weise macht eine Datenbank ja nicht anderes) verhindert oftmals das Arbeiten „nebenher“ – alles ist klar geregelt.
Besonders schwierig wird es, wenn bisher mit Excel-Listen oder Datenbanken „light“ (aka Access) gearbeitet wurde, in denen die Struktur nicht übermäßig wichtig war und die eben auch auf Veränderungen recht flexibel zu sprechen waren. Die Mitarbeiter sind es somit nicht (mehr?) gewohnt klar Angaben zu machen, es findet sich ja ohnehin irgendwie alles in einem großen Haufen, man muss nur ein wenig danach „wühlen“/“blättern“/“filtern“. Das diese Form der Datenerfassung nicht für automatisierte Datenauswertungen tauglich ist, liegt klar auf der Hand, zumindest für denjenigen der schon einmal aus der Form geratene Excel-Tabellen mit doppelt genutzten, gesplitteten und zusammengeführten Tabellen in der Hand hatte. Im Gegensatz dazu sind Datenbank-Tabellen definitiv „flach“ – die in Excel erzeugte Mehrdimensionalität wird in der Datenbank durch den Mechanismus der Fremdschlüssel abgebildet – eine 1:n Beziehung zweier unterschiedlicher Entitäten bedeutet immer auch den Einsatz von zwei Tabellen.
Aber bereits an der Unterscheidung von Objekten und den damit verknüpften Entitäten scheitert es oftmals – da werden ganze Pakete als ein „Datensatz“ bezeichnet, egal wie viele unterschiedliche Entitäten beteiligt sind (aus Benutzersicht vielleicht noch nachvollziehbar, aber nicht wenn man sich ein wenig detaillierter damit auseinander setzen will/muss: Die Identifikation von Abläufen und den daran beteiligten Artefakten ist nicht immer einfach, aber zur sauberen und maschinenlesbaren Aufbereitung ist sie leider unerlässlich.
Da es mir trotz mehrerer Anläufe nicht geglückt ist (es ist teilweise nicht einmal gewünscht sich auch nur etwas näher erklären zu lassen, da müsste man ja womöglich mitdenken und die graue Masse zwischen den Ohren mal wieder umquirlen) den Sinn und Zweck dieser Analysen und der strukturierten Vorgehensweise näher zu bringen, habe ich es jetzt erst mal aufgegeben – kein schönes Gefühl muss ich sagen, man fühlt sich vielmehr ins Mittelalter zurück versetzt: Der Chef als allmächtiger Papst, der über jegliche Analytik und naturwissenschaftliche Argumentation erhaben ist und sie nach Gutdünk sogar für „nicht zulässig“ erklären kann.
Mir persönlich ist nicht klar, wie man sich heute als Mensch mit einem technischen Hintergrund nicht auf eine logische Analyse (die wie beschrieben ja notwendig ist für das Ziel der automatischen Auswertung) einlassen will oder kann. Läuft da evtl. in der Bildung mit Laisez-Faire schon etwas falsch? Oder wird Mathematik und Logik in der Gesellschaft mittlerweile wieder als „böses Teufelszeug“ gesehen, vor dem man sich schützen muss – vielleicht weil es immer nur schlechte Noten gab/gibt?
Insgesamt bleibt mir nur die Frage des Artikels wie folgt zu beantworten: Logisches Denken und strukturiertes Arbeiten ist nicht gesundheitsschädlich – einzig das Erläutern und Näherbringen bei betonharten, festgefahreren Strukturen (das haben wir schon immer so gemacht) mit dem Ziel der Verbesserung kann derart nervenaufreibend sein, dass der damit verbundene Stress für den Logiker zum echten Problem werden kann.