#AnyTech

Die Domäne spielt kaum eine Rolle

Oft sehe oder erhalte ich Anfragen nach Tech-Experten, die Einschränkungen hinsichtlich der Fachlichkeit verlangen („Muss-Kriterien“). Entsprechende Anfragen, Ausschreibungen und Projekte erwarten explizit drei, vier oder fünf Jahre Erfahrung im Banken-, Versicherungs-, Energie- oder Industrieumfeld – oder in anderen Branchen. Da frage ich mich: Warum? Muss das wirklich sein, wenn es nicht um Raketenwissenschaften, Quantenphysik oder hochregulierte Bereiche geht? Und selbst da wäre ich skeptisch, denn auch das ist alles erlern- und verstehbar, wenn genügend gesunder Menschenverstand und kognitive Kapazität für Transferprozesse gegeben ist. Zumeist ist ohnehin ein Verständnis von den Zusammenhängen ausreichend und ein umfangreiches Detailwissen gar nicht nötig.

Immer wenn eine technische Lösung oder ein technisches Produkt im Sinne einer (Web-)Anwendung („App“) konzipiert, geschätzt, geplant, implementiert, getestet und geliefert werden soll, wird am Ende fast immer eine Software entwickelt, die Backend- und Frontend-Systeme berührt. Fast immer flankiert dies auch sogenannte CI/CD-Pipelines (DevOps), Datenhaltung mit (zumeist) Datenbanken und, je nach Anwendungsfall, auch flüchtige, kurzfristige Datenaustauschsysteme wie Message-Broker (Auflistung nicht komplett). Über diese Systeme werden dann pure technische oder fachlich-technische Entitäten verarbeitet. Da unterscheiden sich Projekte nicht voneinander.

Es bedarf immer einer Einarbeitung

Wenn Mitarbeitende (extern als Berater:innen oder intern als Festangestellt:e) neu in einem Projekt starten, ist eine Einarbeitung immer nötig. Die Fachlichkeit und die Prozesse des jeweiligen Auftrag- oder Arbeitgebers müssen erst einmal verstanden werden. Da ist eine vorherige Erfahrung in dem Umfeld hilfreich – zugegeben. Entsprechende Erfahrung verkürzt die Einarbeitungszeit. Die Frage ist dabei aber: Um wie viel? Und ist es im Sinne des Auftrag- oder Arbeitgebers, wegen weniger Tage erhöhten Einarbeitungsaufwands außergewöhnlich gute Engineers, Teams oder Mitarbeitende nicht einzustellen oder einzukaufen, sprich zu onboarden? Auch dann nicht, wenn sie sich durch jahrzehntelange Erfahrung bei der technischen Umsetzung auszeichnen und sich nachweislich in kürzester Zeit durch schnell gelieferte, ganzheitlichere Lösungen mit niedriger Fehlerquote „bezahlt“ machen?

Aus meiner persönlichen Erfahrung sowie der meiner Kolleg:innen, die wir in all den Jahren in diversen Firmen gesammelt haben, kann ich berichten: Das notwendige fachliche Verständnis, um technische Anwendungen im E-Commerce- und Retail-Bereich zu konzipieren, lässt sich genauso gut in einer Woche erlernen, wie im Immobilienbereich (PropTech), Finanzwesen (FinTech), Versicherungswesen (InsurTech), Energiebereich, Transport- und Logistikwesen. Wichtig ist: Diese Woche ist anstrengend. Sie muss vollgepackt sein mit einer fachlichen „Druckbetankung“ und Didaktik, ergänzt durch eine durchdachte Struktur mit Erläuterungen, Gründen und Zusammenhängen. Und das ist auch der Teil, den der oder die Kund:in als Auftrag- oder Arbeitgeber:in erfüllen und somit als zeitliches Investment einbringen muss.

