„The Lean Entrepreneur“-Autor Brant Cooper mit Workshop und Talks in FrankfurtRheinMain

Brant Cooper

Zum Jahresende erwartet die Lean Startup-Community in FrankfurtRheinMain noch ein fettes Highlight: Brant Cooper kommt aus San Diego zu Gast nach Wiesbaden.

Neben „The Lean Entrepreneur“, das eines der Standardwerke für Lean Startup und Lean Innovation darstellt, ist er auch Co-Autor von „The Entrepreneur’s Guide to Customer Development“ und von „The Entrepreneur’s Guide to the Lean Brand“.

Am Abend vom 10. November könnt ihr Brant bei einem kostenfreien Meet&Greet kennenlernen: https://www.facebook.com/events/175112143066615/.

Zusätzlich gibt es diese Gelegenheiten, mehr über Lean Innovation und Lean Startup von Brant Cooper im Rahmen seines Aufenthalts in Wiesbaden zu lernen:

  • Am 10. November im Vorfeld des Meet&Greet bei einem ganztägigen Workshop: https://seibert.biz/brantcooper
  • Oder bei seiner Keynote und einer zusätzlichen Session beim XCamp (Unkonferenz zu Agile, Lean, Design Thinking & Co.) am 11. November: https://xcamp.co/.

Verwaltung eines Multi-Produkt-Backlogs

Wie lässt sich die Verwaltung eines Backlogs mit mehreren Produkten übersichtlich darstellen, so dass der Product Owner die Backlog-Verwaltung und die Release-Planung mit mehreren Stakeholdern komfortabel und effizient vornehmen kann? Wir haben uns hier zur Strukturierung eines Backlogs mit mehreren hundert Tickets dafür entschieden, einmal den Canvas for JIRA von Comalatech auszuprobieren, der eine Erweiterung von Atlassians JIRA darstellt.

In einem Workshop haben wir eine Matrix aufgespannt, die wir anschließend digital abgebildet haben. Besonders wichtig für die Release-Planung ist dabei die Aufgliederung des Backlogs nach dem MoSCoW-Prinzip. Die Backlogs der einzelnen Produkte werden nach diesem Prinzip eingeteilt in diese Kategorien:

  • Must-have-Anforderungen (sie sind essenziell für die Anwendung und unbedingt umzusetzen)
  • Should-have-Anforderungen (Anforderungen, die nicht zwangsläufig umgesetzt werden müssen, aber dennoch einen hohen Nutzen haben)
  • Could-have-Anforderungen (falls noch Zeit und Budget vorhanden ist)
  • Won’t-have-Anforderungen (Sie sind sinnvoll, aber nicht jetzt)
Canvas for JIRA für die Verwaltung eines Multi-Produkt-Backlogs

Canvas for JIRA für die Verwaltung eines Multi-Produkt-Backlogs

Unterstützung bei der Planung von Releases

Diese MoSCoW-Kategorien sind recht leicht verständlich und machen auch deutlich, auf welchen Teil sich für die Planung der nächsten Releases zunächst fokussiert werden kann. Diese Ansicht hilft also dabei, in einer Release-Planung für die Produkte schnell zu prüfen, was Berücksichtigung finden sollte.

Tickets der Kategorie „Won’t have“ entfernen wir aus dem Backlog, um diesen übersichtlich zu halten. Wir haben aber noch zusätzlich eine Ebene „High Business Value“ zum Einsatz gebracht, mit der zum Ausdruck gebracht werden kann, dass bestimmte Funktionalität (die in Must, Should oder Could liegen kann) ein gutes Verkaufsargument liefern würde.

Visualisierung der Arbeit für den Product Owner

Durch diese Art der Visualisierung wird auch einfach deutlich, wenn Tickets bestehen, die noch keiner Komponente/keinem Produkt zugeordnet wurden oder die noch nicht mit einer Priorität versehen wurden. Dadurch kann der Product Owner einfach sehen, wo er noch aktiv werden muss. In der ersten Spalte befinden sich dazu die „unlabelled“ Tickets, die dann per Drag&Drop einfach in die passende Spalte gezogen werden können.

