- Juristische Aspekte und Prototyping
Juristisch betrachtet beginnt das Prototyping damit, dass der Soll-Zustand (Juristen sprechen von der vereinbarten Beschaffenheit) durch den Prototypen in seiner Version 1.0 beschrieben wird.
Der Kunde testet nun in mehreren Phasen den Prototypen und überprüft, ob dieser die Funktionen und Eigenschaften aufweist, die der Kunde bei der Realisierung seine Geschäftsprozesse erwartet und braucht. Im Rahmen dieser Phasen fertigt der Kunde durch seine Nutzer (die dann Key-User genannt werden) eine Dokumentation an. Diese Dokumentation dient den Mitarbeitern des IT- Unternehmens dazu, Änderungswünsche des Kunden zu verstehen und umzusetzen.
Juristisch betrachtet ist diese Dokumentation ein Teil der vereinbarten Beschaffenheit. Das IT- Unternehmen muss am Ende eines Zyklusses ein Ergebnis abliefern, das dem Prototypen entspricht unter Berücksichtigung der Modifikationen, die der Kunde in der Dokumentation niedergelegt hat.
Aus der Sicht des IT- Unternehmens ist es ratsam, genau darauf zu achten, ob die in der Dokumentation niedergelegten Änderungswünschen des Kunden tatsächlich ein Change sind oder Konkretisierungen des Zieles, das die Parteien mit dem Prototypen erreichen wollen.
Deswegen ist sehr zu empfehlen, dass man zu Beginn des Prototyping ein Lastenheft anfertigt, das wie üblich die groben Ziele des Vertrages und eine grobe Spezifikation über die Funktionen und Eigenschaften des Prototypen zum Zeitpunkt der Abnahme dokumentiert. Wenn man diesen Schritt unterlässt, läuft man immer Gefahr, dass der Kunde bei der Anfertigung der Dokumentation viele Dinge realisiert haben möchte, von denen vorher niemals die Rede war („Wünsch Dir was- Liste“).
Der richtige Lauf des Prototyping lautet also, zunächst wird das Lastenheft angefertigt und eine 1. Version des Prototypen, die darauf beruht, was der ITl-er meint aus dem Lastenheft verstanden zu haben. Danach wird in Zyklen gearbeitet, wobei die Parteien die Anzahl der Zyklen gemessen am Budget frei festlegen können.
Es ist klar, dass am Ende eines jeden Zyklusses der Ist-Zustand des Prototypen ein wenig mehr der Vorstellung des Kunden entspricht. Es ist auch klar, dass eine unendliche Anzahl von Zyklen nicht realisierbar ist. So ist es schlicht eine Frage des Budgets, in welchem Umfang und wie häufig die Zyklen durchlaufen werden sollen.
Jeder Zyklus beginnt mit einer Vorstellung des jeweiligen Ist- Zustandes des Prototypen. Dann müssen die Key-User dokumentieren, welche Änderungswünsche sie haben. Diese Dokumentation muss von dem IT- Unternehmen darauf geprüft werden können, ob die Änderungswünsche einen Change bedeuten oder Konkretisierungen des Lastenheftes sind. Im Zweifelsfall ist immer der Lenkungsausschuss anzurufen, der ja eine Deeskalationsfunktion hat und sowohl Budget als auch die Kundenzufriedenheit im Auge haben muss. Nachdem das IT- Unternehmen die so geprüfte Dokumentation freigegeben hat, ist der Prototyp entsprechend anzupassen und dann wieder dem Kunden vorzustellen. Irgendwann entscheidet man sich, den GoLive mit Echtdaten vorzubereiten und zu realisieren.
Ganz klar: Das Prototyping ist auch nicht der Stein der Weisen. Es wird immer eine Diskrepanz zwischen dem Ist-Zustand des Prototypen und der Wunschvorstellung des Kunden bleiben. Nach wie vor geht es darum, dass die Programmierer die Vorgaben der Nutzer umsetzen müssen. Und dieser Weg von dem Gehirn des Nutzers in das Gehirn des Programmierers ist ein komplexer Vorgang. Schwachstellen sind nicht auszuschließen. Deswegen tun die Parteien gut daran, im Rahmen des Lenkungsausschusses ein realistisches Maß des Machbaren zu bestimmen.