Am Ende ist bei der technischen Umsetzung ein:e Makler:in, ein:e Mieter:in, ein:e Bank- oder Versicherungsberater:in, ein:e Zug- oder LKW-Fahrer:in eine Person mit Eigenschaften, die bestimmte Dinge erledigt und technisch repräsentiert und unterstützt wird. Ebenso sind Banken, Kraftwerke, Fahrzeuge oder Versicherungspolicen domänenspezifische Begriffe für technische Entitäten, die am Ende in einem technischen Produkt durch Namen, Eigenschaften und Aktionen miteinander in Verbindung stehen, ebenso wie technische Akteure in diesem Kontext bestimmte Aktionen tätigen. In dem allseits beliebten und generisch anwendbaren User-Story-Template wird das auch intuitiv greifbar:

Ich als <Entität>
möchte <Aktion> machen
damit ich ein <Ziel> erreichen kann.

Umsetzung

Die fachlichen Aktionen, die auf die Zielerreichung einzahlen, erfolgen technisch üblicherweise nach den CRUD-Prinzipien: Anlegen (Create), Lesen (Read), Aktualisieren/Verändern (Update) und Löschen (Delete). Techies nutzen diese User Stories dann, um eine technische Umsetzung zu gewährleisten. Am Ende werden die implementierten Lösungen hinsichtlich der definierten Akzeptanzkriterien getestet – jene Kriterien, die die konkrete Ausgestaltung definieren und somit die Grundlage darstellen, um die User Story als erfolgreich mehrwertstiftend abzuhaken. Im besten Fall als Teil der CI/CD-Pipeline als automatisierte Testsuite, die sowohl einzelne technische Feinheiten (Unit-Tests) sicherstellt als auch die ganze Lauffähigkeit des Systems (Integration-Tests). Gerne wird das Ganze noch um automatisierte Tests bezüglich der eigentlichen Anwendungsfälle erweitert, die sogenannten Acceptance-Tests. Je nach dem verwendeten technischen Umfeld kommen auch gerne sogenannte Contract-Tests vor, die üblicherweise auf die Funktionsfähigkeit von Schnittstellen abstellen. Alles Themen, die keinerlei oder so gut wie keinen fachlichen Bezug haben oder Fachlichkeit verlangen.

Strukturiertes und systemisches Denken

Im Kern dreht sich Software-Entwicklung um das Umsetzen und Möglichmachen fachlicher Spezifikationen unter Zuhilfenahme erprobter Verfahren, Programmiersprachen, Frameworks, Konzepte, Algorithmen und gesunden Menschenverstands. Oder anders formuliert: es geht um strukturiertes, systemisches Denken und den Einsatz bewährter Vorgehensmodelle. Bei der technischen Umsetzung einer Lösung spielt es de facto keine Rolle, welche Struktur und Logik hinter einer fachlichen Entität steckt, die in Form von technischen Repräsentationen (heutzutage meistens JSON, früher auch XML oder serialisierte Objekte) in Datenbanken gespeichert, im Browser in welcher Form auch immer angezeigt, im Backend nach den CRUD-Prinzipien verarbeitet und in Nachrichten oder Ereignissen in einem Message-Broker verwendet wird. Es ist daher auch für den Techie nicht wichtig, jahrelange Erfahrung in einer fachlichen Domäne zu haben, um eine hervorragende technische Implementierung zu liefern. Am Ende bleibt ein Datenbankeintrag eines Mieters mit seinen Mietzahlungen, eine Überweisung im Finanzwesen oder eine Zugverbindung im Transportwesen ein Datenbankeintrag. Ein Formular mit Kosten und Einnahmen zu Mietzahlungen oder Kosten für eine LKW-Fracht bleibt am Ende ein Formular mit Kosten und Einnahmen. Und so weiter…

Natürlich ist es wichtig, dass die fachlichen Details verifiziert, hinterfragt, geprüft und in verständliche Anwendungsfälle greifbar heruntergebrochen werden. Und natürlich ist es auch wichtig zu entscheiden, welche technische Lösung dem Anwendungsfall unter Berücksichtigung einer großen Unternehmensstrategie, einer Meilensteinplanung, eines Budgets, einer gewünschten Resilienz oder Wartbarkeit dienlich ist. Hierzu bedarf es aber einer produktverantwortlichen Person – dem oder der Product Owner:in. Im besten Fall als langjährige:r Mitarbeiter:in des Kunden (Auftrag- oder Arbeitgeber).

