Jeder kennt es. Projekte starten super und
eskalieren dann echt schnell. Genau das konnten wir auch in 24
Stunden erleben. Coding Buddies Dein Podcast rund
um Softwareentwicklung und aktueller Tech News Herzlich
Willkommen Halli Hallo und herzlich
Willkommen zur neuen Folge des Coding Buddies Podcast schön,
dass du wieder eingeschaltet hast und deine Gastgeber, wie
soll es anders sein. Meine Wenigkeit, der Tino und
der fantastische Fabi, der mich angrinst.
Eine klassische Anmoderation. Er fühlt es wie immer Fabi, was
geht ab. Moin Tino, Ich mach wieder was
geht an. Ja das sieht man, man sieht es
direkt du. Bist bereit, du hast Bock?
Na klar, auf jeden Fall. Podcast das ist immer, ist immer
schön, ja immer schön zusammensetzen, das ist n
bisschen quatschen. Eigentlich.
Das ist gut, weil sonst würde das ganze ja auch nicht so Sinn
machen. Also es ist schön, dass du da
Bock drauf hast. Ach.
Scheiße wieder Podcast. Nein.
Ich würd, ich würd sehr cool finden, wenn wir irgendwie noch
so weißte. Ich würd gerne mal noch so n
Kaffee dabei haben, aber man hört das schlürfen einfach zu
viel weißte. Wir sind einfach
kaffeeschlürfer. Ja, irgendwie schon.
Also Schlucker, dass. Man so ich glaub wir trinken
einfach komisch fabi deswegen absolutes Kaffeeverbot.
Ich weiß, es ist hart, mal 40 Minuten keinen Kaffee zu
trinken, aber dafür haben wir uns entschieden.
Deswegen auch jetzt stell die Tasse weg.
Ist gar nichts drin. Und bevor wir zum heutigen Thema
kommen, was sehr, sehr cool ist, noch mal ganz kurz ein Appell an
dich, liebe Zuhörerin, lieber Zuhörer, falls du diesem Podcast
noch nicht folgst, auf der Plattform deiner Wahl, dann.
Pausier doch mal ganz kurz Klick kurz aufs Knöpfchen, damit du
keine Folge mehr verpasst. Und das würde uns auch
unheimlich supporten. Deswegen vielen vielen Dank an
der Stelle und dann würd ich sagen Fabi, Bühne frei für dich,
hau doch mal raus was das heutige Thema ist.
Genau. Wir hatten ja vor, ich glaube
nicht letzte Folge, sondern die Folge davor ungefähr so in die
Richtung hatten wir auch schon mal über den Hackathon
gesprochen und da ging es ja um die unsere Vibe Coding
Erfahrung, die wir gemacht haben.
Wir hatten das extra auch so gemacht, dass wir das Thema
Hackathon, jetzt sag ich mal aus 2 verschiedenen Perspektiven
betrachten wollen. Das eine hatten wir ja schon
gemacht, das andere war für uns aber auch noch sehr interessant
oder relevant und deswegen haben wir gesagt, wir nehmen jetzt
noch mal Thema Hackathon, was wir gemacht haben und betrachten
das noch mal aus einer anderen Perspektive, und zwar die
Perspektive, an einem Projekt zu arbeiten, und das war schon,
fand ich super interessant. Weil man ja wie gesagt, diese 24
Stunden hatte, um mehr oder weniger ein kleines Projekt zu
bauen, aufzusetzen, zu erstellen und so wie man das Halt eben
auch im großen Stil bei einem Projekt kennt und der
Projektarbeit mit allem was dazu gehört, agilen Routinen und so
weiter das konnte man irgendwie, oder wir haben das ja so n
bisschen Revue passieren lassen und haben dann gemerkt, ey, man
kann das irgendwie auch so. Im kleinen Stil auch auf diesen
Hackathon in den 24 Stunden sehr komprimiert, irgendwie Münzen
und das ist das Thema im Endeffekt.
Genau, weil das Schöne an diesem Hackathon ist, dass es nicht nur
ein Learning gab für uns, sondern mehrere.
Und deswegen können wir daraus einfach noch mal unser unsere
Erfahrung teilen und ich find es auch richtig cool, dass wir das
Thema heute behandeln, weil es wirklich.
Echt so richtig, wie soll ich es also es war so so klischeehaft
nenn ich es fast mal wie es abgelaufen ist.
Als also jetzt aus Projektsicht weil jeder kennt das natürlich
so klassische Probleme die im Projekt auftreten, man fängt auf
der grünen Wiese an, man startet alles ist so richtig cool am
Anfang, man macht Progress, es läuft und läuft und läuft bis zu
die ersten Probleme kommen und die Leute anfangen im Kreis zu
Rennen und Panik also einfach Panik haben.
Das ist jetzt n bisschen witzig dargestellt, aber sinnbildlich
passt das schon ganz gut, dass Projekte oft so ablaufen, bis
hin, dass sie völlig eskalieren und alle nur noch im typischen
firefighting Mode sind und nur noch Brände löschen.
Ja, so und ich fand es halt super, super spannend, wie du es
ja schon angeteasert hast, dass wir im Prinzip so n Project in
der Nutshell haben durften durch diesen Hackasson, dass wir in 24
Stunden mal alle Zyklen sozusagen durchgespielt haben.
Weil das Ziel war ja nen fertiges Produkt, also ja nen
MVP, aber halt nen Produkt abzuliefern.
Ja und in der in diesem Lebenszyklus dieser oder in
diesen Iterationen von 24 Stunden, die man dazwischen hat
das ganze Mal zu betrachten finde ich ist halt super
spannend. Vielleicht magst du mal so n
bisschen unseren Plan erklären, dem wir, also wir waren ja ein
Vierer Team mit 2. Mitgliedern aus der Community,
was super, super cool war und wir hatten natürlich, wir waren
ja ambitioniert und wir hatten unseren Plan und unsere
Vorstellung, wie das ablaufen kann.
Also erzähl doch mal noch mal kurz so wie wie es hätte laufen
können. Hätte, hätte, Fahrradkette.
Ne. Na ja, also wir hatten also ich
sag mal so, grober Plan ist ja du fängst an, du musst irgendwie
dir was überlegen, du kriegst ne Aufgabe gestellt, das ist ja das
erste, du kriegst diese Aufgabe, das muss passieren, das ist
sozusagen das, wo es hingehen soll, also fängst du natürlich
an und sagst alles, klar, wir machen uns natürlich erst mal n
Plan, wie soll dieses Produkt überhaupt überhaupt aussehen, ne
beziehungsweise ist der erste Schritt ja, dass wir uns gesagt
haben. Wir wollen gucken, wie wir das
Ganze überhaupt verstanden haben.
Ne, das fand ich auch auf jeden Fall fair für diesen Hackathon,
dass man gesagt hat, OK, angenommen man hätte dieses die
Aufgabe nicht hundertprozentig so verstanden oder vielleicht
auch dran dran vorbeigearbeitet wäre, war es auf jeden Fall
wichtig, immer zu sagen, wie betrachtest du das Problem ne,
also wie hast du es verstanden? Und dann haben wir natürlich
geguckt, OK, wie haben wir alle im Team alle 4 das Problem
verstanden oder beziehungsweise die Aufgabe verstanden und haben
dann uns überlegt, wie wir an die Sache rangehen wollen.
Ne, also wie soll das aussehen, welche Anforderungen haben wir,
wie sollen sag ich jetzt mal Daten eingegeben werden, welche
Technologien verwenden wir dieses ganze Vorgeplänkel, was
du in einem Projekt immer eigentlich hast?
Ne, also du musst dir erst mal überlegen dir n groben Plan
machen, ne. Was passiert hier, was sollen
wir machen und welche Technologien nutzen wir so?
Und dann geht es ja darum, irgendwie so kleine Steps
vorzubereiten, zu sagen, OK, wie fangen wir an, dann gehen wir
bis zu einem bestimmten Punkt und gucken, wie weit wir
gekommen sind und können dann sozusagen die nächsten Steps
weiter überlegen und planen. Ne bis man dann halt irgendwann
fertig ist. So das wär jetzt erstmal so der
grobe Plan gewesen, sag ich jetzt mal mit dem wir ja auch
dann angefangen haben zu starten.
Ja erstmal das ganze Organisatorische und technische.
Was halt spannend ist. Was ich auch so im Nachhinein
noch mal n bisschen Challenge an unserer Vorgehensweise, weil man
es eigentlich besser wissen müsste.
Mhm, Wir hatten ja im Prinzip genau einen Stakeholder, ne und
das war der Challengepartner, der die Challenge reingegeben
hat. Also wenn wir jetzt mal nicht
quasi unsere Aufteilung im Team betrachten, ne wenn du jetzt
sagst OK mein Stakeholder ist halt auch keine Ahnung der
Frontend Entwickler der sagt was er braucht weißt du darum geht
es jetzt nicht, sondern wirklich mal kommt unser Team nach außen
und wir haben im Prinzip n Pitch bekommen.
Was das Problem ist und danach haben wir angefangen, unsere
eigenen Gedanken uns dazu zu machen.
Wie du meintest, sind aber nie wieder auf den Stakeholder
zugegangen. Ja, das.
Stimmt, wär im echten Projekt auf jeden Fall sehr
problematisch und theoretisch kann man sagen, war es auch hier
problematisch, nur dass wir es natürlich so nicht betrachtet
haben durch diese ganze Euphorie.
Durch den Hackathon zu sagen, ey, ich hab richtig Bock
loszulegen. Wir haben uns unsere Gedanken
gemacht, da muss ich sagen, das lief auch sehr gut, nicht
einfach loszumachen, weil man sagt, ist ja NMVP jetzt jeder
Attacke, sondern wir haben uns wirklich noch mal allined
hinsichtlich was ist unser Ziel und wie stellen wir uns das
Produkt vor, ja, also auch wie das Featureset aussieht, was
wollen wir alles drin haben innerhalb von diesen 24 Stunden.
Wie ist die die User Story dahinter?
Ne, also auch so aus UIUX Hinsicht, dass man sagt, wie
erwarte ich denn wie der Endnutzer das Tool verwenden
soll, aber wir sind nicht noch mal auf den Call da hingegangen,
also jetzt auf ihn zugegangen und noch mal sag ich mal uns
dahingehend alliged bei Fakt ist das ist ja das was du meintest,
sie haben quasi gecheckt wie hat man das verstanden, die Aufgabe.
Aber eigentlich ist muss das Verständnis ja matchen und man
hat ja auch am Ende gesehen, bei allen, die dann gepitcht haben
und ihr Ergebnis gezeigt haben, dass das schon auseinander ging,
die Vorstellung. Ja.
Also ich würde das ist ja eigentlich auch irgendwo so n
Learning. Ich würd sagen, es gab so 2
verschiedene Ansichten oder Verständnis weisen der Aufgabe
im Groben so von den 6 Teams, die die Aufgabe bearbeitet
haben. Aber das stimmt, das ist auf
jeden Fall ein wichtiger Punkt, den man da auf jeden Fall als
Learning mitnehmen kann und sagen kann, es ist natürlich
sinnvoll, wie in einem normalen Projekt auch, was eigentlich
absolut logisch ist. Rücksprache mit dem Stakeholder
zu halten. Es ist auf jeden Fall klar und
ich bin ganz ehrlich, ich es ist natürlich auch immer die Frage
bei dem Hacker von 24 Stunden, wie stark man das machen kann
und wie präsent. Der entsprechende Stakeholder
dann halt auch eben ist. Ich bin der Meinung, dass es so
von es gab ja 5 verschiedene Aufgaben von, ich sage mal 5
verschiedenen Stakeholdern und ich glaube, die Präsenz der
verschiedenen Stakeholder war unterschiedlich, aber sei mal
dahingestellt. Ja, also gehen wir einfach mal
davon aus, man hätte den Stakeholder schon erreichen
können und und Fakt ist, es haben ja auch Teams gemacht,
vielleicht jetzt nicht unbedingt von unserer Challenge, aber an
unseren Nachbartischen. Hat man das ja mitbekommen und
die hat natürlich ne andere Challenge.
Also das war ja auch gut gemacht, dass man quasi nicht
Challenge an Challenge saß und gucken konnte, was macht der
andere aus meiner aus meiner Bubble sozusagen, aber man hat
es ja bei den anderen mitbekommen und das haben Leute
schon wahrgenommen und das ist clever und richtig deswegen
also. Man kann ja auch selbst, wenn
man sich selbst als Team align kann, das ganze Team ja in ne
falsche Richtung laufen, definitiv, was ja wieder im
Projekt aus Projektsicht dafür spricht.
Warum gibt es dieses ganze Konzept auch zum Beispiel in
agilen Routinen? Ja, dass du halt diese kurzen
Feedback Zyklen haben möchtest. Ja.
Was n gutes Stichwort ist. Wie haben wir denn für uns diese
Zyklen definiert? Weil ich find, das war
eigentlich vom Plan her ne gute Sache.
Ja, das stimmt. Also wir hatten ja genau, also
sagen wir mal, wir gehen jetzt, sind jetzt an dem Punkt, wo wir
gesagt haben, wir haben geklärt, wie die Aufgabe aussehen soll
und wie wir sie verstanden haben, hätten noch mal ne
Rücksprache mit dem Stakeholder halten können, Learning haben
wir nicht fertig und haben dann ja auf jeden Fall auch erstmal
den Tech Stack geklärt, haben uns überlegt, OK, wie wollen wir
das Ganze angehen, wie soll der der Tech Stack aussehen?
Und wie soll dann die ganze Aufmachung sein?
Das ist ja auch noch ne Sache, die wir geklärt haben, nicht nur
die Aufgabe an sich, sondern auch ne die Aufmachung unseres
Produktes und halt eben die, die technisch der technische Aspekt
und nachdem diese Sachen dann geklärt waren, genauso wie unser
Stream Setup, weil wir auf Tisch gestreamt.
Haben ja, das hat auch noch mal Zeit gekostet.
Aber unabhängig davon haben wir dann natürlich.
Also haben wir dann gesagt, OK, lass uns anfangen zu arbeiten.
Und haben dann auch geguckt, dass wir bestimmte, also
Aufgabenpakete definiert haben. Ne, also haben dann quasi
natürlich geschaut, dass wir nicht gesagt haben, OK, wir
haben jetzt n Produkt, wo wo wir sagen, wir fangen jetzt an und
wenn wir fertig sind, sind wir fertig, sondern wir haben
natürlich gesagt, OK, wir haben Aufgabenpakete und haben
zusätzlich immer gesagt, und ich fand die Idee auch sehr, sehr
gut, die kam glaub ich auch von dir, Tino, deswegen props an
deine Idee. Dass wir gesagt haben, wir haben
immer n bestimmten Stand nach einer gewissen Zeit, ich weiß
gar nicht mehr, ob wir jetzt hundertprozentig genau die Zeit
festgelegt haben, also immer ein festes Intervall genannt haben,
oder ob wir mal gesagt haben, OK, die nächste Aufgabe lass uns
mal wieder syncen um, wir hatten ja mal n Countdown, den man
gesehen hat, wieviel Zeit noch übrig war von den 24 Stunden.
Aber auf jeden Fall haben wir gesagt, OK, ab einem bestimmten
Zeitpunkt sünken wir uns und wir haben einen Lauffähigen stand,
was wir immer quasi gesagt haben, OK oder der Plan war, wir
arbeiten an einem Arbeitspaket und wenn wir dieses Arbeitspaket
fertig haben, dann haben wir n stand, den wir sozusagen zeigen
können, was gut war, weil wir ja im Twitchstream waren und
gestreamt haben und gleichzeitig dann natürlich auch den
Zuschauern und Zuschauerinnen eben diesen Stand zeigen
konnten. Ja.
Es war natürlich noch mal doppelte Motivation, aber
grundsätzlich ist natürlich gut, in kleineren Iterationen sich
immer wieder zu leihen, zu sagen, OK, wie läuft es, was
gibt es für Probleme, also im Prinzip ja auch so agile
Konzepte mit einfließen zu lassen.
Ja, weil wenn man stundenlang jeder für sich irgendwas macht,
kann das halt völlig in verschiedene Richtungen laufen
und wir haben ja auch festgestellt, dass selbst in
unseren kleinen Zyklen. So was passiert ist ne, dass
dann 2 Leute zum Beispiel am Frontend arbeiten und der eine
gefühlt ne andere Umsetzung einer Page macht wie der andere.
Und eigentlich sollte gar nicht zweimal diese Page da sein.
So und dann war es halt dann auch wieder so n bisschen
abspracheprobleme oder nicht ganz klar was das Ziel ist von
der nächsten Iteration, wir haben es ja uns relativ simpel.
Wir haben das relativ simpel gehalten, dass wir einfach kurz
aufgeschrieben haben, was ist das Ziel dieser Iteration,
welche Features wollen wir da drin haben, haben dann
runtergebrochen, wie das für Frontend, Backend und Datenbank
und so aussieht, also für unsere Komponenten im Projekt und
Attacke und dann haben wir gesagt und jetzt nach so und so
viel Zeit müssen wir gucken, dass wir das hinkriegen, und
dann geht es weiter mit der nächsten Runde sozusagen, das
hat ja auch am Anfang gut funktioniert, wie gesagt, die
grüne Wiese ist immer schön am Anfang.
Aber wie es so kommen musste und auch in vielen Projekten ist
uns, dass er irgendwann n bisschen entglitten, sag ich
mal. Ja, also dass wir dann doch uns
der Euphorie hingegeben haben und einfach so n bisschen, ja
sag ich mal Anarchie ausbrechen lassen haben.
Wie wie hast du das so wahrgenommen an der Stelle?
Ja, ist auf jeden Fall n guter n guter Punkt.
Also ich fand es auf jeden Fall spannend, weil auf der einen
Seite haben wir natürlich für diesen für diese entsprechenden
Punkte oder Pakete, die wir uns vorgenommen haben, haben wir uns
natürlich irgendwie gesagt, OK, darauf arbeiten wir hin und
gleichzeitig merkt man einfach wie.
Fragil eigentlich, so der Fokus von jeder einzelnen Person.
Am Ende ist ne, also das hab ich auch selbst bei mir gemerkt, ich
hab halt dann irgendwie an einer Sache gearbeitet und dachte mir
so ey es wär doch irgendwie cool, wenn man jetzt zum
Beispiel noch irgendwie die Kleinigkeit mit rein baut so,
aber jetzt wär auch cool, wenn man das noch so n bisschen mit
rein baut und dies noch und das noch und dann weil man irgendwie
vielleicht gerade noch so n bisschen Zeit hat und dann ne
anfängt an irgendwie einer anderen Aufgabe oder an
irgendwas noch. Komplexer zu machen, als es
eigentlich vielleicht unbedingt sein muss beziehungsweise was
mir auch aufgefallen ist, ist, dass man auch gerade bei der bei
der Planung ne von den Paketen relativ schnell von einem MVP
gedanklich meiner Meinung nach weggekommen ist.
Hinzu, wir haben nen riesengroßes Featureset.
Was halt einfach gar nicht mehr unbedingt den MBP abbildet.
So und dann ist kommst du relativ schnell in so n Modus,
dass du sagst, OK wir fangen mit der ersten Aufgabe an ja und
lass uns doch noch das nächste gleich machen, das also zum
Beispiel du hast irgendwie Daten die du irgendwie eingeben kannst
und gleichzeitig sagst, OK, diese Daten müssen wir noch
editieren und gleichzeitig könnte man aber noch sozusagen
verschiedene Instanzen von diesen von von von diesen Daten
sag ich mal herstellen. Also es war ja beispielsweise
was das ne ne Person. Also es wurde sozusagen ich, ich
versuch es jetzt mal auf Metaebene zu machen.
Du hast ne Person mit einem mit einem Datensheet sozusagen ne
und für den MVP wäre es sinnvoll gewesen zu sagen, diese Person
hat einen Datensheet. Aber und das war ja für uns dann
auch wieder so n Ding rein theoretisch sinnvoller wäre es
aber, wenn du für eine Person mehrere Datensheets anlegen
könntest. Ne und genau aus solchen
Überlegungen ne, weil also diese.
Diese minimale Anforderung zu sagen, lass uns erst mal gucken,
dass wir wirklich nur sehr, also strikte Vorgaben haben und
sagen, eine Person hat jetzt einen Datensheet fertig ist ne
mehr nicht. Kommt man halt wieder in diese
Realität und in in diese, in diese.
Was wäre denn jetzt ein richtig tolles Produkt und ich fand das
war so, waren so 2 Punkte auf der einen Seite die Definition
von Arbeitspaketen anhand des MVPS um sich wirklich an dem MVP
lang zu hangeln und gleichzeitig zu sagen, Lass uns mal ein
Datenpaket Datenpaket sei schon ein Aufgabenpaket was wir uns
definiert haben. Auch wirklich.
Bis zu diesem Punkt abarbeiten, Syncen und dann weitermachen.
Und das waren so 2 wirklich schwierige Knackpunkte.
Ja, ich glaube allerdings, dass nicht die Definition der
Features, die wir aufgeschrieben haben, die gibt es ja noch, die
Liste, das können wir auch im Nachgang gern noch mal prüfen,
dass nicht die Feature Definition das Problem war,
sondern sich nicht dran zu halten, wie du meintest.
Also wir haben nicht quasi. Über den MVP hinaus das Ganze
definiert, was wir in dieser Iteration erreichen wollen,
sondern und ich find es auch gut, dass du es sagst, diese
Aufmerksamkeiten, dieser Fokus ist halt dadurch, dass es ja
auch alles, sag ich mal n bisschen spielerisch war, also
spielerisch im Sinne von nen MVP von Hackathon ist es halt
ausgeufert, sozusagen ne, also es ist halt einfach OK, das
Feature machen wir jetzt ja OK, was muss ich machen das das OK
da stand ja auch nur sowas wie ich.
Meinetwegen im Backend. Ich brauch n Endpunkt der das
und das macht ganz kleine Sachen Frontend.
Ich nehm diesen Endpunkt und zeig das an mal jetzt auch auf
Metaebene ne, aber dann war ja schon so n ja aber im Frontend
könnten wir das ja noch gebrauchen oder?
Im Backend könnten wir ja, aber dann brauchen wir ja
wahrscheinlich den noch, das Stand aber gar nicht da drin,
das ist ja der Punkt den du meintest, aber da haben wir
quasi auf entwicklerebene uns also sag ich mal die Versuchung
war zu groß zu sagen ich bau das noch ein weil das wär cool fürs
Produkt. War aber gar nicht aufgeplant.
Also wir sind quasi von dem ursprünglichen Plan einfach zu
schnell weggedriftet ja im Kopf für.
Mich sind es auf jeden Fall, also ja, auf jeden Fall.
Ich hab es tatsächlich, aber also trotzdem, wie soll ich das
am besten sagen, also was für mich n Punkt ist ist, dass ich
glaube erstmal um so n Learning mit zu mitzukriegen NMVP zu
bauen ist nicht einfach. Und zwar sich auch wirklich
gedanklich auch bei der Aufplanung daran zu halten.
Was ist wirklich das Minimalste wichtigste, was das braucht,
damit dieses Produkt funktioniert und ich finde, für
mich ist es das einfach NN absolut essentieller Punkt das
wirklich zu definieren, damit man gar nicht in diese
Versuchung kommt zu sagen. Wir könnten ja auch noch das und
das machen, weil für mich hat sich das so angefühlt, ja, dass
man, wenn man ein Produkt sich überlegt und sagt, das ist das
Wichtigste, was wir brauchen, und gleichzeitig könnten wir
noch, also wenn du nicht diesen, diesen minimalen Kern definieren
kannst, sondern direkt schon ne Hülle um diesen Kern baust und
aber denkst, dass der das minimale Produkt, dieser Kern
mit der Hülle ist, dann fängst du schon gleichzeitig direkt an,
ne, also. So geht das jetzt zumindest in
meinem Kopf gleich weiter zu denken, gleich noch zu
versuchen, wir haben jetzt n Feature definiert und können
noch gleichzeitig noch mehr dazu packen, weil man immer selbst
bei dieser Definition des also es sind 2 Punkte definitiv
einmal dieses Alignment zu sagen, das ist unser Feature was
wir jetzt bauen ne und selbst wenn dieses Feature worum es
geht nur der Kern ist ohne die Hülle.
Aber diese Hülle gedanklich mitschwingt.
Dann kommt man super schnell in diese diesen, diesen, diesen
Focus Loss, dass man halt genau sagt, OK, ich hab jetzt
irgendwie, ich arbeite an diesem Kern und gleichzeitig noch könnt
ich diese Hülle noch mit dazu packen.
Weißt du was ich meine und und das ist schwierig, weil wenn man
von vornherein wirklich schon diese Hülle aus den Gedanken
rauslöscht, dann dann dann gibt es diese Hülle gar nicht mehr,
ne, also. Aber wenn du vorher schon sagst
ne, es ist OK, wir können darüber nachdenken, dann kommt
man schnell in diesen Modus. Das auch noch mit zu
implementieren. Ich weiß nicht, ob ich das jetzt
so rüberbringen konnte, wie wie ich das gerne wollte, aber das
war für mich auf ist auf für mich auf jeden Fall n Punkt und
n Learning ne ja also genau also es ist halt sind halt die
Punkte, dass man sagt OKNMVP minimal wirklich definieren ist
schwierig, definitiv geb ich dir recht.
Das haben wir ja wie gesagt in den Features am Anfang
eingeplant oder runtergebrochen und sind dann aber in den Modus
gekommen, wo wir das nicht mehr sauber gemacht haben und dann
ist die Tür offen für dieses über NMVP hinaus.
Genau so, warum haben wir das irgendwann nicht mehr sauber
gemacht in den Iteration, weil natürlich irgendwann die ersten
Probleme kommen. Dass beispielsweise es bei
manchen Teammitgliedern denn zum Beispiel auch Projektprobleme
gab, dass irgendwas nicht mehr richtig lief, wo man sich auf
einmal gefragt hat, hä, was ist denn da jetzt los?
Also alles so diese, es ist halt wirklich witzig, dass man
innerhalb von 24 Stunden klassische Probleme von
Softwareprojekten, also Softwareentwicklungsprojekten
auch gespürt hat. Ja, und das ist sehr witzig,
muss ich sagen und auch so aussagekräftig.
Dass das einfach valide Probleme sind, die immer wieder auftreten
und die man irgendwie managen muss.
Ja, also Sonne, Sachen zum Beispiel oder Blogger, ja, also
um noch mal so n bisschen in die agile Welt zu gehen, du hast n
Feature und sagst ich will das jetzt implementieren, auf einmal
kriegst du auch innerhalb von 24 Stunden nen Blogger und denkst
dir ich kann das so jetzt nicht machen, wir brauchen den
Alternativplan und anstatt sozusagen.
Diese Liste oder unseren unseren Plan zu refinen ja, also mal zu
sagen, lass mal kurzen zum Beispiel n Huddle machen ja
einfach nur sagen Ey Leute alle kurz mal liegen lassen, hier ist
n Blogger, wir müssen da jetzt drüber sprechen, ist ja jeder in
seinen Modus verfallen weil die Uhr tickt, das finde ich hat da
auch psychologisch n riesen Einfluss, spätestens wenn es nur
noch n paar Stunden daran angezeigt wurden.
Dass man in den Modus verfällt, wie löse ich das jetzt?
Ich muss das jetzt lösen für mich, ich muss mir jetzt was
überlegen, wie ich das mache und dann ist man halt komplett
weggedriftet vom eigentlichen Plan.
Also ja, also kurz mal. Nicht schwärzer malen, nicht
Farben kann man nicht steigern, ne, aber also nicht böser
darstellen als es eigentlich war, weil wir haben ja am Ende
unser Ziel erreicht, was wir wollten, ja also gar keine
Frage, das definitiv cool, ja und hat auch funktioniert, aber
das sind so die Learnings die ich da mitnehme und ich finde
das ist ja auch wichtig und ich frag mich, warum man in so
Paniken in so n Panikmodus verfallen ist, weil zu dem
Zeitpunkt waren auch noch glaub ich 10 Stunden auf der Uhr oder
so. Wo die wo so n erstes größeres
Problem auf uns zukam hinsichtlich wir hatten ne
Vorstellung wie wir es lösen können und dann ging es so nicht
und wir brauchten Alternativlösung.
Ja, also ich glaub das waren sogar noch mehr als 10 Stunden.
Also von daher aber. Noch vor der übertriebenen
Müdigkeit auf jeden Fall genau. Ja, also ich, ich find das ist n
guter Punkt den du ansprichst und zwar Dinge wie zum Beispiel
kurze Syncs, Huddle miteinander sprechen, zwischendrin auch
Blocker feststellen, da muss ich auch sagen, gerade wenn es jetzt
zum Beispiel in einem großen Projekt oder halt auch in in
diesem kleinen nutshell Projekt, sag ich jetzt mal so wie es da
war, man merkt halt, ich find es gut, dass du es angesprochen
hast, dieses. Typische angenommen du
Onboardest n Mitglied, neues Teammitglied ne, dann willst du
ja eigentlich im Best Case möglichst schnell dafür sorgen,
dass Teammitglied halt eben auch die Software das Projekt an dem
man arbeitet halt eben auch auschecken kann, zum Laufen
bringen kann lokal. Zum Beispiel ne, dass man
irgendwie in der Lage ist zu sagen, OK, pass auf, du möchtest
damit arbeiten, du möchtest damit irgendwie entwickeln, dann
musst du natürlich auch irgendwie in der Lage sein, das
bei dir laufen zu lassen, damit du auch Änderungen relativ
schnell in dieser schnellen Feedback loop halt eben auch
mitkriegst und da muss ich sagen, das ist auf definitiven
Learning und das kann ich auch nur empfehlen, weil man das ja
auch normalerweise in einem Projekt eben auch so macht und
nicht ohne Grund, dass man auch in im Hackathon zum Beispiel
gesagt hat. Irgendwo tritt n Problem auf,
dann müssen wir dieses Problem erstmal lösen.
Für ein Teammitglied und dann können wir weitermachen.
Ne, das ist auf jeden Fall also diese dieses dieses Blogger
Thema zum Beispiel definitiv wichtiger Punkt und das haben
wir ja zum Beispiel dann auch etwas schleifen lassen im Team.
So, dann haben wir auch versucht Aufteilung zu machen.
Wieder dass man sagt, OK, ein ein Teil macht sozusagen die
Problemlösung, ein Teil arbeitet schon mal weiter, aber dann
kommt man natürlich wieder an den Punkt, wenn man das dann
noch kombiniert mit so einer gewissen Art von.
Verlieren des Fokus dass man dass der eine dann zum Beispiel
schneller weiter arbeitet über das Abgemachte Arbeitspaket
hinaus vielleicht als das, was eigentlich definiert war, und
dann eskaliert es halt total ne, und dann kommt vielleicht noch
so was dazu wie du meintest, dass zum Beispiel auch technisch
etwas in dem Moment nicht funktioniert hat, wie es
eigentlich hätte funktionieren sollen und wir eigentlich dann
an der Stelle noch einen anderen Plan brauchten und ich kann mich
noch ganz gut erinnern, dass das war es auch so ein so ein.
Punkt im Projekt, wo erstmal so richtig so völliges Chaos
kurzzeitig ja, wie wie du schon meintest, nicht schwärzer malen
als es am Ende war. Aber also weil wir es ja am Ende
hingekriegt haben, aber trotzdem war das ja auf jeden Fall voll
das Learning, weil es diesen Zeitpunkt gab, wo es komplett
eskaliert ist, wo wir auch zum Beispiel unsere Stände, die wo
wir gesagt haben, wir machen immer regelmäßig n stand, was
den wir zeigen. Haben wir auch zwischendrin halt
komplett verloren, dass wir das gar nicht mehr hingekriegt haben
aus diesen Gründen zum Beispiel. Genau, also wir sind halt
wirklich in diesen Brandlöschmodus verfallen, dass
wir dachten, jetzt fällt uns das auseinander.
Unser ganzer Plan ist hinfällig, was ja gar nicht war, also es
ging ja nur um n teilproblem sozusagen, was sich auf die Art
und Weise, wie wir uns das gedacht hatten, nicht lösen
ließ. Ja, aber das heißt ja nicht,
dass alles andere hinfällig war. Ne, und dann kam alles so auf
einmal ne bei dem einen läuft die Umgebung nicht mehr, wir
haben das Problem und so weiter und dann ist es halt so n
bisschen in so n Brandlöschmodus verfallen und das ist auch n
Learning wie du ja meintest. Wir hätten uns da schneller
wieder rauskämpfen müssen und es wäre eigentlich mit mit einem
erneuten. Zusammenkommt, drüber sprechen,
Lösung finden, also wirklich Ruhe bewahren da.
Also ich find das, das ist genauso wie irgendwas in einem
richtigen Projekt passiert, Schlimmes ja und wie verhältst
du dich Post mortim sag ich mal ne also dein Service ist
ausgefallen, es ist n Schaden entstanden wie verhältst du dich
danach? Wirst du jetzt panisch rennst du
im Kreis, versuchst irgendwie das Ding wieder hochzufahren,
koste es was es wolle. Oder sagst du, es ist passiert?
Wir haben den Chan und wir müssen gucken, dass es nicht
wieder passiert ist ja auch n klassisches Beispiel in
Projekten ja und genauso sind wir da in diese Falle getappt zu
sagen erstmal n bisschen im Kreis rennen bevor wir wieder
normal weitermachen ich mein du hast dann zwischenzeitlich das
einzig richtige gemacht, du bist ne Runde Mario Kart fahren
gegangen ne und das hat dich ja dann auch wieder n bisschen
befreit weiß ich nicht, obwohl du kannst noch aufgekratzter
zurück, dann ne. War.
Vielleicht nicht die beste Idee, aber sagen wir mal so ne gute
Idee wär wirklich gewesen mal weg von den Laptops.
Ja kurz mal Stream pausieren, allen Bescheid sagen, wir müssen
uns mal kurz ohne Geräte an Tisch stellen und drüber reden
weil was und jetzt kommen wir wieder zu zu den guten
Erfahrungen also. Wenn man das jetzt mal so
einteilen möchte, weil wir haben ja dann irgendwann entschieden,
so Leute, Pass auf, wir machen mal n Break, wir gehen mal n
paar Stunden schlafen, weil durchziehen macht keinen Sinn,
der Kopf qualmt, wir wissen also, es kommt auch nicht mehr
so viel Produktives dabei raus so.
Dann haben wir diese Pause gemacht.
Ja, kurz mal die Augen zu, mal n bisschen geschlafen und dann
haben wir genau das gemacht, was ich gerade meinte und das war so
so hilfreich für das Projekt, dass wir uns erstmal an den
Tisch gestellt haben. Jeder hat sich n Kaffee geholt,
also nach der schlafenspause sag ich mal ne sozusagen nächster
morgen in Anführungsstrichen, aber dann haben wir uns einfach
wirklich wie, das hat sich wie nen gutes Daily angefühlt.
Hingestellt noch mal kurz auf den Tisch gebracht.
Was sind unsere Probleme gerade, was ist unser Ziel, wo soll es
hingehen? Wir haben noch so und so viel
Zeit, haben das denn Runtergebrochen in machbaren
Schritten und vor allem, und das noch mal den Bogen zu schließen
zu deinem Learning, wir sind auch noch mal wirklich auf das
MVP zurückgekommen und haben gesagt, Leute, das ist unser
Ziel. Das wollen wir und alles, was
wir dann noch schaffen, wenn wir noch Zeit haben, können wir
gerne noch on top bauen. Aber jetzt ist das Ziel, diesen
MVP fertig zu kriegen und schon waren wir wieder alle aliged
jeder wusste, was los ist. Motivation kommt natürlich
automatisch wieder rein, weil du einfach wieder weißt, jetzt, so
machen wir weiter und dann haben wir das echt straight die
letzten Stunden noch runtergearbeitet mit lauffähigen
Ständen wieder wieder mit den Iterationen.
Also wir sind einfach wieder zu unserem Ursprungsplan
zurückgekehrt, haben aber Stunden dazwischen diesen
Brandlöschmodus gehabt. Aber was natürlich irgendwann
kickt durch die Müdigkeit und so, keine Frage.
Was ich vorhin meinte, das ist halt genau, also vielleicht ist
es auch nicht, habe ich das auch nicht so richtig definiert, aber
ich glaube, dass am Anfang war, zumindest war das mein Eindruck,
als wir angefangen haben, war glaube ich nicht für jeden
hundertprozentig klar. Im Team.
Was ist wirklich der MVP Umfang? Weil ich hab im Rückblick n
bisschen das Gefühl gehabt, dass für den einen war der MVP Umfang
größer als für ne andere Person, im Großen und Ganzen war halt
für alle dieser Kern den ich meinte klar, aber diese Hülle
drumherum, die war vielleicht für den einen sehr dünn, für den
anderen etwas dicker ne also das ich nenn das jetzt mal so ne on
top Feature Hülle und das ist dann halt.
Und und das, was wir an dem am nächsten Morgen gemacht haben,
nachdem wir 3 Stunden geschlafen haben, war also Daily ist n
guter Begriff dafür, weil wir genau gesagt haben, wo stehen
wir, wie machen wir jetzt weiter genau und wo sind gerade unsere
Probleme an sich, war das wirklich n perfektes Daily, so
wie man es eigentlich machen sollte und dann auch sehr sehr
zielgerichtet und das war gut. Nur wie du meintest, wir haben
uns dann besonnen, dass wir wirklich das MVP machen,
bedeutet ja gleichzeitig, dass wir offensichtlich Features
hatten, die wir irgendwie gedanklich eingeplant haben,
obwohl sie eigentlich nicht wirklich zum MVP beigetragen
haben und das war für mich auch so.
N so n Learning, so n Kleines, so n so n so n.
Punkt, der mir gesagt hat, OK, ich glaube es ist wichtig, dass
man sich wirklich und wenn das noch mal ne halbe Stunde länger
dauert in Lindt, was ist unser MVP und auch wirklich dann jeder
muss offen dafür sein zu sagen, OK, ich finde diese Idee, dieses
Feature finde ich gerade geil, aber es bringt gerade nichts für
das MVP weil und das ist finde ich auch n noch n Learning und
Topman glaubt immer. Das ist das MVP.
Aber wenn wir das noch machen, das ist nicht wirklich viel
Aufwand und das schaffen wir noch und das wär supergeil.
So weißt du, und das ist dann genau der Punkt und wenn man
dann aber an an einem in einem Modus ist, wo man sagt, diesen
Punkt haben wir jetzt fertig. Oder den hab ich jetzt fertig
gemacht, aber ich hab ja noch diesen kleinen Ah, das mach ich
noch schnell mit rein, aber das zieht so n Rattenschwanz durch
die ganze Anwendung durch, unter Umständen, dass man es eben dann
halt nicht schafft und dann hinterher an diesen Punkt kommt
wo man sagt, komm wir schmeißen das wieder weg und dann hat man
natürlich an etwas gearbeitet, was nicht wirklich sinnvoll ist.
Und genau das merkt man ja auch in in größeren Projekten auch
dass es immer Einzelpersonen gibt, die sich denken.
Komm, ich bau das jetzt noch ein.
Das ist übelst geil, das ist so die Kirsche auf der Torte, aber
eigentlich brauchst du diese Kirsche gerade gar nicht, ne und
das ist halt so NN wichtiger Knackpunkt, den man einfach im
Auge behalten muss super super wichtiger Punkt irgendwie.
Zumal, so NMWP. Ist ja auch immer die Frage, was
ist der MVP? Ja, also wir haben gesagt, nach
24 Stunden wollen wir auf jeden Fall was Lauffähiges zeigen mit
einem gewissen Minimum Set an Features, das kann jetzt unser
MVP sein, grundlegend haben wir es ja aber auch so geplant
gehabt, dass wir immer sozusagen was lauffähiges haben, was wir
zeigen können, das heißt wir hatten ja von vornherein gesagt,
lasst mal keine Big Bang Integration am Ende machen und
völlig in Panik verfallen und auf letzter Minute irgendwas
einreichen. Muss man ja auch sagen, so
ungefähr 2, anderthalb Stunden vorher waren wir mit dem durch,
dann haben wir noch so ein 2 Sachen gemacht, so nice to have,
aber wir haben da nichts mehr riskiert, sozusagen ne riskiert
im Sinne von wieder in diesen Gedanken zu verfallen.
Boah ey jetzt, das wär geil, weil dieser Rattenschwanz, der
ist absolut real, dass das passiert am Ende, weil dann
passt irgendwas nicht boah ja kannst du im Backend das bitte
schnell einbauen, weil ich hab jetzt hier ey, das ist geil, das
müssen wir haben, bloß mach mal ich brauch n Endpunkt.
So, und der denkt sich gut, alles klar.
Ja OK, weißt du was? Come on mach ich so, Ah der war
die Daten haben wir gar nicht so boah ich kann das gar nicht so
aus der Datenbank ziehen und schon geht es los ja und dann
machst du irgendwelche Sachen dann läuft n Test irgendwie
nicht und man muss ja auch sagen wir hatten ja auch Tests da drin
und es war uns ja also wir haben ja versucht unsere
Arbeitsmethodik mal abgesehen von dem Vibecode ja das haben
wir ja in der extra Folge ja weil Fakt ist auch, dass hier
noch mal die Anmerkung bei dem Tempo.
Den du durch Vibecome, wenn du es zu 100% machst.
Bei dem Tempo was du da aufnimmst, ist es auch wirklich
schwer noch agil im Sinne der vom wendig sein ja noch
einzuhalten und auf irgendwas zu reagieren, weil alle Rasen mit
180 in diesem Projekt langt ne und keine Ahnung, du stellst dir
gerade im Backend die Frage Boah, macht das so überhaupt
Sinn? Ich müsste vielleicht.
Das noch mal noch mal Rücksprache halten, aber der
Frontentwickler hat schon den prompt abgesetzt und das Ding
implementiert. Schon sowas also das das kommt
natürlich noch hinzu, dass wir wirklich gesagt haben, wir
ziehen es mal einmal komplett durch als Erfahrung und gib ihm
ne, also die Credits haben ja wirklich geglüht muss man sagen,
aber trotzdem war kann man ja auch sagen, wir hatten
eigentlich immer am Anfang bis wir es am Ende wieder hatten
immer nen MVP. Ja, und auch wirklich mal zu
denken, was wäre der nächste MVP sozusagen in diesem Projekt und
da den Fokus behalten, das wär halt also ihn noch mehr zu
behalten. Wie gesagt, wir hatten ihn am
Anfang und am Ende und in der Mitte sind so typische
Projektsachen geschehen, bisschen, das würd ich glaub ich
genau wir sind abgedriftet und das ganz kurz noch beim nächsten
Hackathon und ich hoffe wir machen es noch mal und auch
gerne wieder als Community Team als mega.
Geil war auf jeden Fall. Das ist eigentlich mein größtes
Learning dabei. Bei allem, was so passieren
kann, zum Beispiel das auch am Anfang mit der Absprache, ja,
haben wir ausführlich gemacht, aber nicht ausführlich genug,
bin ich ganz bei dir, sonst wär das nicht passiert, aber dieses
nicht in Panik verfallen und bei dem Gameplan Bline sozusagen,
ist eigentlich mein größtes Learning, was ich hoffe, dass
wir es beim nächsten Mal besser machen.
Was ich auch noch interessant finde ist, wenn man das jetzt
mal wirklich sagt, MVP ja. Zu in 24 Stunden zu einem echten
MVP, das wär nur fair zu sagen. Echtes MVP eines Produktes über
also für n echtes Produkt, was natürlich deutlich länger ist.
Wir können auch noch darüber hinausgehen und sagen, OK, wir
tun jetzt mal so als wär es wirklich n echtes Produkt, würde
es n echtes Produkt im Hacker von 24 Stunden ist egal, aber
wenn man sich jetzt überlegt wir haben 24 Stunden Zeit gehabt und
haben. Am Ende ein Daily da drin
gemacht. Würde ja bedeuten, dass du im
gesamten Projekt oder im gesamten MVP eines Projektes ein
keine Ahnung. Monats 3 Monats machst ein three
month Lea keine Ahnung, egal wie lange.
Also du musst dir vorstellen wir haben ein Daily gemacht, wir
haben gemerkt das Daily war super, es war wirklich super
hilfreich aber rein theoretisch auf diese Zeit von 24 Stunden.
Ist ein Daily halt viel zu wenig, weil du machst ja auch
nicht innerhalb eines Projekt, einer Projektdauer oder einer
Dauer eines MVPS ein Sync. Das ist ja auch viel zu wenig ne
und genau deshalb. Ja gut, dann, da muss man
natürlich sagen, also wir hatten den Sync.
Ja, also wir haben ja da uns zusammengesetzt und haben die
Features aufgemalt, also sozusagen n Planning gehabt.
Aber ich geb dir insofern recht, dass wir nur ein richtiges Day
hatten, wo wir wirklich mal gesagt haben, Leute, lasst mal
alles stehen und liegen, wir gehen jetzt zum Beispiel an den
Stehtisch, so wie wir was da gemacht haben, was übrigens die
beste Entscheidung war und zu sagen, wie läuft es denn gerade,
wir haben etwas geplant, das haben wir gemacht, ja, also in
da war ja auch irgendwo in Sync drin.
Aber wir haben nicht drüber gesprochen, wie es läuft und was
für wie unser Empfinden ist dabei.
Das klingt jetzt also, weißt du, wie ich das meine so dieses ich
glaub das ist zu viel oder ich glaube das kriegen wir so nicht
ins Ziel über sowas halt zu sprechen und vor allem, und das
ist absolut normal, da will ich auch keinen ankreiden, das hab
ich auch selbst gemacht wie du meintest du bist gerade in einem
Thema, jetzt sagt jemand ah Zeit ist rum, jetzt wird gesynct
jetzt gehen wir in das Board rein und gucken.
Und du denkst dir ja, bin gleich bei euch Leute, bin gleich bei
euch, mach das noch schnell fertig, läuft nicht.
Ah ich bin auch wirklich gleich bei euch, dann kommst du dazu,
dann hat der andere sich gedacht Boah gar keinen Bock zu warten,
ich mach das fertig und so haben wir es ganz selten geschafft im
späteren Verlauf alle 4 im Kopf anwesend zu kriegen, es sei denn
wir sind zu diesem Tisch. Gegangen.
Genau das ist also dieses Weg vom vom vom Bildschirm, aber ich
finde genau diesen diese parallele kann man ja super
ziehen, ob man jetzt von einem Daily redet oder nicht, aber es
geht um diesen effektiven Sync, den wir gemacht.
Ja, den man auch glaub ich oftmals in großen Projekten auch
einfach vermisst. Ne und es geht jetzt.
Wirklich und auch oft abgelenkt ist.
Ja, es geht um diese effektiven Syncs ne und ob du es jetzt
Daily nennst oder ob du es n huddle nennst oder wie auch
immer man das nennen möchte, aber wirklich effizient effektiv
zusammenzukommen und daran zu denken, das ist halt wichtig und
ein Punkt, ein letzter Punkt, der mir auf jeden Fall noch
einfällt und das ist genauso wieder so n Ding.
Wir haben gesagt, wir arbeiten dran, wir haben dran gearbeitet,
wir sind immer müder geworden. Ja, weil wir im Rush waren und
so weiter wir sind halt auch generell einfach müde geworden.
Und dann merkst du, die Zeit wird knapp.
Ja, jetzt kann man sich mal überlegen Projekte mit Deadline,
die Zeit wird knapp, was machen die Leute, was macht man im
Projekt, man wird unaufmerksam, man rennt im Kreis, man wird
hektisch, man weiß nicht, was man tun soll und was man aber
oftmals in diesen Phasen nicht macht, ist genau das, was wir
gemacht haben, einfach aus dem Grund, weil man irgendwann müde
ist, was man ja theoretisch über eine längere Zeit gut
kompensieren kann, wenn man einfach pennen kann
zwischendurch. Aber es war halt erzwungen,
diese Pause, die mussten wir machen.
So, und genau das wird manchmal nicht gemacht zu sagen, man
macht mal ne Pause, man evaluiert das noch mal aus einer
anderen, aus einem anderen Blickwinkel, und kann dann
sozusagen weitermachen. Nein, in einem richtigen Projekt
bist du die ganze Zeit im Firefighting Modus und kommst
nicht mehr aus diesem aus dieser Hektik heraus.
Genau. Das war sehr gut.
Dass wir da die Kurve gekriegt haben und auch wirklich noch
Zeit am Ende hatten und wirklich ausliefern konnten.
So gesehen ja, ohne dieses Gefühl zu haben, ob bitte lass
es funktionieren, sondern wir hatten die Zeit, wir wussten,
der Stand läuft, wenn wir was eingebaut haben, hätten wir auch
jederzeit zurücksetzen können, also das was wir so die letzte
Zeit gemacht hatten, ne also wir wussten wir haben auf jeden Fall
was was wir liefern können und das ist halt n geiles Gefühl und
da bin ich auch richtig froh, dass wir das am Ende so
hinbekommen. Haben und nicht wir haben ja
auch andere Teams gehört, die meinten, EY, dann ging am Ende
nichts mehr. Jetzt haben wir die Hälfte
gemockt und fertig, auch absolut valide vom Hackathon, aber es
war nicht unser Ziel, unser Ziel als Team war.
Wir liefern was, was lauffähig ist, wo alles verknüpft ist, wo
nichts gemockt ist fertig, was du einfach verwenden kannst.
Und da muss ich sagen, bin ich auch richtig stolz auf unser
kleines Community Team. Ja auch noch mal vielen Dank an
die anderen beiden und das hat Mega Mega Bock gemacht und gerne
wieder. Definitiv bin ich auch voll
dabei. Wie gesagt, das war jetzt auch
wirklich meckern auf hohem Niveau hier.
Es sollte ja genau mal so ein Fazit sein oder das Learning,
was wir also quasi bekommen haben aus einem kurzen Projekt
und. Was man vielleicht so für
Parallelen sieht, halt auch in größeren Projekten.
Und witzigerweise sind die Dinge, die da aufeinandertreffen
oder die Probleme, die man da bekommt halt sehr sehr ähnlich
und das ist halt irgendwie spannend am Ende und dann kann
man vielleicht auch was mitnehmen.
Ja für die Zukunft, für den nächsten Hacker von aber auch
für richtige Projekte, ja ja danke Tino, für bitte bitte den
Tor Spaß macht auf jeden Fall. Wie gesagt, Hacker von machen
wir gerne wieder bei der nächsten Gelegenheit werden wir
das natürlich auch wieder verkünden und hoffen, dass wir
wieder ein Community Team auf die Beine stellen können und in
dem Sinne vielen Dank fürs Zuhören Liebe Zora, wenn du
sagst ey, ich habe auch schon mal bei dem Hacker von
mitgemacht und bestimmte Erfahrungen gemacht, dann lass
uns das gerne wissen. Kommen auf unseren Discord und
lass uns uns lass uns da austauschen, das wäre richtig
cool. Ansonsten empfiehl den Podcast
gerne weiter und bewerte ihn auf jeden Fall wenn er dir gefallen
hat. Und wenn du sagst, der Podcast
gibt mir sogar noch viel mehr, ich möchte eine kleine Spende da
lassen, dann gibt es da auch einen kleinen Link in den
Shownotes und ansonsten hören wir uns einfach in der nächsten
Folge wieder deine Colling. Wallis gemeinsam besser weißt
du, was? Auch sehr coole parallel
zwischen Hackers und unseren Podcasts ist.
Hier haben wir auch noch einen Plan, was wir sagen wollen und
dann eskaliert es auch völlig.