Fangen wir an, Inhalte mehr wie Code zu behandeln

Die Technologiebranche ist ziemlich besessen davon, zu verhindern, dass Codefehler in die Produktion gelangen. Wir geben uns große Mühe, um sicherzustellen, dass ein Fehler nicht von den Fingerspitzen des Entwicklers bis hin zum Produktsystem gelangt.

Es gibt einen ganzen Bereich namens DevOps (kurz für "Development Operations"). Es handelt sich dabei um eine Branche mit einem Umsatz von etwa 5 Milliarden Dollar. Es gibt ganze Marktsegmente mit Unternehmen, die die Bewegung und das Testen von Code streng kontrollieren.

Such doch mal nach"DevOps-Diagramm". Du wirst erstaunt sein, was du findest - detaillierte Schemata, die genau zeigen, wie der Code kopiert, verpackt, getestet und eingesetzt werden sollte. Entwickler, die keinen künstlerischen Funken in sich haben, werden plötzlich zu Da Vinci, wenn sie genau beschreiben, wie sie den Code-Einsatz organisieren wollen.

All das dient nur einem Ziel: zu verhindern, dass schlechter Code in die Produktion gelangt. Ein hehres Ziel, gewiss.

...aber warum kümmern wir uns nicht so sehr um den Inhalt?

Während wir auf der Codeseite majestätische Akrobatik betreiben, läuft es bei den Inhalten meist so ab: "Also, Alice schreibt etwas in Word, schickt es per E-Mail an Bob, der es in den Rich-Text-Editor kopiert" und drückt dann auf "Veröffentlichen".

Herzlichen Glückwunsch, du hast die dichteste, zuverlässigste Codebasis, die schreckliche Inhalte liefert. A+. Gute Arbeit.

Inhaltsfehler sind ein Problem, und wir tun nicht genug, um sie zu verhindern. Vor allem sehen wir die Entwicklung von Inhalten nicht als einen Prozess an, der gesteuert werden muss. Wir denken, dass es sich um eine Art Magie handelt und nicht um einen Arbeitsfluss mit Kontrollpunkten, nachvollziehbaren Aufgaben und Überprüfungsschleusen. Wir sind davon überzeugt, dass dies der Arbeit die "Seele" nehmen würde oder so.

Während unsere Entwicklerinnen und Entwickler also sechsstellige Summen an Spielzeug bekommen, um sicherzustellen, dass sie jede Codezeile sofort austauschen können, ohne ihren Kaffee zu verschütten, kopieren unsere Inhaltserstellerinnen und -ersteller Dinge in Slack und schreien "Ich schwöre, dass ich dir das letzte Woche geschickt habe" über die Kabinenwand.

Das müssen wir besser machen.

Das Erstellen von Inhalten ist keine Magie - genauso wenig wie Code Magie ist. Es ist ein Prozess, der genauso verwaltet werden kann und sollte wie die Bereitstellung von Code, und er verdient die gleiche Wertschätzung.

Deine Inhaltsersteller brauchen:

• Bibliotheksdienste. Deine Entwickler haben eine Quellcodeverwaltung. Sie wissen immer, wo der Code ist. Wahrscheinlich haben sie noch Versionen davon, als sie noch Teenager waren. So etwas gibt es auch für Inhalte - man nennt sie Content Marketing Plattformen (CMPs) und Digital Asset Management Systeme (DAMs). Sie wurden entwickelt, um Inhalte zu speichern, zu organisieren und zu versionieren, damit die Ersteller/innen wissen, wo sich alles befindet.
• Änderungsmanagement in Form eines Redaktionskalenders. Deine Entwickler/innen wissen, wann der Code veröffentlicht wird (Achtung: nicht freitags). Sie planen diese Dinge lange im Voraus. Aber wenn du einen Inhaltsersteller fragst, wann Inhalt X für die neue Kampagne veröffentlicht wird, kann er nur sagen: "Ich weiß es nicht. Ich habe es Bob gezeigt. Es liegt jetzt in seiner Hand..."
• Workflow: Entwickler/innen haben detaillierte Ticket-Management-Systeme, die ihre Aktionen bis zur genauen Zeile des Quellcodes zurückverfolgen können, die sie geändert haben, um einen Fehler zu beheben. Diese Systeme sorgen dafür, dass jeder zu jeder Zeit weiß, wer für was verantwortlich ist. Währenddessen können die Inhaltsredakteure nur mit den Schultern zucken, wenn jemand fragt, wer den Blogbeitrag der Geschäftsführerin bearbeiten sollte, den sie gerade von der Keynote-Bühne aus angekündigt hat.
• Inhaltsvorschau. Ich verspreche dir, dass dein Entwicklungsteam ein abgestuftes System von Umgebungen hat, in denen sie den Code testen. Wahrscheinlich verbringen sie Hunderte von Stunden mit der Pflege dieses Systems, damit sie den Code isoliert ausführen können und genau wissen, wie er funktioniert, bevor sie ihn einsetzen. Denke das nächste Mal gerne daran, wenn deine Bildunterschrift in 30pt Fettschrift veröffentlicht wird, weil dir niemand gesagt hat, dass das nicht so sein würde. (Übrigens habe ich in letzter Zeit viel über Vorschauen nachgedacht.)