Für diese Person ist es durchaus hilfreich, wenn umfassendes, fachliches Domänenwissen existiert, das bestenfalls über einige Jahre gewachsen ist. Das hilft ihr, das große Ganze besser einzuordnen, Prioritäten im Sinne des Auftraggebers zu beurteilen und potenziell strategische Entscheidungen in der Produktentwicklung einfließen zu lassen. Am Ende hilft dies auch den Software Engineers, denn während der Software-Entwicklung werden Fragen, Unwägbarkeiten und Unklarheiten auftauchen, die durch die produktverantwortliche Person den Techies greifbar gemacht werden. Und es hilft dieser Person, die gelieferte Software vor dem Hintergrund der definierten Spezifikationen zu testen, um die fachlich korrekte Umsetzung abzusegnen.

Fazit

In der Technik läuft es darauf hinaus, dass technische Entitäten lediglich andere Namen tragen, die Aktionen, die sie ausführen, wiederum je nach Fachlichkeit andere Entitäten modulieren, moderieren oder verändern und somit die Anzeige für den oder die Anwender:in (Frontend) beeinflussen. Dabei müssen dann wahlweise die Informationen und Daten aus den oben genannten beispielhaften Formularen in Backend-Systemen validiert, gespeichert und an Drittsysteme weitergereicht werden. Dabei ist es völlig egal, ob es sich bei den Zahlen um Mietzahlungen, Überweisungen, Reinigungskosten, Ladungsgewichte bei LKWs, Streckenkilometer auf der Schiene oder einfach um die Rechnung des externen Service-Dienstleisters für Software-Entwicklung handelt.

Mein Appell

Achtet bei der Personalauswahl weniger auf vorhandene fachliche Expertise und mehr auf das technische Wissen. Und noch mehr auf die Teamchemie und das richtige Mindset der Brainworkers. Es geht teilweise um die Erfahrung mit Programmiersprachen, Frameworks und anzubindenden Systemen. Wobei ich selbst das gewissermaßen einschränken möchte, denn als erfahrener, intelligenter Software Engineer lernt man nach der zweiten oder dritten Programmiersprache oder Framework auch die vierte oder fünfte innerhalb kürzester Zeit. Es geht um das analytische Denken, das strukturierte Arbeiten, das Verständnis und die Konzepte hinter einer Programmiersprache. Dazu aber in einem anderen Post mehr, wenn ich darauf eingehe, dass Erfahrung mit unterschiedlichen Frameworks und Programmiersprachen nur eine untergeordnete Rolle spielen – sicherlich aber eine höhere als die notwendige, hier thematisierte fachliche Erfahrung.

Schlussendlich geht es immer um das richtige Mindset des Brainworkers, die Offenheit, Neues zu lernen, und die kognitiven Fähigkeiten für Transferprozesse. Es geht darum, Herausforderungen mit einer strukturierten, technischen Denkweise pragmatisch und nachhaltig zu lösen. Es geht darum, zu abstrahieren und erfahrungsbasiert zu lernen.

Schlussbemerkung

Meine vorherigen Ausführungen und Perspektiven in diesem Post möchte ich vor dem Hintergrund folgender Prämisse verstanden wissen: Ich schrieb über intelligente, erfahrene und motivierte Menschen. Ihre Erfahrung erstreckt sich über viele Jahre, in denen sie komplexe Sachverhalte verstanden und Herausforderungen in verschiedenen Branchen und Themen erdacht, konzipiert und umgesetzt haben. Es geht um Menschen, die ein inhärentes Interesse hegen, Mehrwerte zu generieren, sich beständig weiterzuentwickeln und Neues zu lernen, um dieses Wissen auf neue Themen anzuwenden und somit ganzheitlich Lösungen zu denken. Dabei geht es mir insbesondere um informationstechnische Lösungen in verschiedenen Bereichen.