In der Praxis läuft es aber immer wieder auf die selben Diskussionspunkte hinaus:
- Fehler oder "works as designed"
- Fehler oder Änderungswunsch -> Unterscheidung korrektive bzw. adaptive Wartung
- Fehler: bezahlen oder nicht.
Gerade der letzte Punkt ist strittig, da die korrektive Wartung in unserer Wartungspauschale enthalten ist. Jedoch wird eine Entwicklung erst nach Abnahme produktiv gesetzt. Der Fehler wurde also beim Test nicht festgestellt. Und wer ist nun schuld, dass es den Fehler im Produktivsystem überhaupt gibt?
Und das ist meine Antwort:
Die Probleme sind mir – als Individualsoftwarehersteller und Ziviltechniker für Informatik – gut bekannt. Also kurz mein Statement dazu:
Die Korrektheit ist der Grad, zu dem ein implementiertes Feature einer Anforderungsspezifikation entspricht. Das Problem ist, dass Anforderungen in den meisten Fällen nicht eindeutig sind (weil sie meist in Prosa und nicht mathematisch abgefasst sind; ein paar UML Grafiken helfen da auch nur ein bisschen) und daher im Nachhinein immer Interpretationsspielraum bieten – das kann nun der Hersteller für seine Zwecke ausnutzen (das ist „works as designed“). Leider ist es ebenso schwierig, eine ganz eindeutige Anforderungsspezifikation im Vorhinein („up-front“) zu liefern, daher sind neuerdings lernende Ansätze wie Scrum so populär.
Es liegt im Interesse des Herstellers, einen Fehler („korrektive Wartung“) wenn möglich als Änderungswunsch zu titulieren, um den Aufwand für die Änderung (Behebung des Fehlers oder Erweiterung der Funktionalität) bezahlt zu bekommen.
Bei meinem Projekten/Kunden halten wir es mit Fehlern – auch in Übereinstimmung mit der mir bekannten relevanten Gesetzgebung - so: Es gibt 6 Monate Gewährleistung ab der Abnahme (6 Monate weil B2B und nicht B2C), in dieser Zeit sind Fehler der Klasse 1 (betriebsverhindernd) und Klasse 2 (betriebsstörend) auf Kosten des Herstellers zu beheben. Dabei ist es auch irrelevant, ob der Fehler im Test nicht aufgefallen ist („versteckter Mangel“), selbst wenn der Kunde mitgetestet hat. Es ist dem Kunden nicht zuzumuten, alle Fehler beim Akzeptanztest aufzudecken – selbst wenn eine Mitwirkungspflicht bei der Durchführung der Tests vertraglich vereinbart ist. Bei Fehlern der Klasse 3 (Kosmetik) weisen wir unserer Kunden darauf hin, dass hier eine strenge Auslegung der Anforderungen besteht – für den Hersteller ist es schwer, wirtschaftlich zu bleiben, wenn der Kunde ab der Abnahme alle 3 Tage meldet, dass er jene Farbe und jenen Dialog gern anders gestaltet hätte. Hier wird generell der Dialog gesucht und Mediation durch den Projektleiter betrieben. Größere Änderungen in der Klasse 3 sind vom Kunden zu bezahlen.
Ist die korrektive Wartung in der Wartungspauschale enthalten, liegt also die Behebung von Fehlern beim Hersteller – hier ist eine genaue Definition von Fehlerklassen - siehe oben - zu empfehlen. Neben dem Fehlergewicht kann man z.B. auch den Fehlertyp (falsch, fehlend, überflüssig, ungenau) zur Klassifizierung heranziehen.
Ein weiteres Problem hierbei ist die Arbeitsweise in der adaptiven oder erweiternden Wartung – wenn der Kunde schlechte Anforderungsqualität „auf Zuruf“ liefert und den Entwicklungsprozess chaotisch managed, kommen wir bei der Verantwortlichkeit für Fehler im System auch ins Diskutieren.
Wie auch immer – denke ich – dass dieses Thema immer Spielraum für Diskussion bietet. Daher muss man möglichst viel Munition vorrätig haben - und eine Mediation von außen - vor allem in heiklen Fällen - kann hier auch helfen, um dem Hersteller zu zeigen, dass er nicht nur den Kunden überzeugen muss (bzw. überrumpeln kann).
Und was denkt ihr?
Euer
JWR@coopXarch.
Keine Kommentare:
Kommentar veröffentlichen