Dies ist unser Playbook. Hier beschreiben wir, wie wir digitale Produkte entwickeln und vor allem wie wir im Bermuda Digital Studio arbeiten.

Hallo

Wir sind das Bermuda Digital Studio. Wir sind ein junges Team aus EntwicklerInnen, DesignerInnen und Produkt ManagerInnen, das digitales Produktmanagement zusammen mit den E.ON Regionalgesellschaften neu denken und umsetzen möchte.

Dies ist unser Playbook. Hier beschreiben wir, wie wir digitale Produkte entwickeln und vor allem wie wir im Bermuda Digital Studio arbeiten. Dabei gehen wir auch darauf ein, von wem und wo wir uns extern inspirieren lassen. Bei der Ausgestaltung des Playbook haben wir uns zum Beispiel vor allem von thoughtbot inspirieren lassen.

Das Playbook ist ein lebendes Dokument, das jedes Mitglied des Bermuda Digital Studios bearbeiten und weiterentwicklen kann.

Außerdem ist das Playbook frei zugänglich, sodass jeder, der Interesse hat, darin lesen, und hoffentlich daraus lernen kann.

Warum gibt es uns?

Die Digitalisierung verändert jetzt alle Wirtschaftsbereiche schneller als je zuvor. Sie hat das Potenzial selbst etablierte Unternehmen komplett zu verdrängen. Gängige Maßnahmen wie Innovationsteams und Dependancen in Start-Up-Hubs wie Berlin oder dem Silicon Valley, reichen nicht, um tiefergreifende Herausforderungen zu adressieren.

Gründe für das Scheitern sind sowohl in dem mangelnden Fachwissen des Personals als auch in einer fehlenden authentischen "digitalen Kultur" zu suchen. Zudem fehlen bei den starren Konzernstrukturen häufig die Freiheitsgrade zur Gestaltung von digitalen Produkten.

Auch bei E.ON wächst die Erkenntnis, dass im Zuge der Digitalisierung Marktsegmente und Kunden verloren gehen. Der Energieversorger der Zukunft ist digital im Geschäft - oder gar nicht. Neue mögliche Geschäftsmodelle, Prozessoptimierungen und Kundenbindung durch digitale Kanäle bieten dabei viel Potential hinsichtlich des technologischen Wandels.

Um zu helfen, dieses Potential effektiv nutzen zu können, wird das Bermuda Digital Studio etabliert. Gemeinsam mit den E.ON Vertriebsgesellschaften konzipiert, entwickelt und testet das Bermuda Digital Studio digitale Produkte und Services.

Dabei werden die Endkunden und Zielgruppen von Anfang an in einem agilen und iterativen Prozess mit einbezogen. Durch ein festes Team mit allen Stakeholdern der digitalen Produktentwicklung - DesignerInnen, DeveloperInnen und Marketeers - wird ein ganzheitliche Entwicklung gewährleistet, ohne Wissen und Erkenntnisse an Externe zu verlieren. Das Bermuda Digital Studio orientiert sich dabei an namenhaften Entwicklungsagenturen und -teams mit dem Ziel diese unterschiedlichen Kompetenzen aufzubauen.

Der ständige Umgang mit state-of-the-art Technologie und Design soll durch die Interaktion mit den Konzerneinheiten schrittweise im Konzern umgesetzt werden. Das Bermuda Digital Studio dient dabei als Ausgangspunkt, an dem diese neue Art des digitalen Produktmanagements eingeführt wird. Unser Ziel ist es, dass diese Kompetenzen mittel- bis langfristig im gesamten Konzern verfügbar sind und die dazugehörige Kultur überall gelebt wird.

Unsere Vision

Das Bermuda Digital Studio ist eine interne Agentur, die die E.ON Vertriebsgesellschaften bei der Umsetzung von neuen Ideen und Projekten unterstützt. Dabei arbeitet das Studio von Anfang an gemeinsam mit dem Kunden, dem Vertrieb und der jeweiligen IT zusammen, um überragende digitale Anwendungen iterativ zu designen, zu bauen und zu validieren. Unser Ziel ist es, Synergien für die deutschen E.ON Vertriebsgesellschaften zu heben und gleichzeitig Wissen und die Kompetenzen für digitale Produktenwicklung zu steigern.

Unsere Werte

Im Bermuda Digital Studio legen wir viel Wert auf Team-Kultur. Alle Teammitglieder treffen sich auf Augenhöhe und entscheiden gemeinsam, welcher Kurs gesetzt wird. Somit ist das gesamte Team für den Erfolg eines Projekts verantwortlich. Authentizität und Spaß an dem, was wir tun, bilden die Grundlage, um Transparenz einfach leben zu können. Denn unsere Produkte, Ergebnisse und Prozesse werden quell-offen dem Konzern zur Verfügung gestellt.

