Feature-Priorisierung in Projekten: So geht's richtig!

Wollten Sie schon einmal etwas haben, nur weil es im Trend lag? Und weil es im Trend lag und alle es zu haben schienen, mussten Sie dem Trend folgen? Wenn Sie mich fragen, müsste ich diese Frage mit Ja beantworten. Ich habe Dinge getan und gekauft, nur weil alle anderen sie taten und kauften und nicht, weil ich sie tatsächlich brauchte. 

Nehmen wir diese Situation aus unserem Alltag nun mit in die Welt der Webentwicklung – glauben Sie, dass sie dort anwendbar sein wird? Ja, und ich sage Ihnen, warum. 

Wenn ein Webprojekt im Gange ist, gibt es Dutzende, wenn nicht Hunderte von Szenarien, die als Ergebnis eintreten können. Es liegt an den Projektmanager:innen, das Projekt in die Richtung zu lenken, die am besten für das in der Planungsphase festgelegte Ziel geeignet ist. Es gibt jedoch Zeiten, in denen das Projekt vom Kurs abkommt.

Wie kann das passieren?

Menschen, die ein Projekt entwickeln, streben oft danach, es zum Besten zu machen. Niemand strebt ein minderwertiges Ergebnis an. Im Streben nach dem Besten versuchen sie daher, das Projekt mit so vielen Funktionen wie möglich zu überladen und verlieren das ursprüngliche Ziel aus den Augen. 

Der Kunde hat danach gefragt, fügen Sie diese Funktion hinzu; 
Ein Stakeholder lehnt eine wertvolle Funktion vehement ab, lassen Sie sie weg; 
Die Konkurrenz hat eine bestimmte Funktion hinzugefügt, das müssen wir auch; 

Entscheidungen wie diese sind ein Hauptgrund, warum Projekte nicht das erreichen, was sie beabsichtigt haben. Es ist auch der Grund, warum Projektmanager:innen die Last der Entscheidung tragen müssen, was in ein Projekt integriert werden soll und was vorerst oder endgültig weggelassen werden soll. 

Diese Praxis, die geeignete Roadmap für ein Produkt zu wählen und diese während der gesamten Entwicklungsphase mithilfe einer gut definierten Strategie umzusetzen, wird oft als Feature-Priorisierung bezeichnet. Sie legt im Wesentlichen die Reihenfolge der Funktionen fest, die in das Projekt aufgenommen werden und wann dies geschehen soll. Hinter der Feature-Priorisierung steckt viel, und die Marktforschung ist der Beginn der Roadmap-Entwicklung. 

Auf die Frage an eine Gruppe von Projektmanager:innen nach den größten Herausforderungen im Zusammenhang mit ihrer Arbeitsbelastung sagten sie Folgendes: 

Die Feature-Priorisierung ist bei Weitem einer der anspruchsvollsten Aspekte im Berufsprofil eines Projektmanagers. Heute werden wir herausfinden, warum das so ist, indem wir verstehen, wie dieses Konzept üblicherweise funktioniert, welche Mängel damit einhergehen und auch die geeigneten Strategien, die die Feature-Priorisierung im Projektmanagement begünstigen. Also, fangen wir an.

Der alltägliche Prozess der Feature-Priorisierung 

Die Feature-Priorisierung ist ein Prozess, der etwas anstrengend sein kann. Ein Hauptgrund, warum ich dieses Adjektiv verwendet habe, ist, dass es ein Prozess ist, der Menschen, ihre Ideen und die damit verbundenen Gefühle involviert. Ein Webprojekt zu entwickeln erfordert Arbeit, aber Menschen und Meinungen einzubeziehen und zu versuchen, für jede Entwicklung im Projekt einen Konsens zu erzielen, würde Arbeit erfordern und Kopfschmerzen bereiten. Fragen Sie jede:n Projektmanager:in, ein Aspirin wäre ein gängiges Nahrungsergänzungsmittel, das mit dem Job einhergeht. Es ist schließlich ein Job, bei dem Emotionen ständig hochkochen. 

Werfen wir einen Blick darauf, wie die Feature-Priorisierung im Alltag durchgeführt wird. 

Fokus auf das übergeordnete Ziel 

Bevor der PM Beweise sammelt, um eine Funktion zu untermauern, und all die langwierigen Diskussionen auf der Grundlage der Beweise führt, um jede Person im Team davon zu überzeugen, dass es funktionieren und ein Muss sein würde, muss der PM allen das Gesamtbild vor Augen führen und sich genau darauf konzentrieren. 

Das Entwicklungsteam wird vielfältig sein, es wird Leute geben, die Profis in dem sind, was sie tun, und diese Leute werden ihren Willen durchsetzen wollen, weil sie denken, sie wüssten es am besten. Und vielleicht tun sie das auch, aber Experte in einem Bereich zu sein, gibt ihnen kein Mitspracherecht bei der Entscheidung, was für das Projekt richtig ist, wobei auch mehrere andere Aspekte eine Rolle spielen. 

