Aufgrund Ihrer Rede von Entwicklern und Produktbesitzern scheint es mir, dass Sie keine mittlere Person haben, die für die Funktionen in Ihrer Organisation verantwortlich ist.
Nun, in meiner Organisation bin ich diese Person. Ich bin der Anforderungsingenieur, der gelernt hat, wie man gute Spezifikationen erstellt und Funktionen auswählt, die zu einer hochwertigen Software mit benutzerfreundlichem Interaktionsdesign führen. (In anderen Organisationen ist es die UX-Person, die den gleichen Job bekommt. Sie kennen diesen Begriff möglicherweise besser).
Und ich kann Ihnen sagen: Es ist schwierig, eine gute Spezifikation zu erhalten. Natürlich hassen es Entwickler, das zu tun. Es ist eine Belastung für sie - sie sind dazu da, eine Software zu entwickeln, und nicht an Machtspiele zwischen Interessengruppen und die mentalen Modelle fauler Benutzer zu denken. Aber weißt du was? Dies ist auch eine Belastung für die Produktbesitzer. Sie wissen nicht besser, welche Funktionen ihre Software enthalten sollte, als die Entwickler oder Benutzer. Das Erstellen einer brauchbaren Spezifikation ist eine erlernte Fähigkeit, und wenn Sie sie nie gelernt haben, können Sie sie nicht gut beherrschen. Klar, es gibt viele Entwickler und Produktbesitzer, die das können, weil sie es in früheren Projekten tun mussten. Aber der durchschnittliche Produktbesitzer oder -entwickler hat Schwierigkeiten damit, weil es natürlich nicht seine Aufgabe ist, dies zu tun. Nicht jeder, der Auto fahren kann, kann ein Auto entwerfen. ähnlich,
Können Sie Software ohne einen Anforderungsingenieur entwickeln? Sicher kannst du. Es ist jedoch nicht fair und nicht gut für das Projektergebnis, das gesamte Gewicht der Spezifikation auf die Schultern des Produktbesitzers zu legen. Vor allem, weil er vor einer für ihn ungewöhnlich schwierigen Aufgabe steht, ist es sehr hilfreich, Input und Unterstützung von anderen zu erhalten. Wenn Sie sich in einer solchen Situation befinden, schauen Sie Ihren armen Produktbesitzer nicht an und sagen Sie "Sagen Sie mir, was ich für Sie machen soll, und ich werde Sie machen". Er weiß wirklich nicht, was er braucht. Aber ein Gespräch mit Ihnen wird ihm helfen, seine Gedanken zu artikulieren und seine Ideen zu erforschen.
Wenn in der Projektstruktur kein Anforderungsingenieur vorhanden ist, gibt es ein anderes Problem: Es gibt keinen Moderator. Alle Entwickler sind auf der technischen Seite, alle Produktbesitzer sind auf der geschäftlichen Seite. Wenn die beiden Kulturen aufeinander treffen, können Konflikte entstehen, bei denen jede Seite die andere dumm und unvernünftig beurteilt (weil sie ihr eigenes Wertesystem zur Beurteilung verwendet). Sprechen Sie mit Ihrem Produktbesitzer über mögliche Funktionen. Seien Sie jedoch höflich und geduldig, auch wenn Sie der Meinung sind, dass er dies nicht verdient. Der Projekterfolg hängt davon ab, wie gut Sie beide miteinander auskommen können. Manchmal ist es besser, eine suboptimale Entscheidung zu treffen, als aufgrund von Konflikten überhaupt keine Entscheidung zu treffen. Es kann hilfreich sein, eine Hierarchie einzurichten und einem von euch beiden das letzte Wort zu geben, da dies festgefahrene Konflikte verhindert. Wenn er das letzte Wort bekommt, verschiebe es, auch wenn du es für unfair hältst.
Über den "passiven" Teil: Wenn Sie keine Ideen haben, versuchen Sie nicht, sich etwas auszudenken, nur um Aktivität zu zeigen. Wenn der Produktbesitzer bereits unsicher ist und keine guten Kriterien für die Bewertung seiner oder Ihrer Ideen kennt, erschweren seltsame Ideen, "nur etwas zu haben", eine ohnehin schwierige Situation. Gute Feature-Ideen zu entwickeln ist keine Zauberei, sondern erfordert Wissen. Wenn Sie es nicht aus Lehrbüchern gelernt haben, werden Sie wahrscheinlich einige Jahre Entwicklererfahrung benötigen, insbesondere in Projekten, in denen Sie Benutzern oder benutzergenerierten Usability-Daten (Analysen, Zufriedenheitsmessungen) ausgesetzt sind, bevor Ihr Gehirn die Muster für sich selbst aussortiert und Sie beginnen zu bemerken: Es gibt ein Problem, das wir hier lösen können. Die Benutzer scheinen etwas auf dieser Seite zu vermissen, Was kann es sein? Dann haben Sie gute Ideen zum Teilen.
Fazit 1: In Projekten ohne Anforderungsingenieur ist es gut, Vorschläge zu machen, wenn Sie sie haben. Tun Sie es mit Fingerspitzengefühl und Fingerspitzengefühl - Konflikte müssen unbedingt vermieden werden, auch wenn dies bedeutet, dass Ihre gute Idee im Keim erstickt.
Und wenn Sie in einem Team mit einem Anforderungsingenieur arbeiten?
Ich liebe es, Feature-Ideen von allen zu hören! Ja, manchmal sind die Ideen der Entwickler schrecklich (wenn sie die Benutzeroberfläche der Programmierlogik folgen lassen wollen). Auch die Ideen von Produktbesitzern sind oft furchtbar (wenn sie Sonne und Mond in einem überschaubaren Budget haben wollen - oh, und der Benutzer soll Seiten mit persönlichen Informationen in höchster Datenqualität eingeben, ohne dafür eine Gegenleistung zu erhalten). Aber es ist meine Aufgabe, eine Spezifikation zu entwickeln, die für alle im Team gut ist. Und selbst wenn Ihre Idee niemals in die Tat umgesetzt werden sollte, macht sie mich darauf aufmerksam, dass Sie Bedenken haben. Sie haben möglicherweise die falsche Lösung für den Vorschlag ausgewählt, aber dies macht Ihre Bedenken nicht weniger berechtigt. Wenn Sie es entdeckt haben, muss es wahrscheinlich behoben werden (oder ich muss einen Grund nennen, warum es keine Bedrohung ist). Wenn Sie einen Anforderungsingenieur haben, der für die Spezifikation verantwortlich ist, zögern Sie nicht, Vorschläge zu unterbreiten. Wenn sie Sie nicht hören, machen sie etwas falsch (beachten Sie, dass "Betrachten" nicht "Akzeptieren" bedeutet).
Ein Anforderungsingenieur muss das Projekt aus der Sicht jedes Beteiligten separat (und manchmal gleichzeitig) betrachten. Wir sind nur Menschen und scheitern oft daran. Wenn Sie da sind, um Ihren wahren Standpunkt darzulegen, ist Ihre Eingabe sehr wertvoll, anstatt den Standpunkt, von dem wir glauben, dass Sie ihn haben.
Hier können Sie sich freier verhalten. Es ist meine Aufgabe, den Sensibilitätstanz zu machen. Sei nicht offen aggressiv, das behindert meine Arbeit, aber du brauchst weniger Selbstbeherrschung und kulturelles / kommunikatives Bewusstsein, weil ich die Lücke schließen kann. Sie schweben auch nicht in einer Situation, in der es zwei widersprüchliche Ideen gibt und niemand beurteilen kann, welche besser ist. Ich soll das wissen, und wenn es nicht klappt, ist es mein Kopf in der Schlinge.
Fazit 2: Befindet sich ein Anforderungsingenieur im Team, gehen Sie mit Vorschlägen für Produktfunktionen zu ihm. Sie brauchen diesmal keine Samthandschuhe.
Und was ist, wenn es keinen Anforderungsingenieur gibt, der Product Owner überfordert ist und nach Ideen ringt, der Chef Sie scharf ansieht und Sie keine Ideen zu bieten haben?
Sie haben ein paar Möglichkeiten. Die eine ist, wie Sie sagten, aufzuhören. Nicht alle Organisationen arbeiten auf diese Weise, und wenn diese Umgebung nicht für Sie geeignet ist, finden Sie eine bessere. Es wird auf lange Sicht gut für Sie sein.
Sie können auch abwarten, ob sich etwas ändert. Das nächste Projekt kann einen erfahreneren Produktbesitzer (oder einen mit mehr Führung) haben. Aber du kannst nicht für immer stehen bleiben.
Die dritte Möglichkeit besteht darin, das Anforderungs-Engineering selbst zu erlernen. Dies ist eine Fähigkeit, die heutzutage sehr gefragt ist. Selbst wenn Sie nie vorhaben, eine Position als Vollzeit-Anforderungsingenieur einzunehmen, erhöht diese Fähigkeit Ihren Wert als Entwickler, da Sie die anderen Mitglieder Ihres Teams (und Ihrer Benutzer) besser verstehen und besser verstehen können Der Entwicklungsprozess verläuft reibungsloser. Und du musst nicht in die ganze Tiefe gehen. In einem Einstiegslehrbuch, in dem Aufgaben, Workflows, mentale Modelle und benutzerzentrierte Datenmodelle erläutert werden, können Sie bereits in einer Software, die von einem Team aus Geschäftsleuten und Entwicklern entwickelt wurde, zahlreiche Verbesserungsmöglichkeiten erkennen. Don' Die dicksten Bücher, die als Referenz für Akademiker gedacht sind (wie die kürzlich erschienene Pohl-Übersetzung ins Englische), sind eher eine Liste aller möglichen Methoden für jeden kleinen Schritt, ohne eine Erklärung, wie man sie tatsächlich macht. Wähle etwas praxisorientiertes.
Wenn Sie es versuchen und feststellen, dass Sie kein persönliches Interesse an der Region haben, ist das immer noch in Ordnung. Zwinge dich nicht dazu, etwas zu tun, das du nicht magst. Aber Sie sollten sich wahrscheinlich nach einem Job in einer Organisation mit einer anderen Teamstruktur umsehen.
Fazit 3: Anstatt jahrelang auf ein intuitives Verständnis zu warten, lesen Sie ein oder zwei Bücher und Sie haben bereits gute Ideen zu liefern