In unserer Herangehenweise sind wir iterativ, agil und halten uns grundsätzlich an das Agile Manifesto. Wesentlich für unser Tun ist es, alles zu hinterfragen. Wir versuchen in unseren Projektaufträgen alle Annahmen durch echtes Benutzerfeedback zu überprüfen. Wir entwickeln unsere Produkte mit dem Nutzer im Fokus. Dabei orientieren wir uns in unseren Methoden an Design Thinking, Human Centered Design und Lean Startup.

Unsere Kompetenzen

Unsere Vision und unsere Ziele erreichen wir nur, wenn es uns gelingt, die dafür notwendigen Kompetenzen in Form von guten Produkt ManagerInnen, DesignerInnen, EntwicklerInnen und User Researchern zu gewinnen und diese stetig weiter zu entwickeln.

Dabei setzen wir uns selbst hohe Maßstäbe. Wir wollen zeitgemäße und kreative Lösungen für das jeweilige Kundenproblem entwickeln. Das bedeutet Produkte und Services, die nicht nur gut aussehen und intuitiv zu benutzen sind, sondern auch die jeweilige Customer Journey komplementieren oder erweitern. Dem Design Thinking folgend ist es uns wichtig, die Nutzersicht bei der Produktentwicklung früh und stetig im Fokus zu haben und bei der Entwicklung unterschiedliche Kompetenzen in einem Team zu vereinen.

Um dies sicherzustellen, hat jedes Teammitglied im Bermuda Digital Studio eine ausgeprägte Kompetenz in einem der genannten Bereiche Produkt Management, Design oder Entwicklung, aber gleichzeitig Grundkenntnisse in allen anderen Bereichen (T-Shaped). Dieser holistische Ansatz ist unserer Meinung nach Voraussetzung für erfolgreiche Produkte.

Dazu arbeiten wir mit verschiedenen Partnern zusammen - insbesondere mit der Produktentwicklungsagentur 9elements, die einen weitreichenden Erfahrungsschatz bzgl. der Kombination von funktionalem Design mit neuester Software-Technologie und insbesondere Stärken in einer ganzheitlichen Produktsicht mitbringt. Seit über zehn Jahren arbeitet 9elements mit Startups wie Employour und Moviepilot als auch mit Global Playern wie der OECD oder IBM zusammen. 9elements unterstützt nun E.ON sowohl strategisch bei der Konzeption des Bermuda Digital Studios als auch fachlich in Form von Designern, Software-Entwicklern und Scrum-Mastern, die diese Kultur der fachübergreifenden Verantwortung bereits erfolgreich leben und in der laufenden Zusammenarbeit an das Bermuda Digital Studio Team übertragen.

Ziel des Bermuda Digital Studios ist es nicht nur, im Studio selbst Wissen und Kompetenzen rund um digitale Produktentwicklung aufzubauen, sondern diese und die gelebte Kultur für alle zugänglich und mit allen Interessierten teilbar zu machen und somit in die tiefen Strukturen von E.ON reinzutragen.

Das Team

Das Team

Ein typisches Team besteht aus:

  • Produkt ManagerIn: bringt in erster Linie die Vision des Produkts und die Perspektive des Kunden in das Team ein

  • DesignerIn: kümmert sich hauptsächlich um User Experience sowie die visuelle Ausgestaltung des Produkts

  • EntwicklerIn: verantworlich für die technische Umsetzung des Produkts

  • User Researcher: unterstützt bei der Vorbereitung und Durchführung von User Testing

Einer der Teammitglieder übernimmt zusätzlich die Rolle des Bermuda Prozesscoach. In dieser Funktion koordiniert und moderiert er oder sie den Produktentwicklungsprozess im Bermuda Digital Studio.

Jede der drei Kern-Rollen wird von mindestens einem Mitglied des Studios gestellt - ein Produktmanager und je nach Projekt ein bis zwei Developer kommen von der auftraggebenden Tochtergesellschaft dazu.

Diese verschiedene Rollen werden im Weiteren näher beschrieben.

Produkt ManagerIn

