Die kleine Welt des Projektmanagements
Übersicht
BlitzBasic FAQ und Tutorials
|
hamZtaAdministratorBetreff: Die kleine Welt des Projektmanagements |
 Mo, Jun 23, 2008 1:43Antworten mit Zitat 
|
|---|---|---|
|
„Mein MMORPG braucht eine Serverfarm!“ oder „Die kleine Welt des Projektmanagement“.
In diesem Namen werde ich hier Stück für Stück ein kleines Tutorial bezüglich Projektmanagements anhand einiger Beispiele verfassen und hoffe, dass ich vielleicht dem einen oder anderen damit helfen kann. Im Laufe der Zeit werden sich die Texte ändern, neue hinzukommen oder gar Sachen gestrichen werden. Es lohnt also, immer wieder mal vorbeizuschauen 
Sollte jemand Fehler/Ungereimtheiten finden bitte ich denjenigen, sie mir umgehend zu melden
Den Text werde ich bei Zeiten auch als PDF zur Verfügung stellen. Wichtig Ich will in diesen Texten niemanden bloßstellen/mich über niemanden lustigen machen. Wie ein Forscher ein Lebendobjekt untersucht, untersuche ich ein "Lebendbeispiel" 
Ich repräsentiere mit dem Beispiel nicht die gesamte Community sondern ziehe ein Beispiel heran, welches Fehler deutlich erkennbar werden lässt. Updates
~ Inhaltsverzeichnis ~ 1 Einleitung 1.1 Warum? 1.2 Wie? 1.3 Über den Autor 2 Analyse 2.1 Einleitung 2.2 Häufig gemachte Fehler 4 Gruppenaufbau 4.1 Einleitung 4.2 Klassisches Modell 4.3 Konflikte 4.4 Die Chance - Der Weg einen Konflikt zum Vorteil aller zu nutzen.~update 29.4.2009~ |
||
- Zuletzt bearbeitet von hamZta am Mi, Apr 29, 2009 21:11, insgesamt 7-mal bearbeitet
|
|
hamZtaAdministrator |
Mo, Jun 23, 2008 1:46 Antworten mit Zitat
|
|---|---|---|
|
1 Einleitung
1.1 Warum? Warum schreibe ich diesen Text über Projektmanagement? Schließlich kostet es viel Zeit und Aufwand (noch dazu mitten in der Prüfungszeit der Uni ) und viel Nutzen habe ich doch auch nicht davon.
Ich denke, man könnte Projektleitung und alle damit verwandten Themen als mein Hobby bezeichnen. Es hat mich schon immer interessiert, in welcher Eigendynamik sich Dinge entwickeln wenn man ihnen freien Lauf lässt. Und natürlich wie sie sich entwickeln, wenn man die Fäden in die Hand nimmt, Entwicklungen lenkt und Entscheidungen trifft. Ich werde diesen Text anhand eines Beispiels schreiben und ich hoffe, das Team CryFuture nimmt es mir nicht übel. Am 22. Juni 2008 wurde im BlitzBasic-Portal ein Thread namens „Reamon“ gepostet. Der Threadersteller beschreibt darin ein Projekt des oben genannten Teams. Der erste Gedanke der mir durch den Kopf ging war wohl „Das wievielte Megaprojekt ist das jetzt?“. Ich stöberte etwas im Forum des Teams, an und für sich ja keine schlechte Sache. Übersichtlich, gut lesbar und sicherlich praktisch um „up-to-date“ zu bleiben. Mich hat allerdings nicht die Optik sondern mehr der Inhalt fasziniert. Fasziniert hat es mich, weil ich mir dachte, dass in diesem Forum eigentlich zusammengefasst wird was schon so viele vor dem Team falsch gemacht haben. Der Mitschnitt einer Konferenz über Teamspeak hat dann letztendlich restlos mein Interesse geweckt. Ein grober Fehler übertrifft den anderen, beinahe eine perfekte Vorlage für eine Abhandlung wie diese hier. Und natürlich äußerst amüsant. 1.2 Wie? Wie oben geschrieben, werde ich mich an viele Beispiele aus dem täglichen Leben eines BBP-Moderators halten. Ich möchte die häufigsten Fehler zusammenfassen, Beispiele dazu bringen und somit aufzeigen, wo die Gemeinsamkeiten liegen die diese Projekte schließlich zu scheitern bringen. Danach werde ich etwas Theorie bezüglich Projetmanagement bringen (Theorie klingt immer so staubtrocken, ich werde so gut ich kann versuchen, euch nicht mit Staub zu bedecken ).
Es würde mich sehr freuen, wenn der eine oder andere etwas aus diesem Artikel mitnimmt und in seine Arbeit steckt. Vielleicht kann man ja noch was dazulernen. Bestimmt kann aber auch ich noch einiges lernen, deshalb würde ich mich sehr über Feedback in welcher Form auch immer freuen. 1.3 Über den Autor Fabian „hamZta“ Schlager ist Moderator des BlitzBasicPortals (im folgenden kurz BBP, www.blitzforum.de), hat selbst Erfahrung im Bereich Projektentwicklung bzw. Projektleitung und ... hahaha. Das klingt vielleicht abgehoben. Mein Name ist Fabian, viele werden mich als „hamZta“ kennen. Seit dem 15. November 2006 geistere ich im BBP als Moderator umher, davor war ich viele, viele Jahre Mitglied. Wie die anderen langjährigen Mitglieder hab ich auch schon vieles gesehen, konnte aus meinen und den Fehlern anderer lernen und so Erfahrung sammeln. Neben dem BBP habe ich allerdings auch berufsmäßig an einem Projekt mit kleinem Team mitgearbeitet (und erkannt, wie fatal sich schlechtes Management darauf auswirken kann ). Nebenbei habe ich kleinere Auftragsarbeiten erledigt und bin meinem Hobby als Programmierer nachgegangen.
Ich möchte meine Erfahrung gerne teilen, einerseits weil mich das Thema einfach sehr interessiert und andererseits, weil ich es schade finde, dass das deutsche Blitz-Portal soviele Leichen hervorbringt. Als „Grundbildung“ habe ich die Bücher „The Art of Project Management“ (Scott Berkun, Verlag O‘Reilly) und „Projektmanagement. Softskills für Projektleiter“ (Tomas Bohinc, Verlag Gabal) gelesen, beide Bücher kann ich wärmsten empfehlen. 2 Analyse 2.1 Einleitung In diesem Kapitel will ich Fehler analysieren. Ich will hier keine Wertung abgeben und versuche, objektiv zu bleiben. Weiters versuche ich, die Theorie hier möglichst gering zu halten, diese soll erst in den späteren Kapitel behandelt werden. 2.2 Häufig gemachte Fehler Als Moderator eines relativ großen Forums für Hobbyprogrammierer hat man ja schon so einiges miterlebt. Ich will gar nicht aufzählen wieviele Projekte ich hab‘ sterben sehen (und lassen. Man versuchts ja selbst auch immer wieder ). Im Grunde läuft es immer gleich ab: ein Anfänger hat eine vermeintlich grandiose Idee für ein Projekt. Meistens sind es MMORPGs, ein Genre das wohl durch WoW einen gewaltigen Aufwind bekam. Seltener Strategiespiele oder First Person Shooter. Gemeinsam haben sie alle ihre meist enorme Größe.
Anfangen möchte ich mit dem oben genannten Beispiel „Reamon“. Ich möchte hier wiederholt anmerken, dass ich hier weder bloßstellen noch milde belächeln will. Projektmanagement ist keine leichte Sache. Wenn mal jemand stolpert ist es angebrachter, ihm aufzuhelfen als ihn auszulachen. Beim Stöbern im Forum des Teams fand ich das Protokoll einer Besprechung. Ich weiß nicht, ob es das allererste Protokoll ist aber nachdem es zumindest das erste im Forum ist gehe ich mal davon aus. Hier der Inhalt:
Hier sieht man schnell einige Fehler die gemacht wurden. Das Protokoll besteht im großen und ganzen aus acht Punkten, die spezifischer nicht sein könnten. Es wurde scheinbar über Fortbewegung im Spiel geredet, über Endgegner und scheinbar eine gewisse Gesinnung der Spieler. Was stört hier? Das einzige, was die Mitschrift zum Thema „Fortbewegung“ preisgibt ist, dass sie „erlaubt“ wird. Was heißt „erlaubt“? War sie vorher schon eingeplant, wurde aber erst jetzt beschlossen? Wird sie jetzt erst umgesetzt? Wer setzt sie um? Wie funktioniert die Fortbewegung? Was sind „Mounts“? Ich könnte noch lange so weiterfragen, aber ich denke man sieht gut, worauf ich hinauswill. Ein Protokoll bzw. eine Besprechung/Konferenz (siehe Kapitel 7 „Konferenzen“) dient in erster Linie dazu, Fragen zu beantworten. Das gezeigte wirft allerdings mehr auf als es beantwortet. Für Teammitglieder die neu einsteigen ist es also unmöglich, frühere Besprechungen zu verwerten. Dasselbe trifft für die Punkte 4, 5 und 6 zu, wobei bei letzterem wohl eher die unglückliche Formulierung stört. Interessant ist Abschnitt 2 des Protokolls „Tastenbelegung wird mit dem Anfangsbuchstaben belegt.“. Bevor grundlegende (planungs-)technische Fragen beantwortet werden wird auf ein kleines, zu diesem Zeitpunkt absolut unwichtiges Detail eingegangen. Das nächste Protokoll findet sich in Form eines Chatlogs und eines Mitschnittes einer Besprechung über das Voicechat-Programm „TeamSpeak“. Da ich leider keine Mitschrift der Besprechung habe kann ich nur darauf verweisen (http://rapidshare.com/files/10..._04_08.rar) und jeden, der sich dafür interessiert dazu ermutigen es sich anzuhören da auch hier wieder massive Fehler gemacht werden. Obwohl ich hier nicht näher darauf eingehen und euch auf das Kapitel 7 „Konferenzen“ vertrösten möchte, nehme ich hier einen Punkt heraus: In dem Mitschnitt kommt auf, dass die meisten Teammitglieder (auch die Programmierer!) scheinbar noch nicht lange mit der Programmiersprache „BlitzBasic“ arbeiten. In meinen Augen ist dies eine der großen Gemeinsamkeiten der sogenannten „Megaprojekte“: Anfänger sind noch nicht mit den Feinheiten einer Sprache vertraut und versuchen sich an Projekten enormen Umfangs und sind dadurch schlichtweg überfordert. Ein Fahranfänger setzt sich nicht in einen Rennwagen, ein junger Löwe jagt keine Büffel, eine Fußballmannschaft der Schülerklasse spielt nicht in der Bundesliga. Jeder fängt klein an, das gilt im restlichen Leben genau wie es in der Programmierung gilt. Was viele Anfänger nicht wissen bzw. nicht glaube wollen, gesagt wird es den meisten ja oft genug: Je mehr kleinere Projekte ich abgeschlossen habe, desto größer ist die Wahrscheinlichkeit, dass ich auch ein größeres abschließen werde. Ständiges Scheitern als Folge von Selbstüberschätzung drückt die Lernkurve, kleinere Erfolge durch abgeschlossene Kleinprojekte motiviert ungemein und auf Motivation folgt Lernerfolg. Auch ich habe oft mit dem Problem der Selbstüberschätzung zu kämpfen. Mir wurde ein Auftrag angeboten in dem es darum ging, eine komplexe Webapplikation in kurzer Zeit umzusetzen. Da ich selbst noch relativ unerfahren was Projekte anbelangt war, schlug ich einen sogar noch kürzeren Zeitrahmen vor. Erst bei der Programmierung selbst merkte ich, wieviel Arbeit das eigentlich bedeutet, wieviele wichtige Punkte ich übersehen hatte. Zu meinem Glück wurde das Projekt gleich zu Beginn aufgrund interner Unstimmigkeiten beim Klienten wieder eingestellt. Ich habe diese Chance genutzt und daraus gelernt, bei meinen nächsten Projekten versuchte ich stets, genau zu kalkulieren und auf das Ergebnis noch etwas Zeit draufzuschlagen - Spielraum ist immer hilfreich. 4 Gruppenaufbau 4.1 Einleitung Bevor gute Planung und Entwicklung losgehen kann, muss man erstmal Ordnung und Struktur in sein Team bringen. Erstens damit Verwaltung- und Organisationsaufgaben leichter zu bewältigen sind und zweitens um einen besseren Überblick bei Problemen o.ä. zu haben. 4.2 Klassisches Modell Wichtig für ein Team ist, dass jedes Mitglied eine Rolle bekommt. Jeder Mitarbeiter muss sich mit dem Projekt identifizieren können, sagen können „Ich kümmere mich um Modul XY!“. Was man dadurch erhält ist eine Gruppe von Spezialisten, jeder mit eigenen Spezialgebiet in dem er sich (im Idealfall) perfekt auskennt und kompetent ist. Teilt man diese Spezialisten noch in Gruppen ihrer Gebiete auf und ernennt einen von ihnen zum Gruppensprecher, so hat man eigentlich schon das klassische Modell eines Teams.  
Abbildung 1: Klassische Teamstruktur Was man in Abbildung 1 sieht zeigt den Weg, den Informationen vom Projektleiter zum Mitglied nehmen, nämlich nicht direkt, sondern über den Gruppenleiter. Was für Vorteile hat dieses Modell? Konferenzen bleiben übersichtlich da nur die Gruppenleiter anwesend sein müssen, der Projektleiter kann seine Informationen „raushämmern“ und sich zurücklehnen, „fire and forget“, die Gruppenleiter sind an der Reihe. Die Nachteile? Jeder, der schon mal stille Post gespielt hat kennt das Problem vielleicht: Am Ende kommt was anderes raus als man Anfangs reingesteckt hat. Der Projektleiter muss sich darauf verlassen können, dass die Gruppenleiter wirklich alles richtig verstanden haben. Einen gravierenden Nachteil darf man allerdings nicht vergessen: Der Projektleiter kann seine Informationen „raushämmern“ und sich zurücklehnen, „fire and forget“, die Gruppenleiter sind an der Reihe. Nein, das ist kein Fehler, ich hab‘ den Satz absichtlich kopiert. Warum? Für unerfahrene Projektleiter kann dieser Punkt zum Verhängnis werden. Ein Projektleiter darf sich nicht zurücklehnen und die Verantwortung abgeben. Er muss auch mit den einzelnen Mitgliedern kommunizieren, mit Gruppenleitern ausserhalb der Konferenzen reden und somit Probleme schneller erkennen und lösen. Näheres dazu jedoch später. Ich bin zwar kein Freund des Militärs, aber ich will trotzdem erwähnen was die Christbaumschmuckträger richtig machen: Sie teilen ihre Truppen in genau solche Gruppen ein, kleben einem einen Stern an die Brust und ernennen ihn somit zum Anführer der Gruppe. Was erreicht man dadurch? Die Gruppe hat ein gemeinsames Ziel, euphorischer gesagt, eine Vision. Die Tatsache, dass mehrere Menschen dasselbe anstreben und merken, dass sie in der Gruppe „stärker“ sind schweißt das Team zusammen, es beginnt zusammenzuhalten. Damit verringert man zwar die Chance auf Konflikte innerhalb einer Gruppe, fördert aber mit einer gewissen Wahrscheinlichkeit die Konflikte zwischen den einzelnen Gruppen. Warum das so ist und was man dagegen machen kann werde ich, erklärt Hyde (danke!) in einem eigenen Kapitel. Das oben genannte Modell setzt natürlich eine gewisse Größe des Projektteams voraus, bei kleineren Teams, in denen zum Beispiel nur ein Mitglied pro Aufgabenbereich (Programmierung, Grafikdesign, etc.) mitarbeitet läuft es aber im wesentlichen gleich ab, die Rolle des Gruppenleiters fällt weg. Stoßt jedoch eine zweite Person zu einer „Gruppe“ dazu, so macht es sofort Sinn, einen zum Gruppensprecher/-leiter zu ernennen, einmal um dem Mitglied einen direkten Ansprechpartner zur Seite zu stellen und andererseits um nicht alles organisieren zu müssen wenn die Gruppe dann größer und größer wird - da ists dann nämlich zu spät. Natürlich ist dies nur eine Form eines Teammodells. In meinen Augen ist es aber eine der einfachsten und natürlichsten, wenn man bedenkt, dass Menschen sich schon immer in Rudeln organisiert und einen „Anführer“ hatten. Sollte jemand noch gute Beispiele für andere Teammodelle so kann er mir diese sehr gerne zuschicken, ich werde versuchen, sie hier zu beschreiben. 4.3 Konflikte von Roman "Hyde" E. Warum führen gefestigte Kleingruppen quasi automatisch zu Konflikten zwischen den Gruppen und wie könnte man das eventuell umgehen? Durch die Festigung der Kleingruppen entwickeln diese Eigendynamiken, die höchsten Falls an die Großgruppe (der Einfachheit halber nenne ich diese im Folgenden Team) angelehnt sind. Es kann also zu einer Abweichung von den vorher gemeinsam ausgehandelten Zielen kommen. Das wiederum liegt daran, dass von vorne herein jedes Teammitglied eigene Vorstellungen hat und diese auch niemals vollständig ablegen wird. Im Team müssen alle etwas von ihrer Vorstellung abweichen und je mehr Teammitglieder es gibt, desto mehr Ideen müssen integriert werden. Das Ergebnis entspräche in etwa dem Durchschnitt aller individuellen Ideen. Nun kommt das Problem. Da die Kleingruppen aus jeweils wenigen aber insgesamt sehr unterschiedlichen Individuen zusammengesetzt sind findet erneut eine Aushandlung statt. Diesmal aber jeweils in den Kleingruppen. Dass die unterschiedlichen Gruppen nicht zu dem selben Ergebnis kommen dürfte klar sein. Interessant hierbei ist noch, dass die meisten Konflikte entstehen, wenn sich zwei Gruppen sehr ähnlich entwickelt haben. Während sehr unterschiedliche Kleingruppen die Notwendigkeit von Kompromissen recht schnell erkennen, kommt es zwischen den sehr ähnlichen Kleingruppen zu heftigeren Auseinandersetzungen, da jeder seine Vorstellungen durchsetzen möchte. Um diese doch etwas komplexen Strukturen zu verdeutlichen habe ich mir ein Beispiel überlegt: Eine Gruppe von 9 Leuten sitzt zusammen. Ihr gemeinsames Ziel ist, gemeinsam den Abend zu verbringen. Nehmen wir nun an, dass es zwei Möglichkeiten gibt das festzulegen. Entweder in der gesamten Gruppe, was vermutlich Zeitraubend wäre, oder in 3 Kleingruppen zu je 3 Leuten die pro Gruppe einen Vorschlag ausarbeiten sollen. Gruppe: Erstmal sollten alle Ideen gehört werden, jeder die Möglichkeit haben sich für oder gegen einen Vorschlag äußern zu können um so zu versuchen den Gruppenwillen festzustellen. Nehmen wir nun an man einigt sich darauf ins Kino zu gehen. Das ist dann zwar nicht dass, was jeder einzelne gerne hätte, aber letztendlich können sich alle damit abfinden. Anders nun bei 3 Kleingruppen. Hier kommen die individuellen Wünsche jeweils viel stärker zum Ausdruck und gehen nicht im Gruppenwunsch unter. Nun werden sich 3 Personen aus einer Kleingruppe auf ein Konzept einigen. Gruppe 1 könnte vorschlagen einen DVD-Abend zu machen. Gruppe 2 könnte sich einen Kneipenbesuch wünschen und Gruppe 3 hätte sich vielleicht auch fürs Kino entschieden. Nun haben wir zwar nicht mehr 9 Wünsche sondern nur noch 3, dafür wird aber jeder Vorschlag von 3 Leuten unterstützt. Es käme also zum Konflikt. Die Kneipengruppe würde schnell einsehen, dass sie in Unterzahl ist. Dagegen gäbe es eine Auseinandersetzung zwischen den DVD- und den Kinoanhängern. Hier sind die Unterschiede geringer. Da jede Kleingruppe ihre Wünsche bevorzugen wird, diese sich aber von den anderen Kleingruppen unterscheiden aber jede Kleingruppe im Gegensatz zum Einzelnen genug Unterstützer hat ist meist ein "Entweder-Oder" unausweichlich. Aber wie kann man einen solchen Konflikt nun lösen oder wie könnte man ihn gar versuchen zu umgehen? Als Lösung würde sich bei unseren Freizeitgestaltungsgruppen ein Vermittler anbieten, der eine demokratische Abstimmung, der sich dann auch alle fügen sollten, initiieren könnte. Um das Problem des Vermittlers von Anfang an zu umgehen und um möglichen Konflikten im Team vorzubeugen sind Planung und Aufteilung das wichtigste, neben der individuellen Leistungen sich auch mal zurücknehmen zu können, nicht nur den eigenen Willen durchsetzen wollen und auf Vorschläge der anderen Teammitglieder einzugehen. Natürlich gibt es unzählige Möglichkeiten Konflikten vorzubeugen bzw. sie vernünftig zu lösen, welche die Beste ist hängt auch mit der jeweiligen Situation zusammen, aber eine mögliche Variante, wie ein Team organisiert sein sollte wäre diese: Da es sehr lange dauern würde jedes Detail im kompletten Team auszuhandeln, sollte höchstens ein grober Fahrplan sowie die Kleingruppeneinteilung und die Aufgabenverteilung gemeinsam festgelegt werden. Wichtig hierbei: Es sollte möglichst keine Überscheidungen von mehreren Kleingruppen für eine Aufgabe geben. In solch einem Fall wäre ein Konflikt vorprogrammiert. Jede Kleingruppe sollte für ihren Aufgabenbereich Entscheidungshoheit haben in die sich nur der Projektleiter einmischen darf. Durch die strikte Trennung der Kleingruppen sollte in jeder Gruppe klar sein, was die Aufgabe der Kleingruppe ist. Koordiniert werden sie vom Projektleiter, der bei Unklarheiten auch immer erster Ansprechpartner sein sollte, um Widersprüche und gegensätzliche Auffassungen von anderen Teammitgliedern zu vermeiden. 4.4 Die Chance - Der Weg einen Konflikt zum Vorteil aller zu nutzen. von Roman "Hyde" E. Im vorherigen Kapitel wurde beschrieben, wie man einen möglichen Konflikt lösen kann, oder von vorne herein zu vermeiden versuchen kann. Nun möchte ich darauf eingehen, welchen Nutzen Konflikte für ein Projekt haben können und wie man diesen erkennt. Ein Konflikt besteht, wie bereits beschrieben, aus mindestens zwei unterschiedlichen Positionen, die aus unterschiedlichen Ideen und Auffassungen entstanden sind. Ich behaupte, dass jede, noch so geniale Idee, Schwachstellen hat, Punkte über die man noch nicht nachgedacht hat oder als nebensächlich oder gar unwichtig eingestuft hat. Allerdings ist es so, dass jedes Individuum den einzelnen Punkten eine ganz andere Priorität zuteilt. Das fällt aber nur auf, wenn man mit verschiedenen Individuen eine Idee bearbeitet. Dabei ist es nun aber enorm wichtig, dass derjenige, der die Idee vorstellt Kritiken nicht als "unwichtig" abtut, sondern diese genau prüft. Der nun (hoffentlich) entstehende Kompromiss dürfte den Durchschnitt, und somit die Auffassung der meisten Individuen eher treffen, als die Position des einzelnen Individuums. Kompromisse, die aus Konflikten hervorgehen helfen also einer Idee zu reifen und sie zu vervollständigen. Natürlich gilt es hier auch, wie immer, die "goldene Mitte" zu treffen, was kein leichtes Unterfangen sein dürfte, aber mit mehreren Köpfen durchaus annähernd erreichbar sein sollte. Destruktiv wäre aber trotzdem "Kritik um jeden Preis". Etwas anders zu machen, nur um es anders zu machen, ist nicht der richtige Weg um das gewünschte Ergebnis zu erreichen. Wichtig ist hierbei auch die Persönlichkeit desjenigen, der die Idee vorgestellt hat zu beachten. Zerredet man seine Idee in Grund und Boden, dürfte ihm die Motivation genommen sein, sie weiter zu entwickeln, denn in der Regel hat jede Idee positive Aspekte, die es auch in der Kritik hervorzuheben gilt. Gute Kompromisse schaffen also etwas Neues, dass für alle ein Gewinn sein sollte. |
||
- Zuletzt bearbeitet von hamZta am Mi, Apr 29, 2009 21:09, insgesamt 4-mal bearbeitet
|
Firstdeathmaker |
Mo, Jun 23, 2008 10:46 Antworten mit Zitat
|
|---|---|---|
|
Wie wäre es mit ein paar konkreteren Tipps? Ich meine das meiste was du bisher gesagt hast ist Kritik an diesem einen speziellen Team. Wie wäre es vielleicht auch mal mit einem positivbeispiel (vllt. aus eigener Erfahrung). Ich weis es ist schwer, weil es bestimmt in jedem Team nicht perfekt läuft, aber einige Sachen können doch bestimmt irgendwo mal wirklich gut gelungen sein?
Mich interessiert das Thema sehr, arbeite ja zur Zeit in einem kleinen Team (kommerziell). Als einen sehr wertvollen Tipp kann ich schon einmal geben: Designdokumente. Im Designdokument werden die verschiedenen Screens (z.B. Hauptmenü, Optionsmenü, Highscoremenü, Spielmenü -> die verschiedenen Spieluntermenü's etc.) genau beschrieben (einerseits Aussehen, andererseits Funktionalität). Dadurch bekommt man schonmal eine gute Struktur in das ganze Programm. Allerdings sollte das ganze am Anfang nicht zu sehr ins Detail gehen was die technische Umsetzung angeht. Zum anderen kann man vielleicht auch ein weiteres Designdokument nur für den Spielinhalt einführen (sofern das Projekt dafür groß genug ist). In diesem wird dann z.B. die Spielwelt beschrieben, die verschiedenen Charaktere vorgestellt (immer vorausgesetzt man hat soetwas) oder Spielgegenstände und Prinzipien vorgestellt. Nicht hier herein gehören bei RPG's z.B. Questsbeschreibungen. Wohl aber was dabei alles möglich sein soll. Durch Designdokumente können die einzelnen Teammitglieder auch zwischendurch wenn sie arbeiten schnell nachschlagen was jetzt wie gemacht werden soll. In Besprechungen gemachte Änderungen und Entscheidungen sollten möglichst in die einfliessen, sodass diese "up-to-date" sind. Dadurch, dass vielleicht erstmal nur eine einzelne Person das Designdokument verfasst und erst nachher in einer Teambesprechung über die einzelnen Änderungswünsche gesprochen wird, hat man auch konkrete Punkte die wichtig sind. Und zum Thema Besprechungen: Wenn man mit oben beschriebenen Designdokumenten arbeitet, kann jedes Teammitglied vor einer Besprechung Notizen machen was er genau für Fragen hat welche das Designdokument nicht behandelt. |
||
|
www.illusion-games.de
Space War 3 | Space Race | Galaxy on Fire | Razoon Gewinner des BCC #57 User posted image |
||
|
|
hamZtaAdministrator |
Mo, Jun 23, 2008 12:49 Antworten mit Zitat
|
|---|---|---|
|
In meinem ersten Post steht, dass der Artikel noch nicht fertig ist
Danke trotzdem für dein ausführliches Feedback, auf Pflichtenhefte bzw. Designdokumente werde ich noch genauer eingehen. hamZta |
||
| Blog. | ||
|
aMulSieger des Minimalist Compo 01/13 |
Mo, Jun 23, 2008 15:03 Antworten mit Zitat
|
|---|---|---|
|
Ich freu mich schon sehr auf die nächsten Teile. Finde das Thema auch sehr interessant.
Von dem was du bisher geschrieben hast, schaut es sehr vielversprechend aus.
|
||
|
Panic Pong - ultimate action mashup of Pong and Breakout <= aktives Spiele-Projekt, Downloads mit vielen bunten Farben!
advASCIIdraw - the advanced ASCII art program <= aktives nicht-Spiele-Projekt, must-have für ASCII/roguelike/dungeon-crawler fans! Alter BB-Kram: ThroughTheAsteroidBelt - mit Quelltext! | RGB-Palette in 32²-Textur / Farbige Beleuchtung mit Dot3 | Stereoskopie in Blitz3D | Teleport-Animation Screensaver |
||
|
tft |
Mo, Jun 23, 2008 15:54 Antworten mit Zitat
|
|---|---|---|
|
Hallo ...
ja sehr interesant. Werde es immermal nachschlagen. gruss TFT |
||
|
TFT
https://www.sourcemagic.ch Monkey,HTML5,CSS3,W 10 64 Bit, 32 GB Ram, GTX Titan, W8 ist Müll !!!!!! |
||
|
Thorsten |
Mo, Jun 23, 2008 16:24 Antworten mit Zitat
|
|---|---|---|
|
Ein Beispiel wie die TeamSpeak Aufzeichnung heranzuziehen ist wirklich brutal.
Das repräsentiert nicht im Allgemeinen die Community. Außerdem, lässt du dich nur über diese Anfänger aus, die wirklichen Anfänger würden das hier nämlich nie im Leben lesen; man muss sich nur mal anhören was die träumen (von wegen selber verkaufen, aber erst seit ein paar Tagen bei BB). Ich finde, es gehört auch einfach dazu, mal selber zu merken, dass soetwas nicht umsetzbar ist; daraus lernt man viel besser als wenn man es von einem User hört. An CryFuture : Sorry, aber so eine Aufzeichnung rauszubrechen, ist peinlich. mfG, Thorsten |
||
|
FireballFlame |
Di, Jun 24, 2008 3:20 Antworten mit Zitat
|
|---|---|---|
|
Thorsten hat Folgendes geschrieben: die wirklichen Anfänger würden das hier nämlich nie im Leben lesen
Wieso sollten das die Anfänger nicht lesen wollen? Anfänger muss ja nicht gleich heißen, naiv oder uneinsichtig Aber ja, wohl fast jeder nimmt sich anfangs was ziemlich Großes vor, was dann nichts wird. Bei mir war's ein kleiner Egoshooter, aber nachdem ich nach vielen Tagen die Steuerung und den ersten Gegner hatte, hatte ich keine Lust mehr ^^
Ich find den Text jedenfalls sehr interessant! Bin schon auf die anderen Teile gespannt
|
||
|
PC: Intel Core i7 @ 4x2.93GHz | 6 GB RAM | Nvidia GeForce GT 440 | Desktop 2x1280x1024px | Windows 7 Professional 64bit
Laptop: Intel Core i7 @ 4x2.00GHz | 8 GB RAM | Nvidia GeForce GT 540M | Desktop 1366x768px | Windows 7 Home Premium 64bit |
||
|
|
Thorsten |
Di, Jun 24, 2008 12:34 Antworten mit Zitat
|
|---|---|---|
|
FireballFlame hat Folgendes geschrieben: Thorsten hat Folgendes geschrieben:
Anfänger muss ja nicht gleich heißen, naiv oder uneinsichtig Wenn es um Megaprojekte geht drücke ich es mal so aus : "von sich selbst überzeugt" mfG, Thorsten |
||
|
|
hamZtaAdministrator |
Di, Jun 24, 2008 19:02 Antworten mit Zitat
|
|---|---|---|
|
Thorsten hat Folgendes geschrieben: Ein Beispiel wie die TeamSpeak Aufzeichnung heranzuziehen ist wirklich brutal.
Das repräsentiert nicht im Allgemeinen die Community. Ich will auch nicht die Community repräsentieren. Ich will ein Beispiel aus dem "echten Leben" heranziehen
Thorsten hat Folgendes geschrieben: Außerdem, lässt du dich nur über diese Anfänger aus, die wirklichen Anfänger würden das hier nämlich nie im Leben lesen;
Wer interessiert ist, der liest es. Wer nicht, der liest es nicht. Ich hab hier keinen Bildungsauftrag zu erfüllen
Thorsten hat Folgendes geschrieben: Ich finde, es gehört auch einfach dazu, mal selber zu merken, dass soetwas nicht umsetzbar ist; daraus lernt man viel besser als wenn man es von einem User hört.
Na klar lernt man schneller wie gefährlich Strom ist, wenn man mal in die Steckdose greift. Aber ich denke, ein kleiner Schups in die richtige Richtung ist vielleicht hilfreich (Außerdem kann ich dann später "Told you so!" sagen ).
Thorsten hat Folgendes geschrieben: An CryFuture : Sorry, aber so eine Aufzeichnung rauszubrechen, ist peinlich.
Bitte gib hier keine Wertung über die Besprechung ab, darum gehts nicht und soll es auch nicht gehen. Danke für dein Feedback! Und natürlich auch danke an alle anderen! Hab Donnerstag & Freitag noch 3 Prüfungen, danach wird es weitergehen. hamZta |
||
| Blog. | ||
|
DAK |
Mi, Jun 25, 2008 6:56 Antworten mit Zitat
|
|---|---|---|
| Aja, Cryfuture hat gestern ihr Hauptprojekt (Reamon) aufgegeben... | ||
| Gewinner der 6. und der 68. BlitzCodeCompo | ||
|
Casiopaya |
Mi, Jun 25, 2008 7:34 Antworten mit Zitat
|
|---|---|---|
|
Hallo
brilliant. Ich war nun bei Studienprojekten (jeweils ein Jahr Uni-Software-Entwicklung im 10 Mann-Team) einmal Projektleiter und einmal QS. Bin sehr gespannt auf weitere Einträge  . Ich denke dieser Thread wird vielen, die in der ingenieursmäßigen Software-Entwicklung anfangen möchten, helfen.
Grüße Casiopaya |
||
Nuramor |
Mo, Jun 30, 2008 15:13 Antworten mit Zitat
|
|
|---|---|---|
|
Hallo
ich bin einer aus dem besagtem CryFuture Team ^^ ... und es stimmt schon teilweise was da steht !!! einiges ist übertrieben bis falsch aber im Prinzip haben wir wirklich viele Fehler am Anfang gemacht
Wir haben nun aufgeräumt und sind zuversichtlich das wir es beim 2ten Anlauf besser machen werden ^^ Jeder muss seine Erfahrungen meine ich in diesem Bereich selber machen ! Ich find es gut das wir diese Fehler gemacht haben denn nur so konnten wir aus ihnen lernen. EIn Projekt was diese Fehler nicht gemacht hat, kommt vll. an einem späterem entscheidendem Punkt an diese Probleme und zerbricht so! naja
Ganz ehrlich ich nehme es euch nicht übel uns als negativ Beispiel genommen zu haben
Möchte aber darauf hinweisen das sich einiges geändert hat ^^ |
||
|
|
hamZtaAdministrator |
Fr, Jul 04, 2008 14:26 Antworten mit Zitat
|
|---|---|---|
|
Ich hab letztens irgendwo ein Zitat gelesen, weiß leider nichtmehr wo, aber es lautete ähnlich wie folgendes:
Zitat: Der Dumme lernt aus seinen Fehlern, der Kluge aus den Fehlern der anderen.
Wird den alten Chinesen zugeschrieben, ich finds etwas hart formuliert, aber die Kernaussage bleibt sich gleich. Finde es gut, dass ihr eure Fehler erkannt habt, Nuramor, und drücke euch für den zweiten Anlauf die Daumen. Vielleicht könnt ihr ja aus diesem Artikel ein paar Anregungen mitnehmen! hamZta |
||
| Blog. | ||
|
Mr.HydeNewsposter |
Mi, Jul 09, 2008 20:00 Antworten mit Zitat
|
|---|---|---|
|
Ja ich wusste wirklich nichts davon, dass ich diesen Teil schreiben sollte, Herr hamZta ging einfach mal davon aus. Und da Dreistigkeit ja siegt, bitte hier mein Beitrag über Konflikte in Teams. Viel Spaß beim lesen.
|
||
|
BBP News RSS | Chaos Interactive | Watanien 2 Screens, Infos und Download | Watanien 2 Worklog | PuzzleMasters
http://abgeordnetenwatch.de - http://www.regierungs-beratung.de - Der Regierung auf die Finger schauen |
||
|
Hagbard |
Do, Jul 10, 2008 20:45 Antworten mit Zitat
|
|---|---|---|
|
Gefällt mir richtig gut. Ich lese mir solche Dinge, die auch psychologischen Hintergrund haben sowieso immer sehr gerne durch. Ich hoffe, dass wir alle daraus lernen und das gerne auch als Referenz für neue Mega-Projekte verwenden können.
In dem Sinne, noch viel Erfolg, ich freue mich schon auf die Fortsetzung. |
||
|
|
hamZtaAdministrator |
Mi, Apr 29, 2009 21:11 Antworten mit Zitat
|
|---|---|---|
|
*push*
Dank an Hyde, er hat noch ein Kapitel für mich geschrieben
|
||
| Blog. | ||
Übersicht
BlitzBasic FAQ und Tutorials
Powered by phpBB © 2001 - 2006, phpBB Group