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

Ja, hallo liebe Hörer 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 Remote.

Und Remote dabei sind heute wieder zwei unserer Stargäste.

Und zwar der Christian und der Johannes.

Hi.

Hallo.

Vielleicht noch ein bisschen vorher am Anfang ein paar News aus der Szene einstreuen?

Ja, können wir eigentlich mal mit anfangen.

Genau.

Was gibt es denn Neues?

Der Christian hatte was Spannendes, glaube ich.

Ich hatte

eingeworfen, wart ihr eigentlich nicht beim

Python Camp dabei? Ich habe gerade überlegt,

dass ihr das gesagt hattet.

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

Self-Contained, Self-Bootstrapping

Anwendungen zu bauen

die man aber auch auf beliebige andere

Python-Pakete

einfach draufjagen kann

das war so ein kleines

interessantes Werkzeug für Leute, die in dem großen

Potpourri aus

wie kann man noch

das Projekt Environment

da reinwerfen

eine der wenigen Möglichkeiten, Virtual Env zu machen.

Ja, genau.

Ja.

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, aber dann eins wurde dann doch wieder aktualisiert,

dann ist das halt eine schöne Variante

um zu machen, dass niemand sich

drum 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 sie dann immer mit den absoluten Faden

aus dem Projekt raus auf

Okay?

Ich habe mich so ein bisschen in das, was Jochen mir gesagt 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 Envs immer so ein bisschen hakelig war,

muss man sich erst raussuchen, welche sind denn outdated

und kann man die jetzt upgraden oder nicht, aber

Poetry Update einmal testlich laufen 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

und ich weiß nicht so genau, woran das liegt.

Aber was halt da interessant ist, es gab tatsächlich eine neue PIP-Env-Release.

Und da sind einige interessante Geschichten dazugekommen.

Das heißt, 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 PipM saw 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.

Bei PipM stand halt so ein bisschen raus,

dass es da auch mal wieder so einen Übergang gab von

ich glaube, war das Kenneth Reitz,

der das Original entwickelt hatte

und er dann halt aber es auch

in der 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. Das ist keine Kritik

oder so, sondern es ist einfach was,

um die Überleitung hinzukriegen.

Erfolgreiche Projekte werden auch irgendwann beendet und so, ja, was unterscheidet denn irgendwie so ein Stück Software von einem Projekt, ja, das ist eine interessante Frage.

Sobald ihr damit seine News habt, müssen wir da mal drüber sprechen.

Ja, ja.

Ach du, du hattest auch noch nicht, oh ja.

Ja, ja, natürlich.

Ja, jetzt break ich hier wieder einfach so rein und mach trotzdem wieder News.

und zwar gab es einen Blog-Eintrag von

Kay Patterson, der geschrieben hat,

dass Async Python nicht faster ist und

da ein paar Benchmarks gemacht hat.

War ganz interessant, den werden wir mal in die Show Notes 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

kann ich mich auch nicht mehr so hart dran.

Ja, ja.

Also Sync ist schneller als Async,

ist die Aussage von diesem Blog-Post.

Ja, aber für was?

Ich kann ja einen Benchmark schreiben, der

beliebige Ergebnisse hat

Gute Frage, für was?

Hat die verschiedenen

Web-Server getestet oder verschiedenen Loads, je nachdem

wie viel Work an und wie viel True-Port

hast du irgendwie generiert

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

und 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, das ist ein schwieriges Thema.

Leute wissen nicht so genau, was sie meinen, wenn sie denn sagen, Async ist schneller.

Also insofern, ich würde auch sagen, 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, dann

kann das natürlich mit Async deutlich schneller sein, es kommt halt immer

drauf an, was man macht

also was man misst, also misst man die Zeit von

es fängt an, ein Request 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 dreht 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 du 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 Koroutine 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, ne, das finde ich völlig valide und

ich meine, ich würde jetzt sagen, mit Threads

kann man das ja auch irgendwie, sozusagen,

wenn man halt eine Queue und Logs, gut, ja, eben,

stimmt, braucht man also... Genau, 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 AsyncIO gegenüber

Threads und für mich die wichtigere

Kombination ist aber, dass du halt Fehler

Quellen eliminierst. Das Dumme

ist halt, Async ist jetzt auch nicht perfekt

und es programmiert sich manchmal auch

ein bisschen komisch, das ist halt so das

Rot-Blau-Problem,

das ist dann halt plötzlich,

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. Ja, aber

optimaler. Ja, alles Async.

Das ist die Lösung jetzt gerade.

Furchtbar.

Also ich mache das tatsächlich

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

jetzt muss ich parallel was machen, jetzt hole ich mal

für diesen Sub-Call-Tree

Async raus,

dann kommt dieser ganze Kram in Async und

danach geht es wieder zurück.

Ja, finde ich

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

wenn mich jemand gefragt hätte, was der

oder wo ich den Unterschied sehen würde zwischen

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

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

Gleiche, das 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 I.O.

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

eher 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.

Es gibt ja andere

Sprachwelten, halt gerade

JavaScript, Node.js.

JavaScript hat von der Sprache 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

und

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 sehr realisiert irgendwie

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 den 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 aufgehört,

da blickt man halt sehr schnell nicht mehr durch.

Da halt eine Balance zu finden, da müssen sich

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 ganz kurz erklären, was eine Promise denn überhaupt ist?

Weiß nicht, ob das jetzt super gut 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.

Ja, also man kennt, das ist auch eine Verallgemeinerung

von dem, 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 einen 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 denen dann