Daher ist das Verständnis des Endziels durch jede Person im Entwicklungsteam entscheidend, wenn ein Konsens erzielt werden soll. Natürlich wird es nicht immer einstimmige Entscheidungen geben, und wenn das passiert, sollten die Teammitglieder die Entscheidung nicht übel nehmen, sondern die Begründung dahinter verstehen können, indem sie sich auf das übergeordnete Ziel konzentrieren. 

Prototyping zur Beweisführung 

Nun kommt der Teil, in dem Beweise zur Unterstützung einer Funktion gesammelt werden, die implementiert werden sollte. Und Prototyping ist hier das Mittel der Wahl. 

Zum Beispiel haben Sie eine Theorie, von der Sie wissen, dass sie zugunsten des Endziels funktionieren wird. Es gibt jedoch gewisse Bedenken dagegen. Was tun Sie dann? Sie erstellen einen Prototyp. Sie werden versuchen, eine testbare Hypothese zu entwickeln, diese auszuführen, die Ergebnisse durch die ordnungsgemäße Durchführung der Testzyklen erhalten und Ihren Beweis erbringen. 

Dieser Beweis würde dem Team helfen, ihre Zweifel an einem Ansatz zu zerstreuen, selbst wenn es um Sie geht. Das Gleiche kann negative Ergebnisse haben, d.h. das Testergebnis könnte ungünstig sein. Auch in diesem Fall hätten Sie die Beweise, um eine bestimmte Vorgehensweise nicht zu verfolgen.

Hierarchie wertschätzen oder nicht?

Bei der Priorisierung von Funktionen werden Sie eine klare Roadmap haben, Sie werden höchstwahrscheinlich ein gewisses Verständnis dafür haben, was Sie wollen und was nicht. All das kann jedoch vergeblich sein, wenn eine hochrangige Idee in Ihren geplanten Aktionsplan platzt. 

Einem Manager seine Anfrage zu verweigern, kann für viele ein Problem sein. Der perfekt ausgearbeitete Projektplan kann von einer hohen Erfolgswahrscheinlichkeit zu einer hohen Misserfolgswahrscheinlichkeit führen, weil ein Stakeholder beschloss, die Projektfunktionen mit seiner Anfrage aus dem Gleichgewicht zu bringen. 

Erinnern Sie sich an das Prototyping, das wir im vorherigen Punkt besprochen haben? Setzen Sie das in die Praxis um und retten Sie Ihr Projekt davor, gefährdet zu werden. Und so müssen Sie Hierarchie wertschätzen.

Die Zukunft durch die Gegenwart sehen

Letztendlich werden die Feature-Priorisierung und sogar der gesamte Entwicklungsprozess für ein Ziel verfolgt, das in der Zukunft erfüllt werden soll. Und es würde nur erreicht werden, wenn Sie heute die Anstrengungen unternehmen. 

Die Zukunft zu sehen bedeutet, dass Sie wissen, wie sich die Punkte verbinden werden, um eine perfekt gerade Linie zu bilden. Dies geschieht, indem man praktisch über den einzuschlagenden Weg nachdenkt und das Sinnvolle vom Sinnlosen filtert.

Sie als Projektmanager:in müssen Ihrem Team die Gründe für die gegenwärtige Arbeit für die zukünftige Implementierung verständlich machen. Wenn die Leute wissen, dass das, was sie heute tun, einem großen oder sogar kleinen Zweck dienen wird, wie der Bereitstellung von Online-Bildung für Haushalte mit geringem Einkommen, werden sie mit Sicherheit ihr Bestes geben; was die Feature-Priorisierung für den PM weniger kopfzerbrechend macht.

Wie würden Sie also die Feature-Priorisierung definieren? 

Laut einem unserer Projektmanager, Abhijeet Sinha, kann die Feature-Priorisierung nicht in eine starre Formel gepresst werden, die für jedes Szenario gilt. Er betrachtet den Prozess als rein kontextbezogen, und somit werden seine Bedeutung und Umsetzung recht dynamisch. Das Einzige, was bei der Feature-Priorisierung Bestand hat, ist das Gleichgewicht – ein Gleichgewicht zwischen den Bedürfnissen der Stakeholder und der Machbarkeit dieser Bedürfnisse. Man kann nicht bei jeder Gelegenheit den Mond und die Sterne liefern, sonst würde der Himmel seinen Glanz verlieren. Und ich bin zu 100 % seiner Meinung.

Das Einzige, was bei der Feature-Priorisierung Bestand hat, ist das Gleichgewicht – ein Gleichgewicht zwischen den Bedürfnissen der Stakeholder und der Machbarkeit dieser Bedürfnisse.

Während meiner Diskussion mit Abhijeet sprachen wir über ein bestimmtes Projekt, bei dem die Priorisierung schwieriger war als bei anderen, weil Prioritäten und Machbarkeiten in massivem Ausmaß kollidierten. 

Dies geschah im Thinkin Blue Revamp-Projekt.

