Nach langen Jahren der Entwicklung und Erweiterungen der infra-struktur Software, wollen wir in diesem Bereich für die Zukunft unsere Wege noch klarer definieren und transparenter darstellen. Viele Anwender und Partner entwickeln während der Arbeit mit der Software Anforderungen und Wünsche – wie gehen wir damit konkret um?
Es ist uns wichtig, dass die Software sich weiter verbessert und Ihnen viele neue Möglichkeiten bietet. Es stellt sich für uns als Hersteller natürlich in dem Zusammenhang die Frage: Nach welchen Kriterien fließen Neuerungen in das Produkt infra-struktur ein? Es ist natürlich fast unmöglich, jeden Wunsch zu berücksichtigen, sonst sieht man irgendwann den “Wald vor lauter Bäumen nicht mehr”. Nach welchen Kriterien sollen die Wünsche aber konkret umgesetzt werden? Vor dieser Frage und weiteren stehen wir täglich. Sind Wünsche zu 100%, unabhängig von der Sinnhaftigkeit, zu berücksichtigen? Wer legt die Kriterien für den Sinn hinter einer Funktion fest? Ist der Respekt vor der Arbeitsweise eines Anwenders höher zu bewerten, als die möglichst objektive Einschätzung? Soll der Anwender sich verändern, oder sich die Software im Sinne des Anwenders ändern und wenn – zu welchem Grad?
Für die Weiterentwicklung gibt es zunächst eine erste, wichtige Entscheidung zu fällen: Bug oder Feature?
I. Wenn es sich um einen Bug handelt, wird nach den folgenden Weiterentwicklungsarten Arten (Bug (B)/Feature (F)) unterschieden. Bugs werden kostenlos durch NETZkultur repariert und genießen die höchste Priorität. Ein Bug wird wie folgt definiert: Die Funktion ist in seiner Logik gestört und eine Zielerreichung ist nicht möglich. Der Fehler lässt sich klar reproduzieren.
Bugs werden wie folgt eingeteilt:
B1.0.0: der Fehler ist kritisch und kann Daten zerstören oder gefährden
-> Priorität 1 (direkter Bugfix zur Laufzeit) (Bsp.: Daten werden nicht gespeichert)
B2.1.0: der Fehler ist kaum zu merken (unkritisch), verändert keine Daten, oft optische Einschränkungen
-> Priorität 2 (wird im nächsten Update behoben) (Bsp.: Rechtschreibfehler)
B2.2.1: der Fehler ist nur mit großem Aufwand zu beheben, man kann aber damit leben
-> Priorität 9
B2.2.2: der Fehler ist quasi nicht in dem aktuellen Modulcode zu beheben
-> Folge: Neugrogammierung des Moduls
-> Priorität 10
Die Bugs der Priorität 9 und 10 stellen einen Sonderfall dar. Sie entstehen nur bei alten Modulen. Auf dem Weg zur infra-struktur 3.0 wird es keine Bugs mit hoher Komplexität und mit hohem Aufwand geben!
II. Die Anforderung ist eine Erweiterung, eine Funktion (Feature):
Eine Funktion oder Feature ist eine Funktionserweiterung oder Verbesserung. Damit sind neue Ziele erreichbar oder Ziele schneller erreichbar. Dazu ist bei Features wichtig, das abstrakte Ziel genau zu definieren, welches erreicht werden soll, nicht das Verhalten. Diese Definition muss lösungsneutral sein. Bsp.: Als Kunde habe ich die Anforderung aus einer Mail eine Aufgabe zu erstellen. Das Ziel lautet dann vielleicht: Mails sollen zeitlich gesteuert auf Wiedervorlage gelegt werden.
Featureanforderungen werden wie folgt eingeteilt
F1.1.0: das Feature weicht von den Zielen von NETZkultur ab, es stellt damit eine kostenpflichtige Zusatzentwicklung dar und ist nicht sinnvoll, es wird nicht umgesetzt
-> keine Priorität
F1.2.0: das Feature weicht von den Zielen von NETZkultur ab, es stellt damit eine kostenpflichtige Zusatzentwicklung dar, ist aber grundsätzlich sinnvoll
-> Priorität 3 (das Feature wird zügig umgesetzt)
Die Deklaration des Sinns, kann nur von NETZkultur bewertet werden. Basis ist die Frage: Wie weicht bei einer Umsetzung die Struktur von der heutigen ab. Bsp.: möchte ein Kunde die DS-Buttons ausbauen lassen und auch dafür bezahlen, stellt dieses einen massiven Eingriff auf die Struktur dar, ist demnach nur mühsam umsetzbar und stellt gleichzeitig bei den anderen Anwendern ein Rückweisungsmerkmal nach dem Kano-Modell dar. Es entsteht bei vorhandenem Feature eine Unzufriedenheit der anderen. Die Werte müssen natürlich statistisch signifikant durch das Pareto-Prinzip sein und keine Einzelfälle.
F2.1.0: das Feature stellt nach dem Kano-Modell ein Basismerkmal dar (fehlt=Unzufriedenheit, vorhanden=keine Zufriedenheit, da selbstverständlich)
-> Bsp.: das Hotelzimmer hat kein Bett
-> Priorität 4 (schnellst mögliche Umsetzung)
F2.2.1: das Feature stellt nach dem Kano-Modell ein Leistungsmerkmal dar (linear, je mehr desto besser) und der Aufwand ist gering
-> Bsp.: im Hotezimmerl gibt es eine Minibar
->Priorität 5
F2.2.2: das Feature stellt nach dem Kano-Modell ein Leistungsmerkmal dar (linear, je mehr desto besser) und der Aufwand ist hoch
-> Bsp.: im Hotel gibt es ein Schwimmbad
->Priorität 6
F2.3.1: das Feature stellt nach dem Kano-Modell ein Begeisterungsmerkmal dar (vorhanden=Begeisterung, nicht vorhanden=keine Unzufriedenheit) und der Aufwand ist gering
-> Bsp.: im Hotel gibt kostenloses WLAN
->Priorität 7
F2.3.2: das Feature stellt nach dem Kano-Modell ein Begeisterungsmerkmal dar (vorhanden=Begeisterung, nicht vorhanden=keine Unzufriedenheit) und der Aufwand ist hoch
-> Bsp.: im Hotel gibt es eine kostenlose Tiefgarage
->Priorität 8
Für die Faktoren F2.x wird also im Grunde die Häufigkeit unter die Hierarchie von Basismerkmal -> Leistungsmerkmal -> Begeisterungsmerkmal gelegt. Begeisterungsmerkmale werden natürlich eine geringe Häufigkeit haben, weil man es nicht störend empfindet, wenn es fehlt. Beim Basismerkmal werden die häufigsten Meldungen kommen, weil ein fehlen sehr schnell auffällt. Genau von dieser Überlegung leiten sich dann die kostenlosen Features für die nächsten Versionen ab, mit der Priorität aufsteigend.
Mit dieser Strategie soll also klar definiert werden, zu welcher Art eine Anforderung gehört. Entweder Bug oder Feature, bei Features in den jeweiligen Prioritäten unter Berücksichtigung: Möchte ich die Erweiterung kostenlos im Rahmen der Weiterentwicklung, oder benötige ich Sie schneller und was ist es mir Wert? Die genaue Einschätzung der Weiterentwicklungsart ist Sache von NETZkultur, wir werden die Art in Zukunft direkt im Supportmodul eintragen. Jeder kann aber genau nachvollziehen, warum wir zu welcher Einschätzung gekommen sind.
Bei der Erreichung eines Ziels, ist also auch immer zu prüfen: Ist es überhaupt erreichbar und mit welchem Aufwand? Auch das hat dann eine direkte Auswirkung auf die Prioritäten. In der Praxis ist es aber elementar wichtig, Prioritäten seriell nach Prioritätenstufe abzuarbeiten. Features der Stufe 3 können also erst fertig werden, wenn alle Anforderungen der Priorität 1 und 2 erledigt sind. Nach hinten wird es also länger brauchen, bis etwas hineinkommt. Bei jeder Einzelfallbetrachtung gibt es zudem noch ein klares Ausschlusskriterium für Wünsche: Es ist technisch nicht realisierbar.
Um auch in Zukunft die drei Merkmale nach Kano abzugrenzen, werden regelmäßig Umfragen durchgeführt und streng ausgewertet. Alle Anforderungen werden über das Supportmodul entgegengenommen (Supportmeldung? Warum?) und direkt gelöst, oder bei höheren Prioritätsstufen in Scrum Stories überführt und regelmäßig überwacht. Eine Roadmap ergibt sich also dann dadurch, das innerhalb unserer Scrum Software die Iterationen mit einem Zyklus von 14 Tagen geplant werden. Für einen gewissen Teil der Stories können wir also angeben, ob sie bereits geplant sind und für welchen Zeitraum.
Somit sind wir also künftig in der Lage ein noch besseres Feedback zu geben und anhand der sich ergebenden Prioritäten auch einen Ausblick auf die Geschwindigkeit der Umsetzung geben zu können.
Wir freuen uns auf Ihre Anregungen, Wünsche und Ideen und werden diese gerne in alle Überlegungen mit einbeziehen.
