Einstieg in das Projektmanagement

Projekte wie die Entwicklung einer App oder eines iOS-Games sind keine „normale“ Arbeit. Ein Maurer kann genau ausrechnen, wie viele Steine und wie viel Mörtel er für eine Mauer braucht, die soundso lang und soundso hoch sein soll. Auch ein KFZ-Mechatroniker weiß, welche Ersatzteile er braucht.

Restauriert er allerdings einen Oldtimer, kann es ihm passieren, dass unter dem Blech ein Problem lauert, das er noch nicht kannte, als er das Projekt begonnen hat.

Mit solchen Überraschungen muss man leben. Und dann halt mehr arbeiten, auch auf die Gefahr, zum Schluss hin die Nerven zu verlieren und das Projekt zu gefährden. Oder?

Nein, muss man nicht.

Projektmanagement und Ressourcenplanung sind keine Raketenwissenschaft

Auch in unübersichtlichen Projekten kann und sollte man so viel und so gut wie möglich planen. Das heißt: Vorhersehen, welche Herausforderungen auftreten könnten und am Freitag schon die Werkzeuge für Montag herauslegen.

Aber wie soll man am Anfang eines Projektes Probleme einplanen, die erst gegen Ende auftreten?

Einfache Antwort: Man sollte etwas Extra-Zeit für „Unvorhergesehenes“ einplanen. Und da sind wir schon beim wichtigsten Unterschied zwischen Amateuren, die gegen Ende ihres Projektes den Überblick und die Nerven verlieren, und Profis, die ihr Projekt mit übersichtlichem Arbeitsaufwand zu Ende führen:

Kapazitätsplanung im Projekt: Nur mit Terminplan und Aufgabenplan

Profis im Projektmanagement machen sich vorher Gedanken, was sie brauchen und wie sie ihre Ziele erreichen. Sie haben einen Terminplan, wissen also, wann das Projekt fertig sein soll und wann welche Funktion erstellt wird; und sie haben einen Aufgabenplan – sie wissen schon am Anfang eines Projektes, welche Aufgaben es geben wird.

Gerade Anfänger werden im Projekt oft von unvorhergesehenen Hürden überrascht. Das liegt daran, dass viele Mitarbeiter einfach loslegen, in der Freude, die sich gerade am Anfang vieler Projekte zeigt. Einfach loslegen bedeutet aber auch oft „kopflos handeln“ – jedenfalls aus unserer Sicht.

Man muss ja nicht gleich Netzplantechnik oder MS Project verwenden. Doch auch für relativ kleine Projekte wie das iOS-Game Cold Crash von Tiny Tap Gems lohnt es sich schon, am Anfang des Projektes zu planen:

Projektphasen für ein erfolgreiches Projektmanagement – am Beispiel Cold Crash

1. Welche Ziele will ich mit meiner App oder meinem Projekt überhaupt erreichen?
   Beispiel: die App Cold Crash sollte dem Nutzer / Leser eine interaktive Story bieten, die sich in Echtzeit entwickelt und die man zwischendurch erleben und spielen kann, mit einer packenden Geschichte um den Überlebenskampf einer jungen Frau.
2. Welche Funktionen soll mein Projekt oder meine App haben, um die Ziele erreichen zu können? Cold Crash sollte…
   1. …offen für andere Storys sein, oder für einen zweiten, dritten, vierten Teil
   2. …Text in zusätzlichen Sprachen anzeigen können
   3. …leicht bedienbar sein
   4. …mit einem übersichtlichen Aufwand sowohl für den Programmierer als auch für den Autor realisierbar sein
   5. …eine möglichst große Zielgruppe erreichen
3. Wie kann ich die Funktionen technisch realisieren? Cold Crash brauchte…
   1. …eine Skriptsprache, die der Autor im Text anwendet und so Ereignisse steuern kann, wie zum Beispiel das Einblenden einer Frage – und das Verzweigen in diesen oder jenen Teil der Geschichte, je nach Auswahl des Spielers
   2. …eine Struktur in der Skriptsprache, um zusätzliche Sprachen realisieren zu können
   3. …Grafiken aus professioneller Hand, um eine Art Chat- oder Messenger-Dienst zeigen zu können
   4. …eine motivierende und emotionale Musik, die zum Genre passt, vor allem für den Trailer
   5. …jede Menge Marketingmaßnahmen wie Blogbeiträge, Pressemitteilungen, Screenshots usw.
