Berufserfahrungen Wolfgang Gräper

Wenn man zwischen "Projektleitung" und "Projektmanagement" unterscheidet, so ist die Leitungsfunktion eher inhaltlich, die Managementfunktion eher formal ausgerichtet.

• Der eigene Vertrieb wird über Schwächen und Stärken eines angebotenen Produktes oder Services informiert.
• Für potentiellen Kunden ist ein "Presales Consultant" als Ansprechpartner für technische Fragen da und springt dort ein, wo der Vertrieb technische Unterstützung braucht.

Das Publikum ist dabei oft nicht sachkundig und nicht involviert; manchmal auch nicht richtig interessiert.

Sie werden "im laufenden Betrieb" durchgeführt, betreffen oft aktuelle Fragestellungen und können ad hoc anberaumt werden.

Sie brauchen keine bestimmte räumliche oder technische Umgebung und können vor Ort durchgeführt werden.

Der Wissensaustausch in Workshops findet zu einem großen Teil zwischen den Teilnehmern statt und der Leiter des Workshops ist eher Moderator als Trainer.

Der Trainer ist umfassend auf das Seminar vorbereitet und verfügt über fundiertes Wissen zum behandelten Thema.

Bei Seminaren und Schulungen wird Wissen vom Trainer an die Teilnehmer weitergegeben.

Wenn solche Probleme sichtbar werden, muss man sich darum kümmern.

An sich ist das die Aufgabe eines Psychologen. Psychologen sind aber fachfremd und werden i.d.R. nicht akzeptiert. Ein Systemberater kann hier als Schmiermittel dienen, wenn es von der Projektleitung unterstützt wird.

Beim Coaching werden technische und menschliche Probleme gleichermaßen angesprochen.

Wichtig ist, dass beim Coaching innerhalb des Teams existierende Probleme "nach außen" getragen und dort diskutiert werden.

QS ist eine das ganze Projekt begleitende Aufgabe.

Im Bereich Softwareentwicklung gehört zur Qualitätssicherung, unabhängig von der Projektorganisation, die Festlegung von Standards, die während der Entwicklung eingehalten werden sollen und überprüft werden müssen.

Im konventionellen Umfeld findet QS außerhalb der Entwicklung statt. Die Prozesse "Verifikation" und "Validation" spielen eine wichtige Rolle.

Im agilen Umfeld ist QS in den Entwicklungsprozess integriert. Die "DoD" (Definition of Done) ist hier ein wichtiges formales Instrument.

In der Anlaufphase einer neu entwickelten Software ist es aber sinnvoll und durchaus üblich, Personen im Support einzusetzen, die an der Entwicklung beteiligt waren und über entsprechendes Insider-Wissen verfügen.

Allerdings kann es vorkommen, dass im Zuge der Softwareentwicklung auch Änderungen an der Definition von Geschäftsprozessen vorgenommen werden (müssen).

Je nach Umgebung ist RE unterschiedlich in den gesamten Entwicklungsprozess eingebunden. In einem konventionellen Umfeld findet RE eher am Anfang des Projektes statt, in einem agilen Umfeld dagegen eher kontinuierlich und begleitend.

Je nach Umfeld können auch unterschiedliche Methoden und Werkzeuge eingesetzt werden: konventionell eher UML, agil eher User Stories.

Im Design wird auch die technische Umsetzung einzelner fachlicher Anforderungen festgelegt und beschrieben.

Je nach Vorgehen findet dass Design kontinuierlich während der Entwicklung statt, ist ein Teil des RE oder wird im Anschluss daran vorgenommen.

Im Wesentlichen ist das die Programmierung.

Wenn an bestimmten Stellen fertig programmierte Bausteine eingesetzt werden, gehört auch das Finden, Konfigurieren und Zusammenstecken der Bausteine zur Entwicklung.

Außerdem fallen in den Bereich Entwicklung alle Arbeiten, die notwendig sind, um die Software prinzipiell in Betrieb nehmen zu können (erstellen und einspielen von Meta-Daten, schreiben von Start-Stop Scripten etc.).

Spätestens vor der Auslieferung findet ein Systemtest statt, bei dem das gesamte System getestet wird.

Eine besondere Art des Systemtests ist der Abnahmetest. Dabei handelt es sich um eine Prüfung des Gesamtsystems durch den Auftraggeber.

Je nach Umgebung ist das Verfahren der Auslieferung sehr unterschiedlich. Die Bandbreite reicht von CD über Freischalten eines Servers, auf dem die Software vorher (stückweise) eingespielt wurde, bis zum Installieren auf den Arbeitsplätzen vor Ort durch einen IT Consultant, der mit einer CD im Gepäck durch die Gegend fährt.

• Den Quellcode
• Inline-Dokumentation
• Konfigurationsdokumentation und/oder -dateien

Was vom Entwickler ausgeliefert werden soll, wird merkwürdigerweise in jedem Projekt neu diskutiert.

Im konventionellen Umfeld wird das "Was" (hoffentlich) in den Projektstandards festgelegt.

