Hinderliche Verhaltensmuster in Projekten Featuritis: Merkmale, Vorbeugung und Heilung

Sie entwickeln gerade ein kleines Tool, das bestimmte Arbeiten erleichtern soll. Die dafür erforderlichen Funktionalitäten sind klar, Ihre Kollegen und Vorgesetzten haben aber darüber hinaus noch jede Menge zusätzlicher Wünsche. Vorsicht – hier besteht Featuritis-Gefahr! Die Software droht von Anforderungen überfrachtet zu werden. Die Folgen sind erhöhte Kosten, verlängerte Laufzeiten und eine schlechtere Bedienbarkeit. Christof Geißel und Matthias Strößner zeigen Ihnen, woran Sie Featuritis erkennen und wie Sie sie bekämpfen.

 

Hinderliche Verhaltensmuster in Projekten Featuritis: Merkmale, Vorbeugung und Heilung

Sie entwickeln gerade ein kleines Tool, das bestimmte Arbeiten erleichtern soll. Die dafür erforderlichen Funktionalitäten sind klar, Ihre Kollegen und Vorgesetzten haben aber darüber hinaus noch jede Menge zusätzlicher Wünsche. Vorsicht – hier besteht Featuritis-Gefahr! Die Software droht von Anforderungen überfrachtet zu werden. Die Folgen sind erhöhte Kosten, verlängerte Laufzeiten und eine schlechtere Bedienbarkeit. Christof Geißel und Matthias Strößner zeigen Ihnen, woran Sie Featuritis erkennen und wie Sie sie bekämpfen.

 

Wird ein Softwaresystem entwickelt, ist es im Idealfall darauf ausgerichtet, bestimmte Arbeiten zu erleichtern. Dafür muss es über festgelegte Funktionalitäten verfügen. Oft geschieht es aber, dass ein System mit Anforderungen überfrachtet wird und immer mehr, im Grunde unnötige Funktionalitäten erfüllen soll. Dann sprechen wir von "Featuritis". Diese ist z.B. gegeben, wenn ein Tool für die Erfassung von Urlaubstagen plötzlich auch Autoreservierungen verwalten oder zur Textverarbeitung dienen soll. Featuritis erhöht die Kosten des Projekts und verlängert seine Laufzeit. Oft werden auch Bedienbarkeit und Verständlichkeit durch die zusätzlichen Funktionalitäten schlechter, so dass die Anwender nicht mit dem Softwaresystem arbeiten möchten.

Soweit muss es nicht kommen, denn wird diese Projektkrankheit in einer frühen Projektphase behandelt, ist sie heilbar. Im Folgenden betrachten wir die Featuritis genauer und stellen einige Erkennungsmerkmale und Heilmittel vor.

Erkennungsmerkmale

Die ursprünglichen Ziele wurden aus dem Blick verloren

Mit Projekten werden bestimmte Ziele verfolgt, z.B. möchte man Innovationen entwickeln oder neue Geschäftsfelder erschließen und die dafür notwendigen Prozesse systemtechnisch unterstützen. Zu Projektbeginn sind diese Ziele in der Regel allen Projektbeteiligten klar. Im Projektverlauf werden aber oft neue Ideen und Wünsche generiert, so dass die ursprünglichen Ziele aus dem Blick geraten. Wenn die aktuellen Arbeitspakete nichts mehr mit den ursprünglichen Projektzielen zu tun haben, ist das ein deutliches Anzeichen für Featuritis. War Ihr Urlaubsplanungstool z.B. dafür gedacht, Informationen über die verfügbaren Personentage zu liefern und den Projektleitern als Planungsgrundlage zu dienen, dann sollten Sie weder an einer Exportfunktion nach Powerpoint arbeiten noch an einer individuell konfigurierbaren Eingabemaske. Um Featuritis vorzubeugen, ist es empfehlenswert, dass Sie die eigentlichen Ziele zu Beginn vollständig und präzise dokumentieren und daraus den Projektscope ableiten. In regelmäßigen Abständen können Sie dann überprüfen, ob sich Ihr Projekt noch auf dem richtigen Weg befindet. So vermeiden Sie auch, dass sich die Ziele unbemerkt ändern.

