DON´T! Discord als Projektmanagement

Okay vorneweg: Discord ist toll, Discord ist super, Discord ist vermutlich aus ganz vielen Entwicklungsteams nicht mehr weg zu denken. Und das auch nicht erst seit Corona. Aber eins ist Discord nicht – und das ist eigentlich selbstverständlich, aber scheint dennoch vielen subtil entgangen zu sein: Discord ist kein Projektmanagement Tool!

Erst mal von vorne: Was ist Discord eigentlich?

Vermutlich kennt es jeder von euch, aber zur Sicherheit noch mal kurz zusammen gefasst: „Discord (auch Discordapp) ist ein Onlinedienst für Instant Messaging, Chat, Sprachkonferenzen und Videokonferenzen, der vor allem für Computerspieler geschaffen wurde, inzwischen aber auch vermehrt für andere Bereiche genutzt wird. Discord kann als Webanwendung oder mit proprietärer Client-Software auf allen gängigen Betriebssystemen genutzt werden. Discord gibt an, mehr als 250 Millionen registrierte Nutzer zu haben.“ sagt Wikipedia dazu.

Viele – besonders viele dezentrale – Entwicklungs-Teams, haben Discord neben dem Marketing ihrer Spiele mittlerweile auch für die Arbeit innerhalb ihrer Teams für sich entdeckt. Skype – so wurde mir neulich von einem Geschäftspartner vor die Füße geknallt – „ist oldschool Alter!“ 😉 So läuft heute die Organisation vieler Teams in der Branche tatsächlich über Discord. Und sie nutzen sie für die Koordination des Teams, Absprachen, Feedback, Live-Calls, die Dokumentation, und, und, und… Oder eben naja: Einfach zum unkoordinierten Labern. Und das bringt mich auf mein heutiges Don´t:

Discord ist keine Projektmanagement Software!

Um das gleich zu sagen: Ich arbeite die meiste Zeit, bis auf einige Aussetzer, wirklich gerne mit Discord. Es ist praktisch, die meiste Zeit zuverlässig und man kann gut verschiedene Teams übersichtlich darüber verwalten. Aber man kann vor allem auch innerhalb der Projekte die verschiedenen Departments und Bereiche klar voneinander trennen. Es ist einem möglich, verschiedene Bereiche für unterschiedliche Mitglieder frei zu geben und gut die unterschiedlichen Berechtigungen zu verwalten. So haben auch mal die Producer ne ungestörte Ecke zum Schnacken.

Was ist also dann mein Problem mit Discord? Nun, das erinnert mich an das Thema Funkgeräte im Live Rollenspiel: Funkgeräte sind – oder waren sie zumindest in den 90ern, als noch nicht jeder ein Handy hatte und das Telefonieren noch echt Geld gekostet hat (JA mann Robert! Ich bin alt!) – einfach saucool! Jeder von den Spielleitern hat so ein schnuckiges Matrix Agenten Headset im Ohr und man kann sich mit allen anderen Spielleitern jederzeit verständigen, während man sich frei auf dem Spielgelände bewegt. Es macht irre viel Spaß, darüber gemeinsam ein Live Rollenspiel zu leiten und hier und da mal nen blöden Spruch zu machen. Bis – ja bis – das ganze unweigerlich ohne die nötige „Funken-Disziplin“ ausartet. Und jeder ständig ununterbrochen schwätzt und sich gegenseitig unterbricht und bis allen nach mehreren Stunden oder sogar Tagen die Ohren förmlich bluten.

Da hilft nur: Direkt zu Anfang der Veranstaltung ein kleiner Workshop in „Funken-Disziplin“, der die nötigen Regeln und Guidelines vermittelt. Und so ist das eben auch mit Discord. 😉

Discord ist nur eine Kommunikations Plattform

Wir sind uns wohl alle einig, dass man prima über Discord mit seinen Entwickler-Teams kommunizieren kann. Aber es braucht eben dafür zu Projektstart – und immer mal wieder zwischendrin – einen Workshop in Funken Disziplin. Also naja klar, es braucht keinen Funken Workshop, sondern was ich meine: Es braucht ein Regelwerk.

Discord ist nämlich nur die Plattform, die eine prima Basis für den Austausch bereit stellt. WIE darauf kommunziert werden soll und über WAS und WIE VIEL und WANN, darüber sollte man als Team ruhig mal sprechen, bevor die Zusammenarbeit beginnt. Ich bin dabei jetzt eher so der klassische Produktionstyp, der zwar jedem in seinem Team immer zuhört und offen für alles ist. Aber dennoch schätze ich es sehr, wenn klare Teamstrukturen und Kommunikationspipelines in einem Projekt definiert werden. Und das möglichst schon bevor alles im Chaos versunken ist. Das bedeutet für mich:

Jeder weiß, wer für was zuständig ist.

