Transcript: Projektmanagement - "es ist alles nicht so einfach"

Ja, hallo, liebe Hörerinnen und Hörer, willkommen beim Python-Podcast, Folge 22.

Wir machen heute Projektmanagement, vielleicht auch ein bisschen mit Python.

Und spannenderweise ist genau diese Folge die Folge, die bis jetzt am wenigsten funktioniert hat.

Und wir versuchen seit September diese Folge aufzunehmen und hatten schon mehrere Termine, die dann wieder geplatzt sind.

Und dann haben wir schon mal eine Folge aufgenommen, die total nicht funktioniert hat.

Und jetzt fangen wir wieder von vorne an. Also Projektmanagement ist eine tricky Sache.

Wir sind wieder beim Jochen im Wintergarten.

Hallo Jochen. Und Remot. Und Remot dabei. Heute wieder zwei unserer Stargäste. Und zwar der Christian und der Johannes. Hi. Hallo. Hallo. Ja. Vielleicht noch ein bisschen vorher am Anfang ein paar News aus der Szene einstreuen? Ja, können wir eigentlich mal mit anfangen. Genau. Ja. Was gibt's denn Neues? Der Christian hatte was Spannendes, glaube ich.

Ich hatte eingeworfen,

wart ihr eigentlich nicht beim Python-Camp dabei?

Ich habe gerade überlegt, was du gesagt hattest.

Genau, da hatte ich das vorgestellt,

weil ihr sagtet, dass

das PIP-Env gerade einen Release

bekommen hat, zum Thema

wie man so Anwendungen paketiert,

beziehungsweise ganze Anwendungen irgendwo

ausrollt mit dem Virtual-Env. Da habe ich

tatsächlich Anfang des Jahres oder vor

so zwei, drei Monaten, als Corona

gerade losging, selber was

gebaut, das nennt sich App-Env,

womit man dann mit einer Requirements-Text-Datei

oder einem Freeze-File in der Lage ist,

so Self-Contained, Self-Bootstrapping-Anwendungen zu bauen,

die man aber auch auf beliebige andere Python-Pakete

einfach draufjagen kann.

Genau, das war so ein kleines interessantes Werkzeug

für Leute, die in dem großen Potpourri aus

Wie kann man noch Virtual Envs?

Environment.

Genau, da reinwerfen.

Eine der wenigen Möglichkeiten, Virtual Envs zu machen.

Ja, genau.

Ja, was sind eure Lieblingssachen?

Also das ist tatsächlich auch dein Lieblingsweg, da Env zu machen?

App Env?

Halt immer für dieses

Thema von, ich will die

in der Form vorliegen haben, um in

Projekten, wo ich mich mit anderen koordinieren

muss und wir das

nicht so global auf dem System installieren

wollen, ist es bei App Env

so, dass du so eine kleine Bootstrap

Datei unter dem Namen,

wie du diese Anwendung in dem Projekt benutzt,

in dein Repository mit eincheckst,

sodass jeder andere, der dieses Projekt auscheckt,

einfach nur .slash

in unserem Fall ist das Bateau, das

Deployment-Werkzeug, aber das kann halt irgendwas anderes sein,

was dann in einem Virtual-End als Executable

lebt, aufgerufen wird und

er sich automatisch darum kümmert, dass jeder

die richtige Version und alle Dependencies

etc. bekommt. Und wenn du

halt manchmal im Team mit 20, 30 Projekten

arbeitest, die alle unterschiedliche Versionen haben

und aber dann eins wurde dann doch wieder aktualisiert,

dann ist das halt eine schöne Variante,

um zu machen, dass niemand

sich darum kümmern muss, wenn er

mit dem Ding interagiert, ob das jetzt gerade

aktualisiert wurde oder nicht. Insofern

das passt uns sehr, sehr gut.

Ja, okay.

Für eine Entwicklung nehme ich es aber nicht. Also wenn

ich Projekte entwickle, dann mache ich meistens einfach

wirklich bloß ein ganz dummes

Virtual-Env in einem

ausgecheckten Repo rein. Ich mache gerne

viele, tausend Virtual-Envs

überall rechts und links.

Ich activate die auch nicht,

sondern ich rufe die dann immer mit den absoluten Faden

aus dem Projekt raus auf.

Okay.

Ich habe mich so ein bisschen in das, was Jochen mir gezeigt hat, Poetry verliebt.

Das fand ich irgendwie auch ganz nett.

Ja, also ich benutze meistens Poetry.

Und das ist halt auch, also in den Projekten, ich habe es noch nicht alles umgestellt,

aber in denen, in denen ich das getan habe, war es dann halt auch so, dass es relativ einfach ist.

Immer wenn ich jetzt da irgendwie was ändere oder so, mache ich gleich ein Poetry-Update

und sozusagen habe dann auch immer aktualisierte Fassungen,

Während das bei dem Ansatz, den ich früher hatte mit Virtual Envys

immer so ein bisschen hakelig war.

Da muss man sich erst raussuchen, welche sind denn outdated

und kann man die jetzt upgraden oder nicht.

Aber Poetry Update einmal testdurchlaufen lassen,

reicht eigentlich immer.

Und das funktioniert tatsächlich auch für mich ziemlich gut.

Was mich so ein bisschen nervt,

ist, dass es teilweise sehr, sehr lange braucht,

bis die Dependencies aufgelöst sind.

Ich weiß nicht so genau, woran das liegt.

Aber was halt da interessant ist,

es jetzt gab tatsächlich

eine neue PIP-Env-Release

irgendwie, das

ja

und da sind einige interessante

Geschichten dazugekommen, das heißt also momentan könnte man sich

das nochmal angucken und

vielleicht wäre jetzt nochmal ein guter Zeitpunkt, das mit Poetry

zu vergleichen, weil Poetry

habe ich eigentlich nur deswegen genommen

und dann halt auch vorgeschlagen, weil

das halt aktiv

entwickelt wurde und PIP-Env sah so ein bisschen

danach aus, als wäre

die Entwicklung da im Wesentlichen schon passiert und

das liegt halt so rum, aber

tut irgendwie nichts mehr und das

hat sich wohl geändert. Also insofern

sollte man sich das vielleicht nochmal angucken, aber habe ich jetzt auch noch

nicht gemacht, insofern kann ich dazu nichts sagen.

Ja, bei Pip-Inf stand halt so ein bisschen

raus, dass es da auch mal wieder so einen

Übergang gab von, ich glaube,

war das Kenneth Rates, der das

Original entwickelt hatte und

er dann halt aber es auch in einer

Form hatte, wo er sagte, ganz fertig ist es noch

nicht und dann der Übergang zu

die PIPA-Leute haben gesagt,

wir würden sie im Prinzip jetzt übernehmen,

aber diese Arten von Transitionen sind halt

mit Kenneth manchmal so ein bisschen holperig.

Ich merke auch gerade, ich habe gerade...

Der Kenneth ist auch so

einer, der gerne Projekte anfängt, oder?

Der macht ganz viele Sachen

erstmal und die...

Ja, da gibt es ganz viele Sachen,

die er mal angefangen hat, um es mal so zu sagen.

Es ist keine Kritik oder so, sondern es ist einfach

was, um die Überleitung hinzukriegen.

Ja, die Überleitung hätte fassen müssen,

wenn wir keine News mehr gehabt hätten.

erfolgreiche Projekte werden

auch irgendwann beendet und so.

Was unterscheidet denn irgendwie

so ein Stück Software von einem Projekt?

Ja, das ist eine interessante Frage.

Ja, was ist das eigentlich?

Sobald er Dominik seine News hat, müssen wir da mal drüber sprechen.

Ja, ja.

Ja, ja, natürlich.

Ja, jetzt

breake ich hier wieder einfach so rein und mache trotzdem

wieder News. Und zwar gab es

einen Blog-Eintrag von Cal Patterson, der

geschrieben hat, dass Async Python

nicht faster ist und da ein paar Benchmarks gemacht hat.

War ganz interessant, wenn wir mal in die Shownotes linken.

Oh ja, da gab es dann

auf Twitter, habe ich nur gesehen, dass das irgendwie

Leute, die darauf reagiert haben und dann geschrieben haben,

war das doch alles Unsinn. Aber ich weiß nicht mehr genau,

warum oder wer oder das

renne ich mich auch nur so halb dran.

Ja, ja.

Schneller als Asunge

ist die Aussage von diesem Blogpost.

Ja, aber für was?

Ich kann ja einen Benchmark

schreiben, der beliebige Ergebnisse hat.

Gute

Frage, für was?

Er hat die verschiedenen Web-Server getestet

und verschiedene Loads, je nachdem, wie viel Work kann

und wie viel Throughput das irgendwie generiert.

Also was ich

einfach mal ein bisschen mitzumeinen,

was ich dann auf Twitter gelesen habe, ist, dass

die Leute ihm vorgeworfen haben, dass er halt eigentlich

nur Postgres getestet hat,

weil da war halt irgendwann

Schluss und

ja, er hat halt irgendwie

gar nicht wirklich Async getestet

und das wäre halt irgendwie nicht okay

gewesen, der Benchmark. Aber

ich habe es mir auch selber nicht angeguckt, insofern kann ich das

nicht sagen, aber das ist auf jeden Fall eine interessante Geschichte. Ich würde auch

sagen, also was sie, ich meine, das ist halt

ein schwieriges Thema. Leute wissen nicht

so genau, was sie meinen, wenn sie denn sagen,

Async ist schneller. Also

insofern, ich meine,

ich würde auch sagen, also wenn man Async irgendwie

macht, hat das natürlich einen gewissen Overhead.

Also wenn man jetzt einfach nur

ein Programm hat, das irgendwie durchläuft,

dann ist das in der Sync-Fassung immer ein kleines

bisschen schneller als in der Async-Fassung.

Aber wenn man jetzt irgendwie,

keine Ahnung, viele Requests gleichzeitig beantworten

will oder so, oder dann

kann das natürlich mit Async deutlich schneller sein.

Es kommt halt immer darauf an, was man macht.

Also was man misst, also misst man die Zeit

von, es fängt an,

zu bearbeiten, bis der Request ist

fertig bearbeitet oder wie viele

Requests pro Sekunde gehen da durch oder so.

Was misst man da eigentlich?

Wichtiger

finde ich eigentlich eher, es geht ja darum, dass das

ein anderes Programmierparadigma ist,

in dem man bestimmte komplexe

Abläufe halt zuverlässiger

aufschreiben können soll.

Also

du hast halt manchmal das Problem, dass du

irgendeine Form von Parallelisierung brauchst, Parallelisierung

Richtung I.O., Parallelisierung

im Balancing, wer irgendwie

Compute-Zeit kriegt und

Async ist ja

tatsächlich halt, heißt ja erstmal Async I.O.

Und

da halt Patterns zu haben, die dann zum Beispiel

eben schneller und skalierbarer auf irgendwie

viele Endpoints reagieren können,

das sind ja die Themen, wo dann im Linux oder bei

anderen halt das Thema

SelectPol, E-Pol, etc.

kommen, um zu gucken, wie viel

CPU-Overhead muss eigentlich nachher draufgehen,

um diese ganzen ausstehenden Ressourcen zu verwalten,

damit dann irgendwann wieder aus der

Kernel-CPU-Zeit

in die User-CPU-Zeit

gewechselt werden kann, um zu sagen, ah, ich hab ja jetzt,

du kannst jetzt wieder richtige Arbeit machen, ich stehe jetzt

nicht bloß da und dreh Däumchen, um rauszufinden,

wo was erreicht wurde. Und das kannst du mit

Threads natürlich auch machen, hast aber

da dann wiederum halt das Problem, dass das ganz

schnell in Locking-Probleme und Koordinationsprobleme

