Kategorie: Anforderungen

„Bei uns ist alles anders!“

Jeder von Euch war sicherlich schon in einer solchen Situation:

  • Der Chef kommt von einer Konferenz: „Wir führen jetzt DevOps ein!“
  • Ein Kollege kommt von einer UX-Weiterbildung: „Wir sollten ab jetzt Paper Prototyping machen!“
  • Der Product Owner kommt von einem neuen Kunden: „Wir sollten den Kunden ganz eng in die Entwicklung einbinden!“
  • Der CIO kommt von einem Vortrag über Netflix: „Unsere Software muss jetzt bei Amazon Web Services betrieben werden.“

Alle berichten enthusiastisch über ihre neuen Erkenntnisse und die Reaktion der Kollegen ist häufig die gleiche: „Das ist zwar schön, geht aber bei uns nicht, weil:“

"Bei uns ist alles anders"

Auf den ersten Blick erscheint diese Aussage meist plausibel und wird oft öffentlichkeitswirksam mit einem Beispiel unterlegt. Dennoch hält diese Aussage bei genauerem Hinsehen oft nicht stand. Hierfür sind uns bisher hauptsächlich 2 Ursachen begegnet: Subjektiv wahrgenommene, extreme Komplexität oder eine überzogene Erwartung bezüglich der Präzision von Software Engineering (SE) Methoden.

Wahrgenommene Komplexität

Dass wir uns in der eigenen Domäne besonders gut auskennen, ist eine absolute Stärke und notwendig, um tolle Produkte zu bauen: Wir kennen die Kunden (manche davon sogar persönlich), die Konkurrenz, den Markt, wichtige Einflussfaktoren und vor allem die Historie des eigenen Unternehmens.

Das hat aber nicht nur Vorteile: Weil wir für unser eigenes Unternehmen alle Details und (noch so abstrusen) Spezialfälle kennen, erscheint unser eigenes Business als viel komplizierter als das der Konkurrenz. Weil wir deren Details und Spezialfälle eben nicht kennen, tendieren wir eher dazu, sie zu simplifizieren. In unserem eigenen Unternehmen sehen wir oft den Wald vor lauter Bäumen nicht und die Fähigkeit zur Abstraktion bleibt im Tagesgeschäft auf der Strecke. Wir tendieren somit dazu, die Situation im eigenen Unternehmen zu übertreiben und die Situation von anderen Unternehmen zu untertreiben.

Untertreiben der fremden Situation, Übertreiben der eigenen Situation

Die wahrgenommene Komplexität (im eigenen Unternehmen) nimmt noch dadurch zu, dass Unternehmen oft groß sind und das Wissen auf viele Köpfe verteilt ist. Somit ist es dem Einzelnen meist gar nicht möglich, sich eine Übersicht zu verschaffen. Um trotzdem zur notwendigen Abstraktion zu kommen, müssen sehr viele Leute involviert werden. Die dadurch entstehende Prozesskomplexität wird dann als Komplexität des zu lösenden Problems wahrgenommen. Diese Prozesskomplexität nimmt man bei der Konkurrenz nicht wahr und somit erscheint deren zu lösendes Problem einfacher.

Diagramm - Wahrgenommene Komplexität

Wahrgenommene Komplexität in Abhängigkeit zum eigenen Detailwissen

Schauen wir uns als Beispiel die Einführung von DevOps an. Wir haben von vielen Unternehmen gehört, dass es erfolgreich eingeführt wurde. Soll es aber bei uns zum Einsatz kommen, dann fallen uns alle Details ein, die dagegen sprechen: alle zu involvierenden Personen und ihre Eigenheiten, Machtspiele und Veränderungsresistenzen, die Komplexität in Varianten und Releases der eigenen Produkte und Systeme und alle internationalen Unterschiede. Alle diese Details sind uns von den anderen Unternehmen nicht bekannt und führen somit nicht zu wahrgenommener Komplexität.

"Überzogene Erwartung"

