Anforderungsmanager

Das ist ein Verschiebebahnhof für Leute, die nicht entwickeln können. 
Ein anständiger Ingenieur macht so eine Pillepalle nebenher.

Ich bin in einem großen Unternehmen, da ich dort erst seit paar Monaten 
arbeite und momentan zu wenig Aufgaben vorliegen wurde mir das angeboten

Nebenher geht dies nicht. Es ist eine eigenständige Position, ich würde 
zwischen verschiedenen Abteilungen als Schnittstelle dienen und wär der 
Ansprechpartner. Aus der Programmierarbeit würde ich mich dann immer 
weiter entfernen. Frage ist nur ob sich das irgendwie lohnt

Aberhallo schrieb:
> Ein anständiger Ingenieur macht so eine Pillepalle nebenher.

Sprach der Höhlenmensch aus der Klitsche.

Torben schrieb:

> ich bin Softwareentwickler in einem großen Unternehmen und mir wurde die
> interne position eines Anforderungsmanagers (Requirment engineer)
> angeboten.


Für was sollst du den die Requirements schreiben? Gerät, Application? 
verstehst du DAS zu dem Du die Anforderungen mangen sollst?

https://image.slidesharecdn.com/2-keyissues4re-dmonett-europeweekuh2014-140310140215-phpapp02/95/key-issues-for-requirements-engineering-lecture-slides-26-638.jpg?cb=1394460516


https://i.pinimg.com/564x/da/28/f4/da28f46266b57dfcd959a9ba38983245--business-analyst-business-cards.jpg

Ja, hab mich in den letzten Jahren auch schon ab und an über solch einen 
Posten gewundert ... Also die Disziplin an sich des RE macht ja schon 
Sinn differenziert zu betrachten, aber ich denke als "Hauptjob" lohnt 
sich das für eine Firma eher im Verbund, bei großen Projekten, wo viele 
Teilaufgaben anstehen. Es KANN eine Anerkennung bedeuten, wenn man 
aufgrund seiner Akzeptanz, Kommunikationsfähigkeit etc. als guter 
Ansprechpartner für sowas nominiert wird.
Ich hatte solch eine Aussschreibung letztens bei einer Klitsche gesehen, 
die vieles anderes nicht auf die Reihe bekommt (war da selbst mal vor 
über 10 Jahren) und musste laut darüber grinsen,weil das definitv ein 
verzweifelter Versuch war , Personal zu bekommen, wo man schon andere 
Leute mit Kleinscheiss verbrannt hat.
Naja. Probiers aus, man wächst mit seinen Aufgaben ;-)

LG

Sina A. schrieb:

> der engineer anteil besteht darin, dass du mit deinen requirements ein
> produkt weiter ausformulierst... somit also einen schritt näher zur
> konkreten implementation führst.

Ja schön wärs, man hat schon Fälle erlebt da hat der Requirement 
Engineer die Entwicklung Lichtjahre von der Implementierung/Realisierung 
weggeführt weil er bspw. pauschal auf Normenwerke referenzierte ohne 
wenigstens Beispiele zu geben wie diese erfüllt werden könnten. Oder 
noch besser,  Systemreuirements, nicht an der Schnittstelle 
runterzubrechen. Oder nicht wirklich quantifizierbare Anforderungen 
stellen wie "Bei Markteinführung muss die Software doppelt so schnell 
sein wie die des nächsten mitbewerbers".

IMHO sollte Requirements nur schreiben, wer Erfahrung in der 
Implementierungund Anwendung hat, kein Milchbubi der noch keine 5 Jahre 
in der Firma/Geschäft ist.

>Naja, ist doch reine Tipparbeit. Das macht bei uns die Sekretärin.

Du bist mehr so im Low-Level-Bereich tätig und hast definitiv keine 
Ahnung.

>Das ist eine Vorgehensweise wie aus dem Elfenbeinturm.

Du solltest dich mehr bemühen, dem Anspruch deines Nicks wenigsten 
rudimentär zu entsprechen.

Bei dreckstool.de ist das Doors einer der Spitzenreiter.

Sheeva P. schrieb:
> Sofern Du ins Management willst, kann das der erste Schritt sein.

Also das halte ich für ein Gerücht, dass Requirements Engineering der 
Weg ins Management sein soll. Abstellgleis trifft es wohl eher.

Ich vermute die Entscheider erhoffen sich einen Super Requirements 
Menschen wenn sie dafür einen echten Entwickler einstellen. Meiner 
Meinung nach funktioniert das aber nicht und ich glaube dass Du am Ende 
für die Fehleinschätzung der Entscheider büßen musst. Ich würde eher 
versuchen jeden Software Entwickler für einen bestimmten Prozentsatz 
seiner Arbeitszeit an die Reqirements zu setzen. Um beim Thema zu 
bleiben, ich könnte das nicht und würde dran kaputt gehen weil ich viel 
zu gern entwickle. Ab und an was zu programmieren brauche ich wie die 
Luft zum Atmen. Ob Du das mit Dir vereinbaren kannst musst Du aber wohl 
individuell für Dich entscheiden. Hältst Du die Stelle für Sinnvoll ?? 
Liegen dir die Teiltätogkeiten?? Ist es okay für Dich lediglich Indirekt 
am Produktentstehungszyklus teilzuhaben ?? Kommst Du mit ev. Arroganten 
Entwicklern klar für die Du dann ev. „Nur“ Doku machst. ( hab ich oft 
gesehen, ist kompletter Schwachsinn, kann aber in manchen Gruppen zu 
richtig realen Gruppenauffassung werden )....