Thinkin Blue ist eines der prominentesten Projekte von OSL; es umfasste die fortschreitende Überarbeitung seiner Website. Der Kunde wollte, dass das bestehende Theme der Website beibehalten werden sollte, die Überarbeitung würde eine Änderung der Templates beinhalten, all dies schien machbar. Das Problem entstand auf der Startseite, wo zwei Themes involviert sein mussten: das bestehende zusammen mit dem neuen, was für die Überarbeitung unerlässlich war, damit sie wie eine Überarbeitung aussah. 

Die Entwickler:innen hatten jedoch Bedenken, denn eine Startseite auf zwei Themes aufzubauen, würde eine riesige Herausforderung darstellen, und kompliziert würde es nicht einmal annähernd beschreiben. 

Der Kunde wollte eine Sache und die Entwickler:innen hielten es für zu kompliziert, das Projekt befand sich in einer Sackgasse. Abhijeet, als PM, versuchte, mit beiden Parteien zu verhandeln, und am Ende gingen die Entwickler:innen Kompromisse ein und die Startseite wurde auf zwei Themes aufgebaut. 

Das Gleiche geschah bei den Headern: Der Kunde wollte globale Header, während die Entwickler:innen nicht dachten, dass dies der richtige Weg für die Startseite war, wegen des neuen Themes. Einer von ihnen musste Abhijeet etwas Spielraum geben, um das Projekt voranzutreiben, und diesmal war es der Kunde. 

Sehen Sie, was Abhijeet getan hat? Er ließ die Stakeholder nicht überall herrschen, noch erlaubte er den Entwickler:innen, alle Gebote zu erlassen. Er hörte immer beiden Seiten zu, dachte rational über die Praktikabilität nach und wo er dachte, er könnte etwas durchsetzen, tat er es. Wenn er die Bedürfnisse des Kunden über die der Entwickler:innen stellen musste, tat er es und umgekehrt. Es gab immer ein Gleichgewicht. Und so sind Projekte erfolgreich, Thinkin Blue ist ein Beweis dafür. In einer Sackgasse festzustecken, würde nur Geld, Zeit und Mühe kosten, und wenn Kompromisse das vermeiden können, dann sollten Sie als Projektmanager:innen daran arbeiten.

Die entscheidenden Priorisierungsfragen, die man stellen sollte

Im vorherigen Abschnitt haben wir über die Feature-Priorisierung gesprochen und wie sie üblicherweise abläuft. Die Beteiligung von Ideen, Emotionen und Hierarchie ist unvermeidlich. Dennoch müssen Sie hartnäckig bleiben, um zu den geeigneten Funktionen für Ihr Projekt zu gelangen, ohne sich in einem wilden Ansturm unerwünschter Attribute zu verlieren, die Sie später mit Sicherheit bereuen werden. 

Hier sind einige Fragen, die Ihnen helfen, nicht vom Weg abzukommen.

Denken Sie an die Nutzer:innen

Die Feature-Priorisierung beginnt bei den Nutzer:innen, für sie werden alle Anstrengungen unternommen. Deshalb müssen Sie sich fragen: 

Wie viele Nutzer:innen würde die vorgeschlagene Funktion beeinflussen?
Wie viele Nutzer:innen könnten die Funktion nutzen, ohne sie komplex oder verwirrend zu finden?
Wie oft wird der/die Nutzer:in diese bestimmte Funktion pro Tag nutzen?
Wie viele Nutzer:innen würden sich durch die Funktion gestärkt fühlen, würde ihr Wert bei den Nutzer:innen Anklang finden?

Je höher die Antworten auf diese Fragen ausfallen, desto besser würde sich die Funktion erweisen. Zum Beispiel würde das Hinzufügen verschiedener Barrierefreiheitsfunktionen, die die Nutzung eines Screenreaders auf Ihrem Webprojekt unterstützen, Sehbehinderten sehr zugutekommen. Bei bis zu 285 Millionen sehbehinderten Nutzer:innen würde ich sagen, dass die Chancen, dass eine solche Funktion die Priorisierung besteht, recht hoch sind.

Denken Sie an Wachstum 

Nach den Nutzer:innen kommt das Wachstumspotenzial. Wachstum ist ein ziemlich weit gefasster Begriff. Es könnte bedeuten, neue Kunden durch eine Einladungsfunktion zu gewinnen, und es könnte auch bedeuten, eine Funktion zu eliminieren, die ein Hindernis beim Anlocken des Wettbewerbsmarktes darstellte. Sie müssen mit allen Wachstumsaspekten Ihrer Funktion vertraut sein und sich dann fragen: 

Würde die Funktion Ihr Wachstum fördern?

Denken Sie an den Aufwand 

Etwas zu entwickeln, das ein Problem löst, wird tatsächlich einen gewissen Aufwand von Ihnen erfordern. Um sicherzustellen, dass Ihre Anstrengungen belohnt werden, stellen Sie sich diese drei Fragen.

Muss die Funktion von Grund auf neu entwickelt werden oder benötigt sie nur eine Feinabstimmung, um besser zu funktionieren?
Erfordert die Funktion viele Ressourcen für ihre Implementierung, und wenn ja, haben Sie einen Plan für die Bereitstellung dieser Ressourcen?
Erhöht die Funktion die Komplexität beim Erstellen und Nutzen für Entwickler:innen und Endnutzer:innen und wird es das wert sein?

