Drei typische Fragen zu Spezifikationen

Ich erhalte häufig drei typische Fragen, die sich immer um folgende Themen drehen:

  1. Welche Spezifikationen machen für euch wirklich Sinn?
  2. Wie können wir möglichst pragmatisch für die ISO 9001 die notwendigen F&E Unterlagen erschaffen?
  3. Wie können wir für den Entwicklungsbereich die Spezifikationen so aufbauen, dass wir sie im Projekt einfach nutzen können?

Du bist Geschäftsführer, Projektleiter oder Entwicklungsleiter in einem kleinen Unternehmen? Dann sind diese Fragen von hoher Relevanz für Dich und Dein Geschäft. Ich versuche daher, sie mal zu beantworten:

Welche Spezifikationen machen für euch wirklich Sinn?

Das Wichtigste ist ein Sammler der Anforderungen aus den verschiedenen Entwicklungsabteilungen, damit die Dokumente, Powerpoint’s, Meeting-Minutes etc. nicht mehr so verteilt herumfliegen. Ich nutze dazu den System Footprint, um die Anforderungen zu visualisieren und zu dokumentieren. Damit schaffe ich ein Lastenheft für die Entwicklungsprojekte. Ich habe in Episode #04 „The System Footprint“ darüber gesprochen.

Mittlerweile habe ich den System Footprint weiterentwickelt (und die Hörer wünschen sich ein Seminar dazu – wird es ab Januar 2013 geben), aber der Stand aus der Episode wird euch sehr helfen, Klarheit zu schaffen, außerdem, wenn Ihr eine klare Systemabgrenzung durchführt. Ich habe das in der Episode #8 „Zehn Tipps für ein effizientes Systemdesign“ beschrieben. Damit habt ihr einen ersten wichtigen Schritt getan, um für euch das System (den Lösungsraum) zu beschreiben.

Wie können wir möglichst pragmatisch für die ISO 9001 die notwendigen F&E Unterlagen erschaffen?

Ich bin kein ISO 9001 Spezialist. Aber ich denke, es ist wichtig, dass ihr eurer Entwicklungsprozess, die ihr aktuell lebt (egal wie gut oder nicht gut), dokumentiert. Eurer Entwicklungsprozess ist in Form gegossenes Firmenwissen. Damit könnt ihr euch dann weiter entwickeln. Wie ein Freund von mir immer sagt: „Viele kleine Schritte sind kein Verrat am Ziel.“
 Schaut nicht auf mögliche Prozessdoku’s von Branchen wie Automotiv oder Luft und Raumfahrt. Wir sind hier schon seit über zehn Jahren damit beschäftigt, und unsere Systeme sind extrem komplex.

Aber was vielleicht eine nützliche Grundlage für euch sein kann, ist, wie in der ISO-Norm 15504 (SPICE) der Reifegrad von Entwicklungsergebnissen (Artefakten) beschrieben ist. Hier ein Link zur ausführlichen Beschreibungen: http://www.automotivespice.com/download. Dort wird allgemein beschrieben, was wir liefern müssen, und jedes Unternehmen schafft darauf basierend seine eigene Grundlage. Den Assessoren ist es egal, wie wir die Artefakte geschaffen haben (agil oder klassisch). Hauptsache, wir können die notwendigen Dinge liefern oder erklären, warum wir sie nicht erstellen. Hört euch mal die Episode #22 „Agile Methoden, SPICE & Qualitätssicherung“ mit Christopher Kreis an. Ich kenne ihn sehr gut, und er ist echt pragmatisch.

Ausserdem hat die GfSE eine Arbeitsgruppe mit dem Titel „Moderat komplexe Systeme“ ins Leben gerufen. Die Ergebnisse dieser Arbeitgruppe sind auf der Homepage der GfSE unter Arbeitgruppen zu finden.

Wie können wir die Spezifikationen so aufbauen, dass wir sie im Projekt einfach nutzen können?

Wenn wir über Spezifikationen reden, dann ist es immer mit verschiedenen „Flugebenen“ und zwei verschiedenen Sichten verbunden. Ich habe das in den Episode #07: „Lastenheft vs Pflichtenheft“, #29: „Wie strukturiere ich ein Pflichtenheft? – Teil 1“ und #30: „Wie strukturiere ich ein Pflichtenheft? – Teil 2“ sehr intensiv besprochen. Aus der Erfahrung heraus sind aber zwei Spezifikationen entscheidend: Das Lastenheft (Problemsicht) und die System Architecture Specification (Lösungssicht). Alle anderen sind auch notwenig, aber im Zweifel können wir auch ohne sie leben (mit einer guten Begründung). Wichtig ist, dass ihr niemals die Problemsicht mit der Lösungssicht und die Lastenheft-Ebene mit der Systemebene vermischt (z.B. alles in ein Dokument kippt). Dann kommt ihr „in Teufels Küche“.

Die Spezifikationen in den verschiedenen Ebenen und Sichten zu schaffen ist kein Ding von ein paar Wochen und wirklich nicht einfach. Damit verbunden ist immer ein grundsätzlicher Wandel im Denken. Das ist eher wie die Vorbereitung auf einen Marathonlauf.

Ich begleite jetzt seit Jahren als Mentor unterschiedliche Unternehmen, und mindestens 12 Monate sind ein sehr typischer Zeitraum für die erste Umsetzung (wenn wirklich der Wille da ist, ans Ziel zu kommen). Der Wert und der wirtschaftliche Vorteil sind aber nicht zu unterschätzen. Anschließend seid ihr in der Lage, über Re-Use viel effizienter mit euren Spezifikationen umzugehen. Wir bauen im Automotiv unsere Spezifikationen „Lego-ähnlich“ zusammen und streuen die fehlenden Requirements „drüber“. Damit können wir viel mehr Zeit auf die Lösungssicht verwenden als früher, ohne Abstriche bei der Problemsicht machen zu müssen.

Und vergesst die Validierungsseite nicht! Ohne gute Spezifikationen sind die Tester nicht in der Lage, eure Ergebnisse zu qualifizieren.

Weitere Empfehlungen

Ich habe immer wieder das Thema Spezifikationen im Podcast. Einfach mal reinhören:

Ich habe für euch auch ein Tutorial online gestellt, wie Lastenhefte pragmatisch erstellen könnt:

Neu beim Zukunftsarchitekten-Podcast?

Ich habe eine eigene Seite zum Einstieg in den Podcast und die reichhaltige Sammlung an Wissen, Tipps und Tricks bereitgestellt.