Ineffizienz im Projektalltag in sieben Akten

10 Minuten später widme ich mich wieder den Safety-Anforderungen. Und war genervt. Ich will Inhalte gestalten. Zur Elektromobilität der Zukunft beitragen. Ein Stück die Natur retten. Aber DOORS macht es unmöglich. Hier und jetzt. Für einfachste Navigation brauche ich die Maus. 3 Klicks braucht es, um die nächste Zelle zu aktivieren. Flow? Undenkbar. Wieso programmieren Hersteller immer wieder Excel-Oberflächen nach und hören auf halbem Wege auf? Leider kann ich Excel nicht verwenden. Der Safety-Assessor kanzelt sowas als »unprofessionell« ab und konstruiert den Super-GAU im Tool.

Während mich DOORS zum Prokastinieren zwingt, fällt mein Blick auf das Gemälde neben meinem Schreibtisch: Geschachtelte Rechtecke, punktuell mit Linien verbunden und vereinzelt schraffiert. Ich mache ein Foto und signiere es. Das schicke ich an Ralph, unserem Chief-Architekten. In der anstehenden Architektur-Session begrüßt er mich mit herzlichem Lachen. Mit Ralph geht sowas. Er ist genauso Pragmatiker wie erfahrener Haudegen.

Wir ergänzen und korrigieren meinen Entwurf samt Anforderungen. Abschließend einigen wir uns, wo ich das im Rhapsody einarbeite samt Schnittstellen, Datentypen, Traceability, und, und, und. Ralph verabschiedet mich mit einem Seitenhieb: »Vergiss net de teure Screenschots!«. Wir lachen und gehen unserer Wege. Aber er hat recht. Was am Whiteboard ein paar Minuten dauert, braucht im PowerPoint / Visio ca. eine Stunde und im Rhapsody mehrere. Mein Design wird kaum wertiger.

Im Gegenteil: Diese Modelle widersprechen dem, was gute System-Architektur leisten soll. Die Abstraktion ist miserabel. Im Rhapsody soll jedes Signal einzeln angelegt und definiert werden. Nur so kann der Modell-Checker auf Vollständigkeit und Konsistenz prüfen. Der ist übrigens seit Wochen defekt. Code generieren wir auch nicht. Und wenn ich Kunden und Kolleginnen die System-Architektur erkläre, ist dieses Modell unbrauchbar. Sichtweisen auf System-Architektur dienen vor allem der visuellen Kommunikation. Erschlagende Details behindern.

Abschließend mache ich Screenshots und lege sie im git ab. Die Tool-Lizenzen sind so teuer, dass sie handverlesen verteilt werden. In Summe der typische Fall von: In der Theorie klingt alles so schön logisch, praktisch ist es schlecht anwendbar.

Ein Review steht an. Anforderungen (DOORS) und Konzept (Rhapsody) sind gereift. Die FMEA (APIS IQ) ist vorbereitet. Ein Review-Ticket ist erstellt (Jira). Alles ist aufeinander verlinkt; möglichst mit Hyperlinks - falls jemand Namensgleichheit nicht kapieren will. Baselines sind auch gezogen (Tools & git).

Falls Sie sich fragen, wozu das Ganze: Automotive SPICE^® will es so. Das ist ein Prozessstandard, den interne und externe Berater als de facto Automotive Franchise[1] – Pardon: State-of-the-Art – definiert haben. Angeblich könnte jemand nachvollziehen wollen, welches Dokument, in welcher Version, wann und mit wem ein Review durchlaufen hatte. Das habe ich für ein Review in den letzten 10 Jahren zwar nie erlebt, aber was weiß ich schon. Zumindest hatte zuletzt der Auditor das als Befund rausgehauen. Die QM ist seither sensibilisiert. Ich glaube, er brauchte einfach irgendwelche Findings.

Ist doch nur Aufwand für ein einzelnes Review? Ja! In komplexen Projekten gibt es eine ganze Menge davon. Die Theorie...

Beim Umsetzen der Formalien beiße ich fast in die Tischkante. Die IT-Infrastruktur hat im VPN pro Klick fast eine 1s Latenzzeit. DOORS ist noch schlechter. Wie das nervt.

