projekte - Einträge für Juni 2008

  • Juni, 2008
  • Episode 12: Anforderungen durch schriftliche Fragen aufnehmen ::: Softwareprojekte

    Eine weitere Möglichkeit Anforderungen aufzunehmen, ist die Problemstellung zuerst in einem Dokument zu beschreiben und die offenen Punkte in schriftliche Fragen zu verpacken. Hiermit kann ohne aufwändige Interviews und Brainstorming-Sessions ausgekommen werden. Falls die Stakeholder physikalisch nicht am gleichen Ort sind, z.B. Entwicklerteam in Deutschland und Stakeholder in USA kann dies eine gute Vorgehensweise sein.

    Vorgehen

    • Beschreiben des Problems, eventuell mit Storybooks oder UML
    • Offene Punkte herausschreiben
    • Stakeholder beantwortet so gut er oder sie kann die offenen Punkte
    • Einarbeitung in das erstellte Dokument
    • Review über die Vorstudie
    Mit nur schriftlichen Vorgehen ist die Gefahr extrem hoch, dass die Kunden nicht das bekommen was sie wirklich wollen. Seid deshalb sehr vorsichtig mit nur schriftlicher Anforderungsanalyse.
  • Auswertung Blogparade: Projektleiter der Welt vereinigt euch

    An dieser Stelle möchte ich meine Erkenntnisse der verlängerten Blogparade Projektleiter der Welt vereinigt euch! zusammenfassen.

    Eigenthref="http://miradlo.net/bloggt/index.php?113-s"">Projektleiter der Welt vereinigt euch! zusammenfassen.

    Eigentlich gibt es gar kein Problem

    Wie immer im Leben gibt es verschiedene Sichtweisen und Erfahrungswerte. Hans hat zum Beispiel keine negativen Erfahrungen gesammelt: Westaflex Markenwelt Lufttechnik Schallschutz Filtration » Blog Archiv » Blogparade Projektarbeit In seiner Umgebung werden Projekte korrekt und mit den notwendigen Ressourcen durchgeführt. Der Projektleiter muss keine Brüllaffen-Mentalität besitzen und Projekte dienen, wie es laut Lehrbuch auch sein sollte, dazu ein Problem aus der Welt zu schaffen. Ich habe solche Erfahrungen ebenfalls gehabt. Eine Firma wollte ein neues Produkt einführen und ich hatte von Anfang an die Zielsetzung, den Umfang und das notwendige Team beieinander. Der Umfang war realistisch, das Team und die benötigten Kenntnisse ausreichend vorhanden und nach der Projektlaufzeit konnten wir erfolgreich abschliessen. Kein Brüllaffe und auch keine Prügelei um Mitarbeiter.

    Oder gibt es doch ein Problem?

    Georg bestätigte mit dem Beitrag Anders leben wollen: Projektleiter der Welt vereinigt euch! jedoch wieder, dass in einigen Firmen Projekte nicht sinnvoll aufgesetzt sind. Ich habe in den letzten Wochen mit meinen Projektleiterkollegen über dieses Thema etwas mehr diskutiert. Sie haben zwar nicht bei der Blogparade mitgemacht, aber wir konnten im Betrieb erreichen, dass wir über die Verteilung der Mitarbeiter anders diskutieren. Wir haben zwar noch keine abschliessende Lösung gefunden, das wird auch nicht möglich sein, wir haben jedoch eine Basis gefunden und sprechen gemeinsam mit allen Beteiligten. Wir kommen ein wenig von der Ellbogenplanung weg.

    Vielleicht ist die Definition eines Projekts einfach falsch?

    Genial finde ich den Beitrag von Rick: Projektleiter = unter einem Projekt Leider Er beschreibt auf eine wunderbar satirische Weise was Projekt und das Projekt (leiden) wirklich bedeutet. Vielen Dank für diese geniale Definition ;-) Wenn man mit Humor an die ganze Sache herangeht ist die Welt wesentlich einfacher und eigentlich auch logischer. Ich danke Euch für Eure Beiträge!
  • Episode 11: Anforderungen mit Brainstorming Sessions aufnehmen ::: Softwareprojekte

    In Episode 10 habe ich darüber gesprochen wie Anforderungen durch Interviews aufgenommen werden können. Es gibt natürlich noch weitere Möglichkeiten.

    Brainstorming Sessions

    Mit Brainstorming Sessions können schnell diverse Anforderungen klar gemacht werden. Eine mögliche Vorgehensweise:
    • Die verschiedenen Stakeholder (Betrieb, Auftraggeber, Anwender, Entwickler usw.) werden eingeladen.
    • Es ist schon einigermaßen klar was wir überhaupt bauen wollen, z.B. eine neue Geldwaschmaschine ;-) )
    • Zu den einzelnen Aspekten werden einleitende Fragen erstellt. Beispielsweise könnte man Fragen was die Bedienbarkeit der Geldwaschmaschine ausmachen soll.
    • Man sollte nicht zu viele Fragen erarbeiten. (Zum Beispiel vier Fragen pro Session)
    • Nun wird die Frage gestellt und alle Beteiligten dürfen zehn Minuten lang alle Ideen, seien sie noch so verrückt, sagen. Die Ideen werden aufgeschrieben.
    • Nach zehn Minuten werden die Ideen angesehen und geordnet.
    • Aus den gesammelten Ideen können die wirklich unsinnigen gemeinsam gefunden und entfernt werden. Alle weiteren Ideen werden nach Wichtigkeit geordnet und später ausformuliert.
    Mit dieser Vorgehensweise können sehr komplexe Themengebiete eingegrenzt und Lösungen dafür gefunden werden.
  • Episode 10: Anforderungen mit Interviews aufnehmen ::: Softwareprojekte

    In Episode 8 Vorstudie strukturieren habe ich ein Beispiel für den Aufbau eines Vorstudiendokuments beschrieben. So ein Dokument ist ja ganz nett, aber wie kriegt man da sinnvolle Daten rein? Hier ein paar Gedanken zu diesem Thema, wie man Interviews einsetzen kann.

    Gute Idee ::: Stakeholder

    Eine wirklich gute Idee ist es, sich mit den betroffenen Stakeholdern zusammen zu setzen und sie zu fragen was sie wollen. Damit das einigermaßen geordnet gehen kann, verwende ich meistens folgendes Vorgehen.

    Vor dem Interview

    Ich mache mir vor dem Interview klar, welche Anforderungen und welche Sprache der jeweilige Stakeholder verwendet.
    • Ein Betriebsmitarbeiter spricht sehr technisch und will vor allem verstehen welche Auswirkungen die neue Software auf seine übrigen Systeme hat.
    • Ein Auftraggeber hat Vorstellungen von dem was er will. Im Normalfall ist er nicht in der Lage die Vorstellungen in einer IT-geeigneten Sprache zu formulieren.
    • Ein Anwender kann, falls es sich um die Ablösung eines bestehenden Systems handelt, noch sagen was ihm daran gefallen und nicht gefallen hat. Er oder sie wird viele Ideen haben und keine Idee konkret formulieren können.
    • Ein Zulieferer wird sein System perfekt verkaufen und einem das Gefühl geben, alle Probleme der Welt auf einmal mit der neuen Software lösen zu können.
    • Ein Partner, der an das zu erstellende System angebunden werden soll, wird so wenig wie möglich Auswirkungen auf sein System haben wollen.

    Zusammenstellen von Fragen

    Für die jeweiligen Stakeholder stelle ich einen Fragekatalog zusammen. Im Interview kann ich somit das Gespräch etwas steuern. Wichtig ist hierbei, dass die Gesprächspartner nicht zu sehr von den Fragen manipuliert werden. Sie sollen immer noch ihre Wünsche und Ansprüche formulieren können.

    Während des Interviews

    Im Interview versuche ich die Erkenntnisse jeweils in grafischer Form aufzuzeigen. Ich erstelle grobe Systemübersichten, Business-Abläufe usw. Diese lasse ich mir im Interview von dem jeweiligen Stakeholder bestätigen.

    Nach dem Interview

    Nach dem Interview schreibe ich die Erkenntnisse in der Vorstudie zusammen und lasse sie vom Stakeholder nochmals gegenlesen. Hiermit können ziemlich viele Fehlinterpretationen direkt beseitigt werden.
  • Blogparade verlängert bis 24. Juni ::: Erfahrungen von Projektleitern

    Die Blogparade war ursprünglich bis 16. Juni 2008 begrenzt. Falls jedoch Fussballfans erst Zeit haben, sobald es einen spielfreien Tag gibt, wird verlängert bis einschließlich Dienstag, 24. Juni 2008 (damit sind es zwei spielfreie Tage der Euro 2008): Projektleiter der Welt vereinigt euch!

    Die Blogparade möchte Antworten von euch zu folgenden Fragen

    • Was sind eure Erfahrungen?
    • Arbeitet ihr mit euren Projektleiterkollegen zusammen oder führt ihr ein Einzelleben?
    Selbstverständlich könnt ihr sowohl in den Kommentaren, als auch mit eurem Blog teilnehmen. Wäre fein, wenn sich noch der ein oder andere beteiligen würde... Die Blogparade Projektleiter haben wir, ebenso wie die Verlängerung bei blog-parade.de eingetragen, ein Service, bei dem Blogparaden gesammelt werden.
  • Episode 9: Wann muss der Betrieb mit ins Boot? ::: Softwareprojekte

    Immer wieder stellt sich bei Projekten die Frage, ab wann der Betrieb involviert werden soll. Der Betrieb hat im Normalfall nicht genügend Mitarbeiter, um in jedem anstehenden Projekt mitzuarbeiten. Auf der anderen Seite muss gewährleistet werden, dass das erstellte Produkt auch vom jeweiligen Betrieb verwaltet werden kann.

    Thomas hatte sich die beiden Familien angeschaut...

    ...und sich den Betrieb genauer betrachtet. Im Fall von Hans, Karl und Orlando kann man nicht von einem klassischen Betrieb sprechen. Die drei sind Entwickler und Betreiber in Personalunion. Bei der zweiten Familie ist die Entwicklung und der Betrieb voneinander getrennt. Die Entwicklung erstellt ein Programm und übergibt es an den Betrieb. Eine vernünftige Dokumentation, wie das jeweilige Programm zu bedienen und warten ist, gibt es nicht. Wenn ein Fehler auftritt, handelt der Betrieb intuitiv. Wenn das nicht klappt, wird der Incident an die Entwickler übergeben. Thomas will bei der Neugestaltung der gemeinsamen IT die beiden Betriebe zusammenlegen und einen möglichst stabilen Betrieb aufbauen. Seine Überlegungen: „Wenn ich den Betrieb permanent mit in das Projekt einbinde wird die Stakeholderliste unnötig groß. Jeder will mitreden und an eine Weiterentwicklung der Software ist kaum zu denken.“ „Wenn ich den Betrieb erst kurz vor der Abnahme einbinde, ist die Gefahr extrem hoch, dass die erstellte Software nicht betreibbar ist.“ Was für ein Dilemma! Nach einigem hin- und her entschied sich Thomas für folgendes Vorgehen: „Ich lass den Betrieb bei der Anforderungsanalyse all seine Anforderungen, die zu diesem Zeitpunkt bekannt sind, formulieren.“ Bekannte Anforderungen können sein:
    • Bekannte Betriebssysteme, die von den Mitarbeitern verwaltet werden können
    • Monitor-Elemente, die gesetzt sind und die eingebunden werden müssen
    • Angaben, wie Projekte dokumentiert und Betriebshandbücher aufgebaut sein müssen
    • Angaben, wie Artefakte an den Betrieb übergeben werden müssen
    • ...
    „Zusammen mit den Anforderungen der Kunden erstelle ich die Architektur und das Detailkonzept. Das Detailkonzept wird vom Betrieb überprüft und anhand der detaillierten Informationen kann der Betrieb genauer angeben, was er wirklich braucht.“ „Danach lasse ich den Betrieb erst einmal wieder in Ruhe.“ Zu diesem Zeitpunkt werden im...

    Projekt vor allem die neuen Komponenten

    erstellt. „Wenn ein testbares System vorhanden ist, muss der Betrieb wieder ran und kontrollieren ob alles für ihn in Ordnung ist.“ Zu testen sind hier
    • Stabilität
    • Auswirkungen auf andere Komponenten
    • Installierbarkeit
    • Konfigurierbarkeit
    • Performance
    • ...
    „Weiterhin werde ich die Betriebsmitarbeiter während dieser Tests schulen.“ Hier ist die Gefahr hoch, dass die Zeit für die Schulung nicht ausreicht, um die Mitarbeiter wirklich für den Betrieb fit zu machen. Und da haben wir auch wieder das Dilemma. Entweder hat man über eine lange Zeit viele Mitarbeiter blockiert und dafür aber später gut ausgebildete Kollegen oder man kommt im Projekt schneller vorwärts und fährt das Risiko, dass sich die Betriebsübergabe verschiebt. Ich selbst glaube, dass es hier keine ideale Lösung gibt. Man muss sich für einen Mittelweg entscheiden. Wichtig ist jedoch, dass der Betrieb von Anfang an ausreichend informiert wird.

Seite 1 von 1, insgesamt 6 Einträge