Vom Projekt zur Produktlieferung

Die Softwareentwicklung wird traditionell wie ein Projekt mit Aufgaben behandelt, die auf verschiedene Teams verteilt und dann zum Endprodukt integriert werden. Jeder bekommt seinen Teil der Arbeit zugewiesen, und das Produkt wird als Team geliefert.

Das Problem bei diesem Ansatz ist, dass er aufgabenorientiert ist. Die Entwickler werden aufgefordert, sich mit ihrer Checkliste von Aufgaben zu befassen und sich darauf zu konzentrieren, diese so schnell wie möglich abzuschließen. Oberflächlich betrachtet scheint dies ein hervorragender Weg zu sein, um die Entwicklung zügig voranzutreiben; in Wirklichkeit verlangsamt es das Projekt und hindert die Entwickler daran, sich ein Gesamtbild des Produkts zu machen.

Wenn Unternehmen darum konkurrieren müssen, das richtige Produkt in kürzester Zeit auf den Markt zu bringen, ist ein traditioneller, projektorientierter Ansatz nicht mehr zeitgemäß. Um ein Produkt zu liefern, das die Benutzer lieben werden, und das in einer wettbewerbsfähigen Time-to-Market, ist ein produktzentrierter Ansatz erforderlich.

Was genau ist ein produktorientierter Ansatz?

Stellen Sie sich ein Szenario vor, in dem Sie eine Softwareanwendung entwickeln müssen. Bei einem traditionellen Ansatz konzentriert sich das Unternehmen auf das Projekt und die Projektabwicklung und unterteilt die Softwareentwicklung in verschiedene Phasen, wobei jede Phase auf die Durchführung bestimmter Aktivitäten ausgerichtet ist. Die Phasen sind: Erfassung der Anforderungen, Entwurf (Planung der Programmiersprache und der technischen Details auf hoher Ebene), Erstellung (Codierung der Software), Test, Bereitstellung und Wartung.

Die Erfolgskennzahlen sind auf das Projekt abgestimmt, z. B. „Lieferung innerhalb des Umfangs“ oder „Projekt innerhalb des Budgets“. Trotz dieser Metriken dauert es lange, bis das Projekt geliefert wird, und wenn es schnell geliefert wird, entspricht es nicht den Anforderungen.

Der Weg zur Produktbereitstellung ist von Natur aus mühsam. In einem großen Unternehmen muss die Entwicklung durch die Hürden des Bedarfsmanagements und der Governance springen, was viele Monate dauern kann. Die Arbeit beginnt erst, wenn das Unternehmen die Initiative mit anderen Möglichkeiten vergleicht und sie als kritisch einstuft. Unternehmen verzichten zunehmend auf herkömmliche Finanzierungsmechanismen, indem sie die Budgets auf Abteilungsebene zuweisen und die Steuerung auf die Geschäftsbereiche verlagern.

Rein aus der Perspektive des Designs und der Bereitstellung können Unternehmen weiter Zeit sparen, indem sie sich zunächst auf die Kernfunktionalität des Produkts konzentrieren und es schnell für die Benutzer einführen, während sie die Funktionen langsam nach und nach ausbauen. Mit anderen Worten: Das Produktteam kann häufiger einen inkrementellen Wert liefern.

Bei einem produktzentrierten Modell steht das Produkt im Mittelpunkt der Lieferung und andere Projektaspekte wie die Dokumentation oder künftige Funktionen werden erst später berücksichtigt. Die Bemühungen sind darauf gerichtet, ein funktionales Projekt zum frühesten Zeitpunkt zu erstellen, die Nachfrage der Benutzer frühzeitig zu befriedigen und gleichzeitig die Grundlage für frühes Feedback zu schaffen, das in die Entwicklung von Funktionen einfließen kann.

Produktzentrierung beseitigt Silos

Ein projektbezogener Ansatz bei der Softwareentwicklung führt unweigerlich zu Silos. Stellen Sie sich eine App-Entwicklungsumgebung vor, in der die Entwickler voneinander abgeschottet sind und sich auf ihre eigenen Ziele konzentrieren, anstatt einen Überblick über das Produkt zu erhalten. In einer solchen Atmosphäre mit eingeschränkter Kommunikation zwischen Personen, die an demselben Produkt arbeiten, ist die Wahrscheinlichkeit groß, dass langfristige Ziele in den Hintergrund treten und die Entwicklerteams sich nur noch motiviert fühlen, ihre Aufgaben zu erledigen.

Silos können nicht nur die Qualität des Produkts und seine zukünftigen Möglichkeiten beeinträchtigen, sondern auch die Moral der Entwickler. Mangelnde Transparenz kann sich negativ auswirken und verhindern, dass die verschiedenen Teams gegenseitiges Vertrauen entwickeln, und es kann zu Ängsten führen, wenn es darum geht, Probleme zu melden, weil man befürchtet, seinen Teil des Projekts nicht richtig erledigen zu können. Fehlt ein offenes, gemeinsames System, steigt das Risiko von Fehlinformationen und verzögerten Arbeitsabläufen.

