Wie die Fachseite Produkte selbst entwickeln kann

Wir leben in einer rasanten Zeit: Neue Produkte kommen mit unglaublicher Geschwindigkeit auf den Markt. Dass wir unser Produkt schneller als unsere Konkurrenz auf den Markt bringen, kann bereits ein wesentliches Kriterium für den Erfolg des Produkts sein. 

Hinter einer Produktentwicklung steht jedoch meist ein umfangreicher und aufwändiger Prozess, der viele Übergaben zwischen verschiedenen Rollen erfordert.
Ich zeige euch eine Möglichkeit, wie ihr diesen Prozess abkürzen und somit die Time to Market beschleunigen könnt.

Was wäre, wenn Mitarbeiter der Fachseite in die Entwicklung einbezogen würden?

Das klingt erst einmal komisch: Jemand, der die Fachseite in einem Unternehmen vertritt und eigentlich dafür zuständig ist, Produkte zu spezifizieren, soll auch an der Entwicklung des Produkts beteiligt werden? Ist dafür nicht umfangreiches technisches Knowhow notwendig?

Lassen wir das Wie zunächst einmal außen vor und überlegen uns, was wir überhaupt davon hätten, wenn dies tatsächlich der Fall wäre. Wenn wir einen Blick auf Produktentwicklungsprozesse in verschiedenen Branchen werfen, dann gibt es oftmals die Unterteilung in den Fachbereich und die IT. Mitarbeiter des Fachbereichs haben, wie der Name sagt, umfangreiches fachspezifisches Wissen, das für die fachliche Funktionalität bzw. Korrektheit des Produkts essentiell ist. Meist verfügen sie jedoch über wenig technisches Wissen. Die IT-Mitarbeiter wiederum haben dieses technische Wissen, ihnen fehlt jedoch das fachliche Knowhow bzw. das Interesse, sich in das Thema tief einzuarbeiten. Das führt dazu, dass sich der Fachbereich Gedanken über die Ausgestaltung und Art des Produktes macht, diese Gedanken in irgendeiner Form, z. B. in Anforderungsdokumenten oder Pflichtenheften, dokumentiert und dann an die IT übergibt, die für die Umsetzung des Produkts verantwortlich ist.

Probleme durch Übergaben zwischen Fachbereich und IT

Diese Übergaben bringen jedoch einige Probleme und Herausforderungen mit sich. Beispielsweise muss der Fachbereich seine Ideen für das Produkt so formulieren, dass die IT diese in Quellcode übersetzen kann. Die Anforderungsbeschreibung muss dabei eindeutig verständlich sein, um Fehler zu vermeiden. Um das zu gewährleisten, ist es oftmals nicht mit diesen beiden Übergaben getan: Für eine gute Übergabe werden Personen zwischengeschaltet, die die Gedanken zum Produkt in strukturierter Form erfassen oder im Extremfall sogar in Modelle oder Pseudocode übersetzen, welche von der IT dann in Quellcode übertragen werden können.

Diese Erfassung ist vor allem wichtig, wenn ein IT-Dienstleister eingebunden ist, der im Ausland sitzt, denn in diesem Fall sind auch sprachliche Barrieren zu beachten: Neben der inhaltlichen Richtigkeit muss gewährleistet werden, dass die Spezifikation von beiden Seiten sprachlich verstanden wird. Zum Testen der Umsetzung erfolgt dann meist wieder eine Übergabe, denn es muss sichergestellt werden, dass das implementierte Produkt auch so funktioniert, wie es funktionieren soll – und das kann wiederum besser die Fachseite beurteilen.

Was wären die Vorteile, wenn die Fachseite an der Implementierung beteiligt wäre?

Das alles kann sehr zeitaufwändig sein, denn die gleichen Sachverhalte müssen wiederholt in unterschiedlicher Art und Weise beschrieben werden – dass sich Fehler oder redundanzbedingte Inkonsistenzen einschleichen, ist dabei fast vorprogrammiert. Stellen wir uns jetzt also vor, wir würden uns alle diese Übergaben sparen und die Fachseite hätte direkt die Möglichkeit, ihre Gedanken so auszudrücken, dass dies automatisch in Quellcode übersetzt werden kann. Wir würden uns dadurch einiges an Zeit sparen, denn wir müssten die Dinge nur einmal aufschreiben. Gleichzeitig vermeiden wir, dass durch die Übergaben Fehler entstehen, z. B. weil etwas falsch verstanden wurde. Und: Das Produkt könnte deutlicher schneller an den Markt kommen.