Hersteller, bitte nehmt eine Stoppuhr und stoppt die Dauer von Alltags-Szenarien. Die Software-Architekten des Vertrauens werden sicherlich nicht erwarten, dass wir im Nachbargebäude der Frankfurter Börse mit unseren Quantencomputern arbeiten und über eine exklusive Standleitung verfügen. Wir arbeiten über VPN und verfügen über eine beschissene Bandbreite, beschissenes WiFi, semi-beschissene Rechner und wir müssen uns durch mindestens 5 Ordnerebenen durchklicken, um eine Datei zu finden. Bei meinen indischen Kolleg/inn/en kann auch mal das Licht flackern.

Wenn wir jetzt noch zügig arbeiten können, dann taugt euer Tool für den Alltag.

Ein paar Tage später: Ich habe zum Kickoff des Fachreviews eingeladen. Unser Kreis besteht aus vier Fachexperten und einem unabhängigen Moderator. Eigentlich will ich meine Arbeit vorstellen, Feedback und Perspektiven sammeln. Heute aber läuft es zäh. Die Diskussion entfaltet sich nicht. Der Grund: Wir warten auf den Moderator. Er tippt UNTERIRDISCH langsam. Ralph ist nach 10 Minuten sichtlich so genervt, dass er übernimmt.

Überall will man Geld sparen und manche Leute können nicht richtig tippen. In den 2020er Jahren wohlgemerkt. Dabei ist Tippen für Wissensarbeiter eine der grundlegenden Tätigkeiten schlechthin (neben Denken und Kommunizieren).

Tippen ist eine muskulär-koordinative Tätigkeit. Wir können somit mit zwei Daumenregeln unseren Skill-Level bestimmen:

Ist die Bewegung 1) hübsch und 2) leise, sind wir wirklich gut darin.

Beim Laufen, Fechten, Yoga, Gewichtheben, Tanzen, Parkour und vermutlich allen anderen körperlichen Aktivitäten: Es muss hübsch sein und leise. Sieht es ästhetisch und elegant aus wie bei einer Prima Ballerina, ist ein/e Meister/in am Werk. Wer seine Finger aus 3cm Höhe auf die Tastatur krachen lässt, braucht vermutlich Training.

Dazu noch eine lästige Beobachtung: Programmierer und Entwicklerinnen sind Profis. Die IT aber malträtiert sie mit 10 Euro Tastaturen.

Gebt Entwicklern gescheite Tastaturen mit kurzem Tastenanschlag. Das holt mindestens 3%. Täglich. Pro Person. Bei jedem Absatz.

Unser Moderator tut sich auch mit Excel sehr schwer. In jede Zelle schreibt er entweder manuell das Datum und die Beteiligten oder er fuchtelt beim Copy-Paste wild mit der Maus rum als ob er mit ner Schlange kämpft.

Da wundert sich der Ungeduldige. Office gibt es seit Jahrzehnten und kostenlose Trainings obendrein.[2] Ferner ist ein Großteil unserer Arbeit repetitiv. 20% der Tool-Funktionen und Satzschnipsel machen mindestens 70% der EDV-Arbeit aus. Tastenkürzel beschleunigen den Alltag ungemein. Falls Tastenkürzel fehlen, leistet Auto Hot Key (AHK) exzellente Abhilfe.[3] Wenn man nicht weiß, wie man den Namen des Kollegen Krishnamacharya schreibt oder das Sonderzeichen in Łukaszek nicht findet oder die gleichen Satzschnipsel immer wieder schreibt, dann löst AHK das sauber auf:

Betriebswirte und Geisteswissenschaftler stöhnen, »Ich kann nicht programmieren!« Tut ihr auch nicht. Ihr definiert eine Regel, in einer Textdatei, nach definiertem Schema. Das kann jede/r.

Aus dem Review-Kickoff habe ich die Frage mitgenommen, wie wahrscheinlich mein angenommenes Worst-Case-Szenario eintritt. Mein Kunde hat eigens entwickelte Dashboards für die Historie der System-Performance aufgebaut. »Cooler Shit«, wie ich befinde. Das Problem aber:

Dashboards veranschaulichen nur, was in der Vergangenheit bereits als relevant entschieden wurde.

Ich erkunde gerade das Unbekannte, die ungestellten Fragen. Und das kann ich mit den verfügbaren Filtern (Design-Entscheidungen) nicht ermitteln. Der Function-Owner sperrt sich. Offensichtlich erkenne ich nicht, dass ja alles im Dashboard stünde! Also frage ich mich bis zur Entwicklerin durch. Sie erkennt das Problem. Wir tauschen anschließend ein verirrtes Safety-Ticket gegen eine CSV-Datei. Nach unserem Kuhhandel bin ich den Rest des Nachmittags mit dem Parsen der Daten und der Fehlerbehandlung von Sonderzeichen beschäftigt.

Mittlerweile habe ich die Daten verstanden und die richtigen Kategorien für meine Frage ermittelt. Trace-Marker sind definiert und in den Code geklopft. Jetzt will ich die Daten zerlegen und analysieren. Die Datenmenge aber zwingt Excel in die Knie und ich will die Analysen viele Releases wiederholen.

Ein Kollege hat für solche Analysen R-Skripte entwickelt, die zum Standardprozess gehören. Mir ist unbehaglich. In R fühle ich mich nicht zu Hause. Ich bin unsicher, ob ich die Skripte richtig bediene. Zunächst wäre ich damit beschäftigt, die Skripte zu verstehen, anstatt sie auf mein Problem zu reflektieren. Ralph befreit mich. Ich soll lieber mein eigenes Skript entwickeln. Also setze ich ein, womit ich mich sicher fühle: Python, numpy, pandas.

Lean-Berater/innen werden nun nervös(?). Skript-Wildwuchs sollte man vermeiden. Standardisierung bringt Effizienz. Für etablierte Geschäftsprozesse stimme ich zu. Beim Erkunden des Unbekannten gelten andere Regeln. Es geht um Erkenntnisvorgänge und um den Umgang mit Unsicherheit:

Ich habe ein Problem, das ich erst noch verstehen muss. Mir fehlt auch ein Werkzeug. Also erschaffe ich eins. Dadurch verstehe ich Problem, Lösung und Werkzeug besser. Das sind individuelle Erkenntnisvorgänge. Pauschales Standardisieren und Optimieren behindern diesen Vorgang.

Die Akte sind natürlich vereinfacht und überspitzt, aber real. Sie haben gemeinsam:

Unsere Erwartungen erzeugen Stilblüten der Ineffizienz

Beispiel Handskizze: Mir fallen viele Entwickler/innen ein, die das nicht akzeptieren. Die schließen unbewusst[4]

„nicht Standard-Tool“ ⇒ unprofessionell ⇒ schlechter Entwurf

Doch stimmt das? Wir betreiben sehr viel Aufwand, nur um die Erwartungen an die Professionalität zu erfüllen. Sprich: Damit uns die Kollegen und Kolleginnen als eine/n der ihren anerkennen.[5] Ähnlich beim Review. Mit den Baselines kann ich recht überzeugend demonstrieren, wie gründlich wir sind. Die Review-Baselines sind argumentativ motiviert. Sind sie inhaltlich wirklich nützlich?

Besonders heikel sind die Themen Tippen und EDV-Basics. Schließlich konfrontiere ich Ingenieure, Naturwissenschaftler, Mathematiker mit sowas banalem! Das eckt an Erwartungen an, auch bei Effizienz-getriebenen Managern. Trotzdem sind Tippen und EDV-Basics für fast alle Entwicklungs-Aktivitäten notwendig. Wieso ist das Thema anscheinend tabu?

Um daran etwas zu ändern, braucht es offenen Diskurs und Achtsamkeit.[6] Wir müssen Erwartungen offenlegen und prüfen, wie sie sich real auswirken. Re-Strukturierung wird daran nichts ändern. Diskurs ist Führungsaufgabe; nichts was Berater/innen leisten könnten.