CD Projekt RED: Kritik von IGDA zur Crunch-Aussage des Studios

[4P|BOT2]

Die International Game Developers Association (IGDA) hat nach einem Bericht von Gamedaily.biz offen Kritik an der Aussage von CD Projekt RED geäußert, wonach das Team im Rahmen des Crunch immer noch zahlreiche Überstunden leisten müsse, um trotz der kürzlich kommunizierten Verschiebung den neuen Releasetermin einhalten zu können."Ein Studios, das so extrem erfolgreich ist wie CDPR, sollte hoffentl...

Hier geht es zur News CD Projekt RED: Kritik von IGDA zur Crunch-Aussage des Studios

[Ribizli]

Mein Gott egal wie groß und erfolgreich ein Unternehmen ist, in jedem Projekt gibt es zum Ende Crunch Phasen. Nicht nur bei Entwicklern. Die Frage hier ist eher wie CDPR das kompensiert (Gute Bezahlung für Überstunden, Erholungsphase nach dem Projekt etc.). Und das die das hier so offen kommuniziert haben ist auch eher positiv zu sehen als den Crunch eher zu verheimlichen wie so ziemlich alle anderen Entwickler.

[Temeter]

Mein Gott egal wie groß und erfolgreich ein Unternehmen ist, in jedem Projekt gibt es zum Ende Crunch Phasen

Nö. Für gewöhnlich wird Crunch als ineffizient und in vieler Hinsicht teuer eingeschätzt.

[R_eQuiEm]

Mein Gott egal wie groß und erfolgreich ein Unternehmen ist, in jedem Projekt gibt es zum Ende Crunch Phasen

Nö. Für gewöhnlich wird Crunch als ineffizient und in vieler Hinsicht teuer eingeschätzt.

Korrekt. Also schießen sie sich ins eigene Knie. Jetzt ist die Frage woran liegt das? Ist Crunch zu einem gewissen Grad gar nicht zu verhindern? Oder ist das Management eines fast jeden großen Entwicklerstudios meist unfähig?

[Temeter]

Mein Gott egal wie groß und erfolgreich ein Unternehmen ist, in jedem Projekt gibt es zum Ende Crunch Phasen

Nö. Für gewöhnlich wird Crunch als ineffizient und in vieler Hinsicht teuer eingeschätzt.

Korrekt. Also schießen sie sich ins eigene Knie. Jetzt ist die Frage woran liegt das? Ist Crunch zu einem gewissen Grad gar nicht zu verhindern? Oder ist das Management eines fast jeden großen Entwicklerstudios meist unfähig?

Schätze mal, das inkompetente Planung oder unrealistische Zielsetzungen der Chefetage viel damit zu tun haben. Die meisten CEOs in der Spieleindustrie haben absolute keine Ahnung von Spielen.

Ansonsten aber KA, was genau das Problem bei denen ist.

[Liesel Weppen]

Korrekt. Also schießen sie sich ins eigene Knie. Jetzt ist die Frage woran liegt das? Ist Crunch zu einem gewissen Grad gar nicht zu verhindern? Oder ist das Management eines fast jeden großen Entwicklerstudios meist unfähig?

Ich arbeite selbst in der Softwareentwicklung und Crunch gibts da überall, nicht nur in der Spieleentwicklung.
Das ganze ist ein Prinzipproblem. Es muss irgendwelche Deadlines geben (egal ob das jetzt Release oder für ein Update oder einfach nur Milestones für bestimmte Features sind), die braucht das Management einfach. Ohne solche Deadlines würde man nie "fertig" werden. Der Knackpunkt ist den Termin der Deadline und der gewünschten Features abzustimmen. Wenns gut läuft ist das synchronisiert, dann passt die verfügbare Zeit bis zur Deadline und der Arbeitsaufwand für die Features zusammen. Das tritt aber so praktisch nie ein.

Softwareentwicklung ist etwas komplexer als z.B. Mauern. Beim Mauern kann man relativ einfach ermitteln, das man 100 Steine pro Minute schafft und der Architekt genau ausrechnen, das 1Mio Steine benötigt werden, daraus kann man sehr genau ausrechnen, wanns denn fertig sein wird. Bei der Softwareentwicklung stößt man aber dauernd auf Probleme. Die Steine passen hier und da nicht und der Architekt ändert während schon gemauert wird laufend den Bauplan und dem Manager fällt ein, das man zum Haus ja auch noch eine Garage braucht. Das das zeitlich nicht passt, wissen die auch. Dafür lässt man halt (erstmal) die Terrasse weg. Kurz darauf merkt man dann aber, das man ohne die Terasse auch den Swimmingpool nicht umsetzen kann, der ist aber selbstverständlich unverzichtbar....

