Review - Aufbau, Ablauf, Tipps & Vorlagen | Consulting LIFE (2024)

AlsAnalyst,ProduktverantwortlicheroderWissensarbeiterbzw. derenBeraterbist Du mit folgenden Fragen konfrontiert:

• Wie stellen wir die vereinbarte Qualität eines (Zwischen-)Ergebnisses sicher?
• Auf welche Weise schaffen wir bzgl. einem Sachverhalt ein einheitliches Verständnis?
• Was schützt uns vor Betriebsblindheit bei der Anfertigung von Dingen?

Unterstützung findest Du im Review und dem resultierenden Review-Protokoll.

Ergebnis:Ergebnisqualität verbessert und gemeinsames Verständnis erzeugt

Teilnehmer:mind. 2 Personen (Entwickler, Reviewer)

Dauer:ab 5 Minuten (Vorbereitung), ab 15 Minuten (Review), ab 15 Minuten (Nachbereitung)

Utensilien:Notebook & Office Software (je nach Ergebnis)

Zweck

Mit einem Review prüfst Du Eigenschaften und Fähigkeiten eines (Zwischen-)Ergebnisses. Das kann ein Dokument, eine Präsentationsunterlage, ein Programmcodeabschnitt, ein Prozess oder ein anderes materielles oder immaterielles Artefakt sein. Das Review identifiziert Abweichungen zwischen Ist- und Soll-Stand, sichert damit die Qualität.

Zudem transferierst Du mit einem Review implizit Wissen. Der Reviewer wird eingebunden und lernt das Ergebnis kennen. In Konsequenz entsteht ein gemeinsames Verständnis. Darüber hinaus können während des Review-Prozesses neue Ideen und Impulse entstehen, die das Ergebnis verbessern.

Last but not Least sind Review teilweise rechtlich gefordert. So verlangen beispielsweise ISO-Zertifizierung die regelmäßige Prüfung von Linienabläufen bzw. Projektresultaten. Nur bei erfolgreichen Review wird das Ergebnis freigegeben.

Synonyme für ein Review sind Prüfung, Kontrolle, Begutachtung, Stellungnahme, Walkthrough und Inspektion oder Wortkombinationen wie Peer-Review, Prozess-Review oder Freigabe-Review.

Aufbau

Konzept – „Was sollte vor Review-Beginn definiert sein?“

Entwickle zunächst das Konzept eines Reviews :

• Ziele – Was soll mit dem Review erreicht werden (z.B. Fehlerkorrektur, Verständniserzeugung)?
• Ergebnisse – Wo sollen Fehler festgehalten werden (z.B. direkt am Ergebnis, separates Review-Protokoll)?
• Schwerpunkte – Worauf soll sich der Reviewer konzentrieren (z.B. Rechtschreibung, Inhalt, Darstellung)?
• Zeitpunkt – Soll das Review vor oder nach Veröffentlichung des Ergebnisses erfolgen (z.B. während Erstellung, vor Abgabe oder nach Abgabe eines Programmcodes).
• Dauer – Wie viel Zeit ist für Finden und Korrigieren von Fehlern vorgesehen? Bis wann sollen das Review spätestens zurückgesendet werden?
• Teilnehmer – Wer soll das Review inhaltlich bzw. organisatorisch begleiten (z.B. interner ein Entwickler, ein extern einbestellter Auditor)?
• Tools – Über welche Medium werden Fragen und Antworten ausgetauscht (Stift & Papier, Web Tool)?

Typen – „Welche Arten von Review gibt es?“

Je nach Konzept kommt lässt sich ein Review mehr oder weniger formal ausgestalten:

• Bei der Stellungnahme (auch Peer-Review, 4-Augen-Prüfung) übergibst Du als Entwickler Dein Ergebnis an einen Reviewer. Dieser hebt nach eigener Lektüre Fehler und offene Punkte in der Unterlage hervor.
• Im Rahmen eines Walkthroughs (auch Demonstration) stellst Du das Ergebnis dem Reviewer vor. Die identifizierten Mängel diskutiert ihr, zeitgleich notierst Du Verbesserungen.
• Für eine Inspektion (auch Freigabe-Review) bereitest Du einen Prüfungstermin vor. In diesem präsentierst Du das Ergebnis dem Reviewer. Schwächen und Korrekturmaßnahmen hältst Du auf einer Fehlerliste fest, welche am Schluss vom Reviewer abgezeichnet wird.

In der Praxis wird üblicherweise nur die Stellungnahme als Review bezeichnet, tatsächlich fallen jedoch alle drei Typen unter diesen Oberbegriff.

Rollen – „Wer übernimmt bei einem Review welche Funktion?“

In der Grundform sind bei einem Review zwei Rollen aktiv:

• Entwickler – Als Entwickler (auch Autor) erstellst Du das Ergebnis, erläuterst es, beantwortest Rückfragen und arbeitest Korrekturen ein.
• Reviewer – Als Reviewer (auch Gutachter) prüfst Du das Ergebnis hinsichtlich der Qualitätskriterien. Gefundene Fehler markiert er in der Unterlage und erklärt sie bei Bedarf dem Entwickler mit.

Du kannst beide Rollen übernehmen, gleichzeitig also Entwickler und Reviewer sein. Empfehlenswert ist jedoch eine personelle Trennung. Ein am Entstehungsprozess unbeteiligter Reviewer wirft einen frischen Blick auf das Ergebnis und geht unvoreingenommen an die Prüfung.

Je nach Formalität des Reviews sind weitere Rollen wie Organisator, Moderator, Schriftführer oder gar Präsentator möglich. Je nach Prüfungsgegenstand und notwendige Fachexpertise sind mehrere (fachlich komplementäre) Reviewer sinnvoll.

Anwendung

Führe ein Review geplant oder adhoc durch. In der Rolle des Entwicklers und Organisators gehst Du wie folgt vor:

1. Konzept definieren

Lege zunächst die Ziele des Reviews fest.

• Geht es um die Abnahme eines zentralen Liefergegenstands?
• Soll das Wissen im Entwicklungsteam auf breitere Schultern gelegt werden?

Plane dann den Ablauf.

• Wann soll das Review begonnen werden?
• Wie viel Zeit bleibt zur Fehlerfindung?
• Wie lange wird für die Korrektur benötigt?

Gehe dabei vom Zieldatum aus, also den Zeitpunkt, zu das Ergebnis geprüft und korrigiert vorliegen sollen.

Wähle schließlich den Reviewer aus und weise in Prozess und Ergebnis ein.

• Muss es ein Fachexperte mit Spezialkenntnisse sein?
• Oder reicht der Praktikant für die Prüfung nach Grammatik- & Orthographieschwächen?

2. Fehler suchen

Lasse den Reviewer Dein Ergebnis begutachten sowie dabei Fehler identifizieren und dokumentieren. Trennt dabei bewusst zwischen Fehlersuche und Fehlerkorrektur als ein bewährtes Prinzip der Qualitätssicherung. Danke dem Reviewer für seine Prüfung und die eingesetzte Zeit.

3. Fehler korrigieren

Korrigiere die aufgedeckten Fehler. Achte darauf, dass dabei keine neuen Fehler entstehen. Prüfe zudem, ob es sich um vermeintliche Fehler handelt, also Aspekte, die sich bei näherer Betrachtung als fehlerfrei herausstellen.

Ein Review ist immer eine Momentaufnahme. Ein einmal verbessertes Ergebnis ist keine Garantie für ein dauerhaftes Optimum. Veranlasse erneut ein Review, insbesondere beim einem langen Entwicklungsprojekt, einem dynamischen Ergebnis sowie einem hohem Wissenszugewinn.

Beispiele

Paarprogrammierung von Software Code

Eine besondere Form des Reviews findet bei der Paarprogrammierung statt. Dabei entwickelt eine Person den Code, die Zweite denkt über das Problem nach und reviewt simultan das Ergebnis. Regelmäßig tauscht das Entwickler-Tandem die Rollen.

AgileAcedemyAus: Agile in Practice – Pair Programming (3 min) – Bei der Paarprogrammierung finden Ergebniserstellung und -review zeitgleich statt

Reviews im Consulting

Die Unternehmensberatung bietet vielfache Möglichkeiten der Anfertigung eines Reviews. In folgenden Situationen bitte ich regelmäßig einen Firmenkollegen bzw. Geschäftspartner um ein Review.

• Prüfung der Bewerbungsunterlagen für die Stelle eines Unternehmensberaters
• Finaler Check eines Beratungsangebots vor Übergabe an den Kunden
• Kontrolle einer Steuerkreispräsentation vor Versand an die Teilnehmer
• Gegenlesen eines Blogbeitrags nach Veröffentlichung auf der Webseite

Vor- & Nachteile

Pro

• Ein Review schützt vor Betriebsblindheit. Es öffnet den Blick für fehlerhafte, überflüssige oder mögliche zusätzliche Aspekte am Ergebnis.
• Auch verbessert ein Review (in der Regel) das Ergebnis. Das Risiko teurer Folgefehler in nachfolgenden Entwicklungsschritten wird reduziert oder ganz vermieden.
• Der Prozess des Reviewens schafft ein gemeinsames Verständnis. Entwickler und Reviewer entwickeln eine einheitliche Sicht auf das Ergebnis. Das Gemeinschaftsgefühl wird gestärkt.

Contra

