Zertifizierungen
1lUYKwP
1lUYKwP
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Blog<br />
Requirements Engineering ist nicht sexy<br />
«Requirements Engineering ist nicht sexy».<br />
Das war ein der Aussage, die ich bei einer<br />
Umfrage unter RE-Verantwortlichen von<br />
verschiedenen Firmen bekommen habe.<br />
Als passionierter Requirements Engineer<br />
war ich natürlich zuerst einmal empört<br />
über diese Aussage. Nach einigem Nachdenken<br />
musste ich dann aber zugeben,<br />
dass dies doch nicht so falsch ist. Warum<br />
ist das so und was kann man dagegen tun?<br />
RE ist nicht sexy – wieso?<br />
In SW-Entwicklungsprojekten geben Produktmanager oder<br />
Produkt Owner vor, was implementiert werden soll. Projektleiter<br />
steuern das Projekt. Entwickler sind sowieso cool, vor<br />
allem wenn sie objektorientiert programmieren und/oder in<br />
einem agilen Team sind. Alle diese Rollen werden als sexyer<br />
angesehen als REs. Und Tester … OK, Testing wird wohl als<br />
noch weniger sexy angesehen als RE (das dürfen meine<br />
Test-Kollegen gerne kommentieren).<br />
In der Tat hat das Ansehen von RE in der letzten Zeit abgenommen.<br />
Im Vergleich zu 2014 ist in unserem neuesten Trends<br />
& Benchmark-Report die Zustimmung zur Aussage «RE ist für<br />
den Erfolg der Organisation strategisch» stark von über 50%<br />
auf 14% gefallen. Dagegen ist die Zustimmung zu «RE ist ein<br />
wichtiger Faktor um verlässliche Software zu produzieren» von<br />
20% auf 50% gestiegen. Das hört sich immer noch OK an –<br />
aber sexy?<br />
Irgendwie hat ja schon jeder im Projekt das Gefühl, dass der RE<br />
einen wichtigen Beitrag zum Projekterfolg leistet. Aber können<br />
wir das auch beweisen? Man kann für RE relevante KPIs definieren.<br />
Aber auf die für das Management entscheidende Frage fällt es<br />
zumindest mir schwer, eine Antwort zu geben: «Um wieviel sind<br />
die Einsparungen durch professionelles Requirements Engineering<br />
höher als die Kosten, die es verursacht?» Also, was kann mal also<br />
sonst machen?<br />
Und was kann man tun?<br />
Eine Antwort ist, dass Profil zu schärfen: Dazu gehört, die Rolle<br />
des Requirements Engineers klar zu definieren. Dabei ist insbesondere<br />
die Abgrenzungen zu anderen Rollen im Projekt deutlich<br />
darzustellen. Das heisst nicht, dass der RE nicht auch andere<br />
Aufgaben übernehmen darf, z.B. mit zu testen. Aber es muss klar<br />
sein, was zu seinem Kernaufgabengebiet gehört und was nicht.<br />
Ausserdem gilt: «Tue Gutes und sprich darüber». Viele RE-Organisationen<br />
sind noch zu defensiv, wenn es um Selbstmarketing<br />
geht. Die eigene Leistung und Erfolge herauszustellen hat nichts<br />
mit Überheblichkeit zu tun, sondern ist ein wichtiges Mittel,<br />
um Akzeptanz im Unternehmen zu erreichen. Ein monatliches<br />
Newsletter ist OK, wird aber oft nicht gelesen. Etwas besser ist es,<br />
ab und zu in Management-Meetings die vergangenen Highlights<br />
zu präsentieren. In einer Roadshow wichtigen Stakeholder (z.B.<br />
Produktmanager, Architekten, Testmanager) darzustellen, welche<br />
Dienstleistungen man anbietet, wie die Prozesse aussehen und<br />
was man von ihnen erwartet, hilft, die Akzeptanz der eigenen<br />
Arbeit zu steigern.<br />
Weiterhin ist es wichtig, laufend zu reflektieren, ob die Dienstleistungen,<br />
die wir als RE anbieten, noch angemessen sind. Wenn<br />
sich das Unternehmen z.B. in Richtung Agilität entwickelt, kann<br />
eine Facilitator-Rolle in den Teams nötig werden. Diese kann<br />
durch kommunikative REs gut gefüllt werden. Gibt es im Unternehmen<br />
schon jemand, der sich mit Usability beschäftigt? Wenn<br />
nicht, kann ein RE sich weiterbilden und diese Rolle abdecken.<br />
Ein scharfes Profil, ein gesundes Selbstmarketing und die<br />
Reflektion der eigenen Tätigkeit können also einen wertvollen<br />
Beitrag dazu leisten, dass Requirements Engineering in Zukunft<br />
als ein bisschen sexyer angesehen wird.<br />
Weitere Informationen, Ideen und<br />
Anregungen zu Requirements Engineering<br />
The Business Analysis Center of Excellence, Requirements<br />
Engineering Magazine 2015-3, IREB<br />
In agilen Projekten muss der RE oft um seine Daseinsberechtigung<br />
kämpfen. Man ist ja ein Team und da braucht<br />
es keine speziellen Rollen (Tester sind davon auch betroffen,<br />
aber etwas weniger). Wenn der RE Glück hat, darf er noch<br />
Proxy-PO für den vielbeschäftigten Produktmanager spielen.<br />
Dabei muss er bei Entscheidungen aber immer rückfragen, was<br />
nicht gerade sein Ansehen stärkt.<br />
Christoph Wolf,<br />
Principal Consultant