Am Ende hast du dann eine Deadline und ein Featureset, das halt gehalten werden "MUSS".
Es ist jetzt so eine generelle Managementkrankheit, das wenn der Termin verschoben werden würde, dann kann man ja auch noch dieses und jenes Feature reinpacken, man hat ja jetzt doch wieder mehr Zeit. Die Verlängerung reduziert den Crunch also nur zum Teil (manchmal auch gar nicht). Und wenn irgendwas mal eine Woche früher schon fertig sein sollte, dann wird der Termin ja auch nicht zurückgelegt, sondern dann hat man ja noch eine Woche Zeit irgendwas einzubauen, das eigentlich nicht geplant war. Das das dann aber auch wieder Testing und Bugfixing braucht, wird meist "vergessen". Also baut man mit nur einer Woche Zeit etwas ein, für das man eine Woche Entwicklung veranschlagt hat. Am Donnerstag merkt man dann, das man ja auch noch Testen und Bugfixen muss. Das schafft man dann aber nicht mehr in der regulären Arbeitszeit, das muss dann also am Wochenende passieren.
Dabei gilt auch, das Testing und Bugfixing grundsätzlich nie fertig wird. Du kannst in einem bestimmten Zeitraum nur so und so viele Bugs fixen. Und du kannst beim Testing unmöglich vorher abschätzen, wann, ob oder wie schwerwiegende Fehler gefunden werden. Es kann sein, das man erst 2 Tage vor Release einen Gamebreaking-Bug findet und wenn der kompliziert ist, kann man das ggf. einfach nicht in 2 Tagen "regulärer Arbeitszeit" fixen. Was machst du jetzt? Crunch? Termin verschieben? Mit schwerwiegendem Bug releasen?

Aus Softwareentwicklersicht kann man einen Termin also nicht halten können, weils schlicht und einfach nicht auf den Punkt planbar ist. Da könnte man bestenfalls ein ungefähres Datum angeben, der Rest ist dann halt "wenns fertig ist". Aber erklär das mal nem Manager. Und dann landet man wieder in der oben beschriebenen Spirale.

Ich bin aktuell auch schon wieder in der dritten Verlängerung. Und es fällt dem PM in der Phase ein, wir müssen etwas ändern, das schon die ganze Zeit funktioniert, aber man halt jetzt gemerkt hat, das man es doch anders haben will (WILL, nicht UNBEDINGT BRAUCHT!). Wie kann man sich da dann auch noch wundern, wenn die Termine nicht klappen...

Fazit, wenn Häuser so gebaut werden würden, wie man Software macht, würde da kein Mensch einziehen, weil das fertige Haus wegen Fehlplanung einsturzgefährdet wäre.

https://pbs.twimg.com/media/A8ZfAk0CAAEpTcY.png

[Sir_pillepalle]

Das wird bestimmt alles besser mit agilen Methoden, oder SCRUM, oder OKRs, oder...

Verantwortliche und entscheidungsbefugte Positionen sind zu einem erschreckenden Teil mit Personen besetzt, die mit IT und Software- bzw. Systementwicklung wenig bis nichts am Hut haben.

[NewRaven]

Nö. Für gewöhnlich wird Crunch als ineffizient und in vieler Hinsicht teuer eingeschätzt.

In Relation zu was? Zu den normalen Entwicklungsphasen? Sicherlich. In Relation zu den Kosten einer Verschiebung der Projektfertigstellung? Nope. Sonst gäbe es diese Crunchphasen nicht.

Ohne Crunch jetzt gutzuheißen, aber jeder der an Projekten, völlig unabhängig davon ob das nun überhaupt die Softwareproduktion ist, arbeitet, insbesondere in Kooperation mit anderen Firmen oder Institutionen, kennt "Crunch" (wenn auch ggf. unter anderem Namen), weil es in diesem Fall eben immer Fristen gibt. Ob das nun eine Großbaustelle, ein Eventplaner oder ein Spieleentwickler ist. Das ist nichts Gutes, aber auch absolut kein Problem, dass für die Spielbranche, in der das Thema in letzter Zeit ständig und leider auch einzig hochkocht, spezifisch wäre, ich würde sogar behaupten, dass manch andere davon weit mehr, weil viel regelmäßiger, betroffen sind als Spieleentwickler. Die Kritik wäre also meiner Meinung nach "allgemeingültig" viel besser aufgehoben als wenn man sich da jetzt immer diesen oder jenen Spieleentwickler als schwarzes Schaf für etwas raus pickt, dass fast alle tun. Überall.