Dann denken Sie an sich selbst 

Nach all dem denken Sie an sich selbst, Ihren Ruf und Ihre Marktposition. Die Art der Funktionen, die Sie in einem Produkt bereitstellen, sprechen für die Werte, die Sie als Marke vertreten. Eine Marke, die Barrierefreiheit priorisiert, würde als Marke wahrgenommen, die soziale Inklusion anstrebt, und das würde wortlos durch die Funktionen, die sie in ihre Produkte integriert, zum Ausdruck gebracht. Und ich muss Ihnen nicht sagen, welchen Wert ein positives Markenimage hat. 

Fragen Sie sich also, wie gut die Funktion zur Vision Ihrer Marke und ihrer Marktposition passt?

Die fehlerhafte Art der Feature-Priorisierung 

Nachdem wir nun ein gutes Verständnis der Do's der Feature-Priorisierung haben, ist es nur fair, auch die Don'ts zu beleuchten. Dies sind bestimmte Dinge und Auswahlkriterien, die Ihnen völlig fair erscheinen mögen, aber in Wirklichkeit den gesamten Prozess behindern können; daher müssen Sie sich ihrer wirklich bewusst sein.

Eine Meinung über vielfältige Ansichten stellen 

Ein Kundenfeedback, eine Analystenmeinung, ein ROI-Bericht zu dieser einen Funktion; was haben all diese gemeinsam? Das Adjektiv „eine/r/s“. Sie werden von einer einzelnen Person oder einem einzelnen Bericht vorgeschlagen, und deshalb können Sie ihnen nicht zu viel Beachtung schenken. Es ist, als würde man seine Meinung nicht äußern, weil eine Person einem gesagt hat, man solle schweigen. 

Sie müssen vielfältige Ansichten betrachten. 

• Wenn eine Reihe von Verbraucher:innen mit einer bestimmten Funktion unzufrieden sind, ziehen Sie eine Behebung in Betracht. 
• Wenn ein Analyst seine Behauptung mit aktuellen Daten und nicht mit veralteten Berichten untermauern kann, ziehen Sie die Umsetzung seiner Meinungen in Betracht. 
• Wenn der Unternehmens-ROI und der Kundennutzen zusammen mit dem ROI der betreffenden Funktion auf dem Tisch liegen, erst dann eine Vorgehensweise in Betracht ziehen.

Andernfalls verschwenden Sie wertvolle Zeit, Mühen und Ressourcen, und ich bin mir ziemlich sicher, dass dies auf Ihrer „Was-man-nicht-tun-sollte“-Liste steht, seit eine solche Liste überhaupt konzipiert wurde.

Bauchgefühl über Rationalität stellen 

Es gibt Funktionen, die wir lieben, und es gibt Funktionen, die notwendig sind. Beide könnten dasselbe sein und der Marke und den Verbraucher:innen zugutekommen, es besteht jedoch auch die Möglichkeit, dass dies nicht der Fall ist. 

Wenn Sie oder sagen wir Ihr Chef denkt, dass eine bestimmte Funktion dem Projekt einen immensen Mehrwert verleihen würde, weil sie sie liebt und ihr Bauchgefühl ihr sagt, dass dies dem Projekt gefehlt hat, können Sie dem nicht folgen. Sie könnte Recht haben, aber dem Bauchgefühl zu folgen, ist ein absolutes No-Go bei der Feature-Priorisierung. 

Es muss eine fundierte Begründung hinter jeder Auswahl, jeder Ergänzung und jeder getroffenen Entscheidung stehen. 

Sie müssen auch wissen, dass Sie nicht immer sicherstellen können, dass jeder im Team eine rationale Entscheidung trifft; kognitive Verzerrungen sind eine reale Sache, und Sie können versuchen, sie zu negieren, aber zu 100 % frei von ihnen im Auswahlprozess zu sein, ist keine Garantie.

Ein interpretierbares Messsystem einem soliden vorziehen 

Wie kommt man in einer Gruppe mit geteilter Meinung zu einem Konsens? Die Antwort ist durch Abstimmung. Und das ist ein wichtiger Teil des Auswahlprozesses bei der Feature-Priorisierung. Diese Stimmen werden zur Maßeinheit, auf deren Grundlage eine Funktion ausgewählt oder verworfen wird. Es muss also ein solides System sein, oder?

Ja, es sollte zweifelsfrei narrensicher sein, es kann jedoch auch anders sein, und das passiert, wenn die Maßeinheiten interpretationsfähig sind. 

Wenn der Geschäftswert eine Zwei-Sterne-Bewertung erhält, können Sie absolut sicher sein, was diese zwei Sterne bedeuten? 

Bedeutet diese Bewertung einen minderwertigen Wert? 
Wie lässt sich das in Geschäftsgewinn umsetzen? 
Wie erreicht man fünf Sterne? 