joinen. Das heißt, in deinem

Hauptprogramm kannst du irgendwie sieben Dinge anfangen,

kriegst dann die Thread-Objekte und kannst am Ende sagen,

und das Join wird in deinem Hauptthread wieder returnen, in dem Moment, wo der Thread sagt, ich habe mich beendet.

Und eine Future oder 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 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 es 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, jetzt hätte ich es gerne,

jetzt warte ich darauf, dass du fertig wirst.

Man kann aber auch in JavaScript inzwischen irgendwie Async-Await-Syntax,

die praktisch genauso aussieht wie in Python, verwenden.

Aber da kommt es dann sehr darauf an, welche

welche Bibliothekwelt man gerade lebt,

was es macht, oder Futures, oder

Await, oder Threads, oder

Timer, oder Callbacks.

Ja, ja. Und was man

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 anhaben.

Und mein Liebling, der mir bei Node

immer auffällt, und das passiert auch in Python,

aber halt auch, ist, wenn dann

irgendwelche 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 hier 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.

Wurscht.

Wir haben heute erstaunlich wenig

Last auf unseren Rädern. Ja, genau, aber

tatsächlich häufig ist es so, der Web-Server in dem

Ding antwortet dann für irgendwelche Status-Seiten

immer noch, ja, ich bin anwesend,

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

Mainloop durchbubbeln

und dann explodieren

und dann geht die Anwendung aus,

wird neu gestartet, kann sich zu Datenbank

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

Tourscript-Weltherzigen.

Aber das ist ja in Python genauso.

Also ich meine, die Sachen können ja auch in Python

abspringen. Aber da kann man jetzt vielleicht noch mal

einen Übersprung

zum Ausländer Dominik hat mal mehr News.

Wusch, wusch, wusch, Wackmanagement.

Weil

dieses ordentliche Handwerkszeug ist ja durchaus

sowas, 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 da halt das über

ü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 Stieferzettel 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 aussagen 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...

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 Volksmanagement.

Das ist eigentlich nur Bearbeiten von Tickets, dann stellst du dich hin

und Ticket, Ticket, Ticket, Ticket, Ticket, Ticket, Ticket.

Das ist aber kein Projektmanagement.

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 wird,

für das Infos,

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 anfangen.

Schalten wir einfach nochmal die gleichen Personen

über das gleiche Ding und hoffen,

dass es jetzt mal anders ausgeht.

Ja, ich war nicht dabei,

dass wir heute was anderes sagen.

Also ich kenne die Definition von Projekt so,

und Jochen unterhalten sich über die Programmiersprache Python

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 kann natürlich,

das Ziel kann natürlich sein... Arbeit ist

fertig. 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 das zum Beispiel

so ein Ziel? Ich kann jetzt 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?

Ja, das ist jetzt das Projektmanagement. 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 das Geschäft

als Profit machen. Und das ist super gut, weil du weißt

ganz genau, es geht vom 01.01. bis zum 31.12.

und dann guckst du

am 31.12. nach deinem 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

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 ein Wochenprojekt.

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

weil es ist ein zeitlich begrenztes Vorhaben, was ein definiertes Ziel hat.

Die Frage ist, wie sinnvoll ist das? Ist es 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 und wie was gemacht werden muss? Versuche ich alle Menschen bei Laune zu halten, um zu gucken, dass sie einfach arbeiten?

Was ist das? 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.

Sehr schön. Es gibt eine DIN für alles.

Es gibt die DIN

6901.

Die sagt, ein Projekt

ist ein Vorhaben, dessen Wesentlichen durch die

Einmaligkeit, aber auch Konstante der Bedingungen

wie ihre 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

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

als Beispiel für die größte Einheit,

die man sich denken kann.

Und ich finde es aber spannend, weil

dieses Thema Einmaligkeit und

Zielgerichtetheit heutzutage in

vielen 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 oder Vorhaben

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 das

eigentliche Produkt, also wenn da ein digitales Produkt

raus, entsteht jemand anderes, der das 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 haben wir das erreicht oder nicht, sondern es gibt mehr ein, ja, wir haben hier irgendwie

und Jochen unterhalten sich über die Programmiersprache Python

oder ich glaube nicht in der DIN, aber in der Literatur.

Das heißt dann Programmen 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 ich kenne das halt aus dieser ganzen Agile-Welt,

es gibt so ein magisches Dreieck 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 vergess ich auch manchmal.

Es gibt manchmal auch mal 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,

wenn wir 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.

So dass es halt irgendwie...

Gestern.

Ja, aber das ist doch die Aufgabe

des Projektmanagers, dafür zu sagen, dass es

gestern fertig ist.

Ja, aber das ist halt auch mehr spannend. Also es gibt ja

verschiedene Perspektiven, die ihr jetzt genannt habt. Es gibt halt die

Perspektive von dem Kunden

beispielsweise, der jetzt sein 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 abgeschlossenes Projekt, 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

Arbeitspakete hat.

Ich weiß nicht, ob ein Arbeitspaket ein geeignetes Maß ist, um ein Projekt zu managen?

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 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, all die sieben Sachen zusammenzubündeln und einmal durchzuprügeln,

um sie dann auch mal wieder

loszuwerden und sagen, jetzt brauche ich mich nicht mehr

drum 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 und Jochen das ganz unterschiedliches Gewicht ob da jetzt zum Beispiel 5000 Tickets rumliegen um die sich nie wieder einer k wird Da denke ich mir so das ist kein Problem

die machen wir einfach alle zu, als

haben wir erfasst, steht da drin, wenn man