(Uns) Informatikern fällt es besonders leicht, Gegenbeispiele zu finden, die belegen, dass eine Neuerung nicht 100%ig angewendet werden kann. Dies gilt meist sogar für eine Anwendung im Allgemeinen aber auf jeden Fall für eine Anwendung im eigenen Unternehmen. Selbst wenn die Neuerung zu 99,9% angewendet werden könnte, so finden wir die 0,1%, in denen es nicht funktioniert. Somit liefern wir den Todesstoß durch Gegenbeispiele:

  • „Herr Müller aus dem Betrieb würde niemals mit uns zusammenarbeiten, daher können wir kein DevOps einführen!“
  • „Bei uns können nicht alle Mitarbeiter zeichnen, somit können wir kein Paper Prototyping einführen!“
  • „Die meisten unsere Kunden wissen eh nicht was sie brauchen, somit können wir sie auch nicht in die Entwicklung mit einbinden!“
  • „Wir hatten auch schon mal Kunden aus dem militärischen Bereich, somit dürfen wir gar keine Daten in der Cloud speichern und schon gar nicht bei einem Unternehmen aus den USA!“

Häufig ist jedoch unser Anspruch an SE-Methoden zu hoch. Statt zu erwarten, dass sie uns in einem überwiegenden Teil der Fälle helfen, erwarten wir 100% Anwendbarkeit und Präzision, am besten anwendbar ohne viel Vorwissen und trotzdem mit tollen Ergebnissen. Sofern dies nicht vollständig gegeben ist, tendieren wir stark zur Ablehnung der Methode. Eine solch ablehnende Haltung wird dann gleich noch generalisiert und die Anwendbarkeit der Methode grundsätzlich in Frage gestellt. Es erscheint plausibel, die 99,9% Verbesserung sicherheitshalber fallen zu lassen, da die Methode nicht 100% funktioniert.

"Software Engineering ist keine exakte Wissenschaft!"

Dabei vergessen wir leider: Software Engineering ist keine exakte Wissenschaft. Vielmehr dient es dazu, den Umgang mit vielen komplexen Einflussfaktoren in der Entwicklung von Software besser beherrschbar zu machen:

  • Mitarbeit von vielen Menschen mit ganz unterschiedlichen Hintergründen und Wissensständen
  • Lösung immer neuer Problemstellungen durch Software. Diese Problemstellungen sind meist nicht klar, ändern sich über die Zeit und werden von verschiedenen Menschen verschieden wahrgenommen
  • Verwendung innovativer Technologien, die häufig nicht in allen Facetten verstanden sind

In einem solch komplexen und heterogenen Umfeld ist es eigentlich klar, dass SE-Methoden nur mit Abstraktionen arbeiten und Approximationen anbieten können. Sie sind selten wirklich formal und erfordern immer ein gewisses Expertenwissen. Im Umkehrschluss ist es dann die Aufgabe der anwendenden Menschen, die Übertragbarkeit oder Nichtübertragbarkeit zu erkennen und im Falle einer Anwendung auch konkret auszugestalten.

In der konkreten Anwendung von SE-Methoden bleibt daher immer der Mensch gefordert: Er hat Gestaltungsspielraum und kann seine Kreativität einbringen. Softwareentwicklung ist keine überaus planbare und vorhersehbare Aktivität, sondern erfordert einen hohen Grad Forschungs- und Planungstätigkeiten (Gedanken dazu in einem Blog-Beitrag von Ralf Westphal).

"Es gibt keine Flileßband-Tätigkeiten im Software Engineering!" (Foto: Pradit.Ph / Shutterstock.com, http://www.shutterstock.com/gallery-2909461p1.html?cr=00&pl=edit-00)

Tätigkeiten mit extrem hoher Wiederholbarkeit (wie zum Beispiel Montage am Fließband) gibt es bei der Softwareentwicklung fast nicht, insbesondere weil Software, einmal erschaffen, beliebig ohne Aufwand vervielfältigt werden kann. Für alle wiederkehrenden Aufgaben entstehen Tools zur Automatisierung, wie zum Beispiel für die Testautomatisierung oder für Continuous Delivery. Zu großen Teilen  ist Softwareentwicklung aber weniger formal und planbar und fordert mehr den Menschen. Wäre dies nicht so, dann wäre Softwareentwicklung mittlerweile vollständig automatisiert und nicht mehr auf Menschen angewiesen. Obwohl das offensichtlich ist, haben dennoch viele den Wunsch nach einer Supermethode, die perfekt auf jeden Kontext passt, völlig reproduzierbar ist (und im Falle der Existenz direkt alle Jobs kosten würde).

Das alles soll natürlich nicht heißen, dass SE-Methoden nicht noch weitaus besser werden können und müssen. Mary Shaw zeigt sehr gut auf, wie sich Software Engineering gegenwärtig gegenüber anderen Ingenieursdisziplinen positioniert und welches Verbesserungspotential noch besteht. Die (angewandte) Forschung hat also noch viel zu tun!

In diesem Wissen über SE-Methoden müssen alle Beteiligten handeln: nicht vorschnell Methoden und Ideen ablehnen. Bevor wir sagen „bei uns ist alles anders“ sollten wir darüber nachdenken, wo Abstraktion und Approximation am Werk sind. Die Kunst ist es also gerade nicht, durch ein Gegenbeispiel eine neue Idee auszuhebeln, sondern umfassend zu beurteilen, ob in der Summe eine SE-Methode wirtschaftlich und erfolgreich einsetzbar ist. Das Ergebnis einer Beurteilung ist oft nicht offensichtlich, wer jedoch zu einem Ergebnis kommen kann ist offensichtlich ein Experte.

Mut zur Naivität (Softwareforen Leipzig)

Dachterrasse der Softwareforen Leipzig

Das 10. Treffen der User Group Requirements Engineering der Softwareforen Leipzig hatte den Themenschwerpunkt „Effektive Anforderungserhebung und Ideenfindung im Requirements Engineering“ (hier gibt es die vollständigen Veranstaltungshinweise als PDF). Zum Auftakt der Veranstaltung wurde die Erhebung von Anforderungen oder Informationen im Allgemeinen zunächst einmal nicht aus dem Blickwinkel der Informatik oder des Software Engineerings betrachtet.

10 Grundregeln für verständliche Texte (im Radio)

Der Radio-Journalist Christian Bollert (BEBE Medien GmbH, detektor.fm) berichtete von seinen Erfahrungen beim Vorbereiten und Durchführen von Interviews fürs Radio. Radiohörer haben leider nicht die Möglichkeit bei einem Wort, das sie nicht verstehen kurz anzuhalten und das Wort nachzuschlagen. Auch können sie nicht einfach einige Seiten zurückblättern, um noch einmal etwas nachzuschlagen. Daher müssen Texte im Radio einfach zu verstehen sein. Ich sehe jedoch keinen Grund, warum geschriebene Texte komplizierter sein sollten, schon gar nicht wenn es um Anforderungen geht. Die 10 Grundregeln für Texte im Radio, die Christian Bollert vorgestellt hat, können somit für jegliche Art von Text angewendet werden:

  1. Kurze, verständliche Sätze, möglichst wenig Nebensätze
  2. Gesprochene Sprache, keine Kunstsprache. Nach dem Motto: Wie erzähle ich es einem Freund – mündlich!
  3. Sätze zum Vorlesen sprechend entwickeln (laut vorlesen)
  4. Aktiv statt Passiv; kein Nominalstil, verbal schreiben
  5. Sätze nicht mit Informationen überfrachten
  6. Eines nach dem Anderen erklären
  7. Fremdwörter oder Fachbegriffe sofort erklären oder ganz darauf verzichten
  8. Namen und zentrale Begriffe wiederholen – Redundanz erwünscht! („Redundanz statt Varianz“)
  9. Bildlich vergleichen: So groß wie ein Fußballfeld
  10. Füllwörter nutzen. Sie ermöglichen Atempausen und verbinden (Beispiele: „deshalb“, „darum“, „aus diesem Grund“)

Gerade technische Texte beschreiben oftmals eine überaus komplexe Fachlichkeit. Daher sehe ich überhaupt keinen Grund, warum diese Texte durch umständliche Formulierungen weiter verkompliziert werden sollen.

"Interviews sollten immer sehr gut vorbereitet werden."

Requirements Engineers verwenden oftmals leider nicht allzu viel Zeit auf die Vorbereitung von Interviews mit Stakeholdern. Zudem wird bei der Vorbereitung meist nur festgelegt WAS man von einem Stakeholder wissen möchte und leider nicht WIE man eigentlich danach fragt. Auch hier hatte Christian Bollert nützliche Hinweise. Er hat 12 verschiedene Typen von Fragen vorgestellt und dabei neben Beispiele auch beschrieben, unter welchen Umständen man den jeweiligen Fragentyp einsetzen sollte. So soll beispielsweise die Entscheidungsfrage „Was brauchen Kinder ihrer Meinung nach mehr: mehr Freiheit in der Erziehung oder mehr Struktur?“ verhindern, dass der Befragte um den heißen Brei herumredet oder sich einfach herausreden kann. Mehrfachfragen sollten gar nicht gestellt werden, da Befrage eigentlich nur die Einzelfragen beantworten, die ihnen am besten zusagen und sowieso nie alle Einzelfragen beantworten.

"Mut zur Naivität!"

Auf die Frage „Was macht einen guten Interviewer aus?“ gab Christian Borschert die folgende Antwort:

  • Empathie
  • Geduld
  • Höflichkeit
  • Rollendistanz zum Thema

Der letzte Punkt seiner Antwort warf dann jedoch die Frage auf, ob Fachwissen für Interviewer bzw. Requirements Engineers hilfreich oder schädlich ist. Darauf antwortete Christian Borschwert: „Manchmal ist es gut, wenn man ein Experte ist, sich aber traut trotzdem wieder naive Fragen zu stellen. Wenn das gelingt, dann ist man einer der Großen.“ Also: „Sei schlau, stell Dich dumm.“ Aus eigener Erfahrung kann ich mich hier uneingeschränkt anschließen. Es lohnt sich eigentlich immer auch grundlegende Konzepte noch einmal zu klären. So sollte man nicht davor zurückschrecken, z.B. in einem Versicherungsunternehmen noch einmal zu fragen „Was ist eigentlich ein Tarif?“ Darauf folgt leider nicht selten die Antwort „Solche grundsätzlichen Fragen müssen wir hier nicht mehr klären. Jeder von uns weiß, was ein Tarif ist.“ Lassen sie sich nicht abschrecken und fragen sie ruhig weiter nach: „OK, dann erklären Sie es mir bitte dennoch einmal. Ich kenne mich in Ihrer Domäne nicht so gut aus.“ Meist stellt sich dann heraus, dass es doch nicht so klar ist, was ein Tarif tatsächlich ist. Sollten mehrere Personen an der Befragung teilnehmen, so haben diese fast immer ein unterschiedliches Verständnis, selbst (oder gerade) von grundsätzlichen und vermeidlich einfachen Dingen. Es lohnt sich immer mutig zu sein und naive Fragen zu stellen.

RE ist wie Autofarhen

In seinem tollen Vortrag „Kultur, Methode, Werkzeug – Drei Bausteine effektiver Anforderungserhebung“ verglich Sebastian Adam (Osseno Software GmbH) Requirements Engineering mit einer Autofahrt von Kaiserslautern nach Leipzig. Auf äußerst unterhaltsame Weise veranschaulichte er die Herausforderungen und Entscheidungen, die beim Aufsetzen und der Durchführung eines unternehmensspezifischen Requirements Engineerings getroffen werden müssen. Immer wieder wurde der Vergleich zu einer Autofahrt gezogen:

  • Auto = Tool / Methode:
    Man kann einen Laster, einen Kombi oder einen Sportwagen verwenden. Mit allen Fahrzeugen (Tools) kommt man ans Ziel. Jedoch hat jeder Autotyp vor und Nachteile. Wenn man genug Zeit hat, kann man sogar mit dem Fahrrad fahren und die Landschaft genießen. Möchte man weniger Aufwand betreiben, kann man auch mit der Bahn fahren (= einen Dienstleister beauftragen).
  • Straßenbeschaffenheit = Firmenkultur (bzgl. RE)
    Man kann über Autobahnen, Landstraßen oder Feldwege ans Ziel kommen. Genauso kann eine Firmenkultur die Arbeiten im Requirements Engineering beschleunigen oder verlangsamen.
  • Strecke = Prozess
    Viele Wege führen ans Ziel bzw. im Beispiel führen viele Wege von Kaiserslautern nach Leipzig. Es gibt auch nicht den einen besten Weg, alle haben ihre Vor- und Nachteile.
  • Ziel (z.B. Leipzig) = Produkt-/ Projektumfang

Alle vier Punkte müssen jedoch zusammenpassen und aufeinander abgestimmt. Zwar kann man sicherlich mit einem Ferrari über Feldwege von Kaiserslautern nach Leipzig fahren, aber wer will das schon? Sebastian Adam stellte zudem die provokante Frage (natürlich in Bezug auf RE): „Würden Sie mit jemanden von Kaiserslautern nach Leipzig fahren, der keinen Führerschein hat, nicht weiß wo Leipzig ist, nie in einer Fahrschule war und nur sehr selten Auto fährt?“

"Fahren ohne Navigationssystem?"

Ein wichtiger Punkt fehlt jedoch im obigen Vergleich. Wenn wir heute unterwegs sind, möchten wir unser Navigationssystem nicht mehr vermissen. Das Navigationssystem sagt uns genau, wo wir gerade sind, wie lange es noch dauert und wann wir wohin abbiegen müssen. Zudem reagiert unser Navigationssystem auf unvorhergesehene Probleme und bietet uns alternative Routen an. Außerdem bringt uns unser Navigationssystem immer wieder auf die Stecke zurück, falls wir einen kurzen Abstecher gemacht haben. Aber wo ist das Navigationssystem fürs Requirements Engineering? Genau dieser Frage hat sich das Fraunhofer IESE Spin-Off OSSENO angenommen, das Sebastian Adam mit seinen beiden Kollegen Norman Riegel und Özgür Ünalan gegründet hat.

"Flüssige Informationen versichern!"

Mit seinem enthusiastischen Vortrag „Von der Idee bis zum Code: Flüssige Anforderungen fließen besser“ eröffnete Kurt Schneider (Leibniz Universität Hannover) den zweiten Tag der Veranstaltung. Insbesondere ging es dabei um die Erstellung von Informationsflussmodellen mit der FLOW (kein Akronym) Notation. Dabei unterscheidet man feste und flüssige Informationen. Feste Informationen (z.B. Dokumente, Bilder, Mitschriften, …) haben den Vorteil, dass sie langfristig zugänglich sind, an viele Empfänger weitergegeben werden können, und vor allem können Dritte ohne Hilfe etwas damit anfangen. Ein großer Nachteil ist jedoch, dass die Erstellung und auch der Abruf (z.B. das Auffinden) von festen Informationen sehr viel Zeit kostet. Flüssige Informationen sind nicht persistiert und somit nur in den Köpfen von Mitarbeitern vorhanden. Diese können jedoch schnell und effizient übergeben werden. Nachteilig ist jedoch, dass diese Informationen an Individuen gebunden sind, kapazitätsbeschränkt sind und mit der Zeit „versickern“. Bei der Informationsflussmodellierung mit der FLOW Notation wird für jede Information angegeben, ob diese fest oder flüssig ist. Kurt Schneider gibt auch nicht vor, wie flüssig oder wie fest ein Informationsfluss sein sollte. Sieht man sich jedoch einen Informationsfluss an, so ist oft leicht zu erkennen, welche Abschnitte „verflüssigt“ werden sollten, da sie zu starr und unflexibel sind. Genauso leicht ist zu erkennen, welche Abschnitte „verfestigt“ werden sollten.

"Informationen mit Video verfestigen."

Wenn es ums „Verfestigen“ geht, sollten wir nicht immer gleich an epische Dokumente denken. Informationen können auch auf andere Art persistiert werden. Kurz Schneider schlägt hierzu auch vor, Videos zu verwenden. Videos können auf effiziente Art und Weise Dokumente ersetzen. Dem kann ich mich nur anschließen. Auch wir haben schon sehr positive Erfahrungen mit Videos gemacht. Dabei ist ganz wichtig, dass diese Videos nicht OSCAR-reif gespielt, gedreht, geschnitten und produziert werden müssen. Dem Verwendungszweck angemessen können auch einfach erstellte Videos einen großen Nutzen bringen. Es muss aber auch nicht immer (gleich) Video sein. Ich bevorzuge beispielsweise auch Fotoprotokolle von Meetings. Einfach die Whiteboards, Flipcharts oder sonstigen Ergebnisse, die im Meeting erarbeitet wurden abfotografieren und in einem PDF-Dokument zusammenfassen. Der Aufwand einer manuellen Digitalisierung (d.h. Abtippen der Bilder) bietet oft keinen Mehrwert, der den Aufwand rechtfertigt.

Alles in allem war es wieder mal eine tolle Veranstaltung bei den Softwareforen. Ich freue mich schon auf meinen nächsten Besuch in Leipzig.

On Tour: Softwareforen Leipzig, User Group Requirements Engineering

Leipzig

Am 28./29. April bin ich bei den Softwareforen Leipzig in der User Group Requirements Engineering. Das Thema des 10. User Group Treffens ist „Effektive Anforderungserhebung und Ideenfindung im Requirements Engineering“.  Seit einigen Jahren setze ich am Fraunhofer IESE gezielt ausgewählte Kreativitätstechniken zur Ideenfindung in unterschiedlichen Bereichen. Zusammen mit meinem Kollegen Jörg Dörr werde ich einen interaktiven Workshop zum „Ausprobieren neuer Kreativitätstechniken“ abhalten.

Hier gibt es die vollständigen Veranstaltungshinweise als PDF.

„Das neue System muss aber das Gleiche können … !“

Wir alle haben sie schon gehört, die einfachste Anforderung der Welt:

"Das neue System muss aber das Gleiche können wie das alte!"

Diese Anforderung hört sich zunächst plausibel an. Sie tritt fast immer auf, wenn Unternehmen aus folgenden Gründen ein Softwaresystem modernisieren oder erneuern müssen:

  • „Wir machen jetzt SOA!“
    Ein neues vielversprechendes Architekturparadigma soll verfolgt werden
  • „Finger weg! Keiner weiß was passiert, wenn wir das anfassen!“
    Niemand traut sich mehr, bestimmte Teile des Systems überhaupt noch zu ändern
  • „Das zahlt uns doch kein Kunde!“
    Eine unzureichende Wartbarkeit macht Änderungen viel zu teuer
  • „Wir gehen jetzt in die Cloud!“
    Ein neues Geschäftsmodell soll verfolgt werden
  • „Silverlight ist tot!“
    Eine bisher eingesetzte Technologie wird abgekündigt
  • „So wie bei Apple!“
    Das User Interface soll moderner werden
  • „Unser Vertrieb braucht jetzt auch Apps!“
    Neue Interaktionsgeräte sollen genutzt werden

In allen diesen Fällen scheint es zunächst plausibel, dass das modernisierte oder erneuerte Softwaresystem das Gleiche können soll wie das alte. Schließlich ändern sich nicht die Features, sondern nur die Architektur (die ersten fünf Fälle) oder die User Experience (die letzten vier Fälle).

Schauen wir uns die Fälle also genauer an:

Die Architektur soll sich ändern: Das Softwaresystem ist offensichtlich schon älter! Das heißt, dass seit dem Zeitpunkt der ursprünglichen Konzeption schon einiges an Zeit vergangen ist. In dieser Zeit wurden viele Ergänzungen und Änderungen umgesetzt. Jede dieser Ergänzungen und Änderungen wurde mit Rücksicht auf den jeweiligen Zustand des Systems oder die Situation des Unternehmens durchgeführt:

  • „Das haben wir auf die Schnelle mal reingebaut!“
  • „Das sollte eigentlich nie so lange drin bleiben!“
  • „Das benutzt schon seit Jahren keiner mehr, aber die Entfernung ist zu riskant!“
  • „Wir mussten damals auf vorhandene Features Rücksicht nehmen: Hätten wir die Freiheit gehabt, hätten wir es ganz anders gemacht!“

Offensichtlich wurden in der Lebenszeit des Systems (oft aus guten Gründen) viele Kompromisse eingegangen, die sich im heutigen System widerspiegeln. Diese Kompromisslösungen wollte eigentlich niemand haben und somit ist auch das System nicht so, wie man es eigentlich haben wollte. Wird das System jetzt massiv modernisiert oder gar erneuert (wie es für eine Architekturänderung nötig ist), dann ist es offensichtlich, dass das neue System gerade nicht das Gleiche machen soll wie das alte.

Diagramm - Anforderungen im Lebenszyklus eines Softwaresystems

Anforderungen im Lebenszyklus eines Softwaresystems

Die User Experience soll sich ändern: Hier geht es gerade darum, das System anders zu benutzen als zuvor.

  • „Es soll einfacher zu benutzen sein!“
  • „Es soll nicht mehr so kompliziert sein!“
  • „Wir benutzen nur 15% der Features!“
  • „Es sieht noch aus wie in den 80ern!“
  • „Auf meinem iPad geht alles einfacher!“

Der Wunsch nach veränderter Benutzung führt immer dazu, dass sowohl Interaktionsdesign als auch visuelles Design massiv überarbeitet werden müssen. Deshalb ist es offensichtlich, dass das neue System gerade nicht das Gleiche machen soll wie das alte. Eine massive Überarbeitung des Interaktionsdesigns oder der Einsatz einer neuen Client-Plattform (z.B. Mobile statt Desktop) führt so gut wie immer auch zu einer Anpassung der darunterliegenden Architektur und damit zu noch mehr Aufwand.

Sowohl für die Veränderung der Architektur als auch der User Experience stellen wir somit fest:

  • Die Veränderungen führen zu massivem Aufwand!
  • Das neue System soll gerade nicht das Gleiche machen wie das alte!

Die einfachste Anforderung der Welt ist somit unsinnig und führt immer zu stark unterschätztem (und auch unnötigem) Aufwand für die Rekonstruktion aller alten Anforderungen, da diese natürlich nie konsistent und vollständig dokumentiert sind. Dennoch hören wir diese Anforderung immer wieder. Und warum? Weil sie so einfach zu formulieren ist, und zwar von jedem, egal wie gut er das System kennt.

Trotzdem hat diese Anforderung auch einen wahren Kern. Natürlich muss man für eine Modernisierung oder Erneuerung viele der alten Anforderungen wieder rekonstruieren und berücksichtigen, aber eben nicht pauschal alle.

Verlgeich Nikon D100 Spiegelreflex-Kleinbildkamera und der Nikon D100 Spieglereflex-Digitalkamera (Front und Rückansicht)

Den signifikanten Einfluss, den ein Technologiewechsel sowohl auf die Architektur eines Systems, als auch auf die User Experience hat, zeigt das Evolutionsbeispiel der Nikon F100 Spiegelreflex-Kleinbildkamera zur Nikon D100 Spiegelreflex-Digitalkamera. Eine neue Technologie eröffnet oft auch neue Möglichkeiten (hier z.B. die Vorschaufunktion am eingebauten Monitor) und macht bisherige Funktionen überflüssig (hier z.B. das Zurückspulen eines Films).

Die Kunst liegt nun genau darin, die Unterscheidung zu treffen, welche Anforderungen vom alten System noch gebraucht werden und welche nicht. Der Ansatz, um auf die zukünftigen Anforderungen zu kommen, besteht gerade nicht darin, zunächst alle alten Anforderungen genau zu erheben und dann die irrelevanten wieder zu streichen. Stattdessen empfehlen wir, die Hauptanforderungen konstruktiv aus der intendierten Benutzung abzuleiten und nicht aus den Features des alten Systems. Dies ist die neue Grundlage für die zukünftige Architektur des Systems. Auf diesem stabilen Fundament kann dann das neue System aufgebaut werden. Bei bestätigtem Bedarf können Detailfeatures aus dem alten System konsistent ergänzt werden.

Wenn schon, dann gleich richtig!

Wir haben gezeigt, dass die Modernisierung oder Erneuerung eines Systems für eine Verbesserung der Architektur und der User Experience IMMER zu hohem Aufwand führt und das neue System NIE das Gleiche machen soll wie das alte. Wer also diesen hohen Aufwand auf sich nimmt, sollte bei einer Modernisierung oder Erneuerung NIE versuchen, die gleichen Anforderungen wie vorher umzusetzen. Offensichtlich, oder?

© 2017 mibinu

Theme von Anders NorenNach oben ↑