Gabi und Sascha
Kategorien : Alle | Berlin | Bücher | Fotografie | Java | Linkhalde | Weichware | Verfassung

Wir haben heute eine qualifizierte Incident-Bewertung erarbeitet. Dabei haben wir bewusst auf den in der IT-Entwicklung vorherrschenden Begriff Bug verzichtet. Uns erschien der Begriff Incident aus ITIL klarer.

Ein Incident wurde von uns als jegliche Abweichung von den Anforderungen definiert. Er wird in unserem Ticket-System als eigenständige Entität definiert, neben z.B. User Story und Epic. Ein solcher Incident muss bewertet werden. Von dieser Bewertung hängt die Dringlichkeit der Bearbeitung ab.

Die 3 Incident Kategorien

Die von uns vorgeschlagene Bewertung von Incidents hat drei Ebenen. Dabei entspricht 1. der dringlichsten Kategorie und 3. der am wenigsten dringlichen Kategorie.

  1. Major Incident
  2. Defect
  3. Nonconformity

Major Incident

Ein Major Incident kann nur von einem Kunden, an den ein Produkt ausgeliefert wurde, gemeldet werden. Ein solcher Major Incident muss immer durch einen Verstoß gegen ein Service Level Agreement (SLA) oder die wesentliche Nichteinhaltung eines Produktmerkmals begründet sein. Ist ein Major Incident nicht durch ein SLA oder eine wesentliche Nichteinhaltung begründet, wird der Major Incident zu einen Defect herab gestuft. In einem solchen Fall muss dokumentiert werden, dass der Defect von einem Kunden gemeldet wurde.

Ein Major Incident löst immer eine beschleunigte Bearbeitung aus. Das heisst, ein Team muss sich unmittelbar um die Lösung des Incidents kümmern.

wesentliche Nichteinhaltung eines Produktmerkmals

Der Begriff wesentliche Nichteinhaltung eines Produktmerkmals ist noch zu unbestimmt. Der Begriff muss genauer bestimmt werden. Zum Beispiel ist bei einer Datenbankanwendung die fehlende Möglichkeit einen korrekten Datensatz ab zu speichern eine wesentliche Nichteinhaltung eines Produktmerkmals. Ebenso kann das entstehen von nicht konsistenten Datensätzen eine wesentliche Nichteinhaltung sein.

Kann hingegen eine virtuelle Maschine nicht mit z.B. einen Hauptspeicher von 4 GB gestartet werden, wohl aber mit 4,1 GB, so ist dies keine wesentliche Nichteinhaltung eines Produktmerkmals

Defect

Eine Defect (Mangel) ist jede Art von Mangel, welcher den bestimmungsgemäßen Gebrauch des Produktes einschränkt. Das Beispiel aus der virtuellen Maschine im vorhergehenden Kapitel ist ein solcher Defect.

Ein bekannter Defect für eine geplante Produktversion ist dabei immer ein sogenannter Auslieferungs- oder Release-Blocker. Grund: in Deutschland darf ein Produkt nur frei von Sach- und Rechtsmängeln ausgeliefert werden (§ 434 BGB).

Einen Release mit einem bekannten Defect auszuliefern bedarf immer einer Sonderfreigabe durch die Geschäftsführung. Schon damit der Releasemanager von Schadensersatzansprüchen geschützt wird.

Nonconformity

Eine Nonconformity beschreibt einen Fehler, der den bestimmungsgemäßen Gebrauch des Produktes nicht einschränkt. Dies können z.B. falsch geschriebene Wörter sein oder eine nicht korrekte Farbgebung. Dabei können die gegebenen Beispiele nicht pauschal angewendet werden. Bei einer Ampelanlage sind falsche Farben eine wesentliche Nichteinhaltung eines Produktmerkmals und damit ein Major Incident.

Ein Produkt kann ohne Sonderfreigabe durch die Geschäftsführung freigegeben werden, wenn es noch nicht frei von Nonconformities ist.

Externe Indicent-Meldungen