und gesharete Datenstrukturen

und Async hat halt dort den Vorteil,

du kannst es leichter aufschreiben, weil die Punkte,

wann die Kontrollflüsse unterbrochen

werden, besser kontrollierbar sind.

Weil du halt weißt, immer nur wenn ich Yield

oder wenn ich die Methode verlasse, die

Co-Routine verlasse, dann gibt es diese Kontextwechsel,

das heißt, du brauchst an vielen Stellen bei geteilten Datenstrukturen

keine Logs, etc., etc., etc.

Das ist halt...

Ah, okay, aber das ist interessant. Ja, nee, das finde ich

völlig valide und

ich meine, ich würde jetzt sagen, mit Splats kann man das

ja auch irgendwie, sozusagen, dann nimmt man halt eine

Queue und Logs, gut, ja, eben, stimmt,

braucht man also eben nicht machen. Genau, Logs hat man,

Genau, so, Logs haben halt das Problem, das sind Kerneldatenstrukturen,

die du fürs Logging halt brauchst und die haben halt

Overhead und das ist halt blöd und wenn du die gar nicht mehr brauchst,

zack, geht das halt weg.

Deswegen ist eher die Frage, wie

verhält sich Async.io gegenüber

Threads und für mich die wichtigere Kombination

ist aber, dass du halt Fehlerquellen

eliminierst. Das Dumme

ist halt, Async ist jetzt auch nicht perfekt

und es programmiert sich manchmal auch

ein bisschen komisch, das ist halt so diese Rot-Blau,

das Rot-Blau-Problem,

dass es dann halt plötzlich in dein

Python-Code hat halt dann

eine rote und eine blaue Variante, nämlich

die Funktionen, die Sync sind

und die Funktionen, die Async sind und die

darfst du nicht durcheinander bringen.

Die dürfen sich auch nicht gegenseitig aufrufen,

das ist auch eine super coole Sache.

Ja genau, da musst du immer so eine Übergabe

Punkte machen und das ist tatsächlich so ein bisschen, na,

es geht noch fluffiger.

Es geht noch optimaler.

Ja, alles Async ist die Lösung jetzt gerade.

Das ist furchtbar.

Also ich mache das tatsächlich

eher so, dass ich dann immer mal so Code-Zweige habe,

wo ich sage, so jetzt muss ich parallel was machen, jetzt hole ich mal

für diesen Subcall-Tree

Async raus,

dann kommt dieser ganze Kram in Async und

danach geht's wieder zurück.

Ja, finde ich

sehr interessant, weil ich hätte jetzt so spontan gesagt,

wenn mich jemand gefragt hätte, was der

Unterschied, oder wo ich den Unterschied sehen würde zwischen

Threads und Async, dann würde ich auch sagen,

ja, so Threads ist halt, im Grunde macht das genau das

Gleiche, es ist beides Multiplexen von

I.O.

irgendwie Parallelität und

aber Threads

gehen halt nur beschränkt viele, weil

naja, das sind halt auch wieder

Kerneldatenstrukturen und du hast halt pro

Thread irgendwie ein gewisses Maß, was man

da dann halt irgendwie

anlegen muss und wenn man dann halt nach ein paar

Hundert, paar Tausend, ist dann halt irgendwie

einfach Schluss, während ich mit Async.io halt

auch, weiß ich nicht,

halbe Millionen offene Verbindungen

gleichzeitig haben kann.

Weiß ich nicht, ob man es wirklich haben kann, aber so theoretisch

könnte es sein, dass es geht und

ja,

das ist

halt auch quasi vergleichbar schnell.

Insofern kann man

dann für solche Sachen, wo man ganz viele

Verbindungen hat, dann halt irgendwie Async.io näher nehmen

als Threads, aber ansonsten, ja.

Und Threads sind halt hässlich zu debuggen, aber das ist

Async.io möglicherweise halt auch

irgendwie, da habe ich jetzt noch gar nicht so viel Erfahrung mit.

Ja, die Antwort ist

ja. Also da gibt es halt auch,

ich meine, es gibt ja andere Sprachwelten,

halt gerade JavaScript,

Node.js, JavaScript hat von der Sprache

halt her schon ein besseres

Execution-Modell,

was die Vorhersagbarkeit

angeht, wann du die Kontrolle über

die Ausführung verlierst.

Bei Python Threading kannst du halt bei jedem

Bytecode

Statement

kann es halt sein, dass die Kontrolle

wechselt. Und dann weißt du halt teilweise

noch nicht mal, ob die eine Zeile, die gerade ausgeführt wird,

komplett durchkommt. Oder ob du

zum Beispiel beim Assignment

rechts die Expression noch ausgeführt kriegst,

dann kommt irgendein anderer Thread und beim

Assignment of the Target

hat sich schon irgendwas geändert

und bei Async

und bei JavaScript ist es halt eben so, du weißt

erst, wenn du den Execution-Block über

einen Yield oder über einen

Coroutine-Call oder halt den Call

verlassen, erst wenn du den verlässt,

dann geht die Kontrolle weg und so lange kannst du

darauf verlassen, dass niemand in diese

Liste reingeschrieben hat, niemand irgendwie

Dinge getan hat und

das reduziert den Denkaufwand

schon nochmal ganz schön massiv.

Was man häufiger machen muss, ist man

muss, glaube ich, den Code nochmal

anders strukturieren, dass er irgendwie lesbar ist,

um ihn für Menschen wieder serialisiert

durchgucken zu können.

Das ist auch das, was man halt kennt

in der Python-Welt dann wieder von dem

Twisted. Das Zeug heißt halt nicht

umsonst so. Das Twisted-Modell ist sehr, sehr nah

an dem dran, was AsyncIO im Prinzip

macht, mit so Promises und

so einem Zeug. Und am Ende hast

du halt für etwas, was du seriell Sync

einfach nur A, B, C, D, E

runterschreiben würdest, plötzlich 40

Funktionen gefühlt, die sich

alle gegenseitig mit irgendwelchen Promises und Callbacks

und wenn der den aber mit Error-Händler

da drüben und wenn der Error-Händler von dem aufgibt

und da blickt man halt sehr schnell nicht mehr

durch. Da halt eine Balance zu finden,

da müssen sich jetzt alle auch erstmal irgendwie dran gewöhnen.

Das gibt es in JavaScript jetzt übrigens auch.

Die haben jetzt auch Promises. Also man kann auch in JavaScript

jetzt... Ja, und mag jemand vielleicht mal ganz kurz

erklären, was eine Promise denn überhaupt ist?

Weiß nicht, ob das jetzt supergut

in die Projektmanagement-Folge reinpasst.

Ja, vielleicht noch ganz kurz, da wäre es gerade so...

Eine Promise ist eine

Berechnung, die

zu einem späteren Zeitpunkt erst fertig

werden kann. Das heißt, anstatt dass ich sage,

das Ergebnis ist 5,

sage ich, ich verspreche dir, dass wenn du

das Ergebnis abrufen willst, dann mache ich es auch fertig.

Das heißt, das Promise

ist so eine Verpackung

für irgendwann wird ein Ergebnis hier sein

und die Garantie, dass das

Ergebnis vorhanden ist, ist erst da,

wenn das Promise abgerufen wird und die

Hoffnung ist halt, dass man in der

Zwischenzeit so genügend andere Dinge

gemacht hat, dass das Promise quasi in Nullzeit

berechnet werden kann.

Weil zwischendurch immer mal wieder

eine von den asynchronen

Co-Routinen daran arbeitet, dass das ein bisschen weiter

verpackt wird.

Das ist auch ein allgemeiner Punkt,

was man von Threads kennt. Also Threads kannst du halt

ja auch sagen,

du kannst halt zwei Varianten benutzen.

Du kannst halt entweder sagen, du machst dir ein Threadpool,

wo eine Funktion immer wieder irgendwas

abruft und verarbeitet und

dein Thread läuft unendlich lange oder du startest

bestimmte Funktionen mit Parametern in einem Thread

und kannst den dann joinen.

Das heißt,

in deinem Hauptprogramm kannst du irgendwie sieben

Dinge anfangen, kriegst dann

die Thread-Objekte und kannst am Ende sagen, so

join, join, join, join und das Join wird in deinem

Hauptthread wieder

returnen, in dem Moment, wo

der Thread sagt, so, ich hab mich beendet.

Und eine Future oder halt eine Promise

ist im Prinzip die Abstraktion davon,

dass du irgendwelche Calls hast, die dir so

ein Future-Objekt liefern

und dann hast du auf dem Ding halt

eine verallgemeinerte

Möglichkeit, um zu sagen, also

übrigens, falls das schief gehen sollte, hier ist noch

ein Callback, der bitte aufgerufen werden sollte, wenn das

schief gehen sollte. Hier ist noch ein Callback,

der aufgerufen werden sollte, wenn es erfolgreich ist

und sag mal, wie geht es dir eigentlich gerade?

Das ist sozusagen diese Verallgemeinerung von

diesen Patterns von, ich lasse irgendwas asynchron

ausführen und will dann irgendwann sagen, so

jetzt hätte ich es gerne, jetzt warte ich

darauf, dass du fertig wirst.

Okay. Man kann aber auch

in JavaScript inzwischen

irgendwie async-await-Syntax,

die praktisch genauso aussieht,

wie in Python verwenden.

Insofern. Aber da

kommt es dann sehr darauf an, welche

Bibliothek-Welt man gerade lebt, ob die

Parasys macht oder Futures oder Await

oder Threads oder

Timer oder Callbacks.

Ja, ja. Und was man halt tatsächlich

dann nicht vergessen darf, ich erlebe das immer

wieder, wenn ich Projekte habe, wo Node.js eine Rolle spielt,

man muss in den async-Sachen

dieses ganze Thema

Kontrollflusssteuerung mit Exceptions

ganz anders anzuhaben und

mein Liebling, der mir bei Node immer

auffällt und das passiert immer in Python aber halt

auch, ist, wenn dann irgendwelche

Datenbankbibliotheken,

Datenbanken angesprochen werden und der Datenbank-Server

geht mal kurz weg und du kriegst dann halt

mittendrin irgendeine Exception von, ja,

hier war die Connection weg und

niemand hat im Framework ordentlich Händler

für diese Exceptions registriert,

dann sitzt dein, weil dein Hauptthread

macht später nichts anderes mehr

als nur diesen Loop von, ja, gibt's

ja noch Async-Dinge zu tun. Ja, dann husch, husch, husch.

Ah, hier sind wieder neue. Husch, husch, husch.

Und der beendet sich aber nie.

Und wenn aber dann halt sozusagen die ganzen

Libraries alle mal gestorben sind

und nur noch sagen, ja, ich konnte mich ja nicht connecten

und mein Connection-Pool ist weg und

keiner behandelt diese Exceptions,

dann sitzt dein Programm da rum,

tut so, als wenn alles okay wäre und

das Monitoring sagt, läuft doch.

Husch, husch.

Wir haben heute erstaunlich wenig Last

auf unseren Redner. Ja, genau. Aber tatsächlich

häufig ist es so, der Webserver in dem Ding

antwortet dann für irgendwelche Statusseiten immer noch,

ja, ich bin anwesend, dass aber die

realen Requests alle auf die Schnauze fliegen und

er zu doof ist, sich zu reconnecten

und das ist was, das hättest du

in einem seriellen Ding

oder einem Synchronen Ding eher weniger, da würde

diese Exception normalerweise bis in den Main

Loop durchbubbeln

und dann explodieren

und dann geht die Anwendung aus,

wird neu gestartet, kann sich zu Datenmark reconnecten

und dann ist alles gut. Das sind sozusagen Sachen,

da hat man jetzt sozusagen Probleme, die eigentlich

schon mal auf eine andere Art gelöst waren.

