Wir haben keine Einigung darüber, wie wir diesen Prozess angehen sollen.
Die Eigenschaften dessen, was wir bauen:
Angesichts dieser Misere bin ich der Meinung, dass wir zusammensitzen (vielleicht für ein oder zwei Tage) und eine Matrix gemeinsamer Probleme erstellen, mit denen das Unternehmen konfrontiert ist (ich glaube, wir nennen dies Business Case) und ihre Lösungen aufschreiben - also die traditionelle Business-Lösung (mit Vor- und Nachteilen), die Problemlösung unseres Produkts (mit Vor- und Nachteilen). Wir können dies festhalten, indem wir es mit Interessenvertretern überprüfen lassen.
Wenn Sie dies posten, können wir mit der Aufgabe beginnen, User Stories, Wireframes usw. zu erstellen.
Allerdings bauen wir die User Stories tatsächlich mit einigen Business Cases auf, die uns insgesamt nicht von der Akzeptanz des Systems überzeugen können oder eine falsche Akzeptanzannahme geben.
Was ist der eigentliche Weg?
Alle diese Projekte sollten mit einem Business Case (BC) beginnen. Der BC sollte das Problem angeben, das Sie lösen möchten, oder die Gelegenheit, die Sie nutzen möchten. Es sollte die Kosten für die Durchführung des Projekts (in Form von Ressourcen und Barmitteln) und die Vorteile angeben, die das Unternehmen nach Ansicht des Unternehmens aus der Durchführung des Projekts ziehen wird. Da die Art des Produkts in Ihrem Fall nicht definiert ist, schlage ich ein kleines Vorprojekt mit eigenem Budget vor, um eine Kunden- und Produktanalyse durchzuführen, um festzustellen, wie das Ergebnis aussehen könnte und welche Funktionen es enthalten muss. Das Ergebnis des Anforderungsanalyseprojekts sollte der BC für das Implementierungsprojekt sein.
Alle BCs sollten vom Unternehmen überprüft, genehmigt und abgezeichnet werden. Sie sind Ihre Zustimmung zum Fortfahren und die Zuweisung des Budgets, um die Arbeit zu erledigen. Sobald Sie dort sind, befinden Sie sich im einfachen Projektmanagement. Wie Sie das Projekt (und damit das Produkt und andere Leistungen) bereitstellen, hängt von Ihren lokalen Präferenzen ab (z. B. Agile/Wasserfall/ein anderes Modell).
Beginnen Sie mit dem Bau eines BC, das stapelbar ist (dh es bringt Ihrem Unternehmen mehr Nutzen als die Kosten für den Abschluss des Projekts – einfach ausgedrückt bringt es mehr Geld ein, als der Bau kostet).
Legen Sie dann im Rahmen des Gesamt-BC die Merkmale des Projekts fest und trennen Sie sie, wenn möglich, nach MOSKAU, dh Must Have, Should Have, Could Have.
Holen Sie sich Ihr Budget. Führen Sie das Projekt aus. Liefern Sie das Produkt. Verdienen Sie Geld (oder messen Sie Ihre Nutzenrealisierung)
Aufgrund meiner Erfahrung im Management neuer Produktentwicklungen denke ich, dass der erste Schritt darin bestehen sollte, einen Markteinführungskunden zu finden.
Kein Launch-Kunde = kein Referenzfall, kein Insiderwissen, IT-getriebenes Produkt, wird sich in einem gesättigten Markt kaum durchsetzen.
In Ihrem Fall würde ich empfehlen, sich mindestens zwei zeit- und kostenfreudige Startkunden zu suchen, da der Anforderungsmix zu unterschiedlich ist und Sie sonst auf eine kundenspezifische Lösung stoßen könnten. Alternativ können Sie sich für eine Person entscheiden, die über Insiderkenntnisse der Branche verfügt, bei potenziellen Kunden gearbeitet hat und über Produktmanagementfähigkeiten verfügt und bereit ist, sich auszutauschen.
Der Rest ist nur der Aufbau eines Business Case mit MoSCoW, agil oder was auch immer, aber immer die Startkunden als Partner an Bord. Viel Glück!
Für mich klingt es so, als ob Sie damit zu kämpfen haben, dass Sie nicht wirklich einen Product Owner für diese Software definiert haben. Bei der Softwareentwicklung, selbst wenn Sie marktorientierte Software schreiben, muss jemand die Rolle des Produktbesitzers bei der Entwicklung Ihrer Software vertreten. Andernfalls entwickeln Sie ziellos und haben letztendlich keine Möglichkeit zu wissen, ob Ihr Code für irgendjemanden einen Mehrwert bietet – einschließlich der Personen, die ihn entwickeln. Product Ownership ist ein kritischer Aspekt der Softwareentwicklung – sobald Sie das festgestellt haben, würde ich persönlich in Betracht ziehen, eine Art agile Entwicklungsmethodik zu verwenden, damit Sie flexibler auf die Bedürfnisse des Product Owners reagieren können.
InfoQ hat hier eine gute Diskussion darüber, wofür ein Product Owner verantwortlich ist: Product Owner Patterns
Eines der entscheidenden Dinge, auf die Sie achten müssen, ist, dass Sie über ein priorisiertes Produkt-Backlog verfügen. Ohne eine Product Ownership-Rolle ist nicht zu erwarten, dass es einen Rückstand an wichtigen Dingen gibt, an denen gearbeitet werden muss.
Als allgemeine Ressource für Entwicklungspraktiken empfehle ich auch diesen Blog, geschrieben von den Entwicklern bei Etsy: Code as Craft