Kitzeln mit COIN-PLC

Requirements Elicitation ist mit der schwierigste Schritt im Entwicklungsprozess. Er steht ganz zu Anfang und hat zum Ziel, die Anforderungen heraus zu kitzeln. Dies erfolgt oftmals hinter verschlossenen Türen mit einer sehr begrenzten Zahl von Teilnehmern/Interessensgruppen. In der Web2.0/Social Community Welt geht man dann mit einer ersten BETA an die Öffentlichkeit.

COIN steht aber für Community Integrated. Das bedeutet also, wir möchten die Community möglichst früh in Entwicklungsprozess mit integrieren. Also nicht erst eine BETA freischalten und dann mal gucken, wie’s läuft. Nun verlangen wir keinesfalls die formvollendete Spezifiaktion von Anforderungen. Das wäre Unsinn. Wir beginnnen langsam und denken, dass wir in einzelnen Schritten den Prozess gemeinsam reifen lassen.  Fragt man Nutzer nach den ersten Wünschen, so ist es schwer, diese ausreichend detailliert anzugeben. Beispielsweise wünscht man sich „Trainingspartner finden“, „Trainingspläne“ oder ähnliches. Um das entsprechend im Sinne der doch noch anonymen Community umzusetzen, sind schlichtweg mehr Informationen nötig. Diese gilt es, heraus zu kitzeln.

In einem ersten Schritt werden wir angedachte, bereits geplante und teilweise in Umsetzung befindliche Dienste und Funktionen in Form von plastischen Zenarien formulieren und auf der Promotion Site von DeinSport darstellen. Hier kann jeder eine Bewertung abgegen. Mitglieder haben den Vorteil, dass Sie SPOTS sammeln können. Schrittweise werden wir weitere Optionen (Kommentare, eigene Szenarien etc.) einfließen lassen. In der Endausbaustufe wird die Community (so wünschen wir uns) eine Großteil, wenn nicht gar den größten Teil der Weiterentwicklung von DeinSport mitbestimmen. Das bedeutet auch, dass wir nicht damit enden, wenn wir in den nächsten Wochen eine erste Version live setzen. Die aktive Mitbestimmung wird ein zentraler Bestandteil des Gesamtsystems und integraler Bestandteil des internen Lieferstufenprozesses (kontinuierliche Entwicklung mit fest getakteten neuen Versionen).

 Die Anforderungsanalyse erfolgt in einer frühen Phase eines Kundenprojektes. Oftmals haben der oder die Kunden und die dahinter stehenden Interessensgruppen (Anwender, Nutzer, Manager, Legislative etc.) eine ungefähre Vorstellung im Kopf von dem, was sie wollen. Es gestaltet sich jedoch immer wieder als schwierig diese Wünsche, Ideen, Konzepte und Themen in eine ausreichende Reife zu überführen, so dass am Ende eines länger dauernden Umsetzungsprozesses das herauskommt, was der oder die Kunden auch wirklich wollen. Nun gibt es vielzählige formale, semi-formale und andere Methodiken oder Vorgehensmodelle, um dem Herr zu werden. Egal, ob agil, starr, formal, formlos, konservativ oder innovativ: Es bleibt ein Problem und die Lösungen dienen  der Risikominimierung. Einmal frei betrachtet von wirtschaftlichen oder zeitlichen Zwängen ist das auch nicht weiter schlimm, denn der Produktlebenszyklus (PLC) ist etwas andauerndes mit den Ziel, das Produkt kontinuierlich zu optimieren und zu verbessern. Ich erinnere mich an einen Professor der Architektur als ein Mitauftraggeber meines ersten Softwareprojektes. Es ging darum, dass ein EDV gestütztes Prüfungs- und Zertifikatsmanagementsystem entwickelt werden sollte. Der gute Professor sagte schlicht: „Es ist doch wohl nicht so schwer. Ich kann schliesslich mit einem Satz sagen, was wir fordern. Wir wollen ein Prüfungsverwaltungssystem!“. Im Prinzip hat er natürlich recht, aber es ist mehr ein Business Objective und keine wirkliche Anforderung. Ok, man könnte sagen, es ist die Mutter aller Anforderungen. Aber der gute war der Meinung, dies müsste als Information ausreichen, um so etwas zu bauen. Nun, das ist Jahre her. Sowohl der Prof, als auch wir, als auch die IT haben sich weiter entwickelt.  Im übrigen hätte eine erste Antwort sein können: „Na, dann brauchen Sie ja nichts mehr zu tun. Sie haben doch bereits eines. Es ist zwar rein organisatorisch, aber es ist ein Prüfungsverwaltungssystem.“ Aber man möchte sich ja auch nicht die ersten Kunden vergraulen .