Latest / Coding Buddies | Tech & Dev-Mindset / Mythos oder Fakt #2 - Mehr Coder = Schnellere Entwicklung

Transcript

Mythos oder Fakt #2 - Mehr Coder = Schnellere Entwicklung · Coding Buddies | Tech & Dev-Mindset

0:00
Weil es ist ja nicht so. Du kommst in den ersten Tag
0:02
irgendwo in nen Team. Was macht dir XY alles klar?
0:05
Bin dabei, gib her wo IDI, ja ich hab meinen Rechner schon
0:08
mit, der ist schon, dass da schon alles eingerichtet, wir
0:09
können loslegen Coding Body Deinem Podcast rund um
0:13
Softwareentwicklung und aktueller Technews.
0:15
Herzlich Willkommen. Was?
0:28
Einen wunderschönen guten Tag und herzlich Willkommen zur
0:31
neuen Folge vom Coding Buddies Podcast.
0:34
Es geht wieder los, wir sind wieder bereit, wir sind wieder
0:37
da. Oh ja, Tino und ich, Tino, grüß
0:40
dich. Grüß dich, fabi.
0:42
Was geht ab? Alles gut bei dir?
0:44
Ja, ich würde sagen, es geht mal wieder los.
0:49
Es ist wieder Zeit. Oh ja, oh ja, wir sind jetzt
0:52
auch glaube ich, langsam schon ganz cool gestartet ins Jahr
0:55
oder so, wir sind wieder richtig drin.
0:57
Ja, das Jahr läuft schon wieder. Also eigentlich ist ja 2024
1:00
jeder hat das schon jetzt schreiend geschrieben.
1:01
Ja, also weißt du dieses typische Nein, aber dieses
1:05
typische, so das erste Datum was du im Jahr schreibst ist das
1:12
Jahr vom letzten Jahr. Weißt du also sozusagen sowas
1:15
wie 7.1. 23 nein, Scheiße. Ich finde das auch eine super
1:22
gewöhnungssache, dann erstmal sich wieder ins neue Jahr zu
1:24
gewöhnen beim Schreiben, da hast du recht, das geht mir wirklich
1:27
immer so, ist total abgefahren, aber wahrscheinlich nicht nur
1:29
mir so. Kleiner Tipp von mehreren Leuten
1:31
muss. Dir im Dezember schon ganz oft
1:34
das Jahr, also die Zahl vom nächsten Jahr sagen.
1:38
Du musst es schon verinnerlichen und dann läuft wie.
1:42
Soll das aussehen, dass man dann irgendwie durch die Straßen geht
1:44
und mit jedem, dem man spricht, sagt?
1:46
Ach übrigens, das ist bei 2024. Nein, du stellst dich in den
1:49
Garten und schreist ganz laut 2020 100 mal.
1:54
Ich hab keinen Garten. Na ja, gut, OK, dann mach ich
1:56
halt Schreibfehler auch kein Thema.
2:00
Schreis aufs Fenster? Nein, keine Ahnung.
2:03
Merk es dir. Ja, merk dir einfach so.
2:06
Wir haben 2024 los geht es, erzähl mal, was ist denn das
2:11
Thema? Du hast doch was mitgebracht.
2:13
Ja, wir wollen mal wieder eine Folge machen, und zwar eine
2:18
Mythos oder Faktfolge. Oh yeah, das war cool letztes.
2:23
Mal. Ja, und da hab ich jetzt mal
2:27
eine Aussage mitgebracht. Aussage soll einfach heißen,
2:34
wenn du mehr Leute in ein Projekt steckst, dann ist die
2:37
Entwicklung der Software, die du sozusagen entwickelst,
2:39
schneller. Mehr Leute, schnellere
2:41
Entwicklung quasi. Also.
2:47
Mehr Softwareentwickler beziehungsweise mehr
2:48
Softwareentwicklerin heißt auch gleichzeitig, ist quasi
2:51
äquivalent zu einer schnelleren Entwicklung dieser Software.
2:56
Ne, das ist quasi sozusagen das Thema, über das wir uns einmal
3:00
ganz kurz ein bisschen unterhalten wollen in einer
3:02
Mythos oder Fun Folge und dann halt mal gucken, ist das jetzt
3:05
ein Mythos oder ist das ein harter Fakt?
3:10
Was sagst du dazu? Was?
3:11
Wie könnten. Wir an die Sache rangehen.
3:15
Naja gut, also im Prinzip kann man ja nur von eigenen
3:18
Erfahrungen berichten, das würde ich jetzt auch mal machen.
3:22
Also ich hoffe, wir machen das nicht nur ich.
3:26
Weil. Ja, ich glaub das kannst du ja
3:29
jetzt nicht irgendwie mathematisch belegen oder so und
3:32
sagen ja, das ist ein Fakt oder keine Ahnung, das ist Mythos,
3:35
weil ne. Also würde ich sagen, lass uns
3:39
doch einfach mal schauen, schauen wir noch mal die letzten
3:41
Jahre zurück, so Projekte die wir gemacht haben und wie das da
3:43
lief. Also also meine Erfahrung dazu
3:49
ist, dass. Meistens.
3:54
Jetzt muss man aufpassen. Also ich will das ja auch nicht
3:57
verallgemeinern, aber meine Erfahrung nach immer ist es eher
4:01
so, immer ist immer so. Dass ab einer gewissen Anzahl an
4:09
Entwicklern es nicht mehr schneller wurde, im Gegenteil.
4:12
Da sind dann andere Probleme mit ins Boot gekommen, die teilweise
4:18
oder auch oft dazu geführt haben, dass genau das Gegenteil
4:21
passiert, also man nicht schneller wird, sondern eher
4:24
langsamer. So, das klingt ja jetzt erstmal
4:26
ein bisschen. Ihr seid doch mehr Leute, mehr
4:29
Leute, die Code schreiben und dann dementsprechend kann ja
4:32
mehr Code schneller entwickelt werden und man müsste ja auch
4:35
schneller vorwärts kommen, aber das.
4:37
Tatsächlich ist das nicht die Erfahrung, die ich gemacht hab.
4:41
Ich weiß nicht, wir können ja gleich auch noch mal so n
4:43
bisschen begründen warum, aber ich würd gern mal wissen, wie
4:46
deine Sicht ist. Vielleicht haben wir ja jetzt
4:48
quasi 2 Seiten und könnten gegenargumentieren oder
4:52
argumentieren, warum wir der gleichen Meinung sind, also hau
4:55
mal raus, wie siehst du das oder wie ist deine Erfahrung dabei?
4:58
Ja, also ich hab auf jeden Fall auch schon in meiner Karriere,
5:03
sage ich jetzt mal, Projekte ganz alleine gemacht.
5:06
Das waren dann eher kleinere Projekte und sehr.
5:11
Begrenzte Themen, die man eben halt auch alleine bearbeiten
5:16
konnte. Und ich habe auch schon in Teams
5:19
gearbeitet mit 4 Leuten bis ungefähr so bis 8 Leuten.
5:25
Also wenn es jetzt wirklich mit Leuten, meine ich wirklich
5:27
Softwareentwickler bzw softwareentwicklerin.
5:31
Und aber aber. Im gleichen an der gleichen
5:34
Software also. 8 Leute, die wirklich, sage ich mal daran.
5:39
Entwickeln genau. Also ich kenne ja.
5:42
Schon ordentlich. Ist schon, ist schon ein
5:44
bisschen. Nicht mehr so klein nennen.
5:46
Nee, auf jeden Fall nicht. Geh ich mit, aber das sind ja
5:49
auf jeden Fall, es ist halt ne Bandbreite zwischen alleine und
5:52
auch Stufen dazwischen, zwischen alleine und 8 ne so Leute.
5:58
Und ich habe auf jeden Fall gemerkt, dass zumindest in
6:04
dieser Range. Wie sagt man?
6:08
Die Goldene Mitte sagt man, also die goldene Mitte in der Mitte
6:11
lag also goldene. Mitte lag in der Mitte.
6:16
Es man glaubt ja mal nicht, dass die Goldene Mitte auch wirklich
6:18
in der Mitte ist. Nee, aber so ich, ich fand auf
6:22
jeden Fall, wenn man alleine arbeitet, ist es so der Punkt,
6:25
dass ich finde, dass es relativ schnell geht, dass man quasi.
6:31
Wenn man jetzt Leute hinzufügt, sagen wir mal, anstatt einen
6:34
alleine zu arbeiten, auch noch eine zweite Person dazu packt,
6:37
geht die Entwicklung auf jeden Fall schneller.
6:38
Also soweit würde ich eigentlich fast immer gehen und sagen, das
6:41
ist Fakt. In einem Gewissen, in einer
6:45
gewissen Range funktioniert das fantastisch.
6:48
Ich würde auch sagen, dass zum Beispiel so bis 4 Personen
6:52
kannst du ne relativ würde ich jetzt aus meiner Erfahrung
6:55
sagen, ne relativ gute Aussage oder wäre die Aussage für mich
6:59
würde ich zustimmen würde ich sagen ist OK. 4 Personen wird
7:04
auch schneller. Ich würde aber zum Beispiel
7:06
nicht sagen, dass wenn du sagst, du hast eine Person und das ist
7:10
jetzt quasi eine. Weiß nicht.
7:12
Eine Entwicklung von 1, dass quasi bei 4 Personen die
7:17
Entwicklung auch auf ich sag jetzt mal die fiktive Zahl von 4
7:21
im Fortschritt steigt? Also ich würde nicht sagen, dass
7:23
es linear ist. Ja genau, und da könnt ich würd
7:27
ich dich jetzt zum Beispiel mal fragen, bevor ich das jetzt noch
7:29
abschließe, bloß bei 8 Leuten hab ich schon gemerkt, da wurde
7:33
es auf jeden Fall schon mal wieder n bisschen träger, also
7:36
die Kurve flacht ab würd ich sagen und dann ist halt die
7:39
Frage geht sie irgendwann auch wieder runter das heißt also hat
7:43
man zum Beispiel irgendwie vielleicht auch diesen Punkt,
7:46
dass man sagt mit 16 Leuten ist man deutlich langsamer als mit 8
7:49
zum Beispiel, aber was meinst du denn was ich mit also wie stehst
7:55
du dazu, wie kannst du dir das vorstellen wenn ich sage?
7:59
4 Leute sind nicht doppelt so schnell in der Entwicklung wie
8:01
2. Ja.
8:06
Also noch mal, falls das nicht ganz rüberkam, ne, wenn wir
8:09
jetzt Projekt und Entwicklung sagen, dann reden wir ja
8:11
wirklich von einem Thema. Also natürlich ab ner gewissen
8:16
Größe sage ich mal. Wenn man jetzt wirklich n sehr
8:19
großes Projekt hat. Sind es natürlich mehr als 48
8:24
Entwickler, Entwickler, dann ist es halt zweistellig, vielleicht
8:27
sogar dreistellig, je nachdem wie riesig das Projekt ist.
8:29
Wir reden ja jetzt wirklich davon, an einem Thema zu
8:32
arbeiten, ne, also jetzt nicht, nicht ein Feature zum Beispiel,
8:36
aber zum Beispiel ein Teilprodukt des gesamten.
8:39
Oder Halt eines Standalone Anwendung.
8:43
Genau, weil da einfacher bin ich auf jeden Fall dann ganz bei
8:46
dir, dass man sagt okay zu zweit auf jeden Fall zu viert, ist
8:50
auch noch cool, dann kann man das noch sehr gut organisieren.
8:53
Wie geht es weiter? Am besten hat man denn schon
8:55
einen, der so ein bisschen. Bisschen zumindest in die Rolle
8:59
übernimmt, das zu koordinieren so ein bisschen vielleicht mit
9:02
anderen Teams redet, also dieses, Wir hatten ja auch mal
9:04
über Scrum geredet, so ein bisschen so den Product owner
9:06
macht, sage ich mal und sagt Okay Leute, ich übernehme das,
9:11
ich entwickle zwar noch mit, aber ich gucke schon mal, dass
9:14
wir die richtigen Features machen, wann müssen wir das
9:16
machen, also da muss halt Koordination rein, weil wenn
9:19
jetzt 4 Leute los sagen. Soll ich dir mal das in dem
9:22
Moment mal? Das hab ich doch schon gemacht
9:23
letzte Woche. Ja.
9:25
Oder also mal übertrieben gesagt ne oder 2 nehmen sich morgens n
9:29
Thema und nehmen sich das gleiche und reden nicht
9:31
miteinander. Also.
9:33
Das Entschuldigung, das Problem oder die die Challenge dabei ist
9:38
ja, wenn du alleine bist, kannst du machen was du willst.
9:41
Du bist dein eigener Herr, zu zweit musst du nur mit einer
9:44
Person reden, vielleicht arbeitet man sogar im Pair, sage
9:47
ich mal und arbeite. Wie immer zusammen easy 34, das
9:52
geht irgendwann nicht mehr oder macht keinen Sinn, dass alle
9:54
denn auf den gleichen Bildschirm gucken.
9:56
Dann kommt ja quasi nen nen Overhead rein an
10:00
Organisationsaufwand. Ja.
10:03
Und der ist ja noch bei 4 Leuten überschaubar.
10:05
Ach, geht auch noch, aber irgendwann kommst du ja an den
10:08
Punkt und da sehe ich halt immer oder da bin ich, werde ich dann
10:11
quasi skeptisch, ob das wirklich noch schneller macht, dass das
10:15
ja alles organisiert werden muss.
10:17
Ja. Also.
10:19
Leute ja auch quasi integriert werden müssen.
10:22
Ne, also das ist halt auch wirklich n seh ich auch so.
10:25
Es ist n. Das ist auf jeden Fall einer der
10:28
Painpoints, die ich auch identifizieren würde, wenn es
10:31
darum geht zu sagen, man packt jetzt einfach nur mehr Leute
10:34
drauf. Also das das Witzige ist ja,
10:36
dass das ich das auf jeden Fall auch schon so, ich sag jetzt mal
10:40
aus. Manager Sicht gehört habe oder
10:45
zumindest mitgekriegt habe, dass es wohl Leute gibt im
10:48
Managementbereich, die vielleicht.
10:51
Diese Auffassung vertreten, dass man sagt, OK, wir haben jetzt
10:55
eine eine Anwendung, die entwickelt werden muss, und wir
10:57
haben jetzt zum Beispiel 4 Leute und diese 4 Leute sagen ja, wir
11:02
werden wahrscheinlich in einem Jahr damit fertig und von
11:05
Managementseite heißt es, naja, aber wäre jetzt schon wichtig,
11:08
dass wir in einem halben Jahr fertig werden, also was können
11:11
wir tun, und dann werden halt verschiedene Möglichkeiten
11:14
gesehen, die meiner Meinung nach dann nicht immer ganz mit dem
11:17
Resultat deckungsgleich sind, weil wenn man dann nämlich zum
11:20
Beispiel sagt, Ja gut. Man braucht ein Jahr mit 4
11:25
Leuten, also brauche ich ein halbes Jahr mit 8 Leuten.
11:27
Die Rechnung ist total einfach. Würde ich mich halt hinstellen
11:31
und sagen, das funktioniert so nicht.
11:32
Also da würde ich definitiv mich hinstellen und sagen, das kann
11:36
so genau nach dieser Rechnung eben nicht funktionieren.
11:39
Und da kommt halt kommen halt so Punkte wie du meintest ne sowas
11:43
wie n Overhead. Du hast Absprachen
11:45
untereinander. Du musst das ganze koordinieren.
11:49
Du musst vielleicht sogar angenommen, du ramst von 4
11:51
Leuten auf 8 Leute hoch, dann hast du ja quasi noch ein
11:55
Onboarding. Du hast ein
11:56
Einarbeitungsprozess, das heißt, du hast auf jeden Fall irgendwie
11:59
Overhead, der quasi irgendwie stattfindet und das.
12:02
Da würde. Ich halt sagen, dass Slow teilt
12:04
das Ganze zumindest entweder kurzzeitig runter, aber im
12:07
Endeffekt auch durch diesen ganzen Overhead, der entsteht
12:10
eben halt auch langfristig. So heißt nicht, dass es sich
12:16
runterslobt, dass man jetzt auf einmal langsamer wird, aber man
12:19
wird auf jeden Fall nicht doppelt so schnell, weil man
12:21
doppelt so viele Entwickler oder Entwicklerinnen quasi an ein
12:24
Projekt setzt. Ja, ich glaube, das ist auch.
12:27
Also ich war nie in der Position, sowas berechnen,
12:31
bestimmen zu müssen. Also ich will mich da auch nicht
12:33
zu weit aus dem Fenster lehnen, aber ich habe halt öfter schon
12:36
in der Vergangenheit das Gefühl gehabt, dass es so ist.
12:39
OK, du hast ne gewisse Manpower, ein Entwickler kostet dich im
12:43
Jahr so und so viel, der sagt Ich brauch n Jahr jetzt um dein
12:47
Beispiel noch mal aufzugreifen, dann sind das Kosten von ja
12:50
keine Ahnung x und wenn ich jetzt aber sage ich möcht es
12:54
aber halb so schnell haben, muss ich einfach die Kosten sozusagen
12:56
verdoppeln. Ich stell noch einen Entwickler
12:58
ein und dann kriege ich die Zeit gedrückt damit.
13:01
Also dein Beispiel fand ich ganz cool weil man hat oft das
13:04
Gefühl, dass irgendwie sowas im Hintergrund gerechnet wird, was
13:07
aber irgendwie in der Praxis nie aufgeht.
13:10
Ja, das mag zwar in der Theorie oder vielleicht auch vor der
13:13
Mathematik. Keine Ahnung, irgendwie.
13:15
Sinn machen, was da berechnet wird, aber in der Praxis habe
13:18
ich persönlich noch nicht erlebt, dass das 1 zu 1 so
13:21
aufgeht. Also weil zum Beispiel ein
13:24
Punkt, ich wollte dich nicht unterbrechen, aber ein Punkt,
13:27
den ich auch super wichtig finde, ist, es ist ja nicht nur
13:29
organisatorische Aufwand, der steigt.
13:31
Ich finde, es ist auch ein zunehmender Aufwand, diesen ein
13:36
Wissenstransfer herzustellen, definitiv also sowas wie.
13:40
Jeder weiß Bescheid, was passiert überhaupt in der
13:42
Software, weil Worst Case bilden sich kleine Inseln auf einmal
13:46
selbst innerhalb des Teams, weil ja die beiden machen immer das,
13:49
die beiden machen immer das, weil das war jetzt so die Woche
13:52
und da das läuft also weißt du die haben jetzt ihr wissen da
13:54
wenn wir jetzt noch mal tauschen würden, dann wären wir ja wieder
13:57
langsam. Das können wir jetzt auf keinen
13:58
Fall machen, also schön so wie es ist.
14:00
Das läuft gerade so und dann wenn die jetzt mal ganz blöd
14:04
davon ausgehst Fluktuation einer verlässt das Unternehmen oder
14:08
wird krank was man ja nie hofft aber kann ja passieren und dann
14:11
hast du halt so deine kleinen Heros auf deinen Inseln die
14:14
wegfallen und dann geht da gar nichts mehr weiter und dann
14:17
guckst dann guckt man halt richtig blöd auf gut Deutsch.
14:20
Du musst ja gar nicht so weit gehen, dass es um Krankheit geht
14:22
oder zum Beispiel um keine Ahnung, Abgänge.
14:25
Es reicht ja schon, wenn eventuell zu einem ungünstigen
14:29
Zeitpunkt bestimmte Personen gleichzeitig im Urlaub sind.
14:34
Ja, genau, das ist. Ein guter Punkt.
14:37
Klar, man kann versuchen, sich da mal abzustimmen, aber das
14:39
klappt ja auch nicht immer, ja, aber.
14:40
Das ist ja zum Beispiel auch n Punkt.
14:42
Wenn wir jetzt gerade also so n bisschen abdriften, aber
14:44
prinzipiell ist es ja nicht schlecht, wenn man genau auf
14:48
sowas achtet, also sowas zu vermeiden, dass man eben schafft
14:52
nen guten Wissenstransfer. Zu generieren, dass man quasi,
14:56
dass jeder zumindest einen guten Überblick hat und überall
14:59
mitarbeiten kann, was natürlich jetzt wieder für kleinere Teams
15:02
spricht oder zumindest nicht dafür spricht, dass man sagen
15:06
könnte, mehr Leute, schnellere Entwicklung oder doppelt so
15:10
viele Leute, doppelt so viel, doppelt so schnell Entwicklung.
15:14
Aber wenn man dann darauf achten kann, durch diesen guten
15:17
Wissenstransfer, den man hinkriegt, dann kann man ja sich
15:19
auch selber eigentlich ein sehr viel schöneres Arbeitsklima
15:22
schaffen. Wenn man dann zum Beispiel sagt,
15:24
Ich möchte dann in den Urlaub und dann heißt es vielleicht
15:26
sorry, aber das geht jetzt leider nicht.
15:29
Also da muss man auch immer überlegen, was springt für mich
15:33
dabei raus und gerade so was, wenn man das im Hinterkopf
15:35
behält und sagt Okay lass uns doch effizient vielleicht in den
15:38
kleineren Teams arbeiten, wo jeder sozusagen.
15:41
Auch n Guten ne wissensdurchmischung gut
15:45
stattfinden kann, dann schaffst du dir vielleicht doch einfach
15:48
ne schönere Perspektive für deine eigene Arbeit.
15:53
Ja, auf jeden Fall. Das ist eigentlich ein ganz
15:56
guter Punkt. Ich hätte aber noch einen
16:00
anderen. Also ich würde gerne noch ein
16:01
anderes Date, das geht jetzt in die andere Richtung, aber was
16:04
mir gerade noch dazu eingefallen ist.
16:07
Es ist ja nicht nur so, dass ein.
16:12
Ist wieviel quasi Organisation, also organisatorisches dazukommt
16:17
oder wieviel man denn noch wegarbeiten kann, sage ich mal.
16:21
Ich finde ein Punkt, der bei diesem ganzen Thema auch ne
16:23
riesen Rolle spielt. Ist ja, wie weit ist man
16:28
fortgeschritten im Projekt, um noch mal dein Beispiel
16:31
aufzugreifen, sagt man, wir brauchen ein Jahr, wenn man das
16:35
Projekt startet oder braucht man noch circa ein Jahr und steckt
16:39
schon ein 2 Jahre in der Entwicklung, also das heißt es
16:42
geht so irgendwann auf die Zielgeraden und man merkt wir
16:45
müssten jetzt doch ein halbes Jahr vorher releasen, also jetzt
16:50
doch noch mal schnell Leute einstellen, damit wir das
16:52
einhalten können, das finde ich sind auch 2 ganz ganz
16:55
unterschiedliche Sachen. Beispielsweise wenn ich gerade
16:59
dabei bin, ein Projekt zu starten und Abschätze wie viele
17:02
Entwickler brauche ich dafür und stellt dann zum Beispiel 4 Leute
17:06
ab aus der Firma, die daran arbeiten sollen, dann können die
17:09
sich ja von Grund auf quasi organisieren, dementsprechend
17:13
das Projekt aufbauen und ja quasi dann daran arbeiten.
17:17
Ganz anders sieht es ja aus, wenn du beispielsweise ja mit 2
17:23
Leuten schon 2 Jahre an etwas arbeitest.
17:25
Zu zweit schafft man in 2 Jahren jetzt auch schon einiges.
17:28
Das heißt, das ist auch nicht mehr so wenig, was da entstanden
17:31
ist. Definitiv.
17:32
Und dann heißt es so, Ah Jungs, wir haben nur noch n halbes Jahr
17:35
hier sind noch mal 2 Entwickler, jetzt seid ihr 4.
17:38
Jetzt macht es bitte in der Zeit fertig.
17:40
Weil ich mein, weißt du, worauf ich hinaus will?
17:42
Also ja, definitiv ja auch Gefahren mit sich, wenn ich da.
17:44
Kurz einhaken kann, das ist ja auch genau der Punkt, den du
17:47
auch schon so n bisschen angesprochen hattest oder
17:49
angeschnitten hattest. Es geht ja um was man immer hat.
17:54
Also es gibt 2 verschiedene. Also das hab ich auch selber
17:56
schon erlebt. Ne du fängst zum Beispiel bei
17:58
einem Projekt an, hab ich gemacht so richtig grüne Wiese
18:01
und man kann von vornherein richtig sagen OK es geht los,
18:04
lass uns mal hier richtig geil von vorne starten, wir haben
18:07
alles in der Hand. Das macht total Bock.
18:09
Kann ich auch jedem empfehlen, dass man das irgendwie auch mal
18:11
machen kann und das ist cool, das war quasi n Team von 6
18:15
Leuten, alle hatten Bock und ja war auf jeden Fall n fähiges
18:20
Team und das hat auf jeden Fall richtig gefloht das war geil.
18:22
Nichtsdestotrotz hast du am Anfang.
18:26
Diesen diesen Effekt, dass du sagst okay man muss erstmal so
18:29
eine gewisse Art von Teambuilding machen und zwar
18:32
guckst du erstmal okay wie sprich also was für
18:35
Konventionen, Absprachen trifft man am Anfang quasi explizit und
18:42
was passiert so implizit zum Beispiel du merkst irgendwann ja
18:45
okay der eine fängt dann und dann an, der andere fängt dann
18:47
und dann an, du kannst das irgendwann, also es gibt manche
18:50
Sachen, die du von vornherein richtig per Absprache regelst
18:53
und manche Sachen finden halt so unter der Hand irgendwann statt.
18:57
Und dann gibt es ja noch den anderen Punkt, und zwar sowas
18:59
wie zum Beispiel jetzt kommt jemand Neues in ein bestehendes
19:02
Team hinein, dann hast du ja dieses ganze Teambuilding, hast
19:06
du ja fertig, das heißt, du musst eigentlich diese eine
19:08
Person und. Beziehungsweise je nachdem, wie
19:10
viele denn dazu kommen, musst du ja sozusagen Druck beschallen
19:14
und dann kommt ja dazu ne wie du meintest, wenn du dieses, dieses
19:18
dieses ganze Teambuilding schon hast.
19:19
Die Leute können gut arbeiten, das läuft, das funktioniert, das
19:22
float. Aber wenn du jetzt zum Beispiel
19:24
sagst Verdoppelst das Team, dann hast du ja erstmal, je nachdem
19:28
wieviel du auch schon geschafft hast.
19:30
Das ist ja auch was du gerade meinst, musst du ja den ganzen
19:33
Leuten erstmal überhaupt, also nicht nur das fachliche, sondern
19:37
auch noch also fachliche übermitteln.
19:39
Was passiert hier, wie läuft das gerade, sondern zusätzlich auch
19:42
noch, wie arbeiten wir hier eigentlich im Team?
19:44
Und dann kann es ja wieder zu Konflikten kommen, weil
19:47
vielleicht zum Beispiel jemand ganz, ganz anders arbeitet, als
19:50
man das vielleicht irgendwie so im Flow schon geschafft hat.
19:54
Und da kann es dann halt auch noch mal zu Konflikten
19:57
beziehungsweise auch Verzögerungen kommen.
19:59
Das war mir jetzt noch mal so wichtig, dass auch noch mal so
20:02
mit in den Raum zu werfen, weil das habe ich beides schon
20:04
erlebt, zum einen neu anzufangen, ein Projekt sowie
20:09
jemand kommt dazu, aber auch ich gehe in ein neues Team rein.
20:14
Ja, so ne. Also.
20:17
Das ist auf jeden Fall, ja, das ist das, finde ich.
20:20
Also die Erfahrung habe ich auch gemacht, das ist ja im Prinzip,
20:23
wenn du sehr fortgeschritten bist in deinem Projekt und dann,
20:25
dann kommen neue Leute dazu. Musst du ja Entwickler abstellen
20:31
um quasi die neuen Entwickler zu onboarden.
20:35
Das heißt zu erklären, wie sieht denn die Infrastruktur aus, was
20:39
macht das Produkt überhaupt, weil es ist ja nicht so, du
20:42
kommst in der ersten Tag irgendwo in ein Team.
20:44
Was macht dir xy alles klar, bin dabei, gib her wo ide ich habe
20:48
meinen Rechner schon mit, der ist da schon alles eingerichtet,
20:50
wir können loslegen. So läuft es ja nicht.
20:54
Getrunken. Keine Witze, wenn jemand trinkt.
21:02
Aber es ist ja doch eher so, dass man erstmal quasi so ein
21:06
Onboarding macht. Was machen wir hier, was ist das
21:09
Ziel, was ist der Projektplan zum Beispiel, also je nachdem,
21:13
wie agil das Ganze läuft und. Dauert das doch, bis so ein
21:18
neuer Entwickler seine Manpower wirklich einbringen kann.
21:22
Zusätzlich wird die Manpower eines bestehenden Entwicklers
21:26
reduziert, weil er sich ja um den Neuen kümmern muss, was ja
21:29
auch richtig ist. Keine Frage, ist ja nicht.
21:31
Damit nicht sagen, Lass den im Regen stehen, der wird schon
21:34
irgendwann klarkommen. Das ist natürlich auch Quatsch,
21:36
aber du musst ja trotzdem mal ehrlich sein und sagen, der
21:40
Entwickler kann erstmal nicht in voller Leistung
21:44
weiterentwickeln. Ja und dann ist die Frage,
21:47
rentiert sich das hinten raus, wenn dann beide quasi wieder
21:51
dran arbeiten können, würden ja jetzt viele sagen ja auf jeden
21:55
Fall ich meine eine Woche einarbeiten, danach 2 Leute die
21:57
durcharbeiten aber das ist ja nicht gegeben, dass es so läuft
22:01
plus. Gesagt haben, dieser
22:03
organisatorische Aufwand, irgendwann musst du ja Leute
22:06
abstellen, die nur noch managen. Und dann fällt diese Leistung
22:10
auch wieder weg und ich finde, dann kommt man relativ schnell
22:13
in den Hamsterrad und Frust kommt auf.
22:17
Zum Beispiel angenommen Du bist ein Entwickler von also
22:20
Vollblutentwickler und auf einmal bist du mehr mit
22:23
organisatorischen Themen beschäftigt als zu entwickeln,
22:26
dann dann kommen ja auch so Frust Faktoren schnell ins
22:28
Spiel. Gut unterbinden muss also
22:31
unterbinden im Sinne von irgendwie lösen muss und das
22:34
sind das ist halt so er das kann halt ein richtiger Teufelskreis
22:37
werden. Aber man sagt ja auch, es gibt
22:40
ja auch. So ein Spruch, der da heißt, so
22:44
bevor es sag ich mal schneller wird, wird es erstmal auf jeden
22:47
Fall langsamer und ich glaube zwar schon, dass man sagen kann,
22:50
also in unserem Beispiel unserem Szenario, dass wir gerade mal so
22:53
ein bisschen gebildet haben, dass man sagt, okay, man möchte
22:56
jetzt zum Beispiel aus einem Team von 4 Leuten, das möchte
22:59
man vielleicht verdoppeln, weil noch mehr Sachen zu tun sind,
23:03
dann würde ich sagen, ist am Anfang definitiv erstmal Fakt,
23:07
dass die der Fortschritt der Entwicklung.
23:11
Was auch immer da entwickelt wird, sagen wir mal irgendeine
23:13
Software n Produkt wird erst mal langsamer und danach kann ich
23:17
mir durchaus vorstellen, dass zum Beispiel von wenn du von 4
23:19
auf 8 Personen gehst, dass es danach sozusagen schneller
23:23
voranschreitet. Das heißt, die Entwicklung kann
23:25
durchaus schneller werden, ich würde aber nicht sagen, wenn du
23:29
jetzt zum Beispiel von 4 auf 8 Personen gehst, dass du dann
23:32
sozusagen deine Entwicklungszeit halbierst.
23:34
Das ist zum Beispiel, das sind 2 Punkte, die ich, glaube ich,
23:37
einfach mal so jetzt in den Raum stellen würde und sagen würde,
23:41
ich vermute, das ist so. Aber das ist, das ist wirklich
23:45
eigentlich schon fast eine coole Zusammenfassung von dem, was wir
23:49
besprochen haben, weil natürlich, wenn ich mehr
23:52
Entwickler habe und das irgendwann eingespielt ist und
23:55
jeder einen guten Job macht, kriege ich ja mehr Manpower
23:59
zusammen und kann schneller entwickeln.
24:01
Die Frage ist aber beziehungsweise das Problem an
24:04
der ganzen Sache ist, dass sowas ja oft entschieden wird, wenn
24:08
Not am Mann ist, also sprich Zeitdruck aufkommt.
24:12
Und wie du schon meintest, man wird erst langsamer um dann
24:15
schneller zu werden. Ist ja quasi gegeben dadurch was
24:18
was ich zum Beispiel gerade meinte mit dem Einarbeiten, dass
24:21
du erstmal Leute abstellen musst um neue Leute einzuarbeiten, das
24:25
ist ja quasi die, also daraus resultiert.
24:27
Ja, dass man langsamer wird. Und meistens ist es so, bevor
24:31
man dann richtig Fahrt aufnehmen kann, ist die Deadline doch dann
24:34
schon gerissen. Ja, also das ist ja genau der
24:37
Punkt, man ist da nicht im halben Jahr fertig, nein,
24:39
vielleicht ist man auch nicht viel schneller als ein Jahr wie
24:42
es ursprünglich war. Man muss dann halt langfristiger
24:44
denken und sich also sich überlegen.
24:46
OK, aber wenn ich diese Leute dabei hab, kann es zukünftig
24:50
schneller werden. Ja, aber ich glaube auch nicht,
24:53
dass du das linear sehen kannst im Sinne von na ja, jetzt 2 und
24:57
dann sind wir. Also doppelt so schnell.
24:59
Ja, das funktioniert halt auf keinen Fall meiner Meinung nach,
25:03
nee. Also das denke ich auch, dass
25:04
Lini also linear wird es nicht sein.
25:06
Ich würde auch sagen, dass es irgendwann einen Punkt gibt, wo
25:09
es wieder schlimmer wird, deswegen würde ich auch zum
25:11
Beispiel schon sagen. Eine gewisse Anzahl teamgröße,
25:16
da sollte nicht unbedingt überschritten werden.
25:18
Wenn man sich jetzt hinstellt und sagt, Na ja, komm, aber wir
25:20
haben jetzt zum Beispiel n weiß nicht n Riesen.
25:24
Projekt, wo ganz viele Leute mitarbeiten.
25:27
Dann würde ich wahrscheinlich vorschlagen zu sagen, OK, dann
25:31
versuchen wir das in einzelne Module zu unters unterteilen,
25:35
sodass man halt sagt, man hat wieder kleinere Teams, die
25:38
miteinander arbeiten können und der, ich sag mal die
25:41
Schnittstelle zwischen den Teams sollte möglichst gering bzw
25:44
möglichst leichtgewichtig. Sein aber.
25:48
Ist ja quasi auch der agile Ansatz, der ja auch in vielen
25:52
Unternehmen verfolgt wird zu sagen, OK, wir haben wieder
25:55
kleinere Teams, zum Beispiel Scrum Teams, ja die dann halt
25:58
wirklich. Super effizient an ihren Themen
26:02
arbeiten können und. Dann sind das umgesetzt werden
26:05
kann. Das ist meine.
26:06
Frage, Da hatten wir auch ne Folge zugemacht.
26:08
Da steht wieder auf einem anderen Blatt, aber das ist ja
26:10
der Sinn dahinter im Prinzip und dann müssen halt die
26:13
Schnittstellen, wie du schon gesagt hast leichtgewichtig
26:16
gehalten werden. Zu dem ganzen Thema gibt es ganz
26:21
witzig wusste ich nicht. Das ist ein bisschen
26:24
recherchiert worden jetzt von uns.
26:27
Fand ich ganz witzig, gibt es ja das sogenannte Brooksche Gesetz,
26:32
was ja im Endeffekt besagt, dass wenn man.
26:36
Quasi Manpower zu einem Projekt, was schon verspätet ist,
26:40
hinzufügt, dass es dann noch später wird.
26:42
Und das deckt sich halt eigentlich ganz geil mit dem,
26:45
was wir hier quasi besprochen haben, weil das auch einfach
26:48
unsere Erfahrung ist. Also es ist keine Lösung zu
26:51
sagen, Oh, wir haben Zeitdruck, jetzt alle Leute da drauf, dann
26:55
dann bremst du dich selbst komplett auf 0.
26:57
Quasi dieses edding menpower to late project, make up make it
27:02
even later. Ich find, das klingt homo,
27:04
klingt so schön auf Englisch irgendwie, aber ich fand es auch
27:08
cool. Also wir haben jetzt kurz vor
27:09
der Folge, irgendwie sind wir drauf gestoßen, fand ich auch
27:13
irgendwie super interessant, das ist überhaupt solche Gesetze
27:15
gibt finde ich halt schon witzig.
27:18
Aber ich würd prinzipiell glaub ich in dem ganzen Zusammenhang
27:21
sagen, es ist also so. Zusammengefasst würd ich sagen
27:25
es ist gut, also Teams nicht zu groß zu halten, das heißt
27:30
möglichst n kleinen Rahmen abzustecken.
27:35
Ich würde so weit gehen, dass man sagt, wenn man ein größeres
27:37
Team bis zu einem bestimmten Rahmen, wie ich gerade meinte,
27:40
hat, dann kann man die Entwicklung auch erhöhen, also
27:44
die Entwicklungszeit verkürzen, dass man halt die
27:47
Geschwindigkeit erhöhen, dass man halt eben sagt, Okay nehmen
27:51
wir 6 Entwickler, sind wir schneller als 2 Entwickler, wenn
27:54
man damit startet, beispielsweise wenn man aber
27:57
jetzt zum Beispiel sagt Okay, um das noch ein bisschen
27:59
zusammenzufassen, wir sind mitten im Projekt und wollen
28:02
jetzt auf einmal mehr Leute hinzufügen, dann kann es halt
28:05
dazu kommen, dass man, bevor man schneller wird, doch erstmal
28:07
langsamer wird, wenn man sich wie gesagt in dem Rahmen eines.
28:11
Kleinen, kleinen Teams bewegt. Und was würdest du jetzt
28:17
abschließend sagen? Mehr Entwickler machen das
28:21
Projekt schneller. Mythos oder Fakt?
28:23
Ich würde sagen, it depens it. Also wenn man jetzt davon
28:29
ausgeht, dass man sagt, OK, für jeden Entwickler oder
28:33
Entwicklerin, die man ins Team hinzufügt, hast du quasi einen
28:36
linearen Anstieg der Geschwindigkeit.
28:38
Wenn man das sieht würde ich sagen, ist es absolut ein Mythos
28:42
und kann man so nicht rechnen, kann man so nicht sehen, wenn
28:45
man aber davon ausgeht zu sagen, wir nehmen eine vielleicht
28:48
maximale Teamgröße und gehen davon aus, dass wir von dem
28:52
Projekt anfangen. Hatten kann man in gewissen
28:56
Grenzen sagen. OK, mehr Leute können eine
28:59
schnellere Geschwindigkeit bringen, aber nicht linear würde
29:02
ich sagen. Ja, gehe ich mit.
29:04
Also für mich ist es auch mehr ein Mythos als n.
29:06
Fakt. Ja.
29:09
Aber wie gesagt, klar, wenn ich alleine bin und noch ne zweite
29:12
Person bekomme, gerade so am Projekt anfangen, macht das auf
29:16
jeden Fall viel schneller und dann skaliert das bis zu einem
29:18
gewissen Punkt haben wir ja besprochen, bin ich ganz bei
29:20
dir, nur dass das immer linear funktioniert ist für mich auch
29:24
ein absoluter Mythos, das glaube ich nicht und ich?
29:26
Glaube, dass viele Leute, die diese Gedanken anstellen, und da
29:32
stelle ich jetzt mal ganz frech, würde ich einfach sagen, so okay
29:37
ich glaube, dass einige denken, dass es so ist.
29:41
Na ja, das war jetzt schon ganz schön frech.
29:45
Wenn man sagen. Hören.
29:50
Sagen. Ja, ich würd sagen.
29:52
Liebe Zuhörerin, lieber Zuhörer. Teil uns doch gerne mal deine
29:55
Meinung mit. Vielleicht hast du auch ähnliche
29:57
Erfahrungen gemacht oder auch vielleicht komplett
29:59
gegensätzliche und hast festgestellt, ja mehr Leute und
30:03
alles ging völlig durch die Decke von der Geschwindigkeit
30:06
her, dann schreib uns doch gerne und melde dich bei uns entweder
30:10
auf den anderen Plattformen oder per Mail die links findest du
30:14
wie immer in den Shownotes würde uns auf jeden Fall sehr
30:16
interessieren, vielleicht bist du auch im Projektmanagement
30:21
tätig und weißt wie solche Sachen genau berechnet werden,
30:24
vielleicht werden da ja noch gewisse Faktoren berücksichtigt,
30:26
wäre auf jeden Fall auch mal sehr spannend zu erfahren also.
30:30
Sagt, melde dich gerne bei uns. Ansonsten hoffen wir dir hat die
30:34
Folge gefallen. Unser kleiner Talk über Mythos
30:37
oder Fakt im Sinne von mehr Entwickler, schnellere
30:40
Entwicklung. Und ansonsten macht ihr noch
30:43
einen schönen Tag. Wir hören uns beim nächsten Mal
30:45
wieder deine Coding Buddies. Gemeinsam besser.