Das Lastenheft auf einer Seite: So beschreiben Sie Ihr Software-Problem

Die meisten Softwareprojekte scheitern nicht an der Technik, sondern daran, dass nie jemand aufgeschrieben hat, was eigentlich das Problem war. Stattdessen kursieren eine E-Mail, zwei Telefonate und die Erinnerung an ein Gespräch, in dem alle genickt haben, jeder an einer anderen Stelle.

Ein Lastenheft löst das. Nur hat der Begriff einen schlechten Ruf, weil er nach 40 Seiten Formularwesen klingt. Muss er nicht. Für das erste belastbare Angebot reicht eine Seite, wenn die richtigen sieben Punkte darauf stehen.

Die Kurzfassung:

• Ein Lastenheft beschreibt das Problem, nicht die Lösung. Technik ist die Aufgabe des Dienstleisters.
• Sieben Punkte reichen für ein belastbares Angebot; alles darüber hinaus ist Verhandlung, nicht Vorbereitung.
• Die häufigste Lücke ist nicht zu wenig Detail, sondern ein fehlendes Mengengerüst.

Warum Sie das Problem beschreiben sollten und nicht die Lösung

Der typische erste Satz lautet: „Wir brauchen eine App, in der die Monteure ihre Aufträge sehen."

Das ist bereits eine Lösung. Sie schließt aus, was vielleicht besser gepasst hätte: eine Weboberfläche, die auf jedem Gerät läuft, eine Erweiterung der vorhandenen Software, eine automatische Nachricht statt einer eigenen Anwendung. Wer die Lösung vorgibt, bekommt ein Angebot auf diese Lösung, auch wenn es die teurere ist.

Der bessere erste Satz: „Unsere Monteure rufen morgens im Büro an, um zu erfahren, wo sie hinmüssen. Das sind rund 15 Anrufe zwischen 6:30 und 7:30 Uhr, die eine Person im Büro komplett binden."

Daraus kann jemand etwas bauen. Und Sie erfahren im Angebot vielleicht, dass es zwei Wege gibt: einen für 4 Wochen und einen für 4 Tage.

Faustregel: Wenn in Ihrer Beschreibung ein Produktname oder eine Technologie vorkommt, ist es keine Anforderung mehr, sondern eine Vorentscheidung.

Anforderungen an Software formulieren: die sieben Punkte

Diese sieben Punkte passen auf eine Seite und reichen aus, damit ein Dienstleister rechnen kann statt zu raten.

1. Ist-Zustand: wie läuft es heute?

Beschreiben Sie den Ablauf so, wie er wirklich ist, inklusive der Zettel und der Excel-Datei, die eigentlich niemand kennt. Der Satz „das machen wir noch von Hand" ist wertlos, weil er nicht sagt, wie von Hand.

Nützlich ist: Wer macht es, in welcher Reihenfolge, mit welchem Werkzeug, und wo geht dabei regelmäßig etwas schief.

2. Auslöser: warum jetzt?

Es gibt fast immer ein Ereignis. Eine Mitarbeiterin geht in Rente und mit ihr das Wissen. Ein Lizenzpreis wurde erhöht. Ein Kunde verlangt eine Schnittstelle. Ein Fehler hat Geld gekostet.

Der Auslöser sagt dem Dienstleister, wie dringend es ist und woran gemessen wird, ob das Projekt etwas gebracht hat.

3. Die drei Muss-Anforderungen

Nicht zehn. Drei. Formuliert als Sätze, die man am Ende überprüfen kann:

• „Ein Monteur sieht seinen Tagesplan bis 6:00 Uhr auf dem Handy, ohne anzurufen."
• „Eine Änderung im Büro ist beim Monteur in unter einer Minute sichtbar."
• „Ein Auftrag lässt sich mit Foto und Unterschrift vor Ort abschließen."

Alles Weitere kommt auf eine zweite Liste mit der Überschrift „später". Diese Trennung ist der eigentliche Wert des Dokuments: Sie entscheidet, was in die erste Version gehört.

4. Wer arbeitet damit?

Zählen Sie die Rollen auf und was jede davon darf. Drei Rollen sind ein anderes Projekt als eine. Wenn ein Monteur die Preise nicht sehen soll, gehört das hierhin. Nachträglich eingebaute Rechteverwaltung ist einer der teuersten Umbauten überhaupt.

5. Das Mengengerüst

Der Punkt, der am häufigsten fehlt und den Preis am stärksten bewegt. Wie viele Datensätze, wie viele Nutzer, wie viele Vorgänge pro Tag, wie viele im Spitzenmonat?

30 Aufträge pro Tag und 3.000 sind technisch zwei verschiedene Welten. Ohne diese Zahlen kalkuliert jeder Anbieter mit einem Sicherheitsaufschlag, den Sie bezahlen.

6. Angrenzende Systeme

Welche Software gibt es bereits, die etwas mit den Daten zu tun hat? Buchhaltung, Warenwirtschaft, Kalender, Onlineshop, Zeiterfassung. Und pro System: Muss es angebunden werden oder reicht ein Export?