die hat man sich jetzt nochmal eingefangen, die muss man jetzt mit

ordentlichem Handwerkszeug neu machen,

aber ordentliches Handwerkszeug, ich will jetzt nicht

zu sehr über die

Kryptwelt herzählen.

Aber das ist ja in Python genauso, also ich meine, die Sachen

könnten ja auch in Python abspringen,

aber da kann man jetzt vielleicht nochmal

einen Übersprung, außer der Dominik

hat mal mehr News, kann man nochmal versuchen,

zu Projektmanagement zu kommen,

weil dieses ordentliche

Handwerkszeug ist ja durchaus was, was man

versucht, über Projektmanagement in den Griff zu kriegen.

Ja, dass man halt sagt, okay,

bevor jemand irgendwas hier

in den Masterbranch pushen darf,

müssen alle Tests gelaufen sein oder irgendwie

sowas, dass du halt das über

quasi Prozesse in den Griff kriegst, die nicht

in der Software drin sind, sondern in den Menschen.

Jetzt könnte ich dazu ja

gerade mal so die,

auf meinem Stichwortzettel für heute,

die, ich wollte so diese Antithese

gerade, ich wollte mit dem bösen

Onkel spielen, aber ich fürchte,

ich bin zu nah an dem dran, was du gerade

tatsächlich auch sagen wolltest.

Also ich beobachte Projektmanagement in den letzten Jahren häufig als eine Art Form von industrialisierte, weaponized Möglichkeit, um Entwickler möglichst zügig in einem Zwei-Wochen-Rhythmus durch eine Ticketliste zu prügeln.

Da bist du aber tatsächlich mit, ja, ja, und wenn man die...

Würdest du sagen, es funktioniert, oder würdest du sagen, es funktioniert nicht?

Das funktioniert halt in den Fällen, wo die Leute nichts Neues machen müssen, sondern halt tatsächlich einfach bloß das Zeug abarbeiten, was sie immer machen.

Ja, aber da würde ich sagen,

das ist natürlich dann eigentlich...

Da brauchst du auch kein Projektmanagement.

Genau, aber ja.

Das ist eigentlich nur Bearbeiten von Tickets,

dann schätze ich da hin und Ticket, Ticket, Ticket, Ticket, Ticket, Ticket, Ticket, Ticket, Ticket.

Das ist ja auch eine Art von Projektmanagement.

Die Priorisierung dann, welches Ticket du nimmst

oder machst du die Reihenfolge nach

oder wann die aufgenommen, für's DIN, für's A oder...

Was ist denn ein Projektmanagement?

Vielleicht fangen wir da nochmal ganz von vorne mit an.

Was ist ein Projekt?

Da haben wir uns doch letztes Mal schon drüber gestritten.

Ja, das letzte Mal haben wir aber wieder weggeschmissen,

das musst du nochmal...

einfach nochmal die gleichen Personen über das gleiche Ding

und hoffen, dass es jetzt mal anders ausgeht.

Dass wir heute was anderes sagen.

Also ich kenne die Definition von Projekt

so, dass es ein Vorhaben ist, was

zeitlich begrenzt ist und ein

genau definiertes Ziel hat.

Das heißt,

Projekt wäre irgendwas, genau,

ganz harte Regeln.

Beziehungsweise genau definiertes Ziel

kann ja auch sein, wir wollen besser werden. Das ist ja auch

ein genau definiertes Ziel.

Das Wichtige ist wirklich, es muss einen zeitlich festgelegten Rahmen haben. Das heißt, es muss von einem Zeitpunkt bis zu einem Zeitpunkt gehen und es muss ein Ziel haben. Und idealerweise ist das Ziel so definiert, dass du hinterher sagen kannst, ja, das Projekt war erfolgreich oder das Projekt war nicht erfolgreich oder es war teilweise erfolgreich.

Das ist ja schon sehr konkret. Also es ist nicht einfach Arbeit, die zu tun ist.

Genau, es ist nicht einfach Arbeit, die zu tun ist, sondern es ist ein Ziel, du willst ein Ziel erreichen. Das Ziel kann natürlich sein, der Zeitraum ist zwei Wochen und in zwei Wochen sind folgende Tickets abgearbeitet. Das ist ja auch ein Ziel, das ist auch ein Projekt in dem Sinne.

Naja, also welche Dimension hat denn jetzt zum Beispiel so ein Ziel? Ich kann erst ja ganz viele kleinteilige Ziele machen und die unter einem großen Oberziel und ganz vielen großen mehreren Zielen machen. Ab wann fängt da ein Projekt an, oder?

Ja, das ist jetzt das, was Projektmanagement ist. Das Projektmanagement, wie du deine Projekte managst, sagt im Wesentlichen, wie lange deine Projekte sind und wie groß die Ziele sind. Du kannst natürlich ein Projekt machen, das heißt Firma und das Projekt heißt Geschäftsjahr und das Ziel ist es, am Ende des Geschäftsjahres viel Umsatz gemacht zu haben.

Profit, Profit, wir treten nach Profit.

Genau, sagst einfach Profit.

Wir wollen am Ende des Geschäfts auch das Profit machen.

Und das ist super gut, weil du weißt ganz genau,

es geht vom 1.1. bis zum 31.12.

Und dann guckst du am 31.12. auf dein Dashboard

und siehst, wie viel Profit du gemacht hast.

Und das ist super gut messbar.

Aber es ist für die Ausführung, für die Durchführung des Projektes

vielleicht nicht so gut, weil da nicht drin steht,

weil da nicht dran hängt, was du tun kannst.

Und das ist sozusagen das größte Projekt, was du machen kannst.

Ich will über die längste Zeit, die ich mir denken kann,

möglichst viel Gewinn machen.

Das kleinste Projekt, was du machen kannst, ist ein Meeting.

Du gehst in ein Meeting und sagst, das Meeting dauert von neun bis zehn

und das Ziel ist es, wir müssen entscheiden,

ob wir JavaScript oder Python verwenden.

Und das wäre auch ein Projekt.

Wenn du das möchtest, kannst du das auch als Projekt sehen.

Weil es ist ein zeitlich begrenztes Vorhaben,

was ein definiertes Ziel hat.

Und die Frage ist, wie sinnvoll ist das? Ist das jetzt sinnvoller, eine Million Projekte zu haben, die so klein sind oder ist es sinnvoller, ein Projekt zu haben, was sehr groß ist?

Kann man denn ganz viele kleine Sachen managen oder braucht man was ganz Großes managen? Was ist denn da managen? Was heißt das? Strukturiere ich das um? Priorisiere ich das? Mache ich eine große Liste, wann was gemacht werden muss? Versuche ich alle Menschen bei Laune zu halten, um zu gucken, dass die einfach arbeiten?

Ja, alles, was du sagst, würde ich sagen. Also alles, was du tun musst, um deine Ziele zu erreichen.

Was ich halt spannend finde, ich habe gerade nebenbei noch die Wikipedia offen gehabt und ich habe festgestellt, es gibt eine DIN für den Begriff Projekt.

Ach, sehr schön.

Es gibt eine DIN für alles.

Jetzt gibt es die DIN 69901, die sagt, ein Projekt ist ein Vorhaben, das im Wesentlichen durch die Einmaligkeit, aber auch Konstante der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie zum Beispiel Zielvorhergabe, zeitliche, finanzielle, personelle, andere Begrenzungen, Abgrenzungen über anderen Vorhaben und die projektspezifische Organisation.

Also was ich interessant finde an der Stelle ist tatsächlich dieses Thema Einmaligkeit und Zielgerichtetheit und wenn ich an der Stelle jetzt drüber nachdenke, das gilt halt für viele Dinge, die ich so sehe, wenn man jetzt mal fragt, okay, was tun wir eigentlich den ganzen Tag lang, dann gilt es halt fast gar nicht mehr so.

Also zeitliche Abgegrenztheit, also ich finde zum Beispiel jetzt diese Metapher mit das Geschäftsjahr einer Firma, das ist so ein bisschen sehr synthetisch und sehr hergeholt, weil tatsächlich so diese Einmaligkeit und zeitliche Begrenztheit ja eigentlich nicht gegeben ist, die ist ja nicht aus diesem Zweck selber raus und wenn man halt Organisationstheorie anguckt, sollte ein Unternehmen im Prinzip tatsächlich auch erstmal noch andere Funktionen haben als nur die Erwirtschaftung des Profits.

Natürlich, das war immer als Beispiel gedacht für die größte Einheit, die man sich denken kann.

Jaja. Und ich finde es aber spannend, weil nämlich dieses Thema Einmaligkeit und Zielgerichtetheit heutzutage in vielen, tja, Aufgaben, die vor einem liegen, gar nicht mehr so gegeben sind. Oder halt dieses Thema konstante Ressourcenallokationen, solche Dinge.

Ich finde es viel interessanter,

für mich ist das ganz anders.

Es ist voll witzig, dass du genau diese beiden

Begriffe rauspickst, weil für mich ist der

zeitliche Aspekt einer, der

heutzutage viel schwammiger behandelt wird,

als man das vielleicht früher gemacht hat.

Das ist richtig.

Der zeitliche ist für mich

tatsächlich, der löst sich für mich halt auch auf.

Ich wollte es

vom anderen Ende aufziehen gerade, weil

ich jetzt ein paar Mal mit

Leuten es davon hatte, dass

eigentlich das, was bisher klassische

Projekte sind, inzwischen eigentlich Produkte

sind.

Also ich habe ganz viele

Ja, ich

finde halt häufig schon wirklich

Produkte in so einer Kombination

tatsächlich auch

wir haben, also bei uns ist es so,

wir haben gerne mal Kunden, die irgendwelche

eher so Geschäftsansätze,

Business

Ideen haben

aus ihrem eigentlichen

Geschäft raus und die suchen sich

irgendwen, der dieses eigentliche Produkt,

also wenn da ein digitales Produkt raus

entsteht, jemand anderes, der es implementiert

und irgendwer muss das Ding dann operativ

irgendwie betreuen und da kommt dann aber sofort

so ein Perpetuum Mobile

schon fast raus, wo

man davor steht und sagt, okay, es ist halt kein

Projekt, weil das ist halt zeitlich nicht begrenzt,

sondern wir wollen das im Prinzip als wie eine Art Mini-Unternehmen

nach vorne treiben

und es ist halt auch nur mäßig

zielgerichtet im Sinne von

es gibt halt kein festes Ziel, von wann haben

wir das erreicht oder nicht, sondern es gibt mehr ein

ja, wir haben hier irgendwie das Gefühl aus unserem

Hauptbusiness raus, in dieser anderen Ecke

da verbirgt sich irgendwie ein neuer Markt.

Wir müssen mal gucken, was man da machen kann.

Lassen wir mal irgendwas da hinwerfen, gucken,

wie der Markt reagiert und dann rennen wir nachher,

wenn wir rausfinden, dass es doof war, in genau die entgegen

die letzte Richtung.

Deswegen bin ich so an diese Einmaligkeiten

an den Ziel gerichtet halt und die zeitliche

Abgrenzung, die löst sich da in der Folge

so im Prinzip sozusagen automatisch auf.

Nur um das kurz

einzuwerfen, da gibt es auch für diese Dinge, die du

beschrieben hast, gibt es auch andere Worte

noch in dieser, ich glaube nicht

in der DIN, aber in der Literatur.

Das heißen dann Programm oder Vorhaben oder

solche Dinge.

Aber ich meine,

ergibt sich das nicht quasi so relativ

zwangsläufig aus? Also wenn ich mir jetzt so

vorstelle, also oder

ich kenne das halt aus dieser ganzen

Agile

Welt halt sozusagen, es gibt

so ein magisches Dreieck irgendwie