Der Produkt Manager bringt in erster Linie die Vision des Projekts und das Wissen über den Kontext des zu entwickelnden Produktes in das Team ein. Er hat den Überblick über alle nicht-technischen Fragestellungen, insbesondere über das zu lösende Kundenproblem. Er hat dazu die User Journey im Blick, kennt die Marketingaspekte und weiß über den Kontext Bescheid, in dem der User auf das Produkt trifft. Seine Aufgabe ist es auch, dem restlichen Team zu vermitteln, was die äußeren Rahmenbedingungen des Projektes sind. Er klärt u.A. die rechtlichen Fragen und wie das Produkt innerhalb von E.ON bzw. der Regionalgesellschaft andockt. Er ähnelt dem Scrum-typischen Product Owner, ist allerdings Teil des Studio-Teams und somit mit den anderen Mitglieder gleichberechtigt an der Sprintplanung beteiligt und arbeitet aktiv an dem Erreichen des Projektziels mit.

DesignerIn

Der Designer bereichert das Team vor allem mit seinem Verständnis von Nutzerprozessen, welches in der Konzeption und Gestaltung von funktionalen User Interfaces Anwendung findet. Seine Aufgabe ist es, die Interaktion des Benutzers mit dem Produkt zu verstehen und Lösungen zu entwickeln, die ästhetisch ansprechend sind und intuitiv benutzt werden können.

DeveloperIn

Der Developer ist für die technische Umsetzung zuständig. Er schreibt den Code der Prototypen sowie des fertigen Produktes und ist maßgeblicher Experte in Diskussionen zur Technologiewahl und technischen Machbarkeit. Er schafft durch Dokumentation und einen guten Programmierstil die Voraussetzung für die Erweiterung der E.ON Open Source Basis.

Bermuda Prozesscoach

Der Prozesscoach hilft dem Team dabei, seine selbstgesteckten Ziele zu erreichen. Dazu gibt er Impulse und macht proaktiv Vorschläge, welche Design Thinking, Human-Centered Design und Lean Startup Methoden in bestimmten Projektphasen eingesetzt werden können. Nach Abschluss eines Projekts organisiert der Prozesscoach ein Review, in dem die Arbeitsweise gemeinsam im Team reflektiert und diskutiert wird.

User Researcher

Der User Researcher unterstützt das Team dabei, regelmäßig den aktuellen Produktstand bei der Zielkundengruppe zu testen. Er ist dabei derjenige, der den Ablauf von User Tests koordiniert, User auswählt und einlädt und sich dabei mit dem Team im ganzen, aber insbesondere mit dem Designer und dem Produkt Manager abstimmt. Abgesehen von konkreten Tests eines Prototypen oder Produkts kann der User Researcher gelegentlich mit Grundlagenforschung beauftragt werden. Er ist kompetent im Planen, Strukturieren und Durchführen von Interviews und stellte diese Kompetenzen dem Team als Service zur Verfügung.

Partnernetzwerk

Das Bermuda Digital Studio arbeitet regelmäßig mit Agenturen oder Freelancern zusammen, um

  • auf Spezialexpertise zurückzugreifen, die nicht im Team vorhanden ist

  • die Kompetenzen des Teams stetig zu erweitern

  • mit anderen coolen Produktentwicklern gemeinsam zu arbeiten.

Produktentwicklungsprozess

Produktentwicklungsprozess

Das Bermuda Digital Studio begleitet den gesamten Prozess von der Ideenfindung bis hin zum fertigen Produkt. Um diesen Prozess möglichst effizient zu gestalten, arbeitet das BDS in kurzen Zyklen mit dem Ziel des Produkt in seiner einfachsten Form möglichst schnell am Kunden zu evaluieren. Dabei setzt das Studio auf die schnelle Entwicklung eines Minimum Viable Produkt (MVP (NOTE: Ein MVP ist die Version eines Produkts welches eines Maximum an validierbarem Lernen über den Kunden erlaubt unter dem Einsatz eines möglichst geringen Entwicklungsaufwands.)) und der anschließenden iterativen Weiterentwicklung des Produkts in Richtung eines Minimum Loveable Produkt (MLP (NOTE: Ein MLP ist die Version eines Produkts, das die maximalen Grad an Liebe des Kunden bekommt unter dem Einsatz eines möglichst geringen Entwicklungsaufwands.)).

Grundsätzlich erarbeitet das BDS das Produkt in einem mehrphasigem Prozess:

  1. Vorbereitung

  2. Produkt Design Sprint

  3. Konzept und Prototyping

  4. Umsetzung und langfristige Betreuung

Vorbereitung

Bevor ein Projekt im BDS mit dem Design Sprint losgeht, sollte das Kunden- und Businessproblem tiefgründig verstanden werden.