Sie müssen nicht auf Gedeih und Verderb an Ihren einmal festgelegten Zielen festhalten. Ziele dürfen sich im Projektverlauf ändern - aber nur, wenn der zusätzliche Nutzen den zusätzlichen Aufwand rechtfertigt. Und vor allem sollten Sie sich darüber bewusst sein, dass eine Zieländerung vorgenommen wird.

Die Zahl der Stakeholder steigt

Stakeholder sind alle Personen, die ein Interesse am Projekt haben oder vom Projekt betroffen sind. Dazu gehören neben der Projektleitung meist auch Fachabteilungen, die Geschäftsführung und der Betriebsrat. Es ist wichtig, dass die Stakeholder auf das Ergebnis des Projekts Einfluss nehmen und ihre Interessen durchsetzen können.

Die Zahl der Stakeholder kann während des Projekts ansteigen. Oft ist das unvermeidlich. Wenn Sie z.B. erst während der Analysephase erfahren, dass Ihr Urlaubplanungstool auch Datenschutzaspekte berücksichtigen muss, werden Sie zusätzlich entsprechende Anforderungen des Betriebsrats oder des Datenschutzbeauftragten berücksichtigen müssen. Die steigende Zahl von Stakeholdern kann aber auch ein Zeichen dafür sein, dass andere Abteilungen oder Projekte versuchen, eigene Wünsche in Ihrem Projekt zu realisieren: Erfährt beispielsweise die Personalabteilung von Ihrem Urlaubsplanungstool und möchte es ebenfalls benutzen, sind zusätzliche Funktionalitäten notwendig: Es muss dann möglich sein, auch Krankheitstage und Fehlzeiten zu verwalten und diese nach einzelnen Mitarbeitern zu filtern. Wenn noch ein oder zwei weitere Abteilungen ihre Wünsche in Ihrem Softwaresystem verwirklicht sehen möchten, entwickeln Sie bald kein Urlaubsplanungstools mehr, sondern eine Eier legende Wollmilchsau.

Legen Sie als Projektleiter deshalb fest, inwieweit bestimmte Stakeholder das Projektergebnis beeinflussen dürfen. So darf der Betriebsrat Ansprüche an den Datenschutz oder die Barrierefreiheit stellen, nicht aber zusätzliche Funktionalitäten fordern.

Sehr umfangreiche Dokumentation

Featuritis erkennt man oft am Umfang der Dokumentation. Wenn diese 2.000 Blätter füllt, seitenlange Entscheidungstabellen enthält und jedes Diagramm drei Unterdiagramme hat, ist das Kind bereits in den Brunnen gefallen. Überlegen Sie sich, ob Sie ein Urlaubsplanungstool oder eine Raumfähre entwickeln wollen und passen Sie den Dokumentationsaufwand entsprechend an.

Am besten lassen Sie es gar nicht so weit kommen, sondern beugen vor, solange die Funktionalitäten Ihres Softwaresystems noch abstrakt beschrieben werden, etwa mit System-Use Cases. Sobald die System-Use Cases definiert sind, entscheiden Sie, welche davon umgesetzt werden sollen und welche nicht. Den Anwendungsfall "Urlaubsantrag stellen" werden Sie bestimmt brauchen, den Anwendungsfall "Urlaubsantrag nach Microsoft Project exportieren" wahrscheinlich nicht. Wenn Sie bereits bei der Anforderungserhebung Extras konsequent weglassen und "Nein" sagen, vermeiden Sie diese unnötigen Features auch in der Architektur und der Implementierung und sparen sich viel Arbeit.

Täglich rennt eine neue Sau durch ihr Projekt

Nach der Analysephase wird Ihre Dokumentation noch oft geändert? Anforderungen werden ergänzt, gestrichen oder umgeschrieben oder es werden sogar ganze Anwendungsfälle nachgereicht? Auch hier kann Featuritis vorliegen, denn Änderungen am Entwurf machen das Softwaresystem in der Regel nicht einfacher, sondern komplizierter. Oft wird ein kleiner Zusatznutzen für eine Stakeholdergruppe mit schlechterer Bedien- und…

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
0 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 1
Kommentare 0