Lasten, Pflichten, gemeinsames Angebot

Der bewährte Ablauf zur Bestellung neuer IT-Lösungen oder zur Bestellung von Anpassungen und Erweiterungen startet mit der kurzen Dokumentation eines Kundenwunsches (Demand) in der Sprache der beteiligten Anwender.

Warnung: Es wird dringend davon abgeraten, Änderungswünsche nur aus Sicht des Managements zu Formulieren, ohne zumindest ausgewählte Benutzer (Keyuser) der betroffenen IT-Systeme einzubeziehen. Die ausgewählten Benutzer müssen in direktem Kontakt mit den Benutzern stehen, die die bestellte Software tagtäglich verwenden oder verwenden werden.

Erstellung eines Lastenheftes mit den Zielen aus Kundensicht

Fritz VerkäuferDer Kundenwunsch aus Sicht des Auftraggebers kann anschließend mit Hilfe eines Spezialisten in ein Lastenheft ausgearbeitet werden.

Genauere, strukturierte Anforderungen im Lastenheft sind nur erforderlich, wenn es für eine Ausschreibung zur Bearbeitung an mehrere potentielle Auftraggeber verteilt wird. Auf keinen Fall kann ein Lastenheft bei der Angebotserstellung ein persönliches Gespräch zur Klärung von Detailfragen durch einen "Requirements Engineer" (AnalytikerIn) und durch ausgewählte Vertreter des Entwicklerteams des Auftragnehmers ersetzen. Es stellt viel mehr eine wichtige Ergänzung zur Vorbereitung dieser Besprechung dar.

Die Abklärung von Anforderungen zur Angebotslegung durch einen Kundenbetreuer/in bzw. Verkäufer/in (z.B. Key Account Manager) gilt als "Antipattern", d.h. dieses Vorgehen hat sich in der Praxis nicht bewährt. Agiles Management zur Produkt-Entwicklung setzt den persönlichen Kontakt zwischen späteren BenutzerInnen, EntwicklerInnen und Lösungs-DesignerInnen (ArchitektInnen) voraus und vermeidet Fixpreis Angebote nach vorgefertigten später nicht mehr verhandelbaren Anforderungen.

Verkürztes Lastenheft wenn Pflichtenheft eingeplant wird

Das Lastenheft kann auf eine kurze fachliche Beschreibung der Kundenwünsche reduziert werden, wenn bereits ein Auftragnehmer fest steht und wenn mit Hilfe eines "Requirements Engineer" (AnalytikerIn) später ein Pflichtenheft und eine Dokumentation zu der gewünschten Applikation (IT-System) erarbeitet wird. Bei Bedarf kann die Erstellung der Dokumentation als eigener Auftrag erfolgen, z.B. wenn zusätzlich die bestehenden Geschäftsprozesse anzupassen sind. In diesem Fall wird zunächst ein Teil der benötigten Dokumentation erstellt und ausgeliefert, bis ein entsprechendes Angebot zur Umsetzung möglich ist. Weitere Details dazu liefert der Beitrag Pflichtenhefte und das Unified Model und für die agile Produktentwicklung der Beitrag agiles Management zur Produkt-Entwicklung.

Stark reduziertes Lastenheft für die agile Produkt-Entwicklung

Das beschriebene Vorgehen widerspricht teilweise den Vorgaben und Werten der agilen Produkt-Entwicklung, und kann vermieden werden, in dem die Problemstellung in einem vorbereiteten Sprint grob analysiert und in einem initalen Product-Backlog dokumentier wird. In der agilen Produkt-Entwicklung wird ein Entwicklungs-Team fix für einen Zeitraum "gemietet", über den der "Product Owner" die in dieser Zeit umsetzbaren Funktionalitäten nach entsprechender Vorbereitung selbst abschätzen und steuern kann - vgl. z.B. Scrum. Auf schwer handhabbare Fixpreis-Angebote kann in der Regel verzichtet werden.

Das agile Vorgehen vereinfacht die Erstelllung des Lastenheftes, das auf eine valide Vision für das gewünschte Produkt, und wichtige, nicht funktionale Vorgaben mit Auswirkungen auf das spätere Lösungsdesign beschränkt werden kann. Dazu zählen z.B. Vorgaben, bestimmte Technologien und Standards zu berücksichtigen, und bestehende Schnittstellen zu nutzen.

Auf ein Pflichtenheft sollte auch im Fall der agilen Projektabwicklung nicht verzichtet werden.