Incident-Meldungen, die nicht von Mitarbeitern der Organisation gemeldet werden, müssen als external incident gekennzeichnet werden. Dies ist bei einem Major Incident impliziet der Fall. Bei einem Major Incident, welcher in einen Defect umgewandelt wird, muss die Markierung automatisch eingefügt werden.

Für "external incidents" gilt, das immer eine Root-Cause-Analyse über die technische und organisatorische Ebene durchgeführt werden muss. Aus dieser Analyse werden dann Massnahmen zur zukünftigen Fehlervermeidung abgeleitet.

Schlussbetrachtung

Ich denke, dass dieses Modell einer Incidentbewertung einigermassen stimmig ist. Unzufrieden bin ich noch mit dem Begriff und der Definition der "wesentlichen Nichteinhaltung eines Produktmerkmals".


Thema Major Incident (MI)

In meinen Augen ist ein MI immer an die bestehende vertragliche Regelung zum jeweiligen Kunden gebunden. So kann ein und der selbe Defect bei einem Kunden einen MI auslösen beim anderen jedoch nicht.

MI werden nicht zum Defect herabgestuft sondern das Gegenteil ist der Fall. Ein Defect kann zum MI hochgestuft werden wenn ein SLA dadurch in Gefahr ist. Somit kann es auch keinen internen MI geben. Innerhalb der Defects gibt es eine Priorisierung die es erlaubt kritische Fehler vor weniger kritischen Fehlern zu lösen. Eine MI Eskalation hingegen ist immer mit zusätzlichen Kosten und einer Störung der regulären Prozesse verbunden und darf daher nur bei Verletzung von einem SLA greifen.

Somit entfällt auch das Problem mit der Formulierung "wesentliche Nichteinhaltung eines Produktmerkmals", da diese für den MI nicht relevant ist.

Ein Kunde kann - und wird - Fehler machen und einen Defect irrtümlich als Major Incident (MI) melden. In einem solchen Fall muss es selbstverständlich möglich sein einen MI in einen Defect herab zu stufen. Vielleicht sogar auf ein Nonconformity.

Wenn davon ausgegangen werden kann, dass ein Defect zu einem MI hochgestuft werden kann, weil z.B. ein SLA in Gefahr ist, dann können MIs auch von intern, nicht vom Kunden, ausgelöst werden. Beipielsweise ist es möglich durch einen internen Codereview einen schwerwiegenden Fehler zu finden. Oder erweiterte Tests zeigen, dass es durch bestimmte Konstellationen in der Anwendung zu Gefährdungen bei SLAs kommen kann. Dann muss schon aus Eigenschutz ein Defect zu einem Major Incident hochgestuft werden.

Bei der wesentliche Nichteinhaltung eines Produktmerkmals geht es um zugesicherte Funktionalitäten des Produktes, die über die allgemeine Produktbeschreibung dokumentiert ist. Diese ist Teil des Vertrages. Ebenso wie ein SLA Teil des Vertrages ist. Der SLA erweitert aber meistens nur die allgemeine Produktbeschreibung. Passiert es nun aber, dass ein Kunde keinen SLA erworben hat und die Software trotzdem einsetzt und die Software nicht arbeitet, weil z.B. das Schreiben in die Datenbank aufgrund eines Softwarefehlers nicht funktioniert, dann ist dem Kunden nicht damit geholfen, dass er nur einen Defect melden kann mit dem nächsten Update eine Fehlerbehebung bekommt. Solang steht vielleicht sein Geschäftsprozess und er verliert minütlich Geld. Wird der Kund so behandelt, hat die Unternehmung ihn nicht lange als Kunden :-)

In dem von dir beschriebenen Fall würde der gemeldete Defect (da keine SLA hinterlegt ist) eventuell zu einem Major Incident herauf gestuft werden. Eventuell deswhalb, weil das Problem vom bearbeiter als solches erkannt werden muss und dies in einer angemessenen Zeit. Ist dies nicht der Fall, hat der Kunde ein grosses Problem, welches schnell zu einem Problem des anbietenden Unternehmens werden kann.