Hier ist der Grund, warum das wichtig ist:

Inhaltliche Fehler sind wichtig. Sie können viel mehr Schaden anrichten als Code-Fehler, sind aber viel schwieriger zu entdecken. Bis du merkst, dass etwas nicht in Ordnung ist, kann das Problem schon lange in der Öffentlichkeit bestehen und viel Schaden anrichten.

Stell dir vor, du hast ein Softwareunternehmen und versuchst, einen Analysten dazu zu bringen, deine Software in einen seiner Berichte aufzunehmen. Deine Analystenbetreuer haben den Analysten ständig umworben, umgarnt und ihm zu verstehen gegeben, dass deine Software genau in sein Segment passt und eine gute Ergänzung für den Bericht wäre.

Der Analyst beschließt schließlich, die Sache zu überprüfen. Er geht auf deine Website und sucht nach Beweisen für all die Dinge, von denen du ihm erzählt hast. Sie haben erwartet, dass sie diese Informationen, diese Energie, diese... Stimmung bestätigen.

Aber das haben sie nicht. Ihr Erlebnis fiel flach. Sie gaben dir eine 20-minütige Chance, klickten dann aber weg und sahen nicht mehr zurück.

Klar, du hattest Pläne. Du hattest vor, diesen Teil der Website zu überarbeiten, und du hattest Gary davon erzählt, kurz bevor er in den Urlaub fuhr. Du hast Gerüchte gehört, dass daran gearbeitet wurde und dass einige Inhalte geändert wurden, aber du hast es nie gesehen und hattest nie die Möglichkeit, es zu begleiten. Die Entwicklung der Inhalte fand scheinbar irgendwo in einem fernen Land statt. Wenn sich etwas auf der Website änderte, warst du normalerweise genauso überrascht wie alle anderen.

Das ist ein inhaltlicher Fehler. Die ganze Sache. Ein großer Fehler.

Warum kategorisieren wir nicht so? Warum nennen wir es nicht so, wie es ist?

Vielleicht, weil es nicht... binär ist? Bei Code funktionieren die Dinge oft entweder, oder sie explodieren spektakulär, so dass wir uns zurücklehnen und getrost sagen können: "Ja, das ist kaputt".

Aber bei Inhalten gibt es ein Spektrum - eine Bandbreite. Die Leute können sich das ansehen und sagen: "Ja, das ist gut", auch wenn es nicht gut ist.

Die einzige Lösung ist hier ein Prozess. Du brauchst einen Weg, um sicherzustellen, dass die Inhalte von den richtigen Leuten zur richtigen Zeit gesehen werden und dass sie den richtigen Input widerspiegeln.

Das passiert bei Code die ganze Zeit. Wir gehen mit Code genau, streng und mit der gebotenen Sorgfalt um.

Das müssen wir auch für Inhalte fordern. Und wir müssen uns eingestehen, dass schlechte Inhalte ein Fehler im Prozess, in der Planung und in den Werkzeugen sind.

Die Werkzeuge, um dies zu vermeiden, sind vorhanden. Wir müssen sie einführen und nutzen.

Wenn du wissen willst, wie die Optimizely Content Marketing Plattform deinen Content-Erstellungsprozess besser unterstützen kann, schau dir dieses kurze Video an.