Aus der Praxis für die Praxis: Der System Footprint in der Anwendung

Im folgenden Beitrag möchte ich Euch ein paar praktische Tipps für die tatsächliche Verwendung des System Footprint 4.0 und dem dazu nötigen Material geben.

Poster oder Beamer-Bild

Die Vorlage zum System Footprint 4.0 findet Ihr in der Online-Bibliothek, dort könnt Ihr sie einfach herunterladen.

Wenn Ihr die Canvas ausdruckt, verwendet ruhig einen DIN-A0-Ausdruck. Das mag zunächst riesig klingen, aber es verschafft Euch eine sehr effektive Übersicht und zudem genug Raum, um Eure Inhalte auch wirklich unterzubringen. Dafür braucht Ihr nur eine passende Wand.

Alternativ könnt Ihr auch einen Beamer verwenden und den System Footprint als pdf-Datei an die Wand projizieren. Die Post-its bzw. Sticky Notes (siehe weiter unten) heftet Ihr dann einfach an die Wand in die „virtuellen“, nur visualisierten Felder.

Bei dem Posterdruck liegt der Vorteil darin, dass Ihr das Ganze nach Beendigung einfach zusammenrollen und mitnehmen könnt – der erste Dokumentationsschritt ist sozusagen inklusive und den Rest könnt Ihr später erledigen.

Bei der Arbeit mit dem Beamer müsst Ihr unbedingt daran denken, Fotos von Eurem Footprint zu erstellen, da Ihr nach Beendigung des Workshops oder Meetings die Projektion beendet und die Zettel abnehmt.

Fotos können manchmal zu einem Problem werden, das wissen alle, die mit Geheimhaltungsregeln in Entwicklungszentren und ähnlichen Institutionen oder Projekten gearbeitet haben. Klärt dies im Vorfeld oder verwendet im Zweifelsfall das ausgedruckte Poster, um auf der sicheren Seite zu sein.

Zettelwirtschaft mit System

Für die Befüllung bietet es sich extrem an, Klebezettel – bekannter als Post-its – zu nehmen. Mein Durchsatz bei System-Footprint-Workshops wie auch bei meinen Moderationstätigkeiten ist extrem hoch, aber mit diesen kleinen Zetteln kann ich wunderbar flexibel arbeiten:

Einfach einen nehmen, etwas draufschreiben, drankleben, fertig. Umpositionieren, inhaltlich auffüllen, übereinander kleben, abnehmen – all das funktioniert einfach und schnell und ist besonders für die Arbeit in Teams sehr wertvoll: Bei Diskussionen und Klärungen von Problemen müssen die Materialien flexibel bleiben.

Es gibt eine feine „Premium-Variante“ der klassischen Post-its mit den Klebestreifen oben auf der Rückseite: Die sogenannten „Sticky Notes“ sind Zettel, die nicht mit Kleber haften, sondern sich dank ihrer statischen Aufladung an diverse Untergründe wie z.B. Fenster, Wände etc. binden.

Das sind sehr coole kleine Dinger, die natürlich auch leicht wieder zu entfernen sind. Diese „Statty Notes“ sind kein Massenprodukt und etwas teurer als die üblichen Post-its, aber ich kann sie dennoch nur empfehlen. Hier könnt Ihr sie finden: www.stattys.com

Sie halten wesentlich besser auf unterschiedlichen Untergründen als Post-its – und nichts ist ärgerlicher, als wenn die Zettel plötzlich nicht mehr an ihrem Platz bleiben, sondern alle herunterpurzeln, weil die Oberfläche für Kleber nicht geeignet oder es zu warm geworden ist.

Stifte mit Reichweite

Ebenso solltet Ihr die Vorteile guter Stifte nicht unterschätzen – und diese müssen überhaupt nicht teuer sein. Ich nutze klassische Filzstifte (wie meine Kinder), die es außerdem noch häufig im Angebot gibt. Die haben eine dünne und eine dickere Spitze an je einem Ende und können also multifunktional eingesetzt werden.

Verwendet bitte keine Bleistifte, Kugelschreiber oder ähnliches, das funktioniert alles nicht, wenn mehr als zwei Leute das Ganze auch wirklich lesen können sollen. Erspart Euch den Ärger und den Frust der ewigen Nachfragen und nutzt die Filzstifte.

Im nächsten Beitrag gebe ich einige weitere Tipps zur Anwendung und Befüllung des System Footprints.

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.

Die erste deutsche Online-Bibliothek zum Thema Lastenhefte

Der Blog „Agile Lastenhefte“ eröffnet seine Online-Bibliothek mit Templates, Lernvideos, Tutorials und vielem mehr

Templates und Checklisten sind und bleiben heißbegehrte Werkzeuge. Ob für einen Startpunkt, für den Abschluss – oder für Probleme mittendrin: Sie schaffen den nötigen Überblick, bilden Strukturen ab und ermöglichen sinnvolle Deadlines für Lastenhefte.

Weiterlesen

Der System Footprint – Aufbau und Inhalt

Im letzten Beitrag habe ich die Entwicklungsgeschichte des System Footprints beschrieben. Nun möchte ich mehr in die Tiefe gehen und erläutern, wie das Ganze funktioniert. Zunächst gehe ich im Detail darauf ein, wie der System Footprint aufgebaut ist.

User- und Use-Cases & die Value-Proposition

Im Grunde kann man sich das Ganze als großes Poster vorstellen, welches in mehrere Kästchen aufgeteilt ist, die – ähnlich wie Puzzlestücke – ineinanderpassen.

Auf der rechten Seite des System Footprints platziere ich den Kunden bzw. den Benutzer, der das System hinterher verwendet. In der Mitte findet sich die Value-Proposition, also das Nutzenversprechen, der Grund dafür, dass der Kunde dieses System überhaupt kauft.

