Diskussion über Bugs, bugfixing und testen

  • Testet mal auf einem Server mit allen


    Wäre das nicht identisch zu "gar nicht testen" und einfach ungetestete Versionen auf allen Live-Spielwelten aufspielen? Und dann jedes mal alle Server runterfahren, wenn wir einen Bug fixen wollen, so alle 1-3 Tage? Denn das ist die Bedeutung von "testen mit allen". Ich bin mir nicht sicher, ob das wirklich etwas ist, was du willst.

    _________________________________________

    Found?DU5gLUo.png

  • Wäre das nicht identisch zu "gar nicht testen" und einfach ungetestete Versionen auf allen Live-Spielwelten aufspielen? Und dann jedes mal alle Server runterfahren, wenn wir einen Bug fixen wollen, so alle 1-3 Tage? Denn das ist die Bedeutung von "testen mit allen". Ich bin mir nicht sicher, ob das wirklich etwas ist, was du willst.

    Ich versuch mal, für Skingrad zu antworten, der (die?) sich ja letzte Nacht mehrfach recht emotionell und metaphorisch über die vielen Bugs geäußert hat. Wo ich ihn verstehe: egal, wie ihr das seht, auch mir nimmt die Menge der Bugs eben auch eine Menge von dem Spaß, den ich mit diesem schönen Spiel haben könnte, und - wichtiger für das Unternehmen - mir nehmen die Bugs jede Motivation, das Spiel weiterzuempfehlen.


    Und zum Testen: ich sags mal ehrlich, ich habe den Eindruck, dass die Progger-Tests in Zeitstress stattfinden und recht oberflächlich sind. Denn eine Vielzahl der Bugs taucht nach Epo 1 auf oder dann, wenn eine Liste so lang wird, dass sie nicht mehr ins Fenster passt ... oder es sind Anzeigebuffs, die beim allerersten Ausprobieren der Funktion hätten auffallen müssen.

    Viele Bugs kommen also auf den Testserver in einer Form, dass man sich fragt, warum der Progger das nicht gesehen hat, als er seine neue Funktion ausprobiert hat.


    Zweiter Punkt ist das Ausrollen der Bugs vom Testserver. Euer Argument ist immer die fehlende Zeit zwischen Test und Ausrollen. Aber das ist Organisation. Wenn euer Gantt-Chart zwischen Test und Ausrollen keine Nachbesserungs-Phase hat ... wozu dann überhaupt testen? Und ein weiterer Grund, sich diese Zeit zu nehmen: Auf dem PTR dürft ihr Fehler machen, wenn ihr die ausrollt, dann geht das in die qualitative Bewertung eurer Arbeit ein, bei Spielern, bei Foris, bei Kunden und bei Bloggern und Sponsoren.


    Und ein Gedanke, den Skingrad letzte Nacht auch wieder bei mir geweckt hat: eines eurer größten Probleme ist die Performance. Und Skingrad stellt korrekterweise fest: Ihr testet auf den PTR mit kleiner Spielermenge, und rollt dann eine Funktion aus, die 100 gleichzeitig gespielt haben, und dann von 2000 angeklickt wird. Ihr macht keine Stress-Tests.

    Skingrad verstehe ich so, dass ihr vielleicht doch einen "normalen" Server in der Live-Liste haben solltet, auf dem offiziell die Testversion läuft? Wo also alle mitmachen könnten, ohne über die PTR-Anmeldung zu gehen. Und als Belohnung Karriere ausbauen könnten.

    Oder alternativ: Eine Belohnung ausschreiben: "Wenn heute auf dem PTR2 drei Stunden hintereinander 2000 Klicks auf den Fahrplanrechner kommen, bekommt jeder aktive Spieler 25 Gold auf den Live-Servern"

    So machen es andere Publisher: klitzekleine Belohnung für ein paar Klicks auf dem Testserver und schon bekommen die Techniker Daten, wie die Funktion bei Überlastung reagiert.


    Skingrad war heute Nacht sehr ... metaphorisch ... aber er hat ein paar Punkte vorgetragen, die auch ich für wichtig halte.


    Und ich finde es gut, Salix, dass du nachfragst.

    Beliebt sein ist eigentlich ganz einfach:

    Man muss nur immer sagen, was die anderen hören wollen.

    Leider liegt mir das so überhaupt nicht.

  • Eine Belohnung ausschreiben: "Wenn heute auf dem PTR2 drei Stunden hintereinander 2000 Klicks auf den Fahrplanrechner kommen, bekommt jeder aktive Spieler 25 Gold auf den Live-Servern"

    Das ist aus mehreren Gründen keine wirkliche Option.

    Zum einen sind PTR- und Live-Accounts (ganz bewusst) nicht verknüpft. GDPR & Co machen es nicht gerade leichter, diese "Lücke" zu überbrücken.

    Zweitens fördert materielle Belohnung Verhalten, das auf Erhalt der Belohnung abziehlt, nicht darauf, hilfreich zu sein. Das sind die meisten dann wenn dann eher per Zufall oder weil wir sehr viel Zeit darauf investiert haben, die Aufgabe sehr klar zu definieren (was meistens erfordert, dass man den Bug schon kennt).
    Drittens untergräbt materielle Belohnung auf Grund des Korrumpierungseffekts die intrinsische Motivation und ist dadurch höchstens kurzfristig effektiver, bringt aber langfristig große Probleme mit sich.
    Viertens sorgt das massenhafte Rekrutieren von Testern die keinen Wert auf Qualität sondern Belohnung setzten, dafür, dass für sehr wenig Mehrwert das Arbeitspensum für das Verarbeiten der (im Schnitt weniger nützlichen) Bugmeldungen deutlich ansteigt. Das verringert die Qualität des ganzen Prozesses, da man im Endeffekt pro Arbeitszeit (die nunmal limitiert ist) im Endeffekt weniger Bugs bearbeitet, trotz mehr Spieler.


    Daher ist materielle Belohnung keine gute Idee. Das wäre primär eine populistische Aktion die vlt gut aussieht, im Endeffekt aber mehr schadet als sie nützt. Materielle Belohung wäre nur dann eine Option, wenn man sehr kurzfristig schlicht und einfach eine hohe Spieleranzahl braucht, z.B. um einfach einen Belastungstest durchzuführen. Das könnte z.B. bei Dingen wie einem neu programmierten RTS nötig sein.

    In allen anderen Fällen steht Klasse ganz klar über Masse und für diesen Fokus ist materielle Belohnung nicht geeignet.



    Der Plan ist eher, den PTR sichtbarer zu machen, damit die Spieler die tatsächlich das Spiel verbessern WOLLEN (was im Endeffekt die Spieler sind, die wir wollen und brauchen), leichter den Weg finden.

    _________________________________________

    Found?DU5gLUo.png

  • ich verstehe eins nicht,ihr wisst genau wie ihr vorgehen müst und trotzdem versemmelt ihr fast jedes update.

    da fragt man sich wirklich warum dies so ist?vielleicht solltet ihr echt mal überlegen,ob euer testweg so noch sinn macht.warum nicht mal neue wege gehen?

  • Danke, Salix, für die Antwort ... wir beide "hijacken" zwar gerade einen Bug-Thread, aber das Thema zermürbt eben viele eurer Spieler und Kunden.

    Das ist aus mehreren Gründen keine wirkliche Option.

    Ob der Satz ein Management Summary ist oder eine Killerphrase, ist Geschmackssache ... aber eine Einleitung sollte zum Weiterlesen verführen, nicht zum Gedanken "Oha, da hat er ja schon alles gesagt" ... oder?

    Zum einen sind PTR- und Live-Accounts (ganz bewusst) nicht verknüpft. GDPR & Co machen es nicht gerade leichter, diese "Lücke" zu überbrücken.

    Wären die PTR echte Test-Server, wäre genau das ein Grund FÜR die Option, denn solange sich PTR und Live hinsichtlich der Sicherheit der privaten Daten (GDPR & Co) unterscheiden, testet ihr im ganz inneren Kern der Accounts was anderes als ihr ausrollt.

    Zweitens fördert materielle Belohnung Verhalten, das auf Erhalt der Belohnung abziehlt, nicht darauf, hilfreich zu sein. Das sind die meisten dann wenn dann eher per Zufall oder weil wir sehr viel Zeit darauf investiert haben, die Aufgabe sehr klar zu definieren (was meistens erfordert, dass man den Bug schon kennt).

    Da unterscheiden wir uns:

    - Ich schaue auf das Ziel. Manchmal auf das Ziel der Kunden, manchmal auf das Ziel des Unternehmens.

    - Antworten von Travian/BR kommen immer mit Befürchtungen über die Kunden, Angst vor Verprechungen, Fürchten der Belohnungs-Gier der Kunden ... irgendwie kommt indirekt immer euer Bild von den Kunden rein, und das ist selten das Bild eines erwachsenen, informierten, denkenden, auf gleicher Ebene gewerteten Menschen. Sorry, wenn ich das mal so deutlich sage.


    Ich sprach vom Ziel "Performance testen", du änderst das in "den Bug schon kennen". Du sprichst von zufälligen Zeiten, ich sprach von definierten 3 Stunden. Du sprichst von der Gier nach der Belohnung statt der sozialen Gier, hilfreich zu sein.

    25 Gold für 3 Stunden Klicken hat nichts mit Abzielen auf Belohnung zu tun. Aber viele Menschen sind eben bereit euch für diese Kleinigkeit tatsächlich mal 3 Stunden hilfreich zu sein ... ihr probiert es nur niemals aus.


    Wenn das Ziel ist, Performance zu testen, muss man den Server belasten, ja überlasten. Das schaffen eure ca. 50 Mitarbeiter nicht selbst, dafür braucht ihr ein oder zwei Tausend. Eure Kunden könnten das, und die Motivation wäre vielleicht bei einigen wenigen die Gier auf die 25 Gold, bei den meisten aber - so sehe ich eure Kunden - das Interesse, das Spiel, das sie lieben, besser zu machen, robuster zu machen, euch zu helfen, beteiligt zu sein, ernst genommen zu werden.


    Wenn ihr Performance testen wollt, braucht ihr eure Kunden, und es ist besser die VORHER zu belohnen, als den Perfomance-Test als Master-Event zu gestalten. Denn ein verkorkstes Master-Event schadet eurem Ruf mehr als es 25 Gold für jeden tun.


    Drittens untergräbt materielle Belohnung auf Grund des Korrumpierungseffekts die intrinsische Motivation und ist dadurch höchstens kurzfristig effektiver, bringt aber langfristig große Probleme mit sich.

    Ich sehe eure Kunden anders. Schau dir allein das Forum an. Es gehört eine Menge Mut dazu, euch immer wieder auf Fehler, Bugs, Lags und andere Misstände hinzuweisen. Darum würde ich mich nicht trauen, einen Satz über meine Kunden mit "Korrumpierung" zu formulieren. Eure Kunden sind nicht korrumpierbar, vielleicht ein ganz kleiner Teil.

    Die, die noch da sind, zeichnen sich eher durch Treue zum Produkt aus.


    Und die langfristigen Probleme sehe ich nicht. Wenn ihr 1000 Tester braucht für eine verwertbare Aussage, solltet ihr die belohnen, partnerschaftliches Geschäft. Und ich sehe bei anderen Publishern, dass solche Testaktionen, Stress-Tests, Performance-Mitmach-Aufrufe ein großartiges Marketing-Instrument sind ... anschließend tauchen da immer neue Kunden auf, neue Mitspieler, weil diese Tests sogar auf Facebook angekündigt werden und Neue neugierig machen ... die Gier auf Neues wecken.


    Viertens sorgt das massenhafte Rekrutieren von Testern die keinen Wert auf Qualität sondern Belohnung setzten, dafür, dass für sehr wenig Mehrwert das Arbeitspensum für das Verarbeiten der (im Schnitt weniger nützlichen) Bugmeldungen deutlich ansteigt. Das verringert die Qualität des ganzen Prozesses, da man im Endeffekt pro Arbeitszeit (die nunmal limitiert ist) im Endeffekt weniger Bugs bearbeitet, trotz mehr Spieler.

    Bei Perfomance-Tests braucht ihr keine Qualität bei den Aussagen, keine Bugmeldungen, ihr braucht Klickraten. Ein Stress-Test soll den Server unter Stress setzen, eure Techniker können dann schon feststellen, ob die FP noch laden oder aufgeben.


    Anscheinend kennt ihr nur eine einzige Art von Test, den PTR und die Bugmeldungen der Kunden. Die Folge ist: Master-Events starten mit katastrophaler Performance, Upgrades erzeugen kein Lob über weniger Bugs sondern Aufstöhnen über mehr Bugs, usw.


    Ihr habt einen Plan, wie ihr entwickelt, testet (auf PTR und Ausrollen bevor das ES gestartet ist) und Bugs zur Kenntnis nehmen wollt. So ein Plan ist gut. Aber euer Plan macht das Produkt nicht besser ... da fehlt noch was.


    Eure Kunden merken und formulieren, dass euer Plan die Zahl der Bugs nicht reduziert, die Qualität des Produktes nicht verbessert, die Ladeprobleme der Anwendung nicht beseitigt und die Performance nicht wirklich verbessert. Und euer Change-Management lässt immer wieder alte Buge reinkarieren.


    Viele eurer Kunden - heute Nacht Skingrad - machen Vorschläge wie das verbessert werden kann ... aber bevor von eurer Seite ein "Gute Idee, das bring ich ins nächste Meeting ein" oder auch nur "darüber könnten wir nachdenken" kommt, erscheint zuerst mal ein kategorisches "Keine Option!"


    Daher ist materielle Belohnung keine gute Idee.

    Es wäre die Idee der geschäftlichen Partnerschaft. Ihr wollt Euronen für die virtuelle Währung Gold, und eure AGB sehen nicht vor, dass ihr dafür irgendeine Verpflichtung eingeht. Die Waage von Geben und Nehmen ist laut AGB nicht ausgeglichen.


    Ist es ein Wunder, dass eure Kunden hier immer wieder erregen darüber, dass ihr so viel Gold verkaufen wollt? Ihr wollt Belohnung für eure Arbeit, die Kunden für ihre Testarbeit belohnen ist "keine gute Idee". Das ist nicht Partnerschaft auf Augeshöhe.


    Den Menschen, die euch helfen, helfen wollen, eine kleine Belohnung anzubieten, ist nichts anderes als ein partnerschaftliches Geschäft zwischen Menschen, die sich gegenseitig respektieren und als mehr sehen als "gierig auf Goldverkäufe" auf der einen Seite oder "gierig auf kleine Vorteile" auf der anderen.


    Euer Bild von den Kunden ist "korrumpierbar" oder "gierig auf die Belohnungen". Manchmal wird das sehr deutlich, dass ihr nichts anderes erwartet ... oder eben diese Reaktion am meisten fürchtet.

    Das Bild, das eure Kunden hier im Forum von euch zeichnen, das von der Überzahl der Goldfunktionen, der Goldverkäufe


    Ihr habt ein Bild von euren Kunden, das wird ihnen deutlich durch euer Verhalten und eure Formulierungen. Wenn dann eure Kunden ein Bild zeichnen von Goldgier und "Gold verkaufen" und "alles teurer" ... dann ist das doch nur ein Spiegel dessen, wie ihr uns seht.

    Der Plan ist eher, den PTR sichtbarer zu machen, damit die Spieler die tatsächlich das Spiel verbessern WOLLEN (was im Endeffekt die Spieler sind, die wir wollen und brauchen), leichter den Weg finden.

    Das ist ein guter Plan, der das Testen interessanter und beliebter machen wird.


    Aber er wird niemals die Mengen zum Testen auf den Plan bringen, wir ihr sie braucht, um ein Masters-Event performant über die Bühne zu bringen. Ihr erlebt die Performance auf dem Live-Server ... aber dort haben die Menschen Euronen bezahlt, sichern euch Einnahmen durch Werbevideos, geben ihre Freizeit, um letztlich ein nicht wirklich fertiges Produkt auszuprobieren ...


    Und es ist das Verschenken einer Marketing-Chance.

    Beliebt sein ist eigentlich ganz einfach:

    Man muss nur immer sagen, was die anderen hören wollen.

    Leider liegt mir das so überhaupt nicht.

    The post was edited 1 time, last by Klabbauter ().

  • Zur Frage "warum das so ist": Weil es eben in der Praxis nicht so simpel ist, wie es immer von außen aussieht.

    Das fängt schon bei Bugmeldungen an. Häufig sind Bugmeldungen z.B. inhaltich etwa auf der Ebene von "XY geht nicht". Ok....was geht nicht? Auf welchem Server? Wann? Unter welchen Umständen? Immer? Mit welchem System? Mit welcher Software? Bei wievielen Spielern?

    All das zu wissen ist natürlich auch für den Spieler oder Mitarbeiter, der den Bug meldet, nicht immer leicht. Es ist aber dennoch nötig das meiste davon zu wissen, um überhaupt zu wissen, was genau der Bug eigentlich ist und woran es liegen könnte.


    Das muss also getestet werden um, Schritte zu finden, den Bug überhaupt zu reproduzieren. Das kann, je nach Natur des Bugs und je nachdem, ob man Umstände und Reproduktionsschritte kennt, einige Minuten oder auch Tage (reine Arbeitszeit!) dauern...oder man findet es nie heraus. Irgendwann kommt dann auch schon die nächste Version und dann ist nicht zwingend gesagt, dass der Bug in der Form überhaupt noch existiert.
    Und manchmal ist ein Bug gar kein Bug, sondern ein Problem dass durch irgendwas komplett anderes, woran wir nichts ändern können, verursacht wird (z.B. instabiles Wlan oder unzureichende Hardware).


    Wenn man es schafft den Bug zu reproduzieren, muss er auch noch gefixt werden. Das geht meistens, aber auch nicht immer und ist unter Umständen ebenfalls zeitintensiv. Dann muss es das ganze natürlich noch vor dem nächsten Udpate schaffen und getestet werden muss es auch (nicht dass der Bugfix neue Bugs verursacht). D.h. durch Abhängigkeiten (PTR-Testzeit, Datum des Live-Updates) dauert das ganze dann noch etwas länger, als der eigentliche Arbeitsprozess.


    Und nicht zu letzt muss auch priorisiert werden. Welcher Bug ist am wichtigesten? Ist ein großer Bug der 5 Spieler betrifft wichtiger als ein mittlerer der 5000 betrifft? Ist ein Bug der legale Konsequenzen haben könnten wichtiger als einer der das Spiel unspielbar macht? Ist ein Brower-Bug wichtiger als ein Mobile-Bug? Sollte ein kleiner Bug, der in 20 Minuten gefixt werden kann gegenüber einem katastrophalen Bug der eine Woche dauert priorisiert werden? Falls ja, wie viele davon? Wie lange will man dann den katastrophalen Bug rausschieben und mit welcher Begründung? Oder falls man sich anders rum entscheidet, wieviel Zeit will man für extrem aufwendige Bugs investieren, ohne tatsächlich Bugs die man schnell erledigt hätte zu fixen?


    Und das ist nur die Oberfläche, das ist das was ich, als jemand der gar nichts mit Bugs zu tun hat, mitkriege. Innerhalb der Teams ist das ganze dann noch mal komplizierter.


    Und dem ganzen zu Grunde liegt die Tatsache, dass es sowas wie bugfreie Software-Entwicklung schlicht und einfach nicht gibt. Kein Spiel der Welt (oder Software im allgemeinen) hat Updates, die keine neuen Bugs enthalten. Selbst große Triple-A-Titel mit ganzen Armeen an Programmierern und Testern und den erfahrensten Fachkräften der Branche implementieren regelmäßig hunderte neuer Bugs.



    Zu deiner Frage, warum wir nicht neue Wege gehen: Tun wir. Wenn sich bei uns Arbeitsprozesse als ineffektiv erweisen, ändern wir diese. Zum Beispiel haben wir neulich geändert, wie wir Bugs priorisieren. Seitdem sind wir in dem Bereich deutlich schneller geworden und wir fixen mehr Bugs als wir implementieren. Auch ab nächster Woche haben wir z.B. auch wieder eine Änderung, wo es darum geht, wer genau zu welchem Zeitpunkt was für wie lange testet. Klingt jetzt nicht sonderlich spektakulär, aber wird uns auch wieder ein wenig effizienter machen.

    _________________________________________

    Found?DU5gLUo.png

  • Salix, ich glaub der Dev hieß Chronos, glaub ich, der Clash in der ersten Version interaktiv mit uns innerhalb von Stunden gefixt hat. Es gibt Alternativen zu eurem Verfahren, ausprobierte Alternativen. Und die haben gezeigt, dass flexible Arbeitsweisen letztlich effektiver sind.

    Was du beschreibst, ist eine Menge Verwaltungsaufwand, bevor der Progger eine Bugbeschreibung bekommt, die über mehrere Stellen gegangen ist, interpretiert und bewertet wurde. Chronos hat damals nachgefragt und das Ding gefixt, einmal innerhalb von Minuten.


    Und nicht zu letzt muss auch priorisiert werden.

    Stimmt. Aber WER priorisiert? Ich hab immer zuerst auf die Progger gehört und ihre Zeitschätzung. Nach der 80/20-Regel waren damit 80% der Bugs schnell weg und die ganze Verwaltung und Priorisierung war nur noch für 20% der Bugs nötig.


    Und dem ganzen zu Grunde liegt die Tatsache, dass es sowas wie bugfreie Software-Entwicklung schlicht und einfach nicht gibt.

    Stimmt. In meinem derzeitigen Projekt sind auch zwei Bugs. Auch ich progge Bugs. Morgen sind wie weg.

    Jedes Software hat Bugs ... altbekannt ... aber keine Entschuldigung.

    Wer seine Arbeitsweise damit entschuldigt, dass andere ähnlich arbeiten ... der wird sich nicht durch ein positives Alleinstellungsmerkmal auszeichnen. Charlie von 2,5 men würde sagen: "Alle machen Bugs ist der Schlachtruf der notorischen Me-Too-Bugger."

    Euer Produkt besticht durch die Menge der Bugs und durch die Hartnäckigkeit ihrer Reinkanationsfähigkeit.

    Zu deiner Frage, warum wir nicht neue Wege gehen: Tun wir. Wenn sich bei uns Arbeitsprozesse als ineffektiv erweisen, ändern wir diese

    Leider wird das von außen nicht wahrnehmbar. Es bleibt intern.

    Und die Sache der Priorisierung: das ist Verwaltung. Ihr verändert die Verwaltung, und das macht Arbeitsweisen nur selten effektiver oder schneller.

    Beliebt sein ist eigentlich ganz einfach:

    Man muss nur immer sagen, was die anderen hören wollen.

    Leider liegt mir das so überhaupt nicht.

  • Mal ein Vorschlag:


    Das hat jetzt alles nichts mehr mit dem FP-Bug zu tun, sondern ist eine allgemeine Diskussion über Bugs und Verhindern von Bugs. Skadi wird das unübersichtlich finden ... wie wäre es, Salix, wenn du den Teil mit der Diskussion in die allgemeinen Diskussionen verschiebst?

    Beliebt sein ist eigentlich ganz einfach:

    Man muss nur immer sagen, was die anderen hören wollen.

    Leider liegt mir das so überhaupt nicht.

  • wie wäre es, Salix, wenn du den Teil mit der Diskussion in die allgemeinen Diskussionen verschiebst?

    Das kann Skadi gerne machen, wenn sie das für richtig hält. Moderation ist ihr Fachbereich, nicht meiner, da misch ich mich nicht auf "Micro Management"-Level ein.

    denn solange sich PTR und Live hinsichtlich der Sicherheit der privaten Daten (GDPR & Co) unterscheiden

    Da hast du mich ein wenig missverstanden. Es geht um die Verknüpfung der beiden Accounts, z.B. in dem wir PTR-Spieler fragen "Was ist die Email-Adresse deines Live-Accounts?".

    Ich sprach vom Ziel "Performance testen", du änderst das in "den Bug schon kennen". Du sprichst von zufälligen Zeiten, ich sprach von definierten 3 Stunden.


    Wie ich ja im Text auf den du geantwortet hast gesagt habe, ist Belohnung für Performance-Tests durchaus eine Option. Aber es geht in diesem Threads ja eher um tatsächlich Bugs, nicht Performance.

    Anscheinend kennt ihr nur eine einzige Art von Test, den PTR und die Bugmeldungen der Kunden.

    Nein. Wir haben auch eine QA-Abteilung und jeder einzelne Mitarbeiter meldet ebenfalls Bugs. Der PTR ist eher ein Zusatz.

    Ich sehe eure Kunden anders. Schau dir allein das Forum an. Es gehört eine Menge Mut dazu, euch immer wieder auf Fehler, Bugs, Lags und andere Misstände hinzuweisen.

    Wir sehen das nicht sehr anders. Ich würde es zwar eher "Leidenschaft" als "Mut" nennen, aber ansonsten seh ich das wie du.


    Euer Bild von den Kunden ist "korrumpierbar" oder "gierig auf die Belohnungen". Manchmal wird das sehr deutlich, dass ihr nichts anderes erwartet ... oder eben diese Reaktion am meisten fürchtet.

    Das ist kein Kunden-Bild, das ist ein Menschen-Bild und es hat nichts mit Gier zu tun, sondern mit Neurobiologie. Der Korrumpierungseffekt ist kein Wort, das ich mir ausgedacht habe, sondern ein gut erforschter psychologischer Effekt, der auf neurobiologischen Prozessen basiert. Und dieser Effekt ist genau der Grund, warum GERADE weil unsere Spieler durch Leidenschaft motiviert sind, hier besonders aufgepasst werden muss. Der Korrumpierungseffekt sagt simpel ausgedrückt aus, dass intrinsische Motivation ("etwas um seiner selbst willen tun") von extrinsischer Motivation ("etwa tun, weil man dafür belohnt wird") überschrieben wird. D.h. selbst wenn jemand schon von sich aus motiviert ist, z.B. ein selbstloser und engagierter PTR-Tester, wird dessen vorhandene Motivation überlagert, wenn er eine Belohnung erhält. Das ist erstmal egal, so lange der Effekt der Belohnung anhält. Endet die Belohnung aber oder verliert sie ihre Attraktivität, kehrt die ursprüngliche intrinsische Motivation nicht einfach so wieder zurück, sondern es ist gar keine Motivation mehr übrig. D.h. beim Versuch einen Spieler zu motivieren der sowieso schon motiviert war, zerstört man langfristig unbeabsichtigt seine Motivation. Das ist der Korrumpierungseffekt, ein gut erforschter und sehr problematischer psychologischer Effekt, für den es zahlreiche Beispiele gibt.


    Ich bezeichne unsere Spieler also nicht als korrumpierbar oder gierig, ich bezeichne sie als Menschen. Und gerade WEIL unsere Spieler und vor allem PTR-Tester so passioniert sind, muss man aufpassen, dass man das nicht so einfach so durch einen simplen Fehler zunichte macht. Wäre kein PTR-Spieler motiviert, wäre materielle Belohnung kein Problem, weil man nichts zu verlieren hätte. Das ist aber (zum Glück) nicht der Fall.


    Aber er wird niemals die Mengen zum Testen auf den Plan bringen, wir ihr sie braucht, um ein Masters-Event performant über die Bühne zu bringen

    Korrekt. Das ist auch nicht der Plan und es stehen für solche Unternehmungen andere Möglichkeiten zur Verfügung. Darunter auch Belohnung.

    Salix, ich glaub der Dev hieß Chronos, glaub ich, der Clash in der ersten Version interaktiv mit uns innerhalb von Stunden gefixt hat.

    Ein simples Stück Software an dem genau eine Person gearbeitet hat und das nahezu komplett unabhängig vom Spiel ist. Das gilt für den Rest des (über Jahre hinweg von verschiedensten Leuten entwickelten) Spiels nicht, da sind die Zusammenhänge auf einem völlig anderem Komplexitätslevel, was dir als Fachmann sicherlich bekannt ist.

    Stimmt. Aber WER priorisiert? Ich hab immer zuerst auf die Progger gehört und ihre Zeitschätzung. Nach der 80/20-Regel waren damit 80% der Bugs schnell weg und die ganze Verwaltung und Priorisierung war nur noch für 20% der Bugs nötig.

    Ein Team aus Vertretern der Abteilungen, die das beurteilen können. Ich gehöre nicht dazu, daher kann ich da wenig dazu sagen.

    hr verändert die Verwaltung, und das macht Arbeitsweisen nur selten effektiver oder schneller.

    Da sind wir uns wohl nicht einig. Verwaltung kann extrem ineffizient sein...oder auch nicht.

    _________________________________________

    Found?DU5gLUo.png

  • Nochmal Dank für deine Antworten. Jetzt kommen Ausführungen, die ich eher nachvollziehen kann als die davor.

    Das ist kein Kunden-Bild, das ist ein Menschen-Bild und es hat nichts mit Gier zu tun, sondern mit Neurobiologie. Der Korrumpierungseffekt ist kein Wort, das ich mir ausgedacht habe, sondern ein gut erforschter psychologischer Effekt, der auf neurobiologischen Prozessen basiert

    Wir sind wohl beide recht gut ausgebildet in Teilgebieten der Psychologie oder Neurobiologie ... schade, dass ich in Berlin wohne, ein Treffen und ein Gespräch über genau diese Themen würde mich sehr interesseiren.

    Es ist ja auch so, dass viele Publisher und Game Studios gerne auch ein oder zwei Psychologen (oder Progger mit abgebrochenem Psychologie-Studium) einstellen, um ausgewogen und fachlich angemessen auf Emotionen, Verhalten und Leidenschaft agieren und reagieren zu können.


    Man sollte ALLE Effekte im Auge behalten. Es gibt ja auch den Effekt der selbsterfüllenden Prophezeiung, ebenso gut erforscht und beschrieben und neurobiologisch überprüft. Der Effekt bewirkt, dass man immer genau das bekommt, was man fokussiert. Und die meisten Menschen benutzen das negativ. Denken nur an Krebs und bekommen Krebs. Fürchten sich vor einem Shitstorm und schon kommt einer. Helikoptern ihr Kind, so dass es nie lernt sich selbstständig im Verkehr zu bewegen und noch als Teenager in die Schule gefahren werden muss. Oder eben, wenn es immer heißt, dass die Kunden leidenschaftlich reagieren, oder "gierig" nach Boni ... dann wird man die so präsentieren, dass genau das passiert.

    Und bei den Sternen und kürzlich bei den Diamanten habt ihr erlebt, was dann passiert.


    Also: solange ihr mit einem bestimmten Kundenverhalten rechnet, es fürchtet, werden sich die Kunden genau so verhalten, wie ihr es fürchtet. Beispielsweise sind alle eure Marketing-Texte sehr Wir-bezogen. Wir tun dies. Wir haben was Neues. Wir machen ein Update. Nur ganz ganz selten schreibt ihr über den Kunden, den Spieler, was für die Menschen "drin ist", die euer Produkt nutzen und finanzieren. Marketing sollte kundenbezogen sein, nicht das Unternehmen als Nr. 1 darstellen, denn genau damit zeichnet ihr ein Bild von euren Kunden als Konsumenten, die dankbar sein müssen für euer Bemühen.


    Doch egal, welche Theorie dahinter steht: Eure Formulierungen über Kunden, über Spieler, über Foris mögen neurobiologisch begründbar sein, auf zwei anderen Kommunikations-Ebenen, der Beziehung, der Selbstaussage, kommt ihr glänzend weg, aber die Kunden als recht unselbstständige Wesen. Wenn ihr glaubt, dass Belohnungen einen negativen Effekt haben, dann wird ein negativer Effekt kommen. Wenn ihr das Testen positiv verkauft, dann wird es positive Auswirkungen haben.


    Ein simples Stück Software an dem genau eine Person gearbeitet hat und das nahezu komplett unabhängig vom Spiel ist. Das gilt für den Rest des (über Jahre hinweg von verschiedensten Leuten entwickelten) Spiels nicht, da sind die Zusammenhänge auf einem völlig anderem Komplexitätslevel, was dir als Fachmann sicherlich bekannt ist.

    Nun ja, ich hab die Interaktion zwischen Proggern und Anwendern eingeführt in einem Projekt mit 60 Proggern. Die Qualitätsabteilung und die Pflichtenheftschreiber (beide Abteilungen auch in der Größenordnung) waren jeweils dabei. Das Feedback war: Noch nie waren diese Meeting so effektiv und so schnell am Ziel ... und so fruchtbar, dass (fast) bugfreie neue Versionen jedes Quartal entstanden. Meistens reichte ein Meeting aus, und es funktionierte ... ohne weitere Meetings, ohne Priorisieren, ohne viel Verwaltung.

    Ihr glaubt daran, dass das nur in kleinen Einheiten klappt. Ich habs mit großen Einheiten ausprobiert, angewendet und schöne Referenzen dafür bekommen.

    Der Anwender (oder der Spieler) sieht die Komplexität tatsächlich nicht ... aber ... er kann ganz pragmatisch sagen, was er erwartet, ganz simpel ausgedrückt und die Progger, Devs, Pflichtenheftschreiber und Lastenheftschreiber sind dann ausgebildet und werden bezahlt dafür, das komplexe Innenleben der Software so zu nutzen, dass am Ende der Anwender zufrieden lächelt.


    Wenn sie aber nicht wissen, oder gar glauben besser zu wissen, was gut für den Anwender/Spieler ist, oder die Info über drei andere Abteilungen läuft ... dann verfangen sich alle in der Komplexität und Verwaltung, verirren sich im Change-Management und produzieren etwas, was der Kunde nicht braucht oder nicht will oder anders will ... und eben neue Bugs aus der Komplexität ins Leben holt.


    Da sind wir uns wohl nicht einig. Verwaltung kann extrem ineffizient sein...oder auch nicht.

    Oh ja. Und weil die meisten Kunden auch in die guten oder schlechten Verwaltungen ihrer Projekte oder Arbeitgeber involviert sind, können sie sehr gut beurteilen, wie effizient ein Unternehmen verwaltet, dessen Produkt sie nutzen.

    Beliebt sein ist eigentlich ganz einfach:

    Man muss nur immer sagen, was die anderen hören wollen.

    Leider liegt mir das so überhaupt nicht.

  • Nur ganz ganz selten schreibt ihr über den Kunden, den Spieler, was für die Menschen "drin ist"

    Gute Neuigkeiten: Im nächsten Blog sind mindestens zwei "du" drin. Und es geht primär darum, für diesen "du" drin ist.

    schade, dass ich in Berlin wohne, ein Treffen und ein Gespräch über genau diese Themen würde mich sehr interesseiren.

    Wenn ich mal in Berlin bin, sag ich Bescheid.

    Wenn ihr glaubt, dass Belohnungen einen negativen Effekt haben, dann wird ein negativer Effekt kommen.

    Das ist in diesem Fall keine Glaubensfrage. Dieser Effekt existiert, völlig unabhängig davon ob man daran glaubt oder nicht.

    _________________________________________

    Found?DU5gLUo.png

  • Sehr schade...

    Nach so einer Einleitung erübrigt sich jede weitere Diskussion.


    Das sehe ich anders. Diskussionen lohnen sich immer. Man hat nichts zu verlieren, außer falsche Ansichten (sofern vorhanden). Im schlimmsten Fall hat man Recht und lernt nichts.

    _________________________________________

    Found?DU5gLUo.png

  • Diskussionen, die ergebnisoffen sind.... Ja, da bin ich bei Dir.

    Leider zeigt gerade die jüngere Vergangenheit hier im Forum, das dies eben nicht der Fall ist.

    Und dann bin ich halt aus der Nummer raus.


    PS: Falls es dich interessiert, findest Du meine Vorschläge im Forum. Aber suchen musst Du selber. 8)

    Wenn Muttern wüsste, was ich alles kann, müsste ich den ganzen Tag arbeiten

  • Das ist in diesem Fall keine Glaubensfrage. Dieser Effekt existiert, völlig unabhängig davon ob man daran glaubt oder nicht.

    Ja, und ebenso existiert der Effekt, dass positive Aussagen und Einstellungen positive Effekte erzeugen.


    Es wird immer wieder deutlich, wovor ihr euch fürchtet, was ihr verhindern wollt ... und dann bekommt ihr das.

    Würdet ihr anders formulieren, euren Kunden mehr partnerschaftlich und auf Augeshöhe begegnen, würdet ihr andere Effekte erzielen. Ich bleib dabei: das Verhalten der Kunden ist Spiegelbild eures Verhaltens, ebenso wie die Einstellung der Kunden euch gegenüber (inklusive Glauben, Meckern, Emotionen) ein Spiegelbild eurer Einstellung ist.


    "Wenn du die Welt verändern willst, dann musst du dich verändern." Das sagen alle Motivationstrainer, und das hat Ghandi schon gesagt.

    Beliebt sein ist eigentlich ganz einfach:

    Man muss nur immer sagen, was die anderen hören wollen.

    Leider liegt mir das so überhaupt nicht.