Ich komme Projektmäßig aus einer Ecke, wo es für die unterschiedlichen Bereiche Spezialisten gibt. Das lässt sich bei größeren Projekten auch gar nicht mehr vermeiden. Einer der Dozenten meines Mannes Helge C. Balzer damals an der HFF Babelsberg hat mal ein großes Filmprojekt mit dem Bau einer Kathedrale verglichen: Es ist aufwändig, es ist teuer, es ist irre kompliziert. Und es ist sauwichtig, dass jemand den Überblick hat und behält und insgesamt dafür gesorgt ist, dass der Steinmetz, der oben rechts den Wasserspeier macht, im gleichen Stil arbeitet, wie der Architekt, der die Balken konstruiert. Und der Steinmetz kommt nicht auf die Idee, dem Architekten zu erklären, dass seine Balken einen anderen Winkel haben müssen.

Natürlich verschwimmt sowas in einem kleinen Team zu recht oft und die Teammitglieder sind auch zum Teil gleichzeitig Game Designer und Creative Director oder zugleich Technical Director und Programmierer, etc. Aber ich denke, es wird klar, was ich meine: Im Team gibt es Leute, die für bestimmte Bereiche zuständig sind. Sie sind die Spezialisten für diese Bereiche und sie haben auch – zumindest so lange kein berechtigtes Veto von ganz oben kommt – das letzte Wort in ihrem Bereich.

Jeder weiß, wer an wen reported und wer wem Feedback gibt

Das ist auch so ein Thema. Auch hier bin ich wieder eher traditionell, was auch hier wieder bei großen Projekten gar nicht mehr anders geht: Für meinen Geschmack sollte klar sein, wer an wen Arbeit abliefert und wer dazu Feedback gibt. Das heißt nicht, dass Arbeiten nicht auch im Team besprochen werden können. Sondern das heißt, dass es einen Verantwortlichen gibt, an den gebündelt und gezielt Arbeit abgeliefert wird und der dann konstruktiv und kompetent (!) dazu Feedback gibt. Also beispielsweise liefert ein Artist seine Arbeit an einen Art Director. Der kann dann auch mit einem Team oder anderen Art Directoren oder dem Creative Director oder wegen mir auch mit seiner Putzfrau besprechen, wie die Arbeit im Kontext des Projektes zu bewerten ist. Oder er macht das, wie wohl die allermeisten Art Directoren, einfach alleine.

DO: Discord für Projektmanagement

Das alles gesagt: Natürlich kann man Discord FÜR das Projektmanagement ganz prima einsetzen. Aber nur, dass wir uns da alle einig sind: Das setzt voraus, dass man ein Projektmanagement hat. Sprich, dass sich irgendwer – oder wegen mir auch alle – darum kümmern, dass klar ist, was, von wem, wann erledigt werden muss, um das Projekt auch tatsächlich fertig zu stellen. Und das setzt voraus – ist eigentlich klar, aber ich sag´s vielleicht trotzdem noch mal – dass irgendjemand das ganze auch aktuell hält und überprüft, ob das auch so alles hin kommt, was man sich da so mal gedacht hat.

Dabei haben sich für mich in den letzten Jahren einige hilfreiche DO´s im Umgang mit Discord ergeben, die ich hier noch kurz mit euch teilen möchte.

DO: Alle bei Bedarf in Discord einführen

Discord ist noch ein verhältnismäßig junges Tool. Und als ich vor ein paar Jahren zum ersten Mal bei einem Projekt dabei war, das im wesentlichen über Discord abgewickelt wurde, stand ich erst mal wie der Ochse vorm Berg. Es macht Sinn, am Anfang der Arbeit über Discord mal eben kurz abzuklopfen, ob alle sich mit Discord schon auskennen. Denn nein, es kennen eben nicht alle Discord und es unterscheidet sich eben doch deutlich von Tools wie Skype, MS Teams, Zoom, etc.

DO: Vorher darüber sprechen, wie man Discord als Team nutzen möchte