an Ressourcen, die begrenzt

sind und die man halt

sozusagen nicht unabhängig voneinander

irgendwie verändern kann.

Das ist halt Zeit,

irgendwie Geld, das man dafür ausgibt

und halt

irgendwie

na, was war das dritte?

Qualität. Ach ja, die wird immer so,

die vergesse ich auch manchmal.

Es gibt manchmal auch noch einen vierten davon.

Funktionsumfang.

Genau, genau. Und

das Problem ist jetzt sozusagen, dass

zwei von den Dingern eigentlich

nicht so richtig optional sind, also die Qualität will man

eigentlich nicht offern oder die Features

und Geld

will man jetzt auch nicht

beliebig da rumliegen, dann bleibt

ja eigentlich nur die Zeit, die variabel sein kann

und die wird es dann halt auch irgendwie

immer, sodass es halt

gestern

Ja, aber das ist doch

die Aufgabe des Projektmanagers, dafür zu sorgen,

dass es gestern fertig ist.

Ja, aber das ist halt auch wieder spannend, also es gibt

ja verschiedene Perspektiven, die ihr jetzt genannt habt, es gibt

halt die Perspektive von

dem Kunden beispielsweise, der jetzt

ein ganzes großes Projekt

da hat und dann da Pivots machen möchte

und wenn er dafür Menschen beauftragt,

die haben dann vielleicht ein kleines Projekt in diesem

Projekt drin. Das heißt, aus deren Perspektive

ist das nur ihr eigenes Abgeschlossenungsprojekt,

wenn dann ihre Aufgabe nach zwei Monaten

erledigt ist oder so. Obwohl das nur ein

Baustein in dem großen Projekt des anderen war. Und das ist

halt wieder diese Verschachtelung von den einzelnen Projektebenen.

Und die Frage ist, wie man das halt vernünftig

hinbekommt, dass man das so organisiert,

dass man einzelne, ich weiß nicht,

Arbeitspakete hat. Ich weiß nicht, ob ein

Arbeitspaket ein geeignetes Maß ist, um

ein Projekt zu managen oder

gibt es überhaupt Metriken? Ist das wichtig, dass man

irgendwas messen kann oder geht es um den Erfolg?

Also was ich spannend finde,

was ich bei uns halt beobachte,

von der Granularität her,

wir versuchen immer,

das geht ja auch in die Frage von, wie kann man

solche Sachen verschriftlichen, welche Tools nimmt man dafür?

Wir schreiben gern

ganz viele Sachen in Tickets rein und uns ist

es wichtig, dass wir ein

System haben, wo alles,

was irgendwie die Firma berührt, in Tickets

landet, damit ich es halt auch ein bisschen

kreuzreferenzieren kann, etc. Und da ist

tatsächlich für uns immer wieder dieses Thema,

weil wir ja eher auch so ongoing

als direkt projektorientiert sind. Ich würde

auch sagen, wir haben manchmal so Projekte, wo wir sagen,

jetzt hat es hier irgendwie einen abgeschlossenen

Fokus, wo wir mal für zwei, drei Monate

versuchen, wie das, die sieben Sachen zusammen

zu bündeln und einmal durchzuprügeln,

um sie dann auch

wieder loszuwerden und sagen, jetzt brauche

ich mich nicht mehr darum zu kümmern, jetzt denkt da

keiner mehr drüber nach. Jetzt haben wir gerade zum Beispiel

das Netzwerk einmal bei uns saniert

und dann war das halt mal für drei Monate was,

was stärker im Fokus war und was

eine ganze Reihe von zusammenhängenden

Aufgaben hatte. Und

da finde ich es zum Beispiel spannend,

für mich gibt es

so eine Balance und ich habe keine Ahnung,

was eine gute Antwort ist, dass wir auf der einen Seite

Unmengen Tickets generieren und für die

Leute in so einem Team,

in einer Firma, hat das ganz unterschiedliches

Gewicht, ob da jetzt zum Beispiel

5.000 Tickets rumliegen, um die sich nie wieder

einer kümmern wird,

da denke ich mir so, das ist überhaupt kein Problem,

die machen wir einfach alle zu, als, ja,

haben wir erfasst, steht da drinnen, wenn man

mal irgendwann nochmal danach suchen möchte

von, sagen wir, haben wir schon mal nachgedacht

über XYZ, dann sieht man, ah, guck mal, da gab es

schon mal drei Sachen, warum war denn das, wieso,

weshalb, warum, versus andere,

die dann gegebenenfalls denken,

jetzt kommt hier ein Ticket rein, fuck, das muss irgendwie

abgearbeitet werden.

Ja, aufgeräumtes Backlog oder

Stress. Das macht dann halt

Stress und auch Backlog ist tatsächlich so,

Da neigen wir gerade eher dazu zu sagen, also alles, was nicht freiwillig sozusagen bei jemandem innerhalb von zwei Wochen auf dem Tisch landet,

kannst du halt im Prinzip auch gleich zumachen, weglegen, aber vernünftig ein bisschen mit Metadaten versehen.

So zu welchem Bereich gehört denn das so grob? Was hat denn das noch für zwei, drei Tags oder so?

Und dann kann man, wenn man dann mal auf die Suche geht von so, okay, was haben wir denn im letzten Jahr für Notizen uns gemacht zum Thema XY?

Weil da wollen wir jetzt nochmal rangehen, dann kann man die dann wieder rausholen.

aber du musst sie nicht ständig pflegen und machen

und tun und

das hilft halt den Leuten auch dann, wenn jemand dir sagt,

ja komm, mach einfach Tickets, immer her damit, immer her damit,

immer her damit, dann hast du so ein bisschen organisationales

Wissen halt auch an der Stelle, ja.

Wie macht ihr denn Tickets, wenn ihr gerade so bei

Tickets sind mit Python oder

Macht ihr Tickets

für wirklich alles? Macht ihr Tickets auch für,

keine Ahnung, Kaffeemaschine ist kaputt oder für

keine Ahnung, Kunde

muss gefunden werden?

Ja, ja,

genau. Also das kommt immer

darauf an, wer das halt macht.

Wenn die Kaffeemaschine, da muss ich

gerade überlegen, es kann sein, dass

meine Kollegin, die dafür zuständig wäre,

sich da ein Ticket macht, um sich zu erinnern,

weil das halt auch in Summe den

Alltags-Arbeitsorganisationsflow abbildet.

Weil halt

jedes Team halt so seine Flowboards

auch hat mit, was liegt denn hier

irgendwie gerade im Team eigentlich so alles an und dann

willst du halt auch sehen, ständig mal eine Kaffeemaschine machen,

dies und jenes.

Und auf der anderen

Seite habe ich aber halt auch häufiger mal Sachen,

weil auch ein Ticketsystem relativ schwergewichtig ist,

habe ich so meine eigenen kleinen To-Do-Listen

noch, wo ich dann irgendwann sage, jetzt schleife ich das ja

ewig rum, jetzt ist es mal wieder zu viel geworden,

jetzt mache ich da irgendwie Tickets draus, damit ich es wieder auch

anderen Leuten im Team geben kann.

Okay.

Es ist spannend, dass ihr alles über Tickets macht.

Ja,

aber ich kann das total verstehen, dass das für

unterschiedliche Leute eine total unterschiedliche

Bedeutung hat. Ich kann aber auch

verstehen, dass es Leute gibt oder dass es vielleicht

Positionen gibt, die damit überhaupt nicht klarkommen,

weil die eben

nicht so einzelne

Arbeitspakete haben, sondern weil die

vielleicht eher eventgesteuert sind oder weil die

eher dauerhafte Aufgaben haben.

Also das

klassische Beispiel ist halt ein Callcenter-Mitarbeiter,

der

wartet halt auf einen Anruf,

der kann keine Tickets bearbeiten,

um es mal sozusagen, bis ihn jemand anruft

und da hilft es auch nichts, wenn er

zehn Tickets auf seinem Tisch hat, weil er halt

auf

dieses Event warten muss.

Umgekehrt gibt es natürlich so Sachen, die ongoing

Ja, dass du halt, du musst halt jeden Tag, keine Ahnung, die Post abholen und du musst jeden Tag die Rechnungen verschicken und du musst jeden Tag die Eingänge prüfen, was weiß ich. Und dafür Tickets zu haben, stelle ich mir auch schwierig vor. Also diese Ticketsachen passen schon eher zu dem, was man so als Softwareentwickler halt macht, dass man was macht.

Ja, das kommt total drauf an, weil wir haben im letzten Jahr eine ISO 27000 gemacht und da musst du relativ viele Prozesse auch zumindest so formalisieren, dass du halt nachweisen kannst, dass Sachen, die passieren sollen, auch passiert sind.

Wenn du dann eh schon ein Ticketsystem hast, wir haben jetzt bei uns so eine Kombi, da kann man in dem, wir haben so ein Media-Wiki für die Dokumentation, für die Prozessdokumentation und dann kannst du in einer Wiki-Seite so ein kleines Template anlegen.

Das komische Media-Wiki generierte da auch gleich so richtig Formulare für. Und jetzt kann man bei uns auf einer Wiki-Seite sagen, zu diesem Prozess gehört es, dass einmal im Quartal jemand irgendwie nachguckt, ob im One-Pass-Wort irgendwie die richtigen Leute drin sind oder noch Leichen rumfliegen oder irgendwie sowas.

Und dann gibt es tatsächlich einen Cron-Job, der aus diesen Daten dann die Tickets generiert zum richtigen Zeitpunkt und du kannst sozusagen so Wiedervorlage-Tickets in der Prozessdefinition hinterlegen und das ist dann auch so ein Mittelweg zwischen, ja, also alles, was man täglich machen muss, das brauchst du, glaube ich, nicht in Tickets nachweisen, aber wenn es dann plötzlich auf alle zwei Wochen, vier Wochen, acht Wochen geht, dann willst du dir vielleicht schon eher Erinnerungen machen können.

Ja, aber dann ist es ja wirklich eher erstmal so ein To-Do-Item, also sowas ganz leichtgewichtiges. Es gibt ja auch Tickets, wo du acht Wochen brauchst und ein Team von zehn Leuten zu bearbeiten. Und da diese Spanne, finde ich auch was ganz Spannendes. Das ist auch das, was der Dominik eben angesprochen hat.

Und das ist so im Wesentlichen die Kernfrage von Projektmanagement. Wie groß sind die Projekte, die man macht? Sind die ganz klein? Sind die eine Woche lang eine Person? Oder sind die ganz groß? Vier Jahre und ein Team von 150 Leuten. Und wie dröseln wir das dann auf, wer was an welcher Stelle in welchem Projekt macht?

Ja, da würde ich sagen, erfahrungsgemäß sind die eher groß. Also die Sachen, die irgendwie dann einzelner Entwickler macht oder so, die sind ja dann meistens, aber die nennt man dann ja nicht Projekt, sondern das ist dann halt irgendwie ein Task oder eine User Story.

Definitionsgemäß sind es natürlich schon auch Projekte.

Ja gut, okay, aber

die gehören immer zu irgendeinem, also es

gibt immer meistens eine Projektnummer, auf die das dann

irgendwie gebucht wird oder so und diese Projektnummern

sind, die sind sozusagen, ich weiß nicht,

die werden irgendwie mal beim Urknall erzeugt

worden sein und die sind halt ewig, die verändern sich auch nicht.

Hinterher bucht man auch ganz andere Projekte

auf alte Projekte.

Ein Projekt ist einfach nur eine Kostenstelle.

Ja, wir haben halt die Herren S, A und P

irgendwann mal erzeugt.

Da geht es ja dann wieder tatsächlich noch

in den anderen Bereich rein, dass

Projekte auch ein Kommunikationsmittel sind

und auch eine gewisse

