We are Developers

Ich hatte die “Ehre”, vor einem Monat die We are Developers Konferenz zu besuchen. Während der Konferenz gab es schon einige Unstimmigkeiten, welche Javascript Frameworks wohl die Besten sind. Viele Speaker sprachen sich gegen Framework X aus und verfechten das ultimative Framework Y. So ging es die ganze Zeit. Als eine Speakerin ein Framework (ich glaub es ging um das Framework von Xamarin) nicht kannte, ging ein Raunzen und Unverständnis durchs Publikum. Dieses Verhaltensmuster bringt mich immer zum Schmunzeln. Aus meiner Sicht wird es immer eine bessere technologische Lösung für ein Problem geben, als die momentan gewählte. Die (aus meiner Sicht) einzig relevanten Fragen am Ende des Tages sind: Konnte ich mit meiner Lösung den Kunden zufrieden stellen? Werde ich in Zukunft auf Änderungen meines Kunden effizient reagieren können? Nuancen in Framework-Unterschieden sind für mich dabei keiner religiösen Diskussion wert.

ÖBB – die Österreichische Bundesbahn

Szenenwechsel. Die ÖBB Seite wurde im Q1 / Q2 neugemacht. Warum nutze ich die ÖBB Seite?

• Ich will eine Bahnauskunft haben: Wie komme ich zum Zeitpunkt X von A nach B?
• Wie teuer ist das?
• Wie schaut es mit Sparschiene Tickets aus?

Am Rande: Worum klebt die Seite links? Aber zurück zum eigentlichen Problem: Die Fahrplanauskunft ist noch immer nicht “responsive”. Oder besser gesagt: Gott sei Dank! Weil ein Teil des Shops wurde ja schon neu gemacht: Die Preisauskunft (bzw. auch Streckenauskunft). Die Seite braucht mal über eine Sekunde zum Laden und bringt so manch altes Handy ins Schwitzen. Aber warum? Ich will doch bloß eine Zahl angezeigt bekommen …

Und wie kann ich jetzt den Preis mit Vorteilscard feststellen? Anscheinend erwartet man sich, dass der Endanwender der Arithmetik mächtig ist und selbst rechnet (1 Erwachsener Normalpreis) … Man muss oben auf “Erwachsener” klicken und gelangt zu einer neuen Unterseite.

Na – schon schlauer geworden? Noch nicht? Kein Problem: Wieder auf den 1. Eintrag klicken und auf “Ermäßigung hinzufügen”. Es klappt seitlich ein Menu mit einer mega, mega sinnlosen “Fade-In” Animation auf und man kann dann endlich seine Vorteilskarte wählen.

Nach einer Odyssee durch die Tiefen der ÖBB Seite weiß ich nun endlich den Preis. Nun fehlen mir noch wichtige Informationen: in welche Richtung fährt das Verkehrsmittel? Oft praktisch, wenn man e.g. an einem Bus Bahnhof steht und sich nicht nur auf die Zahl verlassen will. Bemerkungen zu den Verkehrsmitteln, die Stationen, … Schon gefunden? Ich habs lange nicht: unten erscheint ein Balken “Reisevorschau”, welcher die Informationen zu Tage bringt.

Der Entwickler hat sich anscheinend große Mühe gegeben, Dinge zu perfektionieren:

• Sinnlose Animationen einfügen.
• Sinnloser Image Hintergrund mit sinnloser Opacity.
• Sinnlose Anzeige meiner gewählten Strecke / Zeit (dieses 3 stufige Ding schaut super schön aus und zeigt auch die Kompetenz des Entwicklers – trotzdem hätte man die Energie – wie oben festgestellt – sinnvoller einsetzen können).
• Und auch oben im Schnellselektionsmenü (Zugzeit, Von-Bis) – sinnlose Animationen bis zum Abwinken.

Für mich als durchaus erfahrener Endanwender stellt die Seite ein Sammelsurium aus Technologien und Spielerein dar. Aber meine End-To-End Szenarien kann ich nicht mehr effizient ausführen (im Kontrast zur alten Seite). Geschweige die Seite auf meinem doch schon etwas älteren Windows Phone ausführen (auf dem aber durchaus komplexe Seiten noch sehr performant funktionieren) – ein Randproblem.

