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.
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.
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
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.
Ja, das kann man aber auf den Kleinen machen.
Vielleicht ist jetzt irgendwie ein ganz guter
Zeitpunkt, irgendwie mal das nochmal so zusammenzufassen,
du hast ja gerade Rapid Application Development irgendwie gesagt,
Es gibt ja noch so mehrere andere Methoden oder
Methodologien, die man irgendwie kennt.
Vielleicht können wir über die eine oder andere
nochmal sprechen, vielleicht nochmal Extreme Programming
und oder Scrum irgendwie 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 irgendwie aufmachen oder wie ihr das
so gerne macht oder
du hast eben auch von Flowchart
oder was gesprochen, was ist das, macht ihr einen Kampanen?
Da gab es ja ganz viele verschiedene Methoden.
Ja, vielleicht kann man da irgendwie
einmal kurz durchgehen.
Wollen wir mit Scrum einfach anfangen?
wer kann am meisten so zählen? Jochen hat da, glaube ich, ganz viele
Teams. 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, äh, das ist halt so
Agile, genau. Oh, Jochen,
jetzt setzt du dich aber ins
Nesseln. Ja, ich glaube, da so groß sind da die
Unterschiede gar nicht. Also der
Spirit ist irgendwie... Oh, jetzt setzt du dich immer weiter in die Nesseln.
Da werden ja ganz viele Leute... Also für
freundliche
Zuhörer-Rants bitte, Jochen,
der Podcast-Punkt.
Er nimmt die
Hate-Mail sehr gerne entgegen.
Wir lesen die, wir
lassen sie dann von Sarah Bosetti filtern und
lesen die Hate-Mail dann auf
geschönt. Hallo, erbeißenpodcast.de
Also Jochen, dann fass doch mal zusammen,
was agile Methoden sind. Ja,
ich würde sagen, das Agile Manifesto
ist ja schon irgendwie ein guter
Startpunkt. Das kriege ich jetzt
auch nicht so aus dem Kopf rezitiert,
aber die wichtigsten Punkte
sind halt sowas wie,
dass halt
Interaktion mit dem Kunden wichtiger ist, als
irgendwie Pläne zu befolgen, dass
halt irgendwie funktionierender Code wichtiger ist
als halt ausführliche
Dokumentation.
Kurze Zyklen?
Ja, genau, dass man das irgendwie
iterativ macht.
Sich auf Änderungen einzustellen ist wichtiger
als dem Plan zu folgen.
Ja, genau.
Ja.
Wo ist es jetzt nicht?
Ich meine, ich kann es
kurz vorlesen, ich habe es gerade da.
Das Original sagt also,
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 why 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 hatte es bestimmt 10 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.
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 welcher Reihenfolge sind die? Und so weiter.
Und ich habe relativ lange 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,
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.
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 widersprechen
sie widersprechen dem Manifesto auch
im Prinzip dadurch. Ja, natürlich, total.
Also ich würde auch oft, wenn man
sagen würde, Leute, das ist ja nicht so gemeint,
dass man das jetzt einfach nur als Regelwerk
nehmen und dann einfach blind anwenden soll.
Ja, aber dann würden die Scrum Master widersprechen.
Die Scrum Master sagen, Scrum ist nur, wenn du alle
Regeln befolgst. Und du hast ja ein Zertifikat
dafür gekriegt.
Ja, natürlich. Das kriegst du nur, wenn du alle Regeln
befolgst.
Wie gesagt, wenn du diesen ganzen
Dingen folgst, dann
fühlt es sich so an,
als ob du viel erreicht hast. Dann fühlst du dich
besser mit deinem Projekt. Aber das Projekt selber
ist dadurch nicht erfolgreich geworden.
Die Projekte, die du machst, sind nicht erfolgreich geworden.
Das war für mich so ein bisschen
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,
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 nicht.
Aber das ist doch wieder spannend.
Also 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 wohlfühlen,
dann wird das schon irgendwie.
Nee, überhaupt nicht. Das ist das, was
die Methoden machen.
Das gute 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...
Ganz kurz.
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 hellen 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, wir folgen jetzt die Regeln einfach nur
alle auf 100 Prozent, wie in XP,
das alles. Da wird es schon gehen.
Und dann in ein paar Monaten, es funktioniert
jetzt 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, irgendwie das Verhalten von Leuten
irgendwie 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 es 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 so sicher, ob das gut
funktioniert. Das ist so, 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.
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.
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.
Ne, ich bin nicht rausgekommen.
Ne, ne, nur aus dem Web.
Ich müsste mich kurz
muten, weil hier mein Drucker angefangen hat,
die zu drucken.
Ich würde aber tatsächlich 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
manager-tools.com, die haben
irgendwie anderthalb tausend
Podcasts inzwischen 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 darfst dein Mikrofon gerade von deinem Mund entfernen
und seitdem bist du leiser als vorher.
Entschuldigung, alles klar, danke.
Was ist wichtiger? Results oder
Retention.
Das kommt her aus der Industrialisierung.
Da war die Managementaufgabe tatsächlich
Results.
Und Results alleine...
Stimmt ja dazu.
Und das alleine reicht halt eben
nicht, weil das halt keine langfristige
Perspektive hat. Und aber auch die
Managementtheorie 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 die 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 irgendwie...
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.
Aber auf der Entwicklung gibt es halt nicht genug.
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, was ständig wackelt
und wo alle gegen dich arbeiten im Prinzip, weil sie halt ihre Jobs nicht sichern, etc.
Und diese Balancierung halt bewusst wahrzunehmen als Aufgabe, das hat uns nochmal ganz schön geholfen.
Die bauen da relativ viel Zeug dann drumherum und haben auch viel Guidance für Leute,
die sich jetzt auch 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 dir verloren gehen,
geht halt Organisationswissen verloren.
Da gibt es auch ganz alte Anekdoten von irgendwie,
ich glaube, einer der IBM-Manager war das oder so,
wo irgendeiner seiner höherrangigen Angestellten,
glaube ich, eine halbe Million Dollar in den Sand gesetzt hat
und er gefragt wurde, ob der jetzt endlich gekündigt wird.
Und er guckt ihn dann halt an und sagt,
du bist bescheuert, ich habe gerade eine halbe Million Dollar
für ein Trainingsprogramm für diesen Mann ausgegeben.
der hat was gelernt, das gebe ich
halt nicht meinem Wettbewerber. Bist du blöd?
Und
das ist halt tatsächlich,
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.
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 ist.
Gibt es dafür eigentlich einen deutschen Ausdruck für False 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,
darin besteht, halt irgendwie
pro bezahlter Stunde
mehr Produktivität aus den Leuten zu
pressen ist.
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
die irgendwann ausgehen oder verschwinden
oder keine Lust mehr haben.
Du musstest nur in der Management-Theorie
musstest 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 machen wir fast eine Schleife zum Anfang wieder 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 eben ein paar Stellen wegrationalisieren im Krankenhaus.
Dann hast du als Manager einen tollen Bonus, weil du hast was gespart.
Genau, 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
da dran 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?
Ja, die kannst du ja einfach messen.
Gibt es eine Mitarbeiterbefragung über glückliche Zufriedenheit?
Keine Ahnung.
Das kannst du machen.
Also die gehen halt eher von einem prozessualen Ansatz aus.
Und das Problem ist sozusagen, wenn du einen 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-Tools ist es so, wir haben uns das halt auch angewöhnt. Wir haben in der Mitarbeiterführung an der Stelle für 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.
Und das ist ganz spannend, weil daraus bei uns nämlich auch, 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 irgendwie exklusiv mal Zeit mit deinem Chef über irgendwas zu reden, dann ist das häufig relativ wenig.
Und wenn ich denen 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.
Wissensgesprä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,
triggert das halt automatisch, dass man sich halt dann alle O3s einmal anguckt,
nochmal durchschaut, was war denn so, worüber haben wir gesprochen,
wie hat sich das entwickelt, etc.
Und da muss auch niemand irgendwie was groß vorbereiten.
Da kommen so ein paar Sachen, irgendwie Eckdaten,
vielleicht nochmal ein bisschen Gehaltsverhandlungen oder sowas.
Das ist eine Ebene, wo wir sagen, dass ein Manager hat halt die Pflicht,
aktiv die Beziehungen zu seinen Mitarbeitern zu pflegen
und auch den Mitarbeitern Gelegenheit zu geben,
ständig mit der Organisation in Austausch zu treten über den Mitarbeiter.
Das nächste sind Coaching-Ansätze, damit der Manager halt,
wenn man im U3 identifiziert, hey, an irgendwelchen Sachen hapert es hier ständig,
du hast entweder Konflikte mit irgendeinem Mitarbeiter
oder du kriegst irgendwie ein bestimmtes Arbeitsthema, geht nicht,
dann gibt es dafür eine Coaching-Struktur und es gibt eine Feedback-Struktur,
um Mitarbeiter tatsächlich geordnet
und freundlich und höflich
darauf hinzuweisen, wenn irgendwie Verhalten,
was sie an den Tag legen, weil Ergebnis erzielen
ist nachher nichts anderes als die Summe des
an den Tag gelegten Verhaltens,
darauf hinzuweisen,
dass irgendwas halt jetzt der Organisation
eher hilft oder eher nicht hilft,
um sich dann damit halt
auseinanderzusetzen. Und die drei
Maßnahmen sind tatsächlich was, das haben wir von den Manager-Tools
mehr oder weniger eins zu eins übernommen,
wo wir sagen, ich habe nichts
studiert in Richtung Management, aber das ist
Zeug, wo wir auch von den Mitarbeitern und von
anderen immer wieder Feedback kriegen von
Fakt, das ist eine gute Struktur und Idee
von, man lässt das nicht einfach
so laufen, sondern da kommen sinnvolle
Sachen bei raus in Richtung Retention und
Organisationsentwicklung. Was ist ein O3?
Ja, ein One-on-One.
Das ist dieses halbe Stunde jede Woche.
Drei O's. One-on-One.
Okay. Genau.
Und ich habe hier so Stapel von Mitarbeitern,
da habe ich jetzt irgendwie seit sechs Jahren jede Woche,
fast jede Woche, irgendwie
mir die Notizen gemacht, wie wir miteinander
arbeiten, was da so anliegt und
etc.
Was erzählt man denn an so einer halben Stunde jede Woche?
Na, die ersten
zehn Minuten, da gibt es, also die haben so ein Formular,
das liegt bei mir auch immer griffbereit für, wenn man es mal
braucht. Da schreibe
ich mir dann halt auf, okay, mit wem rede ich gerade,
was ist heute für ein Tag? Und dann hat er
zehn Minuten, da stelle ich mir auf der Watch dann so einen
Timer von, so, das sind deine zehn Minuten,
erzähl mir was. Und dann kann er mir was erzählen, ob er
seinen Garten umgegraben hat, wie es im Urlaub
war oder ob irgendwie gerade
der Fuß wehtut oder ob das letzte
macOS-Update ihm irgendwie die Haare vom Kopf frisst.
Das sind seine 10 Minuten.
Da quatsche
ich dann normalerweise auch nicht dazwischen, außer er
bittet mich drum. Da mache ich mir
seine Notizen. Dann habe ich nochmal 10 Minuten,
wo ich ihm Updates gebe über
bevor wir im Team
Entscheidungen kommunizieren, ist es auch so,
dass jeder Manager vorher mit
jedem Einzelnen diese
Änderungen bespricht oder Neuigkeiten aus
der Organisation. Bei uns gibt es
ein Grundsatz, der sagt, in Meetings gibt es
keine Überraschung.
Wenn im Meeting irgendwas verkündet wird,
wo es eine Überraschung ist, ist es mehr so, im Meeting
hören das alle nochmal im großen
Kreis und man guckt sich in die Augen und sagt, ja,
das ist jetzt das, was hier passiert,
aber in dem Moment ist es nicht
oder habe ich auch noch nie was davon gehört.
Das geht einfach nicht.
Im Meeting
werden auch Entscheidungen nicht herbeigeführt.
Im Meeting wird im Prinzip nur
von allen dokumentiert mit, ja, wir haben
diese Entscheidung wahrgenommen. Die soziale Magie
ausgeübt, die diese
Konstruktion Wirklichkeit werden lässt.
Richtig, genau. Da haben wir noch einen separaten
Prozess dazu. Wir drucken dann so Bilder aus
und stempeln die dann halt, jeder hat so einen kleinen
Figurenstempel und committet sich da
indem er da draufstempelt.
Genau, und das Letzte ist dann halt die Frage
so, was brauchst du noch für deine
persönliche Weiterentwicklung hier im Unternehmen?
Wo fehlt es dir? Wo geht die Reise
hin? Da gibt es auch ein paar unterschiedliche Prompts
auf dem Formular, damit man
halt weiß, okay, das immer mal aufzufrischen,
immer mal neue Perspektiven einzunehmen von
dass man mal
guckt, okay, wie sieht denn deine To-Do-Liste gerade
aus, ist die zu lang, kommst du klar
oder dass man halt fragt, wie sieht es denn aus, wie sieht
das nächste Quartal bei dir aus, wie war denn das
bei dir mit dem Hausbau, wie ist denn, dass man tatsächlich
wirklich auch, der Arbeitstag
ist stressig, man kann sich so ein Kram nicht in jeder
halben Stunde neu ausdenken
da gibt einem das halt einfach tatsächlich so ein bisschen Struktur
dass man so alle Bereiche, die man mit Leuten
halt, mit denen man ständig zu tun hat, auch
regelmäßig abklopft, auch wenn es mal ein bisschen mehr
und viel wird und man es dann nicht halt runterfallen
lässt.
Also auch sehr persönlich dann,
das ist wichtig. Es ist sehr persönlich
an der Stelle, weil das
erlebe ich auch immer wieder, wenn du
dann solche Situationen hast, dass ein Unternehmen
vor großen
Herausforderungen steht und Corona ist
da für alle von uns mit extrem hoher
Unsicherheit versehen von
wo geht hier was, wie weiter, wo
kann im nächsten Jahr, wenn die zweite
Welle kommt oder sowas, dann bin ich froh,
wenn ich weiß, dass im Unternehmen zu
allen Mitarbeitern halt eine gute Beziehung
besteht, auf der man solche Herausforderungen tatsächlich in
solchem Rahmen auch gut diskutieren kann.
Weil das ist nachher das, wo ich dann sagen muss, da kann ich
mich, ich kriege ein besseres Gespür, wie ich mich darauf
verlassen kann, wer arbeitet wie, wer
hat wo welche
Herausforderungen persönlich gerade, wer ist wo mental
wie gefordert. Und das sind ja,
wie Johannes halt meinte, am Ende geht es um die Menschen,
die diese Aufgaben erlegen müssen.
Ich kann im Projektmanagement die
Leute ja nicht als austauschbare Ressourcen behandeln.
Wenn ich habe Kunden, da
kriege ich dann manchmal die Krise, die habe ich
nicht für die Kunden momentan. Keiner meiner Kunden muss sich
angefangen fühlen.
Aber ich hatte in der Vergangenheit Kunden,
die hatten tatsächlich... Wir hatten alle schon mal solche Kunden.
Ja, die haben tatsächlich angerufen,
ich glaube mir fein,
ob ich dann
in den nächsten vier Wochen noch drei Ressourcen für sie
hätte.
Menschen sind unsere
wichtigste Ressource, sagt man da.
Ja, nee, hab ich nicht. Nein, Entschuldigung.
Das klingt wirklich so, also
wer Menschen als Ressourcen betrachtet,
der verheizt sie dann auch.
Ja, und das ist tatsächlich, und ich glaube, wenn man schon von Organisationen sowas wie Führung von dem Ende her denkt und so angeht, dann erledigen sich auch so diverse andere Probleme aus dem Projektmanagement.
Ja, was du halt versuchst irgendwie im Projektmanagement zu erschlagen, eben durch auch es egal zu machen, wer jetzt eigentlich Dinge tut oder wie viele Leute und ja, es ist halt, kannst es halt nicht alles voneinander trennen.
Das war jetzt irgendwie ein sehr langer Braindump, sorry.
Ich glaube auch, dass da so ein bisschen das Wort einfach falsch ist.
Man sagt, man spricht ganz viel über Projektmanagement
und tut ganz viel so, als ob die Projekte diejenigen wären,
die da gemanagt werden.
Aber im Endeffekt ist es ja nicht die Projekte, die gemanagt werden,
sondern es sind ja die Menschen, die gemanagt werden.
In idealer Weise werden die nicht gemanagt,
weil managen hört sich halt so ein bisschen an wie so die Ressourcen
oder die Kühe, die im Stall sind, die da managen.
Rumschubsen mit der Peitsche, knall.
Sondern es ist schon so ein bisschen ein Element von Führung.
Man muss die Leute führen, anführen, dazu das zu tun, was richtig ist und was notwendig ist.
Es gibt Leute, die können das ganz beeindruckend gut und die erreichen alle ihre Ziele, die sie haben wollen.
Und die Leute bleiben alle dabei und die würden alle voneinander durchs Feuer gehen.
Und es gibt Situationen bei Kunden, wo die Menschen halt als Ressourcen bezeichnet werden
und dann verhalten die sich halt auch wie Ressourcen.
Die verhalten sich halt wie der Esel im Stall
und sagen, ja, da ist jetzt ein Problem,
aber das ist ja zum Glück nicht mein Problem.
Und das geht mal eine Weile gut
und in großen Firmen geht es auch erstaunlich lange gut,
aber irgendwann werden auch die aufgegessen von den Teams,
die das besser können.
Ja, tatsächlich.
Also ich glaube, dass zum Beispiel ein wichtiger Punkt dabei ist,
halt so etwas wie
die
Qualität auch der Dinge,
die dann halt, also der
Ergebnisse, die halt erzeugt werden, ist halt irgendwie
für die Leute, die das machen, ganz wichtig,
weil das halt eine Quelle
sein kann für
warum tut man das überhaupt, hat das irgendeinen
Weil selbst wenn das jetzt irgendwie am Markt scheitert oder so, wenn ich das Gefühl habe, ich habe da irgendwas gebaut, irgendein cooles System oder ein Ding, was halt was Tolles tut, dann ist das unter Umständen eine sinnvolle Erfahrung, auch wenn das jetzt am Markt vielleicht irgendwie nicht funktioniert oder so.
Und der Markt, wenn man dem Markt das überlässt, das zu steuern, dann ist oft so, dass man quasi als jemand, der das beauftragt oder entwickeln lässt, halt eine gerne Qualität gegen Zeit oder Kosten tauschen würde, weil man sagt, naja, also den Effekt, dass ich durch die geringere Qualität das am Markt ein bisschen schlechter verkaufen kann, der ist lange nicht so stark, wie die Kosten, die ich sparen kann oder lange nicht so stark, wie ich die Zeit.
Das Problem dabei ist halt nur, dass man
damit das langfristig kaputt
macht, genau, und
es funktioniert einfach nicht. Und tatsächlich
ist es wahrscheinlich besser, irgendwie
auf die Qualität zu gehen und zu sagen, okay, langfristig
erhöhen wir die Produktivität darüber,
dass die Leute halt einfach ihre Profession so
beherrschen und das halt können, was sie da machen,
dass sie da halt
besser sind als andere, die da halt
sozusagen immer am Limit
arbeiten.
Es stimmt halt auch einfach nicht.
Es stimmt halt auch einfach nicht. Es gibt
viele Beispiele von Produkten, die
sehr viel konnten
und sehr schlecht und die einfach nicht angekommen
sind. Und es gibt auch umgekehrt
sehr viele Beispiele von Produkten,
die sich halt auf eine Sache
reduziert haben und da die
Qualität mordsmäßig rausgeholt haben und die
in einer ungeheuer schnellen Zeit
reingetan haben,
die dann sehr erfolgreich geworden sind. Und ich glaube,
dass das der zweite Weg ist, der im Projektmanagement
oft einfach übersehen wird.
Anstatt, dass du viele Sachen schlecht machst, kannst du
ja auch wenige Sachen gut machen.
Und hast dann trotzdem weniger Zeit
verbraucht. Und wenn das
die richtigen Sachen sind und wenn du die richtig gut machst,
dann kommen die raus.
Gmail ist da
so ein Beispiel. Das konnte am Anfang gar nichts,
aber es hatte halt ein super gutes
Interface, so wie die Leute das haben wollten.
Und das hatte null Features.
Und ein Gigabyte Platz gehabt.
Ja, und ein Gigabyte Platz gehabt. Okay, gut.
Das ist natürlich eine Eigenschaft, die ist sehr schwer nachzustellen,
wenn man noch in Megabyte denkt.
Aber die haben sich
einfach auf diese Kernfeatures konzentriert
und haben die so exzellent gemacht, dass die
fehlenden anderen Features völlig egal waren,
weil die Kernfeatures schon da waren.
Und da ist dann eben die Qualität drin,
in diesem kleinen Bereich,
der
dann überzeugt. Auch das kennt
man unter einem bekannten
Wort, und das heißt halt hier MVP, Minimum Viable
Product, macht die Sachen so
gut, wie sie sein müssen, dass der Markt die
akzeptiert, aber nicht mehr. Ja, aber das ist
ja eben nicht Qualität
unbedingt.
Doch, weil du halt eine kleinere Menge hast und dort bringst du die akzeptabel, das würde ich nicht unterschätzen, akzeptable Qualität heißt nicht scheiße.
Genau, die notwendigen Bedürfnisse empfüllst du ja gerade, die gerade so notwendigen, dass das genau dein Bedürfnis befriedigen kann.
Genau, genau und es geht ja auch daran, deswegen ich würde dort auch, auch da würde ich wieder aus Komplexitätsperspektive für eine flexiblere Sichtweise plädieren.
Wenn ich zum Beispiel fünf Experimente gleichzeitig mache, dann will ich die Qualität runterschrauben. Dann will ich die Qualität gerade so haben, dass ich möglichst schnell eine Info kriege, ob ich überhaupt in die richtige Richtung laufe. Wenn ich noch gar nicht mal weiß, ob das, was ich baue, überhaupt Sinn hat oder überhaupt funktioniert, lohnt es sich nicht, von vorne bis hinten irgendwie alles durchzupolieren.
Im Gegenteil, das ist verschwendete Zeit, weil dann kriege ich die Info nicht und das Geld, was ich hätte, um es eigentlich richtig zu machen, ist dann weg. Das ist auch manchmal, wenn ich mich mit jemandem reibe, der eher aus dieser Ingenieursdenke kommt, dann gibt es manchmal diesen blöden Spruch, der mir an den Kopf kommt, das ist dieses, there is always time to do it twice, but never to do it right.
Und es ist halt Bullshit, weil es voraussetzt, dass das, was ich einmal richtig mache, das Richtige ist, was ich mache. Und dann habe ich mir aber halt tatsächlich dann sowohl die Zeit als auch das Geld verballert, anstatt halt noch einen Versuch zu haben oder eben erstmal was Halbes zu bauen, um dann hinzugehen, ja, jetzt war es richtig und jetzt gehen wir hier volle Kanne rein.
Also deswegen da so einen flexibleren Ansatz um dieses Dreieck ist ja eben auch nicht gedacht von, ja es muss alles, man muss sich als Unternehmen oder als Projekt entscheiden, ob dieses Dreieck jetzt auf Zeit, auf Qualität oder auf Funktionsumfang achtet, sondern die Frage ist eher, was ist denn heute gerade unser Fokus?
Um dann zu wissen, okay, wenn wir uns jetzt auf Funktion konzentrieren wollen oder auf Zeit, sagen wir, wir wollen uns auf Zeit konzentrieren, um schnell zu ergeben zu sein, wissen wir, wir müssen Abstriche bei Qualität und bei Funktionsumfang machen.
Manchmal muss man einfach auch noch was draus machen.
Ja, und jetzt kann ich aber eine bewusste Entscheidung draus machen. Das ist ein Werkzeug, um Entscheidungen zu treffen und nicht ein Ding, um sich davor zu stellen, zu sagen, das ist halt so.
Ja, was leite ich denn draus ab, wenn ich sage, jetzt muss ich weniger Qualität machen?
Aber ja, also overengineert kann auch ein Nachteil sein, glaube ich.
Also ich glaube quasi täglich, ich weiß nicht.
Das ist für einen persönlich als Entwickler wahrscheinlich sehr wichtig
und halt für Retention irgendwie.
Aber so in so einem Projekt, wenn ich jetzt dafür sorge,
dass das alles super funktioniert,
aber vielleicht nicht mehr so variabel oder flexibel ist
oder so schnell austauschbar ist,
dann mache ich mir vielleicht auch Probleme, die ich ...
Qualität ist ein sehr flexibler Begriff.
Das bedeutet nicht nur, dass alles schnell gut ist,
sondern das bedeutet, dass es so sein soll.
Ja, wer definiert das?
Genau. Für mich aus Operations-Perspektive bedeutet Qualität zum Beispiel, dass ich möglichst viele Dinge, möglichst ohne mir Gedanken zu machen habe, einfach wegschießen kann und die kommen danach halt schon irgendwie wieder. Ja, das ist für mich ein Qualitätsaspekt. Wenn ich aber gerade erst evaluiere, ob das Zeug inhaltlich überhaupt sinnvolle Dinge tut, nein, dann brauchst du es noch nicht so weit gebracht zu haben.
Wichtig ist aber eben zu sagen, man weiß, dass Code halt flexibel ist und ich glaube, viele Leute fallen ja auf die Sunk-Coast-Fallacy rein, also dass nur weil ich in etwas schon Zeit und Geld gesteckt habe, darf ich jetzt nicht aufhören, noch Zeit und Geld reinzustecken oder im Gegenteil, ich darf es nicht wegwerfen, das ist halt noch viel schlimmer.
Und der Trick ist aber, Code ist zum Wegwerfen da.
Code steht immer zur Disposition.
Ich tue mich da auch schwer,
weil wenn ich mal schönen Code geschrieben habe, dann will ich nicht,
dass der weggeht, weil, oh, das ist mein Code.
Aber gleichzeitig...
Ja, genau, genau.
Ich habe den Code mal umformatiert.
Ah!
Jede Zeile neu committed,
damit auch die History weggeht.
Ja, genau.
Und den...
Das ist aber tatsächlich...
Es ist ja nur ein Hilfsmittel, Code ist immer nur das Hilfsmittel, um zu ermitteln, um auszudrücken, was ist gerade unser Verständnis von, wie soll das hier alles funktionieren und dann muss ich ihn halt wieder aufreißen, wenn ich festgestellt habe, der war jetzt falsch.
Und ich mache es aber tatsächlich so, da geht es dann halt sehr weit runter in diesen ganzen Code as a Craft zum Beispiel. Abstraktion kommt bei mir wirklich erst, wenn ich weiß, was ich überhaupt tue. Ich bin sogar beim Refactoring so, dieses Dry-Prinzip mit Don't Repeat Yourself, das hat eine Falle.
Viele Informatiker und Ingenieure meinen, das bedeutet, wenn ich etwas das zweite Mal aufschreibe, muss ich es verallgemeinern.
Und das Problem ist, du kannst es auch mathematisch betrachten als Verallgemeinerung ist eine Extrapolationsfunktion.
Und je weniger Datenpunkte ich extrapoliere, desto falscher extrapoliere ich.
Und im Prinzip, wenn ich halt anfange, während ich die zweite Instanz eines Codeschnipsels schreibe, der sehr ähnlich aussieht wie der erste,
und dann schon extra, und dann schon abstrahiere,
dann extrapoliere ich im Prinzip von einem
Datenpunkt. Das kann halt
alles sein. Das ist dann aber Yagni, oder?
Your arm gonna be the...
Ja genau, das kann man
gut als Gegengewicht machen. Und ich mal hab mir
angewöhnt, frühestens beim dritten Mal,
wenn ich irgendwie so einen Junk von
5, 6, 7, 8, 10 Zeilen
wiederhole, ich lade
frühestens beim dritten, eher beim vierten Mal
dann zu gucken, was ist denn hier wirklich
eigentlich das, was hier gemeinsam ist.
Und ich schreibe es ganz bewusst auf und ich
muss mich manchmal dazu prügeln und sagen, nein, du schreibst
es jetzt nochmal auf. Fängst noch nichts an zu
abstrahieren.
Ja, das hat ja auch eine gewisse
Freude, wenn man so eine
Abstraktion gefunden hat. Egal, ob man die dann nur
einmal aufruft oder viermal.
Das ist
da so ein Problem da drin. Ich mache das gerne.
Ich schreibe gerne eine Funktion, die alles
kann und die alle
Parameter hat, die an genau einer
Stelle aufgerufen wird mit konstanten Parametern.
Ja, genau.
Auch das sind ja Entscheidungen,
die dich dann nachher eher auch unflexibel machen.
Weil wenn du das dann wieder umbauen willst,
musst du plötzlich die Absorption wieder ausbauen
und das ist auch was, das passiert viel seltener.
Ja, genau.
Und deswegen ist Erweiterbarkeit,
Code, der nicht existiert,
ist am allererweiterbarsten.
Ja, wobei ich sagen muss,
es ist halt nie so einfach.
Es gibt auch wieder das Gegenteil.
Was mir zum Beispiel tatsächlich
Also dieses, ich habe das manchmal, wenn ich so auf Code gucke und denke mir so, nee, das muss irgendwie anders sein, dann mache ich das jetzt nicht so, dass ich irgendwie darüber nachdenke, quasi, ja, ich zeichne mir nicht erst ein Diagramm, sondern es ist so ein gewisses ästhetisches Gefühl.
Das ist so wie, weiß ich nicht, wenn man Musik macht oder einen Satz formuliert oder so, dann fühlt sich das manchmal richtig an und manchmal nicht. Und diese ästhetische Komponente kann einen auch dazu bringen, überhaupt erst ein Problem auf eine sinnvolle Art irgendwie anzugehen.
Also das habe ich auch oft, dass mich sozusagen mein Sinn für Ästhetik irgendwie dann zu einer Lösung führt, wo ich sie am Anfang gar nicht gesehen hätte, sondern ich habe nur aus einer ästhetischen Motivation heraus irgendwas umgestellt und dann stelle ich plötzlich fest irgendwann so, ach, das löst das Problem ja.
Und insofern kann auch irgendwie reine, ich meine, ohne dass man jetzt vorher schon weiß, wohin das führt, irgendwie ästhetisch motivierte Code-Umformatiererei, die kann einen natürlich auch ins Verderben führen, das stimmt. Oder halt zur Lösung. Tja, keine Ahnung, was man sagen soll.
Das ist die Tagline dieser Episode, oder?
Es ist alles nicht so einfach.
Das Spannende dabei ist aber ja zum Beispiel,
du aktivierst damit halt eins deiner kognitiven Systeme,
gerade halt eher so das auf Pattern-Matching basierte,
wo du halt eben nicht eine kausal hergeleitete Kette hast,
von warum du jetzt diese eine Änderung führst,
sondern du sagst, irgendwann mein Bauchgefühl ist komisch
und das ist ja der Teil von, das ist der Craftsmanship.
Also ein guter Handwerker, der viel Erfahrung hat,
Der kann dir manchmal noch nicht genau sagen, warum das jetzt eine schlechte Idee ist, aber wir machen es jetzt mal anders.
Und in dem Moment, wo er dann fertig ist, ist er, aha, ja genau da drüben, das da.
Das kann er dir aber vorher nicht sagen und das Bauchgefühl und die Erfahrungen sind aber wertvoll.
Und er wird natürlich währenddessen beobachten, ob seine Schleife, die er da gerade dreht, jetzt tatsächlich richtig ist oder nicht.
Der wird auch wieder zurückgehen und sagen, nee, ach Mist, war jetzt irgendwie falsch.
Und wichtiger ist aber eben, das ist ja genau diese Art von Flexibilität, um die es bei Agilität ja auch geht, um dieses Responding to Change.
Du gehst mit einer Annahme da rein, fängst an zu arbeiten,
stellst fest, nee, so nicht, ach doch so, aber nee, jetzt eher hier drüben.
Also ein Freund von mir hat halt auch so einen Projektablaufplan
immer wieder mal für Kunden, ein relativ bekannter Comic,
wo du sagst, wo ist unser Startpunkt, wo ist unser Zielpunkt?
Und die meisten Leute denken halt, du läufst jetzt diesen geraden Weg
von A nach B ab.
Der ist aber, und so versucht auch viel Projektmanagement zu sagen,
so, wir sortieren das jetzt alles mal so,
dass wir diesen Weg hier gerade durchlaufen können.
Das Problem ist nur, wenn man das als eine Landschaft betrachtet, so als so eine Karte von wie du dich in der Welt orientierst, dann ist dieser Weg nicht unbedingt sinnvoll, weil dazwischen sind irgendwie drei Sümpfe mit Alligatoren und ein riesengroßer Berg und eine riesengroße Schlucht und um das irgendwie, um das so zu queren, ist völlig bekloppt und es wäre viel einfacher, erstmal ein bisschen nach links zu laufen, dann nach oben und siehe da, hier ist ein Aufzug, aha und hier ist eine Straße und da ist ein Taxi-Service und jetzt sind wir schon da.
Deswegen sieht ein Projekt halt manchmal eher so aus,
dass man halt so tausend schleifen und rechts und links
und das ist aber tatsächlich der in Summe
energetisch bessere Weg, als zu
versuchen, es von vorne nach hinten durchzuprügeln
mit so einem abgeschlossen definierten Punkt.
Weg.
Das ist ja ein großes Abenteuer
auf einer Landkarte.
Kompass ist kaputt. So sind Projekte.
Ja, genau.
Und man darf das halt nicht wegmachen.
Ich glaube, der Fehler im Projektmanagement ist, wenn man versucht, das
wegzumachen, dass das nicht passiert.
Weil dann fehlen dir diese ganzen
eigentlichen Erkenntnisse da drin.
Ja, und das wird aber auch dann versucht.
Man sagt halt so, die Karte ist das
Gebiet und dann, ja.
Ja, weil wenn du halt erwartest,
dann holt man halt den großen Bohrer und dann geht man halt durch.
Also auch hier wieder
nochmal, also ich muss selber ein bisschen korrigieren.
Wenn du in einer
bekannten Domäne arbeitest, ist das
legitim. Wenn deine Aufgabe ist, du sollst
von A nach B und der Deal ist,
du befindest dich in Deutschland, in
München und sollst mit dem Auto nach Berlin
fahren, dann holst du halt nun mal die blöde
Karte raus, guckst, wo die Autobahnen sind, guckst,
wo der Stau ist und dann fährst du halt.
Wenn aber
die Aufgabe ist,
wir wollen heute ein schönes Picknick
machen, da drüben ist eine Wiese,
wo ist denn hier der schönste Punkt
zum Picknicken, dann kann ich halt die Karte
nicht raus und dann muss ich anfangen loszulaufen
und dann kann ich mich nicht nur auf den bekannten Wegen
bewegen und dann ist mein Werkzeug auch ein anderes.
Dann muss ich irgendwie mir die Gummistiefel anziehen
und damit rechnen, dass hier irgendwie
noch irgendwo plötzlich ein Schaf um die Ecke kommt
und ein Hund und ich irgendwie in ein
Loch trete, das ist halt was anderes.
Da brauche ich halt Regeln und
Verhaltensweisen, die mir erlauben, mich in unbekannten
Gebieten zu bewegen und mich darauf einzustellen, was hier eigentlich gerade
passiert. Und das ist
kategorisch anders,
aber eben situationsabhängig, legitim oder
auch nicht. Aber bekannte Probleme
kann man ja anscheinend dann doch mit einem Wasserfall erschlagen.
Natürlich.
Ja, aber wenn es ein bekanntes Problem ist,
warum entwickelt man dann Software? Dann nimmt man einfach
irgendwie, keine Ahnung, SAP. Warum gibt man dann Software neue?
Die gibt's ja dann schon. Die gibt's ja dann schon. Ja, genau.
Im besten Fall.
Also auch da kann's Gründe geben,
die alte Software ist zu alt, im Sinne von der Compiler
geht nicht mehr, die Firma ist weggeseitigt.
Aber dann kannst du's auch so angehen. Dann kannst du auch
sagen, wir setzen uns jetzt hin, wir programmieren das jetzt
nochmal so runter. Ist ja kein Problem, dann macht man
das halt.
Es gibt ja auch Ansätze, die sagen, du sollst
Teil 2 machen. Musst halt zweimal machen.
Das erste Mal weißt du noch nicht, wie's geht und beim
zweiten Mal weißt du halt, wie's geht und deshalb musst du's zweimal
machen. Ist auch eine
legitime Methode, nur da verlierst
du halt das, was der Christian die ganze Zeit schon
sagt. Meistens
weißt du ja gar nicht, wo du hin willst. Oder meistens
weißt du ja gar nicht,
ob das der richtige Ort ist, an den du gehst.
Meistens weißt du gar nicht, ob es diese Lösung gibt,
die du haben möchtest. Auch wenn du sie erreicht
hast, weißt du nicht, ob es die gibt oder
ob es die richtige ist. Und es dann nochmal zu
programmieren, macht dir sicherlich, oder nochmal zu
entwickeln, macht sicherlich das Produkt
besser, aber ob das das richtige Produkt ist, weißt du
dann immer noch nicht. Ja,
Ja, auch ein schönes Phänomen, auf das man dann halt
irgendwie so in der Praxis auftrifft, ist dann
irgendwie, ich weiß nicht, ob das jetzt, aber das
ist da auf jeden Fall auch nah dran, irgendwie
Second System, irgendwie.
Oh ja, das ist dann der Gegenteil.
Wenn du es beim zweiten Mal machst, dann baust du alles ein, was
du dir beim ersten Mal ausgedacht hast.
Und da kommen die, und da kommen
ja die Agile Methoden halt im Prinzip
ins Spiel, dass du eben nicht sagst,
ich mach da Second System draus, sondern das ist halt
im laufenden Projekt, diesen Modus
wechseln kannst und so, weil wir Unitests
haben und weil wir dies haben und weil wir jenes
haben, weil wir mit unserem Code flexibel umgehen und weil
es Common-Code-Ownership ist.
Deswegen können wir jetzt den Code,
in der vielleicht noch nicht Qualität wir haben wollen,
im laufenden Betrieb sukzessive umbauen.
Und das halt, Komplexität
erfordert auch einen granularen Blick auf die Welt,
dass du halt immer wieder mal kleinere Einheiten,
größere Einheiten anguckst und dann zu sagen so,
das Subsystem da drüben hat sich jetzt stabilisiert,
da räumen wir die Qualität jetzt auf, da drüben
experimentieren wir noch. Es muss halt keine Blanko-Entscheidung
für alles sein.
Ja, gleichzeitig kannst du ja aber auch
das Ziel nachführen. Das ist so ein
so dieser andere Aspekt
der agilen Entwicklung,
dass du zwar die Software, die du entwickelst,
so gut wie es geht entwickelst, aber
dass du ja erst nach und nach rausfindest,
was du überhaupt für Software entwickeln musst, was du überhaupt
erreichen möchtest. Und das
kannst du natürlich nur dann nachziehen,
wenn du die Flexibilität hast, das Ziel
zu verändern. Wenn du die Flexibilität
hast zu sagen, okay, der Plan,
den wir uns zurechtgelegt haben, das ist der perfekte
Schlachtplan und den können wir so durchziehen,
aber der bringt uns nichts.
Dann haben wir hinterher ein Produkt, was
egal ist und das findest du raus, während du es machst, das findest du raus, wenn du es released hast und deshalb sind da diese ganzen Sachen drin, Release Early, Release Often, Break Things, Fail Fast, diese ganzen Sachen, die sind nicht dafür da, um die Qualität des Produktes zu verbessern, sondern die sind dafür da, den Product Fit zu verbessern, die sind dafür da, ein besser passendes Produkt zu finden, was du vorher nicht wissen kannst.
Du kannst vorher nicht wissen, was der Kunde
haben möchte, wenn du es nicht ausprobiert hast.
Selbst wenn du selber der Kunde bist,
kannst du es nicht vorher
wissen. Und das ist uns allen schon mal so gegangen,
dass wir uns überlegt haben, oh, da muss ich jetzt eine Library für
irgendwas schreiben. Und dann hast du es geschrieben
und hast gemerkt, das ist ja ein Quatsch und hast es weggeschmissen
und hast nochmal neu angefangen und gemerkt,
ich brauche was anderes.
Wie
war Einstein, das ja sagte, wenn wir
wüssten, was wir tun, wäre es keine Wissenschaft.
Und
Und es ist tatsächlich spannend, weil wir halt jetzt in einem Feld sind, wo man das halt dieses, wir wissen eigentlich nicht, was wir tun, aber wir haben halt Handwerkszeug und wir können das operationalisieren, wir können das halt im laufenden Geschäft machen.
Ich kann, das ist total merkwürdig, wir sind jetzt an einem Punkt, wo ich halt sagen kann, ja lieber Kunde, ich baue dir jetzt da halt auf Systemebene, auf einer Infrastrukturebene noch irgendeine neue Lösung ein und ich liefere dir, und zwar jetzt in einer halben Woche mal hingestrickt und dann nehmen wir das live in Betrieb und dann hast du da irgendwie 99,5% SLA auf diesem Ding drauf.
mit Garantie, weil ich weiß,
dass wir ausreichend flexibel sind, ausreichend
kleine Änderungen haben und das ganze Handwerkszeug
halt eben belastbar ist.
Wer würde denn heutzutage irgendwie ein Haus
kaufen, also bauen,
ich habe jetzt ja gerade saniert,
wo der Dachdecker sagt, ja, ich baue dir das
jetzt erstmal hin und dann müssen wir ein halbes Jahr
lang warten, ob es zusammenstürzt oder nicht.
Und der ist halt in der Lage,
mit seinem Handwerkszeug zu sagen,
während das Projekt, der war einfach sehr gut, der Dachdecker
hier, währenddessen man hier halt
sagen kann, während der Dach rumfummelt noch, du können
mal da drüben noch umbauen und da noch umbauen, ich brauche das eigentlich anders
und wir haben festgestellt, der Plan so geht nicht
und ein guter Dachdecker sagt dann, ja,
das ist anders, da drüben so und so und so
und der weiß halt, wo seine Grenzen sind,
wo man das halt gut umsteuern kann.
Ich muss glaube ich langsam
die Endrunde einleiten,
ich bin übernächtig
von den letzten zwei.
Die Diskussion wird auch langsamer.
Dafür nimmst du natürlich beim
Dachdecker halt die Ineffizienz in Kauf,
dass du erst was baust, was du dann wieder wegbaust.
Aber es ist einfach notwendig.
Du kannst nicht vorher wissen, wie es ausschaut.
Es ist wichtiger, das unterwegs zu merken.
Deswegen war ich halt, also die Bauherren,
kann ja immer keiner leiden, der schnell auf der Baustelle ist,
aber ich habe die Elektrik bei uns gemacht.
Insofern nimmt man mich dann halt auch ernst,
wenn ich da halt eh in der Arbeitshose rumhänge.
Und dann kann ich halt unterwegs die Entscheidung treffen.
Und ja, das war etwas teurer,
aber in vielen Fällen gar nicht so viel teurer,
als wenn man feststellt, jetzt ist es fertig,
jetzt müssen wir uns nochmal aufreißen. Das ist halt
prohibitiv. Genau, das ist halt genau die Sache.
Wenn du
eine Veränderung
früher bemerken kannst,
dann musst du sie früher reintun.
Das spart Kosten.
Und je früher du sie
bemerken kannst, umso früher
solltest du versuchen, sie zu bemerken. Das ist
so generell dieses,
das generelle
dahinterstehen, oder? Dass du die Änderungen, die du
machen musst, so früh wie möglich
bemerkst. Information, Information,
Information. Ich hätte noch
so eine Idee, was man vielleicht noch am Schluss machen
könnte. Ich meine, damit das auch irgendwie außer
so ganz luftigen
Gedanken ein bisschen
Content bekommt.
Was gibt es denn so für Tools oder so, die man
benutzen kann? Habt ihr positive Erfahrungen mit
irgendwas gemacht?
Auf die letzten drei Monate,
wo wir uns doch alle
mehr mit Tools beschäftigt haben, weil
bestimmte Sachen einfach nicht mehr so gehen.
Also ich habe
in den letzten drei Monaten sehr viel mit GitLab
gearbeitet und
das geht so ein bisschen
daran, was der Christian vorhin erzählt hat.
Das
Ticketboard in GitLab, das ist
sehr, sehr lightweight. Das ist im Wesentlichen,
wenn man es so benutzen möchte, eine To-Do-Liste, die man
hoch und runter ziehen kann und rechts und links
verschieben kann. So ein Kanban-Board fast, ne?
Ja, aber auch an einem Kanban-Board
hängst du ja normalerweise nur die
Überschriften hin und im GitLab, wenn du es so
verwenden möchtest, sind es einfach nur erst mal
die Überschriften.
Man kann da natürlich dann auch
ganze Tickets draus machen, aber so dieses
einfache
hier ist was zu tun und hier ist ungefähr
die Reihenfolge, in der es wichtig wäre,
das reicht schon aus.
Das ist sehr, sehr lightweight.
Das ist sehr
wenig
Steuerung, aber die Steuerung kommt dann
halt von unten, von denen, die es machen.
Da sagen, okay,
dieses eine Ticket ist zwar
höher eingetragen, aber das andere
geht schneller oder das andere
erleichtert mir das Leben oder das andere
bin ich jetzt gerade in der Stimmung dafür.
Auch das ist was, was in Agile
vorkommt, der Unterschied zwischen Push und Pull,
wo du eben nicht von oben
vorgibst, was getan wird und in welcher Reihenfolge,
sondern wo du sagst, hier sind die Dinge, die erledigt werden
müssen und von unten
die Leute, die es machen, die sagen dann, okay, jetzt mach ich
das und dann das und dann das und dann das.
Das hat da sehr gut
funktioniert.
Das war sehr angenehm.
Also die GitLab-Issues
und GitLab-Boards
haben für mich genügend Flexibilität,
um einen sehr angenehmen Arbeitsmodus
zu erreichen.
Mir geht es ähnlich.
Ich mag das, wenn Systeme auch so duale
Benutzungsmöglichkeiten haben.
Also wir sind momentan bei uns
jetzt mehrere Jahre
Fogbox benutzt.
Das ist ein System, was
auch einer der Internet-Urgesteine
von Joel Spolsky und so
und
mit dem Werkzeug sind wir sehr
happy. Die haben leider, die haben dieses Produkt
an ein separates Unternehmen verkauft und seitdem ist
vor einem Jahr hätte ich noch
irgendwie gesagt, hurra, hurra, hurra, kauft das
bitte alle und jetzt würde ich sagen, fuck, wir müssen davon weg,
weil die halt einfach echt,
das bricht alles zusammen.
Ist das nicht an Atlassian verkauft worden?
Nee, das war Trello.
Trello, ja, genau.
Aber ist ja eine ähnliche Geschichte.
Trello ist auch ein Joel-Tool,
Genauso wie Stack Overflow halt. Und was die sehr gut gemacht haben, ist tatsächlich dieses ganze, den Bedienungsflow, zumal zwischen Ticket, also dass du so unterschiedliche Repräsentationen von Listen, Trees und so einem Kram haben kannst und die haben schon sehr zeitig ein sehr fluffiges User Interface gehabt, was sich extrem schnell bedient.
Und ihnen war wichtig in der Abgrenzung zu Jira, das war ja lange Zeit eine harte Konkurrenz, Jira ist ihnen dann davon gelaufen, was die Marktanteile anging, dass sie gesagt haben, wir wissen, wie die Workflows sind, wir haben hier eine Meinung, wie gute Workflows und gutes UI funktioniert und das war dann die Abgrenzung zu Jira im Sinne von, ja mit Jira kannst du alles machen, es hat halt keine Meinung, es hat halt keinen Arsch in der Hose und es ist halt dann häufig völlig zerkonfiguriert und völlig kaputt.
Das hat uns an dem gefallen, plus die haben auch eine Integration mit E-Mail, wo du ein wirklich hochwertiges Support-Tool gleichzeitig drin hast und du musst dich bei einem Ticket nie entscheiden, ob das jetzt mit Kundenkommunikation oder interner Kommunikation ist.
du kannst jederzeit dazwischen im Ticket sagen,
du bist jetzt ein Mitkunde oder ohne Kunde
Ticket und ich habe die Historie und ich kann genau
sehen und sie haben einen richtig guten
E-Mail-Client dann auch sozusagen so mit
eingebettet, dass sich das auch anfühlt, wie ich schreibe jetzt
eine Kunden-E-Mail und der kann das dann irgendwie sehen
und gleichzeitig kannst du dann Kanban-Boards
ziehen, also das war eigentlich alles
sehr fluffig, wir orientieren uns
gerade Richtung Odoo,
das ist so ein Open-Source
eigentlich Enterprise-Resource-Management-Ding,
die haben aber
im Prinzip sozusagen alles in Boards
gepackt, sämtliche Arten von Ressourcen
kannst du immer in irgendwie
Boardsichten oder Listen oder
die haben so einen abgefahrenen
Excel-Roundtrip-Export. Kannst du sozusagen
irgendeine Query von irgendeiner Ressource
als Excel ziehen, im Excel bearbeiten,
das Excel wieder hochladen und er zerpflückt das
wieder und macht dann die Änderungslisten draus,
die du im UI hättest machen wollen.
Hört sich krass an.
Ja, finde ich so schwierig.
Ja, du müsst eigentlich...
Aber das ist bestimmt nicht so schwierig,
das ist meistens der Weg ins Verderben.
Das kann doch nicht so schwer sein.
Ich mach das noch schnell fertig.
Ja, also da gucken wir uns gerade
so ein bisschen um.
Ansonsten muss man, finde ich, mit den Boards,
wenn man so über Boards nachdenkt, muss man immer dran denken,
Kanban, das hat man jetzt als Methodik
noch nicht angerissen,
aber diese Flow-orientierten Sachen,
Die gehen im Prinzip davon aus, dass die Einheiten homogene Größen haben.
Wenn du dir dein Arbeitszeug zurechtlegst und über Flow managen möchtest,
dann musst du im Prinzip Dinge tun, die vorhersagbare und ähnlich große Items haben,
weil du sonst ständig in den Head-of-Line-Blocking kommst.
Dann gibt es plötzlich das eine fette Ding, was du jetzt angefangen hast und fertig machen musst
und es sitzt da mittendrin und es geht nicht voran und dann hast du irgendwie dieses Work-in-Progress-Limit,
das heißt ein anderes darf jetzt auch nicht rein und dann kommen wieder diese starren Regeln zu Trage
und dann lässt du die Regeln aber sein,
dann explodiert sie wieder auf eine andere Art
und plötzlich hast du halt wieder Ticket-Chaos.
Ja, ja, du müsstest sie ja alle zerlegen.
Ja, nee, das Problem ist,
Flow-Systeme wie hier Toyota Production System
und solche Sachen,
die sind halt produktionsorientiert.
Mach mir bitte 20 Prios.
Ja, und das ist was anderes als,
oh, erfinde bitte ein neues KI-System,
was irgendwie, was ist denn das für ein Ticket?
Ja, würde das eine Rolle
spielen, ob das irgendwie Python-basiert ist oder nicht?
Weil es gibt da so ein Ding, das halt auch so
ein bisschen sich, glaube ich, was die Komplexität angeht,
so zwischen irgendwie Trello und
Jira irgendwie ansiedelt.
Tiger, das ist halt
Jungle-Rest-Framework und
irgendwie sah ganz nett aus.
Ich habe es mal irgendwie installiert und da so ein bisschen
mit rumgespielt, aber habe es dann
auch nicht weiter verfolgt, weil, naja, gut.
also so beruflich
ist es auch momentan eher so GitLab und Jira
irgendwie, sind die Geschichten,
die ich verwende da.
Ich finde, bei den
Tools ist es egal. Ja, es ist auch ein bisschen egal,
wie die geschrieben sind, solange die gut funktionieren.
Ich habe mal Tiger versucht zu installieren und habe es
nicht hingekriegt und da hatte ich dann keine Lust mehr drauf.
Tiger hatte ich weggelegt,
weil die, also wir haben eine
relativ lange Historie, wir hatten irgendwie alles.
Hat noch jemand einfach Whiteboards
mit so normalen Post-its?
Ihr macht ja auch 4 Teams
und jedes probiert was aus und dann habt ihr irgendwann mal
alles aus.
Also 1999 hatten wir angefangen
mit Bugsilla, glaube ich.
Dann haben wir irgendwann den Request-Tracker gehabt.
Dann haben wir Redmine gehabt.
was haben wir noch? Was hat man noch so gehabt?
Etrello immer so ein bisschen.
Zermatt haben wir mal angetestet.
Also relativ viel Zeug so.
Und was
ich jetzt wiederum, weswegen
wir in Richtung Odoo gucken
und Odoo ist selber auch in Python geschrieben,
aber das ist so mehr nachgeordnet,
weil die eine gute Abi haben.
Bei Odoo ist dieses
Projektmanagement im ERP
Prozess überall
mit angedockt. Die haben sich relativ viel Mühe
gegeben, so ein allgemeines, fast schon SAP-artiges
System aufzubauen und haben
dann aber fachlich kompetent einzelne
Module, die gut ineinander übergehen. Du kannst zum Beispiel,
wenn du dann einen Verkaufsprozess
hast und
dem Kunden ein Projekt
verkaufst, kannst du im Verkauf
schon sagen, das ist ein Projekt der und der Art,
kannst du da irgendwie dran tackern, was da irgendwie
die Kalkulationsstrukturen sind, so typische
was legst du noch an Anhängen, an PDF
bei, etc., etc.
Und wenn der Kunde sagt, so, das machen wir jetzt,
dann kannst du in diesem Auftrag draufklicken,
ja, das wird jetzt ein Projekt und kannst gleich
für dieses Angebot ein passendes
Projekt-Template in, hier
habe ich ein Board, das sind die 50 Sachen, die jetzt
zu tun sind, rauslassen
und die sind alle aneinander geknüpft und du kannst
die Stunden, die da reingehen, gleich in den Auftrag
buchen und das war so ein, okay,
hier geht irgendwie, du kannst alles mit allem verknüpfern.
Da hat es mir so ein bisschen
die Sprache verschlagen.
Also ich muss aber sagen,
gerade wenn man jetzt Remote arbeitet, das ist vielleicht jetzt gerade
was anderes, aber wenn man irgendwie jetzt nicht Remote arbeitet,
sondern in so einem Office ist, finde ich
diese klassische, wir haben jetzt so
Whiteboards und hängen da Post-its hin, Sache
sehr cool, weil das halt so eine Haptik hat und man muss
aufstehen und hingehen und mal so die Distanz ändern
und hat das halt nicht in irgendwelchen
verschwurmelt ein Ticket, sondern man sieht das alles irgendwie so
vor sich visuell und das hat irgendwie einen riesen Vorteil.
Man braucht halt ganz viele Boards,
aber wenn man das geht, ich finde das sehr charmant.
Und hast halt keine Nachverfolgbarkeit, das
ist dann schwierig. Ja, vielleicht muss man das irgendwie dann
abnehmen oder so. Nein, das ist gut.
Nein, das ist recht, weil jemand, der nicht
da ist, das nicht sehen kann.
Nein, nein, Nachverfolgbarkeit kommt halt immer drauf an,
weil da gibt es halt auch eine interessante
Dynamik, weil
Transparenz im Unternehmen
ist keine absolute
Größe, weil das Problem
ist Transparenz. Das meine ich ja gar nicht. Ich meine ja die Leute, die da mit dran
beteiligt sind. Ja, ja, ja, warte, warte, warte.
Transparenz
hat das Problem, zu viel
Transparenz killt dir die Innovation,
weil keiner traut, irgendwas
zu machen, weil das könnte in zehn Jahren noch irgendwer lesen,
dass er mal eine blöde Idee hatte.
Zu wenig Transparenz und du hast
Ja, aber
kurz die Scheibe machen. Zu wenig Transparenz
bedeutet wiederum, dass du halt Korruption reinkriegst.
Ja, da brauchst du Transparenz. Und ich weiß,
dir geht es gerade darum, wenn du gemischte Teams hast, wenn du halt
Leute hast, die gerade krank waren oder die gerade irgendwie etc.
Das ist immer was.
Ja, irgendwas ist immer.
Wofür ich Whiteboard-Prozesse halt
gerne nehme mit dieser Haptik, ist tatsächlich
eher so ein Workshop-orientiertes Verfahren,
wo du sagst, okay, jetzt sind wir hier, die vier, fünf
Leute gerade mal vor Ort und du willst diese
High-Band-With-Low-Latency-Kommunikation,
die Menschen halt, wenn sie vor Ort sind, halt einfach
mal volle Kanne ausnutzen, dann machen
sich so Sachen mit Whiteboards und wir
haben auch so extra hexagonale Post-its,
weil die sich gut clustern lassen.
Das ist ein hexagonales Post-it.
ein hexagonales Post-it
und die
die nutzen wir dann
und dann werden die abfotografiert
und aber im Prinzip
wird jeder, der da war
verschriftlicht sich
die Erkenntnisse
und danach wird das ganze Ding wieder weggefaltet
und weggepackt und dann geht es irgendwie in Tickets weiter
aber das ist halt nur so ein temporäres
man muss auch mal Mut haben
auch mal Sachen abzuschneiden und zu vergessen
und zu verlieren
mein Kumpel sagt dann auch immer wieder
die wichtigen Sachen kommen wieder.
Ja, so kann man das
natürlich machen.
Es ist erschauend, wenn man
zu viele Mails kriegt, eine gute Strategie,
einfach nicht mehr drauf reagieren.
Die wichtigen Sachen erreichen dann
einen über andere Wege.
Wer schreit, hat noch Reserven.
Ja, das ist doch ein schönes
Stichwort zum Thema Projektmanagement. Wer schreit,
der kann auch. Schöne Folge.
Ja, ihr habt das zwar trotzdem vergessen, XP und Scrum-Chats,
ich bin da ein bisschen böse, vielleicht muss der Jochen das gleich noch
alleine nachlesen.
Machen wir nächstes Mal.
Ja, genau, wir machen einfach Teil 2.
Die Details.
Wir machen das wie beim Känguru, der Jochen
spricht jetzt noch die Fußnoten ein.
Das kann jeder in den Shownotes nachlesen.
Genau.
Zum Extreme-Pro-Rolling gab es nochmal so einen Podcast irgendwie bei
Cash-Rolling-Express, ich glaube die Nummer 28 war das,
mit Pavel Maja und Jim Whitlap.
Das war schon ein bisschen älter,
15 Jahre oder so, aber
Das ist immer noch gut.
Das habe ich ja nicht neu erfunden.
Das ist damals schon ein Podcast.
Ja, und ich habe das damals schon gehört.
Das Ding hat mich damals dazu gebracht,
irgendwie zu überlegen,
wir haben damals in der Firma Wasserfall-Geschichten gemacht
und als ich das gehört habe, dachte ich mir so,
das muss irgendwie anders werden.
Das kann nicht so bleiben.
Und genau, ja.
Ja, vielen Dank für die Projektmanagement-Folge,
die wir endlich hinbekommen haben.
Also das Projekt, Projektmanagement-Folge
haben wir jetzt quasi erfolgreich abgeschlossen.
Wie fühlt ihr euch? Ich weiß nicht, wie geht man
in das Projekt nach? Muss man das nochmal aufbearbeiten,
um das nächste Projekt, Learnings
mitzunehmen? Macht man so
ritualisierte Verfahren?
Geben wir uns alle einen High-Five am Ende?
Du reißt den Topf jetzt nicht wieder auf.
Wir haben gerade schon immer drauf.
Das Ende eines Projektes ist der Anfang des
nächsten Projektes.
Du hast vor einer halben Stunde schon gesagt, wir sollen zum Ende kommen.
Ja, cool.
Nö, fand's auch
echt interessant.
Vielen Dank, dass ihr das wieder rüberkommt.
Da sind viele Themen noch offen, wie der Dominik sagt.
Da kann man sicherlich noch mal eine Folge draus machen.
Feedback, weitere Wünsche, hallo at peisenpodcast.de.
Bleibt uns gewogen. Schaltet mal wieder rein.
Vielen Dank, dass ihr dabei wart.
Bis zum nächsten Mal. Tschüss.
Danke fürs Zuschauen. Tschüss.