mal irgendwann nochmal danach suchen

möchte von, haben wir schon mal nachgedacht

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

schon mal drei Sachen, warum waren 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

Reds.

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

die nicht ständig pflegen und machen und tun

und das

hilft halt den Leuten auch, wenn der 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, genau.

Also das kommt immer drauf an,

wer das halt macht. Also wenn die Kaffeemaschine,

da muss ich halt ü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 jeder, weil 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,

ah, 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 schreibe 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.

Ja, das 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

Das klassische Beispiel ist halt

ein Callcenter Mitarbeiter

der wartet

halt auf einen Anruf, der kann keine Tickets

bearbeiten, um es mal sozusagen bis in jemand

anruft und da hilft es auch

X, weil er 10 Tickets auf seinem Tisch hat, weil er halt

auf dieses Event warten muss.

Umgekehrt gibt es natürlich so Sachen, die

ongoing sind.

Du musst halt jeden Tag

die Post abholen

und du musst jeden Tag die Rechnungen

verschicken und du musst jeden Tag die Eingänge

prüfen und 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

macht.

Das kommt total drauf an, weil wir haben

und Jochen unterhalten sich über die Programmiersprache Python

auf einer Wiki-Seite sagen,

zu diesem Prozess gehört es,

dass einmal im Quartal jemand

irgendwie nachguckt, ob

im One Password irgendwie die

richtigen Leute drin sind oder noch Leichen

rumfliegen oder irgendwie sowas.

Und dann gibt es tatsächlich einen Con-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 2 Wochen, 4 Wochen

8 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 leicht gewichtiges

Es gibt ja auch Tickets, wo du

8 Wochen brauchst und ein Team

von 10 Leuten

zu bearbeiten und

da diese Spanne, finde ich auch was ganz

Spannendes, das ist auch das, was

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?

Da würde ich sagen, erfahrungsgemäß

sind die eher groß.

Also die Sachen

klassischerweise ja.

Die irgendwie dann einzelne

Entwickler macht oder so, die sind ja dann meistens, aber die nennt man

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.

Die fallen halt auf alte Projekte.

Ein Projekt ist einfach so eine kostenstelle.

Ein P raus.

Ja, wir haben halt die Herren S, A und P irgendwann mal.

Ne, 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 das hat 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 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

also immer

aber es war ein gutes

Vorjahrsmenschen

da merke ich auch, da versuche ich eher

anders an die Sachen heranzugehen, wir haben

ein bisschen den Vorteil, dass wir typischerweise

eben aus dieser

operativen Sicht kommen, wo eh alles

ein ongoing concern ist im Prinzip

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

und

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 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 Knevin mit C-Y-N-E-F-I-N

die Valiser haben sehr lustige

Ausspracheregeln, deswegen kommt da dann am Ende

Knevin 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

und Jochen unterhalten sich über die Programmiersprache Python

oder halt

eher bürokratische einfache geordnete Systeme, wo ich halt weiß, 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, so was in diesem Problem wäre denn etwas, was man mit

Expertenwissen erschlagen kann, wo sich jetzt

einer mal mit der Timebox eine Woche Zeit nimmt

und sagt, so, dick, lehne dir 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

in alle möglichen definierbaren Teile

zu gliedern, die dann entsprechend

schätzen und bepreisen, dann wirst 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

und die Technik.

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 ist es 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

und 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 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

Softwareentwicklung hat halt immer auch sowas

Exploratives dabei oder man weiß am Anfang

noch nicht wie die Lösung aussieht

Ja, naja, sag mal so, die Prinzipien,

also wie man das managt, ist halt

sozusagen fast umgekehrt. Also

bei so einem

Fast-Food-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 oder dick oder was auch immer.

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

Genau, das löst halt dieses...

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...

Oder genau.

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.

die gleiche der ist, umso besser

genau, du willst auch

wenig Variationen da drin haben

die

die

Seite bei der Softwareentwicklung

und Explorativen ist halt

solange du gar nicht weißt, was du tust

musst du ja erstmal an der Wirksamkeit

der Lösung arbeiten, du musst erstmal die Effektivität

herstellen, du musst erstmal fragen, tue ich ja eigentlich

das Richtige und ich meine

das willst du halt auch nicht

das ist jetzt philosophisch abstrus, ich muss sehr an die Simpsons

einen Jugendlichen, der immer beim

Hamburger Journalist sagt, du willst nicht, dass er sich die Frage stellt,

ob er hier gerade das Richtige tut.

Das willst du halt nicht.

Der kommt nachher auf die Idee,

seinen Lebenssinn eine Frage zu stellen.

Das wäre für den Ausdruck der Bürger

jetzt eher schwierig.

Nachher sagt er, ich will gar nicht arbeiten.

Ich würde sogar 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

halt explodieren, während wenn du sagst, naja,

es ist für mich leicht,

und Jochen unterhalten sich über die Programmiersprache Python

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 es 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 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 dieser Komplexen heißt es

unarticulated needs,

weil du halt das Problem hast, dass die Leute,

die das Zeug einsetzen, dir vorher,

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 von irgendeinem Produktmanager.

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 den Produktions... Also ich fand, genau, finde ich alles richtig,

und Jochen unterhalten sich über die Programmiersprache Python

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. So 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, dann sieht man das so als

zum Beispiel jemand, der so extern dazukommt und denkt

sich so, also da geht es irgendwie

nicht weiter und dann spricht man das an und dann

oft erst so informell und dann

kriegt man halt zurück, ja, das wissen wir

