Wie man an die richtigen Requirements kommt

Bevor wir bei der TechDivision über konkrete Projekte reden bzw. in ein Projekt einsteigen, führen wir inzwischen sehr häufig eine Online-Strategie-Beratung durch. Das hat eine immense Auswirkung auf die Art und Weise, wie wir an Web-Projekte herangehen. Und auf deren Erfolg. Weshalb ist das so?

 

Status Quo

Ganz einfach gesagt geht man an Projekte erfahrungsgemäß so heran, dass man zunächst einmal den Rahmen absteckt. Also was wird gebraucht, was davon sieht man als wichtig, was als weniger wichtig an. Story– und Impact Mapping sind dabei echt gute Tools. Am Ende hat man ein ganz gutes Set an sinnvollen Features. Wenn das noch mit den Zielgruppen übereinstimmt: top. Aus agiler Sicht: Nichts verkehrt damit.

 

Business Value

Nur das mit dem Business Value ist und bleibt schwer. Wer kann schon Business Value beurteilen? Warum sonst stecken Agenturen oft unzählige Tage Aufwand in die tausendste Bildergalerie – oder fertigen alles mehr oder weniger von der Stange, so dass jeder dasselbe bekommt? Hierzu gibt es ein interessantes Buch: „The Art of Business Value„. Der Autor beschreibt hier sehr genau, dass Business Value in jedem Projekt anders ist und es Teil vom Projekt sein muss, diesen zu verstehen. Er sagt prägnant „Business Value is what the business values“.

 

Software im Allgemeinen

Das ist aber kein generelles Problem mit Software und Business Value.

Die meiste Software (selbst Consumer-Smartphone-Apps) wird für einen Bereich entwickelt, der mit Prozessen und Abläufen zu tun hat, und zwar sehr oft aus der Prozesssicht. Und das in einem recht bekannten Umfeld, das von verschiedenen meist bekannten Stakeholdern dominiert wird: Mitarbeitern, Kunden und solchen, die es werden wollen. Oder embedded, also als Teil eines physikalischen Geräts. Nicht dass das weniger komplex wäre, im Gegenteil. In diesem Umfeld ist Requirements Engineering entstanden und dafür wurde es designed. Das Web ist einfach nur etwas anders…

 

Das Web

Corporate Websites und Onlineshops haben jedoch ganz andere, recht komplexe Stakeholder:

  • Suchmaschinen zum Beispiel. Suchmaschinen, die sich immer mehr an echten Menschen orientieren.
  • Und Social Networks.
  • Und Hacker.
  • Und den Rest der Welt (nichts ist so öffentlich wie eine Website).

Außerdem ist ein ganz wesentlicher Teil davon, die richtigen (meist noch völlig unbekannten) Besucher in der richtigen Menge auf die Plattform zu leiten; und ihnen dort etwas zu bieten das sie wollen oder brauchen – das wir aber häufig noch nicht  (im Detail) kennen.

Wir befinden uns hier an einer Schnittstelle zwischen Business, Marketing, Softwareentwicklung, Prozessen, Digitalisierung und allem, was das Unternehmen on- und offline macht; denn egal was der (zukünftige) Kunde sonst tut: er schaut sich die Website / den Shop an.

So wird „Online“ aber selten behandelt. Wenn ich einen Laden habe, kümmere ich mich um Schaufenster, Beschilderung, Werbung etc. Aber einen Onlineshop oder eine Website stelle ich einfach in die Landschaft und hoffe, dass jemand kommt und kauft????

 

Marketing

Ein anderer Ansatz hat in der Vergangenheit häufig nicht geklappt bzw. nicht die erhofften Ergebnisse gebracht: die reine, klassische Marketing-Brille. Bis heute wählen Agenturen den klassischen Weg und bauen Online-Kataloge und Online-Unternehmensbroschüren.

Aber bei Katalogen und Broschüren wird einseitig nach außen „kommuniziert“ und man hofft, dass sie jemand liest und bei mir bestellt.

