it-swarm.dev

Sind Entwickler ein Stakeholder in einem System?

Werden Entwickler eines Produkts als Stakeholder betrachtet?

23
Tom

Im Allgemeinen sind Entwickler an einem Softwareprojekt beteiligt. Das stimmt mit dem Wörterbuchdefinition des Begriffs überein. Hier einige Definitionen von Stakeholdern aus verschiedenen Veröffentlichungen:

Karl Wiegers Softwareanforderungen :

Stakeholder Eine Person, Gruppe oder Organisation, die aktiv an einem Projekt beteiligt ist, von dessen Ergebnis betroffen ist oder dessen Ergebnis beeinflussen kann.

Ian Sommvervilles Software Engineering 8 :

Der Begriff Stakeholder bezieht sich auf jede Person oder Gruppe, die direkt oder indirekt vom System betroffen ist. Zu den Stakeholdern zählen Endbenutzer, die mit dem System interagieren, und alle anderen in einer Organisation, die von der Installation betroffen sein können. Andere Systembeteiligte können Ingenieure sein, die verwandte Systeme entwickeln oder warten, Unternehmensmanager, Domänenexperten und Gewerkschaftsvertreter.

Roger S. Pressmans Software-Engineering: Ein Ansatz für Praktiker (6. Ausgabe) definiert fünf Gruppen oder Stakeholder: leitende Angestellte, die geschäftliche Probleme definieren, Projekt-/technische Manager, die die Praktiker organisieren und kontrollieren, die Praktiker, die das entwickeln System, Kunden, die die Anforderungen an die Software angeben, und Endbenutzer, die mit dem gelieferten System interagieren.

Scott Amblers aktive Stakeholder-Beteiligung: Eine agile Best Practice :

Meine Definition eines Projektbeteiligten ist jeder, der ein direkter Benutzer, ein indirekter Benutzer, ein Benutzermanager, ein leitender Manager, ein Betriebsmitarbeiter, der "Goldbesitzer", der das Projekt finanziert, ein Supportmitarbeiter (Helpdesk), Prüfer und Ihr Programm ist/Portfoliomanager, Entwickler, die an anderen Systemen arbeiten, die das zu entwickelnde System integrieren oder mit diesem interagieren, oder Wartungsfachleute, die möglicherweise von der Entwicklung und/oder Bereitstellung eines Softwareprojekts betroffen sind.

...

In dieser Definition habe ich beschlossen, die Entwickler auszuschließen, die an dem Projekt arbeiten. Dies mag zunächst seltsam erscheinen, da Entwickler eindeutig einen wichtigen Anteil an den Projekten haben, an denen sie arbeiten. Ja, Entwickler sind definitiv Projektbeteiligte. Warum unterscheide ich weiterhin zwischen Entwicklern und Projektbeteiligten? Weil ich bequeme Begriffe möchte, um sie zu unterscheiden, mag ich "Entwickler-Stakeholder" und "Nicht-Entwickler-Stakeholder" nicht wirklich und weil sie unterschiedliche Rollen in einem Projekt spielen.

In der Praxis habe ich normalerweise gesehen, dass Stakeholder in Gruppen aufgeteilt wurden, und eine Gruppe enthält die Personen, die das System aufbauen. Es ist wichtig zu erkennen, dass die Entwickler beim Aufbau eines Systems Bedürfnisse und Bedenken haben, die mit den Bedürfnissen aller anderen in Einklang gebracht werden müssen. Diese müssen jedoch priorisiert und bei jedem anderen Bedarf berücksichtigt werden.

20
Thomas Owens

Normalerweise nein, aber es kann Ausnahmen geben. " Essen Sie Ihr eigenes Hundefutter " kommt als Hauptausnahme in den Sinn, da in diesem Fall die Entwickler möglicherweise das verwenden, was sie direkt erstellen, und somit in gewissem Maße Stakeholder sind. Ich würde jedoch fragen, ob dies insgesamt mehr als ein paar Prozent der Entwickler waren.

5
JB King

Wenn dies in Bezug auf Scrum gefragt wird, dann nein ...

... Definition eines Projektbeteiligten ist jeder, der ein direkter Benutzer, ein indirekter Benutzer, ein Benutzermanager, ein leitender Angestellter, ein Betriebsmitarbeiter, der "Goldbesitzer", der das Projekt finanziert, ein Supportmitarbeiter (Helpdesk), ein Prüfer Ihr Programm-/Portfoliomanager, Entwickler, die an anderen Systemen arbeiten, die das zu entwickelnde System integrieren oder mit diesem interagieren, oder Wartungsfachleute, die möglicherweise von der Entwicklung und/oder Bereitstellung eines Softwareprojekts betroffen sind ...