vertragliche Vereinbarung enthalten

können, weil Projekte eben

ein Mittel sind, wie man mit einem Kunden kommunizieren

kann. Du sagst, okay, wir machen

jetzt erstmal ein Projekt und dann hat das

eine gewisse Schwere. Das ist nicht

was, was du einfach so machst, sondern wir machen

mal ein Projekt und das hat gewisse Komponenten, die

da sein müssen, weil

du den zeitlichen Rahmen festlegen musst, weil du

die Ressourcen festlegen musst, weil

du das Ziel festlegen musst.

Ja, aber dafür braucht man ja schon die ganzen Informationen,

die man vielleicht ja noch gar nicht hat.

Das heißt, was man da irgendwie machen muss,

ist irgendwie so eine Pi-mal-Daumen-Schätzung

oder die mehr oder weniger valide Schätzung abzugeben.

Ja, klar.

Aber das ist ja nicht möglich bei unbekannten Dingen.

Also das geht ja nur dann, wenn man sowas schon mal kennt.

Ja gut, du hast halt ein Projekt,

was eventuell sein Ziel nicht erreicht

oder was verlängert werden muss oder was über Budget geht.

Aber das haben wir ja, glaube ich, alle schon mal erlebt.

Passt man die Sachen halt an.

Also immer.

Aber es ist eigentlich ein gutes Feuerstein.

Ja, also da merke ich auch, da versuche ich eher anders an die Sachen heranzugehen. Wir haben so ein bisschen den Vorteil, dass wir typischerweise eben aus dieser operativen Sicht kommen, wo eh alles ein ongoing concern ist im Prinzip. Und wo man halt auch mal sagen kann, so ja, okay, jetzt machen wir hier mal.

Wir machen praktisch keine Projektarbeit, aber natürlich haben wir das Thema, dass halt bestimmte Innovationen oder bestimmte Änderungen oder bestimmte Weiterentwicklungen halt irgendwie aufgefangen, mit begleitet werden müssen, umgesetzt werden müssen etc.

Und ich habe aber halt aus dieser Beschäftigung mit den Komplexitätstechniken, so rund um Kinevin etc., komme ich dann halt eher da rein zu sagen, naja, entweder ist das etwas, was wir kennen, dann sehe ich zu, dass das so gut wie möglich automatisiert und operationalisiert wird.

Dann habe ich aber einen ongoing concern daraus gemacht. Oder es ist was total Unbekanntes und in einer komplexen Welt will ich bei was Unbekanntem mir nicht schon ein Ziel setzen, weil ich damit halt psychologisch das Problem aufmache, dass ich halt unterschätze, wie viel Erkenntnisgewinn ich auf der Reise eigentlich einsammle, um dann zu dem eigentlichen Ziel zu kommen.

Das ist, glaube ich, das, was der Dominik sagen wollte, oder?

Ja, also ihr müsst vielleicht erstmal nochmal die ganzen kleinen Sachen definieren, die unsere Hörer vielleicht gar nicht kennen.

Zum Beispiel, was ist denn Kinevin?

Kinevin ist ein Ansatz von einem walisischen Professor namens Dave Snowden, nicht verwandt mit Edward Snowden.

Und der beschäftigt sich so seit den 80ern mit Knowledge Management, war lange bei der IBM und hat, beschäftigt sich mit komplexen Systemen, auch komplex-adaptiven Systemen genannt.

Und schreiben, geschrieben wird Knaven mit C-Y-N-E-F-I-N.

Die Beliezer haben sehr lustige Ausspracheregeln, deswegen kommt da dann am Ende Knaven raus.

Und da geht es zum Beispiel darum, dass man halt multimodale Entscheidungssysteme braucht.

dass du halt in der Lage sein musst zu sagen, ja, für bestimmte Arten von Problemen muss ich halt unterschiedliche Lösungsstrategien angehen können und gleichzeitig ist es auch nicht so, dass ein bestimmtes Problem absolut betrachtet einer bestimmten Komplexitätsklasse zuzuordnen ist, sondern die Frage ist mehr, kann ich mir unterschiedliche Perspektiven ranziehen, also er hat solche Sachen wie ungeordnete und geordnete Systeme, komplexe Systeme, wo ich retrospektiv erklären kann, wie die Zusammenhänge hier eigentlich sind

Oder chaotische Systeme, wo ich auch retrospektiv nicht mehr sagen kann, wie es eigentlich dazu gekommen ist. Oder geordneten Systemen, wo ich halt einen Experten, einen Ingenieur dransetzen kann, dem das Problem schüttere, der dekliniert das durch und sagt mir, die Antwort ist X. Oder halt eher bürokratische, einfache geordnete Systeme, wo ich halt sage, okay, wenn der Herr einen Ausweis will, dann müssen wir hier halt das Verfahren X abarbeiten und dann kommt da hinten ein Ausweis raus.

Und was da spannend dran ist, ist halt das nicht ontologisch zu betrachten von, ja ist ein Problem jetzt einer dieser Domänen zuzuordnen, sondern die Frage ist, was lerne ich über ein Problem, wenn ich es aus einer dieser Brillen halt betrachte, um es dann gegebenenfalls zu zerteilen und zu fragen, was in diesem Problem wäre denn etwas, was man mit Expertenwissen erschlagen kann, wo sich jetzt einer mal mit einer Timebox eine Woche Zeit nimmt und sagt, so, dekliniert das mal durch, habe ich danach eine Lösung, sehr gut.

Oder ist die Frage, ist es komplex, müssen wir im Prinzip erst anfangen, mit dem Ding ein bisschen zu spielen, um was drüber zu lernen, um dann zu gucken, ob wir es weiter zergliedern können, um zu wissen, aha, hier geht es in die richtige Richtung, hier geht es in die falsche Richtung oder brennt mir hier gerade irgendwie alles ab und ich muss erst mal draufhauen und danach fragen.

Und das sind Ansätze, wo ich merke, die gehen so weit weg von einem im klassischen Projektmanagement stark bürokratieorientierten Ansatz. Also ich bin zur Uni gegangen, das war 2001 bis 2003, da sind wir noch mit diesen klassischen Wasserfallmodellen konfrontiert worden, während wir gleichzeitig, gleichzeitig kam 2001 das Agile Manifesto raus.

Und als Studenten hatten wir halt dieses Agile Manifesto vor uns, während unsere Profs und irgendwie Function-Point-Schätzungen gaben von, du musst ein Projekt halt in alle möglichen definierbaren Teile zergliedern, die dann entsprechend schätzen und bepreisen. Ja, dann addierst du dir halt auf und dann bist du halt fertig. Und diese Ansätze berücksichtigen ja keinerlei Interaktionen und Erkenntnisgewinne auf der Reise oder wie Dinge halt komisch sich verzweigen.

Und heute sind wir dummerweise wieder an einem Punkt, ich nenne das dann immer Weaponized Agile, dass man halt eben sagt, agil ist jetzt, wenn eine große Firma sich Scrum einkauft, jedes Team genau den gleichen Arbeitsmodus hat und alle zwei Wochen ihre Tickets abliefert und ich gucke auf das Agile Manifesto und denke mir so, ja Moment, nee, da stand erstmal drauf, dass es um funktionierende Software und ordentliche Zusammenarbeit und dass das Team im Prinzip sich überlegen muss,

was denn in diesem Projekt jetzt gerade der richtige

Arbeitsmodus ist und allein schon

eben dieses Thema, du sagst es ja auch

das ist jetzt mal ein Task

oder ein Ticket, da brauchst du 10 Leute für

8 Wochen, da platzt dir

ja jeder Scrum Master

Haben wir aber alle schon mal gehabt, solche

Ja, das ist halt so, wo ist denn das Problem?

Ja, gut, ich würde jetzt sagen

so aus Agile Perspektive, es ist halt so

sowas sollte man sich nicht vornehmen, weil einfach das Risiko

dass das schief geht, ist halt zu hoch, kann man das

nicht vielleicht irgendwie ein bisschen

in Teile aufteilen, aber

und das geht ja dann meistens auch

irgendwie.

Ja, aber ich finde das sehr interessant

und ich finde, also möglicherweise

ja, eben, was man für Probleme hat,

hängt halt unter Umständen auch damit zusammen,

eben, ob man jetzt eher Projektgeschäft macht oder

eher, ja, irgendwie operative

Geschichten, so Produktionen.

Ich glaube auch, dass da ein großer,

dass da noch ein wichtiger Unterschied ist,

den man vielleicht nicht so

ja, ansonsten, wenn man das

sich jetzt schon auf irgendeine Methodologie

einschießt, vielleicht nicht so wahrnimmt, aber

der ist, glaube ich, tatsächlich

sehr relevant

und es geht üblicherweise in eine

bestimmte Richtung immer sehr schief,

nämlich man hat halt einen Unterschied,

wenn ich jetzt zum Beispiel bei Softwareentwicklungen,

wenn ich darüber nachdenke,

wie funktioniert das, was

macht man da eigentlich, im Gegensatz

zu, weiß ich jetzt nicht, zum Beispiel

irgendwas,

man hat ein Fastfood-Franchise-Restaurant,

irgendwie sowas.

Hast du Hunger?

Ein bisschen.

Okay.

Mal gucken.

Ja, Softwareentwicklung hat halt immer auch

sowas Exploratives dabei, oder?

Man weiß am Anfang noch nicht,

wie die Lösung ausschaut.

Ja, na ja, sagen wir mal so,

die Prinzipien, also wie man das managt,

ist halt sozusagen fast umgekehrt.

Also bei so einem Fastfood-Franchise würde ich sagen,

also man muss Sachen standardisieren,

man muss halt zusehen,

dass irgendwie keine Fehler

passieren, dass man einfach

die Fehlerquote kontinuierlich senkt,

dass keine Überraschungen passieren, dass alles

irgendwie so wie es im Buch steht

halt gemacht wird.

Man muss halt irgendwie dafür sorgen, dass die Leute irgendwie

pünktlich zur Arbeit kommen und

dass halt irgendwie die ganzen formalen Geschichten

eingehalten werden.

Das ist alles total wichtig und

keine Experimente. Es gibt irgendwo eine Zentrale,

da überlegen die sich vielleicht neue Rezepte oder so,

aber irgendwie die Leute

im Restaurant sollen halt austauschbar sein

und die sollen halt irgendwie funktionieren

und das Ganze ist quasi so eine Maschine

und die soll halt laufen, damit da irgendwie Cheeseburger

rausfallen und die Leute glücklich sind.

Ja, aber das löst doch auch nur so ein gewisses

Problem, oder? Genau, das löst halt dieses

dieses, ja.

Ja, aber das Ergebnis davon ist halt

ein Fastfood-Hamburger und wenn du einen guten

Hamburger essen willst, gehst du nicht zu einem Fastfood-

Laden, weil da kriegst du zwar immer

den gleichen und auch auf der ganzen Welt überall

immer den gleichen, aber du kriegst

halt auch immer nur den Fastfood-Burger.

Ich glaube auch bei

Also was du ja

beschreibst gerade, ist eben, das ist die Optimierung

auf Effizienz. Das ist, du willst

möglichst viel Output mit möglichst wenig Input haben.

Das ist Effizienz.

Und Standardisierung.

Du willst immer den gleichen Output haben.

Je gleicher der ist, umso besser.

Ja, genau.

Du willst halt, du willst auch wenig

Variationen da drin haben.

Die

Seite

bei der Softwareentwicklung und Explorativen

ist halt, solange du

gar nicht weißt, was du tust, musst du

erst mal an der Wirksamkeit der Lösung arbeiten.

Du musst erst mal die Effektivität herstellen.

Du musst erst mal fragen, tue ich hier eigentlich das Richtige?

Und ich meine, das