[johndoe711686]

Softwareentwicklung ist etwas komplexer als z.B. Mauern. Beim Mauern kann man relativ einfach ermitteln, das man 100 Steine pro Minute schafft und der Architekt genau ausrechnen, das 1Mio Steine benötigt werden, daraus kann man sehr genau ausrechnen, wanns denn fertig sein wird. Bei der Softwareentwicklung stößt man aber dauernd auf Probleme. Die Steine passen hier und da nicht und der Architekt ändert während schon gemauert wird laufend den Bauplan und dem Manager fällt ein, das man zum Haus ja auch noch eine Garage braucht. Das das zeitlich nicht passt, wissen die auch. Dafür lässt man halt (erstmal) die Terrasse weg. Kurz darauf merkt man dann aber, das man ohne die Terasse auch den Swimmingpool nicht umsetzen kann, der ist aber selbstverständlich unverzichtbar....

Das könnte auch von einer Baustelle geschrieben sein, denn auch wenn mauern an sich simpel ist, gibt es ja kaum Baustellen die pünktlich fertig werden. Ganz so einfach ist es da offenbar auch nicht.

[R_eQuiEm]

Spoiler

Show

Korrekt. Also schießen sie sich ins eigene Knie. Jetzt ist die Frage woran liegt das? Ist Crunch zu einem gewissen Grad gar nicht zu verhindern? Oder ist das Management eines fast jeden großen Entwicklerstudios meist unfähig?

Ich arbeite selbst in der Softwareentwicklung und Crunch gibts da überall, nicht nur in der Spieleentwicklung.
Das ganze ist ein Prinzipproblem. Es muss irgendwelche Deadlines geben (egal ob das jetzt Release oder für ein Update oder einfach nur Milestones für bestimmte Features sind), die braucht das Management einfach. Ohne solche Deadlines würde man nie "fertig" werden. Der Knackpunkt ist den Termin der Deadline und der gewünschten Features abzustimmen. Wenns gut läuft ist das synchronisiert, dann passt die verfügbare Zeit bis zur Deadline und der Arbeitsaufwand für die Features zusammen. Das tritt aber so praktisch nie ein.

Softwareentwicklung ist etwas komplexer als z.B. Mauern. Beim Mauern kann man relativ einfach ermitteln, das man 100 Steine pro Minute schafft und der Architekt genau ausrechnen, das 1Mio Steine benötigt werden, daraus kann man sehr genau ausrechnen, wanns denn fertig sein wird. Bei der Softwareentwicklung stößt man aber dauernd auf Probleme. Die Steine passen hier und da nicht und der Architekt ändert während schon gemauert wird laufend den Bauplan und dem Manager fällt ein, das man zum Haus ja auch noch eine Garage braucht. Das das zeitlich nicht passt, wissen die auch. Dafür lässt man halt (erstmal) die Terrasse weg. Kurz darauf merkt man dann aber, das man ohne die Terasse auch den Swimmingpool nicht umsetzen kann, der ist aber selbstverständlich unverzichtbar....

Am Ende hast du dann eine Deadline und ein Featureset, das halt gehalten werden "MUSS".
Es ist jetzt so eine generelle Managementkrankheit, das wenn der Termin verschoben werden würde, dann kann man ja auch noch dieses und jenes Feature reinpacken, man hat ja jetzt doch wieder mehr Zeit. Die Verlängerung reduziert den Crunch also nur zum Teil (manchmal auch gar nicht). Und wenn irgendwas mal eine Woche früher schon fertig sein sollte, dann wird der Termin ja auch nicht zurückgelegt, sondern dann hat man ja noch eine Woche Zeit irgendwas einzubauen, das eigentlich nicht geplant war. Das das dann aber auch wieder Testing und Bugfixing braucht, wird meist "vergessen". Also baut man mit nur einer Woche Zeit etwas ein, für das man eine Woche Entwicklung veranschlagt hat. Am Donnerstag merkt man dann, das man ja auch noch Testen und Bugfixen muss. Das schafft man dann aber nicht mehr in der regulären Arbeitszeit, das muss dann also am Wochenende passieren.
Dabei gilt auch, das Testing und Bugfixing grundsätzlich nie fertig wird. Du kannst in einem bestimmten Zeitraum nur so und so viele Bugs fixen. Und du kannst beim Testing unmöglich vorher abschätzen, wann, ob oder wie schwerwiegende Fehler gefunden werden. Es kann sein, das man erst 2 Tage vor Release einen Gamebreaking-Bug findet und wenn der kompliziert ist, kann man das ggf. einfach nicht in 2 Tagen "regulärer Arbeitszeit" fixen. Was machst du jetzt? Crunch? Termin verschieben? Mit schwerwiegendem Bug releasen?