Dazu bietet es sich an, dass der Product Owner aus der REG bereits im Vorfeld Interviews mit Kunden führt, um das Kundenproblem und den Kunden besser zu verstehen. Hilfestellungen für solche Tiefeninterviews gibt es im Buch The Mom Test von Rob Fitzpatrick oder auch in dem Buch Talking to Humans von Cliff Constable. Alternativ kann es auch sinnvoll sein, den Kunden / Nutzer in seinem normalen Umfeld zu beobachten, um zu lernen wie er mit dem Problem aktuell umgeht. All diese Informationen helfen später bei der Erarbeitung einer auf den Nutzer ausgerichteten Lösung. Bei den User Interviews und User Shadowing hilft das BDS gerne bereits vor dem gemeinsamen Design Sprint.

Der Ausgangspunkt eines Projekts ist der Project Canvas, auf dem das Kundenproblem, das Business-Ziel, die Kundengruppe sowie die angestrebte Lösung mit der dahinterliegenden Technologie skizziert wird. Wichtig für die Produktentwicklung im BDS ist das Verständnis, dass alle Elemente Arbeitshypothesen sind, die es erst noch mit echten Nutzern oder Kunden zu validieren gilt.

Für die Product Owner aus der Regionalgesellschaft gilt es vor allem folgende Fragen beantworten zu können:

  • Welches Problem versuchen Sie zu lösen?

  • Wie sind Sie auf das Problem gestoßen? (Durch Kundenfeedback? Mitarbeiterfeedback?)

  • Was wollen Sie mit der Lösung erreichen?

  • Wer ist die Kunden- / Zielgruppe? Wie können Sie diese Gruppe beschreiben?

  • In welchem Umfeld / Kontext liegt das Problem bzw. die angestrebte Lösung?

    • Welche Produkte muss man kennen, um das Problem zu verstehen? Stellen Sie bitte diese Produkte vor (Produktskizze, Kundengruppen, Anzahl Kunden, Erfahrungen etc.)
    • Liegt das Problem / die Lösung auf einer bestehenden Website / App? Bringen Sie bitte alle verfügbaren Informationen zum Webauftritt mit (Klickzahlen, Absprungraten, Testergebnisse etc.)

Falls einige Antworten auf diese Fragen offen sind, können Experten zum ersten Tag des Design Sprints eingeladen werden. Dies könnten zum Beispiel ein Produkt Manager sein, ein Kollege aus dem Marketing oder aus dem Kundenservice.

Der letzte Punkt der Vorbereitung auf das Projekt im Bermuda Digital Studio ist es, die Weichen für Kundenfeedback zu stellen. Für B2C-Projekte übernimmt das Bermuda Digital Studio in der Regel die Organisation von Kundenfeedback in der Design- und Konzeptphase. Für B2B-Projekte erwartet das Bermuda Digital Studio im Vorhinein vereinbarte Termine mit potenziellen Nutzern.

Produkt Design Sprint

Los geht das Projekt mit einem Design Sprint, der sich stark an dem Design Sprint von Google orientiert.

An Tag 1 liegt der Fokus darauf, das Kundenproblem zu verstehen. Alle verfügbaren Informationen und bereits erhobenden Kundenerkenntnisse werden im Team geteilt und darauf aufbauend eine *Persona für die Kundengruppe *entwickelt. Diese Persona dient dazu, das Produkt gezielt für diese Kundengruppe zu entwickeln.

An Tag 2 werden Ideen für Lösungen generiert. Dazu kommen vor allem leere Blätter und Stifte auf den Tisch mit denen jedes Teammitglied Anwendungen oder Aspekte davon skizziert (Crazy 8, Storyboard). Zwischendurch werden die Ideen durch Punktekleben und Diskussionen immer wieder fokussiert.

An Tag 3 muss das Team als erstes aus den erarbeiteten Ideen des Vortags entscheiden, welche Lösung ausgestaltet werden soll und dafür ein Konzept zu entwickeln.

An Tag 4 wird aufbauend auf diesem Konzept ein funktionierender Prototyp entwickelt. Dieser kann eine Landing Page, ein Klick-Dummy, eine gebastelte Broschüre oder ein Lego-Konstrukt sein. Hauptsache das Team kann damit am Nachmittag mit echten Nutzern oder Kunden ein User Testing durchführen und Feedback sammeln.

An Tag 5 wird das Kundenfeedback ausgewertet und darauf basierend eine *grobe Planung für das weitere Projekt *gemacht.

Um einen besseren Eindruck vom dem Ablauf eines Design Sprints zu haben kann man sich an folgender beispielhaften Agenda orientieren.

Understand

Der Tag beginnt mit der

  • Vorstellungsrunde, alle Teammitglieder stellen sich einander vor und die etwaigen Teamrollen werden mit dem Team abgestimmt. Darauf folgt ein

  • Lightning Talk der REG um die Idee allen Beteiligten näher zu bringen und es werden erste aufkommende Fragen geklärt und festgehalten. Im Anschluß werden dann die

  • Erwartungen der REG an das BDS und umgekehrt geklärt. Dabei wird besprochen welches Wochenziel verfolgt wird, wie das BDS aufgestellt ist und das Konzepts des Design Sprints näher erläutert. Nach dieser kennenlernen Phase wird direkt mit der

  • Frame your design Challenge begonnen. Dabei werden unter anderem wichtige Fragen angegangen:

    • Welches Problem versuchen wir zu lösen?
    • Was wollen wir damit erreichen?
    • Welche möglichen Lösungsansätze für das Problem gibt es?
    • Was ist der Kontext? Welche Einschränkungen gibt es?
  • Wichtig ist hierbei auch der Input der REG um ein besseres Produktverständnis zu bekommen.

    • Was ist der Kontext?
    • Was ist der Status Quo?
    • Wer sind die Stakeholder?
    • Wurde alles an Material gesichtet?
    • Gibt es Studien? Gibt es Informationsmaterial?
    • Wer sind die Kunden aus Sicht der REG?
    • Welche Rahmenbedingungen müssen eingehalten werden?
  • Wurden all diese Fragen hinreichend beantwortet wird als nächstes damit begonnen die

  • Persona des Kunden zu erarbeiten und festzuhalten. Dabei ist es wichtig die Zielgruppe möglichst genau auszuloten. Am Ende des Tages wird sich dem

  • Project Canvas zugewandt und nach bestem Wissen alle Felder gefüllt. Dabei hilft es sich folden Fragen zu stellen

    • Was ist das Business-Ziel des Produkts?
    • Was ist das Business-Umfeld/Einschränkungen?
    • Für wen genau wird das Produkt gebaut? Wer sind ggf. die Early Adopters?
    • Wie bringen wir das Produkt an den Kunden? WelcheMarketing Kanäle stehen zur Optionen bzw. sollen genutzt werden?
    • Was erreichen wir mit dem Produkt für den Kunde? Welchen Benefit hat der Kunde?
    • Welche Features umfasst das MVP bzw. der erste Prototyp am Ende des Design Sprints?

Am Ende der Phase wird zum

  • Abschluss der Canvas noch einmal betrachtet und von allen beteiligten abgenommen.

Diverge

Zu Beginn des zweiten Tages widmet sich das Team noch einmal dem

  • Project Canvas und stellt sicher das dieser komplett und verständlich für alle Teilnehmer ist. Falls nicht wird gegebenenfalls nachgebessert. Ist der Canvas komplett ist es ratsam einen

  • 1st Tweet, eine kurze und prägnante Beschreibung des Produkts, zu verfassen. Dazu nimmt sich jeder Teilnehmer10 Minuten Zeit um eine oder mehrere Ideen auszuarbeiten, die im Anschluss dem Team präsentiert und gemeinsam diskutiert werden.

    • Hat sich das Team auf eine gemeinsame Formulierung geeinigt wird mit der eigentlich Ideen- bzw. Lösungsfindung begonnen werden.
    • Um den Fokus des Teams hoch zu halten werden werden Konzepte wie 8 Ideas in 5 minutes bis hin zu 1 Idea in 10 min benutzt. Alle Teilnehmer skizzieren oder beschreiben mögliche Lösungsansätze für ein Teilproblem. Konnte das Team sich einigen werden die Ideen verfeinert bis sich eine überschaubare Anzahl an Ideen herauskristallisiert hat.
    • Der obige Prozess wird im Laufe der Phase für verschiedene Teilprobleme wiederholt bis sich für alle Probleme hinreichende Lösungsansätze ergeben haben.
    • Am Ende der Phase ist es auch hier sinnvoll die Lösungsansätze och einmal mit dem Project Canvas abzugleichen.

Decide + Prototype

Zu Beginn der Decide Phase beginnt das Team einen *Lösungsansatz für jedes Teilproblem auszuwählen. Dabei ist es während des Design Sprints wichtig noch nicht zu detailverliebt zu sein und eher *Quick and Dirty zu arbeiten. Es ist zu bedenken, dass der anstehende Prototyp dazu dienen soll ein initiales Kundenfeedback durch Usertests zu bekommen und die Grundidee zu validieren, nicht ein komplett fertiges Produkt zu demonstrieren. Als nächstes wird das

  • Storyboard erarbeitet. Das heißt die einzelnen Teillösungen werden zu eine Gesamtlösung zusammengesetzt und auch etwaige Abläufe werden festgelegt. Ist das gesamte Storyboard komplett, dann widmet sich das Team anschließend der

  • Vorbereitung der Validierung. Dabei wird diskutiert, wie man möglichst viele entscheidungsrelevante Informationen bekommen kann. Oft wird im Zuge dessen auch ein

  • Inverviewleitfaden für die Kundentests entwickelt. Sind alle Entscheidung getroffen kann ein

  • Prototyp entwickelt werden. Hier ist liegt der Fokus klar auf Benutzbarkeit und nicht auf der Entwicklung einer besonders schönen Lösung. Verschiedenste Lösungen sind denkbar, auch ein Prototyp mit Stift und Zettel. In demDesign Sprint sollte man von einer weiteren Ausgestaltung vorerst absehen.

Prototype and Validate

Der letzte Tag beginnt oft mit der

  • Kundenbefragung. Das Team führt Interviews mit diversen Kunden durch. Hier ist es wichtig, dass es reale Kunden sind. Das Interview ist orientiert am zuvor erarbeiteten Interviewleitfaden und sollte sich darauf fokussieren zuvor aufgestellten Thesen zur Persona und deren Bedürfnisse zu evaluieren. Im Anschluss setzt sich das Team noch einmal zusammen um die gewonnen

  • Erkenntnisse zu diskutieren und zu lernen was an der vorgestellten Idee/Umsetzung nicht funktioniert. Am Ende des Design Sprints wird festgelegt wie das

  • weitere Vorgehen ist und inwiefern und welche Richtung die Idee ausgearbeitet wird. Mögliche Ausgänge sind auchein Abbruch des Projekts, wenn sich die Grundthesen nichtbestätigen. Im generellen Fall allerdings sollte überlegt werden, welche Thesen falsch waren und wie man die Bedürfnisse der Kunden besser verstehen und erfüllen kann.

Konzeption

Nach dem Design Sprint gehen wir in eine Prototyping Phase. Ausgehend davon, dass bereits ein erster Prototyp auf Papier im Design Sprint entwickelt wurde, wird dieser weiter ausgearbeitet. Dabei ist unser Ziel möglichst schnell ein MVP zu erzeugen, welches durch Kundentests evaluiert werden kann, um möglichst erfolgversprechende Schritte in der Produktentwicklung einzuschlagen.

Im Allgemeinen gliedert sich die Konzeptionsphase in mehrere Schritte, die zum Teil parallel bearbeitet werden können.

Requirements

Ausgehend von dem ersten Ideen und Ergebnissen aus der Design Sprint Phase werden die Anforderungen des Produkts noch einmal resümiert und hinterfragt. Somit kann im Anschluss die nächste Iteration der Anforderungen formuliert werden.

Abhängig von den Anforderung ist der nächste Schritt die Definitionen der minimalen *Features, die es erlauben ein *MVP zu erzeugen.

Eine Möglichkeit ist die erforderlichen Eigenschaften in User Stories (US) festzuhalten. Dabei beschreibt man die Anforderung aus Kunden/User Sicht und fokussiert dabei darauf, wie ein User eine definierte Aufgabe erledigt. Im allgemeinen werden User Stories** **folgendermaßen beschrieben:

"Als Kunde, möchte ich ein Ziel aus einem bestimmten Grund erreichen"

User Journey

Sind die grundsätzlichen Anforderungen und Funktionen des MVP festgelegt, geht es darum die User Journey neu zu durchdenken. Dabei wird erarbeitet, wie der Nutzer zu der Applikation gelangt, in welchem Kontext er die Applikation nutzt und wie die Reise danach für den Nutzer weitergeht.

Auswahl der Plattform / des Mediums

In der ersten Phase der Konzeption müssen wir uns für eine Plattform entscheiden.

Die Wahl der Plattform ist hier sehr problemabhängig und sollte so gewählt werden, dass das Kundenproblem bestmöglich gelöst wird. Meist werden dies aber Web- oder Mobile Applikationen sein, aber auch andere Ansätze sind denkbar.

User Flows

Neben der User Journey werden auch die User Flows hinterfragt und adaptiert. Im Gegensatz zur User Journey, welche sich eher mit allem rund um das Produkt beschäftigt, geht es bei den User Flows eher um Aktionen innerhalb der Applikation. Typische User Flows beschäftigen sich mit der Bewegung des Nutzers bei einer speziellen Aufgabe, beispielsweise der Registrierung eines neuen Users oder dem Kauf eines Artikels über die Applikation.

Hierbei wird sehr viel Wert darauf gelegt, dass dem Kunden eine möglichst einfache und effiziente Nutzung einer bestimmten Funktion ermöglicht wird. Dabei sollte darauf geachtet werden, dass die einzelnen Schritte in einem User Flow kurz gehalten werden und sich auf das Wesentliche konzentrieren.

Designprozess

Wireframing

Sind alle User Journeys und User Flows definiert, geht es in der nächsten Phase darum, vor allem den grundsätzlichen Inhalt und dessen strukturellen Aufbau der einzelnen Schritte/Pages/Screens in sogenannten Wireframes zu definieren.

Es geht in dieser Phase noch nicht um spezifische Layouts oder Gestaltungselemente wie z.B. Farben, Schriften, Bilder. Die Funktionalität der erstellten Wireframes wird im Anschluss anhand eines ersten Prototypen getestet und validiert.

User Interface und Interaction Design

Unter Berücksichtigung etwaig vorgegebener Gestaltungsrichtlinien und nach Vorbild der zuvor definierten Wireframes wird ein visuelles Erscheinungsbild ausgearbeitet. Nach Vorbild des Atomic Design Prinzips entstehen daraus finale Layouts der Benutzeroberflächen. Darüber hinaus definiert der Designer das Interaktionsverhalten sowie gegebenfalls Animation und Übergänge der einzelnen Gestaltungselemente.

Produktentwicklung

Funktionalität

Auf Basis der in den Konzept- und Designphasen erarbeiteten und validierten Prototypen wird zunächst die technische Basis geschaffen. Im ersten Schritt beginnt ein Entwickler die grundsätzliche Anwendungsstruktur (Frontend, Backend, Schnittstellen etc.) aufzusetzten und konzentriert sich auf die Umsetzung der Kernfunktionen.

Finales Minimum Viable Product

Am Ende der parallel laufenden Prototyping Phasen aus Design sowie der funktionalen Entwicklung werden alle Elemente zu einem finalen Minimum Viable Product zusammengeführt und Testnutzern zugänglich gemacht.

Testingphase

Usability Tests

Um aus dem Prototypen zu lernen, sollte dieser so früh wie möglich mit echten Menschen und potenziellen Nutzern getestet werden. Hier geht es vor allem darum, ob der Nutzer versteht, wie er sich durch die Applikation navigieren soll? Kann der Nutzer mit dem Prototypen sein Problem lösen? Bei den Usability Tests sollte mindestens der Produkt Manager und User Researcher, idealerweise auch der Designer, dabei sein, um den Nutzer zu beobachten, während er den Prototypen nutzt. Dabei werden kritische Nutzungssituationen notiert, in denen der Nutzer nicht mit dem Prototypen zurecht kam. Anschließend muss im Team ausgewertet werden, wie der Prototyp verbessert werden kann, sei es vom Aufbau (User Flows) und/oder visueller Gestaltung.

Online Marketing

Qualitative Interviews und Usability Tests helfen in der Anfangsphase, um ein besseres Produkt zu bauen, das tatsächlich das Problem des Nutzers löst und das er zu nutzen versteht.

Um herauszufinden, wie das Produkt im Markt und nicht von einzelnen Nutzern in einer Test-Situation genutzt wird, muss die Applikation live geschaltet werden und mit größeren Mengen an Nutzern ausprobiert werden.

Je nach Produkt und Zielgruppe kann das BDS die Regionalgesellschaft unterstützen die ersten Nutzer zu akquirieren. Dies kann über verschiedene Kanäle geschehen, wie z.B.:

  • Bezahlte Marketing-Kampagnen wie z.B. Google AdWords, Facebook Ads,

  • bezahlte Anzeigen in Offline-Kanälen,

  • Email-Kampagnen an bestehende Kunden,

  • Blog-Beiträge

  • und Pilotkunden / -partner.

Umsetzung und langfristige Betreuung

Nachdem das Minimum Viable Product im Bermuda Digital Studio qualitativ und in den ersten Zügen quantitativ getestet wurde, sollte dies in der Regionalgesellschaft kontinuierlich weitergeführt werden. Dies bedeutet z.B. A/B-Tests durchzuführen, um das MVP zu optimieren oder aber auch bei Nicht-Akzeptanz der Nutzer das Produkt grundsätzlich zu hinterfragen. Bei beiden Aufgaben kann das Bermuda Digital Studio in Absprache mit der REG unterstützen.

Sollten die ersten Kundentests so positiv ausfallen, dass das MVP in einem stabileren auf langfristige Nutzung ausgelegtem Format gebaut werden soll und vor allem an die REG-spezifischen Backend-Systeme angebunden werden soll, kann das Bermuda Digital Studio dabei unterstützen, das Konzept und das MVP an eine Partneragentur oder die REG-IT zu übergeben.

Arbeitsweise

Arbeitsweise

Alle erarbeiteten Materialien ‘wie wir arbeiten’ sind open source. Das Playbook, Wireframing-Kits, Checklisten etc. sind für alle einsehbar und können auch von Teams außerhalb des Studios genutzt werden.

Alle erarbeiteten Materialien ‘was wir entwickeln’ sind innerhalb von E.ON zugänglich. Hierzu gehören User Flows, Wireframes, Code etc. sowie die dazugehörige Dokumentation der einzelnen Projekte.

In regelmäßigen Abständen wird das Bermuda Digital Studio zum Open House und zu Workshops einladen, bei denen Experten ihr Wissen und ihre Erfahrung teilen und den Teilnehmern von E.ON und außerhalb zugänglich machen. Diese Veranstaltungen bieten außerdem eine Plattform für einen regelmäßigen, informellen Austausch.

Jedoch allem voran wird Kompetenz innerhalb des E.ON Konzerns durch die aktiv gelebte Zusammenarbeit der Regionalgesellschaften mit dem Bermuda Digital Studio gefördert und transferiert.

Programmierkultur

Programmierkultur

Das Team des Studios entscheidet selbst, mit welcher Technologie und welchen Tools es arbeitet und wie es sich im Detail organisiert. Insbesondere prüft das Team kontinuierlich, ob die momentan gelebten Strukturen noch adäquat sind und sucht ständig nach Verbesserungen. Allerdings gibt es eine Menge bekannter Best Practices, aus denen die folgende handverlesene Auswahl einen sinnvollen Startpunkt und eine Referenz darstellen soll, an der sich jedes Produktteam zunächst orientieren sollte.

Versionsverwaltung

Wir benutzen git und organisieren unsere Branches nach gitflow. Generell gilt ‘commit fast / commit often’. Das Studio hat eine Gruppe auf gitlab.com, in der Projekt-Repositories abgelegt werden. Erledigte Features und Bugfixes werden durch das Stellen eines Pull-Requests dem restlichen Team vorgestellt. Erst nach erfolgtem Review, an dem das ganze Team beteiligt ist, dürfen die Änderungen in den develop-Branch übernommen werden. Ein Review schließt das auschecken des Branches und ein automatischen und/oder manuelles Testen mit ein. Der primäre Sinn von Code-Reviews liegt nicht darin, den Author zu prüfen, oder gar bloßzustellen. Vielmehr sollte ein Pull-Request als ein Vorschlag verstanden werden. Dieser Prozess ermöglicht jedem Team-Mitglied sämtliche Änderungen mitzuverfolgen und sich so für die gesamte Codebasis und damit für das Produkt verantwortlich zu fühlen. In diesem Geist sollten Pull-Requests gelesen werden und entsprechend über die vorgeschlagenen Änderungen diskutiert werden.

Codestyle

Der Output des BDS wird immer E.ON-weit veröffentlicht und hat somit Beispielcharakter für die ITs der REGs und die E.ON IT. Code-Qualität ist bei jedem Softwareprojekt essentiell - in dem Fall des Bermuda Digital Studios kommt noch die Intention hinzu, Vorbild für andere Units zu sein.

Zeit für Refactoring ist in jedem Sprint, bei jedem Feature einzuplanen. Pull-Requests sollten nur übernommen werden, wenn der Code vorzeigbar ist. Während der Entwicklung sollte ein Linter benutzt werden.

Code sollte hinreichend dokumentiert sein. In erste Linie meint dies eine aktuelle und gepflegte README Datei, die die Funktion und den Kontext des Codes erläutert und einem Einsteiger in die Lage bringt, das Projekt aufzusetzen. Code-Kommentare sollten hinzugefügt werden, wo es nötig erscheint - allerdings sollte vorher überprüft werden, ob ein Kommentar überflüssig wird, wenn die Lesbarkeit des Codes erhöht werden kann. Im besten Fall spricht Code für sich selbst.

Test-Fälle und ausführbare Spezifikationen sind als Dokumentation anzusehen und die Titel entsprechend aussagekräftig zu wählen.