willst du halt auch nicht. Das ist jetzt philosophisch

abstrus. Ich muss sehr an die Simpsons denken.

Irgendwie da den einen Jugendlichen,

der immer beim Hamburger

du willst nicht, dass der sich die Frage stellt, ob er hier

gerade das Richtige tut.

Das willst du halt

nicht. Der kommt nachher auf die Idee, seinen

Lebenssinn irgendwie in Frage zu stellen. Das wäre

für den Output der Burger jetzt eher

schwierig. Nachher sagt

er, ich will gar nicht arbeiten.

Ich würde sogar fast noch einen Schritt weiter gehen

und sagen, bei Software weißt du am Anfang

oft gar nicht, was das Ergebnis sein soll.

Genau.

Solange du nicht weißt, was du für einen Burger

haben willst, kannst du auch keinen Prozess machen,

diesen Burger herzustellen.

Und Achtung, natürlich gibt es da einen Zwischenton

im Sinne von, wenn du mit deinem Handwerkszeug

effizient

umgehen kannst, im Kleinen,

im Sinne von, wie schreibe ich Code und wie

strukturieren wir eine Softwarebasis,

etc., dann kannst

du natürlich kostengünstiger

mehr explorativ machen,

als wenn du die ganze Zeit nur dabei bist, irgendwie

dagegen, also wer nicht zehn Finger schreiben kann,

nicht jeder muss

zehn Finger schreiben können, aber

wer halt, wer Schwierigkeiten

hat, eine gewisse Menge Code effektiv

und effizient ins System reinzukriegen,

der kann halt nur schwierig experimentieren,

weil es halt sehr teuer ist,

halt mal vorwärts, rückwärts, links, rechts und

Da ist aber auch tatsächlich diese klassische Projektmethodologie drin, du willst die Fehler während des Prozesses minimieren, weil die nach hinten heraus explodieren, während wenn du sagst, naja, es ist für mich leicht, schnell viel Code zu produzieren, zu testen, anzugucken und darüber nachzudenken und dann die nächste Iteration reinzugehen, dann brauche ich nicht von vorne nach hinten alles ausdefiniert haben, sondern kann es mir leisten, zu sagen, Code ist auf eine gewisse Art ein lebendes Gespräch mit einem komplexen System,

um zu sagen, was passiert denn hier,

wenn ich jetzt diese Menge von Code reinstreue.

Daraus entstehen neue Ideen.

Und dann kommst du dahin zu sagen,

und das ist das, wo ich dann wieder andocke mit,

das ist diese Softwareentwicklung als Ongoing-Concern

eines Produktmanagements.

Dann willst du aus so einer Kombination aus,

da gibt es Leute, die haben halt ein Business-Anliegen,

da gibt es Leute, die können Software entwickeln,

da gibt es Leute, die betreuen sowas operativ.

Und aus denen willst du einen andauernd laufenden

Co-Creation-Prozess bauen,

Wo jeder im Prozess die Möglichkeit hat, Erkenntnisse einzufüttern, um dieses, was tun wir hier eigentlich, weiterzuentwickeln und anzufüttern. Und nicht nur dieses, ja, haben jetzt alle ihre Aufgaben gemacht, dann ist jetzt das Projekt vorbei, dann brauchen wir es jetzt für fünf Jahre nicht anfassen und das läuft jetzt hier vor sich hin.

Ein Co-Creation-Prozess, das ist schön.

Ja, das ist halt, wenn man mal versucht, irgendwie dieses blöde Thema Digitalisierung mit irgendwas sinnvoll zu unterfüttern, dann finde ich, ist gerade so ein Begriff wie Co-Creation das, wo man tatsächlich Wert schöpfen kann, wo du wirklich sagen kannst, was ist jetzt an Softwareentwicklung, außer von, ja, wir haben es jetzt perfektioniert, möglichst schnell Fachanwendungen mit immer den gleich aussehenden Formulareingabefenstern auszukotzen.

Was kann man da eigentlich besser machen?

Und besser machen ist eben tatsächlich zu sagen,

naja, du willst in den Alltag rein, bis zum Nutzer,

diese Konversation mit dem komplexen System von

was tun wir hier eigentlich und was geht eigentlich unterfüttern.

In Knevin, in dieser komplexen, heißt es unarticulated needs,

weil du halt das Problem hast, dass die Leute, die das Zeug einsetzen,

die verstehen heutzutage nicht, was kannst du eigentlich alles bauen

und du kannst nicht kommunizieren,

was in ihrer Domäne jetzt vielleicht sinnvoll wäre zu bauen.

Das heißt, du musst auf eine gemeinsame Reise gehen,

um eine Sprache zu entwickeln,

um tatsächlich im täglichen Dienstag früh um sieben,

mein Patient ist komisch ausgerutscht,

weil das Programm mir gestern vergessen hat,

auf eine sinnvolle Art zu sagen,

dass da bitte eine Mathe hinzulegen ist.

Diese Schleifen brauchst du halt nicht am grünen Tisch

irgendwie von irgendeinem Produktmanager.

Du brauchst diese Schleife tatsächlich zwischen

bis zu da ist der

Patient hingefallen, weil XYZ.

Und diese Informationen ordentlich

durch die Gegend zu leiten, ist tatsächlich

auf einer ganz anderen Ebene, als was man klassischerweise

unter Projektmanagement verstehen würde.

Das ist jetzt aber schon ein sehr agiler Ansatz,

dass du den Kunden direkt in das Projekt

einbettest, dass du erstmal den Kunden beobachtest

und dass du das immer in kleinen Schritten

machst.

Aber nochmal ganz kurz, um das mit dem Produktions...

Also ich fand, genau, finde ich alles

richtig. Ich würde jetzt nur sagen, was ich

oft sehe, was Leute tatsächlich, wo ich auch

denke, dass es läuft einfach immer oder oft

schief, ist halt, dass

wenn ich jetzt so ein Projekt habe, wo eigentlich

all diese schönen Sachen gemacht werden sollten,

wie wird das

oft in Firmen gemanagt? Dann wird es so gemanagt, als

wäre das ein Burger-Franchise.

Und das ist eigentlich

fast genau falschrum, weil

eigentlich müsstest du

sozusagen, wenn

du nicht weißt, also wenn du all diese

komplexen Probleme hast, musst du eigentlich zum Beispiel

eben experimentieren, eigentlich

sozusagen mehr vorantreiben

als verhindern. Du musst halt irgendwie

sagen, okay, naja, Fehler können halt passieren.

Es kann sein, dass man mal eine Zeit lang in eine falsche Richtung läuft.

Da muss man sich halt umdrehen und in eine andere Richtung laufen.

Was man aber tatsächlich oft sieht, ist

halt sehr defensives Management an der Stelle.

Zum Beispiel, also

alle sagen immer, dass Fehler gut sind und dass es kein Problem ist

und dass man daraus lernen kann und anders gar nicht lernen kann

und so. Also Lippenbekenntnisse hört man oft.

Aber was man auch in den

meisten, also ganz oft, was ich da

höre, ist immer sowas wie

ja, wenn man zum Beispiel jetzt sieht

in einem Projekt irgendwie, das ist so ein bisschen in der Sackgasse

gelaufen, ja, und dann sieht man das so als zum Beispiel

jemand, der so extern dazukommt und denkt sich so

hm, also da geht's irgendwie nicht weiter

und dann spricht man das an und dann

oft erst so informell und dann kriegt man

halt so, ja, ja, das wissen wir ja alles,

aber das geht jetzt halt nicht anders

und das läuft schon so lange und das, machen wir

das lieber schrittweise, machen wir lieber Tickets und so

und dann denkst du, ja, aber wo soll das hinführen, das geht

nirgendwo hin, das ist, das ist

Das geht ins Ticketgraben.

Ja, da haben wir mit dem Kunden nicht genug gesprochen.

Das ist schon freigegeben, du hast schon die Freigabe,

dann musst du das auch machen.

Ja, aber genau, und dann kann man

das vielleicht, ja, das ist halt

dann aber nicht mehr, wenn das nicht geht,

oder wenn einem die Leute sagen,

wenn man dann sagt, okay, probieren wir das einmal,

nee, das ist politisch nicht durchsetzbar,

dann weiß man, okay, hier sind Fehler

nicht so richtig erwünscht, weil jetzt, da haben alle

schon gelernt, wenn man jetzt sagt, okay, das war

ein Fehler, wir machen es jetzt anders, dann ist das

politisch keine gute Idee, weil

Fehler wohl offenbar doch keine so gute Idee sind.

Und wenn man jetzt Leute, also

man könnte zum Beispiel Leute

fragen, was war eigentlich die letzte

fiese Architektur-Fehlentscheidung,

die so passiert ist? Und wenn

Leute sagen, ist nie passiert, oder Projekt,

das eine Sackgasse ist, wo man mal, wenn Leute

sagen, sowas passiert nicht, nie,

dann ist das zu wenig, weil das ist nicht optimal.

Also optimal wäre durchaus, ab und zu sich

zu irren und irgendwie

mal eine Sackgasse zu laufen und

dann halt wieder umzudrehen. Also

ja, das ist halt

Das kommt vielleicht auch alles so ein bisschen aus dieser

Welt, die der Tony vorhin schon

angesprochen hat, dass

ganz viel noch Waterfall

gematcht wird. Und das geht

halt nicht. Es ist in den Köpfen irgendwie drin, ja.

Ein agiler Wasserfall.

Übrigens, dieses

Waterfall-Modell, das ist definiert worden

von Royce Winston,

ist schon ganz lange her.

Ich würde euch die Jahreszahl sagen, aber ich finde

sie gerade nicht.

Und war eigentlich als Negativbeispiel gedacht.

war eigentlich gedacht als Beispiel von

so geht Software-Management nicht, so kann man

Projekte nicht managen. Nur leider hat

nie jemand... Dann machen wir das jetzt so.

Es hat nie jemand über die erste Seite

hinausgelesen und nur dieses erste

Diagramm ist das, was man immer sieht.

Auch in diesem ersten Paper steht

schon drin, als eine von den Sachen

involve the customer, also sprich mit

den Leuten, die das dann benutzen sollen

und benutzen müssen, weil nur die wissen, was

da

Anforderungen tatsächlich drin ist. Nur die

wissen, was die tatsächlich brauchen. Das erste wäre

mal einen Kunden zu finden. Einige Leute

fragen dann irgendwelche Leute, wo sie denken, dass es ihre Kunden sind,

aber gar nicht und die erzählen dann irgendwelchen Unsinn.

Ja gut, aber da kannst du mit Projektmanagement

nichts dagegen tun, dass du Fehler auf einer anderen

Ebene hast. Ja, wobei

das Problem ist, das zu merken kann schwierig sein.

Also ich würde gerne ein paar

Stellen dort andocken, aber da gibt es eine Anekdote,

wo wir auch genau dieses Thema hatten,

so um 2002, 2003 rum,

Agile und Kunden mit einbeziehen und Customer

On-Site, ja, den Kunden mit ins

Team holen, haben wir dann gemacht.

Was macht der Kunde?

hat uns jemand geschickt und der war dann auch später

immer wieder im Freigang.

Und dann haben wir irgendwann, das hat lange gedauert, bis wir es

gemerkt haben, weil auch wir die Erfahrung an der Stelle noch nicht

hatten, der hat halt irgendeinen

billigen Mitarbeiter geschickt,

also irgendeinen Praktikanten.

Der war halt entbehrlich.

Der durfte aber nichts entscheiden.

Das heißt, der hat sich auch bloß immer umgedreht und hat mit

zu Hause telefoniert, wollte aber natürlich auch ein bisschen

eingebunden sein. Und ich habe

irgendwann tatsächlich realisiert,

der hat uns immer so ein paar SQL-Querys geschickt