• Ein Review benötigt Zeit. Die Prüfung muss vorbereitet und durchgeführt, das Ergebnis im Nachgang nachgebessert werden. Auch besteht eine direkte Abhängigkeit zu einer zweiten Person. Die Auslieferung des Ergebnis wird verzögert.
• Die Durchführung des Reviews bindet neben dem Entwickler eine zusätzliche fachkundige Person. Nicht immer steht diese zur Verfügung bzw. verfügt über ausreichend Zeit für eine sorgfältige Prüfung.
• Insbesondere bei Wiederholungs-Review kann Langeweile und Eintönigkeit aufgekommen. Das Ergebnis ist bekannt, die zusätzliche Wertsteigerung durch die Prüfung hält sich in Grenzen. Disziplin ist erforderlich.

Praxistipps

Tipp 1 – Ergebnis perspektivenbasiert begutachten

Prüfe ein Ergebnis aus unterschiedlichen Blickwinkeln mit verschiedenen Schwerpunkten.

• Typische Perspektiven sind Funktionen (z.B. Einkauf, Marketing, Produktion) oder Rollen (z.B. Nutzer, Administrator, Entwickler)
• Typische Schwerpunkte sind Inhalt (z.B. Konsistenz, Vollständigkeit) und Darstellung (z.B. Layout, Design)

In Disziplinen wie das Rechtswesen oder die Softwareentwicklung hat sich eine multiperspektivische Betrachtung bewährt.

Tipp 2 – Ergebnis in den Vordergrund stellen

Mit einem Review bewertest Du ein Ergebnis, nie die Menschen dahinter. Überträgst Du gefundene Mängel auf den verantwortlichen Entwickler, kann das als persönlicher Angriff interpretiert werden. Beziehe Deine Verbesserungsvorschläge daher immer auf das Ergebnis bzw. den zu Grunde liegenden Erstellungsprozess.

Tipp 3 – Checkliste für Standard-Review aufsetzen

Erstelle für wiederkehrende Reviewaufgaben eineCheckliste. Diese erleichtert die Fehlersuche, vereinheitlich den Ablauf und sorgt dafür keine Prüfpunkte zu vergessen. Zudem kann das Review (anteilig) an einen Dritten übergeben werden.

Klebe beim Review jedoch nicht ausschließlich nur an der Checkliste. In der Wissensarbeit sind Ergebnisse oft einmalig. Betrachte den Kontext und beziehe Sonderfaktoren in Deine Prüfung ein.

Tipp 4 – Bestehende Review-Struktur erfragen

Ob Finanzinstitut, Entwicklungsdienstleister oder Wirtschaftsprüfer – viele Unternehmen besitzen bereits eine etablierte Review-Struktur. Diese regelt, wann, wer, womit, was wie lange und unter welchen Bedingungen reviewet.

Erfrage diese bestehenden Prüfungsgepflogenheiten, bevor Du ein neues Review-Vorgehen etablierst.

Tipp 5 – Review extern anfertigen lassen

Ein unternehmensinterner Reviewer ist einfach zu organisieren und zu koordinieren. Ganz unabhängig prüft dieser jedoch nicht, schließlich steht er zu Dir als Entwickler in kollegialer bzw. gar freundschaftlicher Verbindung.

Für hochwertige Ergebnisse, aufgrund Zeitmangel oder wegen gesetzlicher Anforderungen kann es erforderliche sein, einen externen Reviewer hinzuzuziehen. Dieser arbeitet ohne den zwischenmenschlichen Druck einer Kollegenbeziehung parallel zum Tagesgeschäft. Dafür steigt Dein Organisations- und Koordinationsaufwand bzw. schlagen nun Zusatzkosten zu Buche.

Tipp 6 – Rechtschreibfehler unmittelbar korrigieren

Bitte den Reviewer Fehler der Rechtschreibung und Grammatik direkt im Ergebnis zu dokumentieren. Eine Diskussion über Kommasetzung und Groß- und Kleinschreibung ist im Deutschunterricht sinnvoll, verursacht im Geschäftsleben jedoch nur unnötige Zusatzaufwände.

Aktuelle Office Software bietet eine Nachverfolgungsfunktion, so dass Du aus den korrigierten Sprachmängeln weiterhin lernen kannst.

Ursprung

Der Ursprung der Methode ist mir nicht bekannt. Gerne Deine Hinweise perE-Mailan mich.

Bonusmaterial

libncsu: Peer Review in 3 Minutes (3 min) – der Review-Prozess für wissenschaftliche Beiträge

• Wikipedia: Peer-Review – ausführlicher Beitrag zur Prüfung von Dokumenten durch einen Reviewer aus gleichem Fachgebiet
• Maik Pfingsten: Geheimwaffe Reviews (18,5 min) – Podcast über Zweck, Arten und Vorteilen eines Reviews.