Hallo Leute, 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? Bieten sich hier Entwicklungsmöglichkeiten? Hat jemand erfahrung und kann mir seinen Alltag erzählen? Bin eigentlich ansonsten sehr zufrieden als Programmierer
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
Mach das. Programmieren tun in Zukunft nur noch Inder, Chinesen, Russen und anderes billig-Personal. Programmierer sind eindeutig in der Sackgasse, außer die hardware-nahen embedded-fuzzis und andere, die persönlich anwesend sein sollten. Meide jeden Job, den man irgendwann outsourcen könnte, denn er wird ausgesourct.
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
Beitrag #5328314 wurde von einem Moderator gelöscht.
also... die viel wichtigere frage ist ob du bock drauf hast. jeden tag mit einem requirement tool arbeiten, dass nicht wirklich das tut was du willst. die ganze zeit meetings wie man die requirements formuliert, damit das die entwickler schlucken, das das abbildet was der produktmanager meint, die richtige granularität, damit du immernoch informationen rüber bringst, aber die entwicklung in ihrem loesungsraum nicht einschränkst... die requirements auch eindeutig getestet werden koennen und das ganz nach norm xyz gemacht ist. irgendeiner kommt immer zu kurz.. da wird viel diskutiert um formalitaeten, damit das alle parteien zu frieden stellt, was meines erachtens unmöglich ist ;) mit den ganzen parteien verändern sich deine 1000 requirements ständig, die du mal mühselig ausformuliert hast... logische zusammenhänge gehen verloren, man kann die abhängigkeiten mit anderen formularen im system nicht mehr nachvollziehen... du räumst hier also ständig auf... diskutierst und räumst wieder auf. so viel zum alltag eines requirement engineers :) es ist halt somit auch recht weit weg vom fertigen produkt... deine erfolgserlebnisse musst du daraus ziehen, dass mal ein dokument von allen parteien unterzeichnet ist. du also einen konsens herbeigeführt hast. wenn ihr noch zulieferer habt, hast du noch mit verträgen zu tun... und musst da gucken, dass die auch die richtigen dokumente liefern... unzwar in einer form, dass diese zu euren prozessen bzw. dokumente passen. 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. spass macht programmieren sicherlich mehr ;) zumindest mir xD
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.
Beitrag #5328353 wurde von einem Moderator gelöscht.
>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.
Beitrag #5328368 wurde von einem Moderator gelöscht.
>Das ist eine Vorgehensweise wie aus dem Elfenbeinturm.
Du solltest dich mehr bemühen, dem Anspruch deines Nicks wenigsten
rudimentär zu entsprechen.
Ibm Door gibt es halt nicht ohne Grund. Der Nachteil von Requirementmanagement ist: es ist langweilig. Der Vorteil: man kann dann auch in der Raumfahrt.arbeiten.
Torben schrieb: > 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. 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. Klassischerweise (das ist je nach Unternehmen und -Kultur verschieden) ist das Requirement Management zwischen Geschäftsleitung, Vertrieb, Beratung, Support, Entwicklung und vor allem dem Kunden angesiedelt. Für einige ist sowas eine extrem spannende Herausforderung, für andere todlangweilig. Kannst Du Dein technisches Knowledge kurzfristig abrufen und ohne jedwede Vorbereitung darüber Vorträge halten? Kannst Du aus den Aussagen des Kunden ableiten, was der Kunde braucht? Kannst Du Produktmanagern und Entwicklern vermitteln, worum es geht und was das Produkt machen und können soll? Wenn Du diese Fragen mit "ja" beantworten kannst, ist das Dein Job. > Frage ist nur ob sich das irgendwie lohnt Die eigentliche Frage ist vielmehr, was Du kannst und wo Du hin willst. Sofern Du ins Management willst, kann das der erste Schritt sein. Mein Tipp: probiers einfach aus -- aber kommuniziere Deinen Vorgesetzten, daß Du Dir nicht sicher bist, ob das der richtige Job für Dich ist. Wenn das nicht paßt, sag' es frühzeitig, ansonsten: go ahead. Viel Erfolg!
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 )....
Beitrag #5328662 wurde von einem Moderator gelöscht.
Naja FMEA und systemischer aufüber mehrere Steuergeräte verteilte Funktionen ist schon interessant ... ich hätte Probleme mit der Ausschließlichkeit.
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.
Beitrag #5329166 wurde von einem Moderator gelöscht.
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
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.