Ja, hallo liebe Hörer und Hörer. Willkommen beim Python-Podcast, Folge 22.
Wir machen heute Projektmanagement, vielleicht auch ein bisschen mit Python.
Und spannenderweise ist genau diese Folge die Folge, die bis jetzt am wenigsten funktioniert hat.
Und wir versuchen seit September diese Folge aufzunehmen und hatten schon mehrere Termine, die dann wieder geplatzt sind.
Und dann haben wir schon mal eine Folge aufgenommen, die total nicht funktioniert hat.
Und jetzt fangen wir wieder von vorne an. Also Projektmanagement ist eine tricky Sache.
Wir sind wieder beim Jochen im Wintergarten. Hallo Jochen.
und Remote.
Und Remote dabei sind heute wieder zwei unserer Stargäste.
Und zwar der Christian und der Johannes.
Hi.
Hallo.
Vielleicht noch ein bisschen vorher am Anfang ein paar News aus der Szene einstreuen?
Ja, können wir eigentlich mal mit anfangen.
Genau.
Was gibt es denn Neues?
Der Christian hatte was Spannendes, glaube ich.
Ich hatte
eingeworfen, wart ihr eigentlich nicht beim
Python Camp dabei? Ich habe gerade überlegt,
dass ihr das gesagt hattet.
Da hatte ich das vorgestellt, weil ihr
sagtet, dass das PIP-Env
gerade einen Release bekommen hat
zum Thema, wie man so Anwendungen
paketiert, beziehungsweise ganze Anwendungen
irgendwo ausrollt mit dem Virtual Env.
Da habe ich tatsächlich Anfang des
Jahres oder vor so zwei, drei Monaten,
als Corona gerade losging,
selber was gebaut, das nennt sich App-Env,
womit man dann mit einer Requirements-Text-Datei
oder einem Freeze-File
in der Lage ist
Self-Contained, Self-Bootstrapping
Anwendungen zu bauen
die man aber auch auf beliebige andere
Python-Pakete
einfach draufjagen kann
das war so ein kleines
interessantes Werkzeug für Leute, die in dem großen
Potpourri aus
wie kann man noch
das Projekt Environment
da reinwerfen
eine der wenigen Möglichkeiten, Virtual Env zu machen.
Ja, genau.
Ja.
Ja, was sind eure Lieblingssachen? Also das ist tatsächlich auch dein Lieblingsweg,
da Env zu machen? App Env?
Halt immer für dieses Thema von, ich will die
in der Form vorliegen haben,
um in Projekten, wo ich mich mit anderen
koordinieren muss
und wir das nicht so global auf dem System
installieren wollen,
ist es bei App Env so, dass du
so eine kleine Bootstrap-Datei
unter dem Namen, wie du diese Anwendung
in dem Projekt benutzt, in dein Repository mit eincheckst, sodass jeder andere,
der dieses Projekt auscheckt, einfach nur .slash,
in unserem Fall ist das Bateau, das Deployment-Werkzeug, aber das kann halt irgendwas anderes sein, was dann
in einem Virtual-End als Executable lebt, aufgerufen wird und er sich automatisch
darum kümmert, dass jeder die richtige Version und alle Dependencies etc.
bekommt. Und wenn du halt manchmal im Team mit 20, 30 Projekten arbeitest,
die alle unterschiedliche Versionen haben, aber dann eins wurde dann doch wieder aktualisiert,
dann ist das halt eine schöne Variante
um zu machen, dass niemand sich
drum kümmern muss, wenn er mit dem
Ding interagiert, ob das jetzt gerade
aktualisiert wurde oder nicht, insofern
das passt uns sehr sehr gut
ja, okay
für eine Entwicklung nehme ich es aber nicht, also wenn ich
Projekte entwickle, dann mache ich meistens einfach
wirklich bloß ein ganz dummes
Virtual-Env in einem
ausgecheckten Repo rein, ich mache gerne viele
tausend Virtual-Envs
überall rechts und links
ich activate die auch nicht
sondern ich rufe sie dann immer mit den absoluten Faden
aus dem Projekt raus auf
Okay?
Ich habe mich so ein bisschen in das, was Jochen mir gesagt hat
Poetry verliebt, das fand ich irgendwie auch ganz nett
Ja, also ich
benutze meistens Poetry
und das ist halt auch, also in den Projekten
ich habe es noch nicht alles umgestellt, aber
in denen, in denen ich das getan
habe
war es dann halt auch so, dass es relativ einfach ist
immer wenn ich jetzt da irgendwie was ändere
oder so mache ich gleich ein Poetry Update
und sozusagen habe dann
auch immer aktualisierte Fassungen
während das bei dem Ansatz, den ich früher hatte mit
Virtual Envs immer so ein bisschen hakelig war,
muss man sich erst raussuchen, welche sind denn outdated
und kann man die jetzt upgraden oder nicht, aber
Poetry Update einmal testlich laufen lassen
reicht eigentlich immer
und das funktioniert tatsächlich auch für mich
ziemlich gut. Was mich
so ein bisschen nervt, ist, dass es teilweise sehr, sehr lange
braucht, bis die
Dependencies aufgelöst sind
und ich weiß nicht so genau, woran das liegt.
Aber was halt da interessant ist, es gab tatsächlich eine neue PIP-Env-Release.
Und da sind einige interessante Geschichten dazugekommen.
Das heißt, momentan könnte man sich das nochmal angucken.
Und vielleicht wäre jetzt nochmal ein guter Zeitpunkt, das mit Poetry zu vergleichen,
weil Poetry habe ich eigentlich nur deswegen genommen und dann halt auch vorgeschlagen,
weil das halt aktiv entwickelt wurde.
und PipM saw so ein bisschen danach aus, als
wäre die Entwicklung
da im Wesentlichen schon passiert und das
liegt halt so rum, aber tut irgendwie
nichts mehr und das hat sich wohl geändert.
Also insofern sollte man sich das
vielleicht nochmal angucken, aber habe ich jetzt auch noch nicht gemacht, insofern
kann ich dazu nichts sagen.
Bei PipM stand halt so ein bisschen raus,
dass es da auch mal wieder so einen Übergang gab von
ich glaube, war das Kenneth Reitz,
der das Original entwickelt hatte
und er dann halt aber es auch
in der Form hatte, wo er
sagte, ganz fertig ist es noch nicht und dann
der Übergang zu die PIPA.
Leute haben gesagt, wir würden sie
im Prinzip jetzt übernehmen, aber diese Arten
von Transitionen sind halt mit Kenneth manchmal
so ein bisschen holperig.
Ich merke auch gerade,
ich habe gerade...
Der Kenneth ist auch so einer, der gerne Projekte
anfängt, oder? Der macht
ganz viele Sachen erstmal und die...
Ja,
da gibt es ganz viele Sachen, die er mal angefangen hat,
um es mal so zu sagen. Das ist keine Kritik
oder so, sondern es ist einfach was,
um die Überleitung hinzukriegen.
Erfolgreiche Projekte werden auch irgendwann beendet und so, ja, was unterscheidet denn irgendwie so ein Stück Software von einem Projekt, ja, das ist eine interessante Frage.
Sobald ihr damit seine News habt, müssen wir da mal drüber sprechen.
Ja, ja.
Ach du, du hattest auch noch nicht, oh ja.
Ja, ja, natürlich.
Ja, jetzt break ich hier wieder einfach so rein und mach trotzdem wieder News.
und zwar gab es einen Blog-Eintrag von
Kay Patterson, der geschrieben hat,
dass Async Python nicht faster ist und
da ein paar Benchmarks gemacht hat.
War ganz interessant, den werden wir mal in die Show Notes linken.
Oh ja, da gab es dann auf Twitter
habe ich nur gesehen, dass das irgendwie Leute, die
darauf reagiert haben und dann geschrieben haben, war das doch alles
Unsinn, aber ich weiß nicht mehr genau, warum oder
wer oder das
kann ich mich auch nicht mehr so hart dran.
Ja, ja.
Also Sync ist schneller als Async,
ist die Aussage von diesem Blog-Post.
Ja, aber für was?
Ich kann ja einen Benchmark schreiben, der
beliebige Ergebnisse hat
Gute Frage, für was?
Hat die verschiedenen
Web-Server getestet oder verschiedenen Loads, je nachdem
wie viel Work an und wie viel True-Port
hast du irgendwie generiert
Einfach mal
ein bisschen mitzumeinen, was ich dann auf Twitter
gelesen habe, ist, dass die Leute ihm vorgeworfen haben,
dass er halt eigentlich nur
Postgres getestet hat, weil da war
halt irgendwann Schluss und
und er hat halt irgendwie gar nicht wirklich Async getestet und das wäre halt irgendwie nicht okay gewesen, der Benchmark.
Aber ich habe es mir auch selber nicht angeguckt, insofern kann ich das nicht sagen.
Aber das ist auf jeden Fall eine interessante Geschichte.
Ich würde auch sagen, das ist ein schwieriges Thema.
Leute wissen nicht so genau, was sie meinen, wenn sie denn sagen, Async ist schneller.
Also insofern, ich würde auch sagen, wenn man Async irgendwie macht, hat das natürlich einen gewissen Overhead.
also wenn man jetzt einfach nur
ein Programm hat, das irgendwie durchläuft
dann ist das in der Sync-Fassung immer ein kleines
bisschen schneller als in der Async-Fassung
aber wenn man jetzt irgendwie
keine Ahnung, viele Requests gleichzeitig beantworten
will oder so, dann
kann das natürlich mit Async deutlich schneller sein, es kommt halt immer
drauf an, was man macht
also was man misst, also misst man die Zeit von
es fängt an, ein Request zu bearbeiten
bis der Request ist fertig bearbeitet
oder wie viele Requests pro Sekunde
gehen da durch oder so
was misst man da eigentlich
Wichtiger finde ich eigentlich eher
es geht ja darum, dass das ein anderes Programmierparadigma
ist, in dem man bestimmte komplexe
Abläufe
halt zuverlässiger aufschreiben können soll
also
du hast halt manchmal das Problem, dass du
irgendeine Form von Parallelisierung brauchst
Parallelisierung Richtung I.O., Parallelisierung
im Balancing, wer irgendwie
Compute-Zeit kriegt
und Async
ist ja tatsächlich halt, heißt ja erstmal
Async I.O.
und da halt Patterns zu haben, die dann zum Beispiel eben schneller und skalierbarer
auf irgendwie viele Endpoints reagieren können, das sind ja die Themen, wo dann im Linux
oder bei anderen halt das Thema SelectPol, E-Pol
etc. kommen, um zu gucken, wie viel CPU-Overhead muss eigentlich nachher draufgehen
um diese ganzen ausstehenden Ressourcen zu verwalten, damit dann irgendwann wieder
aus der Kernel-CPU-Zeit in die User-CPU-Zeit
gewechselt werden kann, um zu sagen, ah, ich hab ja jetzt, du kannst jetzt wieder richtige Arbeit machen, ich stehe jetzt
nicht bloß da und dreht Däumchen, um rauszufinden, wo was erreicht wurde.
Und das kannst du mit Threads natürlich auch machen, hast aber da dann wiederum halt das Problem,
dass du das ganz schnell in Locking-Probleme und Koordinationsprobleme und gesharete Datenstrukturen
und Async hat halt dort den Vorteil, du kannst es leichter aufschreiben,
weil die Punkte, wann die Kontrollflüsse unterbrochen werden, besser kontrollierbar sind.
Weil du halt weißt, immer nur wenn ich Yield oder wenn ich die Methode verlasse,
die Koroutine verlasse, dann gibt es diese Kontextwechsel,
das heißt, du brauchst an vielen Stellen bei geteilten Datenstrukturen keine Logs etc.
etc. etc. Das ist halt...
Ah, okay, aber das ist interessant.
Ja, ne, das finde ich völlig valide und
ich meine, ich würde jetzt sagen, mit Threads
kann man das ja auch irgendwie, sozusagen,
wenn man halt eine Queue und Logs, gut, ja, eben,
stimmt, braucht man also... Genau, Logs
haben halt das Problem, das sind Kerneldatenstrukturen,
die du fürs Logging halt brauchst und die haben
halt Overhead und das ist halt blöd und wenn du die gar nicht mehr
brauchst, zack, geht das
halt weg. Deswegen ist eher die Frage,
wie verhält sich AsyncIO gegenüber
Threads und für mich die wichtigere
Kombination ist aber, dass du halt Fehler
Quellen eliminierst. Das Dumme
ist halt, Async ist jetzt auch nicht perfekt
und es programmiert sich manchmal auch
ein bisschen komisch, das ist halt so das
Rot-Blau-Problem,
das ist dann halt plötzlich,
dein Python-Code hat halt dann
eine rote und eine blaue Variante, nämlich
die Funktionen, die Sync sind und die
Funktionen, die Async sind und die darfst du nicht
durcheinander bringen.
Die dürfen sich auch nicht gegenseitig aufrufen,
das ist auch eine super coole Sache. Ja genau,
da musst du immer so eine Übergabe-Punkte machen
und das ist tatsächlich so ein bisschen, na, es geht noch
fluffiger. Ja, aber
optimaler. Ja, alles Async.
Das ist die Lösung jetzt gerade.
Furchtbar.
Also ich mache das tatsächlich
eher so, dass ich dann immer mal so Code-Zweige habe, wo ich sage,
jetzt muss ich parallel was machen, jetzt hole ich mal
für diesen Sub-Call-Tree
Async raus,
dann kommt dieser ganze Kram in Async und
danach geht es wieder zurück.
Ja, finde ich
sehr interessant, weil ich hätte jetzt so spontan gesagt,
wenn mich jemand gefragt hätte, was der
oder wo ich den Unterschied sehen würde zwischen
Threads und Async, da würde ich auch sagen,
ja, so Threads ist halt, im Grunde macht das genau das
Gleiche, das ist beides Multiplexen von
I.O.
irgendwie Parallelität und
aber Threads
gehen halt nur beschränkt viele, weil
naja, das sind halt auch wieder
Kerneldatenstrukturen und du hast
halt pro Thread irgendwie ein gewisses Maß,
was man da dann halt
irgendwie anlegen muss und wenn man dann halt
nach ein paar hundert, paar tausend ist dann halt
irgendwie einfach Schluss, während ich mit Async I.O.
halt auch, weiß ich nicht,
halbe Millionen offene
Verbindungen gleichzeitig haben kann.
Weiß ich nicht, ob man es wirklich haben kann, aber so
theoretisch könnte es sein, dass es geht.
Und ja,
das
ist halt auch quasi vergleichbar
schnell. Insofern
kann man dann für solche Sachen, wo man ganz viele
Verbindungen hat, dann halt irgendwie Async.io
eher nehmen als Threads, aber ansonsten, ja.
Und Threads sind halt hässlich zu debuggen,
aber das ist Async.io möglicherweise halt
auch, irgendwie, da habe ich jetzt noch gar nicht so viel
Erfahrung mit.
Ja, die Antwort ist ja.
Es gibt ja andere
Sprachwelten, halt gerade
JavaScript, Node.js.
JavaScript hat von der Sprache her schon
ein besseres Execution-Modell,
was die
Vorhersagbarkeit angeht, wann du die Kontrolle
über die Ausführung verlierst.
Bei Python Threading kannst du halt
bei jedem
Bytecode-Statement
kann es halt sein,
dass die Kontrolle wechselt. Und dann weißt
und
reingeschrieben hat, niemand irgendwie Dinge
getan hat und das
reduziert den Denkaufwand schon
nochmal ganz schön massiv.
Was man häufiger machen muss, ist man
muss, glaube ich, den Code nochmal anders
strukturieren, dass er irgendwie lesbar ist, um ihn für Menschen
wieder sehr realisiert irgendwie
durchgucken zu können.
Das ist auch das, was man halt kennt in der
Python-Welt dann wieder von dem Twisted.
Das Zeug heißt halt nicht umsonst so.
Das Twisted-Modell ist sehr, sehr nah an dem
dran, was AsyncIO im Prinzip macht,
mit den Promises und so einem Zeug.
und am Ende hast du halt für etwas, was du
seriell sync einfach nur
A, B, C, D, E runterschreiben würdest,
plötzlich 40 Funktionen gefühlt,
die sich alle gegenseitig mit
irgendwelchen Promises und Callbacks und wenn der den
aber mit Error-Händler da drüben und wenn
der Error-Händler von dem aufgehört,
da blickt man halt sehr schnell nicht mehr durch.
Da halt eine Balance zu finden, da müssen sich
alle auch erstmal irgendwie dran gewöhnen.
Das gibt es in JavaScript
jetzt übrigens auch, die haben jetzt auch Promises.
Also man kann auch in JavaScript jetzt...
Ja, und mag jemand ganz kurz erklären, was eine Promise denn überhaupt ist?
Weiß nicht, ob das jetzt super gut in die Projektmanagement-Folge reinpasst.
Ja, vielleicht noch ganz kurz, da wäre es gerade so.
Eine Promise ist eine Berechnung, die zu einem späteren Zeitpunkt erst fertig werden kann.
Das heißt, anstatt dass ich sage, das Ergebnis ist 5, sage ich, ich verspreche dir,
dass wenn du das Ergebnis abrufen willst, dann mache ich es auch fertig.
Das heißt, das Promise ist so eine Verpackung für irgendwann wird ein Ergebnis hier sein.
Und die Garantie, dass das Ergebnis vorhanden ist, ist erst da, wenn das Promise abgerufen wird.
Und die Hoffnung ist halt, dass man in der Zwischenzeit so genügend andere Dinge gemacht hat,
dass das Promise quasi in Nullzeit berechnet werden kann.
Weil zwischendurch immer mal wieder eine von den asynchronen Co-Routinen daran arbeitet,
dass das ein bisschen weiter verpackt wird.
Ja, also man kennt, das ist auch eine Verallgemeinerung
von dem, was man von Threads kennt. Also Threads kannst du halt ja auch sagen,
du kannst halt zwei Varianten benutzen.
Du kannst halt entweder sagen, du machst dir einen Threadpool,
wo eine Funktion immer wieder irgendwas abruft und verarbeitet
und dein Thread läuft unendlich lange oder du startest bestimmte Funktionen
mit Parametern in einem Thread und kannst denen dann
joinen. Das heißt, in deinem
Hauptprogramm kannst du irgendwie sieben Dinge anfangen,
kriegst dann die Thread-Objekte und kannst am Ende sagen,
und das Join wird in deinem Hauptthread wieder returnen, in dem Moment, wo der Thread sagt, ich habe mich beendet.
Und eine Future oder eine Promise ist im Prinzip die Abstraktion davon, dass du irgendwelche Calls hast, die dir so ein Future-Objekt liefern
und dann hast du auf dem Ding eine verallgemeinerte Möglichkeit, um zu sagen, also übrigens, falls das schief gehen sollte,
hier ist noch ein Callback, der bitte aufgerufen werden sollte, wenn es schief gehen sollte.
hier ist noch ein Callback, der aufgerufen werden sollte, wenn es erfolgreich ist und sag mal, wie geht es dir eigentlich gerade?
Das ist sozusagen diese Verallgemeinerung von diesen Patterns von
ich lasse irgendwas asynchron ausführen und will dann irgendwann sagen, jetzt hätte ich es gerne,
jetzt warte ich darauf, dass du fertig wirst.
Man kann aber auch in JavaScript inzwischen irgendwie Async-Await-Syntax,
die praktisch genauso aussieht wie in Python, verwenden.
Aber da kommt es dann sehr darauf an, welche
welche Bibliothekwelt man gerade lebt,
was es macht, oder Futures, oder
Await, oder Threads, oder
Timer, oder Callbacks.
Ja, ja. Und was man
tatsächlich dann nicht vergessen darf, ich erlebe
das immer wieder, wenn ich Projekte habe, wo Node.js eine Rolle spielt,
man muss in den
Async-Sachen dieses ganze Thema
Kontrollflusssteuerung mit Exceptions
ganz anders anhaben.
Und mein Liebling, der mir bei Node
immer auffällt, und das passiert auch in Python,
aber halt auch, ist, wenn dann
irgendwelche Datenbanken
angesprochen werden und der
Datenbank-Server geht mal kurz weg und du
kriegst dann halt mittendrin irgendeine Exception von
ja, hier war die Connection weg
und niemand hat im Framework ordentlich
Händler für diese Exceptions registriert,
dann sitzt dein, weil dein
Hauptthread macht später nichts
anderes mehr als nur diesen Loop von
ja, gibt's hier noch Async-Dinge zu tun, ja dann
husch husch husch, ah hier sind wieder neue, husch husch husch
und der beendet sich aber nie
und wenn aber dann halt sozusagen die ganzen
Libraries alle mal gestorben sind,
und nur noch sagen, ja, ich konnte mich ja nicht
connecten und mein Connection-Pool ist weg
und keiner behandelt diese Exceptions,
dann sitzt dein Programm da rum,
tut so, als wenn alles okay wäre
und das Monitoring sagt, läuft doch.
Wurscht.
Wir haben heute erstaunlich wenig
Last auf unseren Rädern. Ja, genau, aber
tatsächlich häufig ist es so, der Web-Server in dem
Ding antwortet dann für irgendwelche Status-Seiten
immer noch, ja, ich bin anwesend,
aber die realen Requests alle auf die Schnauze fliegen
und er zu doof ist, sich zu reconnecten
und das ist was, das hättest du
in einem seriellen Ding
oder einem Synchronen Ding eher weniger,
da würde diese Exception normalerweise bis in den
Mainloop durchbubbeln
und dann explodieren
und dann geht die Anwendung aus,
wird neu gestartet, kann sich zu Datenbank
reconnecten und dann ist alles gut. Das sind sozusagen
Sachen, da hat man jetzt sozusagen Probleme, die
eigentlich schon mal auf eine andere Art gelöst waren,
die hat man sich jetzt nochmal eingefangen, die muss man jetzt
mit ordentlichem Handwerkszeug neu machen,
aber ordentliches Handwerkszeug,
ich will jetzt nicht zu sehr über die
Tourscript-Weltherzigen.
Aber das ist ja in Python genauso.
Also ich meine, die Sachen können ja auch in Python
abspringen. Aber da kann man jetzt vielleicht noch mal
einen Übersprung
zum Ausländer Dominik hat mal mehr News.
Wusch, wusch, wusch, Wackmanagement.
Weil
dieses ordentliche Handwerkszeug ist ja durchaus
sowas, was man versucht, über Projektmanagement
in den Griff zu kriegen. Ja, dass man halt sagt,
okay, bevor jemand
irgendwas hier in den Masterbranch pushen darf,
müssen alle Tests gelaufen sein
oder irgendwie sowas. Dass da halt das über
über quasi Prozesse in den Griff kriegst,
die nicht in der Software drin sind, sondern in den
Menschen.
Jetzt könnte ich dazu ja gerade mal so die
auf meinem Stieferzettel für heute
die, ich wollte so diese Antithese
gerade, ich wollte mit dem bösen
Onkel spielen, aber ich fürchte,
ich bin zu nah an dem dran, was du gerade
tatsächlich aussagen wolltest.
Also ich beobachte
Projektmanagement in den letzten Jahren
häufig als eine Art Form
von industrialisierte, weaponized
Möglichkeit, um
Entwickler möglichst zügig
in einem Zwei-Wochen-Rhythmus
durch eine Ticketliste zu prügeln.
Da bist du aber tatsächlich mit...
Würdest du sagen,
es funktioniert, oder würdest du sagen, es funktioniert nicht?
Das funktioniert halt
in den Fällen, wo die Leute nichts Neues machen müssen,
sondern halt tatsächlich einfach bloß
das Zeug abarbeiten, was sie immer machen.
Ja, aber da würde ich sagen,
das ist natürlich dann eigentlich...
Da brauchst du auch kein Volksmanagement.
Das ist eigentlich nur Bearbeiten von Tickets, dann stellst du dich hin
und Ticket, Ticket, Ticket, Ticket, Ticket, Ticket, Ticket.
Das ist aber kein Projektmanagement.
Das ist ja auch eine Art von Projektmanagement.
Die Priorisierung dann, welches Ticket du nimmst,
oder machst du die Reihenfolge nach,
oder wann die aufgenommen wird,
für das Infos,
was ist denn ein Projektmanagement?
Vielleicht fangen wir da nochmal ganz von vorne mit an.
Was ist ein Projekt?
Da haben wir uns doch letztes Mal schon drüber gestritten.
Ja, das letzte Mal haben wir aber wieder weggeschmissen,
das musst du nochmal anfangen.
Schalten wir einfach nochmal die gleichen Personen
über das gleiche Ding und hoffen,
dass es jetzt mal anders ausgeht.
Ja, ich war nicht dabei,
dass wir heute was anderes sagen.
Also ich kenne die Definition von Projekt so,
und Jochen unterhalten sich über die Programmiersprache Python
definiert, dass du
hinterher sagen kannst, ja, das Projekt war erfolgreich oder
das Projekt war nicht erfolgreich oder es war teilweise erfolgreich.
Das ist ja schon sehr konkret. Also es ist nicht einfach Arbeit, die
zu tun ist. Genau, es ist
nicht einfach Arbeit, die zu tun ist, sondern es ist ein Ziel.
Du willst ein Ziel erreichen. Das kann natürlich,
das Ziel kann natürlich sein... Arbeit ist
fertig. Der Zeitraum ist
zwei Wochen und in zwei Wochen sind
folgende Tickets abgearbeitet. Das ist ja auch ein Ziel.
Das ist auch ein Projekt in dem Sinne.
Naja, also welche Dimension hat denn das zum Beispiel
so ein Ziel? Ich kann jetzt ja ganz viele
kleinteilige Ziele machen und die unter einem großen Oberziel und ganz vielen
großen mehreren Zielen machen. Ab wann fängt da ein Projekt an?
Ja, das ist jetzt das Projektmanagement. Das Projektmanagement, wie du deine Projekte
managst, sagt im Wesentlichen, wie lange deine Projekte sind und wie groß die Ziele sind.
Du kannst natürlich ein Projekt machen, das heißt
Firma und das Projekt heißt
Geschäftsjahr und das Ziel ist es, am Ende des Geschäftsjahres
viel Umsatz gemacht zu haben.
Profit, Profit, wir treten nach Profit.
Genau, sagst einfach Profit. Wir wollen am Ende das Geschäft
als Profit machen. Und das ist super gut, weil du weißt
ganz genau, es geht vom 01.01. bis zum 31.12.
und dann guckst du
am 31.12. nach deinem Dashboard
und siehst, wie viel Profit du gemacht hast
und das ist super gut messbar. Aber es ist
für die Ausführung,
für die Durchführung des Projektes vielleicht
nicht so gut, weil da nicht drin
steht, weil da nicht
dran hängt, was du tun kannst.
Und
und das ist sozusagen das größte Projekt, was du machen kannst.
Ich will über die längste Zeit, die ich mir denken kann, möglichst viel Gewinn machen.
Das kleinste Projekt, was du machen kannst, ist ein Meeting.
Du gehst in ein Meeting und sagst, das Meeting dauert von neun bis zehn
und das Ziel ist es, wir müssen entscheiden, ob wir JavaScript oder Python verwenden.
Und das wäre ein Wochenprojekt.
Wenn du das möchtest, kannst du das auch als Projekt sehen,
weil es ist ein zeitlich begrenztes Vorhaben, was ein definiertes Ziel hat.
Die Frage ist, wie sinnvoll ist das? Ist es jetzt sinnvoller, eine Million Projekte zu haben, die so klein sind, oder ist es sinnvoller, ein Projekt zu haben, was sehr groß ist?
Kann man denn ganz viele kleine Sachen managen oder braucht man was ganz Großes managen? Was ist denn da managen? Was heißt das? Strukturiere ich das um? Priorisiere ich das? Mache ich eine große Liste, wann und wie was gemacht werden muss? Versuche ich alle Menschen bei Laune zu halten, um zu gucken, dass sie einfach arbeiten?
Was ist das? Ja, alles was du sagst, würde ich sagen.
Also alles, was du tun musst, um
deine Ziele zu erreichen.
Was ich halt spannend
finde,
ich habe gerade nebenbei noch die Wikipedia
offen gehabt und ich habe festgestellt, es gibt eine DIN
für den Begriff Projekt.
Sehr schön. Es gibt eine DIN für alles.
Es gibt die DIN
6901.
Die sagt, ein Projekt
ist ein Vorhaben, dessen Wesentlichen durch die
Einmaligkeit, aber auch Konstante der Bedingungen
wie ihre Gesamtheit gekennzeichnet ist,
wie zum Beispiel Zielvorhergabe, zeitliche,
finanzielle, personelle, andere Begrenzungen,
Abgrenzungen über anderen Vorhaben
und die projektspezifische Organisation.
Also was ich
interessant finde an der Stelle ist
dieses Thema Einmaligkeit
und Zielgerichtetheit und
wenn ich
an der Stelle jetzt drüber nachdenke,
das gilt halt für
viele Dinge, die
ich so sehe,
wenn man jetzt mal fragt, okay, was tun
wir eigentlich den ganzen Tag lang,
dann gilt es halt fast gar nicht mehr so.
Also zeitliche Abgegrenztheit, also ich finde zum Beispiel
jetzt diese Metapher mit
das Geschäftsjahr einer Firma, das ist so ein bisschen
sehr synthetisch und sehr hergeholt,
weil
tatsächlich so diese Einmaligkeit und zeitliche
Begrenztheit ja eigentlich nicht gegeben ist, die ist ja
nicht aus diesem Zweck selber raus.
Und wenn man halt Organisationstheorie anguckt,
sollte ein Unternehmen im Prinzip tatsächlich auch
erstmal noch andere Funktionen
haben als nur die Erwirtschaftung des Profits.
Natürlich, das war
als Beispiel für die größte Einheit,
die man sich denken kann.
Und ich finde es aber spannend, weil
dieses Thema Einmaligkeit und
Zielgerichtetheit heutzutage in
vielen Aufgaben,
die vor einem liegen, gar nicht mehr so
gegeben sind. Oder halt dieses Thema
konstante Ressourcenallokationen,
solche Dinge.
Ich finde es viel interessanter,
für mich ist das ganz anders.
Es ist voll witzig, dass du genau diese
beiden Begriffe rauspickst, weil für mich ist
der zeitliche Aspekt, einer der heutzutage viel schwammiger behandelt wird, als man das vielleicht früher gemacht hat.
Das ist richtig. Der zeitliche ist für mich tatsächlich, der löst sich für mich halt auch auf.
Ich wollte es vom anderen Ende aufziehen gerade, weil ich jetzt ein paar Mal mit Leuten es davon hatte,
dass eigentlich das, was bisher klassische Projekte sind, inzwischen eigentlich Produkte sind.
Also ich habe ganz viele
Ja oder Vorhaben
Ja ich finde halt
häufig schon wirklich Produkte
in so einer Kombination tatsächlich
auch
wir haben, also bei uns ist es so, wir haben gerne mal
Kunden, die irgendwelche
eher so Geschäftsansätze
Business
Ideen haben, aus ihrem
eigentlichen Geschäft raus
und die suchen sich irgendwen, der das
eigentliche Produkt, also wenn da ein digitales Produkt
raus, entsteht jemand anderes, der das implementiert und irgendwer muss das Ding dann operativ
irgendwie betreuen und da kommt dann aber sofort so ein
Perpetuum mobile schon fast raus, wo man davor steht und sagt, okay,
es ist halt kein Projekt, weil das ist halt zeitlich nicht begrenzt, sondern wir wollen das im Prinzip als
wie eine Art Mini-Unternehmen nach vorne treiben und es ist halt
auch nur mäßig zielgerichtet im Sinne von, es gibt halt kein
festes Ziel, von haben wir das erreicht oder nicht, sondern es gibt mehr ein, ja, wir haben hier irgendwie
und Jochen unterhalten sich über die Programmiersprache Python
oder ich glaube nicht in der DIN, aber in der Literatur.
Das heißt dann Programmen oder Vorhaben oder solche Dinge.
Aber ich meine, ergibt sich das nicht quasi so relativ zwangsläufig aus?
Also wenn ich mir jetzt so vorstelle,
also ich kenne das halt aus dieser ganzen Agile-Welt,
es gibt so ein magisches Dreieck an Ressourcen, die begrenzt sind
und die man halt sozusagen nicht unabhängig voneinander irgendwie verändern kann.
Das ist halt Zeit, irgendwie Geld, das man dafür ausgibt und halt irgendwie,
na, was war das dritte?
Qualität.
Ach ja, die wird immer so, die vergess ich auch manchmal.
Es gibt manchmal auch mal einen vierten davon, Funktionsumfang.
Genau, genau.
Und das Problem ist jetzt sozusagen, dass zwei von den Dingern eigentlich nicht so richtig
optional sind, also die Qualität will man eigentlich nicht
offern oder die Features.
Und Geld,
wenn wir jetzt auch nicht
beliebig da rumliegen, dann bleibt ja eigentlich
nur die Zeit, die variabel sein kann.
Und die wird es dann halt auch irgendwie immer.
So dass es halt irgendwie...
Gestern.
Ja, aber das ist doch die Aufgabe
des Projektmanagers, dafür zu sagen, dass es
gestern fertig ist.
Ja, aber das ist halt auch mehr spannend. Also es gibt ja
verschiedene Perspektiven, die ihr jetzt genannt habt. Es gibt halt die
Perspektive von dem Kunden
beispielsweise, der jetzt sein ganzes
großes Projekt da hat und dann
da Pivots machen möchte und wenn
er dafür Menschen beauftragt, die haben dann vielleicht
ein kleines Projekt in diesem Projekt drin. Das heißt, aus
deren Perspektive ist das nur
ihr eigenes abgeschlossenes Projekt, wenn dann
ihre Aufgabe nach zwei Monaten erledigt ist oder so.
Obwohl das nur ein Baustein in dem großen Projekt
des anderen war. Und das ist halt wieder diese Verschachtelung
von den einzelnen Projektebenen. Und die Frage ist,
wie man das halt vernünftig hinbekommt,
dass man das so organisiert, dass man einzelne
Arbeitspakete hat.
Ich weiß nicht, ob ein Arbeitspaket ein geeignetes Maß ist, um ein Projekt zu managen?
Gibt es überhaupt Metriken? Ist das wichtig, dass man irgendwas messen kann?
Oder geht es um den Erfolg?
Also was ich spannend finde, was ich bei uns halt beobachte von der Granularität her,
wir versuchen immer, das geht ja auch in die Frage von, wie kann man solche Sachen verschriftlichen,
welche Tools nimmt man dafür?
Wir schreiben gern ganz viele Sachen in Tickets rein.
und uns ist es wichtig, dass wir ein System haben, wo alles, was irgendwie die Firma berührt, in Tickets landet,
damit ich halt auch ein bisschen Kreuzreferenzieren kann etc.
Und da ist tatsächlich für uns immer wieder dieses Thema, weil wir ja eher auch so ongoing als direkt projektorientiert sind.
Ich würde auch sagen, wir haben manchmal so Projekte, wo wir sagen, jetzt hat es hier irgendwie einen abgeschlossenen Fokus,
wo wir mal für zwei, drei Monate versuchen, wie das, all die sieben Sachen zusammenzubündeln und einmal durchzuprügeln,
um sie dann auch mal wieder
loszuwerden und sagen, jetzt brauche ich mich nicht mehr
drum zu kümmern, jetzt denkt da keiner mehr
drüber nach, jetzt haben wir gerade zum Beispiel das Netzwerk
einmal bei uns saniert und dann
war das halt mal für drei Monate was, was
stärker im Fokus war und was eine ganze Reihe
von zusammenhängenden Aufgaben
hatte und
da finde ich es zum Beispiel spannend
für mich gibt es so eine Balance
und ich habe keine Ahnung, was eine gute
Antwort ist, dass wir auf der einen Seite Unmengen
Tickets generieren und für die
Leute in so einem Team in einer und Jochen das ganz unterschiedliches Gewicht ob da jetzt zum Beispiel 5000 Tickets rumliegen um die sich nie wieder einer k wird Da denke ich mir so das ist kein Problem
die machen wir einfach alle zu, als
haben wir erfasst, steht da drin, wenn man
mal irgendwann nochmal danach suchen
möchte von, haben wir schon mal nachgedacht
über XYZ, dann sieht man, ah guck mal, da gab es
schon mal drei Sachen, warum waren das, wieso,
weshalb, warum, versus andere,
die dann gegebenenfalls
denken, jetzt kommt hier ein Ticket rein, fuck, das muss irgendwie
abgearbeitet werden.
Ja, aufgeräumtes Backlog oder
Reds.
Das macht dann halt Stress und auch Backlog ist tatsächlich so,
da neigen wir gerade eher dazu zu
sagen, also alles, was nicht
freiwillig sozusagen bei jemandem innerhalb von
zwei Wochen auf dem Tisch landet,
kannst du halt im Prinzip auch gleich zumachen,
weglegen, aber
vernünftig ein bisschen mit Metadaten versehen,
so zu welchem Bereich gehört denn das so grob, was hat
denn das noch für zwei, drei Tags oder so und dann
kann man, wenn man dann mal auf die Suche geht von
so, okay, was haben wir denn im letzten Jahr für
Notizen uns gemacht zum Thema
XY, weil da wollen wir jetzt nochmal rangehen, dann kann man
die dann wieder rausholen, aber du musst
die nicht ständig pflegen und machen und tun
und das
hilft halt den Leuten auch, wenn der sagt, ja komm, mach
einfach Tickets, immer her damit, immer her damit, immer her damit,
dann hast du so ein bisschen organisationales Wissen halt
auch an der Stelle, ja. Wie macht ihr denn
Tickets, wenn ihr gerade so bei Tickets
sind mit Python oder?
Macht ihr Tickets für wirklich
alles? Macht ihr Tickets auch für, keine Ahnung,
Kaffeemaschine ist kaputt oder für,
keine Ahnung, Kunde muss
gefunden werden?
Ja, genau.
Also das kommt immer drauf an,
wer das halt macht. Also wenn die Kaffeemaschine,
da muss ich halt überlegen,
es kann sein, dass meine Kollegin,
die dafür zuständig wäre,
sich da ein Ticket macht, um sich zu erinnern, weil das halt auch
in Summe den Alltags-Arbeitsorganisationsflow
abbildet.
Weil halt jeder, weil jedes Team
halt so seine Flowboards auch hat mit
was liegt denn hier irgendwie gerade im Team
eigentlich so alles an und dann willst du halt auch sehen,
ah, ständig mal eine Kaffeemaschine machen, dies und jenes.
und
auf der anderen Seite habe ich aber halt auch
häufiger mal Sachen, weil auch ein Ticketsystem
relativ schwergewichtig ist, habe ich so meine eigenen kleinen
To-Do-Listen noch, wo ich dann irgendwann sage,
jetzt schreibe ich das ja ewig rum,
jetzt ist es mal wieder zu viel geworden, jetzt mache ich da irgendwie Tickets
draus, damit ich es wieder auch anderen Leuten im Team geben kann.
Okay.
Ja, das ist spannend,
dass ihr alles über Tickets macht.
Ja, aber ich kann das
total verstehen, dass das für unterschiedliche Leute eine total
unterschiedliche Bedeutung hat.
Ich kann aber auch verstehen, dass es Leute gibt
oder dass es vielleicht Positionen gibt, die damit
überhaupt nicht klarkommen
weil die eben nicht
so einzelne Arbeitspakete haben
sondern weil die vielleicht eher eventgesteuert
sind oder weil die eher dauerhafte Aufgaben
haben
Das klassische Beispiel ist halt
ein Callcenter Mitarbeiter
der wartet
halt auf einen Anruf, der kann keine Tickets
bearbeiten, um es mal sozusagen bis in jemand
anruft und da hilft es auch
X, weil er 10 Tickets auf seinem Tisch hat, weil er halt
auf dieses Event warten muss.
Umgekehrt gibt es natürlich so Sachen, die
ongoing sind.
Du musst halt jeden Tag
die Post abholen
und du musst jeden Tag die Rechnungen
verschicken und du musst jeden Tag die Eingänge
prüfen und was weiß ich. Und dafür Tickets zu haben,
stelle ich mir auch schwierig vor.
Also diese Ticketsachen passen
schon eher zu dem, was man so als Softwareentwickler
macht.
Das kommt total drauf an, weil wir haben
und Jochen unterhalten sich über die Programmiersprache Python
auf einer Wiki-Seite sagen,
zu diesem Prozess gehört es,
dass einmal im Quartal jemand
irgendwie nachguckt, ob
im One Password irgendwie die
richtigen Leute drin sind oder noch Leichen
rumfliegen oder irgendwie sowas.
Und dann gibt es tatsächlich einen Con-Job, der aus
diesen Daten dann die Tickets generiert
zum richtigen Zeitpunkt und du kannst
sozusagen so Wiedervorlage-Tickets
in der Prozessdefinition
hinterlegen. Und das ist dann auch so
ein Mittelweg zwischen, ja, also alles, was man täglich
machen muss, das brauchst du, glaube ich, nicht in Tickets nachweisen,
aber wenn es dann plötzlich auf alle 2 Wochen, 4 Wochen
8 Wochen geht, dann willst du dir vielleicht
schon eher Erinnerungen machen können
Ja, aber dann
ist es ja wirklich eher erstmal so ein To-Do-Item
also sowas ganz leicht gewichtiges
Es gibt ja auch Tickets, wo du
8 Wochen brauchst und ein Team
von 10 Leuten
zu bearbeiten und
da diese Spanne, finde ich auch was ganz
Spannendes, das ist auch das, was
Dominik eben angesprochen hat und
das ist so im Wesentlichen die Kernfrage
von Projektmanagement. Wie groß sind
die Projekte, die man macht? Sind die ganz
klein? Sind die eine Woche lang eine
Person? Oder sind die ganz groß?
Vier
Jahre und ein Team von 150
Leuten. Und wie
dröseln wir das dann auf, wer was an welcher
Stelle in welchem Projekt macht?
Da würde ich sagen, erfahrungsgemäß
sind die eher groß.
Also die Sachen
klassischerweise ja.
Die irgendwie dann einzelne
Entwickler macht oder so, die sind ja dann meistens, aber die nennt man
ja nicht Projekt, sondern das ist dann halt irgendwie
ein Task oder
eine User-Story. Definitionsgemäß
sind es natürlich schon auch Projekte.
Ja gut, okay, aber die gehören
immer zu irgendeinem, also es gibt immer
meistens eine Projektnummer, auf die das dann irgendwie
gebucht wird oder so und diese Projektnummern sind
die sind sozusagen, ich weiß nicht, die werden
irgendwie mal beim Urknall erzeugt worden sein
und die sind halt ewig, die verändern sich auch nicht.
Die fallen halt auf alte Projekte.
Ein Projekt ist einfach so eine kostenstelle.
Ein P raus.
Ja, wir haben halt die Herren S, A und P irgendwann mal.
Ne, da geht es ja dann wieder tatsächlich noch in den anderen Bereich rein,
dass Projekte auch ein KommunIKATIONSMITTEL sind und auch
eine gewisse vertragliche Vereinbarung enthalten können, weil
Projekte eben ein Mittel sind, wie man mit einem Kunden kommunizieren kann.
Du sagst, okay, wir machen jetzt erstmal ein Projekt und das hat eine gewisse Schwere.
Das ist nicht was, was du einfach so machst, sondern wir machen mal ein Projekt und das hat
gewisse Komponenten, die da sein müssen.
Weil du den zeitlichen Rahmen festlegen musst, weil du die Ressourcen festlegen musst, weil du das Ziel festlegen musst.
Ja, aber dafür braucht man ja schon die ganzen Informationen, die man vielleicht ja noch gar nicht hat.
Das heißt, was man da irgendwie machen muss, ist irgendwie so eine Pi mal Daumen-Schätzung oder die mehr oder weniger valide Schätzung abzugeben.
Ja, klar.
Aber das ist ja nicht möglich bei unbekannten Dingen. Also das geht ja nur dann, wenn man sowas mal kennt.
Ja gut, du hast halt ein Projekt, was eventuell sein Ziel nicht erreicht oder was verlängert werden muss oder was über Budget geht.
aber das haben wir ja glaube ich alle schon mal erlebt
also immer
aber es war ein gutes
Vorjahrsmenschen
da merke ich auch, da versuche ich eher
anders an die Sachen heranzugehen, wir haben
ein bisschen den Vorteil, dass wir typischerweise
eben aus dieser
operativen Sicht kommen, wo eh alles
ein ongoing concern ist im Prinzip
wo man halt auch mal sagen kann, so ja
okay, jetzt machen wir hier mal
wir machen praktisch
keine Projektarbeit, aber natürlich haben wir
das Thema, dass halt
und
automatisiert und operationalisiert wird.
Dann habe ich aber einen ongoing concern
daraus gemacht. Oder
es ist was total Unbekanntes
und in einer komplexen Welt
will ich bei was Unbekanntem mir nicht
schon ein Ziel setzen,
weil ich damit psychologisch
das Problem aufmache, dass ich halt
unterschätze,
wie viel Erkenntnisgewinn ich auf der
Reise eigentlich einsammle,
um dann zu dem eigentlichen Ziel zu kommen.
Das ist glaube ich das, was der
Dominik sagen wollte, oder?
Ja, also ihr müsst vielleicht erstmal nochmal die ganzen kleinen Sachen definieren, die unsere Hörer vielleicht gar nicht kennen. Zum Beispiel, was ist denn Kinevin?
Kinevin ist ein Ansatz von einem walisischen Professor namens Dave Snowden, nicht verwandt mit Edward Snowden.
Und der beschäftigt sich so seit den 80ern mit Knowledge Management, war lange bei der IBM und hat beschäftigt sich mit komplexen Systemen, auch komplex-adaptiven Systemen genannt.
und schreiben
geschrieben wird Knevin mit C-Y-N-E-F-I-N
die Valiser haben sehr lustige
Ausspracheregeln, deswegen kommt da dann am Ende
Knevin raus
und da geht es zum Beispiel darum, dass man
halt multimodale
Entscheidungssysteme
braucht, dass du halt in der Lage sein
musst zu sagen, ja für bestimmte Arten
von Problemen muss ich halt unterschiedliche
Lösungsstrategien angehen können
und gleichzeitig ist es auch nicht so, dass ein
bestimmtes Problem absolut
und Jochen unterhalten sich über die Programmiersprache Python
oder halt
eher bürokratische einfache geordnete Systeme, wo ich halt weiß, okay
wenn der Herr einen Ausweis will, dann müssen wir hier halt das Verfahren X
abarbeiten und dann kommt da hinten ein Ausweis raus.
Und was da spannend dran ist, ist halt das nicht ontologisch zu betrachten von
ja ist ein Problem jetzt einer dieser Domänen zuzuordnen,
sondern die Frage ist, was lerne ich über ein Problem, wenn ich es aus einer dieser
Brillen halt betrachte,
um es dann gegebenenfalls
zu zerteilen und zu fragen, so was in diesem Problem wäre denn etwas, was man mit
Expertenwissen erschlagen kann, wo sich jetzt
einer mal mit der Timebox eine Woche Zeit nimmt
und sagt, so, dick, lehne dir das mal durch,
habe ich danach eine Lösung, sehr gut. Oder
ist die Frage, ist es komplex,
müssen wir im Prinzip erst anfangen,
mit dem Ding ein bisschen zu spielen,
um was drüber zu lernen,
um dann zu gucken, ob wir es weiter zergliedern können,
um zu wissen, aha, hier geht es in die richtige Richtung,
hier geht es in die falsche Richtung, oder brennt mir
hier gerade irgendwie alles ab und ich muss erst mal
draufhauen und danach fragen.
Und das sind
Ansätze, wo ich merke, die gehen
in alle möglichen definierbaren Teile
zu gliedern, die dann entsprechend
schätzen und bepreisen, dann wirst du dir
halt auf und dann bist du halt fertig.
Und diese Ansätze berücksichtigen ja keinerlei
Interaktionen und Erkenntnisgewinne
auf der Reise oder wie Dinge halt
komisch sich verzweigen und
heute sind wir dummerweise wieder an einem
Punkt, ich nenne das dann immer Weaponized Agile,
dass man halt eben sagt, agil
ist jetzt, wenn eine große Firma sich
Scrum einkauft, jedes
und die Technik.
Haben wir aber alle schon mal gehabt solche
Ja, das ist halt so, wo ist denn das Problem?
Ja, gut, ich würde jetzt
sagen, so aus Agile Perspektive ist es halt so,
sowas sollte man sich nicht vornehmen, weil einfach das
Risiko, dass das schief geht, ist halt zu hoch.
Kann man das nicht vielleicht irgendwie ein bisschen
in Teile aufteilen,
aber, und das geht ja dann meistens auch
irgendwie.
Ja, aber ich finde das sehr interessant
und ich finde, also möglicherweise
und ja, eben, was man für Probleme hat,
hängt halt unter Umständen auch damit zusammen,
eben, ob man jetzt eher Projektgeschäft macht oder
eher, ja, irgendwie operative
Geschichten, so Produktionen.
Ich glaube auch, dass da ein großer,
dass da noch ein wichtiger Unterschied ist,
den man vielleicht nicht so,
ja, ansonsten,
wenn man das jetzt schon auf irgendeine
Methodologie einschießt, vielleicht nicht so wahrnimmt,
aber der ist, glaube ich, tatsächlich
sehr relevant
und es geht üblicherweise
in eine bestimmte Richtung immer sehr schief.
nämlich man hat halt einen Unterschied
wenn ich jetzt zum Beispiel bei Softwareentwicklungen
wenn ich darüber nachdenke
wie funktioniert das
was macht man da eigentlich im Gegensatz
zu weiß ich jetzt nicht zum Beispiel
irgendwas
man hat ein Fastfood-Franchise
Restaurant irgendwie sowas
Hast du Hunger?
Ein bisschen
Softwareentwicklung hat halt immer auch sowas
Exploratives dabei oder man weiß am Anfang
noch nicht wie die Lösung aussieht
Ja, naja, sag mal so, die Prinzipien,
also wie man das managt, ist halt
sozusagen fast umgekehrt. Also
bei so einem
Fast-Food-Franchise würde ich sagen, also
man muss Sachen standardisieren, man muss halt
zusehen, dass irgendwie
keine Fehler passieren,
dass man einfach die Fehlerquote kontinuierlich
senkt, dass keine Überraschungen passieren,
dass alles irgendwie
so wie es im Buch steht halt
gemacht wird. Man muss halt irgendwie dafür
sorgen, dass die Leute irgendwie pünktlich
zur Arbeit kommen und dass halt
irgendwie die ganzen formalen Geschichten
eingehalten werden. Das ist alles total
wichtig und keine Experimente.
Es gibt irgendwo eine Zentrale, da überlegen die sich
vielleicht neue Rezepte oder so, aber irgendwie
die Leute im Restaurant sollen
halt austauschbar sein und die sollen halt
irgendwie funktionieren und das Ganze
ist quasi so eine Maschine und die soll halt laufen,
damit da irgendwie Cheeseburger rausfallen und die Leute
glücklich sind oder dick oder was auch immer.
Ja, aber das löst doch auch nur so ein gewisses Problem, oder?
Genau, das löst halt dieses...
Ja, aber
Das Ergebnis davon ist halt ein Fastfood-Hamburger.
Und wenn du einen guten Hamburger essen willst,
gehst du nicht zu einem Fastfood-Laden,
weil da kriegst du zwar immer den gleichen
und auch auf der ganzen Welt überall immer den gleichen,
aber du kriegst halt auch immer nur den Fastfood-Burger.
Ich glaube auch bei...
Oder genau.
Also was du ja beschreibst gerade ist eben,
das ist die Optimierung auf Effizienz.
Das ist, du willst möglichst viel Output
mit möglichst wenig Input haben.
Das ist Effizienz.
Und Standardisierung.
Du willst immer den gleichen Output haben.
die gleiche der ist, umso besser
genau, du willst auch
wenig Variationen da drin haben
die
Seite bei der Softwareentwicklung
und Explorativen ist halt
solange du gar nicht weißt, was du tust
musst du ja erstmal an der Wirksamkeit
der Lösung arbeiten, du musst erstmal die Effektivität
herstellen, du musst erstmal fragen, tue ich ja eigentlich
das Richtige und ich meine
das willst du halt auch nicht
das ist jetzt philosophisch abstrus, ich muss sehr an die Simpsons
einen Jugendlichen, der immer beim
Hamburger Journalist sagt, du willst nicht, dass er sich die Frage stellt,
ob er hier gerade das Richtige tut.
Das willst du halt nicht.
Der kommt nachher auf die Idee,
seinen Lebenssinn eine Frage zu stellen.
Das wäre für den Ausdruck der Bürger
jetzt eher schwierig.
Nachher sagt er, ich will gar nicht arbeiten.
Ich würde sogar noch einen Schritt
weiter gehen und sagen, bei Software
weißt du am Anfang oft gar nicht, was das Ergebnis sein soll.
Genau.
Solange du nicht weißt,
Was du für einen Burger haben willst, kannst du auch keinen Prozess machen, diesen Burger herzustellen.
Und Achtung, natürlich gibt es da einen Zwischenton im Sinne von, wenn du mit deinem Handwerkszeug effizient umgehen kannst,
im kleinen, im Sinne von, wie schreibe ich Code und wie strukturieren wir eine Softwarebasis etc.,
dann kannst du natürlich kostengünstiger mehr explorativ machen, als wenn du die ganze Zeit nur dabei bist,
irgendwie dagegen, also wer nicht zehn Finger
schreiben kann,
nicht jeder muss zehn Finger schreiben können,
aber wer halt,
wer Schwierigkeiten hat, eine gewisse Menge
Code effektiv und effizient ins
System reinzukriegen, der kann halt nur schwierig
experimentieren, weil es halt
sehr teuer ist, halt mal vorwärts, rückwärts,
links, rechts und da ist aber auch tatsächlich
diese klassische Projektmethodologie drin, du willst
die Fehler während des Prozesses minimieren,
weil die nach hinten heraus
halt explodieren, während wenn du sagst, naja,
es ist für mich leicht,
und Jochen unterhalten sich über die Programmiersprache Python
eines Produktmanagements,
dann willst du aus so einer Kombination aus,
da gibt es Leute, die haben halt ein Business
anliegen, da gibt es Leute, die können
Software entwickeln, da gibt es Leute, die betreuen sowas
operativ und aus denen willst du
einen andauernd laufenden
Co-Creation-Prozess bauen,
wo jeder im Prozess die Möglichkeit hat,
Erkenntnisse einzufüttern, um dieses, was tun
wir hier eigentlich,
weiterzuentwickeln und anzufüttern und nicht
nur dieses, ja, haben jetzt alle ihre Aufgaben gemacht,
dann ist jetzt das Projekt vorbei, dann brauchen wir es
jetzt für fünf Jahre nicht anfassen und es läuft jetzt hier
vor sich hin. Ein Co-Creation-Prozess.
Das ist schön.
Ja, das ist halt, wenn man mal versucht,
irgendwie dieses blöde Thema Digitalisierung
mit irgendwas sinnvoll zu unterfüttern,
dann finde ich,
ist gerade so ein Begriff wie
Co-Creation das,
wo man tatsächlich Wert schöpfen kann, wo du
wirklich sagen kannst, was ist jetzt an Softwareentwicklung,
außer von, ja, wir haben es jetzt
perfektioniert, möglichst schnell
Fachanwendungen mit immer den gleich aussehenden
Formulareingabefenstern
auszukotzen.
was kann man eigentlich besser machen?
Und besser machen ist eben tatsächlich zu sagen, naja, du willst
in den Alltag rein, bis zum
Nutzer, diese
Konversation
mit dem komplexen System von was tun
wir hier eigentlich und was geht eigentlich
unterfüttern.
In dieser Komplexen heißt es
unarticulated needs,
weil du halt das Problem hast, dass die Leute,
die das Zeug einsetzen, dir vorher,
die verstehen heutzutage nicht,
was kannst du eigentlich alles bauen
und du kannst nicht kommunizieren, was in ihrer Domäne jetzt vielleicht sinnvoll wäre zu bauen.
Das heißt, du musst auf eine gemeinsame Reise gehen, um eine Sprache zu entwickeln,
um tatsächlich im täglichen Dienstag früh um sieben, mein Patient ist komisch ausgerutscht,
weil das Programm mir gestern vergessen hat, auf eine sinnvolle Art zu sagen,
dass da bitte eine Mathe hinzulegen ist.
Diese Schleifen brauchst du halt nicht am grünen Tisch von irgendeinem Produktmanager.
Produktmanager, du brauchst diese Schleife tatsächlich zwischen, bis zu da ist der
Patient hingefallen, weil XYZ. Und diese Informationen ordentlich durch die Gegend zu
leiten ist tatsächlich auf einer ganz anderen Ebene, als was man klassischerweise unter
Projektmanagement verstehen würde.
Das ist jetzt aber schon ein sehr agiler Ansatz, dass du den Kunden direkt in das Projekt
einbettest, dass du erstmal den Kunden beobachtest und dass du das immer in kleinen Schritten
machst.
Aber nochmal ganz kurz, um das mit den Produktions... Also ich fand, genau, finde ich alles richtig,
und Jochen unterhalten sich über die Programmiersprache Python
eben experimentieren, eigentlich
sozusagen mehr vorantreiben
als verhindern. Du musst halt irgendwie
sagen, okay, naja, Fehler können halt passieren.
Es kann sein, dass man mal eine Zeit lang in eine falsche Richtung läuft.
Da muss man sich halt umdrehen und in eine andere Richtung laufen.
Was man aber tatsächlich oft sieht, ist halt
sehr defensives Management an der Stelle.
Zum Beispiel, also alle
sagen immer, dass Fehler gut sind und dass es kein Problem ist
und dass man daraus lernen kann und anders gar nicht lernen kann
und so. So Lippenbekenntnisse hört man oft.
Aber was man auch in den
meisten, also ganz oft, was ich da
höre, ist immer sowas wie
ja, wenn man zum Beispiel
jetzt sieht in einem Projekt irgendwie, das ist so ein bisschen
in der Sackgasse gelaufen, dann sieht man das so als
zum Beispiel jemand, der so extern dazukommt und denkt
sich so, also da geht es irgendwie
nicht weiter und dann spricht man das an und dann
oft erst so informell und dann
kriegt man halt zurück, ja, das wissen wir
ja alles, aber das geht jetzt halt nicht
anders und das läuft schon so lange und
machen wir das lieber schrittweise, machen wir lieber Tickets
und so, dann denkt man sich so, ja, aber wo soll das hinführen?
Das geht nirgendwo hin, das ist
ein Dead-End-Ticket.
Ticket graben.
Das ist schon freigegeben.
Du hast schon die Freigabe, dann musst du es auch machen.
Ja, aber genau.
Und dann kann man...
Das ist halt dann aber nicht mehr, wenn das
nicht geht, dann...
Oder wenn einem die Leute sagen, wenn man dann sagt, okay,
probieren wir das einmal, dann sagen die, nee, das ist politisch nicht durchsetzbar.
Dann weiß man, okay,
hier ist ein Fehler nicht so richtig erwünscht,
weil jetzt da haben alle schon gelernt,
wenn man jetzt sagt, okay, das war ein Fehler, wir machen es jetzt anders,
dann ist das politisch keine gute Idee,
weil Fehler wohl offenbar doch keine so gute Idee sind.
Und wenn man jetzt Leute,
also man könnte zum Beispiel
Leute fragen, was waren eigentlich die
letzte fiese Architekturfehlentscheidung,
die so passiert ist?
Und wenn Leute sagen, es ist nie passiert,
oder Projekt, das ist eine Sackgasse,
wenn Leute sagen, sowas passiert nicht, nie,
dann ist das zu wenig, weil das ist nicht optimal.
Also optimal wäre durchaus, ab und zu
sich zu irren und irgendwie
mal in eine Sackgasse zu laufen
und dann halt wieder umzudrehen.
Also, ja,
Das kommt vielleicht auch
alles so ein bisschen aus dieser Welt
die der Tony vorhin schon angesprochen hat
dass
ganz viel noch Waterfall gematcht wird
und das geht halt nicht
Es ist in den Kopf und in die drin
Übrigens
dieses Waterfall Modell
das ist definiert worden von Royce Winston
ist schon ganz lange her
ich würde euch
die Jahreszahl sagen, aber ich finde sie gerade nicht
und war eigentlich als
negativ Beispiel gedacht. Es war eigentlich gedacht als
Beispiel von, so geht Softwaremanagement
nicht, so kann man Projekte nicht managen.
Nur leider hat nie jemand...
Dann machen wir das jetzt so.
Es hat nie jemand über die erste Seite hinaus gelesen
und nur dieses erste Diagramm ist das, was man
immer sieht. Und auch in diesem
ersten Paper steht schon drin, als eine
von den Sachen, involve the customer,
also sprich mit den Leuten, die das dann benutzen
sollen und benutzen müssen, weil nur die
wissen, was da
Anforderungen tatsächlich drin ist.
Nur die wissen, was die tatsächlich brauchen.
und hat dann ein paar SQL-Queries geschickt für Sachen, wo er gerne noch Auswertungen für hätte.
Und das lief immer nicht sauber.
Da hat immer irgendwas in der Syntax gehakelt, etc., etc., etc.
Irgendwann kam er an und sagt, die Änderung vom letzten Mal habe ich hier rot markiert.
Und dann ist der Groschen gefallen, der hat die nie ausgeführt.
Der hat nur bei sich am Rechner gesessen und in seinem Word SQL-Queries runtergeschrieben,
die er mir dann geschickt hat.
nur damit ich dann feststelle,
ja das geht ja vorne und hinten nicht.
Und als er dann meinte rot markiert, hat er tatsächlich
dann halt angefangen, das Word-Change-Tracking
zu nutzen
um mir, also im Prinzip
war ich, ich war sein
Word-E-Mail-basierter
Postgres-Interpreter,
der dann immer zurück mit den
Fehlermeldungen von der Postgres-Stell kam.
Das war halt so eine
völlig, bis man das auch merkt, dass dieses
Customer Onset da völlig daneben gelaufen.
Es hat gedauert.
Man darf auch auf die Kunden
nicht zu viel hören. Das ist auch so
ein Problem, was man heutzutage
manchmal hat, weil
die Kunden oder die Benutzer
oft ganz verrückte Vorstellungen haben.
Wie du genau
vorstellst, die Kunden
wissen nicht, was man bauen kann.
Und das heißt, entweder sagen sie,
ja, es wäre schon gut, wenn man hier
Text eingeben könnte.
Ja, das konnte man 1970 schon.
und welche Person da auf dem Bild ist
und du denkst dir, ja gut, Google kann das,
aber wir können das ja nicht.
Welcher ist denn der Mensch, der das so entscheidet?
Ist das der UX-Mensch, der das kann?
Diese Sprache sprechen mit, wer der Kunde ist
und was der eigentlich will.
Es muss auf jeden Fall so eine Rolle geben,
der diese Sprachen spricht
und das ist ein Zeichen von erfolgreichem
Projektmanagement
und erfolgreicher Softwareentwicklung,
und dann denkt er sich halt aus, dass die Leute
es nicht wissen müssen, was sie müssen.
Und dann kriegst du so Projekte,
die irgendwo hinlaufen, die irgendwas
herstellen, was dann keiner haben möchte.
Und tatsächlich, also diese
Art von Übersetzung ist,
ich würde nochmal andocken wollen, weil
mir fällt tatsächlich auf, das habe ich gar nicht gedacht,
eine Vorbereitung, dass mir jetzt die
ganzen Komplexitätsbasierten
Ansätze da alle reinlaufen.
Das ist halt
es ist halt, wobei es auch ein
steckenpferden ist dokumental halt überall an.
Das eine ist das Thema
Fehlerkultur, da bin ich dort auch
nochmal auf den Trichter gekommen.
Es wird dort
auch bezeichnet, dass wenn du in einer komplexen Welt bist,
wo du halt die Interaktion nicht vorhersehen kannst, musst
du parallele Experimente
machen. Das Spannende ist tatsächlich
zeitlich parallel. Ist das so AB-Testing
oder was kann man das so kurz sagen?
Ne, ja, noch nicht
mal. Du willst
ja nicht nur zwei machen, sondern du willst im Prinzip
was du machen möchtest, ist du willst
und Jochen unterhalten sich über die Programmiersprache Python
Es gibt eine gewisse Menge Widerspruch zwischen den unterschiedlichen Ansätzen.
Wenn du anfängst sie zu implementieren, nicht alle tatsächlich valid sein können,
dann hättest du nämlich nichts gelernt.
Und du willst auch machen, dass du bestimmte Ansätze nochmal um die Ecke denkst.
Da ist es immer hilfreich, wenn man im Team nochmal irgendwie naive Leute hat,
also Leute, die noch nicht so lange dabei sind oder Quereinsteiger sind und so.
Und da kommt dann nämlich dieses Thema, diese Experimente,
und die
und Jochen unterhalten sich über die Programmiersprache Python
und Jochen unterhalten sich die Programmiersprache Python Wir wissen noch nicht was die Antwort ist Und eine von den vier Sachen wird schief gehen Wir wissen auch noch nicht welche Aber irgendwas wird schief gehen Und wir bereiten uns auch jetzt darauf vor von was machen wir denn wenn das schief geht Und das war f mich eine massive Erkenntnis zum Thema ja diese halbherzige Fehlerkultur ist kaputt weil man denkt Fehler sind immer noch etwas was man im Idealfall vermeiden kann Und es muss hingehen zu Fehler sind etwas was ich provoziere weil ich erst dann den Optionsrahmen so weit ausgesch habe dass ich echte Innovation treiben kann dass ich eine echte Erkenntnis hatte
Ich muss vielleicht nochmal kurz dazu gehen, wie provoziert man denn so einen Fehler und worum geht es dabei?
Ja, indem du Theorien aufstellst, die sich widersprechen.
Du sagst halt, du hast eine bestimmte Aufgabe und du weißt noch nicht, was die möglichen Ergebnisse sind.
Beispiel, bildlich gesprochen, du bist irgendwo mitten in einer Wüste und deine Aufgabe ist rauszufinden,
in welche Richtung geht es jetzt hier eigentlich ordentlich voran.
Ja, wo müssen wir hin?
Zum Wasser oder zum Meer oder?
zum Wasser oder zum Meer oder was auch immer.
Dann schickst du also vier Leute
oder du versuchst rauszukriegen, wie weit geht's
denn hier eigentlich. Und dann schickst du
halt vier Leute in
vier Himmelsrichtungen
und jetzt kannst du entweder sagen, naja,
ich lass die alle jeweils einen Kilometer
laufen
und dann zurückkommen, dann können sie
dir sagen, ja, hier geht's jeweils in ein Kilometer
Richtung. Schön. Jetzt hast du aber noch
nicht gelernt, wo hier Ende ist.
Das heißt, du musst im Prinzip an der Stelle
einer von den vier Richtungen irgendwo in Oase ist, aber es kann nicht überall eine sein.
Und damit müssen sich die, die sich auf diese Expedition begeben,
darauf vorbereiten, dass sie derjenige sind, der keine Oase findet.
Na, die verdursten.
Was mache ich denn dann?
Ja, idealerweise tun sie das halt nicht.
Idealerweise überlegst du dir ein Protokoll, wie die das halt...
Und deswegen ist sozusagen diese Aussage, ja, ich fange an Dinge zu tun, wo ich...
Du weißt bloß nicht, welcher von denen halt der ist, der nachher das Problem haben wird.
und den musste ausrüsten mit Mechanismen
zu sagen, okay, ich bin jetzt wirklich so weit gefahren,
wie ich konnte, jetzt brauche ich hier
Verstärkung, irgendwann muss ich mich abholen.
Und das ist halt genau dieses Abstrakter
gesehen ist halt, du machst hier ein Portfolio,
jede Theorie in sich muss schlüssig
sein, die muss sein, die darf
der Naturwissenschaftlichen
nicht widersprechen, du musst
einen Anhaltspunkt haben, wo du sagst,
irgendwo hat sowas in der Art schon mal funktioniert, es ist nicht völlig
an den Haaren herbeigezogen,
auch wenn wir sozusagen jetzt auf
dieser Idee so lange rumhauen und so viele
versuchen, sie niederzumachen, irgendwie scheint es trotzdem noch irgendwie eine gute Idee zu sein,
dann sollten wir das jetzt mal ausprobieren.
Und so kommst du halt zu einem Portfolio,
wo du mit relativ wenig Aufwand
einen zeitlich kurzen
Zyklus tatsächlich provozieren kannst,
dass dir Feedback von
dem Universum gegeben wird, was davon
jetzt eine gute Idee ist und was nicht.
Das ist die
Pale-Fast-Philosophie, oder?
Das ist so, dass sie schnell zu
einer Stelle kommen, wo es nicht weiter geht.
Genau, und aber wichtig an der Stelle
auch parallel, weil deine Umwelt ändert sich, während du das machst.
Die Oase wandert,
Vater Morgana.
Ja, genau.
Ja, ja, ja, total.
Die,
ist mir gerade auch
irgendwie der Faden abhanden gekommen an der Stelle.
Entschuldigung.
Und du verschiebst auch
die Diskussion weg von
welches ist die richtige Lösung
hin zu
welche
Welche interessanten möglichen Lösungen können wir jetzt hier alle generieren, ohne uns dann zu streiten, wer hier recht hat, sondern es geht nur dazu, können wir möglichst viele interessante, ausprobierbare Lösungen generieren.
Eventuell ist nachher die tatsächliche Lösung, die man nimmt, weil dann gibt es eine Technik, die man dann noch ansetzen kann, wenn du dann das durch hast, dann kontrastierst du, was du aus diesen unterschiedlichen Lösungen gelernt hast und kannst mit den realen, praktischen Erfahrungen dann eine neue Lösung tatsächlich generieren.
und da muss es nämlich nicht sein, welche von den vier Lösungen war jetzt eigentlich die richtige.
Beispiel, um bei der Wüste zu bleiben, keiner von denen ist zur Oase gekommen,
aber der Typ, der nach Norden gelaufen ist und der Typ, der nach Osten gelaufen ist,
hat gesagt, als ich fünf Kilometer nach Osten gelaufen bin, habe ich im Norden was gesehen.
Und der andere sagt, als ich fünf Kilometer in den Norden gelaufen bin, habe ich im Osten was gesehen.
Das kannst du jetzt übereinanderlegen und weißt, aha, in der Distanz nordöstlich ist was,
Keine der konkreten Lösungen war richtig, aber aus beiden Erkenntnissen konnte ich mir die richtige Lösung nachher generieren. Und wenn man sich aber die ganze Zeit nur darauf versteift hätte zu fragen, ist es jetzt richtig nach Norden, Süden, Osten oder Westen zu gehen, hättest du nie den Input gehabt, um dieses Ding im Nordosten zu finden.
Kann ich nochmal kurz eine blöde Frage stellen und zwar möchte ich gerne verstehen, an welchen Projekten man diese Methode am besten macht? Also hast du ein unbekanntes Problem oder was möchtest du lösen?
bei dem... Du hast ein Problem, dass du
nicht a priori, also du bist in einer
Situation, die so ungeordnet ist, dass du
nicht a priori die Lösung festlegen kannst.
A priori ist etwas,
da neigen wir deutschen Ingenieure
sehr dazu, ich kriege
ein Problem, ich kenne meine Handlungsweisen,
ich laufe meinen Optionsraum ab
und ich präsentiere dir nach einer Woche irgendwie die
Lösung. Wenn das nicht der
Fall ist, im Komplexen passiert dann typischerweise
folgendes, dann kommt der nach einer Woche mit einer
Lösung um die Ecke, du implementierst die,
und die Reaktion des Ingenieurs war, ja, du hast mir zu engen Zeitrahmen gegeben,
hättest mich noch eine Woche arbeiten lassen sollen.
Oder du hast mir nicht alles gesagt.
Nicht gut spezifiziert, genau, ja, ja.
Aber, aus der komplexen Perspektive wird immer wieder ein komplexes Problem retrospektiv als geordnet mit,
ja, ich habe ja nur X vergessen.
das Dumme ist nur, du kannst dieses X nie a priori bestimmen
wenn du hättest ihm noch eine Woche mehr gegeben
hätte es ein Y gegeben, hätte es ihm noch eine Woche gegeben
hätte es ein Z gegeben
und das muss man halt umdrehen
weil im Nachhinein kann man es immer erklären
nur im Nachhinein, also auf lange Sicht sind wir alle tot
und so
was du dort halt tatsächlich machen kannst
ist, du kannst, wenn du normalerweise
in einem ingenieursmäßigen Ansatz arbeitest
sagen, okay, wir probieren das Problem
klassisch über
einen Expertenansatz
innerhalb einer gesetzten Timebox zu lösen und wenn das nicht geht,
dann müssen wir diesen Modus wechseln.
Also so kann man ein Team, was tatsächlich gewöhnt ist, zu sagen,
ja, da setze ich hier einmal hin, arbeite das Ticket ab und komme dann mit der Lösung raus.
Und wenn du dann diesen Effekt siehst von, ja, toll, alles ausdefiniert,
alles abgearbeitet, super Codequalität, aber es tut nicht,
dann solltest du die Frage stellen, gut, dann sollten wir jetzt hier mal
vielleicht zwei, drei Varianten in die Breite ausprobieren und gucken, wo wir weiterkommen.
Das ist ein möglicher Ansatz, wie man das machen kann.
kann. Also Engineering sollte
sich immer einer Timebox eignen,
weil er sucht ja im Prinzip nur
aus bekannten Lösungen aus. Und wenn
das Engineering aber anfängt, neue Lösungen
zu entwickeln, dann musst du im Prinzip in diese andere
in diesen anderen Modus wechseln.
Das ist das, was man Unknown Unknowns
manchmal nennt, oder?
Die Dinge, die wir nicht wissen.
Nee, das sind die Known Unknowns tatsächlich.
Wir wissen jetzt schon,
da ist etwas, was wir noch nicht kennen.
Ja, okay, wenn du die erste Timebox gemacht hast,
dann weißt du, dass es nicht geht, aber vorher weißt du es nicht
ja
die
und man kann viel machen, um es abzusichern
das sind die solchen Kohärenztests
sind meine Lösungen irgendwie in sich schlüssig
widersprechen sie dem
heliozentrischen Weltbild
solche Sachen
was ich noch spannend finde
ist ein Ansatz, der auch
so aus den 90ern fehlverstanden wurde
wo du gerade das Wasserfallmodell meintest
ist Rapid Application Development
das war so Ende der 90er, das waren so Pascal basierte Tools wie Delphi und solche Formbilder etc.
und Dave hatte mit denen tatsächlich was zu tun, der hat eine ganz interessante Story
was eigentlich mit Rapid Application Development gemeint war
weil was raus geworden ist, ist auch wieder dieses
ja ich kann ganz schnell diese Formulare zusammen klicken und habe dann eine fertige Anwendung
worum es eigentlich ging, war eine Methodik dahinter
und die ist aber aufgrund dieser sehr starken Technikfokussiertheit von
ja ich habe diese Formbilder weggefallen
und das war folgendes, das nennt sich ein Triple Eight
die haben bei der IBM
für Kundenprojekte
folgendes gemacht, die haben
vom Kunden vier Leute sich geholt
die die Aufgaben
die die Problemstellung kennen
Abrechnungssoftware irgendwie überarbeiten
haben vom Kunden
die vier Leute an vier verschiedene Teams
bei der IBM rangesetzt, jeweils mit so
fünf, sechs Leuten
Montag früh
und haben mit denen gesagt, welche Features brauchen wir jetzt als allererstes und haben die halt entwickelt.
In so einem Rapid Application Ding.
Da hast du dann nach einem Arbeitstag so die ersten, so, ja, heißt für mal eine Tabelle und hast mal ein Formular
und hast mal dies und hast mal jenes, das geht relativ zügig.
Dann haben sie diesen Code, und das ist in vier Teams parallel passiert.
Jedes hat für sich gearbeitet und durfte nicht miteinander reden.
Dann haben die ihren Code eingecheckt und aus Europa nach 8 Stunden an ein Team in den USA gegeben
Und dieses Team in den USA hatte keinerlei Zugriff auf irgendwelche Formen von Spezifikationen, Kunden oder irgendwas
Und hat nur die Aufgabe gekriegt von so, hier ist irgendwie Code, mach mal weiter
Dann haben die sich das angeguckt mit, ah ja okay, alles klar, die machen hier so Abrechnungskram
und die haben das wiederum nach 8 Stunden abgegeben und jeweils an ein Team in Asien gepackt.
Dann hat sich das Team in Asien das Ding angeguckt, wo jetzt sozusagen die Europäer mit dem Kunden,
danach der Ami ohne Kunde und dann der Asiate auch nochmal ohne Kunde wieder drauf geguckt hat von
was wollten die ja eigentlich, was ist denn das, hä, okay, das machen wir gar nicht,
und Jochen unterhalten sich über die Programmiersprache Python
Z. Und das haben die zwei Wochen am Stück gespielt. Dann hast du dieses Projekt in vier
Ausprägungen über 10 mal 3, über 30 Iterationen geprügelt und kontrastierst dann, was ist
eigentlich in diesen vier Handlungssträngen rausgekommen, weil die ja auch noch nicht mal
miteinander geredet haben über die Zeit. Und dann setzt du dich hin und fragst du, was
haben wir jetzt eigentlich gelernt? Und jetzt kannst du dich hinsetzen und kannst sagen,
so, okay, jetzt suchen wir uns heraus, was wollen wir hier eigentlich?
Und das war der ganze
Charme von einem Rapid Application Development
Ansatz, so einen hochgetakteten
Zyklus zu fahren von, wie kriege
ich eigentlich Erkenntnisgewinn?
Also die Innovationsgeschwindigkeit ist hoch, oder?
Diese Innovationsgeschwindigkeit ist brutal.
Das hört sich so ein bisschen an wie
das Startup-Modell auf 11
aufgedreht. Wir machen jetzt vier Sachen gleichzeitig
und jeweils sind drei Schichten.
Das war Mitte der 90er,
aber das war nicht gedacht
als ein Modell,
was im Dauerbetrieb funktioniert, sondern das war gedacht als ein Ansatz um, wenn ich
habe wenig Information, viel Unsicherheit und muss irgendwie Entscheidungen treffen
für ein extrem teures strategisches Projekt, dann ist die Aussage, dann machen wir das
jetzt mal zwei Wochen und danach hast du mal so richtig Datenbasis.
Und dafür war Rapid Application Development halt wichtig, da ging es nicht darum, ein
finales Produkt in der Hand zu haben, was hochpoliert etc., sondern es war darum, in
so einer Materialschlacht
in einer Personalschlacht
so schnell wie möglich, so viele Varianten
wie möglich zu generieren.
Und das hat mir die Augen geöffnet,
weil ich saß ja auch davor und habe
in der Uni mit diesen Rapid Application
Development Tools so ein Wasserfallmodell
irgendwie versucht übergeholfen zu kriegen.
Und dann hörst du plötzlich von dieser
Story, IBM hat ja diese Sprachen
mitentwickelt. Und das war aber dieses
zweigleisige Ding von, wir wollen hier
diesen Prozess fahren können
und dieser Prozess hat es aber nie geschafft,
irgendwie mal außerhalb
angewendet zu werden und dann
bleibt aber trotzdem über mit, na jetzt haben wir so Tools,
die können wir ja verkaufen.
Tja.
Ja, das ist halt,
wenn man viele Ressourcen hat, kann man da Sachen
erschlagen und man muss die dann
auch nutzen.
Das kann man aber auf den Kleinen machen.
Vielleicht ist jetzt irgendwie ein ganz guter Zeitpunkt,
das nochmal so zusammenzufassen, was hast du gerade
Rapid Application Development irgendwie gesagt?
Es gibt ja noch so mehrere andere Methoden oder
oder Methodologien, die man irgendwie kennt.
Ja, da gibt es ganz viele.
Vielleicht können wir über die eine oder andere nochmal sprechen,
vielleicht nochmal Extreme Programming und oder Scrum
mal kurz erklären für unsere Hörer, was das
eigentlich so ist und wie man das so macht und vielleicht
ein, zwei Probleme damit aufmachen oder
wie ihr das so gerne macht oder
ist das eben auch von Flo
Schad oder was gesprochen, was ist das,
macht ihr einen Kampanenwunder?
Vielleicht kann man da irgendwie
einmal kurz durchgehen.
Sollen wir mit Scrum einfach anfangen?
Ich glaube, wer kann am meisten so zählen?
Jochen hat da glaube ich ganz viele... Ich glaube man muss mit
XP anfangen, oder? XP ist zeitlich früher
und Scrum ist dann das nächste. Ich würde die
alle zusammenfassen zu
das ist halt so Agile, genau.
Oh Jochen, jetzt setzt du dich aber ins
Nestle. Ja, ich glaube da so
groß sind da die Unterschiede gar nicht.
Also der Spirit ist irgendwie... Oh, jetzt setzt dich immer
weiter in die Nestle, da werden da ganz viele Leute
Also für freundliche
Zuhörer-Rants bitte
Jochen, Python-Podcast-Punkt.
Er nimmt die Hate-Mail sehr gerne
Wir lassen sie dann von Sarah Bosetti filtern und lesen die Headmail aufgeschüttet.
Hallo, es heißt podcast.de
Also Jochen, dann fass doch mal zu sagen, was agile Methoden sind.
Ja, ich würde sagen, das Agile Manifesto ist ja schon ein guter Startpunkt.
Das kriege ich jetzt auch nicht so aus dem Kopf rezitiert, aber die wichtigsten Punkte sind halt sowas wie,
und
genau
ja
ähm
weiß jetzt nicht
Ich meine, ich kann es kurz vorlesen, ich habe es gerade da.
Das Original sagt also,
we are uncovering better, deswegen, da fange ich auch immer wieder an,
die meisten überspringen das,
we are uncovering better ways of developing software
by doing it and helping others do it.
Through this work we have come to value
individuals and interactions
over processes and tools,
working software over comprehensive documentation,
customer collaboration over contract negotiation,
Responding to Change over Following a Plan.
That is, while there is
value in the items on the right,
we value the items on the left more.
Das ist eigentlich ein sehr versöhnliches Manifest.
Es ist ein Unglaub, und es ist
so aktuell eigentlich, wenn ich es halt
neben diese
industrialisierten Varianten von
Agilität halte. Ich habe es
wirklich lange Zeit nicht angeguckt.
Ich habe es bestimmt zehn Jahre nicht in der Hand und im letzten halben Jahr
immer mal wieder rausgeholt. Es ist
aktueller denn je.
Das stimmt, da habe ich tatsächlich eine kleine Anekdote dazu
Ich habe mal, als ich mein Studium fertig hatte, wollte ich gerne noch ein bisschen an der Universität bleiben
Deshalb habe ich eine Doktorarbeit angefangen
Und die Doktorarbeit beschäftigte sich so im Großen mit Projektportfolio-Management
Das ist quasi eine Ebene drüber, das ist nicht Management eines einzelnen Projektes, sondern Management vieler Projekte
Also welche Projekte mache ich überhaupt, welche sind wichtig, wie priorisiere ich die, in welche Reihenfolge sind die und so weiter
und ich habe relativ lang Literaturrecherche
gemacht und habe
dann diese Doktorarbeit wieder abgebrochen,
als ich ein Paper
gefunden hatte mit dem Titel
Are we getting any better? Comparing
Project Management in the years 2000 and 2008.
Super Paper,
rate ich jedem zu lesen.
Die kurze Form
ist
Nope.
Sie haben viele Projekte untersucht,
im Jahr 2000 und im Jahr 2008
und wenn man die Leute in den Projekten befragt, dann sagen die, ja, das ist jetzt alles viel besser.
Wenn man aber die Ergebnisse der Projekte anguckt, dann hat sich eigentlich nicht viel getan.
Und wir haben die Zufriedenheit erhöht.
Genau, wir haben die Zufriedenheit erhöht. Das ist ja auch schön,
aber es ist nicht das, was man eigentlich erreichen wollte.
Und das war für mich so ein bisschen der Punkt, wo ich mir gesagt habe,
okay, viele Sachen, die man hört im Projektmanagement und viele von diesen Methodologien,
die sind sehr dogmatisch
und die sind sehr, ihr müsst es so machen
und ihr müsst es so machen und da gehören Scrum und XP
absolut dazu, die haben sehr sehr strikte
Regeln, also es gibt quasi niemanden der ein echtes
Scrum macht, es gibt niemanden der
echtes XP macht
weil die einfach so super strikt
sind, dass man die pragmatisch nicht befolgen kann
Ja also tatsächlich
sie widersprechen
dem Manifesto auch im Prinzip dadurch
Ja natürlich, total
Oft wenn man sagen würde
das ist ja nicht so gemeint, dass man das jetzt einfach nur
als Regelwerk nehmen nehmen nehmen nehmen nehmen nehmen nehmen nehmen nehmen nehmen nehmen nehmen nehmen
der Weg hin zu weniger Projektmanagement ist mehr Projektmanagement, was ja durchaus dem Agile Manifesto auch entspricht
und das ist der Punkt, worauf ich raus will
das Agile Manifesto ist deshalb immer noch relevant
weil wir
Probleme lösen, die
weil wir versuchen Probleme zu lösen
die wir aber nicht lösen
wir machen immer mehr Projektmanagement, in Firmen ist
Projektmanagement so
ungeheuer wichtig, dass
man dem nicht entkommen kann
im Endeffekt löst es aber die Probleme.
Aber das ist doch wieder spannend.
Wir haben jetzt immer noch nichts über die Methoden gesagt, aber das hört sich
so an, als wäre Projektmanagement,
gutes Projektmanagement quasi so, du musst
dafür sorgen, dass sich die Menschen, die für dich
arbeiten, gut fühlen und wohl fühlen,
dann wird das schon irgendwie.
Nee, überhaupt nicht. Das ist das, was die Methoden
machen.
Gutes Projektmanagement sorgt dafür, dass die Projekte
erfolgreich sind, egal wie die
Menschen gehen.
Aber Projekte werden halt von Menschen.
Da würde ich auch...
Ich möchte nicht missverstanden werden
Die Menschen machen ja die Projekte
Das heißt, du kannst nicht dafür sorgen, dass Projekte
erfolgreich werden, zumindest nicht auf lange Sicht
wenn du die Menschen dabei kaputt machst
The gaming industry would like to differ
Ja, wobei die ja auch
Ja, auch die machen so langsam auf
Auch die
haben schon ihre herben Rückschläge gehabt
Genau, da würde ich
gerne einhaken, weil
das halt auch so ein
Ja, so ein fundamentales Problem ist irgendwie so, je älter ich werde, so am Anfang, ich war auch sehr, ich war da, ich habe tatsächlich mal irgendwie diese Agile-Geschichte halt im Unternehmen, also mit sehr dafür gearbeitet, dass das da umgesetzt wird.
Ich dachte, ja, das machen, wir folgen jetzt die Regeln einfach nur alle auf 100 Prozent wie in XP, das ist alles.
Ja, wird es schon gehen.
Und dann in ein paar Monaten funktioniert das ja alles, das hat dann irgendwie ein paar Jahre gedauert und das war ein eher schmerzhafter Prozess.
und
es hat schon irgendwie funktioniert,
aber es war alles nicht so rosig
und irgendwie je älter ich werde, desto mehr
habe ich so das Gefühl, es ist nicht so
beim Management von diesen Dingen
nicht so sehr
die Frage, wie man das macht,
sondern die Frage, wer das macht, ist auch sehr, sehr
wichtig.
Ja klar und das ist auch so ein bisschen das,
was da rauskommt. Du kannst dir ganz viele Regeln
ausdenken, aber die funktionieren nicht, weil das halt
Menschen sind, die die Projekte machen.
und du musst dafür sorgen, dass die Menschen,
die die Projekte machen, die Projekte
erfolgreich machen. Und das heißt,
da ist immer diese menschliche Komponente
dabei. Du musst die richtigen Menschen finden, du musst die
Menschen richtig dazu bringen, die
Sachen zu machen und dann am Ende, wenn du das geschafft hast,
musst du auch noch dafür sorgen, dass du die richtigen Projekte
machst.
Ja, es ist nicht ganz einfach und ich bin
auch zunehmend pessimistisch,
was die
Möglichkeit angeht,
das Verhalten von Leuten so großartig
zu verändern. Ich meine, auch wenn man
jetzt irgendwie sich zum Beispiel Kinder anguckt.
Und also ich meine, so als Eltern
ist man ja wahrscheinlich so in der
privilegierten Position,
ja, sozusagen man
hat die
maximale Möglichkeit,
Dinge zu beeinflussen eigentlich. Also besser wird's nicht.
Also ich glaube, Manager haben wesentlich weniger
Zeit, Energie und
was sie da reinstecken können, um halt
das Verhalten zu modifizieren. Und selbst bei Kindern,
naja, ich bin mir nicht immer so sicher,
ob das gut funktioniert.
Ein bisschen kann man schon ändern, aber
so grundsätzlich.
Ja, und ich fürchte,
wenn man jetzt als Manager die Vorstellung hat,
man ändert irgendwie das Verhalten von Leuten grundsätzlich
oder macht Leute zu anderen Personen oder
das funktioniert einfach nicht.
Ja, das glaube ich auch nicht.
Deshalb sage ich ja, du hast diese menschliche
Komponente dabei, du musst dafür sorgen, dass die
Menschen, die du im Projekt hast, die
richtigen sind und dass die die Sachen so machen,
dass sie sehr erfolgreich sind.
Und das wird immer unterschiedlich sein.
Es wird immer unterschiedlich sein, je nachdem,
welche Projektteilnehmer du hast.
Es wird keinen Hamburger Prozess geben, wo hinterher immer der gleiche Hamburger rauskommt
und selbst wenn du so einen Prozess findest, dann wird es halt immer der gleiche schlechte Hamburger sein
und jetzt bin ich rausgefallen
Ich bin nicht rausgefallen
Ich müsste mich kurz
müten, weil hier mein Drucker angefangen hat
Ich würde aber mal reingehen, weil da kann ich
tatsächlich noch eine völlig andere Ecke mit reinwerfen, das sind die
Manager Tools,
weil da gehen wir jetzt weg von
Projektmanagement über zu
Management allgemein.
Was wir relativ
viel benutzen ist tatsächlich
einen Ansatz
von
ja, die heißen managertools.com
die haben irgendwie
anderthalb tausend Podcasts
veröffentlicht.
Ja, einmal diesen sehr
straightforward Punkt.
Es sind so zwei irgendwie Ex-Militärs
und die haben aber tatsächlich dieses Thema
wo Jochen und ich eben so ein bisschen kurz aufschreien wollten
zum Thema ja Hauptsache die Projekte sind erfolgreich
die haben sich halt diese klassische Management-Theorie
relativ gut weiterentwickelt
mit der Aufschrift von
die zwei Aufgaben des Managers sind
Results and Retention
Und welches ist wichtiger?
Ich versuche gerade rauszukriegen, was der Dominik mir sagen will.
Du hast dein Mikrofon gerade von deinem Mund entfernt und seitdem bist du leiser als vorher.
Entschuldigung, alles klar, danke.
Was ist wichtiger, Results oder Retention?
Ne, es kommt her aus der Industrialisierung, da war die Managementaufgabe tatsächlich Results.
Stimmt ihr dazu?
Genau, und das alleine reicht halt eben nicht, weil das halt keine langfristige Perspektive hat.
und aber auch die Management-Theorie aus Mitte des 20. und frühen 20. Jahrhunderts weiß schon, dass eine Organisation halt auch ihr langfristiges Wohl im Auge behalten muss.
Das heißt, du musst die Fehler, die du durch eine reine Result-Orientierung erzeugen würdest, durch eine entsprechende Retention der Personen, die du halt hast, balancieren.
und das ist dann eben genau die Aufgabe eines Managers,
das gut in den Einklang zu bringen,
zu gucken, dass dein Team
funktioniert und zwar auch
für die Menschen funktioniert,
weil ohne die Menschen geht es halt nicht,
aber eben mit den Menschen zusammen entsprechende
Ergebnisse zu erzielen.
Kannst du vielleicht nochmal ganz kurz definieren,
was Retention ist?
Retention heißt, die Leute, die für dich
arbeiten, bleiben dir erhalten.
Wenn du nur Results erzeugst,
dann verschleißen die Leute, dann gehen sie entweder
oder werden krank oder was auch immer.
Das ist so Industrialisierung
Wenn die Masse an Arbeitern unendlich ist
an Arbeiterinnen, dann hast du
Wenn du genügend Nachschub hast
an Jugendlichen, die Burger machen
oder an jungen Männern, die Computerspiele machen wollen
dann kannst du das machen
Selbst bei den Burgern
ist es so, wenn du ein eingespieltes Team hast
bist du effizienter
und kannst mehr erwirtschaften, als wenn du ein Team hast
das ständig wackelt
und wo alle gegen dich arbeiten
im Prinzip, weil sie halt irgendwie ihres Jobs nicht
sicher sind etc. Und
diese Balancierung halt bewusst wahrzunehmen
als Aufgabe, das hat
uns nochmal ganz schön geholfen, die bauen da relativ viel
Zeug dann
drumrum und haben auch viel Guidance für Leute, die
sich jetzt so für Management allgemein interessieren.
Wichtig ist auch, das ist halt keine
irgendwie mal schön sich
ausgedachte Theorie, sondern es ist
halt relativ offensichtlich, weil wenn Mitarbeiter
wieder verloren gehen, geht halt
Organisationswissen verloren.
Da gibt es auch ganz alte
und Jochen unterhalten sich über die Programmiersprache Python
Leute neu reinzukriegen und Wissen neu in die Organisation reinzuholen, ist so unendlich teuer und fragil, dass halt Leute aus einer Organisation loszuwerden oder zu verlieren, ist halt einfach mal, das ist prohibitiv, das geht nicht. Du musst dich halt darauf einstellen, das ordentlich zu machen.
Tja, naja.
Ja, ich würde
auch sagen, ich weiß nicht genau, also ich kann
das verstehen, dass man sozusagen dann so Turnover
versus
Ergebnis irgendwie
vielleicht gegeneinander, aber ich weiß
gar nicht, ob das so eine richtige Dichotomie,
gibt es dafür eigentlich einen deutschen Ausdruck für Vollst Dichotomie?
Keine Ahnung,
fällt mir jetzt keiner ein, ehrlich gesagt,
weil im Grunde
setzt man da ja voraus,
dass die einzige Möglichkeit, das
Ergebnis zu verbessern,
daran besteht, halt irgendwie
pro bezahlter Stunde
mehr Produktivität aus den Leuten zu
pressen.
Ja, nee, eben nicht. Es geht eben darum, eben nicht eine Dichtung
Mietraus zu machen, sondern
es als komplementäre Aufgabe anzusehen.
Ja, genau, weil
ich denken würde, man kann nämlich auch genau das
andere machen. Man kann halt versuchen, einfach,
dass die Leute pro Stunde produktiver werden,
das Ziel zu verfolgen. Und das ist
halt eben nicht damit verbunden,
dass die Leute langfristig
irgendwie, weiß ich nicht, irgendwie
in den Wörtern ausgehen oder verschwinden oder keine Lust mehr haben.
Du musst es nur in der Management-Theorie als explizites Ziel des Managers machen,
weil alles, was du zum Ziel aufrufst, und das ist bei Menschen nun mal so,
und deswegen ist auch, da macht man fast eine Schleife zum Anfang zurück,
zum Thema Zielorientierung.
Wenn du einem Menschen ein Ziel gibst, dann wird er das gnadenlos verfolgen.
Gnadenlos.
Wenn du dem Manager sagst, dein Ziel ist Results, Results, Results und du gibst ihm noch was, was gemessen werden kann, dann wird er den Teufel tun und das Ding optimieren. So schlimm, dass im schlimmsten Fall sogar der Messwert dich anlügt, aber er hat sein Ziel erreicht.
Ja, du kannst mal ein paar Stellen wegrationalisieren im Krankenhaus, dann hast du als Manager einen tollen Bonus, weil du hast was gespart.
und dabei geht es
tatsächlich darum, du musst in der Organisation
das Bewusstsein schaffen und auch bei den Leuten,
die das tun, dass sie an beidem gemessen werden.
Dass sie sowohl daran gemessen werden,
kontinuierlich
Ziele zu erreichen und
aber ein sozusagen
inhärent verankertes Ziel, also das
Metaziel ist die Zielerreichung
und das zweite
Metaziel daran ist aber halt währenddessen
die Organisation nicht kaputt zu machen.
Wie macht man denn diese Verantwortung? Wie schafft man
das? Das ist ja spannend.
Indem du auf die Menschen
eingehst, die da drin sind
Das kommt immer wieder runter auf die Menschen
Das ist für mich das
einzige Ergebnis, was ich aus dieser ganzen Zeit
sehen kann, das kommt immer auf die Menschen an
Aus einer Firmenperspektive nochmal sehen möchte
Wie schaffe ich es denn, dass ein Projektmanager
die Verantwortung gegenüber den Menschen
wahrnimmt? Also ich muss den ja irgendwie
Accountable, Responsible halten dafür, was da passiert
Also messe ich die
Retention Rate oder
Ja, die kannst du ja einfach messen
eine Mitarbeiterbefragung über glückliche
Zufriedenheit, keine Ahnung.
Das kannst du machen. Also die
gehen halt eher von einem prozessualen Ansatz aus
und du solltest
halt das Ziel, also das Problem ist sozusagen,
wenn du ein
Messwert zum Ziel machst, wird er halt
gamifiziert. Das heißt,
da musst du immer aufpassen, dass die
Feedback-Schleife nicht direkt
ist weil dann wird sie halt immer ausgenutzt werden Bei den Manager ist es so wir haben uns das halt auch angew wir haben in der Mitarbeiterf an der Stelle f einen Manager der hat drei Werkzeuge
die ihm dafür zur Verfügung stehen und die er zu nutzen hat. Das eine ist
Beziehungspflege über sogenannte One-on-Ones, das heißt jeder Mitarbeiter von uns hat
das Recht und der Manager hat die Pflicht, mit jedem Mitarbeiter einmal
die Woche ein 30-minütiges One-on-One zu führen. Da gibt es auch eine
entsprechend inhaltliche Struktur, dass der Mitarbeiter auf jeden Fall einmal die Woche zehn Minuten die
ungefilterte, ungeteilte
Aufmerksamkeit seines
führenden Managers hat, der wiederum sich gefälligst vorbereitet und Themen, die
arbeitstechnisch, die
organisationstechnisch, die vertraglich, die von der persönlichen Weiterentwicklung abhängen, mit ihm zu besprechen, zu dokumentieren.
Das ist ganz spannend, weil daraus bei uns nämlich auch
und wir haben tatsächlich dann so 75% davon schaffen war.
Mein Drucker springt schon wieder an.
Den müssen wir irgendwie rausfiltern.
Und das Spannende ist, aus dieser Struktur heraus ergibt sich dann zum einen,
ich bin immer verwundert, wenn ich mit anderen Leuten rede,
wenn die fragen, wie oft hast du exklusiv mal Zeit mit deinem Chef über irgendwas zu reden,
dann ist das häufig relativ wenig.
Und wenn ich ihnen sage, das machen wir irgendwie jede Woche,
dann fallen irgendwie alle aus allen Wolken.
Deswegen würde mich auch mal interessieren, wie das bei euch so ist
Das ist sehr ungewöhnlich, glaube ich
Also sieht man nicht so häufig
Und es ist so ein Riesenwerkzeug, weil zum Beispiel
sowas wie ein Jahresgespräch
ist bei uns kein Jahresgespräch, sondern
wird getriggert durch
Es kommt spätestens nach
zwölf Monaten
wenn es dazwischen kein
Leistungsgespräch gab
Leistungsgespräch ist eine blöde
Übersetzung von dem englischen Begriff
den die haben
oder wann immer sich in der Rolle, in der Tätigkeit des Mitarbeiters etwas strukturell ändert.
Das heißt zum Beispiel nach sechs Monaten, wenn deine Probezeit vorbei ist,
dann ist 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. 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 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, wenn man im U3 identifiziert, an irgendwelchen Sachen hapert es hier ständig.
Du hast entweder Konflikte mit irgendeinem Mitarbeiter oder du kriegst ein bestimmtes Arbeitsthema, geht nicht.
und die
1 ü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, fuck, 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 diese halbe Stunde jede Woche.
Drei O's, One-on-One. Okay.
Und ich habe hier so Stapel von Mitarbeitern, da habe ich jetzt irgendwie seit sechs Jahren jede Woche
und Jochen unterhaltenhaltenhaltenhaltenhaltenhaltenhaltenhaltenhalten
und die Programmiersprache Python
und
die 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 hin, wenn man da draufstempelt.
Genau, und das letzte ist dann halt die Frage, 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, kommt sie klar oder dass man halt fragt, wie sieht es aus, wie sieht das nächste
Quartal bei dir aus, wie war 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.
Spannende Sache.
Das 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 halt 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
die Kunden momentan, keiner meiner Kunden muss sich angesprochen fühlen
aber ich hatte in der Vergangenheit Kunden die die die die
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.
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 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 rumschubsen
mit der rechten Knall
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
ein wichtiger Punkt dabei ist,
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 Sinn, weil
selbst wenn das jetzt irgendwie am Markt scheitert oder so,
wenn ich das Gefühl habe, ich habe da
irgendwas gebaut, irgendeine coole
ja,
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 sparenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenarenPräsen
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 hat in den Features...
Und ein Gigabyte Platz gehabt.
Ja, und ein Gigabyte Platz gehabt.
Das ist natürlich eine Eigenschaft,
und 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, und es geht ja auch darum, auch da würde ich wieder aus Komplexitätsperspektive fühlen,
und Jochen unterhalten sich über die Programmiersprache Python
weg. Das ist auch,
manchmal, wenn ich mich mit
jemandem reibe, der
eher aus dieser Ingenieurstheke 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 zu sagen, ja, jetzt war es richtig und jetzt
gehen wir hier volle Kanne rein. Also deswegen da so ein
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, dann 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?
Also, ja, also
Oberinitiativ kann auch ein Nachteil sein, glaube ich.
Also ich war quasi tätig, ich weiß nicht.
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.
Ja, klar.
Sondern das bedeutet, dass es so sein soll.
Ja, ja.
Ja, definitiv.
Genau. Für mich als Operationsperspektive 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. Das ist für mich ein Qualitätsaspekt.
und die Programmiersprache Python.
und der
von, wie soll das hier alles funktionieren. Und da 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
und der
Das ist dann aber Jagdmier, oder?
Ja, genau.
Das kann man gut als Gegengewicht
machen. Und ich habe mir angewöhnt,
frühestens beim dritten Mal,
wenn ich irgendwie so einen Junk von 5, 6,
7, 8, 10 Zeilen wiederhole,
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. Du fängst noch nichts an zu
abstrahieren.
Ja, das ist 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.
Ja, es ist
Aber das sind
auch das sind ja Entscheidungen, die sich dann nachher
eher auch unflexibel machen
Weil wenn du das dann wieder umbauen willst
musst du plötzlich die Absatzform wieder ausbauen
und das ist auch was, das passiert viel selten
Ja genau
Und deswegen ist
Erweiterbarkeit, Code der nicht existiert
ist am aller erweiterbarsten
Wobei ich sagen muss
Es ist am schnellsten geschrieben
Es ist halt nie so einfach, es gibt auch wieder das
Gegenteil, was mir zum Beispiel
und
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 natürlich auch ins Verderben führen, das stimmt.
Oder halt zur Lösung. Tja, keine Ahnung.
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,
und Jochen unterhalten sich über die Programmiersprache Python
und 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 eine Karte, von wie du dich in der Welt orientierst
dann ist dieser Weg nicht unbedingt sinnvoll
und Jochen unterhalten sich über die Programmiersprache Python
Weg.
Ein großes Abenteuer auf einer Landkarte.
Kompass ist kaputt.
So sind Projekte.
Ja, 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, aber wenn er halt wartet, 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
auch 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
und Jochen unterhalten sich über die Programmiersprache Python
und die Firma ist weg.
Aber dann kannst du es auch so angehen.
Dann kannst du auch sagen, wir setzen uns jetzt hin,
wir programmieren es 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.
Du musst Teil 2 mal machen. Das erste Mal weißt du
noch nicht, wie es geht und beim zweiten Mal weißt du halt, wie es geht.
Deshalb musst du es 2 mal 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 Python-Programmierung.
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 ja die Agile Methoden halt im Prinzip ins Spiel, dass du eben nicht sagst,
ich mache da Second System draus, sondern das ist halt im laufenden Projekt,
diesen Modus wechseln kannst, das Ganze so, weil wir Unitests haben und weil wir dies haben
und weil wir jenes haben und 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.
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 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
herausfindest, 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,
und Jochen unterhalten sich über die Programmiersprache Python
steuern kann.
macht. 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.
vielleicht noch am Schluss machen könnte.
Ich meine, damit das auch irgendwie außer
so ganz luftigen
Gedanken ein bisschen
Content bekommt. Weil was gibt es denn so
für Tools oder so, die man da 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 kann man ein Board fast.
fast, 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
erstmal 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
und Jochen unterhalten sich über die Programmiersprache Python
die sagen dann, okay, jetzt mache 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
FrogBugs benutzt.
Das ist ein System, was
auch einer der Internet-Urgesteine
von Jules Borski 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 muss ich sagen, fuck, wir müssen davon weg,
weil die halt einfach echt,
das bricht alles zusammen.
Ist das nicht an der Platte, die dann verkauft worden ist?
Ne, das war Trello
Trello, ja genau
Aber ist ja eine ähnliche Geschichte
Trello ist auch ein Joel-Tool
genauso wie Stack Overflow halt
und
die
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 ein 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 und 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 sich die Programmiersprache Python
oder ohne Kundenticket 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 kann sie dann
Kanban-Boards ziehen, das war eigentlich alles
sehr fluffig,
wir orientieren uns gerade Richtung Odo,
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
Das ist bestimmt nicht so schwierig, das ist meistens der Weg ins Verderben.
Das kann doch nicht so schwer sein.
Ich mache das noch schnell fertig.
Da gucken wir uns gerade so ein bisschen um.
Ansonsten muss man
mit den Boards, wenn man so über Boards nachdenkt,
muss man immer daran 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
und Jochen unterhalten sich über die Programmiersprache Python
Das Problem ist, Flow-Systeme wie hier Toyota Production System und solche Sachen, die sind halt produktionsorientiert. Mach mir bitte 20 Prios. Und das ist was anderes als, oh erfinde bitte ein neues KI-System, was irgendwie, was ist denn das für ein Ticket?
Ja, ja.
Alright.
und Jira irgendwie sind die Geschichten die ich verwende
da, ja.
Ich finde bei den Tools ist es egal,
wie die geschrieben sind, solange die gut
funktionieren. Ich hab mal Tiger versucht zu installieren
und hab's 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.
Also wir haben ja irgendwann
einfach Whiteboards mit so normalen Post-its
Ja, einfach
vier Teams und jedes probiert was aus
und dann habt ihr irgendwann mal alles aus
Also 1999
hatten wir angefangen mit Bugzilla, glaube ich
Dann haben wir irgendwann den Request-Tracker
gehabt, dann haben wir Redmine
gehabt und
was haben wir noch?
Was hat man noch so gehabt?
Etrello immer so ein bisschen
Zermatt haben wir mal angetestet
Reiteflieh-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 typisch, was legst du noch an Anhängen, dem PDF, 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.
so ein bisschen in die Software wieder Sachen geschlagen.
Also ich muss aber sagen, gerade wenn man jetzt
remote arbeitet, 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
verschwurmelten Tickets, sondern man sieht das
alles irgendwie so vor sich visuell und das hat irgendwie
einen riesen Vorteil. Man braucht halt so ganz viele Boards,
aber wenn man das geht,
ich finde das sehr charmant. Und hast halt keine Nachverfolgbarkeit,
das ist halt schwierig.
Ja, vielleicht muss man das irgendwie dann abwenden.
Nein, das ist gut.
Nein, das ist echt perfekt.
Weil jemand, der nicht da ist, das nicht sehen kann.
Nein, nein, Nachverfolgbarkeit kommt halt immer darauf an,
weil da gibt es halt auch eine interessante Dynamik,
weil Transparenz im Unternehmen ist keine absolute Größe.
Das meine ich ja gar nicht.
Das sind ja die Leute, die da mit dran beteiligt sind.
Ja, ja, ja, warte, warte.
Transparenz hat das Problem, zu viel Transparenz killt dir die Innovation.
und und du hast Ja aber Zu wenig Transparenz bedeutet wiederum dass du halt Korruption reinkriegst 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 sie
so Sachen mit Whiteboards und wir haben auch
so extra hexagonale Post-its,
weil sie sich gut clustern lassen.
Ein hexagonales Post-it.
Ja, ein hexagonales Post-it.
Und 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 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 halt nicht machen.
Es ist erstaunlich, wenn man zu viele Mails kriegt, eine gute Strategie, einfach nicht mehr darauf 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 noch
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 nachmachen
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 an
Das kann jeder in den Shownotes nachlesen
Genau
Also zum Extreme Pro-Rigging gab es nochmal so einen Podcast
bei Cars for the Express, ich glaube die Nummer 28 war das
mit Pavel Mayer und Tim Pitlap
Das war schon ein bisschen älter
15 Jahre oder so, aber
Das ist immer noch gut
Damals schon ein Podcast
Und ich habe das damals schon gehört
Das Ding hat mich damals dazu gebracht
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 denn 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?
Vielleicht kommt jetzt nicht wieder auf.
Das Ende eines Projektes
war der Anfang des nächsten Projektes.
Du hast vor einer halben Stunde schon gesagt, wir sollen zum Ende kommen.
Ja, cool.
Fand ich auch echt interessant.
Ja, dann vielen Dank.
Das war ein sehr guter Tag.
Das war ein sehr guter Tag, wie der Dominik sagt.
Da kann man sicherlich noch mal eine Folge draus machen.
Feedback, weitere Wünsche, hallo at pythonpodcast.de.
Bleibt uns gewogen. Schaltet mal wieder rein.
Vielen Dank, dass ihr dabei wart.
Bis zum nächsten Mal. Tschüss.