für Sachen, wo er gerne noch Auswertungen für hätte.

Und

das lief immer nicht sauber.

Da hat immer irgendwas in der Syntax gehakelt,

etc., etc., etc. Irgendwann kam er an

und sagt, so, die Änderung vom letzten Mal habe ich dir rot markiert.

So.

Und dann ist der Groschen gefallen,

der hat die nie ausgeführt.

Der hat nur bei sich am Rechner gesessen

und in seinem Word

SQL-Querys runtergeschrieben,

die er mir dann geschickt hat,

nur damit ich dann feststelle,

ja, das geht ja vorne und hinten nicht. Und als er dann meinte

rot markiert, hat er tatsächlich dann halt angefangen

das Word-Change-Tracking

zu nutzen um mir

um, also im Prinzip war ich

Du warst quasi der Compiler. Ich war sein

Word-E-Mail-basierter

Postgres-Interpreter

der dann immer zurück mit den Fehlermeldungen

von der Postgres-Trail kam.

Das war halt so eine völlig

bis man das auch merkt, dass dieses Customer-On-Set

da völlig daneben gelaufen ist, hat gedauert.

Man darf auch auf die Kunden nicht zu viel hören, das ist auch so ein Problem, was man heutzutage manchmal hat, weil die Kunden oder die Benutzer oft ganz verrückte Vorstellungen haben.

Wie du genau vorhast, dass die Kunden nicht wissen, was man bauen kann.

Und das heißt, entweder sagen sie, ja, es wäre schon gut, wenn man hier Text eingeben könnte und dann denkst du, ja, das konnte man 1970 schon.

Andererseits kommen sie dann und sagen, ja, aber der muss doch erkennen, dass da eine, welche Person da auf dem Field ist und du denkst dir, ja gut, Google kann das, aber wir können das ja nicht.

Welcher ist denn der Mensch, der das so entscheidet? Ist das der UX-Mensch, der das kann? Diese Sprache sprechen mit, wer der Kunde ist und was der eigentlich will?

Es muss auf jeden Fall so eine Rolle geben,

der diese Sprachen spricht und das ist

ein Zeichen von

erfolgreichem

Projektmanagement und erfolgreicher Softwareentwicklung,

dass es so eine

nicht eine übergeordnete, so eine

vermittelnde Rolle gibt, der sowohl

mit der Softwareentwicklungsseite

sprechen kann, als auch mit der Kundenseite.

Also idealerweise bräuchte

man in jedem Projekt einen, der

zum Kunden

gehört, aber in seiner Freizeit Open Source

Software entwickelt, weil

der diese Brücke schlagen

kann. Nur so jemanden gibt es halt

oft nicht. Und dann denkt sich das jemand aus

und wenn das jemand ist, der

zu wenig Empathie hat, dann

denkt er sich halt aus, dass die Leute

das nicht wissen müssen, was sie müssen.

Und dann kriegst du so

Projekte, die irgendwo hinlaufen, die

irgendwas herstellen, was dann keiner haben möchte.

Und tatsächlich, also

diese Art von Übersetzung ist,

ich würde nochmal andocken wollen,

weil mir fällt tatsächlich auf, das habe ich

gar nicht gedacht, eine Vorbereitung, dass mir

jetzt die ganzen

Komplexitätsbasierten Ansätze da alle reinlaufen.

Typisches Frequenzmanagement-Problem.

Ja, ja. Es ist halt

dummerweise auch mein Steckenpferd und das Dokumentar halt

überall an. Das eine ist

das Thema Fehlerkultur, da bin ich

dort auch nochmal auf den Trichter gekommen.

Es wird

dort auch bezeichnet, dass wenn du in einer komplexen

Welt bist, wo du halt die Interaktion nicht vorhersehen kannst,

musst du parallele

Experimente machen. Das Spannende ist

tatsächlich zeitlich parallel. Ist das so

A-B-Testing oder was kann man das so kurz sagen?

Ja, noch nicht mal.

Du willst ja nicht nur zwei machen, sondern du willst im Prinzip,

was du machen möchtest, ist, du willst,

es geht ein bisschen in die Richtung A-B-Testing,

aber schon vorgeschalten, im Prinzip schon während dem du entwickelst,

zu gucken, in welche Richtung entwickelt sich was.

Und du willst dir sozusagen für ein gestelltes Problem,

wo du die Lösung eben nicht a priori bestimmen kannst,

sondern eben Softwareentwicklung erst entwickeln musst,

Willst du dir mehrere Theorien ausdenken, die tatsächlich auch so geartet sind, dass du brauchst immer mindestens drei, lieber fünf bis sieben, wo du weißt, es gibt eine gewisse Menge Widerspruch zwischen den unterschiedlichen Ansätzen, dass also wenn du anfängst sie zu implementieren, nicht alle tatsächlich valid sein können.

dann hättest du nämlich nichts gelernt und du willst auch machen, dass du bestimmte Ansätze nochmal um die Ecke denkst, da ist es immer hilfreich, wenn man im Team nochmal irgendwie naive Leute hat, also Leute, die noch nicht so lange dabei sind oder Quereinsteiger sind und so und da kommt dann nämlich dieses Thema, diese Experimente, die dann halt auch schon zum Beispiel in einem agilen Projekt, der schon mal nach zwei Wochen ausgerollt werden könnte, sagen können, so, keine Ahnung, wir bauen jetzt hier eine, ich übertreibe, in Richtung Einfachheit,

Wir bauen eine Zinsberechnungsfunktion und wir implementieren jetzt aber drei verschiedene Varianten, weil wir noch nicht wissen, welche davon jetzt die richtige ist und tatsächlich kannst du sagen, da machst du zum Beispiel A, B, C Testing und das Wichtige ist, die müssen halt fehlerresistent sein, in dem Sinne von, dass du halt vorher dich fragst, was mache ich denn, wenn ein Fehler auftritt?

Dann kannst du dir solche Strategien zurechtlegen wie, naja, wir machen jetzt ein Monitoring, wenn eine von den Komponenten, eine von den Implementationen erhöhte Fehlerraten hat, dann nehmen wir die halt raus und lassen halt nur noch die anderen antworten und gucken dann, was irgendwie los ist oder was machen wir, wenn eine von denen irgendwie total die tolle Performance hat und macht, dass sie super skaliert, ja okay, dann committen wir uns halt zeitiger auf die.

Und das Interessante zum Thema Fehler ist halt, auf der einen Seite, du musst es so designen, dass irgendwas davon tatsächlich Fehler wirft. Sonst hast du nämlich deinen Optionsraum nicht ausreichend ausgesucht, wenn du nicht bis ans Ende und übers Limit gegangen bist. Und das finde ich ist halt zum Thema Fehlerkultur extrem wichtig.

ein Fehler ist an der Stelle nicht etwas, was

hoppla passiert ist, sondern

du designst das von vornherein,

dass da ein Fehler passieren muss,

weil sonst hast du nichts gelernt.

Und das finde ich ist nämlich dann, wenn

du sagst Lippenbekenntnis, ein massiver

Denkfehler, nicht ein, ja hoppla

ist halt passiert, dass da ein Fehler aufgeht,

sondern nein, nein, nein, wir setzen uns jetzt hier hin

und wir designen jetzt etwas, wo wir wissen,

wir wissen noch nicht, was die Antwort

ist. Und eine von den vier Sachen wird schief gehen.

Wir wissen auch noch nicht, welche. Aber irgendwas wird

schief gehen und wir bereiten uns auch jetzt darauf vor, von was

machen wir denn, wenn das schief geht? Und das war

für mich eine massive Erkenntnis zum Thema

ja, diese halbherzige Fehlerkultur

ist kaputt, weil

man denkt, Fehler sind immer noch etwas, was man

im Idealfall vermeiden kann und

das muss hingehen zu, Fehler sind etwas, was

ich provoziere, weil ich

erst dann den Auktionsrand so weit ausgeschöpft

habe, dass ich echte Innovation treiben kann,

dass ich eine echte Erkenntnis hatte.

Jetzt musst du vielleicht nochmal kurz dazu gehen, wie provoziert man

denn so einen Fehler und worum geht es dabei?

Ja, indem du Theorien aufstellst,

die sich widersprechen.

Du sagst halt, du hast

eine bestimmte Aufgabe

und du weißt noch nicht,

was die möglichen Ergebnisse sind.

Beispiel.

Bildlich gesprochen. Du bist irgendwo

mitten in einer Wüste und deine Aufgabe ist rauszufinden,

in welche Richtung geht es jetzt hier eigentlich ordentlich voran.

Ja, wo müssen wir hin?

Zum Wasser oder zum Meer oder?

Zum Wasser oder zum Meer oder was auch immer.

Dann schickst du also vier Leute

oder du versuchst rauszukriegen, wie weit

geht es denn hier eigentlich?

Und dann schickst du halt vier Leute

in vier Himmelsrichtungen

und jetzt kannst du entweder

sagen, naja, ich lasse die alle jeweils

einen Kilometer laufen

und dann zurückkommen,

dann können sie dir sagen, ja, hier geht es jeweils

in einen Kilometer Richtung. Schön.

Jetzt hast du aber noch nicht gelernt, wo hier Ende ist.

Das heißt, du musst im Prinzip

an der Stelle eher sagen, naja, du machst vier Experimente

und jedes davon läuft so weit,

bis es irgendwie mindestens irgendwo

anstößt. Und anstoßen kann halt, wenn du

Pech hast, heißen, da fällt jemand eine Klippe runter.

Und das wäre ja ein Fehler.

Er verdurstet in der Wüste dann.

Er verdurstet halt irgendwo in der Wüste.

Ja, das wäre vielleicht sogar ein Beispiel an der Stelle.

Und du weißt vielleicht,

ja, irgendwo ist eine Oase,

aber halt eben nicht überall.

Dann machst du halt Theorien und sagst,

naja, die höchste Wahrscheinlichkeit ist,

dass in einer von den vier Richtungen

irgendwo eine Oase ist,

aber es kann nicht überall eine sein.

Und damit müssen sich die,

die sich auf diese Expedition begeben,

darauf vorbereiten,

dass sie derjenige sind, der

keine Oase findet. Na, die verdursten. Was mache ich denn dann?

Ja, idealerweise

tun sie das halt nicht. Idealerweise überlegst

du dir ein Protokoll, wie die das halt, so, und

deswegen ist sozusagen diese Aussage, ja, ich

fange an, Dinge zu tun, wo ich,

du weißt bloß nicht, welcher von denen halt der ist,

der nachher das Problem haben wird. Und den

musst du ausrüsten mit Mechanismen, zu sagen,

so, okay, ich bin jetzt wirklich so weit gefahren, wie ich

konnte, jetzt brauchen wir halt, ich brauche hier Verstärkung,

irgendwer muss mich abholen. Und

das ist halt genau, dieses abstrakter gesehen

ist halt, du machst hier ein Portfolio,

Jede Theorie in sich muss schlüssig sein, die muss sein, die darf der Naturwissenschaftlichen nicht widersprechen, du musst einen Anhaltspunkt haben, wo du sagst, naja, irgendwo hat sowas eine Art schon mal funktioniert, es ist nicht völlig an den Haaren herbeigezogen, auch wenn wir sozusagen jetzt auf dieser Idee so lange rumhauen und so viele versuchen sie niederzumachen, irgendwie scheint es trotzdem noch eine gute Idee zu sein, dann sollte man das jetzt mal ausprobieren.

Und so kommst du halt zu einem Portfolio, wo du mit relativ wenig Aufwand und zeitlich kurzen Zyklus tatsächlich provozieren kannst, dass dir Feedback von dem Universum gegeben wird, was davon jetzt eine gute Idee ist und was nicht.