Ich als Freiberufler, sowie auch einige Kollegen, nutzen Discord besonders gerne auch zum asynchronen Arbeiten. Besonders als Freiberufler arbeitet man häufig nicht Vollzeit an einem Projekt und eben zu seinen eigenen Arbeitszeiten. Da ist es eine großartige Möglichkeit, dass in zum Teil asynchronen Teams jeder dann arbeiten kann, wann er eben arbeitet und trotzdem eine kontinuierliche Kommunikation gewährleistet ist. Damit meine ich nicht, wenn der eine `ne Nachtschicht schiebt – wovon ich ja eh nichts halte – dass die anderen dann nachts ansprechbar sein müssen. Sondern das bedeutet, dass er dann nachts seine Updates posten kann und die anderen dann am nächsten Morgen beim Kaffee schauen können, was es Neues gibt.

Natürlich könnten sich jetzt aber ohne vorherige Absprachen Teammitglieder genötigt sehen, zum Beispiel Abends noch Fragen zu beantworten, obwohl sie aber eigentlich gerade ihre Kinder ins Bett bringen. Und genau deswegen sollte man am Anfang und ruhig auch immer mal wieder darüber sprechen, wie man Discord im Team nutzen möchte. Vergleichbare Themen sind dabei auch: Wieviel chatten ist bei einem Projekt erwünscht? Gerade wenn jemand länger nicht online war, kann dieses Teammitglied bei seiner Rückkehr bei aktiven Gesprächen der anderen Teammitglieder auch mal in ne Wall of Text rennen. Oder aber: Offtopic Themen und Geblödel Ja Nein? Oder wenn ja, dann nur auf nem extra Kanal? You get the picture…

DO: Verschiedene Kanäle für verschiedene Bereiche

Einer der, wenn nicht der Vorteil überhaupt, von Discord sind die zahlreichen Kanäle auf einem Server. Hier empfiehlt es sich, für die unterschiedlichen Departments einer Produktion je einen eigenen Kanal einzurichten. Und das auch bei kleinen Teams, wo einzelne Teammitglieder auch mehrere Departments betreuen. Auch wenn man das genau wie ein gutes Game Design Document immer individuell an jedes Projekt anpassen muss, hat sich bei mir eine immer wieder unterschiedliche Auswahl aus folgenden Kanälen dabei bewährt:

• #allgemein
• #kontaktdaten
• #production
• #projektplanung
• #dev
• #gamedesign
• #art
• #story
• #marketing
• #build_log
• #offtopic

Und was ich mir noch von meiner sehr geschätzten Kollegin Kristin Janulik abgeschaut habe, ist ein extra Kanal #voicechat. Hier kann man gut ohne weiteren Kommentar Sachen posten, während man gerade auf einem Sprachkanal spricht, und die nur für die Teilnehmenden gerade aktuell relevant sind. Und die anderen Teammitglieder, die da gerade nicht dabei sind, können ihn guten Gewissens muten und den Content ignorieren.

Je nach Art des Projekts können natürlich noch andere ganz individuelle Kanäle dazu kommen, wie zum Beispiel #lernziele bei einem Serious Game oder #minigames für …naja, was mit Minigames 😉 Meiner Erfahrung nach sollte man darüber hinaus nicht der Versuchung erliegen, zu viele Kanäle aufzumachen. Am Ende wird es sonst unübersichtlich und keiner weiß mehr so recht, wo er noch mal was gelesen hatte.

DO: Eigene Kanäle für die Producer

Ich bin ein Riesenfreund von Transparenz im Team. Aber meiner Erfahrung nach ist es nicht immer schlecht, den Producern, Execs oder aber auch anderen Teams wie den Proggern einen eigenen, für sie privaten Bereich zur Verfügung zu stellen. FALLS das wirklich nötig ist. Standardmäßig würde ich das nicht machen, sondern immer erstmal frontal auf Transparenz setzen. Aber manchmal kann das hilfreich sein. Sei es, weil die Progger sowieso keiner mehr versteht. Oder sei es auch manchmal nur deswegen, um NDAs oder Verträge nicht zu reißen.

DON´T: Dokumentation NICHT in Discord

Und doch noch ein kleines Don´t hinterher: Wichtige Sachen gehen in Discord unter. Das ist so sicher, wie das Amen in der Kirche. Discord ist einfach mit seinem stetigen Fluss an Informationen nicht für die Dokumentation eines Projekts geeignet und kann nie, nie, NIEMALS ein Game Design Document oder Technical Document, oder auch nur eine vernünftige Art Description oder dergleichen ersetzen. NIE! (Wie man eine vernünftige Art Description schreibt, darüber habe ich hier schon mal geschrieben) Deswegen gehört die Dokumentation eines Projekts am besten in ein Wiki oder auf andere eher statischere Plattformen.

Das alles gesagt: ich mag Discord für die Koordination von Projekten. Aber eben nur mit der nötigen Funken Disziplin 😉

Habt ihr noch hilfreiche Tipps für die Nutzung von Discord zur Umsetzung von Projekten? Weitere Do´s und Dont´s? Dann lasst es uns gerne wissen und hinterlasst nen Kommentar 🙂

PS: durch die Zusammenarbeit mit dem großartigen Kai Rosenkranz ist bei mir die Tradition entstanden, dass ich mit all meinen Teams immer mal die Musik, die ich gerade beim Arbeiten höre, in den #offtopic Kanal poste. So konnten wir alle schon oft unsere Musik Bibliotheken um echte Schmuckstücke erweitern. 🙂 (und ich konnte nennenswerte Mengen an Musik von befreundeten Komponisten abstauben 😉 )