Vom Menschen her denken

Von der Software- entwicklung lernen

In der Automatisierungstechnik und bei der Realisierung von Industrie-4.0-Projekten nimmt die Bedeutung von Softwarekomponenten zu und die Komplexität steigt. Gleichzeitig nehmen Planbarkeit und verfügbare Entwicklungszeit ab. Zur Lösung dieser Probleme sind in der Softwareentwicklung heute agile (lat. agilis: flink, beweglich) Entwicklungsprozesse erfolgreich im Einsatz. Der Blick auf agile Prozesse lohnt.

Autor: Autoren: Dr. Thies Pfeiffer, Dipl.-Inf., Mediablix IIT GmbH & Prof. Dr. Jörg Thomaschewski, Fachber


Bild 1: Beispiel einer Persona für die Planung einer Prozessüberwachung
Bild: Hochschule Emden/Leer

Die Basis aller agilen Entwicklungsprozesse bildet das 'agile Manifest', das im Jahr 2001 von erfahrenen Softwareentwicklern geschrieben wurde. Die agile Entwicklung reduziert den Aufwand für die Projektplanung und -dokumentation auf ein Minimum. Ein weiterer Kernpunkt vieler agiler Entwicklungsprozesse ist die iterative Entwicklung. Dabei wird nicht am Anfang versucht, das Gesamtsystem bis ins letzte Detail zu planen. Vielmehr wird nur das wirklich planbare und offensichtlich Notwendige in einem ersten Schritt umgesetzt. Der Fokus wird damit von Anfang an auf direkte Projektergebnisse gelegt und nicht auf umfangreiche Planung, wie dies zuvor oftmals üblich war. Dies bietet auch den Vorteil, dass durch die agile Projektsteuerung sehr flink auf neue Anforderungen reagiert werden kann. Anforderungen, die sich während oder nach der Umsetzung eines ersten Schrittes ergeben, können jeweils im nächsten Umsetzungsschritt berücksichtigt werden. Die agile Entwicklung erkennt somit die Tatsache an, dass Änderungen des Projektes schon während der Projektlaufzeit geschehen: Neue Systeme kommen hinzu; Anforderungen ändern sich aufgrund geänderter Kooperationen, Abläufe, Kundenanforderungen etc. Das 'große Ganze' ist zwar immer im Fokus der Projektentwicklung, aber für die ganz konkrete Planung wird immer nur das nächste Teilprojekt betrachtet, das dem Unternehmen einen direkten Mehrwert bringen muss.

Agil ja - aber menschenzentriert

Um den wachsenden Anforderungen im Bereich der Automatisierungstechnik und in den Industrie-4.0-Projekten gerecht zu werden, ist die Einführung von agilen Entwicklungsprozessen ein erster Schritt. Diese ermöglichen eine flexible Projektsteuerung und verbessern den Entwicklungszyklus. Dies alleine reicht jedoch nicht aus: In komplexen Projekten muss zusätzlich der Mensch in den Fokus gestellt werden. Daher stellen wir als zweiten Lösungsschritt einen menschenzentrierten Ansatz vor, ohne den moderne Hard- und Softwareentwicklung nicht erfolgreich sein wird. Durch die gesteigerte Komplexität der Systeme steigen auch die während der Bedienung zu berücksichtigenden Prozesse und Abhängigkeiten. Leicht kann dabei der Überblick verloren gehen aufgrund von unübersichtlich gestalteten Bedien-Schnittstellen oder unklaren Systemmeldungen (kognitive Überforderung). Hieraus resultierende Fehlbedienungen können zu Produktionsstörungen und Kosten führen. Diese lassen sich stark reduzieren, indem die beteiligten Menschen frühzeitig in die Entwicklungsprojekte einbezogen werden. Vom Menschen aus denken bedeutet, dass ein Wechsel der Perspektive stattfinden muss. Die menschenzentrierte Entwicklung (Human Centered Design) ist dabei nicht neu. Die Basis hierfür bildet die EN ISO13407 aus dem Jahr 1999. Die neuesten Richtlinien finden sich in der DIN EN ISO9241-210 aus dem Jahr 2011. Die Vorgehensweisen sind weltweit erprobt, insbesondere in komplexen Softwareprojekten. Vereinfacht betrachtet, kann man zwei Vorgehensweisen während der Planungsphase unterscheiden.