Wo ich das Problem sehe

Was sind nun die Gemeinsamkeiten dieser beiden doch konträren Beobachtungen? Ich unterstelle den betroffenen Entwickler(gruppen) ein großes Interesse an technischen “Spielerein” (was per se ja nicht schlecht ist) – aber ein geringes Interesse, den Endbenutzer zu verstehen. Als Entwickler ist man ständig mit Framework Hypes beschäftigt, dass einem keine Zeit mehr für andere Dinge bleibt. Doch heute ist man kein “Programmierer” mehr, sondern ein “Software-Entwickler” – dessen Verständnis auch Requirement-Engineerung(-Grundlagen) und womöglich auch Business-Analyse(-Grundlagen) umfassen sollte.

Auch denke ich, dass bei vielen inzwischen eine Feature-Island-Denkweise eingetreten ist: Man schraubt an kleinen isolierten Features ohne das große Ganze zu kennen bzw. zu verstehen. Wie soll man es dann kritisch hinterfragen? Die einzige Möglichkeit ist, dass man es vorgekaut bekommt – was aber auch nicht Sinn der Sache ist und oft auch nur bedingt funktioniert.

Warum wir Software bauen?

Ganz banal gesagt: Um den Kunden / Endanwender das Leben zu erleichtern. Man kann im Vorfeld Messkriterien festlegen (e.g. Abarbeitungsdauer einer gewissen Aufgabe), die nach der Änderung (e.g. Einführung der Software) erneut gemessen werden und hoffentlich eine Verbesserung zeigen. Die Software soll dem Endanwender einen Mehrwert bieten – ansonsten wird er diese im schlimmsten Fall gekonnt ablehnen oder im besten Fall einfach nur “hassen”.

Im Laufe meiner Recherche bin ich auf einige Disziplinen gestoßen, welche uns dabei helfen, Software zu bauen, die der Kunde liebt und die ihm den Alltag vereinfacht. Die Disziplinen werden im Folgenden ohne bestimmte Reihenfolge aufgezählt.

Business Analysis

Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value. (BABOK V3)

Business analysis is the application of knowledge, skills, tools, and techniques to:

• Determine problems and identify business needs
• dentify and recommend viable solutions for meeting those needs
• Elicit, document, and manage stakeholder requirements in order to meet business and project objectives
• Facilitate the successful implementation of the product, service, or end result of the program or project.

In short, business analysis is the set of activities performed to identify business needs and recommend relevant solutions; and to elicit, document, and manage requirements. (PMI)

Wie die Definition schon sagt geht es um Zukunft: Wir haben eine Ist-Zustand und einen Soll-/Wollen-/Bedürfnis-Zustand (der Need). Das nächste große Schlagwort ist Solution, welche uns dabei hilft, den Need zu erreichen. Die Separierung zwischen Need und Requirement gefällt mir sehr gut. Ein Need wird zu einem Requirement, wenn jemand entscheidet, dass die Umsetzung getätigt wird.

Needs are things that someone wants but doesn’t have. [3]

Business-Analyse kann auf verschiedenen Ebenen im Unternehmen stattfinden – aber sie haben eines gemeinsam: In welche Richtung sollen wir uns bewegen? Dabei besteht Business-Analyse aus zwei Teilen [3]:

• Goal: Beschreibt, warum man die Analyse machen will. Sollen die Betriebseinnahmen gesteigert werden oder Kosten reduziert werden? Oder …?
• Process: Der Prozess beschreibt das “Wie”. Beschreibt, was die Lösung tun soll und können muss.

Wie bereits erwähnt, kann Business-Analyse auf verschiedenen hierarchischen Ebenen stattfinden [3] - ein Auszug:

