Die gescheiterte Kommodifizierung technischer Arbeit
(ludic.mataroa.blog)- Die Erwartungen von Management und Anbietern sind groß, technische Arbeit wie in einer Fabrik zu standardisieren und daraus reproduzierbare Ergebnisse zu machen, doch viele Umgebungen lassen sich auf diese Weise noch nicht zuverlässig als Ware standardisieren
- Der Betrieb nach McDonald's-Art beruht weniger auf der Qualität des Produkts selbst als auf der Disziplin, mit der unterschiedliche Standorte und Mitarbeitende das gleiche Ergebnis liefern; auch mehrere Managementbücher betrachten IT-Betrieb als solchen Produktionsfluss
- Der Verkauf von Enterprise-Software kommt oft dem Versprechen gleich, SQL-, Daten- und Entwicklungsarbeit durch Drag-and-drop und konsistente Oberflächen zu ersetzen, sodass Personal austauschbar wird
- In realen Organisationen lösen schlechte Softwarelizenzen und falsche Abstraktionen technische Probleme nicht; am Ende müssen oft hervorragende Engineers schlechte Datenmodelle und technische Entscheidungen direkt korrigieren
- Arbeit, die Kreativität, Geschmack, Expertise und menschliche Verbindungen erfordert, lässt sich nicht vollständig auf Jira-Boards oder Agile-Punkte reduzieren; selbst in großer Produktionsinfrastruktur bewegen einzelne Menschen die Systeme
Was McDonald's über die Schwierigkeit der Standardisierung zeigt
- Der erste Manager, ein herausragender Data Engineer, war jemand, der sich intensiv mit Kochen beschäftigte, und würdigte mehrfach die Komplexität des McDonald's-Betriebs
- Der Wert von McDonald's liegt weniger in der Qualität des Ergebnisses selbst als in der Optimierung und Disziplin, mit der Mitarbeitende mit unterschiedlichem Bildungsniveau und aus unterschiedlichen Regionen denselben Burger herstellen
- Ungelernte Arbeitskräfte an verschiedenen Standorten dazu zu bringen, ein konstantes Ergebnis zu liefern, ist nicht einfach; dieses Beispiel führt zur Diskussion über die Kommodifizierung technischer Arbeit
Managementbücher behandeln IT wie eine Fabrik
- The Phoenix Project stellt IT-Betrieb als ein Problem dar, das der Arbeit in einer Fertigungsfabrik ähnelt, und rückt Arbeitsflüsse und Kommunikationsmanagement innerhalb der Organisation in den Mittelpunkt
- Bücher mit ähnlicher Haltung sind The Unicorn Project, Investments Unlimited und The Goal
- The Goal erzählt davon, wie tatsächlicher Fabrikbetrieb verändert wird, und gilt als ein Werk, das die anderen Bücher inspiriert hat
- Auch High Output Management erklärt Arbeitsflüsse am Beispiel von Abläufen in einem Restaurant: Werden Eier zum falschen Zeitpunkt gekocht, ist der Toast kalt, wenn er beim Kunden ankommt
- In dieser Denkrichtung tauchen Themen wie Skaleneffekte, Durchsatz und Arbeitsfluss immer wieder auf
Im Kern des Vendor-Pitchs geht es weniger um Technik als um Austauschbarkeit
- Mehrere Produkt-Pitches auf einer Vendor-Konferenz konzentrierten sich weniger auf technische Details als auf das Versprechen, hinreichend gute Arbeitsergebnisse reproduzierbar zu liefern
- Ein bestimmtes Produkt warb damit, Abhängigkeiten per Drag-and-drop-Editor konfigurieren zu können, ohne direkt SQL zu schreiben
- Tatsächlich verbindet sich die Anwendung mit Postgres; SQL verschwindet also nicht, sondern eine lizenzierte Abstraktionsschicht schreibt SQL an seiner Stelle
- Für Führungskräfte kann ein solcher Pitch wie die Botschaft klingen, „langsames, problembehaftetes SQL“ durch eine konsistente Oberfläche und Tool-Experten aus dem Markt zu ersetzen und so die Datenbereitstellung innerhalb der Organisation reibungsloser zu machen
- Auch die Art, wie Agile in durchschnittlich dysfunktionalen Organisationen umgesetzt wird, zeigt ein ähnliches Problem
- Engineers werden als Maschinen, Ergebnisse als Bauteile und Story Points als Produktionseinheiten gezählt; anschließend wird geprüft, ob die Ziele der nächsten Woche erreicht wurden
Warum viele technische Arbeit noch nicht kommodifiziert wurde
- McDonald's liefert meist innerhalb von fünf Minuten Pommes frites in gleichbleibender Qualität, doch viele Tech-Organisationen kaufen schlechte Softwarelizenzen, ohne etwas Wertvolles auszuliefern
- Der Weg, technische Probleme und schlechte Datenmodelle mit Geld zu lösen, besteht eher darin, hervorragende Engineers zu gewinnen, die sich ganz auf Problemlösung konzentrieren
- Es gibt viele Bereiche, in denen Kommodifizierung möglich erscheint, tatsächlich handelt es sich aber oft um eine Kombination aus Unternehmen, die nicht funktionierende Produkte verkaufen, und unwissenden Entscheidern, die sie kaufen
- Manche Entscheider nutzen im Namen der rechtlichen Compliance Telefonsupport in Niedriglohnregionen und wählen auch Ansätze, bei denen Kunden, die kündigen wollen, keine Beachtung finden
- Es wird auch die Erfahrung beschrieben, beim Bedarf an Support zuerst die Sales-Hotline anzurufen, um zu versuchen, schnell mit einer befugten lokalen Ansprechperson verbunden zu werden
Bei kreativer technischer Arbeit bleibt der menschliche Faktor bestehen
- Rich Hickeys Hammock Driven Development behandelt einen Arbeitsfluss, bei dem man Recherche ins Unterbewusstsein einspeist, meditiert, schläft und so zu Designlösungen gelangt
- Programmierer erleben häufig, dass ihnen Antworten einfallen, wenn sie Abstand vom Problem haben; das unterscheidet sich davon, einfach schneller Widgets auszustoßen
- In der Gesellschaft gibt es viel Arbeit der Art, Dinge schneller auszustoßen, doch viele wertvolle Ergebnisse entstehen dort, wo schwer definierbare Kreativität auf die Realität der Produktion trifft
- Auch bei Beispielen wie Büchern, Essen oder Restaurantbetrieb lassen sich Massenproduktion oder Lieferketten verfeinern, doch schöne Ergebnisse erfordern Geschmack und Sorgfalt
- Selbst wenn man Feature-Entwicklung auf Jira-Boards und Agile-Storys reduzieren will, ist es schwer, wertvolle Ergebnisse zu erzielen, wenn keine Verbindung zu Menschen besteht
- Wie im Beispiel eines Bekannten, der Chips für das iPhone entwirft, können einzelne Menschen eine entscheidende Rolle spielen: Trotz Test- und Massenproduktionsinfrastruktur kann sich das nächste Release verzögern, wenn eine bestimmte Person krank wird
- Zwar beruht die Gesellschaft in der Praxis auf Kommodifizierung, doch technische Arbeit lässt sich nicht allein durch reine Kommodifizierung betreiben, die das Verständnis für ein bestimmtes Handwerk sowie die Komplexität, Bedürfnisse und Verletzlichkeit von Menschen ignoriert
1 Kommentare
Kommentare auf Hacker News
Ich glaube, der Autor übersieht, dass ein erheblicher Teil dessen, was früher als technische Arbeit galt, inzwischen allgemein zur Ware geworden ist.
Früher bedeutete Serienbrief tatsächlich, massenhaft Adressetiketten auszudrucken und sie von Hand auf Briefe und Umschläge zu kleben; ungefähr Word 2.0 löste dieses Problem in den 1990ern, und MailChimp hat es im 21. Jahrhundert produktisiert.
Auch die doppelte Buchführung war einmal technische Arbeit für hochqualifizierte Leute, aber heute scannt der Ladenbesitzer einen Barcode, und der Kunde bezahlt per Tap-to-Pay.
Es gibt noch kein Drag-and-drop-Interface, das für etwas Komplexeres als Scratch taugt, aber der schwierige Teil ist nicht die technische Arbeit, Libraries zusammenzustecken, sondern die Anforderungserhebung.
Eine hochwertige Kryptografie-Library einzubinden, eine interaktive Karte auf eine Website zu bringen oder eine Website per WYSIWYG zu bearbeiten, ist einfacher denn je.
Der Autor hat recht, insofern man keinen gelangweilten 18-Jährigen vor eine IDE setzen und ihn ein ERP bauen lassen kann; aber viele Kleinarbeiten in der IT sind inzwischen eindeutig zur Ware geworden.
Ich denke, in der Tech-Industrie nimmt die Kleinarbeit eher zu als ab: Es gibt derzeit X an Kleinarbeit, eine neue Technologie Z kommt heraus und reduziert X auf 0,1X, ermöglicht aber zugleich neue Arbeitsweisen und erzeugt als Nebenprodukt weitere Kleinarbeit. Dann liegt die aktuelle Kleinarbeit bei Y, und Y ist ungefähr wieder nahe an X.
Wenn der technologische Fortschritt in den 2000ern stehen geblieben wäre, wäre die aus den 90ern stammende Kleinarbeit heute fast bei 0; neue Technologien bringen aber Automatisierung und Kleinarbeit gemeinsam mit.
Ein aktuelles Beispiel sind KI-Tools. Es gibt Tools zum Erzeugen von Audio, Bildern, Video und Text, aber um differenzierte Produkte oder Erfahrungen zu schaffen, braucht es Kleinarbeit, die Tools wie ChatGPT und Stable Diffusion miteinander zu kombinieren.
Je stärker man kommodifiziert, desto höherdimensionaler werden die Probleme, und die spezialisierten Engineers, die man einstellt, wandern weiter nach oben im Stack.
Unter den jüngst zu SaaS gewordenen Startup-Produkten scheint ein hoher Anteil noch nicht wirklich das zu tun, was man möchte. Das Muster ist: Man bringt Leute dazu, für den Service zu zahlen, sammelt dann die Use Cases der Kunden als Implementierungsziele und versucht, sie für andere Kunden zu produktisieren; dadurch werden Lead Times länger, und geistiges Eigentum sickert durch.
SQL-Templating ist etwas, das Führungskräfte ständig missverstehen. SQL hat in der Branche erstaunlich lange überlebt und ist tatsächlich ziemlich gut. 99 % der Wrapper oder DSLs, die man daraufsetzt, machen es deutlich schlechter, und alles, was auch nur ein wenig nicht trivial ist, muss am Ende wieder auf SQL herunter. Statt SQL-Experten einzustellen, landet man in der Situation, Experten für irgendeinen gar nicht existierenden SaaS-DSL-SQL-Wrapper X heranziehen zu müssen.
Das Grundproblem könnte sein, dass solche Produkte so gestaltet werden, dass sie für Käufer, die nicht in dem jeweiligen Bereich arbeiten, wie ein Haushaltsgerät wirken, das man kauft, einsteckt und damit ist das Problem gelöst.
Viele Produkte lösen das Problem in Wirklichkeit nicht; sie sehen nur so aus, als würden sie es lösen, weil andere sie kaufen. Und man kann nur befördert werden, wenn man lügt und behauptet, die Implementierung sei erfolgreich gewesen. Dinge wie Serienbriefe sind wirklich bereits gelöste Probleme wie ein Wasserkocher; solche Probleme kann man durch eigenes Ausprobieren lösen.
Das größere Problem ist, dass mein Arbeitgeber Workday gekauft hat, weil er es für etwas wie einen Wasserkocher hielt, aber es konnte nicht beheben, dass unsere Organisationsstruktur so furchtbar ist, dass sie sich überhaupt nicht modellieren lässt.
Dieses Jahr habe ich zum ersten Mal begriffen, dass eine hinreichend schlechte Organisationsstruktur in einem Großunternehmen eine Art technische Schuld ist. Man tut alle möglichen seltsamen Dinge, um herauszufinden, wer für wen arbeitet und was dieser Nutzer in dieser Datenbank sehen darf.
Wie viel einfacher ist es heute im Vergleich zu 1994 oder 2004, ein Geschäft zu betreiben, eine Website zu bauen, eine Reise zu planen oder Rechnungen zu bezahlen?
Manchmal fühlt es sich so an, als hätten frühere Generationen ein gemächlicheres Lebenstempo gehabt und dadurch ein erfüllteres Leben geführt. Heute vergeht die Zeit viel zu schnell, und der Stress ist hoch.
Vor kurzem habe ich in einer Bank mindestens drei Menschen über 60 gesehen, die einfache Dinge nicht erledigen konnten, ratlos waren und Mitarbeitende um Hilfe baten. Es waren Dinge, die per Online-Banking leicht möglich sein sollten, aber wegen Ausnahmefällen vom System nicht unterstützt wurden; am Ende mussten sie einen Termin vereinbaren, und der früheste Termin lag drei bis vier Monate später.
Einer von ihnen musste Geld von einem gesperrten Konto abheben, um Brennholz zu kaufen und sein Haus zu heizen, aber der Bankmitarbeiter sagte nur, er solle drei Monate warten.
Vor zwei Jahren fand mein Vater in Sizilien keine Möglichkeit, einen einfachen Anruf nach Hause zu tätigen. In den 1970ern hätte man einfach in die nächste Bar gehen und ein paar Münzen einwerfen können.
Früher konnten normale Leute üblicherweise Dinge wie eine Lampe, ein Auto, die Heizung oder eine nicht automatische Tür selbst reparieren; heute muss man einen Experten rufen.
Der Versuch, technische Arbeit vollständig zur Commodity zu machen, ist eine schlechte Idee, und ich hoffe, dass er auch künftig scheitert.
Allerdings habe ich The Phoenix Project zweimal gelesen und mag den größten Teil von Scrum nicht, sehe aber nicht, dass dieses Buch so etwas behauptet.
Die Kernaussage, die ich daraus mitgenommen habe, ist: ein klares System dafür zu haben, wiederholbare Arbeit auszuführen und zu verwalten; dort zu automatisieren, wo es möglich ist; laufende Arbeit zu reduzieren, damit Menschen nicht an zahllose Aufgaben gebunden sind; Informationen breit zu teilen und mehreren Teammitgliedern zu ermöglichen, dieselbe Arbeit zu erledigen; sicherzustellen, dass man tatsächlich das tut, was das Business braucht; und Lärm sowie ungeplante Arbeit zu reduzieren, damit Mitarbeitende statt durch einen chaotischen Sumpf zu waten hochwertige Arbeit tun können, die ihnen Freude macht.
Der Kern von The Phoenix Project besteht nicht darin, Menschen zu austauschbaren Automaten zu machen, sondern Systeme zu schaffen, die ihnen Freiraum und Zeit geben, die wirklich wertvolle Arbeit zu tun, die sich nicht automatisieren oder systematisieren lässt.
Ich habe eine Fabrik betrieben und war auch Entwickler, daher kenne ich beide Seiten: Entwickler zu Arbeitskräften einer Produktionsfabrik zu machen, ergibt keinen Sinn, aber Arbeit, die wie Fabrikarbeit aussieht – bekannte Aufgaben und wiederholbare Schritte –, sollte ähnlich behandelt werden.
s/manufacturing/IT/gdarauf anzuwenden und es mit modernen Referenzen zu aktualisieren.Das heißt nicht, dass ich das Buch nicht mag. Ich habe es halbwegs gelesen und versucht, Teams dazu zu bringen, es zu lesen, um ihr Denken stärker auf Systeme auszurichten. Aber ich würde nicht sagen, dass es sehr viel tiefer oder einsichtsvoller ist als The Goal.
Ich habe mich zwar über den Stil lustig gemacht, aber es war tatsächlich lesenswert. Viele Dinge, die Menschen bei bekannten Aufgaben oder wiederholbaren Schritten falsch machen, kann man nicht dem Denken im Stil von Phoenix Project anlasten.
Beim Programmieren kommt es allerdings selten vor, dass man bekannte Aufgaben als wiederholbare Schritte ausführt. Wenn das doch passiert, liegt es oft daran, dass im Stakeholder-Management ein taktischer Fehler gemacht wurde und keine Zeit mehr blieb, es zu automatisieren.
Eine sorgfältige Lektüre führt zu Schlussfolgerungen wie im letzten Absatz, aber ich weiß mit Sicherheit, dass die meisten Manager, denen ich begegne, den Unterschied zwischen Widget-Produktion und Systemdesign nicht verstehen.
Kontinuierliches Lernen, Automatisierung und Instrumentierung sind die Werkzeuge, die die Punkte 1–5 oben ermöglichen.
Ich habe aus The Phoenix Project nicht die Botschaft herausgelesen: „Arbeite härter, um mehr Dinge schneller zu erledigen.“
https://scrumguides.org/scrum-guide.html
Grauenhaft ist normalerweise der ganze Kram, den Leute daraufpacken und Scrum nennen. Der beste Weg, schlechtem Scrum entgegenzutreten, war nicht zu kämpfen, sondern so zu tun, als sei man der eigentlichen Lehre puristisch treu ergeben. Man wirkt dadurch weniger rebellisch und kann leichter Einfluss nehmen.
Der Titel hat mich verwirrt. Bedeutet „commodify“ nicht „verkaufbar machen“, also kommerzialisieren? Hat die Technologie nicht bereits Milliarden Dollar eingebracht?
Was der Autor meint, scheint eher commoditization zu sein, also technische Arbeit zu einer allgemeinen Tätigkeit zu machen, die jeder austauschbare Mitarbeiter erledigen kann.
Laut https://en.wikipedia.org/wiki/Commoditization lässt sich commoditization so zusammenfassen, dass etwas Proprietäres zu einem Allgemeingut wird, während commodification bedeutet, dass etwas, das nicht verkäuflich war, verkäuflich wird.
Bin ich da übermäßig kleinlich? Ich dachte, die beiden Begriffe hätten unterschiedliche Bedeutungen.
Nachtrag: Ein Blick ins Wiktionary zeigt, dass https://en.wiktionary.org/wiki/commodification sagt, dass sie auch austauschbar verwendet werden. Offenbar ist es einfach eine häufige Verwechslung.
https://www.merriam-webster.com/dictionary/commodify
Es bedeutet „etwas, etwa einen intrinsischen Wert oder ein Kunstwerk, in eine Ware verwandeln“, also geht es bei commodify eher um commoditization.
Öl ist eine Commodity, weil es viele Produzenten gibt und alle dasselbe herstellen, sodass es egal ist, von wem man kauft.
In der McDonald’s-Analogie ist der Entwickler nicht der Teenager, der vor der Maschine arbeitet, sondern der Ingenieur, der die Maschine entworfen hat. In dieser Analogie ist der Computer der Teenager.
Programmieren ist keine Arbeit, sondern Meta-Arbeit. Sobald ich einmal eine Liste von Anweisungen erstellt habe, führt der Computer diese Arbeit rund um die Uhr aus, und ich gehe los, um eine neue Anweisungsliste für eine andere Aufgabe zu schreiben.
Wenn man dieselbe Anweisungsliste zweimal schreibt, macht man im Grunde etwas falsch. Deshalb macht man ständig neue Dinge, und weil man dieselbe Sache nicht zweimal tut, ist schwer abzuschätzen, wie lange es dauern wird.
IT ist keine Fabrik, sondern die Arbeit, Fabriken zu bauen.
Viele Konflikte zwischen Entwicklern und Managern entstehen meiner Ansicht nach daraus, dass das Wort „Manager“ viel zu pauschal verwendet wird. Ein McDonald’s-Manager beaufsichtigt, ob die Mitarbeiter dem Prozess folgen, mit dem das Produkt hergestellt wird. Ob der Prozess befolgt wird, ist klar; der Prozess wird als gültig vorausgesetzt; und ob kein Ergebnis herausgekommen ist, ist ebenfalls klar.
Programmierer hingegen werden dafür eingestellt, den Prozess zu entwickeln, dem die Maschine folgen soll. Auch für die Person, die diese Mitarbeiter verwaltet, kann es einen Prozess geben, dem die Programmierer folgen sollen, und ob sie ihn befolgen, mag klar sein. Aber ob dieser Prozess gültig ist, ob eine bestimmte Handlung zu einem festgelegten Ergebnis führt und ob das Ergebnis selbst klar definiert ist, bleibt unsicher.
Trotzdem werden beide Rollen „Manager“ genannt.
In dieser Maschinenanalogie ist der Programmierer nicht jemand, der Menschen managt, sondern ein anderer Typ von Manager, der Maschinen dirigiert. Nur werden diese Maschinen in die Welt entlassen, und der Programmierer überwacht sie nicht ständig.
Natürlich besteht, wie in anderen Kommentaren erwähnt, die Möglichkeit, dass dieses Konzept kompletter Unsinn ist. Aber selbst wenn ich in ein paar Jahren merke, dass das eine dumme Idee war, ist es immerhin besser, jemanden zu haben, der sich gemeinsam mit mir schämen kann, statt allein peinlich berührt zu sein.
Vor etwa zehn Jahren waren ein paar Freunde von mir, Maschinenbauingenieure, überrascht, als sie hörten, dass ich Softwareentwicklung studiere.
Sie sagten Dinge wie: „Gibt es da überhaupt noch viel zu tun? Lässt sich nicht alles, was man braucht, mit bestehenden Systemen erledigen?“
Das Missverständnis besteht in der Vorstellung, dass das Bauen von Systemen zur Lösung neuer Probleme einfach und bereits zur Ware gemacht sei und man deshalb keinen Code mehr schreiben müsse.
In der Realität ist der Aufbau von Software nur selten so einfach wie das Konfigurieren einer UI. Man braucht Text, um logische Regeln und Abläufe auszudrücken, Versionsverwaltung, um Änderungen am System nachzuverfolgen und zurückzurollen, und am Ende braucht man Programmierer.
Coding verschwindet nicht; nur das Abstraktionsniveau steigt.
Die Tech-Branche versucht seit Langem, Entwickler zur austauschbaren Ware zu machen, und COBOL oder Java standen meiner Ansicht nach ebenfalls in dieser Linie.
Aber egal, was man abstrahiert, es gibt wesentliche Eigenschaften, die wieder zum Vorschein kommen. Selbst wenn Anforderungen einfach aussehen und es High-Level-Frameworks gibt, funktioniert ein großer Teil unserer Software immer noch nicht richtig.
Wie der Autor sagt, ist die eigentliche Lösung ein fähiger Entwickler, dem es nicht egal ist. Daraus kann man eine Karriere machen.
Wenn man lange im selben Bereich arbeitet, wiederholen sich Muster zwar ähnlich, aber die jeweiligen Business-Anforderungen unterscheiden sich immer ein wenig. Auf jeder Schicht des Stacks werden diese Unterschiede größer, und insgesamt entsteht enorm viel nicht kommodifizierte, maßgeschneiderte Arbeit.
Deshalb sind zwei Produkte nicht exakt gleich, und deshalb gibt es nicht ein einziges riesiges globales Unternehmen, das alles produziert.
Ich habe unzählige Male gesehen, wie Entwickler begeistert reagieren, wenn sich ihnen eine Gelegenheit zur Selbstkommodifizierung bietet, bei der sie sich selbst nach tayloristischen Prinzipien zerlegen.
Das Gesundheitswesen ist mein Gegenbeispiel, wenn Diskussionen über automatische Kommodifizierung aufkommen. Emotional hat das zwei Anziehungspunkte. Patienten mögen es nicht, von Arzt zu Arzt weitergereicht zu werden. Sie verstehen, dass Kommodifizierung mit einem gewissen Maß an zunehmender Spezialisierung einhergeht und dass jede zusätzliche Übergabe einen weiteren möglichen Fehlerpunkt schafft.
Der zweite Punkt ist, dass sich Status und Arbeitsweise als höherer Status ausgeben lassen. Wenn man den ersten Punkt in den Vordergrund stellt und den zweiten als Subtext mitschwingen lässt, funktioniert das meistens gut. Beschäftigte behalten allgemeinere Fähigkeiten und verlassen sich eher darauf, einander zu konsultieren, statt Dinge per Übergabe weiterzureichen.
Ein Fließband ist Spezialisierung in festgelegter Reihenfolge; man muss sich nur die Übergabefehler im Zusammenhang mit den Arbeitszeiten von Assistenzärzten ansehen.
Betrieb, Innovation, Wartung. Man kann beliebige drei von diesen drei wählen.
Es ist besser, wenn dasselbe Team oder sehr eng beieinanderliegende Teams sie übernehmen.
Idealerweise sollte jede Person im Team alle drei Funktionen in unterschiedlichem Ausmaß ausführen. Denn daraus entsteht die Inspiration für Verbesserungen.
Man kann diese drei Funktionen auch auf drei Gruppen und drei Managementebenen aufteilen, aber das Ergebnis ist meist mittelmäßig und die Menschen werden unglücklich. Besonders diejenigen, die im Wartungsteam feststecken, leisten undankbare, aber zentrale Arbeit.
Man kann ein Team auch für alle drei Funktionen verantwortlich machen, stellt aber oft Manager ein, die auf genau eine davon überangepasst sind. Zufällig ist genau diese eine Funktion dann die, die im nächsten Quartal zu besserer Vergütung führt.
Operative Exzellenz, gewissenhafte Wartung und Zeit für gründliches Nachdenken innerhalb einer einzigen Kultur gleichzeitig zu vertreten, ist schwer. Es ist ganz normal, dass das schwer ist.
Betrachtet man die Rolle Business Intelligence/Analyst, versucht die Branche, Menschen, die SQL verwenden, durch Menschen zu ersetzen, die Tools wie Tableau verwenden.
Nach dem Motto: „Einfach mit irgendeinem Datenspeicher verbinden, dann können nichttechnische Mitarbeiter per Drag-and-drop arbeiten.“
Es gibt dabei mehrere Probleme. Erstens wird vergessen, dass der Output nur linear wächst und man deshalb mehr niedrig bezahlte Arbeitskräfte einstellen muss. Da alles UI-basierte Arbeit ist, muss ein Mensch die Kurbel von Hand drehen.
Zweitens entsteht weiterhin sehr komplexer, unaufgeräumter Transformationscode für Business-Logik, nur ist er jetzt in der UI vergraben. Die einzigen, die wissen, was diese Logik ist, sind PMs oder Business-Teams.
Die Engineering-Organisation stellt recht primitive, aber hochwertige und getestete Datensätze bereit, um Business-Fragen zu beantworten. Der schwierige Teil war, das Problem zu lösen, auf merkwürdige Weise aus Quelldaten Business-Ergebnisse zu gewinnen.
Jetzt wird diese Lösung in einer Tableau-Workbook gespeichert und kann nicht als Input für anderes verwendet werden. Man muss sie in der UI in eine neue Tableau-Workbook kopieren und einfügen.
Da man den Tableau-Cloud-Service gekauft hat, kann das BI-Team SQL-Extrakte zwar strenger gestalten und pflegen. Tableau wirkt, als wolle es einen Teil des Databricks-Geschäfts übernehmen, aber diese Arbeit machen nun Nicht-Engineering-Teams. Ob das gutgehen wird, weiß ich nicht.
Ein typisches Beispiel ist: „Aus welchem Land kommen unsere Nutzer?“ Geht es um das Land, das sie im Registrierungsformular angegeben haben, das Land, aus dem sie derzeit auf den Dienst zugreifen, das Land des Zahlungsmittels, ihr Geburtsland, das Land ihrer Staatsbürgerschaft, ihr aktuelles Wohnsitzland, die Lieferadresse oder die Rechnungsadresse? Das ist jeweils etwas anderes.
Wenn der Datensatz groß genug ist, ergeben sich jeweils unterschiedliche Antworten. Im Bereich „globales Fintech“ werden solche merkwürdigen Fälle zur Normalität werden.
Der typische niedrig bezahlte Tableau-Nutzer wird wahrscheinlich den sichtbaren Ländercode suchen, ein count darauf ausführen und das dann zur Wahrheit erklären.
Ein etwas klügerer Tableau-Nutzer wird einen Engineer bitten, SQL zu schreiben.
Man braucht jemanden, der den Datensatz und die Quellsysteme kennt, um dem Business Gegenfragen zu stellen und die richtige Frage samt Kontext einzufordern.
Tools der Tableau-Art sind gut darin, „technische Arbeit“ zu ersetzen, bei der man jeden Tag dieselbe SQL-Query in pgAdmin einfügt und eine CSV per E-Mail verschickt. Aber sie bringen UI-zentrierte, gering qualifizierte Arbeitskräfte nicht dazu, besser nachzudenken.
Lineare Skalierung des Outputs im Verhältnis zu den Kosten lässt sich in Tabellenkalkulationen modellieren und an Kunden weitergeben oder abrechnen. Alle in der Business-Schicht fühlen sich mit dieser Dynamik wohl.
Dagegen sorgt eine Situation, in der ein dedizierter Experte mit wenig Aufwand den 1000-fachen Output erzeugen kann, man aber nicht sicher ist, ob es einen Tag oder eine Woche dauert, bei allen für Unsicherheit und macht Führungskräfte nervös. Wenn alle bequeme Mittelmäßigkeit wollen, ist das schwer zu verkaufen.
Punkt 2 erfordert ironischerweise mehr Experten, nur eben Experten anderer Art. Denn all diese Logik muss gewartet werden.
Am Ende läuft es wie ein Beschäftigungsprogramm und wird teurer, aber es wird den politisch einflussreichen Fürstentümern proportional Wert zuweisen und deshalb erfolgreich sein.
Zuerst entlässt man alle Backend-Leute mit der Begründung, sie verstünden das Business nicht, und macht Tableau zum neuen Backend. Dass die Backend-Leute Business-Anforderungen aufgenommen und verfeinert haben, wird ignoriert.
Wenn sich die Business-Leute später in dem chaotischen Spinnennetz verfangen, das sie selbst gebaut haben, ruft man Tableau-Berater, die Geld absaugen, ohne irgendetwas Wertvolles zu schaffen.
Ich komme aus dem Bauingenieurwesen, genauer aus der Tragwerksplanung, und Software wirkt auf mich eher wie Stadtplanung als wie andere Ingenieurdisziplinen.
Sie ist einfach zu umfassend. Es ist nicht überraschend, dass im Lauf der Zeit immer mehr Rollen entstanden sind, die bestimmte Arbeitstypen beschreiben, etwa Backend-, Frontend-, Firmware- und Machine-Learning-Engineers, Data Scientists, Security-Analysten oder Kernel-Entwickler.
Wenn sich Standards weiterentwickeln, könnte es meiner Ansicht nach irgendwann sehr spezifische Zertifizierungen erfordern, um in solchen Positionen zu arbeiten. Vielleicht nimmt es auch eine andere Form an, aber der Kristallisierungseffekt ist klar zu erkennen.
Software als Fabrik zu denken, kann ebenfalls möglich und nützlich sein. Aber nicht alles passt in diese Analogie. Etwa wenn man an Produktintegration denkt oder daran, dass etwas ein Service ist und keine App.
Eine Fabrik impliziert, dass etwas hergestellt wird, doch in vielen Fällen ist Software nicht das Endergebnis, sondern selbst das Mittel, das etwas ermöglicht.
In der Software wurde der größte Teil der Arbeit asymptotisch automatisiert. Deshalb vergisst man, dass diese Arbeit einmal Arbeit war.
Man denke nur an simples Kopieren von Dateien. Gewissermaßen ein „automatischer Kopist“.
Das Kopieren ist so weit automatisiert, dass die enorme Menge an Kopiervorgängen, die unsere Systeme ausführen, unsichtbar geworden ist, und es ist auch als Punkt wirtschaftlicher Differenzierung verschwunden.
Außerdem ist es auch auf der Metaebene nützlich. Das Kopierprogramm selbst lässt sich mit demselben Algorithmus leicht kopieren.
Der Punkt ist, dass man beim Schreiben von Software, ähnlich wie in der Mathematik, immer Zeit an der Grenze zwischen Bekanntem und Unbekanntem verbringt. Denn jeder vollständig bekannte und charakterisierte Bereich wird auf eine Weise automatisiert, die das Problem für alle löst und zugleich den wirtschaftlichen Boden dieser Tätigkeit verbrennt.
Softwarearbeit enthält in jedem Bereich immer ein Element der Erkundung, also der Forschung: Man betritt unbekanntes Terrain, um Reichtum zu finden. Egal ob dieses neue Gebiet glorreich oder auf tragische Weise banal ist.
Bereiche, die ein Manager ohne Software-Expertise automatisch erledigen kann, sind wie Obstbäume, die so domestiziert wurden, dass man leicht Früchte pflücken kann. Nur tragen solche Bäume keine Früchte mehr.
Wenn die Problemdefinition dieses Managers nicht wieder in schwer zu automatisierende Bereiche aufsteigt, die lästige Kreativität und Expertise erfordern, macht er keine differenzierte oder wertvolle Arbeit mehr.