Sind neue Tickets noch nicht dem richtigen Produkt zugeordnet worden, wird ganz oben eine erste Zeile angezeigt. Hier kann der Product Owner dann ebenfalls tätig werden und die Tickets dem entsprechend passenden Produkt zuordnen.

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben: Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder den RSS-Feed.

VERANSTALTUNGSHINWEIS: Tools4AgileTeams Konferenz in Wiesbaden

Produktmanagement Lesetipps: Gründen ohne technischen Co-Founder, Design Thinking, Reflective Thinking, Peer Reviews

Eine Ladung Informationen für Produktmanager gefällig? Wir haben Euch wieder eine Reihe von Lesetipps zusammengestellt. Diesmal geht es um’s Gründen ohne technischen Co-Founder, um den Ansatz „Design Thinking“, etwas Zeit zum Reflektieren, sowie die Kraft von Peer Reviews. Viel Spaß beim Lesen!

  • Why you should stop looking for a technical co-founder – at least for now von Andreas Kwiatkowski kann all denjenigen Nicht-Techies Mut machen, die denken, ohne das Erlernen einer Programmiersprache oder einen technisch versierten Co-Founder ließe sich die eigene Idee nicht realisieren. Die ersten Artikel auf seinem Blog Kwiat.com sind sehr vielversprechend und machen ihn zu einem Lesetipp für alle Internet-Produktmanager.
  • Ahmet Emre Acar stellt bei Gründerszene in seinem Artikel „Die Welt des Design-Thinking“ die Grundlagen des Design Thinking-Ansatzes dar. Dieser Innovationsansatz stellt in den Vordergrund, Dinge mit dem Menschen im Fokus neu zu erschaffen.
  • Don’t be Too Busy to Do Some Reflective Thinking – Wer sich täglich einem Information Overload aussetzt, sollte von Zeit zu Zeit ganz bewusst zurücktreten und sich die Zeit für etwas Reflektion nehmen. Marty Zwilling gibt uns ein paar Tipps, wie wir dabei vorgehen können, ohne auf der anderen Seite in ein „over-thinking“ zu verfallen.
  • Sebastian Schneider betont in seinem Beitrag zu „Peer Reviews“ die Bedeutung einer frühen Feedbackschleife durch die direkten Kollegen, die sehr kostengünstig ist und eine zeitnahe Qualitätssicherung ermöglicht, die spätere teure Korrekturen meidet.

Foto: 0xMatheus

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben: Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder den RSS-Feed.

Produktmanagement Lesetipps: Product Owner-Rolle, Kunden- und Anwenderbefragungen, Bereitschaft zu Fehlern, Pretotyping

Nach längerer Pause gibt es wieder einige Leseempfehlungen aus meinem RSS-Reader zu verschiedenen Themen, die für Produktmanager von Bedeutung sind.

Die Rolle des Product Owners

Roman Pichler stellt zwei typische Varianten gegenüber, wie die Product Owner-Rolle besetzt wird: Die Besetzung durch den Kunden selbst sowie eine Besetzung mit einem Proxy. Er schlägt aber auch vor, bei einem größeren Projektportfolio die beiden Varianten zu nutzen, je nachdem, ob nur für einen Kunden oder für eine Vielzahl von Kunden entwickelt wird: „Two common ways to apply the product owner role„.

Hilfreiche Tipps für Kunden- und Anwenderbefragungen

Egal ob Customer Development, Lean Startup oder agile Softwareentwicklung – sie alle empfehlen die aktive Einbeziehung von Kunden und Anwendern. Ein Mittel hierfür ist die Durchführung von Kunden- und Anwenderbefragungen. Zur Durchführung solcher Befragungen gibt es hier zahlreiche Tipps von einem erfahrenen Produktmanager: „How do I set up customer interviews?

Keine Angst vor Fehlern

Im hervorragenden Blog von HackFwd, dem Pre-Seed Investor von Lars Hinrichs, wird die Bedeutung des Scheiterns und des Fehler machen betont. Für die Realisierung von neuen Produkten ist es wichtig, die Bereitschaft aufzubringen, Fehler zu machen und aus ihnen zu lernen: „Fail better„.