Für eine Person mag der Wert klar sein, für eine andere jedoch unklar; der Grund dafür ist der Unterschied in der Wahrnehmung der Menschen, und es gibt kulturelle Unterschiede, die bei der Interpretation ebenfalls eine Rolle spielen. 

Jede Stimme auf dem gleichen Niveau priorisieren 

Um auf die Abstimmungsdiskussion zurückzukommen: Es wird oft gesagt, dass jede Stimme gleich viel wert ist. Doch wenn die abstimmende Person ahnungslos ist, worüber sie abstimmt, sollte ihre Stimme das gleiche Gewicht haben wie die eines Spezialisten in diesem Bereich? Denken Sie darüber eine Minute nach.

Jedes Team verfügt über ein vielfältiges Kompetenzprofil, das auf seinen Mitgliedern basiert. Es gibt Personen mit technischem Hintergrund wie die Entwickler:innen und Personen mit einem nicht so technischem Hintergrund wie die Marketingfachleute. Nun sagen Sie mir, sollte ein Marketingfachmann die gleichen Stimmrechte wie der Entwickler erhalten, wenn es um eine technische Funktion geht? 

Was ist mit Zeit- und Personalbeschränkungen?

Ob man es mag oder nicht, oftmals wird eine Funktion zurückgestellt, nicht weil sie ungeeignet war, sondern weil das Team nicht die Zeit hatte, sie zu entwickeln, oder nicht die richtigen Leute dafür hatte. So etwas ist in jeder Organisation irgendwann einmal passiert. 

Ein solcher Vorfall, wenn Sie nicht die richtigen Leute haben, um eine Funktion auszuführen, von der Sie wissen, dass sie Wunder für Ihr Projekt wirken würde, ist frustrierend, was verständlich ist. Sie können nichts dagegen tun; Sie können eine neue Person einstellen, aber das könnte eine ganz andere Aufgabe für sich sein. 

Sie können diese Einschränkungen als negativ betrachten, oder Sie können den Silberstreif am Horizont sehen und sie als ein weiteres Filterinstrument betrachten, das Ihnen hilft, weiter zu priorisieren. Da ich der Typ bin, der das Glas halb voll sieht, würde ich sagen, es ist eine gute Sache. 

Wenn Sie alles organisiert planen und Ihr Prozess narrensicher ist, haben Sie die halbe Miete gewonnen. Die ordnungsgemäße Umsetzung würde Ihnen helfen, Zeit- und Personalbeschränkungen zu überwinden. Wenn Ihr Team dem Plan zustimmt und ihn kennt, steigen Ihre Erfolgschancen immens. Dies bedeutet auch, dass das Team Prioritätsaufgaben von Nicht-Prioritätsaufgaben unterscheiden kann. 

Das Endziel jedes Projekts ist die Verbesserung, und es sind Forschung und Prototyping, die dies ermöglichen. Wenn Sie also einen Prozess zur Implementierung dieser beiden haben, können Sie keine Einschränkungen zurückhalten. Und vielleicht helfen Ihnen diese beiden Einschränkungen sogar dabei, ein Überreizen zu vermeiden?

Die idealen Strategien für die Feature-Priorisierung?

Wir haben alles gelernt, was wir über dieses Konzept können, jetzt ist es an der Zeit, etwas über die Strategien zu lernen, die Projektmanager:innen bei der Umsetzung helfen. Es gibt einige Frameworks zur Feature-Priorisierung, die Erwähnung verdienen. 

Das KANO-Modell 

Das KANO-Modell hilft Ihnen, die Bedürfnisse und Wünsche der Verbraucher:innen zu verstehen und Ihre Funktionen darauf aufzubauen. Dies geschieht durch Fragebögen und Kundenfeedback. Obwohl es ein zeitaufwändiger Prozess ist, gibt es Ihnen ein klares Bild davon, wo der Verbraucher in Bezug auf Produktfunktionen steht, indem es diese klassifiziert. 

Laut dem KANO-Modell denkt der Nutzer auf vier Arten. 

• Erstens will er Begeisterung. Diese Funktionen fügen dem Produkt oder der Dienstleistung keinen Wert hinzu, aber ihre Anwesenheit reicht aus, um den Verbraucher zu begeistern und anzulocken.
• Zweitens will er eine erhöhte Leistung. Je besser die Leistung der Funktion, desto höher die Kundenzufriedenheit und umgekehrt. 
• Drittens will er die Grundlagen. Es gibt bestimmte Dinge, die vorhanden sein müssen, obwohl sie dem Nutzer keine Begeisterung bereiten; man könnte sie als Schwellenwert bezeichnen.
• Schließlich wird er gleichgültig. Diese Gleichgültigkeit bezieht sich auf Funktionen, deren Anwesenheit oder Abwesenheit den Verbraucher nicht beeinflusst.

Alle vier, mit ihren unterschiedlichen Zufriedenheits- und Funktionalitätsniveaus, helfen den Projektmanager:innen, die Stärken und Schwächen des Projekts zu erkennen.

Das MoSCoW-Modell 

