Beiträge

Spezifikationen: Problembewusstsein schaffen – und Lösungen finden

In diesem Beitrag möchte ich auf die Frage eingehen, wie Projekte mit dem Problem der vielen, aber kaum gelesenen Spezifikationen umgehen – und wie sie damit umgehen sollten.

Welche Spezifikationen? Oder: Duck an cover

Den ersten und häufigsten Weg nenne ich gerne „duck and cover“ nach dem amerikanischen Spruch aus dem kalten Krieg. Diese Variante liegt in zwei Ausprägungen vor.

Aus Last mach Pflicht – Variante I

Die eine Ausprägung: Man nehme sich das Lastenheft, kopiere stumpf einfach alles – und schreibe darüber „Pflichtenheft“. Das habe ich als Troubleshooter in einem Projekt gehabt und schließlich gefragt: „Wie ist eigentlich diese Systems-Requirements-Specification entstanden?“ „Die ist aus dem Lastenheft kopiert. Wir haben keine Zeit und es sind viel zu viele Anforderungen.“

Das waren in der Tat 40.000 Anforderungen. Ich bin das durchgegangen, habe das analysiert und schnell zeigte sich, dass sie damit auch alle nicht-technischen Projektanforderungen kopiert haben – inklusive einiger unsinniger Anforderungen … Damit haben sie gleichzeitig akzeptiert, was dort drinsteht – und einfach weggeschaut.

In einem anderen Fall hatte ein klassisches, mittelständisches Maschinenbau-Unternehmen ihr System entwickelt, nämlich das, was auf der technischen Zeichnung stand, das waren ja die Anforderungen.

Die Probleme mit einem Teilsystem, das im Feld Schwierigkeiten machte, waren dann groß, denn Elektronik und Software, die mit verbaut waren, hat keiner richtig betrachtet. Und es gab auch kein Lastenheft, denn niemanden interessierte das – bis ich hinzukam. Für sie war es eher überflüssiger Ballast. Sie haben sich geduckt und gehofft, dass der Sturm an ihnen vorbeizieht.

Das große Nichtstun – Variante II

Die zweite Variante sehe ich häufiger bei kleinen und mittelständischen Unternehmen: Einfach gar nichts machen.

Diesen Fall habe ich mit absolut extensiven Spezifikationen bei einem Elektromobilitäts-Projekt erlebt. In der Vorprojektphase brachte der Hersteller ein 600-Seiten starkes Dokument und sagte, dies seien die Spezifikationen.

Parallel waren damit auch viele Widersprüchlichkeit verbunden, denn in der Automobilindustrie wird heutzutage regelrecht in einem Lego-Schema gearbeitet, vieles ist also „reused“. Das ist generell ein großes Thema, weil oft einfach mehrere Bauteile zusammengesteckt werden und ein Lastenheft ergeben sollen und zwar ein extrem ausführliches – das niemand lesen will.

Da wir zudem in einem Innovations-Projekt saßen, hatte gerade mal ein gefühltes Drittel überhaupt Relevanz für uns. Die anderen zwei Drittel dieses Lastenheftes waren zwar da und wir mussten die durchgehen, aber im Grunde konnten wir das hinterher alles komplett wegkehren.

Wirklich hinschauen – die Visualisierung der Spezifikationen

Der dritte Weg, der sich nun mehr und mehr durchsetzt, ist, die Anforderungen erstmal zu visualisieren und sich ein Gesamtbild zu machen.

Ich habe als Mentor in vielen Projekten genau das gemacht: Wir haben den System Footprint aufgehängt, die unterschiedlichsten Spezialisten und auch Bereiche wie Marketing, Vertrieb, Produktmanagement etc. eingeladen und sind gemeinsam durch diesen Footprint gegangen.

Durch diese Visualisierung wird allen erstmal bewusst, was die Anforderungen an dieses gesamte System sind. Wenn ich dann eine Spezifikation lese, habe ich dieses Bild auch im Kopf. Das ist einer der großen Gewinne daran – und dass es für alle funktioniert.

In einem Projekt beispielsweise was es für das Marketing sehr wichtig. Diese Abteilung gab sehr viele Anforderungen mit hinein, doch mit dem Footprint hat das alles wunderbar funktioniert. Er wird dort mittlerweile in den ganzen Business Units eingesetzt und die Unternehmensführung weiß, dass es für sie ein extrem wertvolles Mittel ist.