Minimale Feedbackschleifen – Pretotyping

Wie kann so schnell wie möglich Feedback vom Markt eingeholt werden, um sicherzustellen, dass nur wirklich Nutzen schaffende Produkte und Features realisiert werden? Der Begriff des Prototyping ist bekannt. Doch auch für so manchen Prototypen wird noch Wochen und Monate gearbeitet.
Alberto Savoia empfielt: „Pretotype it!„. Und stellt auch gleich ein kostenfreies E-Book bereit, in dem er erklärt, wie hierfür vorzugehen ist.

Weitere Ausgaben der Produktmanagement Lesetipps:

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder RSS-Feed.

1. Treffen des Lean Startup Circle Rhein-Main

Nach dem derzeit heißesten Thema in der Produktentwicklung gefragt, ist meine Antwort sicherlich: „Lean Startup“. Dieser von Steve Blank und Eric Ries geprägte Ansatz erhält derzeit weltweit große Aufmerksamkeit.

Während wir dank der agilen Softwareentwicklung sehr gut wissen, wie wir gute Software entwickeln können, hilft uns der Lean Startup-Ansatz herauszufinden, ob wir die richtigen Dinge entwickeln. In Kombination geht es nicht mehr darum, Userstories umzusetzen, sondern im Team zu lernen, was funktioniert und bei den Usern Akzeptanz findet und was nicht.

Bisher gibt es im Rhein-Main-Gebiet noch keinen regelmäßigen Austausch zu diesem Thema. Daher starten wir den „Lean Startup Circle Rhein-Main„. Das erste Treffen des Lean Startup Circle wird am 2.4.2012 ab 18 Uhr in der Koi Nudelbar in Wiesbaden stattfinden. Zielsetzung für das erste Treffen ist es, Gleichgesinnte aus dem Rhein-Main-Gebiet kennenzulernen und uns gemeinsam a) über „The Lean Startup“ und den Erfahrungsstand sowie b) über die weitere Planung für den Lean Startup Circle Rhein-Main auszutauschen.

Anmeldungen erfolgen bitte über das XING-Event oder per E-Mail an pherwarth@seibert-media.net. Gerne könnt Ihr Euch auch melden, falls Ihr Interesse habt, an dem 1. Treffen aber nicht teilnehmen könnt. Falls Ihr einen Kurzbeitrag beisteuern möchtet, bitte auch kurz Bescheid geben. Informationen über den Lean Startup Circle Rhein-Main gibt es auch auf der entsprechenden Internetseite.

Foto: BetsyWeber

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder RSS-Feed.

Innovation needs waste – Verschwendung kann sinnvoll sein

Design ThinkingIm Rahmen einer Session auf den XPDays 2011 (17.-19.11.) wurde Design Thinking unter dem Titel „Innovation needs waste“ von Dirk Lässig und Pierluigi Pugliese vorgestellt.

Im Kern der Session ging es um die Ergänzung von agilen und schlanken Vorgehensweisen in der Umsetzung durch Design Thinking in der vorgelagerten Ideengenerierung und -findung. Im Rahmen von „Agile“ und Lean wird viel über die Vermeidung von Verschwendung gesprochen. Wenn das Ziel aber die Entwicklung einer innovativen Lösung bzw. eines innovativen Produkts ist, kann der Fokus im ersten Schritt nicht auf der Vermeidung von Verschwendung liegen. Hier ist zunächst einmal eine breit aufgestellte Suche sinnvoll, um sicherzustellen, dass ein sehr gutes Produkt für die zu lösende Problemstellung entwickelt wird.

Grundprinzipien des Design Thinking