Muss-Funktionen; 
Soll-Funktionen; 
Kann-Funktionen; 
Wird-nicht-haben-Funktionen;  

Diese vier fassen die Bedeutung und die Logik hinter dem MoSCoW-Modell zusammen. Alle kategorisieren Funktionen nach ihrer Bedeutung für das Projekt. Von oben beginnend: 

• Funktionen, die in einem Projekt vorhanden sein müssen, um es zu vervollständigen, sind die Muss-Funktionen und sollten über alles andere priorisiert werden. 
• Funktionen, die in das Projekt aufgenommen werden sollten, aber vorerst verzögert werden können, sind Soll-Funktionen, ähnlich wie grünes Gemüse; man sollte es essen, aber man kann eine Zeit lang ohne auskommen. 
• Funktionen, die in das Projekt aufgenommen werden könnten oder auch nicht, ohne die Gesamtfunktionalität zu beeinträchtigen, sind die Kann-Funktionen. Es ist gut, sie für eine höhere Kundenzufriedenheit zu haben, aber ihre Abwesenheit wird dem Verbraucher nicht offensichtlich sein.
• Funktionen, die „Wird-nicht-haben“-Funktionen sind, sind diejenigen, die im Moment überhaupt nicht entscheidend für das Projekt sind und nur zusätzlichen Stress für die vorhandenen Ressourcen verursachen würden. 

Das Besondere am MoSCoW-Modell ist, dass es Ihnen zeigt, welche Art von Funktionen Sie in Zukunft einbringen können. Dies liegt daran, dass Prioritäten niemals gleich bleiben; eine Funktion, die aufgrund von zu viel Aufwand und zu geringem Einfluss zurückgestellt wurde, könnte in Zukunft zu einer Muss-Funktion werden.

Laut den Projektmanager:innen von OSL wird der Erfolg eines Projekts maßgeblich durch die intelligente Priorisierung verschiedener Aufgaben bestimmt. Die Auswahl der richtigen hochprioritären Funktion mag entmutigend erscheinen, aber für eine erfolgreiche und termingerechte Projektabwicklung ist dies ein Muss. Neha Grover, eine unserer Projektmanagerinnen, ist der Meinung, dass in Projekten, in denen eine Liste von Arbeitspaketen vorliegt, die priorisiert und in eine Work Breakdown Structure (WBS) umgewandelt werden müssen, der PM eine Schlüsselrolle dabei spielen muss, die Erwartungen und Prioritäten der Stakeholder und des Entwicklungsteams auf einen Nenner zu bringen.

"Ich wende in meinen Projekten die MoSCoW-Priorisierungstechnik an, da diese recht einfach und weniger zeitaufwändig ist und sich sowohl auf Kunden als auch auf Stakeholder konzentriert."

Das Cost-of-Delay-Modell 

Es wird oft gesagt, dass man Zeit nicht mit Geld aufwiegen kann, sie ist tatsächlich unbezahlbar; einmal vergangen, kommt sie nie wieder zurück. Wenn Sie jedoch die richtige Matrix zur Verfügung haben, können Sie tatsächlich den Wert der Zeit oder vielmehr die Kosten der Verzögerung beziffern. Und darum geht es bei diesem Framework zur Feature-Priorisierung. 

Das CoD-Modell berechnet Ihre Verluste, die durch die Verzögerung der Entwicklung und Implementierung einer bestimmten Funktion entstehen. Basierend auf diesen Kosten erhalten Sie eine Vorstellung von der Bedeutung dieser Funktion und priorisieren deren Entwicklung entsprechend. 

Zum Beispiel, 

Angenommen, es gibt eine Funktion, deren Entwicklung 30 Tage dauern würde und die die Organisation täglich 1000 $ kosten würde. Dann gibt es eine Funktion, deren Entwicklung die gleiche Zeit in Anspruch nehmen würde, die die Organisation jedoch im Vergleich dazu täglich mehr als das Doppelte kostet.

In einem solchen Szenario, welche Funktion würden Sie priorisieren? Die Antwort ist einfach: diejenige, die Sie mehr Geld verlieren lässt. Diese zuerst zu entwickeln, würde Ihre Verluste stärker stabilisieren als die andere, da die Kosten der Verzögerung dieser Funktion höher waren als die der anderen. 

Priorisieren Sie, was Ihnen mehr Geld spart, indem Sie die Kosten der Verzögerung reduzieren.

Das Wertmodell 

Unternehmen entwickeln Funktionen, weil sie denken, dass diese für sie wertvoll sein würden. Um diesen Wert zu erzielen, bemühen sie sich, etwas Gutes zu entwickeln. Was aber, wenn dieser Wert nicht so beeindruckend ist, wie das Unternehmen, die Projektmanager:innen und die Entwickler:innen dachten? Deshalb wird das Wertmodell zu einer wichtigen Strategie, die während der Feature-Priorisierung umgesetzt werden sollte. 

Der Zweck des Wertmodells ist es, den höchsten Wert einer Funktion für das Unternehmen durch seine zwei Facetten zu erzielen.