ja alles, aber das geht jetzt halt nicht

anders und das läuft schon so lange und

machen wir das lieber schrittweise, machen wir lieber Tickets

und so, dann denkt man sich so, ja, aber wo soll das hinführen?

Das geht nirgendwo hin, das ist

ein Dead-End-Ticket.

Ticket graben.

Das ist schon freigegeben.

Du hast schon die Freigabe, dann musst du es auch machen.

Ja, aber genau.

Und dann kann man...

Das ist halt dann aber nicht mehr, wenn das

nicht geht, dann...

Oder wenn einem die Leute sagen, wenn man dann sagt, okay,

probieren wir das einmal, dann sagen die, nee, das ist politisch nicht durchsetzbar.

Dann weiß man, okay,

hier ist ein 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 waren eigentlich die

letzte fiese Architekturfehlentscheidung,

die so passiert ist?

Und wenn Leute sagen, es ist nie passiert,

oder Projekt, das ist eine Sackgasse,

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 in eine Sackgasse zu laufen

und dann halt wieder umzudrehen.

Also, ja,

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 Kopf und in die drin

Ü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

negativ Beispiel gedacht. Es war eigentlich gedacht als

Beispiel von, so geht Softwaremanagement

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 hinaus gelesen

und nur dieses erste Diagramm ist das, was man

immer sieht. Und 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.

und hat dann ein paar SQL-Queries 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, die Änderung vom letzten Mal habe ich hier rot markiert.

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-Queries 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, also im Prinzip

war ich, ich war sein

Word-E-Mail-basierter

Postgres-Interpreter,

der dann immer zurück mit den

Fehlermeldungen von der Postgres-Stell kam.

Das war halt so eine

völlig, bis man das auch merkt, dass dieses

Customer Onset da völlig daneben gelaufen.

Es 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

vorstellst, die Kunden

wissen nicht, was man bauen kann.

Und das heißt, entweder sagen sie,

ja, es wäre schon gut, wenn man hier

Text eingeben könnte.

Ja, das konnte man 1970 schon.

und welche Person da auf dem Bild 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,

und dann denkt er sich halt aus, dass die Leute

es 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.

Das ist halt

es ist halt, wobei es auch ein

steckenpferden ist dokumental 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 AB-Testing

oder was kann man das so kurz sagen?

Ne, ja, noch nicht

mal. Du willst

ja nicht nur zwei machen, sondern du willst im Prinzip

was du machen möchtest, ist du willst

und Jochen unterhalten sich über die Programmiersprache Python

Es gibt eine gewisse Menge Widerspruch zwischen den unterschiedlichen Ansätzen.

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,

und die

und Jochen unterhalten sich über die Programmiersprache Python

und Jochen unterhalten sich die Programmiersprache Python 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 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 es muss hingehen zu Fehler sind etwas was ich provoziere weil ich erst dann den Optionsrahmen so weit ausgesch habe dass ich echte Innovation treiben kann dass ich eine echte Erkenntnis hatte

Ich muss 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's

denn hier eigentlich. Und dann schickst du

halt vier Leute in

vier Himmelsrichtungen

und jetzt kannst du entweder sagen, naja,

ich lass die alle jeweils einen Kilometer

laufen

und dann zurückkommen, dann können sie

dir sagen, ja, hier geht's jeweils in ein 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

einer von den vier Richtungen irgendwo in 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...

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 musste ausrüsten mit Mechanismen

zu sagen, okay, ich bin jetzt wirklich so weit gefahren,

wie ich konnte, jetzt brauche ich hier

Verstärkung, irgendwann muss ich 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,

irgendwo hat sowas in der 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 irgendwie eine gute Idee zu sein,

dann sollten wir das jetzt mal ausprobieren.

Und so kommst du halt zu einem Portfolio,

wo du mit relativ wenig Aufwand

einen 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

Pale-Fast-Philosophie, oder?

Das ist so, dass sie 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, genau.

Ja, ja, ja, total.

Die,

ist mir gerade auch

irgendwie der Faden abhanden gekommen an der Stelle.

Entschuldigung.

Und du verschiebst auch

die Diskussion weg von

welches ist die richtige Lösung

hin zu

welche

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 durch hast, 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 da muss es nämlich nicht sein, welche von den vier Lösungen war jetzt eigentlich die richtige.

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, 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 hast du ein unbekanntes Problem oder 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,

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.

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ätte es ihm noch eine Woche gegeben

hätte es ein Z gegeben

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 hier 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 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.

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 diese andere

in diesen anderen Modus wechseln.

Das ist das, was man Unknown Unknowns

manchmal nennt, oder?

Die Dinge, die wir nicht wissen.

Nee, das sind die Known Unknowns tatsächlich.

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 die solchen Kohärenztests

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

ist 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 raus geworden ist, ist auch wieder dieses

ja ich kann ganz schnell diese Formulare zusammen klicken und habe dann eine fertige Anwendung

worum es eigentlich ging, war eine Methodik dahinter

und die ist aber aufgrund dieser sehr starken Technikfokussiertheit von

ja ich habe 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

und haben mit denen gesagt, 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, heißt für 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 und durfte nicht miteinander reden.

Dann haben die ihren Code eingecheckt und aus Europa nach 8 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

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

und die haben das wiederum nach 8 Stunden abgegeben und jeweils an ein Team in Asien gepackt.

Dann 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 ja eigentlich, was ist denn das, hä, okay, das machen wir gar nicht,

und Jochen unterhalten sich über die Programmiersprache Python

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 du, 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?

