Wie man Individualsoftware beauftragt, ohne in endlosen Scope zu geraten

Endloser Scope ist nichts, was Dienstleister Ihnen antun. Er entsteht, wenn niemand im Raum definiert, was die Software nicht tun soll. Ein Projekt ohne explizite Grenzen dehnt sich aus, um jede gute Idee aufzunehmen, die unterwegs auftaucht, und jede dieser Ideen ist für sich genommen vernünftig. Das Ergebnis ist ein Bauvorhaben, das dauerhaft drei Monate vor der Fertigstellung steht.

Die Lösung ist weder ein härterer Verhandler noch ein dickerer Vertrag. Es ist eine andere Art des Zuschnitts: das Projekt über die operativen Ergebnisse definieren, die es liefern muss, nicht über die Liste der Features, die es enthalten sollte. Wir sagen das als Team, das Software baut und zugleich eigene Produkte im laufenden Betrieb verantwortet. Wer Software nach der Auslieferung selbst betreibt, lernt schnell: Ein kleiner Scope, der einen echten Tag trägt, schlägt einen großen Scope, der nur in einem Dokument existiert.

Warum Featurelisten endlosen Scope erzeugen

Eine Featureliste wirkt wie Gründlichkeit, hat aber ein Einwegventil eingebaut. Jedes Meeting fügt ein Feature hinzu, weil Hinzufügen sich nach Fortschritt anfühlt und in der Planungsphase nichts kostet. Niemand streicht eines, weil Streichen sich anfühlt, als gäbe man etwas bereits Bezahltes auf. Also wächst die Liste nur, und jeder Zusatz macht den nächsten leichter zu rechtfertigen.

Dann wird die Liste zur Spezifikation, und die Spezifikation wird zum Streit. Jede Mehrdeutigkeit, etwa ob 'Berichte' den Export nach Excel einschloss, wird zur Verhandlung darüber, wer wem was schuldet. Das Dokument, das beide Seiten schützen sollte, wird zum Gelände, auf dem sie kämpfen. Und während dieser Streit läuft, stellt niemand die einzige Frage, die zählt: Ändert Punkt 23 irgendetwas daran, wie das Unternehmen tatsächlich arbeitet?

Nach Ergebnis zuschneiden

Ein operatives Ergebnis ist ein konkreter Moment im Geschäft, der anders sein muss, sobald die Software existiert. Zum Beispiel: Ein Außendienstmitarbeiter fotografiert einen Beleg, und die Ausgabe existiert im System, kategorisiert, bevor er wieder im Wagen sitzt. Dieser eine Satz schlägt drei Seiten Features eines Ausgabenmoduls, weil er benennt, wer was tut und mit welchem Ergebnis, und weil er sich prüfen lässt, indem man einem echten Menschen an einem echten Tag zusieht, statt eine Checkliste zu lesen.

Genau so schneidet Cazullo Projekte zu: als kurze Menge benannter Momente, jeder in der echten Operation überprüfbar. Features werden zu Implementierungsdetails, gewählt von denen, die bauen, und gemessen an dem Moment, dem sie dienen. Was keinem benannten Moment dient, liegt per Definition außerhalb des Scopes. Nicht abgelehnt, nur nicht in diesem Projekt.

Die Disziplin der v1

Sind die Momente benannt, verlangt die erste Version einen weiteren Akt der Disziplin: Breite verweigern. Wir halten diese Linie bei unseren eigenen Produkten aus einem eigennützigen Grund, denn wir sind diejenigen, die betreiben müssen, was auch immer ausgeliefert wird.

• Ein Workflow komplett von Anfang bis Ende schlägt fünf halbe Workflows. Ein Beleg, der zuverlässig zur kategorisierten Ausgabe wird, ist ein Produkt. Fünf Module bei 60 Prozent sind eine Demo.
• Software, die einen echten Tag trägt, verdient sich das Recht zu wachsen. Sobald ein Workflow den echten Betrieb stemmt, stützt sich das nächste Scope-Gespräch auf Nutzung statt auf Vorstellungskraft.
• Alles andere ist ein beschriftetes Backlog, kein Versprechen. Notieren Sie gestrichene Ideen mit Name und Grund, damit sich das Entfernen aus der v1 wie Ablegen anfühlt, nicht wie Verlieren.

Vertragsformen, die helfen

Keine Vertragsform beseitigt Scope-Drift, seien Sie also skeptisch gegenüber jedem, der das von seiner behauptet. Manche Formen machen Ehrlichkeit allerdings leichter. Die wichtigste: Phasen, in denen jede Phase mit etwas endet, das läuft, mit einem Ergebnis, das eine echte Person in echter Arbeit nutzt. 'Anforderungen abgeschlossen' und 'Architektur freigegeben' sind Dokumentationsmeilensteine, keine Ergebnisse. Ein Mitarbeiter, der eine echte Ausgabe über das System erfasst, ist ein Ergebnis.

Die andere nützliche Form ist die Möglichkeit, nach jeder Phase ohne Trümmer aufzuhören. Wenn der Kunde nach Phase eins mit funktionierender Software gehen kann, die ihm gehört, dann muss der Auftragnehmer Phase eins wirklich nützlich machen, und der Kunde muss hineinlegen, was tatsächlich zählt. Diese Ausstiegsoption hält alle ehrlich, uns eingeschlossen.

Fragen, die den Scope schrumpfen lassen

Wenn ein Scope-Gespräch anfängt, sich aufzublähen, lassen diese Fragen die Luft heraus:

• Welche Tabelle stirbt in der v1? Wenn keine Tabelle, keine Chatgruppe und kein Papierprozess verschwindet, ist die Software eine Ergänzung statt eines Ersatzes, und die Akzeptanz wird es zeigen.
• Wer nutzt das am ersten Tag? Nennen Sie echte Menschen. Ein Feature, das keine benannte Person im ersten Monat anfasst, gehört ins Backlog.
• Was geht kaputt, wenn wir das streichen? Wenn die ehrliche Antwort 'noch nichts' lautet, streichen.
• Wie kommt der Betrieb zurecht, während gebaut wird? Der manuelle Behelf verrät meist, welcher Teil wirklich dringend ist.
• Welche dieser Features hat jemand verlangt, und welche haben wir uns nur ausgemalt?
• Was muss in neunzig Tagen wahr sein, damit diese Phase ein Erfolg heißt, ohne dass jemand eine Demo vorführt?
• Wenn das Budget halbiert würde, was behielten wir? Was diese Frage überlebt, ist der echte Scope.

Fangen Sie kleiner an, als sich bequem anfühlt

Unsere Empfehlung ist direkt: Beauftragen Sie die kleinste Software, die einen echten operativen Moment verändert, geben Sie sie in echte Hände und lassen Sie das, was tatsächlich passiert, den nächsten Scope schreiben. Eine v1, die klein, live und in Nutzung ist, lehrt mehr darüber, was als Nächstes zu bauen ist, als jeder Planungszyklus. Von einem Team, das betreiben muss, was es baut: Das ist kein Kompromiss. Es ist der schnellste Weg, den wir kennen, zu Software, die zählt.