Wert basierend auf Kosten 

Kosten bedeuten nicht unbedingt Geld, sie könnten auch als Aufwand oder sogar Komplexität interpretiert werden. Das Modell besagt, dass man einfach die Aufgaben mit hohem Wert und geringen Kosten zuerst priorisieren sollte, dann zu den Funktionen mit hohem Geschäftswert und hohen Kosten übergehen sollte. Wenn Sie möchten, können Sie die Funktionen mit geringem Wert und geringen Kosten übernehmen, aber Funktionen mit geringem Wert und hohen Kosten unbedingt vermeiden. 

Wert basierend auf Risiko

Von den Kosten kommen wir zum Risiko, einer weiteren Metrik, die bei der Priorisierung von Funktionen zu beachten ist. Es funktioniert mehr oder weniger ähnlich wie das Wert-Kosten-Modell, nur dass Sie sich statt auf die Kosten auf das Risiko konzentrieren würden. 

Funktionen mit höherem Wert und geringem Risiko würden über alles andere priorisiert, während Funktionen mit geringem Wert und hohem Risiko gänzlich vermieden würden. Dies hilft sicherzustellen, dass Sie am Ende nichts Unnötiges oder gar etwas zu Einfaches bauen, indem Sie auf Nummer sicher gehen.

Das Finanzmodell 

Ein Einkommen ist das, wonach jeder strebt, und die Feature-Priorisierung funktioniert nach dem gleichen Prinzip. Der Zweck der Umsatzsteigerung und Kostenreduzierung ist in allen Geschäftsentscheidungen allgegenwärtig, und die Auswahl von Funktionen für ein bestimmtes Projekt fällt unter diesen Schirm. 

Das Nachdenken über die finanzielle Seite der Funktionen ist also das Wesen dieses Modells. 

Ob Sie neue Einnahmen generieren können; 
Ob Sie Ihre Betriebseffizienz steigern und Kosten senken können; 
Ob Sie die Kundenfluktuation verringern können;
Ob Sie zusätzliche Einnahmen von den bereits bestehenden Kunden erzielen können; 

All dies sind wichtige Szenarien, die im Finanzmodell für die Feature-Priorisierung berücksichtigt werden müssen. 

Dann gibt es die tatsächlichen Geldmetriken, die im Auswahlprozess beachtet werden müssen, welche drei wichtige Dimensionen umfassen. 

• Erstens der Fokus auf den Barwert des Geldes. Was Sie heute investiert haben und die Rendite, die Sie in fünf Jahren daraus erzielen, würde nicht den gleichen Geldwert haben, da dieser sich ständig ändert. Eine Projektion basierend auf der Nettobarwertformel ist daher eine kluge Wahl. 
• Zweitens die Berechnung des internen Zinsfußes (Internal Rate of Return), der im Wesentlichen ein prozentualer Wert der Renditen für ein Projekt ist und wie schnell diese steigen könnten.
• Drittens der Fokus auf die laufende Summe der diskontierten Cashflows, um einen Überblick über die Zeit zu erhalten, die es dauern würde, die Investition zurückzugewinnen. Dies wird auch als „diskontierte Amortisationszeit“ bezeichnet.

Das Opportunity-Scoring-Modell

Für jede Funktion in jedem Produkt gibt es zwei Attribute, die sich neben den finanziellen Aspekten dieser Funktion normalerweise abheben. Und diese sind: 

Wie wichtig ist die Funktion oder ihr Ergebnis für den Verbraucher?
Und wie zufrieden ist der Verbraucher mit der bereitgestellten Funktion?

Nehmen Sie die Antworten auf diese Fragen und beginnen Sie, sie in einem Diagramm darzustellen, und Sie werden am Ende etwas erhalten, das so aussieht. 

Das Scoring erleichtert die Priorisierung, indem es Visualisierungen und Kategorien gleichzeitig nutzt. Funktionen, die für den Verbraucher wichtig, aber nicht sehr zufriedenstellend sind, würden stärker priorisiert als Funktionen, die für den Verbraucher zufriedenstellend, aber nicht sehr wichtig sind. 

Das RICE-Modell  

Das RICE-Modell gibt Ihnen ein tiefgehendes Verständnis jeder Funktion, die Sie implementieren möchten, basierend auf vier Parametern, die einige der anderen Strategien nicht bieten können. 

Reichweite 

Reichweite bezieht sich auf die Anzahl der Personen, die die Funktion erreichen und beeinflussen würde. Diese Zahlen werden auf der Grundlage realer Metriken wie „Kunden pro Quartal“ und „Transaktionen pro Monat“ berechnet, wodurch alle Formen persönlicher Voreingenommenheit aus der Gleichung entfernt werden. Je höher die resultierende Zahl, desto größer die Reichweite der Funktion.

Wirkung 

Das I steht für Impact (Wirkung), d.h. die Art der Wirkung, die die Funktion auf einzelne Nutzer:innen sowie auf die Ziele und     Vorgaben des gesamten Unternehmens hätte. Dies wird von minimal über mittel bis hoch und massiv eingestuft, basierend auf Punkten von 0,25 bis 3.