Also die Innovationsgeschwindigkeit ist hoch, oder?

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

als ein Modell,

was im Dauerbetrieb funktioniert, sondern das war gedacht als ein Ansatz um, 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 und 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.

Und dann hörst du plötzlich von dieser

Story, IBM hat ja diese Sprachen

mitentwickelt. Und das war aber dieses

zweigleisige Ding von, wir wollen hier

diesen Prozess fahren können

und dieser Prozess hat es aber nie geschafft,

irgendwie mal außerhalb

angewendet zu werden und dann

bleibt aber trotzdem über mit, na jetzt haben wir so Tools,

die können wir ja verkaufen.

Tja.

Ja, das ist halt,

wenn man viele Ressourcen hat, kann man da Sachen

erschlagen und man muss die dann

auch nutzen.

Das kann man aber auf den Kleinen machen.

Vielleicht ist jetzt irgendwie ein ganz guter Zeitpunkt,

das nochmal so zusammenzufassen, was hast du gerade

Rapid Application Development irgendwie gesagt?

Es gibt ja noch so mehrere andere Methoden oder

oder Methodologien, die man irgendwie kennt.

Ja, da gibt es ganz viele.

Vielleicht können wir über die eine oder andere nochmal sprechen,

vielleicht nochmal Extreme Programming und oder Scrum

mal kurz erklären für unsere Hörer, was das

eigentlich so ist und wie man das so macht und vielleicht

ein, zwei Probleme damit aufmachen oder

wie ihr das so gerne macht oder

ist das eben auch von Flo

Schad oder was gesprochen, was ist das,

macht ihr einen Kampanenwunder?

Vielleicht kann man da irgendwie

einmal kurz durchgehen.

Sollen wir mit Scrum einfach anfangen?

Ich glaube, wer kann am meisten so zählen?

Jochen hat da glaube ich ganz viele... Ich glaube man muss mit

XP anfangen, oder? XP ist zeitlich früher

und Scrum ist dann das nächste. Ich würde die

alle zusammenfassen zu

das ist halt so Agile, genau.

Oh Jochen, jetzt setzt du dich aber ins

Nestle. Ja, ich glaube da so

groß sind da die Unterschiede gar nicht.

Also der Spirit ist irgendwie... Oh, jetzt setzt dich immer

weiter in die Nestle, da werden da ganz viele Leute

Also für freundliche

Zuhörer-Rants bitte

Jochen, Python-Podcast-Punkt.

Er nimmt die Hate-Mail sehr gerne

Wir lassen sie dann von Sarah Bosetti filtern und lesen die Headmail aufgeschüttet.

Hallo, es heißt podcast.de

Also Jochen, dann fass doch mal zu sagen, was agile Methoden sind.

Ja, ich würde sagen, das Agile Manifesto ist ja schon ein guter Startpunkt.

Das kriege ich jetzt auch nicht so aus dem Kopf rezitiert, aber die wichtigsten Punkte sind halt sowas wie,

und

genau

ja

ähm

weiß jetzt nicht

Ich meine, ich kann es kurz vorlesen, ich habe es gerade da.

Das Original sagt also,

we are uncovering better, deswegen, da fange ich auch immer wieder an,

die meisten überspringen das,

we are uncovering better ways of developing software

by doing it and helping others do it.

Through this work we have come to value

individuals and interactions

over processes and tools,

working software over comprehensive documentation,

customer collaboration over contract negotiation,

Responding to Change over Following a Plan.

That is, while there is

value in the items on the right,

we value the items on the left more.

Das ist eigentlich ein sehr versöhnliches Manifest.

Es ist ein Unglaub, und es ist

so aktuell eigentlich, wenn ich es halt

neben diese

industrialisierten Varianten von

Agilität halte. Ich habe es

wirklich lange Zeit nicht angeguckt.

Ich habe es bestimmt zehn Jahre nicht in der Hand und im letzten halben Jahr

immer mal wieder rausgeholt. Es ist

aktueller denn je.

Das stimmt, da habe ich tatsächlich eine kleine Anekdote dazu

Ich habe mal, als ich mein Studium fertig hatte, wollte ich gerne noch ein bisschen an der Universität bleiben

Deshalb habe ich eine Doktorarbeit angefangen

Und die Doktorarbeit beschäftigte sich so im Großen mit Projektportfolio-Management

Das ist quasi eine Ebene drüber, das ist nicht Management eines einzelnen Projektes, sondern Management vieler Projekte

Also welche Projekte mache ich überhaupt, welche sind wichtig, wie priorisiere ich die, in welche Reihenfolge sind die und so weiter

und ich habe relativ lang Literaturrecherche

gemacht und habe

dann diese Doktorarbeit wieder abgebrochen,

als ich ein Paper

gefunden hatte mit dem Titel

Are we getting any better? Comparing

Project Management in the years 2000 and 2008.

Super Paper,

rate ich jedem zu lesen.

Die kurze Form

ist

Nope.

Sie haben viele Projekte untersucht,

im Jahr 2000 und im Jahr 2008

und wenn man die Leute in den Projekten befragt, dann sagen die, ja, das ist jetzt alles viel besser.

Wenn man aber die Ergebnisse der Projekte anguckt, dann hat sich eigentlich nicht viel getan.

Und wir haben die Zufriedenheit erhöht.

Genau, wir haben die Zufriedenheit erhöht. Das ist ja auch schön,

aber es ist nicht das, was man eigentlich erreichen wollte.

Und das war für mich so ein bisschen der Punkt, wo ich mir gesagt habe,

