Mein Name ist Maxim und seit acht Jahren arbeite ich in großen Unternehmen als Business Analyst und Product Owner. Heute möchte ich Ihnen meine Gedanken zur Produktentwicklung mitteilen, die unter Einsatz einer großen Anzahl von Entwicklerteams organisiert wurde.
Diejenigen, die interessiert und bereit sind, über dieses Thema zu sprechen - willkommen unter Katze.
Beginnen wir mit den großen Unternehmen. Mit großen Unternehmen meine ich Unternehmen mit Tausenden von Entwicklern, Testern, Analysten, Entwicklern, Produktbesitzern und anderen Personalmanagern. Dies sind Dutzende von Abteilungen, Hunderte von Teams, komplexe Hierarchien, endlose Abhängigkeiten und Verantwortungsbereiche.
Wenn man in ein solches Unternehmen einsteigt, ist es zunächst schwierig zu navigieren. Aber die Zeit vergeht und jetzt können Sie sich Ihre "Insel" vorstellen. In der Regel sind dies:
- Ein verständliches System oder eine verständliche Komponente, die an einem sehr großen und komplexen Geschäftsprozess beteiligt ist;
- Der Product Owner ist eine Person, die zweifellos weiß, wo dieses System zu entwickeln ist.
- Eine Reihe von Dokumentationen in unterschiedlichem Relevanzgrad;
- Eine Reihe von Tests, automatisiert und nicht sehr.
Klingt bekannt?
So sieht ein typisches und nicht das schlechteste Softwareentwicklungssystem aus. In der Regel kommen Entwicklungsabteilungen von Unternehmen mit erfolgreichen Produkten in 10-15 Jahren zu dieser Form. Erfolgreiche Produkte bringen Geld ein, Geld wird in die Entwicklung investiert. Die Entwicklung wächst sprunghaft, sie ist linear skaliert und führt zu einer Situation, in der Projektmanager nicht mehr alle Abhängigkeiten im Kopf behalten können, viele Teams beginnen, die "Decke" über sich zu ziehen und manchmal das Produkt zu beschädigen anstatt es zu entwickeln. In einer solchen Situation ist es ganz normal, dass ein Team nach seinem eigenen Erfolg strebt und sich keine Sorgen mehr macht, dass seine Kollegen Probleme haben, und dass ihre gemeinsame Funktion aus diesem Grund nicht bereitgestellt wird. Es liegt in der Natur der Sache, die Funktionalität zu entwickeln, die endlose Stakeholder am lautesten verlangen, und nicht die, die Benutzer benötigen.Entwicklung "auf dem Tisch" ist keine Seltenheit. Der Prozess geht weiter - Anforderungen kommen, werden implementiert, getestet, geliefert. Es ist einfach, die Hauptsache hinter einem Trubel zu verstecken - die Produktentwicklung ist bei weitem nicht mehr so effektiv wie früher.
Um diesen Effizienzverlust zu verstehen, wenden wir uns den Klassikern des Produktmanagements zu. Jetzt gibt es genug Online-Schulen oder Universitäten, die Ihnen diese Wissenschaft für etwas Geld beibringen können.
Meine kleine Liste, wenn Sie sie nicht kannten
Nach den "Klassikern" kaufen die Leute also ein Produkt. Die Aufgabe eines Produktmanagers besteht darin, die Zielgruppe zu finden, die Wertbotschaft zu bestimmen, geeignete Vertriebskanäle auszuwählen, die Wirtschaft zu reduzieren, Wachstumspunkte zu finden und alle geeigneten Hypothesen zu sortieren. Ändern Sie bei Bedarf die Idee, die Zielgruppe, die Kanäle, die Botschaft, das Geschäftsmodell und den Markt. Oder töten Sie das Produkt sogar, wenn klar ist, dass es keine vorhersehbaren Aussichten hat.
Klingt nicht nach der obigen Geschichte, oder?
Der Punkt ist, wenn Sie ein kleines Startup sind, sind alle Produktentwicklungsprozesse ziemlich transparent und unkompliziert. Es ist sehr einfach, das Problem zu erkennen und zu beheben. Die Idee des Produkts ist leicht zu verstehen. Es ist einfach, die erforderlichen Funktionen zu verstehen und zu entwickeln. Benutzer - hier sind sie zur Hand. Prod - hier ist es mit allen Metriken.
Mit der Zeit gewinnt das Produkt jedoch erfolgreich Marktanteile, entwickelt sich zu einer Produktlinie, es werden immer mehr Entwickler eingestellt, und bevor Sie es wissen, verwandelt sich Ihr Unternehmen in ein riesiges Durcheinander von Strukturen, Interessen und Verantwortlichkeiten.
- Benutzerdefinierte Produktbenutzer? Jetzt erinnern sich Ihre Produktbesitzer nicht mehr an sie, sondern eilen von einem Stakeholder zum anderen und versuchen zu verstehen, welche Anforderungen zuerst zu erfüllen sind.
- War die Einheitsökonomie klar und transparent? Jetzt berücksichtigen die Besitzer des Produkts nicht einmal PnL (Profit and Loss) und laden das gesamte Team mit Seiten mit zweifelhaften Vorteilen auf den Sprintboden.
- Gab es eine Jobgeschichte, eine Customer Journey Map und andere Personen? Jetzt schreiben sie im Laden: „Als Produktbesitzer möchte ich, dass dies getan wird, weil die Abteilung für Betrieb und Wartung dies benötigt.“
- Gab es ein Verständnis der Verantwortung für das Ergebnis und die Bedingungen? Jetzt ist jedes Team für sich. Ihre Funktionen werden für ein oder zwei Releases später an die Produktion geliefert.
Die Komplexität des Entwicklungsmanagements für Großprodukte wächst exponentiell. Was ist zu tun?
Das erste, was dem Top-Management in den Sinn kommt, ist, dass wir ein magisches Framework benötigen, mit dem dieses gesamte komplexe System wie eine Schweizer Uhr funktioniert. Es gibt Nachfrage - es gibt Angebot. Ich kenne mehrere solcher Rahmenbedingungen, die theoretisch die anstehende Aufgabe bewältigen können.
Sind sie eine "Silberkugel"?
Ich habe mehrere geschäftliche Veränderungen durchlaufen, bei denen goldene Trainer eingestellt und die modernsten Management- und Kommunikationsprozesse eingeführt wurden. Tausende von Menschen wechselten über Nacht ihre Position und zogen in eine neue Struktur, ein neues Team, neue Prozesse, neue Projekte.
Und ich kann folgendes sagen:
- ist es teuer;
- es ist nicht schnell;
- es ist sehr riskant;
- Der endgültige Erfolg hängt in hohem Maße von der Unternehmenskultur ab. Wenn Menschen verstehen und glauben, ist Erfolg wahrscheinlich.
Ist dieser Ansatz der einzig richtige? Mal sehen, was Sie sonst noch tun können.
Ich glaube, es gibt andere Möglichkeiten, die Produktentwicklung zu skalieren. Leider habe ich keine Schritt-für-Schritt-Anleitung für Sie, aber hier sind meine Ideen, die Ihnen dabei helfen könnten:
Produkt . Das Produkt muss Mehrwert schaffen. Betrachten Sie den Zoo Ihrer Systeme und Komponenten in Bezug auf den Wert. Markieren Sie alle Wertströme für Endkunden, Gegenparteien oder Dritte und teilen Sie die Systemzuordnung durch solche Ströme. Jeder Product Owner muss eine vollständige Wertschöpfungskette unter Kontrolle haben. Geben Sie ihm ein paar Analysten, wenn der Verantwortungsbereich zu groß ist.
Metriken... Um zu verwalten, müssen Sie zuerst lernen, wie man misst. Jeder Produktbesitzer muss Metriken für sein Produkt identifizieren, auf deren Grundlage er die Entwicklung dieses Produkts durchführen wird.
Benutzer . Lassen Sie uns die Stakeholder beiseite legen. Nur Benutzer können eine echte Vorstellung vom Wert eines Produkts geben. Der Product Owner sollte sich von den Ergebnissen der Interviews und der Analyse der Support-Tickets in seinen Hypothesen leiten lassen.
Hypothesen . Keine blinden Implementierungen der Funktionalität mehr. Jedes Epos oder Feature sollte Erwartungen an die Auswirkungen auf Metriken haben. Wenn Produktbesitzer Funktionen implementieren und mit A / B-Tests testen, müssen sie verstehen, ob die Hypothese erfolgreich war oder nicht.
Koordinierung... Natürlich muss die Arbeit mehrerer Produkte gemäß dem von Ihnen gewählten Rahmen koordiniert werden. Sie sollten diese Koordination jedoch nicht in ein kollektives Verantwortungsgremium von Produktmanagern verwandeln.
Ich glaube, dass Sie das Produktmanagement nur unter Beibehaltung der oben beschriebenen Bedingungen erfolgreich skalieren können, und im Großen und Ganzen spielt es keine Rolle, welchen Rahmen Sie für diese Skalierung wählen.