Das ist die Fail-Fast-Philosophie, oder? Das ist so, möglichst schnell zu einer Stelle kommen, wo es nicht weiter geht.

Genau, und aber wichtig an der Stelle auch parallel, weil deine Umwelt ändert sich, während du das machst.

Die Oase wandert, Vater Morgana.

Ja, ja, genau.

Ja, ja, ja, total.

Die, ähm,

ist mir gerade auch irgendwie der Faden

abhandengekommen an der Stelle.

Entschuldigung. Achso, doch, und du verstehst,

und du verschiebst auch die Diskussion

weg von, welches

ist die richtige Lösung,

ja, hin zu,

welche interessanten

möglichen Lösungen können

wir jetzt hier alle generieren,

ohne uns dann zu streiten, wer hier recht hat,

sondern es geht nur dazu, können wir möglichst viele interessante, ausprobierbare Lösungen generieren.

Eventuell ist nachher die tatsächliche Lösung, die man nimmt,

weil dann gibt es eine Technik, die man dann noch ansetzen kann,

wenn du dann das durchhast, dann kontrastierst du, was du aus diesen unterschiedlichen Lösungen gelernt hast

und kannst mit den realen, praktischen Erfahrungen dann eine neue Lösung tatsächlich generieren.

Und dann muss es nämlich nicht sein, welche von den vier Lösungen war jetzt eigentlich die richtige,

Ein Beispiel, um bei der Wüste zu bleiben. Keiner von denen ist zur Oase gekommen, aber der Typ, der nach Norden gelaufen ist und der Typ, der nach Osten gelaufen ist, hat gesagt, als ich fünf Kilometer nach Osten gelaufen bin, habe ich im Norden was gesehen. Und der andere sagt ja, als ich fünf Kilometer in den Norden gelaufen bin, habe ich im Osten was gesehen.

Das kannst du jetzt übereinanderlegen und weißt, aha, in der Distanz nordöstlich ist was. Keine der konkreten Lösungen war richtig, aber aus beiden Erkenntnissen konnte ich mir die richtige Lösung nachher generieren. Und wenn man sich aber die ganze Zeit nur darauf versteift hätte zu fragen, ist es jetzt richtig nach Norden, Süden, Osten oder Westen zu gehen, hättest du nie den Input gehabt, um dieses Ding im Nordosten zu finden.

Kann ich nochmal kurz eine blöde Frage stellen und zwar möchte ich gerne verstehen, an welchen Projekten man diese Methode am besten macht? Also du hast halt unbekanntes Problem oder du möchtest, also was möchtest du lösen bei dem?

Du hast ein Problem, dass du nicht a priori, also du bist in einer Situation, die so ungeordnet ist, dass du nicht a priori die Lösung festlegen kannst. A priori ist etwas, da neigen wir deutschen Ingenieure sehr dazu, ich kriege ein Problem, ich kenne meine Handlungsweisen, ich laufe meinen Optionsraum ab und ich präsentiere dir nach einer Woche irgendwie die Lösung.

Wenn das nicht der Fall ist, im Komplexen passiert dann typischerweise Folgendes,

dann kommt der nach einer Woche mit einer Lösung um die Ecke,

du implementierst die, sie besteht alle Tests

und in dem Moment, wo sie draußen in die Realität trifft,

fängt es an, rechts und links zu knarzen.

Und die Reaktion des Ingenieurs war,

ja, du hast mir zu engen Zeitrahmen gegeben,

hättest mich noch eine Woche arbeiten lassen sollen.

Oder du hast mir nicht alles gesagt.

Oder du hast mir nicht alles gesagt.

Nicht gut spezifiziert, genau, ja, ja.

So, aber, genau, so, aber aus der komplexen Perspektive

wird immer wieder ein komplexes Problem

retrospektiv als geordnet mit

ja, ich habe ja nur X vergessen.

Das Dumme ist nur,

du kannst dieses X nie a priori bestimmen.

Wenn du hättest ihm noch eine Woche mehr gegeben,

hätte es ein Y gegeben,

hättest du ihm noch eine Woche gegeben,

hättest du ein Z gegeben.

So, und das muss man halt umdrehen,

weil im Nachhinein kann man es immer erklären,

nur im Nachhinein,

also auf lange Sicht sind wir alle tot und so.

Was du dort halt tatsächlich machen kannst,

ist, du kannst, wenn du normalerweise

in einem ingenieursmäßigen Ansatz arbeitest,

sagen, okay, wir probieren das Problem klassisch über einen Expertenansatz innerhalb einer gesetzten Timebox zu lösen.

Und wenn das nicht geht, dann müssen wir diesen Modus wechseln.

Also so kann man ein Team, was tatsächlich gewöhnt ist, zu sagen, ja, da setze ich einmal hin, arbeite das Ticket ab und komme dann mit der Lösung raus.

Und wenn du dann diesen Effekt siehst von, ja, toll, alles ausdefiniert, alles abgearbeitet, super Codequalität, aber es tut nicht,

Dann solltest du dir die Frage stellen, gut, dann sollten wir jetzt hier mal vielleicht zwei, drei Varianten in die Breite ausprobieren und gucken, wo wir weiterkommen. Das ist ein möglicher Ansatz, wie man das machen kann. Also Engineering sollte sich immer einer Timebox eignen, weil er sucht ja im Prinzip nur aus bekannten Lösungen aus. Und wenn das Engineering aber anfängt, neue Lösungen zu entwickeln, dann musst du im Prinzip in diesen anderen Modus wechseln.

Das ist das, was man Unknown-Unknowns manchmal nennt, oder?

Das Ding, die wir nicht wissen.

Nee, das sind die Known-Unknowns tatsächlich.

Nee, nee, das ist ein Wir-Wissen-Jetzt-Schon.

Da ist etwas, was wir noch nicht kennen.

Ja, okay, wenn du die erste Timebox gemacht hast,

dann weißt du, dass es nicht geht.

Aber vorher weißt du es nicht.

Ja.

Die, und man kann viel machen, um es abzusichern.

Das sind diese solchen Kohärenztests eben mit diesem

Sind meine Lösungen irgendwie in sich schlüssig?

Widersprechen sie dem heliozentrischen Weltbild?

Solche Sachen.

Was ich noch spannend finde, ist

ein Ansatz, der auch so aus den

90ern fehlverstanden wurde, wo du gerade das

Wasserfallmodell meintest, war dieses

Rapid Application Development.

Das war so Ende der 90er, das waren so

Pascal-basierte Tools wie Delphi und

solche Formbilder etc.

Und Dave hatte mit denen tatsächlich was zu tun.

Der hat eine ganz interessante Story, was

eigentlich mit Rapid Application Development gemeint

war. Weil was

rausgeworden ist, ist auch wieder dieses

Ja, ich kann ganz schnell diese Formulare zusammenklicken

und habe dann eine fertige Anwendung.

Worum es eigentlich ging, war eine Methodik dahinter

und die ist aber aufgrund dieser sehr starken Technik-Fokussiertheit

von, ja, ich habe hier diese Formbilder weggefallen

und das war folgendes, das nennt sich ein Triple Eight.

Die haben bei der IBM für Kundenprojekte Folgendes gemacht.

Die haben vom Kunden vier Leute sich geholt,

die die Aufgaben, die die Problemstellung kennen,

Abrechnungssoftware irgendwie überarbeiten.

Haben vom Kunden die vier Leute an vier verschiedene Teams bei der IBM rangesetzt, jeweils mit so fünf, sechs Leuten.

Montag früh haben mit denen gesagt, so welche Features brauchen wir jetzt als allererstes und haben die halt entwickelt in so einem Rapid Application Ding.

Da hast du dann nach einem Arbeitstag so die ersten, so ja, hast du mal eine Tabelle und hast mal ein Formular und hast mal dies und hast mal jenes, das geht relativ zügig.

Dann haben sie diesen Code und das ist in vier Teams parallel passiert.

Jedes hat für sich gearbeitet, die durften nicht miteinander reden.

Dann haben die ihren Code eingecheckt und aus Europa nach acht Stunden an ein Team in den USA gegeben.

Und dieses Team in den USA hatte keinerlei Zugriff auf irgendwelche Formen von Spezifikationen, Kunden oder irgendwas.

Und hat nur die Aufgabe gekriegt von so, hier ist irgendwie Code, mach mal weiter.

Die haben sich das angeguckt mit, ah ja, okay, alles klar, die machen hier so Abrechnungskram.

Ja, okay, die Formulare, das würde ich ja so nicht machen.

Guck mal, das geht noch besser, das kann man so und so und so machen.

Die haben das wiederum nach acht Stunden abgegeben

und jeweils an ein Team in Asien gepackt.

Da hat sich das Team in Asien das Ding angeguckt,

wo jetzt sozusagen die Europäer mit dem Kunden,

danach der Ami ohne Kunde und dann der Asiate auch nochmal ohne Kunde

wieder drauf geguckt hat von, was wollten die eigentlich?

Was ist denn das? Hä? Okay, das machen wir gar nicht.

Machen wir mal so, so, so und so.

und so. Jetzt hast du zum einen

drei Kulturkreise durchlaufen.

Hast unterschiedliche Wirtschaftssysteme

durchlaufen.

Und am zweiten Tag, Dienstag

früh, hat deine Anwendung

viermal drei Iterationen

hinter sich. Jetzt gucken sich die Europäer das wieder

an, was aus ihrem Code geworden ist.

Schlagen die Hände über

den Köpfen zusammen?

Nee, und sagen so,

da hätten wir ja gar nicht dran gedacht. Dann gehen wir

zum Kunden und sagen, wie viel hältst du von X, Y und Z?

Und das haben die zwei Wochen am Stück gespielt.

Dann hast du dieses Projekt in vier Ausprägungen über 10 mal 3, über 30 Iterationen geprügelt und kontrastierst dann, was ist eigentlich in diesen vier Handlungssträngen rausgekommen, weil die ja auch noch nicht mal miteinander geredet haben über die Zeit.

Und dann setzt du dich hin und fragst so, was haben wir jetzt eigentlich gelernt?

und jetzt kannst du dich hinsetzen und kannst

sagen, so okay, jetzt suchen wir uns heraus, was

wollen wir hier eigentlich. Und das

war der ganze Charme von einem Rapid Application

Development Ansatz, so einen

hochgetakteten Zyklus zu fahren von

wie kriege ich eigentlich Erkenntnisgewinn.

Das ist die Innovationsgeschwindigkeit, das Buch dann, ja.

Diese Innovationsgeschwindigkeit ist

brutal.

Das hört sich so ein bisschen an wie das Startup-Modell

auf 11 aufgedreht. Wir machen jetzt vier Sachen

gleichzeitig und jeweils sind drei Schichten.

Das war Mitte der 90er,

aber das war nicht gedacht,

Das war nicht gedacht als ein Modell,

was im Dauerbetrieb funktioniert,

sondern das war gedacht als ein

Ansatz, um unter

wenn ich habe wenig Information,

viel Unsicherheit und muss irgendwie Entscheidungen

treffen für ein extrem teures

strategisches Projekt,

dann ist die Aussage, dann machen wir das jetzt mal zwei Wochen,

danach hast du mal so richtig Datenbasis.

Und dafür war

Rapid Application Development

halt wichtig. Da ging es nicht darum,

ein finales Produkt in der Hand

zu haben, was hochpoliert etc., sondern es war

darum, in so einer

Materialschlacht, in einer Personalschlacht

so schnell wie möglich

so viele Varianten wie möglich zu generieren

und das

hat mir die Augen geöffnet, weil ich saß ja

auch davor und habe in der Uni mit

diesen Rapid Application Development Tools so

ein Wasserfallmodell irgendwie versucht,

übergeholfen zu kriegen.