Nach der Einleitung in das Thema stellten Lässig und Pugliese die Grundprinzipien von Design Thinking vor:

  • interdisziplinäres Team: Es wird mit interdisziplinären Zusammensetzung gearbeitet. Die Hintergründe sollten vielfältig sein. Es kommen z.B. Leute aus dem Marketing, dem Design, dem Vertrieb, Product Owner und Entwickler zusammen. Die Vielfalt wird als Bereicherung wahrgenommen.
  • iterativ & mit Timebox: Es wird über mehrere Iterationen hinweg an und mit den Ideen gearbeitet. Timeboxes helfen dabei, dass dennoch auf den Punkt auch ein Ergebnis vorliegt.
  • Ermutige Experimente: Experimente sollen angeregt und gefördert werden.
  • Kollektives Eigentum der Ideen: Ideen gehören, sobald sie geäußert wurden, dem Team und dürfen von jedem aufgegriffen und weiterentwickelt werden.
  • Reframe Fehler: Fehler mit Scheitern gleichzusetzen führt zu Angst, Fehler zu machen. Damit können innovative Ansätze im Keim erstickt werden. Ein anderes Verständnis von Fehlern ist daher erforderlich. Sie stehen auch für Erfahrung und gehören zum Erfolg dazu.
  • Sei empathisch: Versetze dich in die Anwender hinein.
  • Sei inspiriert.
  • Involviere reale Anwender: Damit die Lösung auch wirklich von den Nutzerbedürfnissen getrieben wird, sind diese in den gesamten Prozess einzubeziehen.
  • Entwickle Ideen: Denke nach.

Dann tauchten sie in das Thema ein und stellten vor, wie Design Thinking konkret angewendet wird.

Anwendung von Design Thinking – Breit starten, Optionen schaffen

Da es sich bei Design Thinking um ein iteratives Vorgehen handelt, lässt es sich als Kreislauf vorstellen, der mehrmals durchlaufen wird.
Der Kreislauf startet mit zwei zentralen Phasen:

1. Divergent thinking – create choices
2. Convergent thinking – make choices

In der Phase „divergent thinking“ wird zunächst einmal unter Nutzung von Kreativitätstechniken Wert auf die Schaffung einer Vielzahl von Möglichkeiten gelegt. Es soll möglichst breit gedacht und sich umfangreich mit der Thematik beschäftigt werden. Viele Auswahlmöglichkeiten und Ideen sind besser als wenige. Insbesondere in dieser Phase wird deutlich, dass Verschwendung vorteilhaft sein kann. Wird am Anfang breit gedacht und in verschiedene Richtungen gedacht, steigt die Wahrscheinlichkeit für eine passende Lösung.
Im Rahmen des konvergenten Denken werden die am besten erscheinenden Wahlmöglichkeiten ausgesucht und für diese Prototypen gebaut und Feedback gesammelt. Dadurch kann gelernt werden und mit diesen Erkenntnissen eine neue Runde eingeleitet werden, die wieder mit dem divergenten Denken startet.

Methoden für die Ideengenerierung

Die Methoden, die im Rahmen des divergent thinking angewendet werden können, sind vielfältig. Es kann eine Vielzahl von Kreativitätstechniken genutzt werden. Eine Auswahl davon stellten Lässig und Pugliese im Rahmen der Session vor:

  • Innovation Games
  • Mindmaps
  • Brainstorming
  • Morphologischer Kasten
  • Disney Strategy (Dreamer, Implementer, Criticiser)
  • 6-3-5 (6 Personen, 3 Ideen, 5 Minuten)

Durch die Anwendung des Verfahrens 6-3-5 konnten wir als Teilnehmer auch selbst eines davon direkt ausprobieren.

Foto: thinkpublic

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

Produktmanagement Lesetipps: Usability-Prinzipien, erfolgreiche Geschäftsmodelle, S.T.U.P.I.D. User, Software-Tests

Die Produktmanagement Lesetipps bieten wieder einen bunten Mix von aktuellen, interessanten Artikeln. Diesmal eine würzige Mischung aus Usability, Geschäftsmodellen und Software-Tests.

Sechs nicht intuitive Tests für Prinzipien von Entwicklungsteams

Wie lassen sich die Usability- und Design-Prinzipien eines Entwicklungsteams darauf prüfen, ob Sie etwas taugen? In einem Blogpost stellt Usability-Guru Jared Spool sechs Tests vor, mit deren Hilfe die Prinzipien überprüft werden können. Die zentralen Fragestellungen dabei sind:

