Eher zufällig bin ich auf den Begriff 360-Grad-Feedback gestoßen. Wikipedia beschreibt es als Methode zur Einschätzung der Kompetenzen und Leistungen von Fach- und Führungskräften aus unterschiedlichen Perspektiven wie zum Beispiel aus dem Blickwinkel der Mitarbeiter, der Vorgesetzten, der Kollegen, Teammitglieder oder Kunden. Die größere Objektivität dieser Methode kommt dadurch zustande, dass eine Person sich selbst bewertet (Selbstbild) und gleichzeitig aus verschiedenen Perspektiven beobachtet und eingeschätzt wird (Fremdbilder).

Die Idee einer umfassenden Betrachtung und Bewertung einer Person lässt sich als Maßnahme für kontinuierliche Verbesserung auch auf ein unpersönliches Objekt wie eine Produktdokumentation übertragen. Die Ziele der Maßnahme sind sehr ähnlich. Der Prüfgegenstand ist eine Leistung, die in einem teilweise kreativen, auf jeden Fall aber systematischen Vorgang erbracht wird. Autoren nutzen ihr spezifisches Wissen, um ein Produkt richtig, vollständig und angemessen in einem Wiki zu beschreiben (Selbstbild). Leser aus mehreren Zielgruppen interessieren sich aus unterschiedlichen Gründen für dieses Produktwissen. Beim Lesen der Seiten im Wiki können sie dem Autor jederzeit und sehr einfach zielgerichtetes Feedback in Form von Kommentaren geben (Fremdbilder). Die Betroffenheit einer interessierten Person ist geklärt durch den Einsatz von Bausteinen, die genau einen Zweck erfüllen, in einer fixen Struktur mit den Bereichen Systembeschreibung, Systemstruktur und Architekturdefinition. Leser wissen immer, was sie von einer Seite im Wiki erwarten können. Und sie kennen den Autor.

Eine Produktdokumentation beschreibt ein Produkt. Wie gut sie das macht, ist nicht leicht zu beantworten. Qualitätsmerkmale wie Richtigkeit, Vollständigkeit, Übersichtlichkeit und Verständlichkeit werden in den Zielgruppen unterschiedlich wahrgenommen. Die Zielgruppen haben außerdem unterschiedliche Bedürfnisse und Erwartungen.

Die Zielgruppe Auftraggeber umfasst interessierte Parteien mit einem strategischen oder wirtschaftlichen Interesse am Produkt. Ein Auftraggeber muss auch finanzielle Aspekte beachten. Eine Fachabteilung will mit dem Produkt wirtschaftlich erfolgreich sein.

In der Zielgruppe Macher versammeln sich alle Personen, die einen Beitrag zur Entwicklung des Produktes leisten. Produktverantwortliche, Entwickler und Tester tun das in einem Entwicklungsprozess und produzieren Code, Testfälle und Dokumentation.

Die Zielgrupper Betreiber ist verantwortlich für den kundenwirksamen Betrieb des Produktes sind. Betreiber gliedern sich in fachliche und technische Betriebsführung. Die Idee der DevOps löst einige der Grenzen zwischen den Zielgruppen Macher und Betreiber auf.

Die Nutzer sind schließlich jene Zielgruppe, die das Produkt verwenden und in der Regel mit Hilfe des Produktes die wirtschaftlichen Ziele des Unternehmens erreichen wollen.

Die Betroffenheit einer Person von einer Sache lässt sich sehr schön durch die Fabel vom Huhn (english: chicken) und vom Schwein (englisch: pig) erklären, Eine Partei ist beteiligt (englisch: committed), die andere interessiert (englisch: involved).

The Chicken says: « Hey Pig, I was thinking we should open a restaurant! »
Pig replies: « Hm, maybe, what would we call it? »
The Chicken responds: « How about 'ham-n-eggs'? »
The Pig thinks for a moment and says: « No thanks. I'd be committed, but you'd only be involved. »