Stakeholder sind Personen außerhalb des aktuellen Produktentwicklungsteams in der einen oder anderen Form. Wenn Sie in Team X und ein anderer Entwickler in Team Y sind und an unterschiedlichen Produkten arbeiten, die zu einem späteren Zeitpunkt miteinander interagieren, werden Sie zu einem Stakeholder des jeweils anderen Produkts.

4
Aaron McIver

Ja - für ein System, das weiterlebt und gewartet wird. Entwickler werden wahrscheinlich mit dem Code arbeiten, um Fehler zu beheben und neue Funktionen einzuführen, lange nachdem das erste Team das Projekt abgeschlossen hat. Eine wichtige Voraussetzung für langlebige Systeme ist die Wartbarkeit, und wer sollte sich dafür einsetzen, wenn nicht Entwickler?

4
froderik

Nach ein bisschen googeln muss ich sagen, dass dies eine unbeantwortbare Frage ist. Es gibt keine einheitliche Definition eines Stakeholder, und verschiedene Quellen verwenden ihn unterschiedlich.

Wie die Scott Ambler-Referenz von Aaron hervorhebt, vermeidet mehr als eine Methode den Begriff insgesamt. Andere versuchen, es in verschiedene Kategorien von Stakeholdern aufzuteilen. Das Ergebnis ist, dass, obwohl es eine allgemeine Bedeutung gibt, dass Stakeholder "jemand mit Interesse" ist, die genaue Bedeutung verloren geht.

Was dieses Interesse ist, hängt von einer von zwei Bedeutungen in meinem Kopf ab:

  • Diejenigen, die erwarten, aus der Anwendung einen primären Wert abzuleiten

oder

  • Diejenigen, die in das Ergebnis des Projekts investieren werden.

Das Sponsoring-Gremium passt zu beiden Definitionen. Wie Endbenutzer in das Sponsoring-Gremium passen, ist ein ganz anderes Thema. Nehmen wir vorerst an, dass sie passen, weil ich nicht bereit bin, Haare darauf zu spalten. Jeder im Projektteam passt auch zur zweiten Bedeutung.

Am Ende kommt es darauf an, dass der Wert aus unseren Bewerbungen abgeleitet wird und wir verstehen, dass die Sponsoren das endgültige Wort erhalten.

Mein allgemeines Gefühl ist, dass Leute, die Entwickler in die "Stakeholder" -Gruppe einbeziehen möchten, sich hauptsächlich darum kümmern, weil sie Situationen gesehen haben, in denen Entwickler als Zahnräder in einer Maschine behandelt werden und daher oft schlecht behandelt werden. Rückmeldungen zu Anforderungen sind nicht zulässig, erhebliche unbezahlte Überstunden sind obligatorisch usw. Da Sie Zeit und Vernunft aufgeben, die über den Erwartungen liegen, neigen Menschen dazu, dies als Investition zu betrachten. Investition = Einsatz In ihren Köpfen sind die Entwicklungsteams Stakeholder.

Daher bin ich kein Fan des Begriffs. "Sponsoren" ist klar. "Stakeholder" ist nicht.

2
MIA

Sie können sein. Wenn ihre Position nach Fertigstellung des Produkts anders ist als zuvor, sind sie Stakeholder. Wenn ein Entwickler beispielsweise ein Gehalt für die Entwicklung von Software für ein Unternehmen erhält, ist er wahrscheinlich kein Stakeholder, da sich nach der Lieferung des Produkts nichts ändert. Wenn er jedoch Partner in einem Startup ist, dessen finanzielle Situation vom Erfolg des Produkts abhängt, würde ich argumentieren, dass er ein Stakeholder ist.

Ein anderes Beispiel wäre der (zugegebenermaßen seltene) Fall, dass ein Entwickler Software erstellt, die er verwenden wird. In diesem Fall ist er definitiv ein Stakeholder, da er ein begründetes Interesse daran hat, dass diese Software ordnungsgemäß funktioniert.

0
Michael K

Entwickler sind in der Tat Stakeholder (die von dem, was produziert wird, betroffen sind): sowohl diejenigen, die anfänglich ein System entwickeln, als auch diejenigen, die es warten. Die ersteren neigen dazu, sich für neue Technologien zu interessieren und ihre Fähigkeiten zu erweitern, während die letzteren in der Lage sein wollen, mit der normalerweise großen Anzahl von Systemen Schritt zu halten, die sie warten müssen.

"Legitime" Stakeholder sind jedoch eine andere Frage. Bei der Abwägung der Anforderungen werden sicherlich nicht alle Beteiligten ihre Bedenken zu ihrer Zufriedenheit finden. Ist Ihr Unternehmen besorgt, Top-Entwickler zu verlieren? Entwickeln Sie Bedenken von Entwicklern. Wenn nicht, landen Entwickler eher am Totempfahl. Leider kann dies auch dazu führen, dass die Wartbarkeit ignoriert wird und technische Schulden entstehen, als gäbe es kein Morgen.

0
Pontus Gagge