Es ersetzt keine Spezifikationen, das ist ganz wichtig, es visualisiert diese nur. Aber dann lässt sich mit ihnen auch arbeiten.

Spezifikationen: Essentiell – und ungelesen

Warum werden Spezifikationen oft nicht gelesen? Alle wissen, dass sie essentiell sind, dennoch befinden wir uns häufig in Situationen, in denen plötzlich niemand weiß, worum es geht. Weiterlesen

Requirement Engineering für komplexe Systeme – Teil II

Im letzten Beitrag habe ich bereits zwei Probleme des Requirement Engineering in komplexen Systemen angesprochen: Fehlende Lastenhefte und die fehlende Trennung zwischen System- und Projekt-Anforderungen. Hier möchte ich zwei weitere, nicht weniger relevante Probleme diskutieren. Weiterlesen

Requirement Engineering für komplexe Systeme – Teil I

In diesem Beitrag möchte ich auf die Frage eingehen, warum Requirement Engineering für komplexe Systeme so wichtig ist. Hierfür erläutere ich zunächst die ersten großen Schwierigkeiten in solchen Situationen: Das fehlende Lastenheft und die fehlende Trennung zwischen System- und Projekt-Anforderungen. Weiterlesen

Episoden

SF004: Lastenheft erstellen – Schritt für Schritt

16.06.2015 33 Minuten

On Air in dieser Episode

avatar
Maik Pfingsten

Ein Lastenheft zu erstellen ist oft Buch mit sieben Siegeln. Ich zeige meine Vorgehensweise, um erfolgreich ein Lastenheft zu erstellen.

Während meiner über 10 Jahren Erfahrung als Troubleshooter habe ich eine sehr effektive und schnelle Vorgehensweise entwickelt, um ein Lastenheft zu erstellen. In dieser Episode gehe ich auf die einzelnen Schritte ein und gebe Tipps und Tricks weiter.

Inhalt der Episode

  1. Warum eigentlich Lastenhefte?
  2. Wie gehe ich vor, um ein Lastenheft zu erstellen?
  3. Tipps und Tricks aus der Praxis

SF003: Tipps um Schnittstellen zu beschreiben

02.06.2015 38 Minuten

On Air in dieser Episode

avatar
Maik Pfingsten

Schnittstellen sind oft der Grund für fehlerhafte Systeme. Um so wichtiger ist es, sie zu identifizieren und zu beschreiben.

Ich habe eine Hörerfrage zur Schnittstellenbeschreibung erhalten. In dieser Episode gehe ich darauf ein, wie wichtig Schnittstellen sind, wie Schnittstellen identifiziert und in einem Lastenheft beschrieben werden können. Denn fehlerhaft oder gar nicht beschriebene Schnittstellen ist einer der Hauptgründe, warum komplexe Systeme später nicht richtig funktionieren. Ich erläutere, wie Schnittstellen zu identifizieren sind, wie ich Pattern nutze, um Schnittstellen zu beschreiben und gebe meine Tipps aus der Praxis.

Inhalt der Episode

  1. Warum müssen wir uns über Schnittstellen Gedanken machen?
  2. Wie können wir Schnittstellen identifizieren?
  3. Was für Tipps und Tricks gibt es?

LH001: Der System Footprint Podcast

05.03.2015 13 Minuten

On Air in dieser Episode

avatar
Maik Pfingsten

In der Episode erfährst du, warum es den System Footprint Podcast gibt, wer ich eigentlich bin und was der Podcast für dich bringen kann.

In dieser Episode erzähle ich, warum ich den Podcast und den Blog gestartet habe. Ich berichte über die Ideen, die ich gerade umsetze und wie du davon profitieren kannst. Wenn du ein Entscheider im Technologieumfeld bist und Fragen zu Lastenheften hast, oder Hilfe brauchst, werde ich für dich eine nützliche Anlaufstelle aufbauen.

Inhalt der Episode

  1. Wer steckt hinter dem Podcast?
  2. Warum gibt es den System Footprint Podcast?
  3. Was habe ich geplant?