Test #1: Basiert das Prinzip auf Nutzerforschung?
Test #2: Hilft das Prinzip, meistens “Nein” zu sagen?
Test #3: Führt das Prinzip zu einem Alleinstellungsmerkmal?
Test #4: Ist es etwas, das in einem späteren Release vielleicht wieder rückgängig gemacht wird?
Test #5: Passt das Prinzip zu diesem Projekt?
Test #6: Wird das Prinzip ständig auf den Prüfstand gestellt?

Wie die Prüfung auf diese Fragestellungen hin erfolgen kann, erfahrt ihr in diesem Artikel im //SEIBERT/MEDIA-Blog.

Eine Idee finden, die wirklich Geld einbringt

Der Unternehmer und Berater Paras Chopra beschäftigte sich in seinen letzten Blogartikeln damit, welche Geschäftsideen für Startups wirklich die Chance bieten, Geld zu verdienen, und welche nicht.

Seine zentralen Empfehlungen für eine erfolgreiche Geschäftsidee sind:

  • Find an industry (ideally, an old fashioned one) where people are making money
  • Find the single differentiator which will put your app apart in the already established industry (read or research what pain points are still not addressed by top 3 solutions)
  • Make a web app, market it, refine it based on feedback, monetize the app
  • Slowly incorporate all standard features expected out of a solution in that industry so you can shoot to be a market leader

Bei t3n gibt es zu den zentralen Punkte aus Paras Chopras Blogartikeln zu diesem Thema eine deutsche Zusammenfassung.

Sind eure User S.T.U.P.I.D?

Ist es für die Produktentwicklung relevant, ob die eigenen User clever sind oder nicht? Nach Stephen Turbek nicht.

It is an honest question: how smart are your users? The answer may surprise you: it doesn’t matter. They can be geniuses or morons, but if you don’t engage their intelligence, you can’t depend on their brain power.
Far more important than their IQ (which is a questionable measure in any case) is their Effective Intelligence: the fraction of their intelligence they can (or are motivated to) apply to a task.

Wir dürfen also auch lernen, dass selbst die cleversten User möglicherweise eine geringe Effektive Intelligenz im Moment der Nutzung der Anwendung aufweisen. Dies bringt S.T.U.P.I.D zum Ausdruck:
Stressed
Tired
Untrained
Passive
Independent
Distracted

Wie Anwendungen geschaffen werden können, mit denen auch S.T.U.P.I.D User zurecht kommen, wird im Artikel bei boxesandarrows erklärt.

Software-Tests: Notwendigkeit und Arten des Testens

In diesem Artikel beantwortet mein Kollege Manuel Kummerländer zwei zentrale Fragen rund um Tests (und vor allem automatisierte Tests) in der Softwareentwicklung. „Warum sind Tests wichtig?“ und „Welche Arten von Tests gibt es?“.

Mangelhafte Testprozesse sind die Hauptursache für im Live-System auftretende Software-Fehler.

Alleine deshalb lohnt sich bereits die Beschäftigung mit diesem Thema, hier geht es daher zum Artikel im Blog von //SEIBERT/MEDIA.

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Das Product Backlog Board

Diese Woche habe ich mit meinem Team einmal über das Product Backlog Board nach Empfehlung von Roman Pichler gesprochen. Das Product Backlog Board ist eine Visualisierung des Product Backlogs und der wichtigsten Constraints (= Nebenbedingungen/Auflagen) im Teamraum, so dass sich jederzeit jedes Teammitglied und auch die Stakeholder darüber informieren können.
Wir haben seit einiger Zeit eine Grundversion eines Backlog Boards im Büro gehabt, nach einer Schulung von Roman in München wurden mir jedoch noch einige Punkte deutlich, die ich mit dem Team abgestimmt habe.

Der Aufbau eines Backlog Boards

Den grundlegenden Aufbau eines Backlog Boards erklärt Roman in seinem Artikel „The Product Backlog Board„. Die folgende Darstellung zeigt ein reduziertes Product Backlog Board, an dem wir uns bei unserem Board orientiert haben:

product-backlog-board

Das Product Backlog Board

Die zentralen Bereiche des Product Backlog Boards sind die Story Area und die Constraint Area.

Die Story Area

In der Story Area wird der Product Backlog der aktuell in Arbeit befindlichen Version vorgehalten. Es handelt sich dabei nicht zwangsläufig um sauber ausformulierte Userstories, auch Fehlermeldungen können dort vorgehalten werden.
Von den Stories sind dort drei verschiedene Granularitäten vorzufinden: Stories, Epics und Themes.

Fein zerteilte Stories, die fertig für eine Umsetzung sind, befinden sich oben im „ready items“-Bereich. Die feine Zergliederung und Fertigstellung von Stories werden dabei auf diejenigen fokussiert, die im nächsten Sprint für eine Umsetzung vorgesehen werden.

Im unteren Teil der Story Area befinden sich Themes und Epics. Die Themes dienen der ganz groben Unterteilung des Backlogs nach Themenbereichen. Die Epics stellen eine grobe Formulierung von Features dar, die erst dann feiner formuliert und ausgearbeitet werden, wenn die Umsetzung nahe rückt.
Im Bereich der „ready items“ ist eine Priorisierung durch den Product Owner Pflicht, während im Bereich der Themes & Epics nach Roman eine Priorisierung nicht unbedingt erforderlich ist.

Die Constraint Area

In der Constraint Area werden die grundlegenden Anforderungen an das User Interface sowie operative Eigenschaften der Software festgehalten.
Das Produkt- und User Interface-Design kann in Form von Screens/Wireframes/Skribbles mit Anmerkungen zu den wichtigsten Vorgaben Vereinbarungen dargestellt werden.
Die operativen Eigenschaften können durch „Constraint Cards“ abgebildet werden, wobei pro Karte eine bestimmte operative Eigenschaft festgehalten wird. Das kann u.a. die Browser, für die optimiert werden soll, die Performance oder die Skalierbarkeit eines Softwareprodukts betreffen.
Die Constraints sollten mit der Definition of Done verknüpft werden, damit deren Einhaltung zum Bestandteil der Abnahme von jeder einzelnen Userstory wird. Das lässt sich gut am Beispiel der Browseroptimierung verdeutlichen. Wird diese in die Definition of Done aufgenommen, ist bei der Abnahme einer Story auch eine entsprechende Prüfung in den verschiedenen Browsern vorzunehmen. Ist die Erfüllung dieses Constraints nicht gegeben, gilt die Story somit nicht als „Done“.

[Anmerkung: Roman weist in seinem Beitrag über das Product Backlog Board noch eine „Model Area“ aus. Diese wurde im Rahmen der Schulung nicht behandelt und eignet sich auch für eine spätere Ergänzung.]

Regelmäßige Backlog-Pflege

Die regelmäßige Pflege des Product Backlogs und des Boards erfolgt in Form von Backlog Grooming Workshops oder Sessions. Das Team (inkl. Product Owner) nimmt dabei gemeinsam eine Aktualisierung des Backlogs vor, bespricht Stories, zerteilt sie, fügt neue hinzu und beschätzt sie. Für Teams mit 2-wöchigen Sprints schlägt Roman vor, wöchentlich 2 Stunden mit Backlog Grooming Workshops zu verbringen.
Wir hatten bisher weniger Zeit mit dem Grooming verbracht und haben die Workshops auch nicht zu einem festen Termin durchgeführt. Dies werden wir in Zukunft tun. Der Beitrag des Teams zur Erstellung und Pflege des Backlogs wird damit deutlich höher, wodurch auch sichergestellt wird, dass alle relevanten Aspekte einer Story besprochen werden.
In dem Workshop kann das Backlog Board auch direkt aktualisiert werden.

Mit diesem Setting werden wir in den nächsten Wochen erst einmal Erfahrungen sammeln. „Inspect and Adapt“. Die Reise mit Scrum bleibt spannend.

Weitere Artikel zur Product Backlog-Pflege:

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.
%d Bloggern gefällt das: