QPATCH-REVIEWS IM DETAIL
Was ist ein Qpatch Review?
Eine Review-Form, die Basis für stabile Entscheidungen im Produktentwicklungsprozess schafft. Denn ...
- Um entscheiden zu können braucht man Wissen
- Um in der Technik entscheiden zu können braucht man Wissen über die Zusammenhänge
- Um in komplexen technischen Aufgabenstellungen stabil entscheiden zu können braucht man Wissen über die Zusammenhänge mit ausreichender Qualität
Das ist die Aufgabe und das Ergebnis von Qpatch-Reviews.
 |
Wie im Qpatch Logo symbolisch dargestellt, fragt man aus vier verschiedenen Sichten nach Artefakten für Zusammenhänge. |
Und zwar aus der:
- Anforderungssicht
- Lösungssicht
- System- oder Randbedingungssicht
- Risikosicht
Die Fragestellungen sind je nach Sicht und Projektsituation unterschiedlich. Startet man zu Beginn eines Entwicklungsprojektes ähneln sie den Fragen einer System- oder Projekt-Footprint Sitzung. Ein paar einfache Beispielfragen:
|
|
|
|
|
|
|
|
|
|
|
|
Nach den "Quality-in-Design" Regeln werden die Artefakte aus den Antworten dokumentiert und miteinander verknüpft.
- Was haben die einzelnen Artefakte miteinander zu tun?
- Wie sind ihre Beziehung untereinander? Wer bedingt wen?
- Wieviel davon wissen wir und was wissen wir nicht?
Erst durch die qualitative Bewertung der Verknüpfungen im Projektkontext generiert das Qpatch-Review seinen Nutzen.
... zur Qpatch-Review Schritt für Schritt Anleitung
Technisches Wissen in Qpatch-Reviews
Einen stabilen Entwicklungsprozess erlebt man, wenn auf Basis fundierter Kenntnisse oder Wissen die notwendigen Entscheidungen getroffen werden können.
Fundiert sind Kenntnisse oder Wissen, wenn dieses vorhanden, nutzbar und in seiner Qualität bewertbar ist.
Vorhandenes Wissen ist gegeben ...
wenn das notwendige technische Wissen für eine Produktentwicklung explizit dokumentiert und gegliedert ist.
Lediglich implizit vorhandenes Wissen ist dagegen schwerer auffindbar, selten eindeutig und eher aus singulären Sichtweisen oder Disziplinen heraus beschrieben.
Nutzbares Wissen ist gegeben ...
wenn es verständlich beschrieben und in seiner Beziehung zum Wissenszweck, also dem Entwicklungsziel, definiert ist.
Ohne diese Beziehungen zum Projektkontext bleibt das Wissen innerhalb der jeweiligen Disziplin und ist schwer nutzbar.
Ein Flickwerk im schlechten Sinn.
Bewertetes Wissen ist gegeben ...
wenn die Art der Beziehung zum Projektkontext bekannt und die Qualität des Wissens beschrieben ist. An der Art und Vollständigkeit der Beziehungen erkennt man die offenen oder losen Stellen und neue Anknüpfungspunkte.
Technisches Wissen besitzt dann die zur jeweiligen Entscheidung geforderte Qualität, wenn die Beziehungen zum Projektziel vollständig, die Beziehungsart eindeutig und das
Nicht-Wissen, rsp. die fehlende Qualität
beschrieben und hinsichtlich der Auswirkung auf das Projektziel bewertet ist.
Auch ein Flickwerk, aber im guten Sinn.
Über Quality-in-Design (QiD) Regeln
Mit der Methode QiD werden die bekannten Zusammenhänge oder Beziehungen einer technischen Aufgabenstellung oder eines Projektes als Artefakte beschrieben, innerhalb dieses Kontextes nach definierten Regeln verknüpft und bewertet.
Die zu verknüpfenden Artefakttypen sind für die
- Anforderungssicht
- die Kundenanforderungen,
- Zulassungs- oder rechtliche Anforderungen,
- Schnittstellenanforderungen,
- Systemspezifikationen
- ...
- Lösungssicht
- Komponenten, Bauteile
- Funktionen,
- Features,
- Charakteristiken, Merkmale,
- ...
- System- oder Randbedingungssicht
- Einflüsse durch die Anwendung,
- Einflüsse durch den Kunden,
- Betriebszustände,
- Störgrössen,
- ...
- Risikosicht
- mögliche Fehlerursachen,
- potentielle Funktionsrisiken,
- die resultierenden Fehlerauswirkungen,
- ...
Es existieren sowohl innerhalb, als auch Sichten übergreifend Zusammenhänge zwischen den Artefakten.
Aus der Dichte der Zusammenhänge und der Vollständigkeit in der Verknüpfung der Zusammenhänge bemisst sich die Qualität des notwendigen Wissens.
Im Laufe des Projektes werden diese Beziehungen durch weitere Reviews ergänzt und detailliert. Man kann schliesslich nicht alles am Anfang wissen.
Damit zu jeder Projekt- oder Systemtechnischen Entscheidung das dafür notwendige Wissen in der jeweils geforderten Qualität verfügbar ist sollte man mit Qpatch-Reviews so früh wie möglich anfangen.
Um damit früh stabile Entscheidungen zu ermöglichen.
Wie dokumentiere ich Qpatch-Reviews?
Qpatch-Reviews mit QiD erfordern zuerst einmal keine zusätzliche Software und kann auf vielen Software-Lösungen abgebildet und gepflegt werden.
Die einzigen Anforderungen an die Software zur Dokumentation von Qpatch-Reviews sind dabei
- die Möglichkeit unterschiedliche Artefakt-Typen aus den jeweiligen Sichten abzubilden
- und Beziehungen zwischen den Artefakten zu ermöglichen.
Software aus den Disziplinen:
- Taskmanagement,
- Anforderungs- oder
- Technischem Risikomanagement sowie
- Systems-engineering
bieten das in der Regel.
Meine Erfahrung mit Software unterstützten Qpatch-Reviews stützt sich auf bekannte Software-Produkte aus jeder dieser Kategorien. ... mehr zu Qpatch-Reviews mit Software
Trotz der vielen Möglichkeiten empfehle ich die ersten Qpatch-Reviews nicht oder mit wenig Softwareunterstützung zu beginnen.
Das heisst: Flip-Chart oder Kartentechnik für die mutigen, das MS Office Paket mit Whiteboard und Excel oder vergleichbares geht natürlich auch.
Wenn das Projekt-Team weiss, wie Qpatch-Reviews in Ihrem Projekt aussehen sollen, muss man über die Dokumenten-Form und die unterstützende Software entscheiden.
In der Regel haben Organisationen ein Software-Produkt, dass die Qpatch-Review Anforderungen erfüllt, schon im Haus und in die Entwicklungsprozesse implementiert, so dass man hier sinnvoll andocken sollte. ... mehr zu Qpatch Software
Wie erkenne ich aus Qpatch-Reviews den sinnvollen Einsatz von Methoden?
Es ist gut zu wissen, was man nicht weiss.
Verknüpfte Zusammenhänge nach QiD-Regeln beschreiben Wissen als Voraussetzung einer Funktion oder als Ergebnis einer Validierung, Verifikation.
In Qpatch-Reviews wird durch das Verknüpfen von bestehendem Wissen zu einem Ziel auch klar, was man noch nicht weiss. Durch eine Bewertung wie "Wissen noch nicht verifiziert".
Die Menge an nicht verifiziertem Wissen gleichen Typs oder die Anzahl an nicht verifiziertem Wissen pro Artefakt, aber ungleichen Typs weisen auf eine notwendige Systematik oder Methodik hin.
Sobald beschrieben ist wo und welche Wissenslücken existieren und nach einer Bewertung des fehlenden Wissens hinsichtlich Projektrisiko, kann man den Bedarf an Methodik allgemein rsp. an einer bestimmten Methode einfach erkennen.
Feedback welcome...
Diese Website befindet sich im Aufbau. Die nächsten neuen Beiträge werden Qpatch-Review Beispiele und die englische Übersetzung sein.
Über Feedback würde ich mich sehr freuen. Bitte schreibt mir Eure Anfragen, Kritiken oder Anregungen ins Kontakt-Formular.