Die Ergebnisse, die wir als Geistesleister erstellen, existieren meist im virtuellen Raum. D.h., wir können sie nicht anfassen oder ausprobieren. Wir können zwar heutzutage mittels moderner Methoden, gewisse Aspekte automatisch prüfen lassen. Allerdings sind Reviews, an denen Menschen beteiligt sind, für unsere Arbeit enorm wirkungsvoll.
Warum das so ist und wie sie effektiv eingesetzt werden können, beschreibe ich im Artikel auf meiner Webseite näher.
In diesem Beitrag möchte ich Prozess-Reviews beschreiben. Dieser Review-Typ bzw. das Audit ist für das gesamte Entwicklungsprojekt entscheidend.
Das Prozess- oder Reifegrad-Review weist die Entwicklungsreife eines Projekts nach. Dabei geht es nicht mehr um den Inhalt der Ergebnisse, sondern um den Nachweis der zu erbringenden Arbeitsergebnisse, also zum Beispiel Spezifikationen, Planungsdokumente, Testdurchführungen etc. Als Basis dienen hier meist Prozessreifegradmodelle wie z.B. SPICE oder CMI. Weiterlesen
Für ein gelungenes Lastenheft sind Reviews meiner Erfahrung nach unerlässlich. Ich habe bereits über die allgemeinen Vorteile von Reviews und die spezielle Form der Peer Reviews berichtet. Kommen wir nun zu den Freigabe-Reviews.
Im Gegensatz zu Peer Reviews ist dieser Typ Geheimwaffe deutlich formaler. Ein Freigabe-Review wird oft in einer Gruppe von Entwicklungsingenieuren durchgeführt. Das bedeutet, sie müssen geplant, vor- und nachbereitet werden. Welche Schritte genau das beinhaltet, möchte ich im Folgenden erläutern. Weiterlesen
Ich habe bereits in anderen Beiträgen über Reviews und ihre Funktionen berichtet: Zwischenergebnisse und Prozesse absichern, Feedback erhalten, Ergebnisse freigeben – ich bezeichne Reviews nicht umsonst als Geheimwaffe.
Im Folgenden möchte ich ein bisschen tiefer in das Thema Peer Reviews einsteigen. Der Begriff kommt eigentlich aus dem wissenschaftlichen Umfeld und geht bis ins 17. Jahrhundert zurück. Das Konzept fokussiert seitdem die Begutachtung von Ergebnissen durch einen gleichwertigen Kollegen – und lässt sich bei Lastenheften natürlich ebenso gut anwenden. Weiterlesen
Hier könnt ihr den ersten und den zweiten Teil lesen!
In der vierten Phase geht es um das finale Review und die Freigabe: Mit der 0.8-Version gehen wir mit dem gesamten Projekt noch einmal in ein Peer-Review, das heißt: Alle bekommen jetzt wirklich alles.
Reviews
Vorher erhielten manche nur Ausschnitte, weil anderes für sie einfach nicht relevant war. Mit dem 0.8-Release aber gibt es nun ein einziges Dokument, das von allen noch einmal in Form des Peer-Reviews durchzugehen und zu kommentieren ist.
Häufig kommt noch sehr viel an Information und an Zusätzen zurück, daraus machen wir dann den 0.9-Release. Mit diesem gehen wir in einen moderierten Review-Workshop: Wir treffen uns alle gemeinsam vor Ort und gehen noch einmal alles durch.
Das Charmante an dieser Phase ist, dass alle den Release inhaltlich kennen und Ihre Anmerkungen schon im Vorfeld gemacht haben. Somit – und das ist meine Erfahrung wie auch meine verfolgte Strategie – ist hier schon fast alles geklärt.
Findings vs. Fehler
Die Kleinigkeiten und Formulierungen, die noch nicht ganz perfekt sind, sind unproblematisch, denn es sind Findings bzw. Auffälligkeiten und werden natürlich auch dokumentiert – aber es sind keine Fehler.
Für diese Dokumentation setze ich eine Review-Checkliste ein, in der wir Folgendes festhalten: Was ist aufgefallen? Wie schwerwiegend schätzen wir es ein? Ist es dramatisch, also „major“, oder weniger kritisch und daher „minor“? Oder ist es einfach nur eine Rückfrage?
Dies stellt für uns die Basis zur Freigabe dar: Wenn wir keine Major-Aspekte haben, sondern nur ein paar Minor-Punkte, kann durchaus die Freigabe erfolgen. Wenn es Major-Punkte gibt, müssen diese zuvor abgestellt werden.
Bei den Minor-Findings ist es bei der Dokumentation sehr wichtig, direkt eine Empfehlung zu geben, wie diese Auffälligkeiten zu ändern sind. Denn in der Regel gehen wir nach dem moderierten Review-Workshop alle wieder zurück an unsere Arbeit – und nicht immer ist die allererste Aufgabe, diese Punkte abzustellen.
Es kann also auch ein paar Tage dauern, bis daran gearbeitet wird. Mit der Dokumentation kann aber jeder sehr gut nachvollziehen, was das Problem war und wie die Empfehlung lautete, das anzupassen.
Der 1.0-Release
Wenn all das passiert ist, also die Review-Checkliste mit allen Findings durchgegangen und alles erledigt worden ist, folgt automatisch der 1.0-Release.
Denn – und das ist das Schöne daran – wir haben jetzt eine Dokumentation, ein Lastenheft, das Review-Protokoll und die Dokumentation über die Abstellung aller Auffälligkeiten beim finalen Review auf 0.9-Basis.
ALLE haben ihr „Go“ gegeben und wir brauchen für diese 1.0-Version entsprechend keine weiteren Unterschriften. Zudem können wir mit 1.0 und dem Review-Protokoll jederzeit alles nachweisen. Das hat bei B. Braun wunderbar funktioniert, auch im offiziellen Vorstellungsmeeting mit dem obersten Top-Management.
Auf dieser Basis folgten zudem u.a. die Aufwandsschätzungen für die zukünftige Entwicklung – denn mit der Erstellung eines Lastenheftes können wir auch diese viel besser unterstützen.