> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2021/w03-digital-workflow.md).

# W03-Digitale Arbeitsabläufe

Bei der Planung für 2021 stellte Jerry mir kürzlich eine Frage: Wie messen wir, wie gut jemand das Geschäft versteht?

Mir fielen einige Blickwinkel ein. Auf der Ergebnisseite könnte man betrachten, wie gut die Architektur das Geschäft unterstützt, wie sinnvoll die technische Planung ist und wie viele Geschäftsprobleme durch Engineering verbessert wurden. Auf der Prozessseite könnte man die Lernzeit für die Geschäftsdomäne, die Beteiligung an Anforderungs- und Planungsdiskussionen oder Rückmeldungen anderer Funktionen betrachten. Offensichtlich ist keine dieser Dimensionen ausreichend SMART. Eine so abstrakte Fähigkeit in eine messbare Kennzahl zu übersetzen ist tatsächlich schwierig.

Dabei fiel mir ein merkwürdiger Widerspruch auf. Wir arbeiten an Digitalisierung, sind selbst aber nicht besonders digitalisiert. Ohne ausreichende Digitalisierung können wir nur schwer abstrahieren, standardisieren und damit skalieren. Es wird schwierig, die Arbeitsweisen hervorragender Mitarbeiter herauszuarbeiten und zu verbreiten oder Kompetenzmodelle für Fähigkeiten wie Geschäftsverständnis aufzubauen.

Aus Sicht der Organisationsführung sehen wir die Verteilung individueller Arbeitskraft derzeit nur anhand von Anforderungen. Für Tätigkeiten außerhalb von Anforderungen haben wir praktisch keine digitalen Daten.

Schon eine vollständige Anforderung durchläuft eine lange Kette grundlegender Schritte: Anforderungsreview, technischer Entwurf, Programmierung, Integrationstest, Code-Review, eigene Tests, Deployment der Umgebung, Canary-Release und Beobachtung in Produktion. Zu jedem Teil gibt es Daten. Sie sind aber nicht fein genug aufgelöst. Wir haben viele Ergebnisdaten und wenig Prozess- und Verhaltensdaten. Zudem sind die Daten zwischen den Schritten kaum verbunden. Bei Ones etwa werden die Zustände jeder Anforderung und Aufgabe von Hand geändert. Das wird immer wieder vergessen oder verspätet erledigt. Solche Daten liefern nur ein grobes Bild. Im Idealfall müssten wir als Nutzer ein Anforderungswerkzeug wie Ones in den meisten Situationen gar nicht bewusst bedienen.

Das lässt mich an Cloud IDEs denken. Früher verstand ich ihren Wert nicht recht. Aus Sicht einer Organisation ist er jedoch enorm. Ihr größter Wert liegt meiner Meinung nach im digitalen Arbeitsablauf. Die IDE gehört zu den meistgenutzten Werkzeugen der Entwicklung. Trotzdem nutzt jeder etwas anderes, und die dabei entstehenden Aktivitäten und Daten bleiben offline. Eine Cloud IDE könnte als Plattform viele vor- und nachgelagerte Vorgänge verbinden, etwa Branches unmittelbar mit Anforderungen verknüpfen, Tests mit einem Klick anstoßen oder Deployments auslösen. Schon einfache Grunddaten würden reichen, um Ones automatisch zu aktualisieren. Hinzu kommen Vorteile für Effizienz und Sicherheit, etwa einheitliche Entwicklungsumgebungen und der Schutz von Quellcode, der nicht auf Entwicklerfestplatten liegen muss.

Stellen wir uns die Zukunft vor: Aus einer Designvorlage entsteht per intelligenter Codegenerierung mit einem Klick weiterbearbeitbarer Code. Er wird in eine Cloud IDE übernommen, angepasst und mit einem Klick als plattformübergreifende Anwendung gebaut und bereitgestellt. Alle Daten und Arbeitsergebnisse liegen dann auf der Plattform. Jeder einzelne Schritt lässt sich mit umfangreichen Daten gezielt verbessern.