Die Value-Proposition sollte unbedingt klar definiert und verstanden werden, denn so können wir später im Requirements Engineering unproblematischer entscheiden, ob eine Anforderung notwendig bzw. wie nützlich sie ist. Manchmal gibt es auch Anforderungen, die einen Nutzen zerstören können. Kenne ich die Value-Proposition eines Systems, kann ich auch hier besser entscheiden, ob diese Anforderung tatsächlich kontraproduktiv ist.

Dieses Nutzenversprechen transportieren wir über zwei Wege zum Kunden: Über die Nutzungsfälle und über die Liefereinheiten. Bei ersterem sind die Key-Use-Cases gemeint, also die Einsatzfälle des Systems. Bei den Liefereinheiten kann es sich entweder um einen ABC-Musterstand handeln oder um Ausprägungen in Basis-, Mittel- und Premium-Varianten.

Beide platzieren wir rechts von der Mitte. Diese beiden Wege sind allein für das Grundverständnis sehr wichtig, denn darüber schafft ein System den essentiellen Wert für den Kunden.

Key Features, Key Components und Schnittstellen

Im mittleren Teil auf der linken Seite des System Footprints setzen wir zwei Aspekte, die den Nutzen erzeugen können: Zum einen die Key-Features bzw. die Hauptfunktionalitäten, die auch in Use-Cases sichtbar werden, und zum anderen die Key Components, also die Hauptkomponenten des Systems. Diese können mechanische, elektronische oder auch Software-Komponenten sein, in denen die Key Features ja häufig verhaftet werden.

Nichtsdestotrotz ist das keine architektonische Vorgabe. Vielmehr ist es oft so, dass es neue Features gibt – schließlich handelt es sich häufig um Entwicklungsprojekte, die noch nicht zwingend ein eigenes Key Component als „Zuhause“ finden.

Dennoch ist diese Trennung wichtig, weil wir aus den Key-Components ja auch die Key-Liefereinheiten, die Key Deliverables darstellen können. Wir können also sagen: „Okay, hier gibt es diesen ABC-Musterstand und da werden diese Key-Components und diese Features einfließen.“

Gleichzeitig kann es diese Ausprägungen für den Markt geben – beispielsweise Basis, Medium, Premium oder Ähnliches -, hierbei sind die Komponenten ebenso notwendig.

Links neben diesem linken Mittelteil finden wir schließlich die Interfaces – also die Schnittstellen des Systems. In jedem Workshop machen wir auch eine große Systemabgrenzung und definieren, was drin und was draußen ist.

Dies ist einer der Schritte, die häufig vergessen werden. Ich kann hier nur nochmals bekräftigen, wie wichtig diese Abgrenzung des Systems und die dazugehörigen Schnittstellen sind.

Der System Footprint im Feinschliff

Das Besondere an diesen Teilen ist, dass wir von links nach rechts quasi einen Wertstrom erstellen: Wir schaffen die Value-Proposition über die Use-Cases und die Liefereinheiten an den Kunden, während wir gleichzeitig dieses Nutzerversprechen über die Schnittstellen, die Features und die Components, also die Funktionen und die Komponenten, erzeugen.

In der Fortentwicklung des System Footprints habe ich die Dimensionen hierbei ein wenig angepasst und die Value-Proposition verkleinert, sodass ich maximal vier Post-Its einfügen kann. In der alten Form war die Value-Proposition in der Mitte ein ziemlich großer Bereich, mit dem die Verlockung wuchs, hier sehr viele Post-Ist einzufügen. Meine Erfahrung über die Jahre ist jedoch, dass zwei, drei Value-Propositions im Kern die beschreibenden Inhalte für ein System abbilden können.

Dies hat zwar die Diskussion um die Value-Proposition noch mal deutlich verschärft, weil ich keinen fünften Post-It zulasse, aber meine Gegenfrage lautet dann: „Wie viele echte KERN-Nutzenversprechen kann es denn realistisch geben?“ Weniger ist auch in diesem Fall mehr.

 

Der System Footprint – Entwicklung und Einsatz

In diesem Beitrag möchte ich den System Footprint als strukturierte Systemvisualisierung diskutieren. Denn obwohl dieser Überblick enorm wertvoll und effektiv ist, wird er oft unterschätzt. Weiterlesen

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

Prozess-Reviews

In diesem Beitrag möchte ich Prozess-Reviews beschreiben. Dieser Review-Typ bzw. das Audit ist für das gesamte Entwicklungsprojekt entscheidend.

Das Prozess- oder Reifegrad-Review weist die Entwicklungsreife eines Projekts nach. Dabei geht es nicht mehr um den Inhalt der Ergebnisse, sondern um den Nachweis der zu erbringenden Arbeitsergebnisse, also zum Beispiel Spezifikationen, Planungsdokumente, Testdurchführungen etc. Als Basis dienen hier meist Prozessreifegradmodelle wie z.B. SPICE oder CMI. Weiterlesen

Freigabe-Reviews für Lastenhefte – Ergebnisse im Team freigeben

Für ein gelungenes Lastenheft sind Reviews meiner Erfahrung nach unerlässlich. Ich habe bereits über die allgemeinen Vorteile von Reviews und die spezielle Form der Peer Reviews berichtet. Kommen wir nun zu den Freigabe-Reviews.

Im Gegensatz zu Peer Reviews ist dieser Typ Geheimwaffe deutlich formaler. Ein Freigabe-Review wird oft in einer Gruppe von Entwicklungsingenieuren durchgeführt. Das bedeutet, sie müssen geplant, vor- und nachbereitet werden. Welche Schritte genau das beinhaltet, möchte ich im Folgenden erläutern. Weiterlesen