1. Die funktionszentrierte Sicht beschäftigt sich mit der Fragestellung: "Was muss das System können?" Der Ansatz dabei: 'Mehr Funktionen = besser' funktioniert, wenn eine Technik ganz neu ist und somit die notwendige die Basisfunktionalität erstellt werden muss. In klassischen Projekten wird dieser funktionszentrierte Ansatz oftmals auch dann noch verwendet, wenn die Basisfunktionalität längst erreicht wurde. Ein Problem hierbei: Es werden oftmals zu viele Funktionalitäten erstellt, die das System kompliziert machen und geringen Nutzen bringen. Hierdurch entstehen vermeidbare Kosten in der Entwicklung und im Betrieb.

2. Die menschenzentrierte Entwicklung klärt die Frage: "Von wem wird es benötigt und warum wird es benötigt?" Es ist ein Wechsel der Perspektive, aus der ein Projekt betrachtet wird.

Anzeige

Menschenzentrierte Entwicklung - welcher Mensch?

Im Rahmen der menschenzentrierten Entwicklung treten oft zwei Fragen auf. Erstens, welche Menschen sind bei der menschenzentrierten Entwicklung zu berücksichtigen? Und zweitens, wie kann man die Menschen berücksichtigen? Zur Beantwortung dieser Fragen benötigen wir Informationen über die Projektziele, um dann die beteiligten Menschen zu ermitteln. Ein Ziel könnte lauten: "Das Monitoring der Produktionsabläufe soll verbessert werden". Dann wären alle Menschen(gruppen) zu betrachten, die in diese Prozesse eingebunden sind. Wir schreiben bewusst Menschen und nicht Mitarbeiter, denn es könnten auch Personen außerhalb der Firma sein, die hierzu Daten liefern oder Daten abrufen. Wir schreiben bewusst Menschen und nicht Benutzer, denn es könnten Personen sein, die das System nicht direkt benutzen. Die menschenzentrierte Entwicklung versucht, am Anfang einen möglichst großen Blickwinkel einzunehmen, und damit alle wesentlichen Personen zu berücksichtigen. Auch dies ist eine Erkenntnis aus der Softwareentwicklung, die sich vom User Centered Design (Betrachtung der Benutzer) zum Human Centered Design (Betrachtung der Menschen) entwickelt hat.

Den Menschen sichtbar machen

Die menschenzentrierte Entwicklung fokussiert sich zuerst auf die beteiligten Personen und nimmt bewusst die funktionale Beschreibung erst zu einem späteren Zeitpunkt vor. Ein einfacher Ansatz mit großer Wirkung ist die Darstellung der am Prozess beteiligten Menschen in Form von Personas (Bild 1). Eine Persona wird dabei auf Basis der Motive und Ziele realer Benutzer entwickelt. Dabei sind Erfahrungen, Verhaltensweisen, Schulbildungen, Sprachen etc. so zu berücksichtigen, dass dem Projektteam die Zielgruppe stets vor Augen ist. In einem kleinen Projekt reichen oftmals vier bis sechs Personas zur Beschreibung einer Zielgruppe. Mithilfe der Personas erhalten alle Projektbeteiligten eine einheitliche Sicht auf die Zielgruppe und damit ein besseres Verständnis von den Menschen, die das System später nutzen. Die Erstellung der Persona ist leicht durchzuführen, indem man sich von den Zielgruppen ein möglichst realistisches Bild macht, beispielsweise durch Interviews und Beobachtungen. Oftmals lassen sich realistische Personas in wenigen Tagen erstellen.

Empfehlungen der Redaktion

Der Nutzungskontext

Nachdem die Zielgruppe ermittelt und Modelle in Form von Personas erstellt wurden, ist der sogenannte Nutzungskontext zu ermitteln, der im Bereich der Automatisierungstechnik eine ganz entscheidende Rolle spielt. Unter dem Nutzungskontext wird die reale Situation verstanden, in der die Anwender eines Systems mit diesem interagieren. In der Softwareentwicklung reichen oftmals kurze Beschreibungen (Szenarien) oder kleine Skizzen (Storyboards) aus, um den Nutzungskontext darzustellen. Im Bereich der Automatisierungstechnik ist dieses Verfahren jedoch nicht ausreichend, da die realen Situationen viele Spezifika aufweisen können. Es werden also Lösungsansätze benötigt, die über die Ansätze der Softwareentwicklung hinausgehen und durch die der Nutzungskontext detailliert aufgenommen werden kann, damit sich z.B. die oftmals weit entfernt sitzenden Systementwickler die Situation in der Produktionsumgebung vorstellen können. Hierzu schlagen wir videobasierte Verfahren und insbesondere Eye-Tracking vor (SPS-MAGAZIN 5/2014, Seite 88).

