"Eine Eigenentwicklung ermöglicht dem Specht neue Futterquellen zu finden, bessere Nester zu bauen und ihr Revier zu markieren." - Warum bekommen Spechte keine Kopfschmerzen?
Wollen Sie eine Innovation auf dem Markt bringen, die nachhaltig wirken soll, kommen sie hier und da um eine Spezialanfertigung nicht umhin. Die einzigartigen strategischen Eigenschaften ihres Geschäftsmodells werden oft erst durch eine Spezialanfertigung möglich. Das passende Team haben Sie schon. Dieses muss nun den richtigen Partner finden.
Es ist ein Trugschluss zu denken, in einer agilen Welt brauche es keine Anforderungsspezifikationen mehr. Wollen Sie bei der Auswahl der Systeme und Partner den Richtigen finden, müssen Sie wissen, was Sie wollen. Der richtige Partner wird nur anhand einer sauberen Spezifikation fähig sein, Kosten und Termine zu schätzen. Diese Transparenz vereinfacht nicht nur das Projektmanagement des ersten Releases, sondern auch des nachgelagerten Betriebs.
Um ehrlich zu sein; je besser wir spezifizierten, desto angemessener der ausgewählte Partner und desto genauer die Kosten- und Terminschätzungen. Die Konzepte, aufgebaut auf Storys und Diagramme, sind auf der strategischen und konzeptionellen Ebene gut und recht, für eine Spezialanfertigung jedoch nicht genügend detailliert.
Das zentrale Element einer sauberen Anforderungsspezifikation sind die Anwendungsfälle. Das sind die detaillierten und strukturierten User Storys. Sie beschreiben in schnörkelloser Sprache die einzelnen Schritte eines Benutzers mit einem System und was danach dabei herauskommt. Daraus leiten Sie die Geschäftsregeln, die Datenstrukturen und die Benutzeroberfläche ab.
Die Systemlieferanten werden die Lösung anhand ihrer Anwendungsfälle präsentieren und nicht anhand einer vorformatierten Verkaufspräsentation. In Standardlösungen werden die Lücken deutlich und bei Eigenentwicklungen kann man die Kosten nach Anwendungsfall aufzeigen. So können Sie dann die Kosten für die jeweiligen User Storys ableiten und entsprechend priorisieren.
Sie werden nicht alles auf einmal in Auftrag geben. Machen Sie kleine Iterationen. Der erste Release muss jedoch lebensfähig sein. Definieren Sie die Anforderungsspezifikation als Vertragsbestandteil und bezahlen Sie das Projekt in Tranchen.
Erstens haben Sie während dem Spezifizieren nie und nimmer alles vorausgesehen (das wäre ohnehin ineffizient), und zweitens verändert sich die Realität von Tag zu Tag; neue Leute mit anderen Ideen kommen hinzu, Systeme reagieren nicht so wie erwartet oder Aufwand und Zeit laufen davon.
Teilen Sie die einzelnen Releases gemäss dem agilen Vorgehen in viele kleine Iterationen ein. Verfolgen Sie den Projektfortschritt anhand erledigter, nicht umgesetzter und neu hinzugefügten Anwendungsfällen. So haben Sie am Ende des Projekts Transparenz über die entstandenen Kosten.
Arbeiten Sie mit Design-freien Wireframes oder Mockups bevor Sie Code schreiben. Damit spielen Sie die oben beschriebenen Anwendungsfälle bildlich durch. Das Ziel ist nicht schöne Layouts zu erstellen, sondern brauchbare. Sie brauchen nicht jeden Bildschirm zu layouten, nur soviel, dass die Testpersonen den Hauptablauf verstanden haben.
Die Mitarbeiter, die danach mit dem Systemarbeiten werden sind mit im Team. Ihre Fachkenntnisse sind wichtig bei der Definition der User Experience. Das sind diejenigen, die die Endbenutzer schulen. Sie werden die Vertreter und Weiterentwickler des Systems, sobald es produktiv geht.