• Enterprise Level: Hier geht es um strategische Entscheidungen – in welche Richtung soll sich das Unternehmen entwickeln?
• Organizational Level: Hier geht es um einzelne Unternehmensbereiche und deren Entwicklung. Die Entwicklung in den einzelnen Units müssen oft nichts gemeinsam haben. So kann bei Microsoft die Xbox Sparte andere (Teil-)Ziele/Bedürfnisse als die Office-Sparte haben.
• Operational Level: Das kann e.g. die Entwicklung einzelner Abteilungen betreffen.
• Project Level: Projekte in diesem Level helfen dem Operational Level die Ziele zu erreichen. Vor allem ist es hier (wie auch bei den anderen Levels) sehr wichtig, mit den oberen Levels konform zu sein: Damit das Operational Level seine Ziele erreichen kann, braucht es das Project Level. Business Analyse hilft dabei, ein “Alignment” zu finden.

Dem Artikel ist zu entnehmen, dass der Business Analyst immer mehr an Bedeutung auch in den oberen Levels – jenseits des Project Levels – erlangt.

Was ist jetzt der Unterschied zwischen Requirements engineering (RE) und Business Analysis (BA)? Diese Frage ist prinzipiell schwer zu beantworten. In einem Podcast mit Peter Hruschka war das Fazit, dass die Grenzen zwischen den beiden Disziplinen verschwommen bis nicht existent sind. Es gab aber auch die Sichtweise, dass BA ein eigenes Tool- und Mindset braucht.

Zu diesen beiden Sichtweisen hab ich noch weitere Recherchen gestartet. Am besten startet man mit der Definition von Requirement-Engineering:

Requirements engineering (RE) refers to the process of defining, documenting and maintaining requirements to the sub-fields of systems engineering and software engineering concerned with this process. Wikipedia

Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system. (Ian Sommerville und Pete Sawyer (1997))

Die wichtigsten Aspekte bei dieser Definition sind für mich:

• RE ist nicht nur auf die IT Welt beschränkt. Ich kann auch beim Bau eines Kleiderschranks RE betreiben.
• Auf den ersten Blick, scheint das Ziel und die Tätigkeiten ähnlich jener von BA zu sein – wie auch von Hruschka [4] beschrieben.

Als nächstes möchte ich die beiden Begriffe Need und Requirement betrachten – ein Zitat [3]:

Needs and requirements may look like they mean the same thing, but here’s the difference: The need is the objective (Ziel), and the requirement is the decision about whether to do something to achieve that objective. A need turns into a requirement when someone recognizes that having the unmet (unerfüllt) need is unacceptable and decides he requires the need to be met.

Auch hier wurde wieder alles auf den Punkt gebracht: Zuerst erkennen wir die Bedürfnisse (Needs), welche das Ziel (Objective) darstellen. Anschließend entscheiden wir, ob wir es umzusetzen, um anschließend Anforderungen (Requirements) zu definieren.

In der Arbeitsgruppe, in der ich momentan bin, haben wir folgendes Beispiel diskutiert:

Das Bild zeigt eine Leitstelle und einen Disponenten. Der Disponent hat die Informationen auf 6-7 Monitoren verteilt. Wenn er Glück hat, kann er diese mit 1 Maus und Tastatur erreichen. Erscheint eine wichtige Information auf einem Monitor und der Disponent konzentriert sich gerade auf einen anderen Monitor, so kann die wichtige Information übersehen werden. Der Need nach einer Integration der Systeme muss erst gefunden werden. Der Benutzer ist sich des Needs vermutlich nicht bewusst – er findet die jetzige Situation wahrscheinlich einfach nur unpraktisch. Die Aufgabe des Business Analysten wäre jetzt, den Need zu erkennen, diese ganze Informationen zu integrieren (auf 1-2 Monitoren) bzw. aggregieren (soweit möglich). Es wird mehrere Solutions geben. Möglicherweise wird das von einem Business-Analysten auf Project- oder Operational-Level erkannt und der Auftrag “bubbeld” bis ins Enterprise-Level rauf – wo sich dann das Unternehmen “Integration von Systemen” auf die Fahne heftet.

Entscheidet man sich für eine Lösung, so können Requirements verfasst werden die u.U. auch festlegen, dass eine Anpassung der Rollen (e.g. Zuständigkeit, wer welche Daten beobachten muss) der Disponenten überarbeitet werden muss (e.g. nicht IT-Lösung).