okay, viele Sachen, die man hört im Projektmanagement und viele von diesen Methodologien,

die sind sehr dogmatisch

und die sind sehr, ihr müsst es so machen

und ihr müsst es so machen und da gehören Scrum und XP

absolut dazu, die haben sehr sehr strikte

Regeln, also es gibt quasi niemanden der ein echtes

Scrum macht, es gibt niemanden der

echtes XP macht

weil die einfach so super strikt

sind, dass man die pragmatisch nicht befolgen kann

Ja also tatsächlich

sie widersprechen

dem Manifesto auch im Prinzip dadurch

Ja natürlich, total

Oft wenn man sagen würde

das ist ja nicht so gemeint, dass man das jetzt einfach nur

als Regelwerk nehmen nehmen nehmen nehmen nehmen nehmen nehmen nehmen nehmen nehmen nehmen nehmen nehmen

der Weg hin zu weniger Projektmanagement ist mehr Projektmanagement, was ja durchaus dem Agile Manifesto auch entspricht

und das ist der Punkt, worauf ich raus will

das Agile Manifesto ist deshalb immer noch relevant

weil wir

Probleme lösen, die

weil wir versuchen Probleme zu lösen

die wir aber nicht lösen

wir machen immer mehr Projektmanagement, in Firmen ist

Projektmanagement so

ungeheuer wichtig, dass

man dem nicht entkommen kann

im Endeffekt löst es aber die Probleme.

Aber das ist doch wieder spannend.

Wir haben jetzt immer noch nichts über die Methoden gesagt, aber das hört sich

so an, als wäre Projektmanagement,

gutes Projektmanagement quasi so, du musst

dafür sorgen, dass sich die Menschen, die für dich

arbeiten, gut fühlen und wohl fühlen,

dann wird das schon irgendwie.

Nee, überhaupt nicht. Das ist das, was die Methoden

machen.

Gutes Projektmanagement sorgt dafür, dass die Projekte

erfolgreich sind, egal wie die

Menschen gehen.

Aber Projekte werden halt von Menschen.

Da würde ich auch...

Ich möchte nicht missverstanden werden

Die Menschen machen ja die Projekte

Das heißt, du kannst nicht dafür sorgen, dass Projekte

erfolgreich werden, zumindest nicht auf lange Sicht

wenn du die Menschen dabei kaputt machst

The gaming industry would like to differ

Ja, wobei die ja auch

Ja, auch die machen so langsam auf

Auch die

haben schon ihre herben Rückschläge gehabt

Genau, da würde ich

gerne einhaken, weil

das halt auch so ein

Ja, so ein fundamentales Problem ist irgendwie so, je älter ich werde, so am Anfang, ich war auch sehr, ich war da, ich habe tatsächlich mal irgendwie diese Agile-Geschichte halt im Unternehmen, also mit sehr dafür gearbeitet, dass das da umgesetzt wird.

Ich dachte, ja, das machen, wir folgen jetzt die Regeln einfach nur alle auf 100 Prozent wie in XP, das ist alles.

Ja, wird es schon gehen.

Und dann in ein paar Monaten funktioniert das ja alles, das hat dann irgendwie ein paar Jahre gedauert und das war ein eher schmerzhafter Prozess.

und

es hat schon irgendwie funktioniert,

aber es war alles nicht so rosig

und irgendwie je älter ich werde, desto mehr

habe ich so das Gefühl, es ist nicht so

beim Management von diesen Dingen

nicht so sehr

die Frage, wie man das macht,

sondern die Frage, wer das macht, ist auch sehr, sehr

wichtig.

Ja klar und das ist auch so ein bisschen das,

was da rauskommt. Du kannst dir ganz viele Regeln

ausdenken, aber die funktionieren nicht, weil das halt

Menschen sind, die die Projekte machen.

und du musst dafür sorgen, dass die Menschen,

die die Projekte machen, die Projekte

erfolgreich machen. Und das heißt,

da ist immer diese menschliche Komponente

dabei. Du musst die richtigen Menschen finden, du musst die

Menschen richtig dazu bringen, die

Sachen zu machen und dann am Ende, wenn du das geschafft hast,

musst du auch noch dafür sorgen, dass du die richtigen Projekte

machst.

Ja, es ist nicht ganz einfach und ich bin

auch zunehmend pessimistisch,

was die

Möglichkeit angeht,

das Verhalten von Leuten so großartig

zu verändern. Ich meine, auch wenn man

jetzt irgendwie sich zum Beispiel Kinder anguckt.

Und also ich meine, so als Eltern

ist man ja wahrscheinlich so in der

privilegierten Position,

ja, sozusagen man

hat die

maximale Möglichkeit,

Dinge zu beeinflussen eigentlich. Also besser wird's nicht.

Also ich glaube, Manager haben wesentlich weniger

Zeit, Energie und

was sie da reinstecken können, um halt

das Verhalten zu modifizieren. Und selbst bei Kindern,

naja, ich bin mir nicht immer so sicher,

ob das gut funktioniert.

Ein bisschen kann man schon ändern, aber

so grundsätzlich.

Ja, und ich fürchte,

wenn man jetzt als Manager die Vorstellung hat,

man ändert irgendwie das Verhalten von Leuten grundsätzlich

oder macht Leute zu anderen Personen oder

das funktioniert einfach nicht.

Ja, das glaube ich auch nicht.

Deshalb sage ich ja, du hast diese menschliche

Komponente dabei, du musst dafür sorgen, dass die

Menschen, die du im Projekt hast, die

