In , dem ersten Teil dieser Serie, haben wir die zahlreichen Probleme im Zusammenhang mit dem traditionellen Projektfinanzierungsmodell behandelt und darauf hingewiesen, dass Unternehmen sich von Projekten ab- und dem Produktmodell zuwenden müssen. Lassen Sie uns nun auf die Einzelheiten eingehen: warum diese Veränderung so wichtig ist.
Warum von Projekten zu Produkten wechseln?
Das Produktmodell bietet einen alternativen Ansatz, der Unternehmen dabei hilft, mehr Wert zu schaffen, und zwar schneller und mit einem höheren Maß an nachhaltiger Qualität, indem die oben genannten Probleme angegangen werden. Darüber hinaus legt die Produktmentalität auch mehr Wert auf Innovation und Verbesserung, was dazu beiträgt, dass sich das Unternehmen an den Bedürfnissen der Kunden orientiert. Dies geschieht durch die Abkehr von zeitlich befristeten Teams, die mit ausgeliehenen Mitarbeitern besetzt sind, und deren Ersatz durch semi-permanente, funktionsübergreifende Teams, die sich aus Fachleuten aller relevanten Abteilungen zusammensetzen, wobei jedes Team auf ein Produkt oder einen Wertstrom des Unternehmens ausgerichtet ist.
Das Ziel des Produktmodells (oder Wertstrommodells) besteht darin, Teams zu bilden, die in der Lage sind, mindestens 80% der ihnen übertragenen Arbeit ohne zusätzliche Unterstützung zu erledigen. Daher ist es üblich, dass Softwareentwicklungsunternehmen, die diesem Modell folgen, über Teams verfügen, die aus folgenden Mitgliedern bestehen:
- Produktmanager
- Designer
- Front-End- und Back-End-Entwickler
- Qualitätstester
- Personal für den Einsatz
- Jeder andere, der den Großteil der Arbeit abliefern muss
Auf diese Weise entstehen autarke Teams die in der Lage sind, in allen Phasen der Produktentwicklung zu arbeiten, von der Vision bis zur Wertschöpfung, ohne dass zusätzliche Unterstützung benötigt wird. Darüber hinaus ist die Verlagerung des Schwerpunkts von Projekten auf die Produktentwicklung nützlich, um Abteilungssilos aufzubrechen und ein System zu schaffen, das eine echte Zusammenarbeit fördert.
Anstatt Mitarbeiter für zeitlich begrenzte Einsätze auszuleihen, werden die Teams in eine gesunde Situation versetzt, in der ihr Ziel nicht einfach darin besteht, Projekte abzuschließen, sondern zusammenzuarbeiten, um sicherzustellen, dass für ihr Produkt oder ihren Wertstrom konstant hohe Qualität geliefert wird, und dass sie über das Fachwissen und die Beziehungen verfügen, um sicherzustellen, dass die Ergebnisse optimal auf die Bedürfnisse des Kunden abgestimmt sind.
Unter dem SAFe®-Modell bestehen diese Teams in der Regel aus etwa 10 Personen, und die Arbeit wird dem gesamten Team zugewiesen, nicht einzelnen Mitgliedern. Die Teams arbeiten nach Scrum oder Kanban, aber die Mitglieder von sind immer im selben Team, unabhängig von der Arbeitsleistung.
Es ist wichtig, dafür zu sorgen, dass die Mitarbeiter nicht mit mehr als einem Team zusammenarbeiten, da dies dazu führt, dass die Abteilungen miteinander um Kapazitäten konkurrieren, was die Mitarbeiter daran hindert, ihre Zeit und ihre Bemühungen auf die effektive Erledigung ihrer Arbeit zu verwenden.
In einem kleineren Unternehmen mit kleineren Produkten und einer modernen, entkoppelten Technologiearchitektur sind diese autonomen, funktionsübergreifenden Teams möglicherweise alles, was man braucht, um geschäftliche Agilität zu erreichen. Aber in vielen Fällen haben größere Unternehmen mit großen, komplexen Produkten mit veralteten Architekturen zu tun, die wirklich viele koordinierte Teams erfordern, die zusammenarbeiten, um einen echten Mehrwert zu liefern. In diesem Fall werden die agilen Teams in "Teams von Teams" gruppiert. SAFe nennt diese Agile Release Trains (kurzARTs ). Sie werden als Flights, Stämme, Wings und eine Reihe anderer lokaler Begriffe bezeichnet, aber in jedem Fall bestehen sie in der Regel aus 5-12 Teams und 50-125 Personen, die an gemeinsamen technologischen und geschäftlichen Zielen arbeiten, damit das Unternehmen auf Veränderungen reagieren und effektiver Werte liefern kann.
Das Ergebnis ist ein Geschäftsmodell, bei dem Feedback und Anpassungsfähigkeit Vorrang vor vorausschauender Planung haben. Auf diese Weise sind Unternehmen besser in der Lage, sich an den Bedürfnissen und Erwartungen ihrer Kunden zu orientieren, so dass sie einen Mehrwert bieten und Schmerzpunkte effektiver angehen können.
Kapazität umverteilen?
Auch wenn Teams im Produktmodell über einen längeren Zeitraum zusammenarbeiten und auf eine Geschäftsdomäne ausgerichtet sein sollen, heißt das nicht, dass sie ewig arbeiten. Es ist immer noch sinnvoll, die produktiven Kapazitäten dort zu konzentrieren, wo sie dem Unternehmen am meisten nutzen.
Beim Modell der Projektfinanzierung erfolgt diese Neuzuweisung, wenn Projekte auslaufen, alte Teams aufgelöst und neue für neue Aufgaben gebildet werden.
Bei dem Produktmodell geht es darum, die Kapazität in einem bestimmten Rhythmus auf der Grundlage der Geschäftsergebnisse neu zuzuweisen.
Organisationen, die SAFe® und anderen skalierten agilen Modellen folgen, stellen ihre Teams und Teamteams so weit wie möglich auf einen gemeinsamen Rhythmus ein. Zweiwöchentliche Scrum-Sprints werden synchronisiert. Mittelgroße, etwa vierteljährlich stattfindende, große Raumplanungsereignisse werden ebenfalls synchronisiert. Diese Kadenzen machen die Koordination innerhalb der Teams und mit den Kunden viel einfacher. Sie bieten auch perfekte Haltepunkte, um Kapazitäten zwischen Produkten oder Wertströmen mit minimaler Unterbrechung zu verschieben.
Aber woher weiß man, ob oder wohin man die Kapazität verlagern soll?
Ergebnisse statt Output
In einem Produktmodell sollte jedes Produkt oder jeder Wertstrom eine Reihe von Frühindikatoren und Trichtermetriken festlegen, die für den jeweiligen Aspekt des Geschäfts sinnvoll sind. Diese sollten letztendlich zu Einnahmen oder Einsparungen oder einer anderen Kennzahl unter dem Strich führen. Aber diese P&L Arten von Kennzahlen sind oft zu langsam, um für die Steuerung nützlich zu sein. Es dauert viele Quartale, bis sie sich deutlich genug bewegen, um uns zu sagen, wie die Dinge laufen. Frühindikatoren und Trichtermetriken sind nicht so eindeutig, aber sie ändern sich viel schneller und liefern uns Daten für die Entscheidungsfindung.
Beispiele für Frühindikatoren sind:
- die Anzahl der Personen, die einen neuen oder veränderten Aspekt eines Systems nutzen
- die Zeit, die sie auf einem bestimmten Bildschirm verbringen
- die Belastung des Systems durch die Benutzer, die von unseren Überwachungssystemen angezeigt wird
- die Anzahl der Support-Tickets (mehr oder weniger), die sich auf verschiedene Aspekte des Systems beziehen, die wir geändert haben
- Kommentare in sozialen Medien
Wenn wir Änderungen an unseren Produkten vornehmen, können wir, sofern wir in ausreichende Instrumente investiert haben, sehr schnell feststellen, ob unsere Kunden die Verbesserungen bemerkt und genutzt haben und ob sie sie überhaupt als Verbesserungen ansehen. Gute Frühindikatoren sind kein Beweis dafür, dass wir bessere finanzielle Ergebnisse erzielen werden, aber sie deuten darauf hin, dass wir einen Mehrwert für unsere Kunden geschaffen haben. Und das Fehlen von Frühindikatoren sollte ein deutliches Zeichen dafür sein, dass wir Geld verschwenden und unsere Annahmen überdenken sollten.
Wenn wir alles richtig machen, werden die Frühindikatoren zu mittelfristigen Ergebnissen führen, die zwar immer noch nicht die traditionellen P&L-Metriken sind, aber viel mehr mathematisch auf halbwegs vorhersehbare Weise miteinander verbunden sind. Für ein typisches SaaS-Softwaregeschäft könnte ein Trichter etwa so aussehen:
- Eine bestimmte Anzahl von Besuchern der Website lädt eine Art von Inhalt herunter
- Ein gewisser Prozentsatz dieser Personen wird sich für eine Testversion des Produkts anmelden.
- Von den erstellten Testkonten ist ein gewisser Prozentsatz auch nach einigen Tagen noch aktiv.
- Von diesen aktiven Testpersonen wird sich eine gewisse Anzahl mit unserem Verkaufsteam in Verbindung setzen, um ein Kaufgespräch zu führen.
- Wir wandeln einen bestimmten Prozentsatz dieser Konten nach einer durchschnittlichen Anzahl von X Tagen in zahlende Konten um.
- Unser typisches neues Konto beginnt mit Y Nutzern und wächst in der Regel innerhalb eines Jahres auf Z Nutzer an.
- Und bei einem durchschnittlichen Sitzplatzpreis bedeutet das, dass wir im Jahr 1 eines Kontos einen gewissen Betrag an Einnahmen generieren werden
Wir könnten die Idee noch weiter ausbauen, aber Sie haben die Idee. Jedes dieser Verhältnisse wird unvollkommen sein. Aber sie werden so vorhersehbar sein, dass wir einigermaßen abschätzen können, wie sich eine Veränderung der Ergebnisse im oberen Teil des Trichters auf die Ergebnisse im unteren Teil auswirken wird. Anstatt jede potenzielle Aufgabe unabhängig voneinander zu bewerten, wenn ein Business Case auf unserem Schreibtisch landet, können wir unsere Bemühungen auf Veränderungen ausrichten, die sich auf unseren Trichter auswirken werden. Und jeder kennt den Trichter, so dass jeder in unseren Teams besser in der Lage ist, seine Bemühungen auf Ergebnisse zu konzentrieren, die dem Ganzen zugute kommen.
Investieren, wo wir echte Ergebnisse sehen
Over time, we can use these funnel metrics to drive decision making within our teams and the product or value stream they support. We can also use them to help decide where to shift capacity. If one area of our business has had 10 teams for a year and generated flat results in their funnel metrics and another has had half that capacity and produced 50 % improvements, wouldn’t it make sense to move some teams? We may not know exactly which features produced those results. It doesn’t necessarily mean the people managing the first value stream are making bad decisions. But we can clearly see where we have productive investment opportunities and where we don’t. And we can shift teams accordingly.
Der produktorientierte Ansatz gibt Teams und Einzelpersonen mehr Verantwortung für ihre Arbeit und ihre Aufgaben. Da die Mitarbeiter nicht ständig von einem Team zum anderen wechseln, haben sie ein größeres Verantwortungsgefühl. Den Mitarbeitern geht es nicht nur darum, die Arbeit zu erledigen und zum nächsten Projekt überzugehen, sondern auch um Innovation und kontinuierliche Verbesserung, denn bei einem Produktmodell sind die Teams für die Entwicklung, den Support und die Wartung verantwortlich, anstatt die Zuständigkeiten auf drei verschiedene Gruppen aufzuteilen.
Letztendlich ermöglicht das Produktmodell den Teams, von der spekulativen Planung zu einem adaptiven Ansatz überzugehen. Teams arbeiten zusammen, um durch kontinuierliche Verbesserungen auf der Grundlage der sich entwickelnden Bedürfnisse eines Kunden Werte zu schaffen. Dies wiederum schafft eine Unternehmenskultur, die der Wertschöpfung Vorrang vor der Fertigstellung von Projekten einräumt. Indem wir aussagekräftige Ergebniskennzahlen für unsere Wertströme festlegen, haben wir die Möglichkeit, Kapazitäten dorthin zu verlagern, wo sie am meisten Gutes bewirken können. Und indem wir die Vorteile der synchronisierten Kadenzen nutzen, haben wir eine minimal störende Möglichkeit, Menschen und Teams bei Bedarf zu bewegen.
Wenn Sie mehr darüber erfahren möchten, wie Planview die Umstellung von Projekten auf Produkte unterstützt, sehen Sie sich die Demo an oder laden Sie unser Whitepaper "Lean Portfolio Management for the Enterprise" herunter, um zu sehen, wie Unternehmen LPM nutzen, um den Wechsel zu einem produktzentrierten Modell zu vollziehen.