Nennen Sie ruhig auch, was Sie nicht anbinden wollen. Das spart genauso viel Diskussion.

7. Rahmen: Budget und Termin

Viele verschweigen das Budget aus Sorge, dass der Preis dann genau dorthin wächst. Das Gegenteil passiert: Ohne Rahmen bekommen Sie ein Angebot über den vollen Wunschumfang, und die Absage kostet beide Seiten zwei Wochen.

Ein Satz reicht: „Wir haben für den Einstieg einen mittleren vierstelligen Betrag vorgesehen und wollen vor der Saison im Frühjahr starten." Ein guter Dienstleister sagt Ihnen dann, was davon realistisch ist, oder dass es nicht passt. Beides ist besser als Schweigen.

Die Vorlage zum Abschreiben

Kopieren Sie das in ein leeres Dokument und füllen Sie es aus. Wenn Sie an einer Stelle nicht weiterkommen, schreiben Sie „weiß ich nicht" hin. Auch das ist eine verwertbare Information.

1. IST-ZUSTAND
   Heute läuft es so: …
   Beteiligt sind: …
   Schiefgehen kann dabei: …

2. AUSLÖSER
   Wir gehen es jetzt an, weil: …

3. MUSS-ANFORDERUNGEN (genau drei)
   a) …
   b) …
   c) …
   Später, aber nicht jetzt: …

4. ROLLEN
   Rolle 1 (…) darf: …
   Rolle 2 (…) darf: …

5. MENGEN
   Nutzer: …   Vorgänge pro Tag: …   Datensätze im Bestand: …
   Spitzenlast (wann, wie hoch): …

6. ANGRENZENDE SYSTEME
   System · anbinden oder Export · wie wichtig
   …

7. RAHMEN
   Budgetvorstellung: …
   Wunschtermin und warum: …

Ausfüllzeit: etwa 30 bis 45 Minuten, wenn Sie die Zahlen aus Punkt 5 zur Hand haben. Genau dieses eine Dokument ist bei uns der gesamte Aufwand, den Sie vor dem ersten Prototyp haben. Wie die Zusammenarbeit danach läuft, steht auf der Leistungsseite.

Was Sie sich sparen können

Drei Dinge stehen oft in Lastenheften und helfen niemandem.

Bildschirmentwürfe. Wenn Sie keine Erfahrung im Oberflächendesign haben, engen Skizzen die Lösung ein, ohne die Anforderung klarer zu machen. Beschreiben Sie stattdessen, welche Entscheidung ein Nutzer auf diesem Bildschirm treffen muss.

Technologie-Vorgaben. „Soll in React sein" ist nur dann sinnvoll, wenn Sie eine eigene IT haben, die es später übernimmt. Sonst schränkt es die Auswahl ein und ändert am Ergebnis nichts.

Die vollständige Wunschliste. 40 Anforderungen ohne Priorisierung sind kein Lastenheft, sondern eine Sammlung. Sie führen zu einem Angebot, das zu teuer ist, um zugesagt zu werden.

Wann eine Seite nicht reicht

Ehrlicherweise gibt es Fälle, in denen ein kurzes Dokument nicht ausreicht:

• Regulierte Bereiche: Medizin, Finanzdienstleistung, alles mit Zertifizierungspflicht. Dort ist die Dokumentation selbst Teil der Anforderung.
• Ablösung eines gewachsenen Altsystems. Die eigentliche Arbeit ist dann, überhaupt herauszufinden, was das alte System tut. Das ist ein eigenes Vorprojekt.
• Mehr als zwei Abteilungen mit widersprüchlichen Interessen. Hier ist das Problem nicht die Beschreibung, sondern die fehlende Entscheidung. Ein Dokument kann die nicht ersetzen.

In allen anderen Fällen, und das ist die große Mehrheit im Mittelstand, ist die eine Seite nicht die Sparversion, sondern die bessere Variante. Sie zwingt zur Priorisierung, und Priorisierung ist genau das, was ein Angebot belastbar macht.

Was danach passiert

Mit dem ausgefüllten Blatt bekommen Sie normalerweise innerhalb weniger Tage eine Rückmeldung, die drei Dinge enthält: eine Einschätzung des Aufwands, offene Fragen und einen Vorschlag, was in die erste Version gehört und was nicht.

Falls die Rückmeldung stattdessen nur ein Preis ist, ohne Nachfragen, dann hat niemand gerechnet. Wer bei Punkt 5 und 6 keine Rückfragen hat, hat sie nicht gelesen.

Zwei Themen schließen sich direkt an: Ob eine eigene Lösung überhaupt der richtige Weg ist, klären Sie vorher mit der Entscheidungsmatrix Standardsoftware gegen Eigenentwicklung. Und wem am Ende der Quellcode gehört, sollten Sie geklärt haben, bevor Sie unterschreiben. Dazu dieser Artikel über IP, NDA und Revenue-Share.