Aus Softwareentwicklersicht kann man einen Termin also nicht halten können, weils schlicht und einfach nicht auf den Punkt planbar ist. Da könnte man bestenfalls ein ungefähres Datum angeben, der Rest ist dann halt "wenns fertig ist". Aber erklär das mal nem Manager. Und dann landet man wieder in der oben beschriebenen Spirale.

Ich bin aktuell auch schon wieder in der dritten Verlängerung. Und es fällt dem PM in der Phase ein, wir müssen etwas ändern, das schon die ganze Zeit funktioniert, aber man halt jetzt gemerkt hat, das man es doch anders haben will (WILL, nicht UNBEDINGT BRAUCHT!). Wie kann man sich da dann auch noch wundern, wenn die Termine nicht klappen...

Fazit, wenn Häuser so gebaut werden würden, wie man Software macht, würde da kein Mensch einziehen, weil das fertige Haus wegen Fehlplanung einsturzgefährdet wäre.

https://pbs.twimg.com/media/A8ZfAk0CAAEpTcY.png

ok. ich habe es mir im Grunde auch so vorgestellt. Der Vergleich mit Häuserbau macht es zwar ansehnlicher, aber im Grunde kann man es nicht vergleichen.
Die Frage die sich mir stellt ist jetzt ob es überhaupt möglich ist Crunch in der Softwareentwicklung zu eliminieren, oder ob man es quasi nur bessern kann. Gerade eine Arbeit wie diese baut sich ja auf soviele Steine auf, die jeweils von so vielen unterschiedlichen Arbeitsprozessen begleitet und abhängig ist, das ich mir schwer tue ein Lösungsbild zu schaffen. Insbesondere wenn Projekte dann solche Ausmaße haben wie die eines Cyberpunks 2077. Da gerade bei euch in der Branche Arbeitsprozesse auf verschiedene Teams auf der ganzen Welt aufgeteilt werden können und das auch so gehandhabt wird, macht es das für mich nur noch komplexer.
Interessant wäre eine halbwegs seriöse Statistik die AAA-Entwickler sowie Indiestudios beinhaltet, die Crunchphasen ermittelt und in ihrem Verhältnis halbwegs akkurat gegenüberstellt. Wenn das überhaupt möglich ist. Gefunden habe ich nichts dergleichen im Netz.
Das einzige Interessante war eine kleine Umfrage seitens Kotaku die 2016 veröffentlicht wurde, die eine ziemlich interessante und differenzierte Sicht auf die Szene blicken lässt. https://kotaku.com/crunch-time-why-game ... 1704744577

Sollte dieser Artikel schon allseits bekannt sein, verzeiht meine Unwissenheit. Ich lese mich erst jetzt gerade ein bisschen detaillierter in die Thematik ein.

[johndoe711686]

Problem daran ist auch, dass wenn die Teile die vor den Entwicklern liegen länger brauchen, nicht etwa der Termin nach hinten rutscht, nein, man hat dann eben weniger Zeit für das gleiche...

[Kajetan]

Ist Crunch zu einem gewissen Grad gar nicht zu verhindern?

Es kommt darauf an. Wenn Deine Auftraggeber bei einem gleichbleibenden Zeitrahmen ständige Änderungswünsche haben, kannst Du mit entsprechenden Projektmanagementmethoden im verfügbaren Zeitrahmen zwar viel erreichen, aber Crunch letztlich nicht vollkommen verhindern. Da wird dann halt gegen Schluss nochmal so richtig rangeklotzt, mit Schlafsack unterm Bürotisch usw. Aber das nicht über Monate hinweg, oder gar als Dauerzustand, sondern maximal wenige Wochen. Gute Projektmanager haben in erster Linie das Talent den Auftraggeber, den Kunden im Zaum zu halten, dem Team den Rücken freizuhalten, damit man dort in Ruhe arbeiten kann. Damit es gar nicht erst zu Crunch kommen muss.

Oder ist das Management eines fast jeden großen Entwicklerstudios meist unfähig?