4. Welche Ressourcen brauchen ich als Projektmanager oder Projektleiter und mein Team (Personal, Technik, Zeit, Werkzeug, Material usw.)? Bei Cold Crash war die Antwort einfach – es gab nur Joachim Mertens und Tim Müßle, zwei Freunde, die sich seit der Schulzeit kannten und die das Projekt gemeinsam realisieren wollten. Alles, was sie selbst nicht leisten konnten, wie z.B. Grafiken und Musik, kauften sie ein, entweder im direkten Kontakt mit dem Grafiker Grobi oder sie kauften Material ein, etwa bei Audiojungle. Wie lange das Projekt dauern würde, war beiden nicht so wichtig, da es in erster Linie um den Spaß an der Arbeit ging.
5. Projektplan erstellen: Wann muss das Projekt fertig sein? Wann halbfertig? Welche Funktionen bauen aufeinander auf? Wer kann wann woran arbeiten? Dieser Plan ist besonders interessant aus Sicht des Autoren, des Texters. Tim Müßle hat den Text von Cold Crash geschrieben und sich dafür einen Plan gemacht, noch bevor er die erste Zeile geschrieben hat. Dabei waren folgende Fragen wichtig:
   1. Storytelling bedeutet: Jemand will etwas haben und bekommt es nicht. Bruce Willis will in „Stirb langsam“ eigentlich nur in Ruhe Weihnachten feiern. Bill Murray in „Und täglich grüßt das Murmeltier“ will bloß den nächsten Tag erleben. Bei Cold Crash hat Anna zwar den Flugzeugabsturz in den Alpen überlebt, muss aber in einer Schneewüste ums Überleben kämpfen – sie will nicht erfrieren. Sie will überleben. Doch der Winter und die Umstände stellen sich ihr entgegen.
   2. Welchen Ausgang soll die Geschichte haben? Hier war es für uns wichtig, dem Spieler mehrere Enden der Story zu bieten. Happy Ends und Tragödien. Da der Spieler im Mittelteil von Cold Crash die Wahl hat zwischen zwei verschiedenen Mittelpunkten der Story, kamen wir schnell auf acht verschiedene Enden.
   3. Das Thema der Geschichte. Jede erfolgreiche Story kombiniert eine These und eine Antithese zu einer Synthese: Anna muss nicht nur gegen das Wetter kämpfen, sondern auch gegen sich selbst – sie traut sich vieles nicht zu und ist der Meinung, vieles nicht zu können – die „These“. Ihr Gegenüber Marcus muss sie antreiben – er hat die „Antithese“: Du kannst das, du schaffst das, und wenn du’s gar nicht erst versuchst, stirbst du. Daraus entwickelt sich die „Synthese“: Ich kann das, und es war gar nicht so unmöglich, wie ich Anfangs dachte.
6. Projekt ausführen – zusätzlich muss wenigstens ein Projekt-Mitarbeiter das Team überwachen:
   1. Arbeiten die Mitarbeiter an den Punkten, an denen sie arbeiten sollen – oder machen sie eine andere Baustelle auf, vielleicht, weil sie daran lieber arbeiten oder weil ihnen die andere Aufgabe (noch) zu schwierig erscheint?
   2. Haben die Mitarbeiter ausreichend Ressourcen, wie Software, Technologie, Material?
   3. Geht es den Mitarbeitern gut? Ist die Arbeitsbelastung okay und haben alle noch Zeit, in die Mittagspause zu gehen und pünktlich Feierabend zu machen? Gelegentliche Doppelschichten sind okay, aber auf Dauer belasten sie die Mitarbeiter zu stark und führen zu miserablen Ergebnissen, vor allem von Projekt zu Projekt.
7. Projekt abschließen und testen – für Cold Crash haben wir mehrere Testspieler gebeten, das Projekt auf Herz und Nieren zu testen. Da wir damit sehr früh angefangen haben, auch in einer Phase, in der erst die Hälfte des Textes geschrieben war, konnten wir recht früh einen fundamentalen Fehler im Konzept von Cold Crash erkennen und beheben. Hätten wir diesen Fehler erst erkannt, als der Text schon fertig war, hätte es doppelt so viel Arbeit bedeutet, den Fehler zu beheben.

Tl;dr: Wer ein Projekt wie eine App oder ein iOS-Game realisieren will, sollte vorher einen Plan entwerfen, um keine bösen Überraschungen zu erleben.