projekte - Einträge für Mai 2008

  • Mai, 2008
  • Projektleiter der Welt vereinigt euch! ::: Blogparade

    Vor dem letzten 1. Mai bin ich an einem Schild vorbei gekommen, auf dem stand „Proletarier der Welt vereinigt euch!“ Dummerweise habe ich das nicht richtig gelesen und dachte dann; es heißt „Projektleiter der Welt vereinigt euch!“ Im Prinzip ist es das Gleiche :-) In Firmen ist der gemeine Projektleiter ein Einzelkämpfer. Firmen haben im Normalfall mehr Projekte als Mitarbeiter. Also muss darum gestritten werden, wer die wertvollen Mitarbeiter bekommt. Und oft gilt dabei, dass der lauteste Brüllaffe die Ressourcen zugeteilt bekommt. Ok, bisher hatte ich Glück und war der beste Brüllaffe. Aber eigentlich müsste das auch anders möglich sein, oder? Also warum vereinigen sich die Einzelkämpfer nicht und bringen die Projekte „gemeinsam“ durch? Häufig ist das so, weil die Projektleiter so erzogen worden sind und glauben nur dann ihre Projekte zum Ziel führen können, wenn sie die anderen Projekte aus dem Weg räumen. Ich habe es schon ein paarmal probiert und es klappt auch ohne gegeneinander zu kämpfen. Wie es überall im Leben so ist, oft geht es auch einfach besser, wenn man die Mitarbeiter gemeinsam einplant und managed. Das ist zumindest meine Meinung. Man muss zwar aufpassen, dass die Projekte fair mit Mitarbeitern ausgestattet werden und die einzelnen Projektleiter ihren Job durchführen können, jedoch das Einzelkämpferdasein halte ich für ziemlich idiotisch.

    Blogparade zu folgenden Fragen

    • Was sind eure Erfahrungen?
    • Arbeitet ihr mit euren Projektleiterkollegen zusammen oder führt ihr ein Einzelleben?
    Eine kleine Diskussion zu diesem Thema fände ich toll... Teilnehmen könnt ihr an der Blogparade bis einschließlich 16. Juni, sowohl in den Kommentaren, als auch mit Beiträgen auf eurem Blog. Ich bin gespannt auf eure Berichte.

    Verlängerung bis  24. Juni

    Wer noch mitdiskutieren möchte, kann bis noch bis einschließlich zum 24. Juni, teilnehmen.
  • Bücherliste zu Webdesign, Projektmanagement, Informatik usw.

    Hier im Blog gibts ja bereits die Quellenliste zu Requirements Engineering. Inzwischen ist auch unsere Bücherliste, mit den bei miradlo genutzten, Büchern online. Ganz vollständig ist sie noch nicht, aber wir arbeiten dran. Da es einfacher ist, diese Liste als eigenständige Seite, laufend zu aktualisieren, habe ich mich entschlossen, sie außerhalb des Blogs im allgemeinen Bereich unterzubringen. Die Bücherliste enthält die Titel, die in unseren Bücherregalen zu finden sind. Angefangen haben wir bereits mit Kurzkommentaren zu den Büchern, so dass ihr nachschauen könnt, welche Bücher wir für besonders empfehlenswert halten. Die Kommentare werden wir im Lauf der Zeit noch ergänzen, die Liste als solche natürlich ebenfalls. Wir haben Bücher aus folgenden Bereichen aufgeführt:
    • CSS
    • Webdesign
    • Linux
    • Projektmanagement
    • Informatik
    • Programmieren (PHP, Java...)
    • Usability, Barrierefreiheit usw.
    • Design
    Darüber hinaus haben wir eine kleine Serie der diversen Versionen des Dudens. Das Kochbuch für Geeks ist ebenfalls dabei, eine gute Freundin hat mir das geschenkt. Sicherlich nicht in der Hoffnung, dass ich deshalb koche, sondern eher als Anregung, was ich mir von den kochenenden Menschen in meiner Umgebung wünschen könnte und einfach so zum Amüsieren. Ja, es stimmt, was ihr daraus schließt: ich koche nicht, auch nicht ein bisschen, auch nicht ab und zu. Zumindest dann nicht, wenn es nicht zählt, Tiefkühlgemüse in der Mikrowelle zu erhitzen und wenn die Definition ist, dass Salat nicht gekocht wird. ;-)
  • Episode 8: Vorstudie strukturieren ::: Softwareprojekte

    Ein Projekt ist einmalig. Es ist mit gewissen Risiken verbunden und ist, da es einmalig ist, nicht mit einem anderen Projekt direkt vergleichbar. Das ist eine in allen Lehrbüchern beschriebene Tatsache. Wenn Projekte einmalig sind, wieso geht man dann immer mehr oder weniger gleich an Projekte heran? Ganz einfach: Projekte können anhand bestimmter Eigenschaften klassifiziert werden. Und so ist die Herangehensweise natürlich pro Projekttyp sehr ähnlich. Wenn ich hier jetzt beschreibe, wie die Vorstudie zu strukturieren ist, kann das keine allgemeingültige Beschreibung sein. Es ist eine mögliche Art die Vorstudie zu strukturieren. Wenn man nichts hat, kann man sich hier ein paar Ideen herausfischen. Andere Themengebiete sind nicht relevant oder durch diese Vorstudie nicht abgedeckt. Also: Selber kreativ sein und Hirn einschalten! Nicht alles was Roland sagt stimmt. Normalerweise laber ich sogar ziemlich viel Mist. Das kommt daher, dass es keine einzige Wahrheit gibt. Die Projektmanagementwelt ist bunt und nicht schwarz- weiß. Thomas befragte in der ersten Woche die Entwickler, Giuseppe, den Familienvater der anderen Firma und einige schwere Jungs. Thomas ist (so wie ich) ein bisschen schwer von Begriff. Aber nach der Woche war ihm klar, dass er sich mit einer kriminellen Vereinigung eingelassen hatte und so schnell da nicht mehr herauskommen wird. Welchen Zweck die Betonschuhe und der Familienteich haben wurde ihm auch klar. „Was solls, wenn man schon Mist baut, dann wenigstens Spaß dabei!“, sagte er sich. Da an kündigen nicht zu denken war, entschied Thomas sich das Projekt durchzuführen. Er erstellte eine Vorlage für eine Vorstudie mit folgenden Kapiteln (zu den Begriffen siehe Glossar Informatik):

    Einleitung / Management Summary

    Hier wird auf maximal einer Seite beschrieben was mit dem zu erstellenden System erreicht werden soll. Es soll den Auftraggebern eine Zusammenfassung geben, was sie erhalten und die wichtigsten Eckpunkte auflisten.

    Systemübersicht

    Falls möglich, sollte gleich eine sehr grobe Systemübersicht dargestellt werden.

    Anforderungen

    Auflistung der Eigenschaften die dieses System haben soll. Die Anforderungen werden in funktionale und nicht-funktionale Anforderungen aufgegliedert. Hier kann schon mit Usecases gearbeitet werden. Wie die Anforderungen zusammen gesammelt werden ist im Prinzip nicht wichtig. Hauptsache sie sind eindeutig identifizierbar und so vollständig wie möglich. Beispielsweise kann man jeder Anforderung eine Nummer geben. Diese Nummer kann man später wieder verwenden.

    Funktionale Anforderungen

    Hier wird beschrieben was man mit dem System später machen kann. Zum Beispiel „Anf#82: Verwalten der schweren Jungs“ oder „Anf#98 Auflistung wie viel Schmuggelware abgegeben wurde“ Weiterhin sind funktionale Anforderungen die Beschreibung der Schnittstellen und anzubindenden Systeme.

    nicht-funktionale Anforderungen

    Wie der Name schon sagt- handelt es sich hier um Anforderungen, die nichts direkt mit der Funktion zu tun haben. Im Prinzip ist es egal ob eine Berechnung 100 Tage benötigt. Wenn nach 100 Tagen das Ergebnis der Berechnung vorliegt, hat die Funktion funktionert. Eventuell sind 100 Tage aber ein bisschen lange um 20+30 zu rechnen ;-)

    Sicherheitsanforderungen

    Welche Personen dürfen auf welche Daten zugreifen? Wie schützen wir uns vor anderen Familien oder der Steuerbehörde?

    Geschwindigkeit

    Wie lange darf eine Bearbeitung dauern?

    Mengengerüste

    Wie viele Mitarbeiter, Daten und Zugriffe sind zu erwarten?

    Betreibbarkeit

    Welche Service Levels müssen vereinbart werden? Vor allem bei einem System, indem Personen direkt betroffen sind, muss man sich hier besonders viel Gedanken machen. Wie viel Wartungsfenster sind zu erwarten? Welche weiteren Kriterien sind hier zu beachten? (Rechenzentrumeigenschaften usw.)

    Rechtliche Fragen

    Was erlaubt das Gesetz? Im Fall der Familie: was ist erlaubt und was wird geahndet?

    Desaster Recovery

    Wie schnell müssen welche Funktionen nach einer Katastrophe wieder verfügbar sein? Welche Vorgaben sind in der Firma vorhanden?

    Business Continuity

    Wie wird gewährleistet das im Katastrophenfall die Geschäfte weiter getätigt werden können? Von welchen IT-Systemen ist die Firma abhängig?

    Wartbarkeit

    Gibt es spezielle Anforderungen an die Wartbarkeit der Systeme? Beispielsweise sind die Legacy Systeme weiterhin zu warten. Wie soll das gewährleistet werden?

    Erweiterbarkeit

    Jedes System muss erweiterbar sein. Wo sind die Grenzen? Woran kann erkannt werden, dass diese Grenzen erreicht werden?

    Dokumentation

    Welche Dokumentation (Betriebsdokumente, Sourcecode Beschreibung usw.) muss erstellt werden?

    Stakeholder

    Welche Personengruppen sind im späteren Projekt zu beachten? Je politischer ein Projekt ist, desto wichtiger ist es zu wissen, wen man alles informieren muss. Dieser Punkt kommt zwar später wieder in der Projektbeschreibung, doch schadet es nichts, sich schon sehr bald darüber klar zu werden, wer alles betroffen ist.

    Abgrenzungen

    Was ist nicht Aufgabe dieses Systems? Diese Frage ist sehr wichtig. Ansonsten wird man mit ungeplanten Anforderungen zugeschüttet. Beispielsweise ist das bestehende System deshalb so komplex, da während des Erstellens immer neue Anforderungen hinzugefügt wurden. Hier kann erkannt werden, dass die Vorstudie unter Umständen schon ein eigenes Projekt ist. Bei großen Systemen wird daher die Vorstudie schon als Evaluationsprojekt durchgeführt. Egal wie groß ein Projekt ist, ich kann nur empfehlen eine gewissenhafte Vorstudie durchzuführen. Jede Überlegung in diesem Bereich spart euch hinterher das Vielfache an Ärger, Fehlern und Aufwänden!
  • Episode 7: Requirements für die Vorstudie ::: Softwareprojekte

    An einem verregneten Morgen kam Giuseppe mit einem Fremden zur Türe herein. Hans, Karl und Orlando waren sofort ziemlich nervös. Nie kam Giuseppe persönlich zu ihnen in die Häckerecke. „Ich möchte euch über unsere neuesten Familienaktivitäten unterrichten“, begann Giuseppe. „Wir haben mit einer Familie in einer anderen Stadt funssioniert. Unsere Geschäftsfelder passen optimal zusammen. Die neue Familie hat sich auf die Verteilung von bewusstseinserweiternden Mitteln spezialisiert. Wir sind gut im Geld waschen und zusammen können wir sehr viel Profit für die Familien erwirtschaften. Die andere Familie hat ebenfalls ein Verwaltungssystem und wir müssen unsere Systeme miteinander verschmelzen.“

    Orlando war begeistert

    „Das ist ja toll! Da können wir sicher voneinander profitieren und neue Integrationsmethoden lernen.“ Hans und Karl standen etwas abseits und ihre Gesichtsfarbe glich der Wand. Sie waren schneeweiß. Hans stotterte: „Das bedeutet nicht nur neue Funktionalität sondern eine Erweiterung der Basisfunktionalität. Wir haben kein System erstellt das mandantenfähig oder auf Austausch mit anderen Systemen ausgelegt ist.“ Giuseppe grinste: „Bevor wir weiter reden möchte ich euch Thomas vorstellen. Thomas ist ein Softwarearchitekt und Projektleiter der im Bereich der Fusionierung von Firmen schon mehrmals wahre Wunder vollbracht hat. Wir haben ihn eingestellt um die beiden Firmen sicher miteinander verbinden zu können. Weiterhin haben wir diverse Expansionspläne erarbeitet. Dem Familienrat ist klar, dass unsere heutigen Verwaltungssysteme uns nicht weiter optimal unterstützen können. Das bedeutet wir werden investieren und ihr braucht euch vorerst keine Sorgen um Betonschuhe und Tauchgänge machen.“ Giuseppe verabschiedete sich und Thomas ließ sich von den Dreien in die bestehende Umgebung einführen.

    Eintrag in das Projekttagebuch von Thomas

    Wie immer endete der erste Tag mit „das schaff ich nie“ Gedanken. Davon lass ich mich natürlich nicht abschrecken. Die drei Kollegen sind ziemlich eingeschüchtert und haben Angst. Ich bin neu in der Firma und werde das Problem hoffentlich bald erkennen. Was Giuseppe mit den Betonschuhen und Tauchgängen gemeint hat, verstehe ich noch nicht. Folgende Punkte habe ich bereits erkannt:
    • Giuseppe scheint ein ziemlich unstrukturierter Auftraggeber zu sein. Seine Ziele sind unklar und müssen genauer analysiert werden.
    • Die Firma befindet sich in einer Fusionierungsphase und das bedeutet einen enormen Change, sowohl bei der Infrastruktur wie auch bei den Mitarbeitern.
    • Die Fähigkeiten der drei Entwickler schätze ich als ausreichend ein. Sie sind Bastler und müssen zuerst an eine vernünftige Vorgehensweise gewöhnt werden.
    • Das Verwaltungssystem ist monolitisch aufgebaut.
    • Es besteht aus Eigenentwicklung ohne offenen Standards
    • Die Strategie und die Pläne der Firma sind nicht klar beschrieben. Hier muss eine umfassende Anforderungsanalyse durchgeführt werden.
    • Projektmanagement-Prozesse und -Vorlagen sind nicht vorhanden

    Was hat Thomas an seinem ersten Tag gemacht?

    Er hat begonnen sich ein allgemeines Bild der Lage zu machen. Er hat die vorhandenen Rahmenbedingungen abgesteckt. Am ersten Tag ist es unmöglich schon alles zu überblicken. Er muss sich an das Thema herantasten. Mit seiner Aufzählung hat er weiterhin begonnen eine Schwachstellenanalyse durchzuführen. Die Eckpunkte werden ihm helfen die Vorstudie erstellen zu können. Das bedeutet, dass man eine Vorstudie erst erstellen kann, wenn man hierfür schon diverse Anforderungen zusammengestellt hat. Diese Aussage klingt logisch, doch einige Kollegen erstellen Vorstudien ohne das tatsächliche Problem zu beschreiben. Vor allem bei Projekten die ähnlich aussehen wie bereits erstellte, verfällt der Projektleiter gerne in den Modus „Hey das kenne ich, das mach ich gleich nochmal!“ Ich kann davon nur abraten. Ein paar Stunden, oder gar Tage, Anforderungen zusammen tragen, spart im Projektverlauf das vielfache an Ärger und Kosten. Einen Nachteil hat diese Vorgehensweise: Niemand bekommt hinterher mit, dass sinnvolle Vorarbeit geleistet wurde. Das kann manchmal ziemlich frustrierend sein. Aber so ist das Projektleben. Wenn es gut läuft wird niemand etwas vom Projekt mitbekommen. Dann ist es einfach fertig gestellt worden.

Seite 1 von 1, insgesamt 4 Einträge