Vertrauen 

Nachdem Sie nun die Zahlen für die Reichweite und Wirkung der Funktionen haben, kommt der Moment, Ihr Vertrauen in sie zu testen, das ist es, was das C bezeichnet. Mit einer Skala von 100, 80 und 50 Punkten, die ein hohes, mittleres und niedriges Vertrauensniveau bezeichnen, beginnen Sie mit der Bewertung. Denken Sie daran, immer Beweise in Form von Daten für jede von Ihnen vergebene Punktzahl zu liefern.

Aufwand

Am Ende steht das E für Effort (Aufwand) in Bezug auf Zeit und Personal. Fragen wie: Wie viel Zeit würde der Bau der Funktion in Anspruch nehmen? Wie viele Personen wären dafür erforderlich, wie viel Zeit müsste eine Person pro Tag für den Bau aufwenden – all das sind Fragen, die in diesem Parameter gestellt und beantwortet werden müssen. 

Sobald Sie die Ergebnisse für alle Parameter haben, werden Sie diese Formel verwenden und erhalten eine Zahl, die den gesamten Einfluss der geleisteten Arbeitszeit angibt. Diese Zahl hilft Ihnen bei der Priorisierung. 

Das Abstimmungsmodell 

Dies ist kein etabliertes Modell, aber es hat viel Verdienst in seiner Umsetzung. Basierend auf zwei verschiedenen Aspekten der Funktionsauswahl, wird es wie folgt verwendet. 

Anmerkung 

Wenn Sie für die Implementierung einer Funktion abstimmen, würden Sie angeben, ob diese Funktion eine hohe oder sogar niedrige Priorität haben sollte; Sie können nicht einfach diese zwei einfachen Worte sagen, es gäbe keine Klarheit darin. Wenn Sie sagen, dass eine Funktion eine hohe Wirkung hat, dann müssen Sie angeben, warum? Es könnte jeder Grund sein, ein Admin-Panel mit einer bestimmten Funktion könnte eine massive Wirkung haben, weil es den Stakeholdern helfen würde, ihre primären Aufgaben mit Leichtigkeit zu erledigen. Ein Kommentar kann die Wahrnehmung einer Funktion wirklich verändern und somit den Auswahlprozess unterstützen.

Diversifizierung

Der zweite Teil des Modells besteht darin, das Abstimmungsteam so weit wie möglich zu diversifizieren. Beziehen Sie sowohl Expert:innen als auch Nicht-Expert:innen in diesem Bereich ein. Dies würde Ihnen ein präziseres Bild von der Beliebtheit der Funktion bei einem breiteren Spektrum von Menschen geben. Denken Sie jedoch daran, dass Sie die Stimmen der Expert:innen klar von denen der Nicht-Expert:innen trennen, denn obwohl eine diversifizierte Abstimmung hilft, eine bessere Wahrnehmung der vorgeschlagenen Funktionen zu erhalten, würden die Meinungen der Expert:innen mehr Gewicht haben. Sie können die Stimmen sogar nach Abteilungen trennen, z.B. könnten Stimmen aus der Finanzabteilung eine Kategorie sein und Marketingfachleute eine andere Kategorie haben. 

Nachdem Sie nun verschiedene Ansätze zur Priorisierung von Funktionen in einem Projekt erkundet haben, lesen Sie mehr über den richtigen Weg, ein Drupal-Projekt zu starten, den Standard-Entwicklungsworkflow für ein Drupal-Projekt, die besten Projektmanagement-Techniken für komplexe Drupal-Projekte, den Unterschied zwischen Produkt-Mindset und Projekt-Mindset und den menschlichen Faktor im Projektmanagement für effektives Projektmanagement.

Fazit 

Es gibt zahlreiche weitere Techniken und Strategien, die für die Feature-Priorisierung implementiert werden können. Sie können alle davon oder nur ein paar verwenden, das ist ganz Ihnen überlassen. Sie müssen jedoch bedenken, dass eine Funktion nicht nur für den Verbraucher und nicht ausschließlich für das Unternehmen ist. 

Sowohl der Verbraucher als auch das Unternehmen haben unterschiedliche Gründe für die Nutzung und Entwicklung einer bestimmten Funktion. Der Verbraucher möchte, dass die Funktion ein Bedürfnis erfüllt, während das Unternehmen möchte, dass die Funktion einen erhöhten Umsatz bringt. Sie müssen sich also bemühen, ein Gleichgewicht zwischen beiden zu finden. Dies kann durch die Wahl von Strategien geschehen, die sowohl geschäfts- als auch kundenorientiert sind, wie das Cost-of-Delay-Modell oder RICE. 

Am Ende möchte ich nur sagen, dass die Feature-Priorisierung ein niemals endender Prozess ist, ähnlich der Entwicklung. Solange Sie weiterentwickeln, müssen Sie bestimmte Funktionen gegenüber anderen priorisieren. Die Beherrschung der Priorisierungstechnik würde Ihren Interessen daher gut dienen.