Erst der Mensch, dann die Funktionalitäten

Wenn geklärt ist, 'von wem' (Personas), 'in welcher Situation' (Nutzungskontext) und 'warum etwas benötigt wird' (Ziele), werden die hierzu gehörenden Basisfunktionalitäten ermittelt. Es hat sich in der agilen Softwareentwicklung bewährt, Funktionalitäten in Form von User Stories aufzuschreiben. Das sind kurze Beschreibungen, die den Ablauf einer Nutzung aus der Sicht und am besten in der Sprache der Nutzer beschreiben. Gerade in der Softwareentwicklung muss im gesamten Projektprozess sichergestellt werden, dass keine Funktionalität hinzukommt, die nicht benötigt wird. Unnötige Funktionalitäten kosten nicht nur Geld und Zeit, sondern können auch die Übersichtlichkeit und die Bedienbarkeit verschlechtern, da sie die kognitive Belastung erhöhen. Daher wird in den sogenannten Persona-driven User Stories zu jeder Funktionalität nochmals der genaue Grund angegeben: "Als möchte ich , um ". Um ein Beispiel zu geben, wird hier die Persona aus Bild 1 aufgegriffen und eine mögliche Persona-driven User Story könnte lauten: "Als möchte , um ". In Bild 2 ist diese beispielhafte Persona-driven User Story abgebildet. Es ist ein wesentlicher Vorteil des hier geschilderten Ansatzes, dass man automatisch auf der Ebene der Nutzer argumentiert und dann in den Persona-driven User Stories auch in ihrer Sprache schreibt. Das bedeutet, dass man auf dieser Ebene die Nutzer auch direkt mit einbeziehen und mit ihnen darüber kommunizieren kann, ohne dass technische Sichtweisen oder unbekannter Fachjargon dem entgegenstehen. Das erzwingt eine ganz andere Transparenz in der Kommunikation im Projekt auf allen Ebenen bis runter zum Bediener. Anhand der User Stories sowie weiterer Technical Stories (diese berücksichtigen die technischen Anforderungen) lassen sich auch die Testkriterien ermitteln, die für eine spätere Qualitätssicherung oder Projektabnahme notwendig sind. An dieser Stelle geht es somit wieder um die Funktionalität, die im Projekt realisiert werden soll. Neu aber ist, dass die Funktionalitäten immer einer Zielgruppe zugeordnet werden. Es gehört einiges an Erfahrung dazu, gute User Stories zu schreiben bzw. schlechte User Stories zu erkennen. In vielen Projekten haben wir erlebt, dass Projektteams diesen Aufwand am Anfang vermeiden möchten. Andererseits rechnet sich der Aufwand bereits, wenn man in 100 User Stories nur zwei bis drei überflüssige Stories bzw. Funktionalitäten entdeckt.

Anzeige

Fazit

Wir haben in diesem Beitrag zwei Perspektiven aufgezeigt. Durch den menschenzentrierten Ansatz kann sowohl in der Produktentwicklung als auch in Projekten der Fokus auf die beteiligten Menschen gelegt werden und zu erfolgreicheren Produkten bzw. Projekten führen. Hierbei ist es wichtig, dass anstelle der Funktionalitäten zuerst die Ziele und Bedürfnisse der beteiligten Menschen im Vordergrund stehen und im gesamten Projektverlauf sichtbar gemacht werden. In der Softwareentwicklung wird dieser menschenzentrierte Ansatz zusammen mit agilen Entwicklungsmethoden genutzt. Agile Methoden gehen davon aus, dass auf äußere Anforderungsänderungen schnell reagiert werden muss, beispielsweise auch innerhalb eines laufenden Projekts. Beide Methoden: 'menschenzentrierte Entwicklung' und 'agile Entwicklungsmodelle' lassen sich zwar unabhängig voneinander einsetzen, entfalten aber im Zusammenspiel ein hohes Potenzial um 'das Richtige und Wichtige' (menschenzentrierte Entwicklung) auch 'gut und in kleinen Schritten' (agile Entwicklungsmethoden) umzusetzen. In vielen Bereichen der Softwareentwicklung hat sich dieses Vorgehen durchgesetzt. Wissenschaftliche Studien und Berichte aus der Praxis belegen die hier beschriebenen Effekte, die beide Autoren auch aus der Unternehmenspraxis kennen.

Anzeige