Ist es normal, dass Entwickler Produktbesitzern Ideen für Funktionen vorschlagen? [geschlossen]


16

Ich habe vor kurzem angefangen, als Entwickler zu arbeiten, nachdem ich zuvor als Systemadministrator gearbeitet habe.

Ich verstehe, wie ein Software-Entwicklungsteam, das Agile-Funktionen einsetzt, die Kommunikation "Was wir implementieren müssen" meist in eine Richtung abläuft, vom Produktbesitzer bis zu den Entwicklern. Entwickler können dem Produktbesitzer ihre Bedenken hinsichtlich der technischen Verschuldung zum Ausdruck bringen. Die Entwicklung von Funktionsideen sollte jedoch nicht zu ihren Hauptaufgaben gehören.

Die Firma, bei der ich arbeite, sieht das anders. Für sie sollten Entwickler nicht nur zu den Produktbesitzern ihres eigenen Teams gehen, um Ideen für Funktionen vorzuschlagen, sondern auch zu den Produktbesitzern anderer Teams, wenn sie der Meinung sind, dass sie etwas zum Produkt dieses Teams beitragen können. Die Idee ist, dass wir alle ein großes Team <Firmenname> sind und alle Entwickler ihr Know-how nutzen sollten, um Funktionen voranzutreiben, von denen sie glauben, dass sie nützlich sind.

Ist ein solcher Ansatz "normal", weil es kein besseres Wort gibt? Bin ich zu passiv, sollte ich die Initiative ergreifen und Ideen an die Produktbesitzer weitergeben? Hat sich das Unternehmen dagegen völlig geirrt und ich sollte woanders nach Arbeit suchen?


15
Sicher, Programmierer wissen oft eine Menge Dinge, von denen der Produktbesitzer noch nie gehört hat. Nehmen wir die Webentwicklung, es gibt Dienste, APIs, eine beliebige Anzahl von Bibliotheken und Plugins und Elemente der Benutzeroberfläche. Wir arbeiten oft mit Kunden zusammen, die nicht viel mehr als eine ungefähre Vorstellung davon haben, was sie tun möchten, aber keine Ahnung haben, wie sie üblicherweise implementiert werden oder welche zusätzlichen Funktionen möglich wären.
thorsten müller

1
Fühlen Sie Ärger oder negative Konsequenzen, wenn Sie keine Features vorschlagen? Es hört sich so an, als ob Ihr Unternehmen die Praxis fördern und diejenigen, die dies nicht tun, nicht bestrafen möchte.
JeffO

Dies ist der normale Prozess in zwei Unternehmen, für die ich gearbeitet habe. Mir ist klar geworden, dass die Geschäftsleute einfach keine Ahnung haben, wie wertvoll wir Entwickler in Bezug auf Lösungen / Problemlösungsfähigkeiten sind. Das springende Schiff wird wahrscheinlich auf dasselbe Problem stoßen. Wenn Produktleuten neue Funktionen vorgeschlagen werden, als ob es sich um eine Lösung handeln würde, wird dies als Verwaltung der Manager bezeichnet und funktioniert einwandfrei. Das einzige Problem ist, dass Sie keine Anerkennung für Ihre Ideen erhalten, aber zumindest Ihre Funktionen implementiert werden.
Jason

IMO das ist eine sehr gute Sache und sehr gesund. Produktbesitzer sind zwar Experten auf dem Gebiet der Geschäftswelt, kennen jedoch wahrscheinlich nicht alle verfügbaren neuen Technologien oder technischen Ansätze. Darüber hinaus können Entwickler Einblicke in das System erhalten, die sich aus der unterschiedlichen Perspektive der direkten Arbeit mit dem Code ergeben. Sie möchten auf jeden Fall bei einem Unternehmen bleiben, das Ideen von allen begrüßt, unabhängig von der Rolle. Dies bedeutet nicht, dass die Eigentümer keine Ahnung haben, sondern dass sie offen für jedermanns Ideen sind.
Ken Liu

Antworten:


2

Es kommt darauf an, was Sie mit Feature-Ideen meinen.

Im Planungsspiel ist es nicht ungewöhnlich, dass Entwickler Eingaben zu einer Story machen, die in der Iteration enden könnte. Dies unterscheidet sich jedoch stark von den Entwicklern, die sich selbst Geschichten einfallen lassen.

In ausgereiften Systemen schlagen Entwickler möglicherweise einen Weg vor, um ein bekanntes Problem zu umgehen, das zu einer Iteration führen könnte.

Verbesserungen könnten in Ordnung sein, z. B. das Hinzufügen eines Diagramms für einen Bericht, aber Alarmglocken würden für mich läuten, wenn die Entwickler sich echte neue Geschichten einfallen lassen. Wenn das einen echten Wert hätte, würde ich fragen, warum es dafür keine nicht umgesetzte Geschichte gibt oder warum sie in der Retrospektive nie aufgetaucht ist.


1
Ich interpretiere meine Firmenphilosophie nicht so, als würde ich Entwickler bitten, Geschichten zu entwickeln, und ich kann mich nicht erinnern, dass dies geschehen ist. Ich denke, sie wollen, dass es die Verantwortung des Entwicklers ist, diese Idee bis zum Ende durchzusetzen, sobald eine Idee veröffentlicht wurde und ein Entwickler die Verantwortung für deren Umsetzung übernommen hat.
louniks