Wie kann sich die Fachseite bei der Entwicklung einbringen?

Der Grundgedanke klingt also erstmal gut. Aber wie ist das möglich, ohne dass der Fachbereich Schulungen in Java, C und Co. absolviert oder man alles in Excel-Monstern ausdrückt?

Die technischen Möglichkeiten dafür existieren. Tools wie beispielsweise MPS von Jetbrains erlauben es, Sachverhalte in domänenspezifischen Sprachen (also Sprachen aus der Anwendungsdomäne des Nutzers) zu erfassen und daraus dann später Quellcode zu generieren. Der Anwender, also in diesem Fall der Fachbereich, formuliert die Sachverhalte dabei so, wie er es gewöhnt ist (z. B. in Form mathematischer, tabellarischer, graphischer oder textueller Notationen), drückt hinterher auf einen Knopf und heraus kommt eine ausführbare Implementierung. Wenn die Sprachen und Werkzeuge richtig gestaltet werden, können die Fachbereiche auch gleich Tests schreiben oder Anwendungsfälle durchsimulieren und dadurch die Korrektheit weiter steigern.

Eine gute Usability ist das A und O

Da wir – wie eingangs erwähnt – jedoch nicht davon ausgehen können, dass der Fachbereich ein umfassendes technisches Verständnis mitbringt (was er auch nicht soll!), ist es umso wichtiger, dass entsprechende Tools den Nutzer unterstützen, seine Gedanken korrekt zu formulieren – die Usability muss also stimmen, sowohl die der domänenspezifischen Sprache, als auch die der Anwendung, in welcher der Nutzer mit der Sprache arbeitet.

In Bezug auf die domänenspezifische Sprache ist es zunächst wichtig zu identifizieren, wie der Nutzer Dinge normalerweise dokumentieren würde und welche Abstraktionen, Notationen und Begrifflichkeiten er in seinem Arbeitsalltag und seiner Fachdomäne verwendet. Durch dieses Wissen kann der Nutzer später im Tool mit einer Sprache und Notation arbeiten, die er bereits kennt.

Gewöhnungsbedürftig kann es dagegen für den Nutzer sein, mit Werkzeugen zu arbeiten, die sich stellenweise anders verhalten als ihm Bekanntes, wie Microsoft Word oder Excel. Grund dafür ist, dass ein solches Werkzeug auf Basis einer Sprachdefinition arbeitet, die den Nutzer dazu zwingt, sich an die Sprache zu halten. Nutzer können dies zunächst als Einschränkung sehen. Auf der anderen Seite können solche Werkzeuge die Nutzer besser unterstützten (z. B. bei Fehlerprüfungen, Tests oder Simulationen). Daher ist im Hinblick auf die Usability der Werkzeuge essentiell, den Nutzer bei seinen typischen Arbeitsschritten zu unterstützen: Das Werkzeug kann dem Nutzer beispielsweise Vorschläge machen, was er als nächstes eingeben könnte, kann ihm Konstrukte, die immer wiederverwendet werden, als Templates anbieten, in denen er nur noch die variablen Teile ausfüllen muss, und es ihm erlauben, bestehende Elemente zu referenzieren und wiederzuverwenden. Zudem helfen im Hintergrund laufende Validierungen und daraus erzeugte Fehlermeldungen dem Nutzer, eingeschlichene Fehler direkt aufzudecken und zu beheben.

Schneller als der Markt sein

Es ist also tatsächlich durch nutzergerecht gestaltete Tools und Sprachen möglich, dass der Fachbereich die definierten Produkte auch direkt umsetzt. Wir werden dadurch schneller, vermeiden Fehler und reduzieren die Komplexität der Entwicklungsprozesse. Es kann also wirklich eine gute Möglichkeit bieten, mit der Schnelllebigkeit unserer Märkte mitzuhalten und diese vielleicht sogar zu überholen.