80 % der Unternehmen planen, bis 2022 eine produktzentrierte Methode zur Anwendungsentwicklung einzuführen

Die obige Statistik von Gartner zeigt, dass die Produktzentrierung in der Softwareentwicklung an Bedeutung gewinnt. In Anbetracht der Tatsache, dass Kunden, Partner und andere Dritte eine zunehmende Anzahl von Anwendungen nutzen, die von Unternehmen entwickelt wurden, gehen Produktzentrierung und eine wachsende Kundenorientierung nahtlos Hand in Hand.

Die Umfrage ergab, dass sich Unternehmen für den produktzentrierten Weg entschieden haben, um schneller zu liefern und ihre Markteinführungsgeschwindigkeit zu erhöhen. Eine weitere Triebkraft ist der Übergang zu einem transformativen Geschäftsmodell im Zeitalter der Digitalisierung; herkömmliche Projektmethoden sind für die Unbeständigkeit und Ungewissheit, die zum festen Bestandteil der Geschäftslandschaft geworden sind, schlecht geeignet.

Wie bereits angedeutet, wird die Produktzentrierung eine Verlagerung von der projektbezogenen Finanzierung zur Produktfinanzierung erfordern. Dieser Wandel und der damit verbundene potenzielle Kulturkonflikt zwischen IT und Unternehmen sind die größten Bedenken der Unternehmen, die sich für ein produktzentriertes Entwicklungsmodell entschieden haben. Außerdem ergab die Umfrage, dass viele Unternehmen bereits einen Produktmanager ernannt haben.

ProActys schematic Project to Product

Agile Entwicklung ist ein wichtiger Wegbereiter

Der agile Ansatz für die Projektentwicklung beinhaltet die schrittweise Erstellung von Software, wobei Unternehmen den Benutzern neue Versionen oder Software anbieten, die in kurzen Arbeitsabschnitten, den so genannten „Sprints“, erstellt werden. Das Agile Manifest nennt vier Kernwerte für die Entwicklung:

  • Individuen und Interaktionen vor Prozessen und Werkzeugen
  • Funktionierende Software über umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden statt Vertragsverhandlungen
  • Reagieren auf Veränderungen statt Befolgen eines Plans

Agile Entwicklung und Kundenzufriedenheit: Bei einem Wasserfall-Entwicklungsansatz bekommt der Kunde das Produkt erst am Ende des Projekts zu sehen. Bei einem agilen Ansatz hat der Kunde frühzeitig und häufig Gelegenheit, das Produkt zu betrachten und kann Änderungen vorschlagen. Wenn bei einem Wasserfall-Ansatz Fehler auftreten, werden diese erst in einer späteren Testphase festgestellt und können dazu führen, dass die Entwickler einige Schritte zurückgehen müssen, um das Problem zu beheben. Bei einem agilen Ansatz besteht die Möglichkeit, Fehler im Laufe der Entwicklung zu korrigieren.

Die Benutzerakzeptanz – ein Test, mit dem sichergestellt wird, dass die Software die erforderlichen Aufgaben in realen Situationen gemäß den vereinbarten Spezifikationen bewältigen kann – wird am Ende des Sprints durchgeführt. All diese Faktoren führen zu einer transparenteren und involvierten Kundenerfahrung, die den Kunden letztendlich mehr zufriedenstellt, als es mit traditionellen Entwicklungsmethoden möglich ist.

Agile Entwicklung und Transparenz der Entwickler: Da der Entwicklungsprozess iterativ abläuft, die Planung begrenzt ist und die Projektdurchführungszeiten zwischen zwei und vier Wochen liegen, fühlen sich die Entwickler weniger festgefahren und unter Druck gesetzt. Bei einem Wasserfall-Ansatz ist jede Entwicklungsphase bedeutender als die Iteration und endet mit einer detaillierten Beschreibung des nachfolgenden Schritts.

Bei der agilen Entwicklung müssen die Teams eng miteinander kommunizieren und die Anforderungen und die Planung gemeinsam analysieren. Prüfer und Entwickler arbeiten zusammen. Der Schwerpunkt liegt auf der gemeinsamen Arbeit und nicht auf der Einstellung, „unseren Teil der Arbeit zu erledigen“. Anstatt sich auf persönliche oder Teamverantwortung zu fixieren, können sich die Mitarbeiter ausschließlich darauf konzentrieren, die Sprints einzuhalten und so schnell wie möglich ein Minimum an lebensfähigen Produkten zu liefern.

Darüber hinaus ermöglicht ein agiler Entwicklungsansatz die Anpassung an sich ändernde Anforderungen und erlaubt es den Teams, in regelmäßigen Abständen darüber nachzudenken, wie die Effektivität verbessert werden kann, und ihr Verhalten entsprechend anzupassen. Diese Denkweise motiviert die Teams, kontinuierlich nach Spitzenleistungen zu streben, und versetzt die Unternehmen in die Lage, auf neue Markttrends zu reagieren.

Das Produkt als etwas Lebendiges begreifen

