Der zweite Teil mit meinen Fehlern, der erste
hier .
Ich möchte Sie daran erinnern, dass ich der Eigentümer des Produkts in einem Team bin, das ausschließlich aus Entwicklern besteht, und dass wir eine IT-Plattform für die Verwaltung von Affiliate-Netzwerken von Tankstellen erstellen.
Fehler vier.
Busfaktor: Was auf den ersten Blick nach vielen Fehlern aussah, stellte sich jedoch als klarer Jackpot für das Team heraus
8 Personen zu rekrutieren, die sich ohne Tester und zunächst ohne Analytiker überhaupt nicht ersetzen können? Es scheint, dass ich verrückt geworden bin und beschlossen habe, das Produkt zu versenken.
Tatsächlich muss ich 6 verschiedene Gruppen von Diensten erstellen, für jede von ihnen gibt es bereits „Best Practice“, die schnell und einfach bereitgestellt werden können. Der Markt erfahrener Entwickler ist groß.
Was bedeutet ein solches
Team für mich ? Die Fähigkeit, schnell ein Team mit den richtigen Kompetenzen zu finden, MVP schnell einzusetzen und Geschäftshypothesen zu validieren und diese sehr freie Nische auf dem Markt zu besetzen.
Was ist das
für das Team ? Auf der Anfangsebene gibt es viele verschiedene Kompetenzen, die sie miteinander teilen können, die Fähigkeit für jedes Feature, die schnellstmögliche Lösung zu verwenden, und vor allem lernen sie ständig etwas Neues, und dies ist, wie Sie sehen, selbst für Senioren interessant. (Zumindest mein Entwicklungsteam teilt diese Prinzipien).
Während des Testens von Geschäftshypothesen arbeitet das Entwicklungsteam miteinander und beginnt im Laufe der Zeit, technische Hypothesen in sich selbst zu testen. In den Streitigkeiten wird daher die Zielarchitektur der vom TEAM erstellten Plattform und nicht nur ein Architekt gebildet. "All Architect" ist meiner Meinung nach eine Person, die nutzlos und teuer ist und nicht existiert :) Wenn ein Team die gleiche Verantwortung trägt, wird das Produkt zu einer gemeinsamen Idee, jeder jubelt ihm zu, ich habe keine Lust, die Verantwortung zu verlagern. Auf solch heikle Weise wächst das Team, trifft Entscheidungen, wie man das Produkt weiterentwickelt, Kompetenzen erweitert, Austauschbarkeit und Selbstorganisation erscheinen. Wir haben diesen Weg noch nicht passiert, aber früher oder später werden wir passieren. Natürlich erweitern wir das Team jetzt zu einem engagierten Tester, aber zu Beginn ist das Team durchaus in der Lage, diese Funktion selbst zu erledigen.
Ja, es ist einfacher, 6 Java-Entwickler zu nehmen, und jetzt sind sie sofort austauschbar, aber schnell von Grund auf werden sie kein funktionierendes Produkt herstellen und werden durch ihre Kompetenzen stark eingeschränkt.
Übrigens ist es äußerst schwierig, Eigentümer eines IT-Produkts zu sein, ohne Erfahrung in derselben IT zu haben, beispielsweise als Entwickler, Systemanalytiker oder Berater (außer Projektmanagern), und selbst wenn Sie einen Architekten-Guru haben, wird es sein Produkt sein, nicht Ihr Produkt . Hier kann man argumentieren, aber die Praxis und Statistik sind wie folgt.
Fehler fünf.
Es ist unpraktisch für mich, andere werden es nicht mögen
Unser Team fragte oft: "Wer braucht das?", "Der Kunde möchte es so", "Es ist definitiv unpraktisch, weil es mir nicht gefällt" und so weiter. Zu Beginn können Sie natürlich an den Kunden denken, ihm etwas anbieten und basierend auf dem Feedback den Rückstand ausfüllen. Die Hauptsache hier ist, eine qualitative Studie durchzuführen und Schmerzen zu hören, keine vorgefertigten Lösungen, sonst werden sie nach einem „schnelleren Pferd“ und nicht nach einer perfekt funktionierenden Maschine fragen.
Es ist notwendig, das Team in die Schmerzen des
Kunden einzutauchen, die
Kunden und das Team zur Pflege anzurufen, dem Team die Kontakte der Kunden zu geben, die sie jederzeit um eine Meinung bitten oder die Funktionalität schnell überprüfen können.
Ich begann mir öfter zu sagen: „Probieren Sie niemals die Rolle eines Kunden an, wenn Sie nicht an seiner Stelle waren, und lassen Sie das Team dies nicht tun.“ Warum vergeblich streiten, wenn Sie die Person fragen können, für die Sie dies tun?
Fehler sechs.
Niemand braucht Prototypen
Ein sehr großer Fehler für einen Anfänger-RO besteht darin, keine Prototypen zu erstellen oder Hypothesen zu testen. Ich möchte schnell das Schöne und sofort das Produktive schaffen.
Wenn der Klient Schmerzen hat: Er sieht die Sterne nachts wegen schlechten Wetters nicht und Sie schaffen sofort ein Raumschiff für ihn, versuchen, seine Erwartungen zu übertreffen und 100-mal besser zu werden, als er es sich hätte vorstellen können, dann ist dies ein klarer Fehler. Er hatte eine andere Aufgabe, Schmerzen und Wünsche.
Sie können drei Tage oder eine Woche damit verbringen, von Hand zu zeichnen, wie das Produkt aussehen wird, und es auch dem Kunden zeigen. Bitten Sie ihn, herauszufinden, wie er es verwenden wird, und vergessen Sie nicht, es jedes Mal zu tun, wenn Ideen in das Produkt-Backlog übertragen werden.
Nun, als Sie ein brillantes Feature entwickelt haben, das als Prototyp erstellt wurde, klatscht Ihr Benutzer in die Hände und möchte es wirklich - nein, Sie können es immer noch nicht zum Laufen bringen :) Vergessen Sie nicht die Metriken der Features, sowohl für Lebensmittel als auch für Unternehmen. Metriken sind im Allgemeinen eine besondere Geschichte mit Fehlern - mehr dazu später und ausführlicher in der nächsten Folge. Während die Ankündigung ...
Fehler sieben.
Metrik der Allmacht
Ich möchte Sie daran erinnern, dass unser Team Teil eines sehr großen Startups in einem großen Unternehmen ist. Der Umgang mit Produktmetriken mit Stakeholdern war schwierig. Es ist eine schlechte Idee, eine Geschäftsmetrik auf eine IT-Lösung zu setzen, die sich noch in der Entwurfsphase befindet. Investoren müssen jedoch ihre Arbeit zeigen, auch wenn es für den Benutzer noch keine Zuwächse gibt.
Alle Geldkennzahlen werden sowohl Sie als auch das Team demotivieren, aber genau auf diese werden die Stakeholder achten wollen. Und jetzt sind Sie bereits auf der rutschigen Spur PI und streben souverän nach unten. Sie können diese Metrik nicht im positiven Sinne beeinflussen. Und in jeder Hinsicht sieht das Produkt von nun an ineffizient und unrentabel aus.
Wenn Sie keinen Fehler Nummer 6 gemacht haben, haben Sie jede Möglichkeit, Stakeholder zu überzeugen, den Prototyp zu verwenden und den Benutzern zu zeigen, Feedback zu sammeln und Attraktivitätsmetriken aufzuhängen. Machen Sie die Entwicklung so transparent wie möglich, zeigen Sie, was Sie an diesem Prototyp tun, welche Schaltfläche oder welches Formular funktioniert, was Sie damit tun können und wie Sie einen schönen Zeitplan verwenden, der sehr bald erscheinen wird. Die Hauptsache hier ist, nicht zu viel zu
versprechen und alle Ihre
Versprechen zu halten.Zusammenfassung der Schlussfolgerungen:
- Versuchen Sie es zuerst, wenn Sie es möchten - gehen Sie zur RO-Schule
- Sie sind nicht unsterblich, greifen nicht alles auf einmal und rekrutieren ein Team, dem Sie vertrauen können
- Du brauchst definitiv einen Scrum Master. Auf die Vollzeit.
- Nutzen Sie die Chance. Das Scrum-Team wird früher oder später austauschbar, und Geschäftshypothesen liegen nicht auf dem Boden. Es ist besser, mit Ihrem MVP schneller einen freien Platz auf dem Markt einzunehmen, wenn auch mit den Risiken des Bassfaktors zu Beginn, als keine Zeit dafür zu haben.
- Kommunizieren Sie mehr mit dem Klienten, erinnern Sie sich an seine Schmerzen und versuchen Sie, sie zu lösen.
- Hinterfragen Sie alle Ihre Ideen, erstellen Sie Prototypen und testen Sie Hypothesen, schauen Sie sich die Reaktion des Kunden an, wir sind hier, um zusammenzukommen :)
- Wählen Sie die Metriken selbst aus. Sie sollen Ihnen dabei helfen, ein qualitativ hochwertiges und iterativ gutes Produkt zu erstellen. Denken Sie daran, dass es aufgrund mangelnder Qualität viele Produkte im "Death Valley" gibt.