Beteiligt sein bedeutet, von einer Sache überzeugt zu sein, sich persönlich dafür einzusetzen, etwas zu tun. Interessiert sein hingegen bedeutet, sich lediglich mit einer Sache zu befassen. Agile Entwicklung mit Scrum verstärkt die Bedeutung beteiligter Personen und schützt sie vor dem negativen Einfluß interessierter Parteien. Feedback zum Produkt wollen wir aber von allen Zielgruppen, ohne Einschränkung und immer wertschätzend.

Für CARDS+ ist ein Wiki eine Systemvoraussetzung. Confluence ist weit verbreitet, gilt als ausgereiftes Wiki und erfüllt alle Anforderungen von CARDS+. Die Verantwortung für den Inhalt jeder Seite ist klar definiert. Ein wichtiges Merkmal der Bausteine ist der vorgegebene Aufbau mit zweckgebundenen Abschnitten. Verbunden mit einer bestimmten, prüfbaren Erwartung an den Inhalt eines Bausteins schafft CARDS+ die Grundvoraussetzung, um alle Zielgruppen als Leser zu gewinnen, zumindest für einen Teil der Produktdokumentation. Motivierte oder durch Fehler oder Lücken provozierte Leser geben Autoren ihr spezifisches Feedback zum Inhalt.

Feedback wird in einem Wiki durch die Kommentarfunktion ermöglicht. Confluence bietet hier sogar drei Funktionen. Mit einem Seitenkommentar kann ein Leser Feedback zum ganzen Inhalt einer Seite geben. Ganz spezifisches und zielgerichtetes Feedback zu einem Wort, Satz oder Absatz gibt ein Leser mit einem Textkommentar. Und schließlich kann ein Leser eine Seite mit “Gefällt mir” (englisch: like) markieren, wenn nach seiner Einschätzung an der Seite nichts auszusetzen ist. Der Autor einer Seite mit Kommentaren hat die Aufgabe, das Feedback der Leser zu bewerten.

Ein Kommentar kann ein Hinweis auf einen Fehler oder eine inhaltliche Lücke in der Seite sein. Der Autor führt eine Überprüfung durch und  korrigiert gegebenenfalls den Fehler oder schließt die Lücke.

Eine konkrete Frage eines Lesers als Kommentar ist für den Autor ein Zeichen, um über den Inhalt seiner Seite nachzudenken. Die Klärung der Frage mit dem Leser kann zu einer sinnvollen Verbesserung der Seite führen. Das kann eine gemeinsam erarbeitete bildliche Darstellung zum Text oder einfach eine bessere Formulierung.

In allen Fällen entfernt der Autor den Kommentar. Mit anderen Worten: Er moderiert die Kommentare.

Ein 360-Grad-Feedback für eine Produktdokumentation bedeutet stetes Feedback aller Zielgruppen. Es ist verbunden mit einer wertschätzenden Nutzung des Feedbacks für eine kontinuierliche Verbesserung, einer Denkweise, die in kleinen Schritten die Qualität erhöht. Feedback kann nicht erzwungen werden. Es kommt von motivierten Personen. Wir brauchen daher eine Feedback-Kultur in allen Zielgruppen. Feedback kann auch provoziert werden. Macht man Wissen für alle sichtbar, dann erhöht sich die Chance, dass selbst introvertierte Personen Feedback geben, wenn sie einen Fehler entdecken. Ein agiler Entwicklungsprozess mit Scrum schließlich macht Feedback zu einer Regelaufgabe. In jedem Review werden alle Anwesenden aufgefordert, ihre Meinung, einen Verbesserungsvorschlag, Lob oder Kritik zum präsentierten Produktinkrement zu geben. In einer Retrospektive reflektiert das Scrum-Team den soeben zu Ende gegangenen Sprint. Gemeinsam diskutieren und priorisieren sie Probleme. Für die nach gemeinsamer Einschätzung wichtigsten Probleme entwickeln und beschließen sie Maßnahmen zur Verbesserung.