Conspiracy Walls in Requirements Engineering – Analyzing Requirements like a Detective<\/a><\/p>\nInterview zu Continuous UX und Requirements Engineering<\/h2>\n
Anne:<\/b> Woher kommen aus UX-Sicht Anforderungen, speziell Nutzeranforderungen bzw. User Requirements? Welche Erhebungstechniken werden eingesetzt, was funktioniert gut, was funktioniert nicht gut? Dazu haben wir verschiedenste Fragen, die wir in verschiedene Themenbl\u00f6cke eingeordnet haben. Kannst du aus deiner Arbeit ein Projekt ausw\u00e4hlen, anhand dessen wir diese Fragen diskutieren? Bestenfalls ein Projekt, bei dem die Anforderungen vom Kunden oder den Stakeholdern kamen und die dann in einer entsprechenden L\u00f6sung umgesetzt wurden. Dann w\u00fcrde ich gerne spezifischer auf die Rollen im Team eingehen, welches das Projekt umgesetzt hat.<\/p>\n
Thomas:<\/b> Ich nehme ein anonymes Projekt aus der Finanzbranche. Es handelt sich um ein UX Design Projekt mit einem Team von sechs Leuten bei Centigrade: ein User Researcher, zwei Frontend Engineers, ein Visual Designer, ein Concept Designer und ich in der Projektleitung. Dazu kam das Team auf Kundenseite.<\/p>\n
Anne:<\/b> Das waren dann auch die Rollen, mit denen du \u00fcber das Projekt hinweg intensiv zusammengearbeitet hast?<\/p>\n
Thomas:<\/b> Genau. Wobei die Intensit\u00e4t der Zusammenarbeit allerdings eher von der Projektphase abhing, in der wir uns gerade befanden. Am liebsten h\u00e4tte man immer alle Menschen zu jedem Zeitpunkt mit dabei. Aus wirtschaftlicher Sicht ist das aber nicht sinnvoll. Deswegen versuchen wir immer, eine effiziente \u00dcberlappung der verschiedenen Disziplinen hinzubekommen. Am Anfang, wenn das Produkt noch in der Discovery Phase steckt und st\u00e4rker von den User Research Ergebnissen abh\u00e4ngt, \u00fcberlappen User Research und Concept Design sehr stark und finden ihre Gemeinsamkeiten im Requirements Engineering. Wenn man innerhalb der Product Discovery Phase st\u00e4rker ins Prototyping gehen kann, \u00fcberlappen Concept Design und Visual Design. Und dann, wenn es in die Umsetzung geht und es von der Discovery eher in eine kontinuierliche Delivery \u00fcbergeht, \u00fcberlappen Visual Design und Software Engineering mit Concept Design. Wir versuchen also, den richtigen Staffelstab im richtigen Moment dem richtigen Kollegen zu bringen, damit dieser das n\u00f6tige Wissen bekommt und seinerseits den Staffelstab wieder weitertr\u00e4gt.<\/p>\n
![\"Thomas](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Thomas-Anne-Interview.jpg\")
<\/p>\n
Anne:<\/b> Verstehe. Das hei\u00dft, du warst \u00fcber alle Phasen hinweg als Product Owner involviert?<\/p>\n
Thomas:<\/b> Nein, nicht als Product Owner, sondern als UX Manager, da die Product Ownership oft beim Kunden liegt. Das hei\u00dft, wenn der Kunde es nicht explizit anders m\u00f6chte, machen wir keine strategischen Vorgaben wie es ein PO oft tut, sondern fragen eher die Gegebenheiten ab, ordnen sie aus nutzer-zentrierter Sicht ein und unterst\u00fctzen der Priorisierung. Wir m\u00f6chten also nicht direkt vorgeben, welches Backlog-Item nach oben oder nach unten geh\u00f6rt, sondern auf Basis der User Research Erkenntnisse informierte Empfehlungen geben. Wir k\u00f6nnen nat\u00fcrlich argumentieren, warum wir glauben, dass eine gewisse Richtung f\u00fcr die Nutzer*innen sinnvoll ist, aber letztlich m\u00fcssen wir alle uns immer die Frage stellen \u201eWelche Gesch\u00e4ftsmehrwerte m\u00f6chte das Unternehmen mittels UX aus strategischer Sicht erzielen?\u201c Beantworten kann diese Frage nur der Kunde selbst. Deswegen liegt die PO Rolle auch fast ausschlie\u00dflich beim Kunden. Wir sehen die UX Manager Rolle also als eine begleitende, assistierende Rolle f\u00fcr den PO: Der UX Manager muss im Gegensatz zum PO darauf achten, dass die Gewerke ineinandergreifen, dass sie \u00fcbergabef\u00e4hig sind und dass sie auf echten User Research Erkenntnissen fu\u00dfen. Das war also auch meine Rolle als UX Manager des angesprochenen Projektes.<\/p>\n
Anne:<\/b> Und gab es au\u00dfer dem PO auf Kundenseite noch weitere Rollen, mit denen du interagiert hast?<\/p>\n
Thomas:<\/b> Ja, bei diesem speziellen Projekt waren das sogar sehr viele. Es gab neben dem PO noch eine dedizierte Projektleitung, um das Projekt zu steuern sowie Ressourcen und Budgets im Blick zu halten. Es gab zudem einen Dom\u00e4ne-Experten, manchmal auch \u201eSubject Matter Expert\u201c oder \u201eBusiness Analyst\u201c genannt, speziell f\u00fcr die Finanzbranche, ein kleines Assistenzteam aus Werkstudenten f\u00fcr User Needs und Marketingrecherche sowie einen Software Architekt, der die gesamte IT-Infrastruktur den Kunden wie seine eigene der Westentasche kannte.<\/p>\n
Anne:<\/b> Was waren die prim\u00e4ren Quellen, aus denen ihr eure Anforderungen erhalten habt?<\/p>\n
Thomas:<\/b> Da es sich um ein gro\u00dfes Finanzinstitut gehandelt hat, gab es nat\u00fcrlich eine dedizierte Marketingabteilung, die vorab schon Marketing-Personas in Richtung Milieus und Generationen segmentiert hatten. Aber diese Art von Profilen, \u00e1 la Millenials vs. Generation Y waren noch zu grob f\u00fcr die UX Arbeit.
\nDaher haben wir im Centigrade Team die User Research Aktivit\u00e4ten geleitet, Interviews gef\u00fchrt, in Foren gest\u00f6bert und spezielle Recherchen beispielsweise in Nutzerforen gemacht. Wir haben uns zum Beispiel durchgelesen, wie sich unsere Zielgruppe darauf vorbereitet, wenn sie mit 18 Jahren zum ersten Mal gesch\u00e4ftsf\u00e4hig wird. Diese und andere Schl\u00fcssel-Lebenssituationen haben wir uns tiefer angeschaut, um herauszufinden, wann welches Nutzererlebnis welche Zielgruppe am besten erreicht.
\nEs gab hierzu gl\u00fccklicherweise auch viele Freiwillige in diesem Konzern, die gesagt haben, ich melde mich als potenzieller Kunde und erz\u00e4hle dir aus meinem Leben.
\nWir haben diesen Menschen viele l\u00f6sungsunabh\u00e4ngige Fragen gestellt, wie z.B.: \u201eWie war das, als du vollj\u00e4hrig geworden bist, als du dein erstes Konto hattest?\u201c, \u201eWas hat das mit dir gemacht, pl\u00f6tzlich m\u00fcndig zu sein?\u201c und so weiter.<\/p>\n
Anne:<\/b> Das hei\u00dft, ihr habt die Ist-Situation untersucht und vom Kunden keine konkreten funktionalen Anforderungen bekommen?<\/p>\n
Thomas:<\/b> Genau, es geht bei der Anforderungsanalyse vor allem um die Beschreibung von Lebenssituationen in Form sogenannter Nutzungs-Szenarien. Eine beispielhafte Lebenssituation w\u00e4re z.B. die, dass gerade der Urlaub eines P\u00e4rchens mit Nachwuchs finanziert werden muss. Das P\u00e4rchen wei\u00df noch nicht, wie viele Ausgaben es mit Kind zu erwarten hat. Das P\u00e4rchen kann also noch gar nicht kalkulieren, was es sich leisten kann. Es braucht eine andere Wohnung, ist aber noch zu jung, um kreditw\u00fcrdig zu sein. Das ist eine der vielen beispielhafte Stellen, an denen neue CX oder UX L\u00f6sungen einen echten Mehrwert liefern k\u00f6nnen. Hinter der Verkn\u00fcpfung der Themen Wohnung, Reise und Finanzierung verbirgt sich offensichtlich ein gro\u00dfes Potenzial, wenn es darum geht, als Finanzinstitut hilfreiche Unterst\u00fctzung f\u00fcr die gesetzte Zielgruppe anzubieten.
\nAus Nutzungsszenario haben wir anschlie\u00dfend sogenannte User Needs abgeleitet. Im Grunde sind das nicht-verifizierte Annahmen dar\u00fcber, welche konkreten Nutzerbed\u00fcrfnisse in verschiedenen Kontexten existieren.<\/p>\n
![\"Thomas](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Thomas-Anne-Interview-2.jpg\")
<\/p>\n
Anne:<\/b> Habt ihr die User Needs mit den Nutzern validiert?<\/p>\n
Thomas:<\/b> Wir haben sie zun\u00e4chst einmal mittels User Research nur verifiziert. Indem wir mit Nutzern ins Gespr\u00e4ch oder in die Beobachtung gehen, erhalten wir konkrete Hinweise dar\u00fcber, ob es korrekt ist, was wir als Anforderung vermuten. Aus den informellen, unverifizierten User Needs als reine Annahmen werden durch die Verifizierung dann schlie\u00dflich User Stories, also echte Nutzeranforderungen.<\/p>\n
Anne:<\/b> Und diese Verifizierung, macht das eine bestimmte Person und ihr habt euch dann ausgetauscht oder hat jeder ein wenig Research betrieben und ihr habt eure Erkenntnisse zusammengetragen?<\/p>\n
Thomas:<\/b> Es sind meistens zwei Personen, die in den User Research gehen. Wir m\u00f6chten hier bewusst eine \u00dcberlappung von User Researcher und Concept Designer. Der User Researcher hat dann allerdings den Lead. In diesem Fall ist das eine Psychologin gewesen, die den Konzepter mit ins Boot genommen hat, so dass die beiden f\u00fcr die kurze Phase der Verifizierung ein kleines Team gebildet haben; der User Researcher schielt dabei etwas mehr auf den Problemraum, der Konzepter etwas mehr auf den L\u00f6sungsraum.
\nUser Research ist f\u00fcr uns n\u00e4mlich eine rein lesende Disziplin. Sie gestaltet nicht, sie stellt in Frage. Sie dreht Steine um. Sie schaut hinter die Kulissen, aber sie setzt keine Ideen in die Welt. Diese harte Trennung finde ich wichtig. So sehr ich mit Continuous UX anstrebe, dass alle Gewerke letztlich ineinanderflie\u00dfen, am Ende des Tages sollte man nie das testen, was man selbst gestaltet hat. Deswegen bin ich da f\u00fcr eine Gewaltenteilung.<\/p>\n
Anne:<\/b> Die User Researcherin war eine Psychologin. Sind es bei euch immer Psychologen, die diese T\u00e4tigkeit machen? Was gibt es sonst noch f\u00fcr Ausbildungshintergr\u00fcnde?<\/p>\n
Thomas:<\/b> Ja, das ist bei uns fast ausschlie\u00dflich so. Wenn es keine reinen Psychologen sind, dann handelt es sich zumindest um eine informatische Ausbildung mit Psychologie als Nebenfach, was zum Beispiel an der Uni Duisburg-Essen inzwischen Kognitionswissenschaften hei\u00dft. Dort bekommt man genug psychologischen Hintergrund, um im User Research effektiv zu sein.<\/p>\n
Anne:<\/b> Wurden trotz der tiefen Nutzeranalyse Kreativit\u00e4tstechniken und Design Thinking in diesem Projekt angewendet? Wie wird so etwas typischerweise durchgef\u00fchrt und wer ist daf\u00fcr verantwortlich?<\/p>\n
Thomas:<\/b> Ja! Mit Eintreffen der ersten User Research Erkenntnisse, gehen wir in die Ideenphase \u00fcber. Hier wiederum ist der Konzepter im Lead und triggert die kreativen Impulse. Allerdings beschr\u00e4nkt er sich auf den Problemraum, den der User Researcher vorgibt. Wir sehen Kreativit\u00e4t immer dann besonders lebendig, wenn der Raum, indem man sich bewegt, m\u00f6glichst begrenzt ist und eben nicht, wenn er zu offen ist. Wir gehen mit etwa 3 User Stories in Ideation Workshops. Diese beschreiben vielleicht gerade mal 4 Minuten im Leben des Nutzers und trotzdem entz\u00fcnden sie oft ein Feuerwerk an Ideen. Es sind alle Ideen erlaubt, allerdings nur wenn sie zum Kontext der ausgew\u00e4hlten User Stories passen. Wenn eine Idee technisch nicht umsetzbar ist, darf sie trotzdem rein. Der in diesem Fall zweifelnde Engineer, darf dann h\u00f6chstens eine weitere Idee vorschlagen, die noch einfacher umsetzbar ist, aber nicht die urspr\u00fcngliche Idee zunichte machen. Software Engineers sind bei diesem Format also explizit erw\u00fcnscht!<\/p>\n
Anne:<\/b> Ihr habt ja ein ganzes Portfolio an Techniken, um Anforderungen zu erheben. Wenn ein neues Projekt kommt, macht ihr am Anfang eine Planung, welche Methoden ihr benutzen wollt? Und wenn ja, was sind Faktoren, die diese Auswahl beeinflussen?<\/p>\n
Thomas:<\/b> Wir versuchen, die besten Methoden herauszupicken und immer wieder mit m\u00f6glichst den gleichen Methoden zu arbeiten. Ich glaube n\u00e4mlich, dass auch eine gute Methode ein schlechtes Ergebnis produziert, wenn dort keine Routine existiert. Das hei\u00dft, du kannst nat\u00fcrlich immer aus einem Blumenstrau\u00df von Methoden ausw\u00e4hlen, aber, wenn du die ausgew\u00e4hlten Methoden nicht st\u00e4ndig jeden Tag anwendest, dann bringen sie dir zwar vielleicht neue Inspiration, aber nicht diese professionelle Routine, um effektiv und effizient zu sein. Ein Visual Designer wird auch nicht auf die Idee kommen, st\u00e4ndig seine Design-Tools zu \u00e4ndern. Es gibt Skills, die man sich immer wieder neu drauf schafft. Nat\u00fcrlich darf man nicht stehen bleiben und muss links und rechts am Wegesrand die Augen offenhalten. Aber man muss auch eine Routine mitbringen.<\/p>\n
Anne:<\/b> Was funktioniert bei euch in der Anforderungserhebung besonders gut?<\/p>\n
Thomas:<\/b> Ich glaube, was wir sehr gut schaffen ist, den Nutzungskontext hart einzugrenzen und \u201eScope Creep\u201c zu verhindern. Den User Research dazu nennen wir daher auch \u201eScoped User Research\u201c, also User Research in begrenztem Umfang. Du kannst n\u00e4mlich ganz leicht deinen User Research starten, in eine Maschinenhalle fahren und dort halb-erschlagen von 1.001 Eindr\u00fccken zur\u00fcckkehren. Du kannst mit jeder Menge Nutzer*innen dort sprechen, aber so viele Notizb\u00fccher kannst du gar nicht f\u00fcllen, wie du dort an Erkenntnissen mitnimmst. Und was machst du dann damit? Du oder deine Kolleg*innen bekommen das gar nicht verarbeitet.
\nIm Scoped User Research legen wir daher explizit vorher fest, was dasjenige Nutzungsszenario ist, welches den h\u00f6chsten gesch\u00e4ftlichen Mehrwert verspricht. Wir legen vorher fest, welches unsere Schl\u00fcsselpersona und unsere wichtigsten User Needs sind und genau die schauen wir dann per Interview oder Beobachtung im Detail an. Klar erz\u00e4hlen die Nutzer*innen auch mal von anderen spannenden Sachen, aber wir versuchen, das weitestgehend f\u00fcr sp\u00e4ter zu parken bzw. als \u201eGef\u00fchl\u201c mitzunehmen, ohne uns eing\u00e4ngiger damit auseinanderzusetzen. Den Finger legen wir auf diejenigen Punkte, die durch das Nutzungsszenario vorgegeben sind. Und dieses Szenario ist immer sehr knackig formuliert, weswegen wir meistens mit einem Tag oder zwei super hinkommen.<\/p>\n
Anne:<\/b> Wo siehst du Probleme oder Herausforderungen in der Erhebung?<\/p>\n
Thomas:<\/b> Die gr\u00f6\u00dfte Herausforderung beim Requirements Engineering besteht darin, Anforderungen so zu dokumentieren, dass jemand sie richtig versteht, der nicht von Anfang an dabei war. Da habe ich selbst noch nicht den \u201eSweet Spot\u201c gefunden. Was ist zu viel, was ist zu wenig Doku? Manchmal h\u00f6re ich z.B. Software Engineers sagen, \u201eEs interessiert mich nicht, was die Persona ist. Ich will nur wissen, was ich jetzt entwickeln soll.\u201c Da bin ich skeptisch, ob das eine gute Einstellung ist. Ich glaube, jeder in einem Frontend-nahen Entwicklungsteam muss UX denken wollen und hier muss man die Software Engineers dann ein St\u00fcck zu ihrem Gl\u00fcck zwingen, beispielsweise indem man sie zum Ideen-Workshop einl\u00e4dt, an dem die Persona zu Beginn gro\u00df und breit vorgestellt wird. Das macht die Herausforderung hinten raus deutlich kleiner. Au\u00dferdem sind immer auch mal wieder Leute krank oder das Team erh\u00e4lt Zuwachs oder was auch immer. Und wie vermittelst du jetzt diesem Neuling in kurzer Zeit, was eigentlich das Problem ist, wenn du auf keinerlei Dokumentation zur\u00fcckgreifen kannst. Das ist extrem schwer. Im Grunde haben wir bei Centigrade den Continuous UX Baukasten ja auch nur deshalb erfunden, damit wir trotz vieler externer Ver\u00e4nderungen, die eine Agentur immer wieder hat, also Kundengr\u00f6\u00dfe, Teamkonstellationen, UX Maturity, Agilit\u00e4tsgrad usw. dennoch immer eine reproduzierbare Qualit\u00e4t liefern k\u00f6nnen. Ich glaube unser Erfolg bei verschiedensten Weltmarktf\u00fchrern sowie zahlreiche Designpreise zeigen, dass das eine wirklich gute Investition war.<\/p>\n
Anne:<\/b> Wir haben von Personas geh\u00f6rt, von Szenarien, User Needs, User Stories, aber auch die von dir im Rahmen von Continuous UX immer wieder genannten User Booklets fand ich spannend. Kannst du dazu mehr erz\u00e4hlen?<\/p>\n
Thomas:<\/b> Bei der User Booklet Methode geht es einzig darum, nutzerzentrierte Artefakte wie User Research Erkenntnisse, Konzeptideen oder Screen Mocks zwischen interdisziplin\u00e4ren Teammitgliedern m\u00f6glichst schnell auszutauschen.
\nDenn: Das reine \u201eAnforderungsdaten reinkippen\u201c machen viele. Viele kippen Daten in Confluence oder ein beliebiges anderes Wiki ein. Aber was passiert dann mit diesen Daten? Nichts, wenn der jeweils n\u00e4chste sich nicht auch konsumieren kann. Daher reichen wir jeder User Story sukzessive mit nur den Informationen an, die in diesem Kontext relevant sind. Wir kippen nicht alle User Research Ergebnisse in den einen Ordner und alle Figma Prototypen in den anderen Ordner. Wir dokumentieren explizit immer nur diejenigen Artefakte, die f\u00fcr ein*e bestimmte*n Nutzer*in in einem bestimmten Nutzungskontext relevant sind. Jemand, der neu ins Team zust\u00f6\u00dft, kann so beispielsweise direkt von einer bestimmten L\u00f6sungsidee zur\u00fcckspringen auf deren Ursprung und Motivation.<\/p>\n
Zudem erzeugen wir aus unseren Anforderungsdaten automatisiert Poster und Geschichten, die andere schnell auf hoher Flugebene abholen. Wir erschaffen per Knopfdruck spannende Stakeholder Infografiken, die auf einen Blick verraten, welche Stakeholder Endnutzer und welche Kaufentscheider oder sogar beides sind. Wir nutzen daf\u00fcr das Software Tool LeanScope, welches sich perfekt f\u00fcr Storytelling-basiertes Requirements Engineering sowie f\u00fcr die User Booklet Methode eignet.<\/p>\n
Anne:<\/b> Spielst du auch immer alles zur\u00fcck, was sich w\u00e4hrend Projektretros ergibt?<\/p>\n
Thomas:<\/b> Nat\u00fcrlich! Man kann manchmal viel falsch machen, bis ein Projekt wirklich knallt. Das hat sich aber dann meistens abgezeichnet und es knallt dann so richtig. Man kann leider auch viel richtig machen und es knallt trotzdem! Daher ist es wichtig zu beobachten, was im Detail an einem Projekt gut funktioniert hat und was nicht. Und was davon ist generalisierbar und was davon ist einfach der Projektkonstellation anzurechnen.
\nIch sehe den Continuous UX Baukasten wie ein versioniertes Produkt. Mit jedem Projekt kommt eine kleine Versionsnummer dazu und wir releasen unser neues Continuous UX Playbook. Und so entwickeln wir uns automatisch immer weiter und Continuous UX wird evolution\u00e4r besser mit jedem Tag.<\/p>\n
Anne:<\/b> Was ist denn die gr\u00f6\u00dfte Herausforderung beim Umsetzen von Anforderungen?<\/p>\n
Thomas:<\/b> Die K\u00f6nigsdisziplin ist es, den Sprung zu schaffen vom Design ins Engineering. Es ist einfach unglaublich schwer, weil es sich gegenseitig so oft bedingt. Bringt man immer alle Software Engineers von Anfang an rein und dann sind sie pl\u00f6tzlich alle Designer? Oder bringt man die Designer am Anfang rein und die Engineers ein bisschen sp\u00e4ter, aber dann geht die Akzeptanz der Software Engineers fl\u00f6ten? Wir glauben daran, dass es gut ist Software Engineers fr\u00fch zu involvieren und als Sparringspartner f\u00fcr die Designer zu sehen. Letztlich sage ich auch immer: Designer sind auch Entwickler, genau wie Engineers. So war es in der Videospiel Branche schon immer\u2026 und da komme ich her.<\/p>\n
Anne:<\/b> Ihr arbeitet hier r\u00e4umlich eng zusammen. Wie l\u00e4uft so die typische Kommunikation ab?<\/p>\n
Thomas:<\/b> Wir sehen kollaborative Workshops mit den Kunden als Pfeiler unseres Continuous UX Prozesses. Die sind unverschiebbar. Es geht los mit dem Scoping Workshop, dann gehen wir in den Ideation Workshop usw. Es gibt diese Workshops zur Synchronisierung zwischen Teams und die sind nach M\u00f6glichkeit face-to-face, funktionieren seit Corona aber auch wunderbar remote. Zwischen den einzelnen Workshops werden die Fachdisziplinen aktiv, schaffen ihre Artefakte und sammeln sie in den User Booklets. Die Workshops sind also kleine strukturgebende Stationen, und dazwischen ist auch mal Freestyle angesagt auf fachlicher Ebene. Aber es kommt eben immer kontinuierlich zu einem Austausch mit einem klar definierten Ziel. Das bringt alle Teammitglieder weiter und lasst sie zusammenwachsen statt in Silos zu denken.<\/p>\n
<\/p>\n","protected":false},"author":5,"featured_media":0,"template":"","tags":[935,569,894,146],"class_list":["post-14997","blog","type-blog","status-publish","hentry","tag-anforderungsanalyse","tag-continuous-ux-de","tag-requirements-engineering","tag-ux-de"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/14997","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/types\/blog"}],"author":[{"embeddable":true,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/users\/5"}],"version-history":[{"count":11,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/14997\/revisions"}],"predecessor-version":[{"id":15066,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/14997\/revisions\/15066"}],"wp:attachment":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/media?parent=14997"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/tags?post=14997"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"\"](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Thomas-Immich-und-Anne-Hess-Interview.jpg\")
<\/p>\n