Wie man am obigen Beispiel sieht, ist der Need oft nicht leicht zu identifizieren, weil der Kunde oft nicht weiß, was er wirklich braucht bzw. will. Eine weitere Sichtweise sehen wir in folgendem Bild [3]:

Mir gefällt die Separierung in Business und Solution-Requirements sehr gut.

Business requirements: Diese Anforderungen leiten sich von den Needs des Business ab. Wikipedia hat eine sehr gute Zusammenfassung:

Business requirements must be delivered to provide value. Products, systems, software, and processes are the ways how to deliver, satisfy, or meet the business requirements whats.

Die Beschreibung über die Hintergründe (Solution-Independent), geht oft auf halben Weg verloren, weil es niemand dokumentiert. Die anderen Requirements (für Produkte, Systeme und Software) beschreiben eben die Lösung, wie wir die “Sache” erreichen können. Auch hier zur Erinnerung (und auch in Wikipedia erwähnt): das Ganze ist nicht nur auf die Software Disziplin beschränkt.

Business requirements whats do not decompose into product/system/software requirements hows. […] Business requirements exist within the business environment and must be discovered, whereas product requirements are human-defined (specified). Business requirements are not just high-level but need to be driven down to detail.

Stakeholder Requirements: Beschreibt ebenfalls die Needs und Problems - aber aus Sicht der Stakeholder, um ihre Ziele zu erreichen. Ähnlich sieht es Wiegers [5]

User requirements describe goals or tasks the users must be able to perform with the product that will provide value to someone

Wiegers spricht hier von einem Product - aber meiner Interpretation nach ist es gleichzusetzen mit einer Solution (wenngleich mir Solution in diesem Kontext besser gefällt – womöglich der ungenauen Separierung von Requirement-Engineering und Business-Analyse zu verschulden?! Wiegers scheint sich auch speziell auf Software-Lösungen zu spezialisieren).

Solution Requirements: Beschreiben die Eigenschaften, welche eine Lösung (Solution) haben muss, um den Needs und Problemen gerecht zu werden. Ein Vision Statement kann beim Beschreiben helfen. Ein Vision and Scope Document gibt eine Grundstruktur zum Formulieren der Anforderungen und Lösungen.

Man unterteilt Solution Requirements in Functional Requirements und Non-Functional Requirements. Auch hier gilt wieder: es muss sich nicht zwingend um Requirements in einem technischen System handeln. Wiegers [5] definiert es sehr schön:

Functional requirements specify the behaviors the product will exhibit under specific conditions. They describe what the developers must implement to enable users to accomplish their tasks (user requirements), thereby satisfying the business requirements.

Transition requirements: Beschreiben Anforderungen, um die Lösung von der Entwicklung in das Real-World-Bussines zu bekommen.

Technology requirements: Nachdem die Solution-Requirements feststehen, kann man die Anforderungen an die technologische Lösung beschreiben. Sie dienen als Bindeglied zwischen BA und Technology-Engineers (e.g. Systemarchitekten, Programmierer, …). Technology Requirements beschreiben genau wie sich die Lösung (Design und Architektur) verhält und funktioniert. Auch hier ist wichtig zu beachten: Man muss zuerst den Need verstehen, bevor man sich an diese Anforderungen heranmacht.

Ich denke, das deckt sich auch mit Wiegers [5] Definition (Ich glaube “System” und “Technology” ist etwas unterschiedlich - aber man befindet sich hier auf gleichener Ebene):

System requirements describe the requirements for a product that is composed of multiple components or subsystems (ISO/IEC/IEEE 2011).

Also für mich sind die Ziele von Requirement-Engineering und Business-Analyse verschieden (und das damit verbundene Mindset um die Ziele zu erreichen). Natürlich wird man eine Schnittmenge zwischen beiden Disziplinen finden und sollte die Erfahrungen und Tools der jeweils anderen Disziplin auch nutzen. Aber ich denke, in der einen Disziplin gut sein ist kein Freifahrtschein die andere Disziplin zu praktizieren.

Der schwerste Teil in beiden Disziplinen liegt (logischerweise) in der Durchführung. Gute Social-Skills und ein gutes Verständnis des Toolsets ist ein Muss. Tools für Elicitation in Business Analyse sind (unvollständig) [3]:

• Document Analysis: Das Tagesgeschäft der Firma verstehen. Betreibt man BA in der eigenen Firma, ist das wahrscheinlich nicht das effizienteste Tool.
• Observation: Das Beobachten kann ein hilfreiches Hilfsmittel sein. Die Gründe um etwas zu Beobachten können e.g. sein, dass man mit dem Prozess nicht vertraut ist. Auch kann man Einschränkungen und Ausnahmen identifizieren, deren sich Benutzer womöglich gar nicht erst bewusst sind.
• Interviews: Wichtig ist, dass man Open-Ended Questions stellt.
• Fragebögen: Hier kann man Stakeholder befragen, ohne direkt zu ihnen Zugang zu haben.
• Requirement Workshops: Hier kann man das geballte Wissen der Gruppe nutzen, um an Requirements zu kommen.
• Brainstorm: Viele Ideen in kurzer Zeit erzeugen.
• Focus Groups: Beschreibung siehe weiter unten.
• uvm.

Was spricht nun dagegen, diese Techniken auch bei Requirement-Engineering anzuwenden? Nichts! Auch Requirement-Engineering hat eine Elicitation Phase, wo man im Trüben fischt. Doch etwas spezifische Business-Analyse Tasks/Tools sind (aus meiner Sicht):

• Business-Needs identifizieren: Hier kann helfen die Mission-Statements des Unternehmens zu analysieren bzw. den Markt zu studieren.
• Probleme im Unternehmen identifizieren: Hat man immer wenn man Ziele verfolgt - es kommt zu Problemen und Hindernissen. Es gilt diese zu identifizieren.
• Warum?: Der Business-Analyst sollte die Warum-Frage ständig fragen – um die Probleme und die Root-Causes zu verstehen.
• uvm.

Sehr viele Details findet man noch in [3] - die auch deutlich zeigen, dass diese Methoden und Denkweisen Business-Analyse vorenthalten bleiben (ich hab sie selbst nur überflogen). Ebenfalls eine interessanter Ansatz ist jener von PMI: SWOT (strengths, weaknesses, opportunities, und threats). SWOT wird in interne (strengths, weaknesses) und externe Faktoren (opportunities, threats) gegliedert. Ein weiteres Tool was PMI anpreist ist Cause-and-Effect Diagrams.

Cause-and-effect diagrams decompose a problem or opportunity to help trace an undesirable effect back to its root cause. These diagrams help to break down the business problem or opportunity into components to aid understanding and generally provide the main aspects of the problem to analyze. [PMI]

Für weitere Informationen scheint der PMI Guide recht gut zu sein (hab auch nur Teile davon gelesen).

Scenario Focused Engineering

Eine interessante Sichtweise wurde innerhalb von Microsoft gefunden: Scenario Focused Engineering [1].

Scenario Focused Engineering is a set of methods and mindsets that help engineers understand customers deeply and create innovative products that they will love

Es geht hier also darum, dem Kunden wirklich einen spürbaren Mehrwert zu liefern. Es ist heute nicht mehr ausreichend Software zu bauen, welche aus Sicht der Entwicklungsteams seinen “Zweck erfüllt”. Ja – in der agilen Welt sind die Feedbackzyklen geringer – allerdings bin ich der Meinung, dass das schon viel zu spät ist. Usability-Testing und Beta-Testing sind gut – aber können eine schlechte initiale Analyse des Problems nicht mehr ausbügeln. Auch das Resultat dieser Analysen bzw. Feedback sind schwierig zu verwerten – kommt die fortgeschrittene Version nicht gut an, steht großes Refactoring an (zeit- und kostenintensiv). Große Teile des obigen Mindsets passieren im Vorfeld – mit dem Ziel, das Problem des Kunden zu verstehen und eine Lösung auszuarbeiten, die dem Kunden den erhofften Mehrwert liefert.

The key to achieving a much deeper sense of connection and delight with a customer is to understand and satisfy the customer’s real-world needs, which are inherently complex and multifaceted. To do that, you must focus on building end-to-end experiences, not individual features. […] Of course, you will still build features as part of your product-development process. But you want to avoid building islands of individual features that don’t interrelate with each other [1]

Scenario Focused Engineering hat seine Ursprünge in [1]

• user-centered design (UCD)
• design thinking
• customer-focused design (CFD)
• human-computer interaction (HCI)
• and practices we observed while working with Microsoft teams and from the industry

Ich muss gestehen, dass ich diese Begriffe irgendwann im Laufe des Studiums gehört habe – sie jetzt auch nicht mehr separieren könnte. Eine schöne Erklärung ist [2]:

• Usability, also referred to as human factors, is the study of how humans relate to any product. Usability practices could be implemented in everything from a toaster to a doorknob, and even the packaging of both
• Human−computer interaction (HCI) is rooted in usability, but it focuses on how humans relate to computing products.
• User-centered design (UCD) emerged from HCI and is a software design methodology for developers and designers. Essentially, it helps them make applications that meet the needs of their users.
• Additionally, there is the subject of user experience (UX). UX is a term often used to summarize the entire experience of a software product. It not only encompasses functionality, but also how engaging and delightful an application is to use.

Der Plan ist also Software zu bauen, welche auf den Benutzer zugeschnitten ist. Aber auf was legen Benutzer heute wert? Auch dieser Frage widmete sich der Autor [1]:

• It does what I need it to, when I need it
• I get the job done quicker
• Always know what I want
• …

Für Entwickler wird die Latte schon recht hoch angesetzt: Man muss das Alltagsszenario des Benutzers verstehen, ob diese angeführten Eigenschaften erfüllen zu können. Die Literatur hat hier auch schon Abstufungen definiert, die den Grad des User Focus wiederspiegelt. Die Abbildung zeigt die User Experience Maturity Pyramid:

Ein Grund für die hohe Latte ist wahrscheinlich auch, dass Benutzer immer mehr “Delightful” Produkte im Alltag benutzen (e.g. iPhone). Die Erwartung an andere Software Produkte ist daher dementsprechend hoch.

When we say that a solution is delightful or desirable for a customer, what we mean is that it evokes some kind of nontrivial positive emotion. Sometimes that positive emotion will be a sense of satisfaction with getting a tough job done more easily than expected. [1]

Fletcher und De Bonte haben auch einen interessanten Prozess vorgestellt: Den Fast Feedback Cycle [1].

Die wichtigsten Eigenschaften sind:

• Target Customer: Man kann es nicht allen Kunden recht machen. Daher sollte man die Zielkunden aussuchen, von denen man annimmt, dass sie die größte und einflussreichste Gruppe sind. Auch sind an dieser Stelle one-size-fits-all approaches zu identifizieren. Das sind aus meiner Sicht Software product lines. Hier gilt es meiner Meinung nach Cluster zu finden, die ähnliche Interessen und Wünsche wiederspiegeln.
• Observe: Oft wissen Kunden gar nicht was ihnen fehlt. Umso schwieriger (bzw. umso wichtiger), sie bei der Suche nach Lösungen zu unterstützen. Das Ganze ist sehr facettenreich – eine grobe Übersicht von Hilfsmittel findet man im Buch [1] bzw. etwas weiter unten.
• Frame: Nach dem Beobachten des Kunden hat man eine Menge Wüsche identifiziert und sollte diese ordnen / priorisieren und filtern und in weiterer Folge ausformulieren. Szenarien sind ein Hilfsmittel, bei dem diese Wünsche beschrieben werden, ohne dabei auf eine Lösung einzugehen.
• Brainstorm: In dieser Phase sollte man sich Lösungen überlegen – die Betonung liegt auf Lösungen – plural: “If you want to have good ideas you must have many ideas.”
• Build: In dieser Phase setzt man die vielversprechendsten Ideen um. E.g. in Form vom Prototypen umso ein Feedback vom Kunden zu bekommen. Das Ganze wiederholt sich dann wieder mit Observe, da man den Kunden beobachtet, wie er mit Hilfe des Prototypen jetzt sein Szenario löst.

Auf den ersten Blick scheinen diese Punkte trivial zu sein – aber man ertappt sich immer wieder dabei, diese Schritte gerne zu überspringen und sich mit Softwarearchitekturen und Technologien zu beschäftigen. Am Ende des Tages löst die Technologie (e.g. WPF vs. HTML5 / Javscript) aber nicht das Problem des Kunden, sondern dient nur als Werkzeug. Auch sollte man den Fast-Feedback Cycle als eine Art experimentalen Prozesse sehen: Oft muss man sich beim Annähern an eine gute Lösung auch in eine “falsche Richtung” begeben, um gewisse Dinge ausloten zu können.

Am Beginn eines Softwareprojektes Technologien ausblenden und Hilfsmittel nutzen

Wer hat sich schon nicht mal dabei ertappt, bei einem neuen Softwareprojekt gleich etwas “technischer zu denken” - ohne dabei den eigentlichen Wunsch des Kunden zu kennen. Welche Sprache nutzen wir? Nutzen wir eine MOM? Usw.

“All of this technical thinking is fine. However, it has no bearing on what clients need because we haven’t collected their user requirements yet! User-centered design helps us remain focused on the user’s core needs. It ensures that we get solid information first and prevents us from trying to make the problem fit the technology” [2]

Zu beachten ist auch, dass nicht jedes Problem mit technischen Lösungen gelöst werden kann. Die Lösung kann oft auch “manueller” Natur sein – e.g. durch Anpassung der Prozesse oder Schulung der Mitarbeiter. Anstatt sich mit den technischen Aspekten in diesem früheren Stadium zu beschäftigen, sollte man sich besser die Frage stellen, wie das Problem / Bedürfnis, dass den Kunden gerade quält überhaupt zu Stande gekommen ist.

Bevor wir aber von Lösungen sprechen: In der Vorgehensweise oben haben wir “Observe” erwähnt – welche grundlegenden Hilfsmittel stehen uns da zur Verfügung?

• Wir können den Kunden besuchen und ihn interviewen.
• Wir können den Kunden beobachten (e.g. mit Kameras oder Screenaufzeichnung). Eye-Tracking kann hier auch hilfreich sein.
• Auch kann man den Kunden autonom / asynchron befragen, in dem man ihn an Umfragen teilnehmen lässt (e.g. mit Fragebögen).
• Stellen wir uns einen Onlineshop vor. Hier könnte man messen, wie oft ein Kunde eine Bestellung abbricht, wie oft er auf zurück klickt, wie oft ein Kunde eine Bestellung storniert, … usw. Alle diese Daten können Kundenwünsche und etwaige Verbesserung zu Tage bringen.
• Auch Beschwerden bzw. Probleme (in Form von Incidents) können Auskunft geben.
• Usability Testing kann Schwachstellen im Design aufzeigen.
• Fokus-Gruppen: Es werden Open-Ended Fragen gestellt. Es sollten homogene Interessensgruppen sein.
• uvm.

Um ein bisschen Struktur in die Flut an Informationen zu bekommen, empfehlen sich z.B. Hilfsmittel wie Affinity diagrams.

Im Frame Abschnitt gilt es das Problem zu formulieren. Warum sind Scenarios effektiv? [1] Als erstes zeigen sie durch Verwendung von Personas, für wenn die Lösung gebaut werden soll. Auch zeigen sie den Wunsch der Person und wie eine “delightful” Lösung für sie aussehen würde.

Fazit

Der Artikel zeigt einen kurzen Überblick über 3 Techniken, die zu besserer Software führen. Für mich war es auch wieder mal interessant, das Ganze zu wiederholen.

[1] De Bonte, Austina, and Drew Fletcher. Scenario-Focused Engineering: A toolbox for innovation and customer-centricity. Microsoft Press, 2014
[2] Lowdermilk, Travis. User-Centered Design: A Developer’s Guide to Building User-Friendly Applications. " O’Reilly Media, Inc.", 2013.
[3] Kupe Kupersmith, Paul Mulvey, Kate McGoey. Business Analysis For Dummies. John Wiley & Sons, Inc. USA, 2013
[4] Hruschka, Peter. Business Analysis und Requirements Engineering: Produkte und Prozesse nachhaltig verbessern. Carl Hanser Verlag GmbH Co KG, 2014.
[5] Wiegers, Karl, and Joy Beatty. Software requirements. Pearson Education, 2013.