richtigen sind und dass die die Sachen so machen,

dass sie sehr erfolgreich sind.

Und das wird immer unterschiedlich sein.

Es wird immer unterschiedlich sein, je nachdem,

welche Projektteilnehmer du hast.

Es wird keinen Hamburger Prozess geben, wo hinterher immer der gleiche Hamburger rauskommt

und selbst wenn du so einen Prozess findest, dann wird es halt immer der gleiche schlechte Hamburger sein

und jetzt bin ich rausgefallen

Ich bin nicht rausgefallen

Ich müsste mich kurz

müten, weil hier mein Drucker angefangen hat

Ich würde aber mal reingehen, weil da kann ich

tatsächlich noch eine völlig andere Ecke mit reinwerfen, das sind die

Manager Tools,

weil da gehen wir jetzt weg von

Projektmanagement über zu

Management allgemein.

Was wir relativ

viel benutzen ist tatsächlich

einen Ansatz

von

ja, die heißen managertools.com

die haben irgendwie

anderthalb tausend Podcasts

veröffentlicht.

Ja, einmal diesen sehr

straightforward Punkt.

Es sind so zwei irgendwie Ex-Militärs

und die haben aber tatsächlich dieses Thema

wo Jochen und ich eben so ein bisschen kurz aufschreien wollten

zum Thema ja Hauptsache die Projekte sind erfolgreich

die haben sich halt diese klassische Management-Theorie

relativ gut weiterentwickelt

mit der Aufschrift von

die zwei Aufgaben des Managers sind

Results and Retention

Und welches ist wichtiger?

Ich versuche gerade rauszukriegen, was der Dominik mir sagen will.

Du hast dein Mikrofon gerade von deinem Mund entfernt und seitdem bist du leiser als vorher.

Entschuldigung, alles klar, danke.

Was ist wichtiger, Results oder Retention?

Ne, es kommt her aus der Industrialisierung, da war die Managementaufgabe tatsächlich Results.

Stimmt ihr dazu?

Genau, und das alleine reicht halt eben nicht, weil das halt keine langfristige Perspektive hat.

und aber auch die Management-Theorie aus Mitte des 20. und frühen 20. Jahrhunderts weiß schon, dass eine Organisation halt auch ihr langfristiges Wohl im Auge behalten muss.

Das heißt, du musst die Fehler, die du durch eine reine Result-Orientierung erzeugen würdest, durch eine entsprechende Retention der Personen, die du halt hast, balancieren.

und das ist dann eben genau die Aufgabe eines Managers,

das gut in den Einklang zu bringen,

zu gucken, dass dein Team

funktioniert und zwar auch

für die Menschen funktioniert,

weil ohne die Menschen geht es halt nicht,

aber eben mit den Menschen zusammen entsprechende

Ergebnisse zu erzielen.

Kannst du vielleicht nochmal ganz kurz definieren,

was Retention ist?

Retention heißt, die Leute, die für dich

arbeiten, bleiben dir erhalten.

Wenn du nur Results erzeugst,

dann verschleißen die Leute, dann gehen sie entweder

oder werden krank oder was auch immer.

Das ist so Industrialisierung

Wenn die Masse an Arbeitern unendlich ist

an Arbeiterinnen, dann hast du

Wenn du genügend Nachschub hast

an Jugendlichen, die Burger machen

oder an jungen Männern, die Computerspiele machen wollen

dann kannst du das machen

Selbst bei den Burgern

ist es so, wenn du ein eingespieltes Team hast

bist du effizienter

und kannst mehr erwirtschaften, als wenn du ein Team hast

das ständig wackelt

und wo alle gegen dich arbeiten

im Prinzip, weil sie halt irgendwie ihres Jobs nicht

sicher sind etc. Und

diese Balancierung halt bewusst wahrzunehmen

als Aufgabe, das hat

uns nochmal ganz schön geholfen, die bauen da relativ viel

Zeug dann

drumrum und haben auch viel Guidance für Leute, die

sich jetzt so für Management allgemein interessieren.

Wichtig ist auch, das ist halt keine

irgendwie mal schön sich

ausgedachte Theorie, sondern es ist

halt relativ offensichtlich, weil wenn Mitarbeiter

wieder verloren gehen, geht halt

Organisationswissen verloren.

Da gibt es auch ganz alte

und Jochen unterhalten sich über die Programmiersprache Python

Leute neu reinzukriegen und Wissen neu in die Organisation reinzuholen, ist so unendlich teuer und fragil, dass halt Leute aus einer Organisation loszuwerden oder zu verlieren, ist halt einfach mal, das ist prohibitiv, das geht nicht. Du musst dich halt darauf einstellen, das ordentlich zu machen.

Tja, naja.

Ja, ich würde

auch sagen, ich weiß nicht genau, also ich kann

das verstehen, dass man sozusagen dann so Turnover

versus

Ergebnis irgendwie

vielleicht gegeneinander, aber ich weiß

gar nicht, ob das so eine richtige Dichotomie,

gibt es dafür eigentlich einen deutschen Ausdruck für Vollst Dichotomie?

Keine Ahnung,

fällt mir jetzt keiner ein, ehrlich gesagt,

weil im Grunde

setzt man da ja voraus,

dass die einzige Möglichkeit, das

Ergebnis zu verbessern,

daran besteht, halt irgendwie

pro bezahlter Stunde

mehr Produktivität aus den Leuten zu

pressen.

Ja, nee, eben nicht. Es geht eben darum, eben nicht eine Dichtung