Online bedeutet, es gibt einen Rückkanal. Der heißt „Interaktion“ – der User kommuniziert. Nicht mehr nur mit dem Megaphon seine Ansichten verbreiten, sondern Kommunikation senden und empfangen.

 

Was ist jetzt mit Requirements Engineering (RE)?

RE funktioniert ganz passabel – meist wird es aber zum falschen Zeitpunkt gemacht. Statt gleich RE zu betreiben, muss man das Thema erstmal breit genug aufziehen. Nicht aus dem meist zu engen Blickwinkel eines Auftraggebers, der eben nicht jahrelange Erfahrung mit Web-Software und Online-Marketing hat.

Man muss die Unternehmensziele kennen und beurteilen, was im Unternehmenskontext überhaupt realistisch ist. Tolle Ideen sind teuer und es braucht auch Kapazität auf Kundenseite.

Wenn man sich nicht ganzheitlich ansieht

  • was das Unternehmen macht,
  • was wie wichtig ist (auch und v.a. unter dem Umsatz-Gesichtpunkt),
  • was das Unternehmen offline macht (wie es z.B. auf Messen auftritt),
  • wie seine Produkte im Laden aussehen,
  • welche User wie auf die Seite kommen und
  • was sie dort tun möchten bzw. sollen,

wird man nie verstehen, was der eigentliche Business Value ist. Es werden weiterhin Websites verkauft, wenn ein Shop oder eine App das richtige wäre – und umgekehrt („weil es sich danach anhört“ ist das schlagende Argument).

Es wird Unmengen Geld in Schnittstellen verbraten (Arbeitsersparnis von 3 Tagen im Monat), während dieselbe Menge Geld in Online-Marketing-Aktionen gesteckt möglicherweise mehrere neue Mitarbeiter bzw. andere, sinnvollere Ansätze finanzieren würde.

Man muss es aktiv herausfinden, sonst wird man es nie besser wissen.

 

Abb.: Teilergebnis aus einem Requirements-Engineering Workshop

 

Relevanz

Eine Web-Agentur kann es sich nicht leisten, es anders anzugehen. Sie befindet sich an einer virtuellen Position, die aus Sicht des Kunden meist viel mehr Relevanz hat als andere Software.

Wie lange braucht ein Unternehmen, bis es pleite ist, wenn es jetzt seine Website abstellt? Das mal den Jahresumsatz und man beginnt zu verstehen, worum es eigentlich geht.

Kein Entwickler oder Product Owner kann langfristig diese Art von Software entwickeln ohne eine gute Vorstellung von Usern, Suchmaschinen, Online-Marketing und dem Business zu haben um das es geht.

Zwei Unternehmen gleichen sich nie, nur weil sie zufällig beide Reisen anbieten. Übrigens ist das auch der ganze Grundgedanke von „Domain Driven Design“ (einer gängingen Praxis in der Softwareentwicklung): die Domäne (das Geschäft) verstehen, für das ich Software entwickle.

 

Der gordische Knoten

… lässt sich nicht lösen, wenn man den Kunden fragt, was er möchte oder braucht. Was er sagt ist erfahrungsgemäß nur teilweise richtig, da er es aus der Perspektive beurteilt, die er am besten kennt: sein Business, seine Prozesse. Und eine falsche Grundannahme entscheidet oft über Erfolg und Misserfolg.

Wie sagte Henry Ford damals schon so passend: „Wenn ich die Leute gefragt hätte, was sie benötigen, hätten sie vermutlich schnellere Pferde genannt….“

Im Gegensatz zum klassischen RE ist das übrigens häufig kein schöner Job, weil man Finger in Wunden legen muss, die ganz schön weh tun können.

Es ist aus unserer Sicht aber der einzige Weg, wie man ehrlich und zielführend beraten kann: Nicht übers Projekt zu reden, sondern einen weiten Blick zu haben um dann beurteilen zu können, welcher kleinstmögliche Ansatz denn sinnvoll ist. Erst dann kann man ein Projekt definieren.

Zu diesem Zeitpunkt kann man dann erst wirkliche Anforderungen definieren, weil man erst dann den eigentlichen Business Value kennt.

 

 

Kommentar abgeben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.