Im agilen Umfeld ist es Bestandteil der DoD, der "Definition of Done".

Die Auslieferung von lauffähiger Software an den Auftraggeber ist Bestandteil des Deployment.

Ein typisches, international akzeptiertes, Dokument ist das durch IEEE definierte SRS (Software Requirement Specification).

In Deutschland hat das Dokument häufig den Namen "Lastenheft", das inhaltlich dem SRS entspricht (so ungefähr).

Es werden die Architektur und die eingesetzten technischen Werkzeuge beschrieben.

Die Systemspezifikation kann in der IEEE Welt im SDD (Software Design Definition) als eigenes Dokument oder als Teil der Gesamtspezifikation im SRS Section D erstellt werden.

Im deutschen Sprachraum existiert das "Pflichtenheft" als Dokument mit vergleichbarem Inhalt.

Je nach Umgebung, wird in der Systemspezifikation ein Bezug zu den fachlichen Anforderungen hergestellt und deren Umsetzung beschrieben.

Eine User Story ist klein und scharf abgegrenzt. Sie beschreibt immer genau eine Anforderung.

Sie kann Akzeptanzkriterien enthalten, die beschreiben, wie die Anforderung umzusetzen ist.

Das Benutzerhandbuch basiert inhaltlich auf dem Fachkonzept, orientiert sich aber an der tatsächlichen Umsetzung. Wenn die Umsetzung der fachlichen Anforderungen im Pflichtenheft oder dem SDD beschrieben wurde, können sie auf dieser Basis fortgeschrieben werden.

Das Systemhandbuch basiert inhaltlich auf dem Designdokument, beschreibt aber, wie das System technisch tatsächlich implementiert wurde und nicht, wie es implementiert werden sollte. Das Systemhandbuch kann also vom Designdokument abweichen.

Wenn es kein eigenes Betriebshandbuch gibt, kann das Systemhandbuch auch einen Teil enthalten, der den Betrieb der Software beschreibt.

Auf jeden Fall enthält die Testdokumentation eine konkrete Beschreibung aller Testfälle, mit Testgegenstand, Testablauf und erwartetem Ergebnis.

Je nach Testebene gehört zur Testdokumentation nach der Testdurchführung auch das Protokoll der TestErzeugnisse (bei System- und Abnahmetest ist das ein Muss).

Die Unterlagen werden an die Teilnehmer ausgehändigt.

Klassische Projektpläne eignen sich für die Planung vorab, aber nicht für die Projektablaufverfolgung.

Auch in der Softwareentwicklung gilt: Kein Plan überlebt die erste Berührung mit der Wirklichkeit!

Wesentlich robuster, und auch einfacher in der Erstellung und Handhabung, ist eine sog. "Work Breakdown Structure", bei der die einzelnen Aufgaben aus der Gesamtaufgabe heraus abgeleitet werden. Dauer und Kosten bleiben dabei unberücksichtigt.

Der Inhalt richtet sich an ein kleines, meist internes Publikum.

Als Medium werden meistens Tabellen oder Folien benutzt. Wenn allerdings eine Projektmanagement Software im Einsatz ist, sollte deren eingebaute Präsentationsfunktion benutzt werden.

Tipp: Wenn PM Software eingesetzt wird, sollte man das Publikum von vornherein an die Ausgabe der Software gewöhnen.

Je nach Kreis der Adressaten muss diese Dokumentation formal sauber sein. Es ist auch wichtig, rechtliche Anforderungen und Empfindlichkeiten Dritter (aber auch die der eigenen Firma) im Auge zu behalten.

Unter dem Dach von Rational sind auch Standards und Modelle entwickelt worden, die weite Verbreitung erlangt haben (UML, RUP).

Die Vantive Applications beinhalten auch eine Komponente zur Fehler- und Aufgabenverfolgung, vergleichbar mit Jira, Mantis oder Rational ClearQuest.

Die Komponente zum Testmanagement ist besonders gut durchdacht.

Die Steuerdateien für Make sind in einem eigenen Format abgelegt, das erst einmal gelernt werden will.

Das bekannteste Werkzeug für die Projektplanung ist vermutlich MS-Project. Daneben gibt und gab es diverse andere Produkte mit vergleichbarem Funktionsumfang. Vor langer Zeit hieß eines Timeline 4.

Mehr aus der Ecke "Projektverfolgung" kommen Werkzeuge, die auf Basis von Aufgaben operieren. Die Aufgaben durchlaufen bestimmte Workflows und lassen sich verfolgen. Ein Beispiel dafür ist Jira.

• eine Textverarbeitung,
• ein Werkzeug für Präsentationen,
• eine Tabellenkalkulation und
• ein Werkzeug, um Grafiken zu erstellen.

Natürlich kann es sein, dass ein mächtigeres Werkzeug zur Verfügung steht (z.B. Enterprise Architect), aber es macht Sinn, mit einem einfachen Tool vertraut zu sein, das überall zur Verfügung steht.