Ja, manchmal ist man dort einfach inkompetent, verrennt sich in Feature Creep, verzettelt sich, bleibt ständig an kleinen Details hängen und verliert den Blick für's Ganze. Ganz alleine. Ohne den Druck Dritter, ohne Publisher, der seine Releasetermine auch nicht immer frei Schnauze festlegen kann.

Manchmal ist es auch eine Firmentradition haufenweise Überstunden zu machen, weil man das schon immer so gemacht hat, die Geschäftsführung es nie anders kennengelernt hat und Crunch dummerweise Teil der Firmenkultur geworden ist. Das scheint wohl bei CDP und Rockstar teilweise der Fall zu sein. Wo die Geschäftsführer noch von den Jahren träumen, wo sie mit ein paar anderen Veteranen in irgendeiner Bruchbude saßen und auf Teufel komm raus ihr Ding fertiggestellt haben. Dass man heute so gar nicht mehr arbeiten muss, dass man, entsprechende Projektmanagementmethoden vorausgesetzt, mit weniger (!) Arbeitsstunden vergleichsweise mehr (!) Arbeit fertigstellen kann ... das dringt nur schwer in die Köpfe dieser Leute.

[Kajetan]

Das wird bestimmt alles besser mit agilen Methoden, oder SCRUM, oder OKRs, oder...

Mein Geschäftsführer, das geplante Treffen konnte nicht abgehalten werden, ScrumMaster Steiner konnte nicht genug erforderliche Teammitglieder versammeln ...

[Liesel Weppen]

ok. ich habe es mir im Grunde auch so vorgestellt. Der Vergleich mit Häuserbau macht es zwar ansehnlicher, aber im Grunde kann man es nicht vergleichen.

Ist ja auch bewusst vereinfacht, um es verständlicher zu machen.

Die Frage die sich mir stellt ist jetzt ob es überhaupt möglich ist Crunch in der Softwareentwicklung zu eliminieren, oder ob man es quasi nur bessern kann.

Naja, es gibt nur zwei Möglichkeiten Crunch komplett zu vermeiden:
1) Überhaupt keinen Releasetermin setzen
2) Den Releasetermin so setzen, das er zum Featureset passt und genug Zeit für Testing und Bugfixing enthält und dabei
2a) hoffen, das beim Testing und Bugfixing kein Klopper kommt, der den Zeitrahmen doch wieder sprengt
2b) sollte man wieder erwarten früher "fertig" werden, trotzdem keine neuen Features (für den Release) oder sowas mehr anfangen, sondern es einfach gut sein lassen, den Release sogar vorziehen, oder einfach noch mehr testen.

Das ist halt nur so in der Wirtschaft meist nicht praktikabel, weil das würde ja Geld kosten, das sogesehen aber keinen Mehrwert bringt.

[oc1d]

Das Problem:

1. Publisher wollen meistens einen Milestone-Plan, der alles schon von vorn herein durchdekliniert. Das gibt denen eine Vermeintliche "Sicherheit" (Old-School)
2. Software Entwicklung ist extrem komplex und beinhaltet sehr viele Risiken und Unsicherheiten , man weiss am Anfang einfach noch nicht was man wirklich machen will. Man findet das erst beim Machen heraus. Insbesondere der Spass an einem Spiel muss so gefunden werden. Dafuer gibt es morderne Methoden wie SCRUM oder generell agile Methoden, die, zumindest fuer eine gewisse Zeit (bis alle Unsicherheiten eliminiert sind) eingesetzt werden sollten. Mit Agilen Methoden geht ein gewisses Kulturverstaendnis einher: Leute arbeiten selbstorganisiert und ihnen sollte viel Vertrauen entgegen gebracht werden.
3. Leider denken viele Studios noch nicht modern und haben, salopp ausgedrueckt, keine Ahnung was es heisst agil zu arbeiten.
4. Insbesondere in Leitungspositionen ist so etwas wie eine Ausbildung oder Grundwissen in agilen / modernen Methoden ein Fremdwort und das Personal wird auch nicht entsprechend geschult. Man macht meistens eine Mischform, ohne wirklich nach einem bestimmtem Prinzip vorzugehen.
5. wegen 3. und 4. klappt das aber nicht so richtig und am Ende wird Micromangement betrieben, weil einem das die Scheinbare Sicherheit aus 1. gibt.

Ich arbeite selbst in der Branche und auch wenn wir in unserem Team einigermassen Glueck hatten, ist es erschreckend zu beobachten wie planlos die Branche agiert. Sie ist halt noch sehr jung und unerfahren.

Hoffentlich wird das bald besser...