1
Sie sagen also, dass Alarmglocken läuten, wenn ein Entwickler an eine Idee denkt, an die ein Produktbesitzer nicht gedacht hat? Warum sollte das so schlimm sein?
Stefan Billiet

1
Es ist in Ordnung, Ideen herumzuschleudern - das gehört zum Planungsspiel dazu. Wenn es eine neue Geschichte wäre, würde ich dies in Frage stellen. Geschichten liefern den Kundennutzen, den Entwickler normalerweise nicht am besten einschätzen können (es sei denn, sie sind Domain-Experten). Ob in der Iteration etwas auftaucht, wird durch den Story-Wert und den Entwickleraufwand im Planspiel bestimmt. Die Beteiligung von Entwicklern an der Erstellung von Storys kann hier zu Interessenkonflikten führen. Das soll nicht heißen, dass es nicht passieren könnte - nur, dass der Produktbesitzer sich dann dafür einsetzen müsste, sonst ist es der Schwanz, der mit dem Hund wedelt.
Robbie Dee

47

Der Grund, warum viele Entwickler "passiv" sind, ist, dass eine gewisse Menge an Fachwissen und Erfahrung erforderlich ist, bevor gute Produktideen zu Ihnen kommen. Aber wenn sie kommen, gibt es keinen Grund, sie nicht vorzuschlagen und für sie einzutreten.

Denken Sie daran - Entwickler, Produktbesitzer, Verkäufer usw. gehören alle zum selben Team, mit dem gleichen Ziel: ein erfolgreiches Produkt aufzubauen. Arbeiten Sie auf dieses Ziel hin, wie Sie können.


Ich denke, Sie haben es verstanden - ich bin in einem Team gelandet, das mit Technologien arbeitet, mit denen ich nur sehr wenig Erfahrung habe, daher fällt es mir schwer, proaktiv zu sein. Es muss eine Lernphase geben, in der ich passiv bleibe. Sobald ich mich mit der Technologie vertraut gemacht habe, kann ich anfangen, proaktiv zu sein.
louniks

1
@louniks nein, du verpasst den Punkt. Auf die Technik kommt es nicht an. Auf das Geschäft kommt es an. Wie transparent sind die Geschäftsleute? Wissen Sie, wie das Unternehmen Geld verdienen will? Wissen Sie, wie das Produkt, an dem Sie arbeiten, zu den anderen Produkten im Unternehmen passt? Wenn nicht, ist Ihr Arbeitgeber Ihnen gegenüber unfair. Sie können keine Funktionen vorschlagen, wenn Sie den Geschäftsplan nicht kennen.
RibaldEddie

3
@RibaldEddie Ich bin mit dem letzten Teil nicht einverstanden. Jeder sollte die Möglichkeit haben, Funktionen vorzuschlagen. Management und Product Owner können weiterhin frei entscheiden, ob das Feature irgendwo eingesetzt werden soll. Lassen Sie sich nicht die Möglichkeit entgehen, dass ein Entwickler mit ausreichendem Fachwissen und technischen Kenntnissen eine riesige Funktion zum Geldverdienen entwickeln kann, die vollständig außerhalb des ursprünglichen Geschäftsplans liegt. Ein Produktbesitzer kann aufgrund begrenzter technischer Kenntnisse niemals auf die gleiche Idee kommen.
Dan Lyons

1
Das klingt nach einer gefährlichen Situation: Die Geschäftsleute, für die Sie arbeiten, wissen nicht, was sie tun. Es ist IHR JOB, Experten auf diesem Gebiet zu sein. Ansonsten warum sind sie da? Ernsthaft. Wenn Entwickler diese Art von Einsicht gewähren, können die Entwickler das Unternehmen genauso gut einfach leiten. Alles andere ist Verschwendung.
RibaldEddie

Sie benötigen nicht immer detaillierte Domain-Kenntnisse, um technische Verbesserungen vorzuschlagen ...
Robbie Dee

5

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


+1 Das ist eine wirklich umfassende Antwort. Die "Schlussfolgerungen" wirken als gut TL;DR.
James Khoury

4

Ja, das ist ganz normal.

Es ist bekannt, dass 80% der Mitarbeiter - 20% Innovationsmodelle bei Google sind, bei denen sich 20% ihrer Zeit mit etwas befassen, das ihnen gefällt. Auf diese Weise erhalten sie nicht nur neue Funktionen, sondern auch ganz neue Produkte und Dienstleistungen.

Bin ich zu passiv, sollte ich die Initiative ergreifen und Ideen an die Produktbesitzer weitergeben?

Das hängt von deiner Persönlichkeit ab. Ich habe mit sehr leidenschaftlichen Menschen gearbeitet, aber auch mit Menschen ohne Emotionen, die ihre 8 Stunden Schicht machen und nach Hause gehen.


Es scheint, als ob die Entwickler bei Google einen Teil ihrer Zeit damit verbringen, Produkteigentümer zu sein.
JeffO

Google-Mitarbeiter, die an ihren eigenen Projekten arbeiten, sind nicht dasselbe, es sei denn, Sie sprechen über eine andere Initiative?
Robbie Dee

@ RobbieDee Ja, richtig. Sie arbeiten an ihren Projekten, aber Google verkauft Dienste, die aus den Projekten hervorgehen.
BЈовић

Was ich meine ist, dass solche Projekte nicht notwendigerweise in der Sphäre eines existierenden agilen Projekts liegen. Sie können völlig autonom sein.
Robbie Dee
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.