Aberhallo schrieb:
> Bei dreckstool.de ist das Doors einer der Spitzenreiter.

top seite

Naja FMEA und systemischer aufüber mehrere Steuergeräte verteilte 
Funktionen ist schon interessant ... ich hätte Probleme mit der 
Ausschließlichkeit.

Systemsicht über ... Scheiss Handy

Sheeva P. schrieb:

> Requirement Management ist vor allem eine Kommunikationsaufgabe mit
> einem starken technischen Hintergrund. Wenn Deine Vorgesetzten Dir diese
> Aufgabe zutrauen, dann vermutlich deswegen, weil Du Dich als guter und
> technisch sattelfester Kommunikator erwiesen hast.

IMHO ist das ein grosser Irrtum, das man mit "Kommunikation" allein 
Entwicklungabschnitte definieren kann und die Technik könne im 
Hintergrund bleiben.

Das technische Verständnis steht m.E. bei Requirement-Engineering im 
Vordergrund. Erst muss man verstehen, was die "Application" tun soll und 
was die zur Verfügung stehende Technologien zu leisten vermag bevor man 
Anforderungen niederschreiben kann.

Wie man dieses Verständnis erlangt ist IMHO nebensächlich. Manche 
bevorzugen eigenes Reverse Engineering und Feldstudien, andere halten 
wochenlang Meetings zum Thema "Wünsch Dir was" und wiederum andere 
extrapolieren ihre jahrzehntelange Erfahrung mit der Firma und ihren 
Produkten.

Kommunikation ist (ein) Mittel zum Zweck, aber kein Allheilmittel.

Nie und nimmer!!
Bei uns hat keiner Bock diese Rolle anzunehmen (zurecht)... d.h. wenn du 
da ein Mal drin bist, kommst du da nicht mehr raus.

Autor: IchGlaubeEsNicht (Gast)
Datum: 24.02.2018 20:38

>> Das ist eine Vorgehensweise wie aus dem Elfenbeinturm.
> Du solltest dich mehr bemühen, dem Anspruch deines Nicks wenigsten
> rudimentär zu entsprechen.

Der ist in diesem Unterforum (PKV-Thread) schon wiederholt unange-
nehm  aufgefallen. Seine abgrundtief dümmlichen Postings zeugten
von fundamentalem Unwissen.

Jürgen W. schrieb:
> Programmieren tun in Zukunft nur noch Inder, Chinesen, Russen und
> anderes billig-Personal.

Denke ich nicht.

Bei mir auf Arbeit kommt das Zeug aus Indien an. Es soll bei uns nur die 
QA gemacht werden.

Was passiert ist, dass wir meist ganze Module/Komponenten neu schreiben, 
weil die Qualität zu wünschen übrig lässt. Der Teamleiter kann nichts 
machen, da er so oder so auf den Deckel bekommt. Sei es weil er zu spät 
oder Schrott liefert.

Solche Sprüche wie von dir halten sich hartnäckig, haben aber wenig 
Substanz.
Die Realität sieht anders aus.

Torben schrieb:
> ich bin Softwareentwickler in einem großen Unternehmen und mir wurde die
> interne position eines Anforderungsmanagers (Requirment engineer)
> angeboten. Was meint ihr soll ich die Position annehmen?
Das ist Frauenarbeit, früher standen sie am Herd heute sind sie 
Requirementsengineeress. In einer einschlägigen Postille schreibt eine 
FH-Professorin regelmässig über diesen Kram, Laberthematik ala BWL.

Das ist Arbeit für jemanden, der/die einen guten technischen Überblick 
hat und sehr gut mit Menschen umgehen und diese motivieren kann. Und 
daran Spaß hat.

Sowohl gegenüber den Mitarbeitern, denen zu erklären ist, dass "diese 
Anforderungen doch Blödsinn sind", als auch gegenüber den 
Chefs/Projektleitern/Vertrieb, dass die Anforderungen nicht permanent 
geändert werden können, wenn irgendwann ein Produkt herauskommen soll.

Wer das gut macht, ist enorm wichtig für die Firma und sehr viel 
schwieriger zu ersetzen oder outzusourcen als ein Programmierer.

Aber wer eigentlich programmieren will, wird in der Position 
wahrscheinlich nicht glücklich. Was dann durchaus dazu führen kann, dass 
der Requirement Manager die Arbeit seiner Programmierer nochmal macht, 
weil er nicht verständlich erklären konnte, wie die Arbeit aussehen 
sollte oder weil er dem Vertrieb/Kunden gegenüber nicht deutlich genug 
widersprochen hat, als der eine neue Deadline wollte. Mit den 
entsprechenden Folgen für Überstunden, Arbeitsklima und 
Jobzufriedenheit.

MfG, Arno