28.01.2016 Aufrufe

Zertifizierungen

1lUYKwP

1lUYKwP

MEHR ANZEIGEN
WENIGER ANZEIGEN

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

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!