Wir sind ein Unternehmen, das Formen und andere Werkzeuge herstellt, die unsere Kunden dann in ihren Maschinen verwenden. Mir wurde eine Reihe von Anforderungen zum Erstellen einer Webanwendung gegeben, von der jemand glaubt, dass unsere Kunden sie verwenden möchten.
Beim Requirements Engineering / BA-Arbeit / Stakeholder-Analyse wollte ich mich zurücklehnen und zuerst das Geschäftsproblem identifizieren, das die vorgeschlagene Anwendung lösen sollte. Die Sache ist: Niemand kann es mir sagen. Es wurde keine Kundenbefragung durchgeführt, der Vertrieb kennt keine Probleme, die die vorgeschlagene Webanwendung möglicherweise lösen könnte, das Marketing hat auch keinen Bedarf erkannt, der PM skizziert nur funktionale Anforderungen, anstatt das zugrunde liegende Problem (falls vorhanden) zu identifizieren.
Ich bin zu dem Schluss gekommen, dass die Erstellung einer Webanwendung für unsere Kunden nichts anderes ist als die Idee eines oder mehrerer (wahrscheinlich hochrangiger) Interessengruppen.
Ich denke, dass die Top-Manager für ein Treffen zur Verfügung stehen würden, bei dem ich mich möglicherweise nach dem Problem erkundigen könnte, aber:
Würde das nicht möglicherweise diejenigen ärgern, die ursprünglich die Entwicklung einer solchen Anwendung vorgeschlagen haben?
Wenn ich das richtig verstehe, denkt Ihr Unternehmen, dass Sie eine Anwendung für Ihren Kunden erstellen sollten. Der Kunde hat es nicht angefordert und Sie haben keine Bestätigung, dass das zu lösende Problem überhaupt existiert?
Wie Sie vorgehen, hängt wirklich davon ab, wo Sie in die Gesamtorganisation passen. Ich gehe davon aus, dass Sie ein Programm-/Projektmanager sind (angesichts dessen, was dieses Thema dieses StackExchange ist).
Ich gehe auch davon aus, dass es in Ihrem Unternehmen keine Struktur auf Portfolioebene gibt. Dies wäre der beste Weg, damit umzugehen. Das wird dieses Problem aber nicht lösen.
Wenn die Anforderungen von einem Produktmanager kommen, der Ihr Kollege ist oder Ihnen in etwa entspricht: Fahren Sie mit der Planung fort, damit Sie den Umfang der erforderlichen Ressourcen ermitteln können. Verwenden Sie dann die gleiche Anleitung wie unten, wenn die Anforderungen von einer älteren Person stammen.
Wenn die Anforderungen von jemandem in einer leitenden Position kommen (zwei oder mehr Ebenen über Ihnen): Sie müssen die Pothole School of Project Management praktizieren. Kurz gesagt, Sie müssen jemanden mit der Autorität und dem Interesse finden, sich zu informieren. Wenn zum Beispiel ein Engineering-VP die Anforderungen gestellt hat, versuchen Sie, den Sales-VP darauf aufmerksam zu machen. Der Verkäufer möchte keine Ressourcen für etwas verschwenden, das der Kunde nicht möchte, und er möchte den Kunden auch nicht verärgern, indem er den Fokus verliert oder etwas liefert, das er nicht möchte.
Der Grund dafür ist, dass Sie als Projektmanager (Programmmanager, Scrum Master usw.) keine direkten Befugnisse haben. Sie müssen mit Einfluss arbeiten. Wenn Sie versuchen, es direkt anzugehen, stehen die Chancen gut, dass Sie derjenige sind, der vom Bus überfahren wird. Die Projektmanagementfunktion wird selten als "Experte" angesehen, sodass sie bei Problemen bereits im Nachteil sind.
Und wie Tobias sagte, binden Sie den Kunden nicht ein. Selbst wenn Sie direkte Beziehungen haben, würden Sie interne Unternehmensinformationen besprechen, und das wird Ihre Glaubwürdigkeit gegenüber dem Kunden und Ihrem Unternehmen beeinträchtigen.
Viel Glück, würde gerne hören, wie es weitergeht.
Das Top-Management anzurufen, klingt fast so, als würde man jemanden in der Hierarchie ignorieren. Wenn der PM in der Lage ist, funktionale Anforderungen zu stellen, hat er zumindest einige geschäftliche Probleme oder Marktchancen im Auge - auch wenn der PM diese nicht formulieren kann, z
Gehen Sie wie folgt vor, um den Geschäftsbedarf zu ermitteln:
Die Sache ist: Niemand kann es mir sagen.
Es heißt Innovation. Ändere deinen Angriffswinkel. Sie scheinen getrieben zu sein, Anwendungsfälle usw. zu identifizieren, aber all dies kommt oft im Fluss des Projekts an. Dies ist auch das Gebiet von TDD, Test Driven Development .
Was Sie tun sollten, ist dies. Sie müssen alle Beteiligten auf dem Laufenden halten und versuchen, sie nach Möglichkeit von Zeit zu Zeit an einen runden Tisch zu bringen. Pflegen Sie einen Gesundheitsplan und eine Dokumentation Ihrer Arbeit, aber überarbeiten Sie ihn nicht. Verstehen Sie, wie Ihr Sponsor Ihre Rolle und Ihr Handeln sieht. Sie muss die Risiken und Auswirkungen unklarer und falscher Anforderungen usw. verstehen. Viel Glück.
Bearbeiten: Es wird dringend empfohlen, die Materialien von Karl Wiegers zu lesen .
Das Erstellen einer Vorlage oder das Finden eines Beispiels für gut geschriebene Anforderungen, die Sie mit den Teammitgliedern teilen können, hilft dabei, ein Mindestmaß an Qualität und Einheitlichkeit auf ganzer Linie zu erreichen. Darüber hinaus kann die Erstellung eines Glossars die Möglichkeit bieten, schlecht geschriebene Geschichten basierend auf einem gemeinsamen Vokabular abzulehnen. Wenn alles andere fehlschlägt, kann das Papier-Prototyping einer Implementierung basierend auf den Anforderungen die Lücken aufzeigen und das Team zur Hilfe motivieren.
Verweise
Jan