Mietraus zu machen, sondern

es als komplementäre Aufgabe anzusehen.

Ja, genau, weil

ich denken würde, man kann nämlich auch genau das

andere machen. Man kann halt versuchen, einfach,

dass die Leute pro Stunde produktiver werden,

das Ziel zu verfolgen. Und das ist

halt eben nicht damit verbunden,

dass die Leute langfristig

irgendwie, weiß ich nicht, irgendwie

in den Wörtern ausgehen oder verschwinden oder keine Lust mehr haben.

Du musst es nur in der Management-Theorie als explizites Ziel des Managers machen,

weil alles, was du zum Ziel aufrufst, und das ist bei Menschen nun mal so,

und deswegen ist auch, da macht man fast eine Schleife zum Anfang zurück,

zum Thema Zielorientierung.

Wenn du einem Menschen ein Ziel gibst, dann wird er das gnadenlos verfolgen.

Gnadenlos.

Wenn du dem Manager sagst, dein Ziel ist Results, Results, Results und du gibst ihm noch was, was gemessen werden kann, dann wird er den Teufel tun und das Ding optimieren. So schlimm, dass im schlimmsten Fall sogar der Messwert dich anlügt, aber er hat sein Ziel erreicht.

Ja, du kannst mal ein paar Stellen wegrationalisieren im Krankenhaus, dann hast du als Manager einen tollen Bonus, weil du hast was gespart.

und dabei geht es

tatsächlich darum, du musst in der Organisation

das Bewusstsein schaffen und auch bei den Leuten,

die das tun, dass sie an beidem gemessen werden.

Dass sie sowohl daran gemessen werden,

kontinuierlich

Ziele zu erreichen und

aber ein sozusagen

inhärent verankertes Ziel, also das

Metaziel ist die Zielerreichung

und das zweite

Metaziel daran ist aber halt währenddessen

die Organisation nicht kaputt zu machen.

Wie macht man denn diese Verantwortung? Wie schafft man

das? Das ist ja spannend.

Indem du auf die Menschen

eingehst, die da drin sind

Das kommt immer wieder runter auf die Menschen

Das ist für mich das

einzige Ergebnis, was ich aus dieser ganzen Zeit

sehen kann, das kommt immer auf die Menschen an

Aus einer Firmenperspektive nochmal sehen möchte

Wie schaffe ich es denn, dass ein Projektmanager

die Verantwortung gegenüber den Menschen

wahrnimmt? Also ich muss den ja irgendwie

Accountable, Responsible halten dafür, was da passiert

Also messe ich die

Retention Rate oder

Ja, die kannst du ja einfach messen

eine Mitarbeiterbefragung über glückliche

Zufriedenheit, keine Ahnung.

Das kannst du machen. Also die

gehen halt eher von einem prozessualen Ansatz aus

und du solltest

halt das Ziel, also das Problem ist sozusagen,

wenn du ein

Messwert zum Ziel machst, wird er halt

gamifiziert. Das heißt,

da musst du immer aufpassen, dass die

Feedback-Schleife nicht direkt

ist weil dann wird sie halt immer ausgenutzt werden Bei den Manager ist es so wir haben uns das halt auch angew wir haben in der Mitarbeiterf an der Stelle f einen Manager der hat drei Werkzeuge

die ihm dafür zur Verfügung stehen und die er zu nutzen hat. Das eine ist

Beziehungspflege über sogenannte One-on-Ones, das heißt jeder Mitarbeiter von uns hat

das Recht und der Manager hat die Pflicht, mit jedem Mitarbeiter einmal

die Woche ein 30-minütiges One-on-One zu führen. Da gibt es auch eine

entsprechend inhaltliche Struktur, dass der Mitarbeiter auf jeden Fall einmal die Woche zehn Minuten die

ungefilterte, ungeteilte

Aufmerksamkeit seines

führenden Managers hat, der wiederum sich gefälligst vorbereitet und Themen, die

arbeitstechnisch, die

organisationstechnisch, die vertraglich, die von der persönlichen Weiterentwicklung abhängen, mit ihm zu besprechen, zu dokumentieren.

Das ist ganz spannend, weil daraus bei uns nämlich auch

und wir haben tatsächlich dann so 75% davon schaffen war.

Mein Drucker springt schon wieder an.

Den müssen wir irgendwie rausfiltern.

Und das Spannende ist, aus dieser Struktur heraus ergibt sich dann zum einen,

ich bin immer verwundert, wenn ich mit anderen Leuten rede,

wenn die fragen, wie oft hast du exklusiv mal Zeit mit deinem Chef über irgendwas zu reden,

dann ist das häufig relativ wenig.

Und wenn ich ihnen sage, das machen wir irgendwie jede Woche,

dann fallen irgendwie alle aus allen Wolken.

Deswegen würde mich auch mal interessieren, wie das bei euch so ist

Das ist sehr ungewöhnlich, glaube ich

Also sieht man nicht so häufig

Und es ist so ein Riesenwerkzeug, weil zum Beispiel

sowas wie ein Jahresgespräch

ist bei uns kein Jahresgespräch, sondern

wird getriggert durch

Es kommt spätestens nach

zwölf Monaten

wenn es dazwischen kein

Leistungsgespräch gab

Leistungsgespräch ist eine blöde

Übersetzung von dem englischen Begriff

den die haben

oder wann immer sich in der Rolle, in der Tätigkeit des Mitarbeiters etwas strukturell ändert.

Das heißt zum Beispiel nach sechs Monaten, wenn deine Probezeit vorbei ist,