Ein produktzentrierter Ansatz für die Softwareentwicklung sieht das Produkt als etwas Lebendiges, Atmendes, das Pflege braucht und sich weiterentwickeln kann, anstatt nur ein Start- und Enddatum zu haben. Der Schwerpunkt liegt dann nicht mehr nur auf der frist- und budgetgerechten Lieferung des Produkts, sondern auf der schnellen Bereitstellung des Produkts, auch wenn es noch nicht vollständig ist, und der effektiven Ausführung seiner Kernfunktionen.

Wenn sich die Erfolgskriterien ändern, ändert sich auch die Einstellung zur Entwicklung, und die Projektmitarbeiter können sich weiterhin auf die Erstellung eines großartigen MVP konzentrieren. Dann kann die Aufmerksamkeit auf die Einführung von Funktionen gelenkt werden, die von den Benutzern geschätzt werden, während gleichzeitig genügend Spielraum bleibt, um Änderungen vorzunehmen, ohne wieder zum Reißbrett zurückkehren zu müssen. Die Anreize und Motivationen der Produktentwicklung sind besser auf die intrinsische menschliche Motivation ausgerichtet, etwas zu entwerfen, das für die Benutzer einen echten Wert hat.

Traditionelle Projektmanagementprinzipien der Produktlieferung sind immer noch wichtig

Der Übergang zu einer produktorientierten Softwareentwicklung und -bereitstellung bedeutet nicht automatisch, dass bewährte Projektmanagementprinzipien aufgegeben werden. Die grundlegenden Aspekte wie die Abstimmung mit dem Unternehmen, die Unterstützung durch die Geschäftsleitung und das Änderungsmanagement sind für eine erfolgreiche Produktentwicklung und -bereitstellung nach wie vor unerlässlich.

Das Produkt muss den Benutzern einen eindeutigen Nutzen bieten, und es muss eine klare Rechtfertigung für die Entwicklung des Produkts geben. Alle Beteiligten müssen sich über die Ziele des Produkts im Klaren sein und wissen, welches Ergebnis sie erwarten. Die Erfolgskriterien – was den Erfolg ausmacht, auch wenn das Produkt noch nicht fertig ist – müssen herausgearbeitet werden. Zu diesem Zweck sollten die Teams die Schritte des Änderungsmanagements abgeschlossen und die Fähigkeiten des Produkts kommuniziert haben, bevor sie es einführen. Sie sollten proaktiv Benutzerfeedback sammeln, die Benutzerakzeptanz bewerten und diese Erkenntnisse nutzen, um nach der Markteinführung des Produkts Verbesserungen vorzunehmen.

Die Zeit für den Wechsel zur produktzentrierten Entwicklung ist gekommen

Unternehmen, die sich für eine produktzentrierte Entwicklung entscheiden, profitieren von einer schnelleren Markteinführung, einer engeren Interaktion mit den Kunden und einer größeren Transparenz und Zusammenarbeit zwischen den Entwicklungsteams. Insbesondere Unternehmen, die eine neue App oder ihre erste App entwickeln, können von der Möglichkeit profitieren, ein Minimum Viable Product auf den Markt zu bringen und das Interesse der Verbraucher an ihrer Marke zu wecken, ohne mehrere Monate oder sogar Jahre warten zu müssen. In einem dynamischen Geschäftsumfeld werden auch etablierte Unternehmen gut daran tun, die Produktzentrierung zu nutzen, um sich auf neue Trends einzustellen und aufkommende Chancen zu nutzen, um einen Wettbewerbsvorteil zu erlangen. Möchten Sie mehr über dieses Thema erfahren? Kontaktieren Sie uns; wir tauschen uns gerne mit Ihnen über Agilität und Produktzentrierung aus!

PROJEKT
PRODUKT
FUNDING Jährlich Kontinuierlich, mit häufigeren (z. B. alle 3 Monate) Kontrollpunkten zu Verschiebungen bei der Finanzierung und den Ressourcen
TIMELINE Diskret mit formalen Anfangs- und Enddaten Kontinuierlich, wird als fortlaufend angenommen; keine festen Enddaten, obwohl das Produkt aus dem Verkehr gezogen werden kann
TEAMING Gemischt – Orchestrierung über Abteilungen und technische Bereiche hinweg, aber mit funktionalen Teams, denen die Ressourcen gehören Multidisziplinarität – ein Großteil des Teams arbeitet Vollzeit an dem Produkt und bricht die Silos der funktionalen Spezialisierung auf
METRICS Pünktlich/Budget, obwohl IT-Organisationen, die reifer sind, Projekte auf der Grundlage von Geschäftsergebnissen messen können Kundenzufriedenheit, Gewinn, Marktanteil
(geschäftsspezifische Kennzahlen)

source: Gartner (May 2017)

Fandest du das nützlich?

YES

TEILEN SIE DIESES HEISSE THEMA

Thank you for your feedback! Would you like to receive our newsletter?

 

Your email address is only used to send our newsletter and information about our activities. You can use the unsubscribe link integrated in each of our emails at any time.

[caldera_form id=“CF5d7f42f68941b“]

General Terms of Use
When you visit our website, it may store information through your browser from specific services, usually in form of cookies. Here you can change your privacy preferences. Please note that blocking some types of cookies may impact your experience on our website and the services we offer.