Erfahrungsbericht: Head of Solution Engineering

Karriere-Ratgeber » Berufsbilder » Erfahrungsbericht: Head of Solution Engineering

Head of Solution Engineering

Mein fachlicher Hintergrund ist ein Studium der Informatik mit Nebenfach Betriebswirtschaftslehre und einem Schwerpunkt auf Softwaretechnologie. Schon während des Studiums habe ich mit der Arbeit als Software-Entwickler begonnen, und bin nach meinem Abschluss bei einer kleinen Firma mit damals nur fünf Mitarbeitern eingestiegen.
Die folgenden Positionen waren Head of Platform Team, Head of Technical Service Evolution und dann schließlich Head of Solution Engineering. In den ersten beiden Anstellungen ging es zunehmend um die Aufsicht über bestimmte Plattformen, wobei immer weniger die eigentliche Softwareentwicklung zu meinen Aufgaben gehörte. Ich beschäftigte mich mehr und mehr mit der Frage was wir da im Moment „wirklich“ entwickeln. Meine Aufgaben lagen damit darin, zu evaluieren was wir programmieren müssten, um eine sinnvolle Lösung für das zugrunde liegende Problem des Projektes zu erreichen. Ebenso war ich dafür verantwortlich zu überprüfen, ob wir uns im Zuge der Entwicklung auch tatsächlich dieser Lösung annähern.

Mein Alltag bestand daraus, zu schauen, mit wem während des Entwicklungsprozesses, wann kommuniziert werden muss, um die Lösungsorientierung nicht aus den Augen zu verlieren. Ich stand also stets mit unserem Entwickler-Team und den Auftraggebern in Kontakt. Dabei nahm der Anteil an Gesprächspartnern, die beispielsweise Features vorschlagen oder Produktideen haben, den sogenannten Requestern, stetig zu. Es ging über die Jahre also immer mehr um konzeptionelles Arbeiten, darum zwischen Anforderungen und den geeigneten IT-Lösungen zu vermitteln. Diese Entwicklung hatte schließlich mit der Position des Head of Solution Engineering ihren Höhepunkt gefunden.

Die Suche nach der passenden Lösung

Die Hauptaufgabe des Head of Solution Engineering ist herauszufinden, was die Requester wirklich möchten oder brauchen. Sie haben zwar meist eine konkrete Vorstellung davon, welche Aufgaben das neue Feature oder Programm erfüllen soll bzw. welches Problem gelöst werden soll, allerdings können sie die damit zusammenhängenden Wünsche auf technischer Ebene nur selten konkretisieren.
Nachdem sichergestellt ist, dass eine technische Lösung notwendig oder hilfreich ist, wird nach und nach mit den Softwareentwicklern herausgearbeitet, mit welchen technischen Ansätzen die Anforderungen erreicht werden können. Auf Basis dieser Überlegungen entstehen Projektpläne und Lösungsskizzen. Letztere werden dann mit den Entwicklern aber auch mit den Requestern besprochen. Ziel ist es herauszufinden, ob die skizzierte Lösung wirklich so umgesetzt werden kann und das der Anfrage zugrunde liegende Problem löst. Erst nach dieser Abstimmung wird das Softwareprojekt realisiert.

Requirements Engineering vs. Solution Engineering

In meinem Fall beinhaltete die Aufgabe des Solution Engineerings auch Aspekte des Requirement Engineerings, also dem Erheben und Verwalten der von den Requestern gestellten Anforderungen. Am Ende des Requirement Engineerings stehen dabei lösungsneutrale Anforderungsspezifikationen, die den Ausgangspunkt des Solution Engineerings bilden. Das Solution Engineering erarbeitet aus den Anforderungsspezifikationen dann lösungsorientierte Systemspezifikationen für den Entwicklungsprozess. Vor Allem in größeren Firmen sind die Rollen des Requirement Engineers und des Solution Engineers häufig personell getrennt. Die Problemstellung, mit der alles anfängt, ist zu Beginn des Projektes manchmal in nur zwei Sätzen einer E-Mail formuliert oder liegt als grobe Skizze vor. Aber das ist natürlich nicht genug, um eine Softwareentwicklung zu starten. Nachdem ich diese Information erhalten habe, heißt es zunächst das Problem zu verstehen, in die technischen Anforderungen zu übersetzen und notwendige Nebenbedingungen zu erkennen. Aber auch ganz andere Fragen, wie z.B. zur Rechnungsstellung etc. werden zu diesem Zeitpunkt abgestimmt. Dies erfordert den Austausch mit vielen verschiedenen Abteilungen einer Firma, nicht nur mit den eigentlichen Requestern.

Vom Konkreten zum Abstrakten und zurück

Die Aufgaben eines Solution Engineers erfordern einerseits ein hohes Maß an Abstraktionsfähigkeit, andererseits aber auch die Fähigkeit, das konkrete Problem der Requester stets vor Augen zu haben. Es gilt die Anforderungen aus der alltäglichen Arbeitswelt zu verstehen und mögliche Softwarelösungen auf technischer Ebene genau zu analysieren. Schließlich obliegt es dem Solution Engineer, wiederum ausgehend von der abstrakten technischen Lösung, den tatsächlich erreichten Mehrwert zu erkennen.
In der Kommunikation an der Schnittstelle zwischen IT und Business ist zudem vieles zweideutig. Ein Solution Engineer muss mit dieser Zweideutigkeit umgehen können, Unklarheiten müssen erkannt, aufgearbeitet und geklärt werden. Wenn der Requester beispielsweise angibt, dass er gerne ein neues Feld in einem Webformular realisiert sehen würde, muss eine ganze Reihe von Fragen beantwortet werden. Werden Zahlen eingetragen oder Freitext? Wenn es eine Zahl ist, soll diese mit anderen Zahlen abgeglichen werden? Für den Requester sind die Antworten vielleicht selbstverständlich, wenn sie aber nie explizit ausgedrückt werden, besteht im Ende vielleicht die Gefahr, dass das Falsche entwickelt wird.

Arbeitsalltag zwischen Request und Solution

Die Projektarbeit ist dort wo ich als Head of Solution Engineering gearbeitet habe, in drei Phasen unterteilt. Die erste Phase heißt „idea bouncing”. Hier entsteht die Idee, welche in ihrer Rohform das Team erreicht, sei es persönlich, per Email, oder wie auch immer. Bereits hier wird mit dem Requester kurz darüber gesprochen, ob die Prozessoptimierung oder das Produkt unter Berücksichtigung der technischen Hintergründe grundsätzlich realisiert werden kann. Der Requester bekommt also eine erste Rückmeldung. Erst wenn beide Seiten eine Weiterführung der Idee für lohnenswert erachten, wird die zweite Phase eingeleitet.

Die zweite Phase ist das “PIA”, preliminary impact assessment. Nun wird sich eingehender mit der Problemstellung befasst. Wenn es sich z.B. um ein neues Feature handelt, wird geklärt, wer dieses Feature programmieren wird, wer sehen muss, ob es aktiv ist, es also testet. Auch, wie das Feature abgerechnet wird muss berücksichtig werden. Dazu gehört auch zu klären, wer insgesamt in den Entwicklungsprozess involviert ist, z.B. die Support-Abteilung, die dann ausprobiert, ob das Feature richtig funktioniert, die Finanzabteilung, die sich mit der zugehörigen Rechnungslegung auseinandersetzt, etc.. Die komplette Wertschöpfungskette wird analysiert, um beurteilen zu können, wie die Umsetzung aussehen könnte. Der Dialog zwischen Technik und Business-Seite wird in dieser Phase in Gang versetzt.

Die dritte Phase nennt sich “pre study”, während der sich nun erstmals konkreter mit der Lösung des Problems befasst wird. Mögliche technische Lösungen werden aus vielleicht mehreren Optionen anhand verschiedener Kriterien ausgewählt. Dabei werden natürlich auch kaufmännische Aspekte berücksichtigt. Wie würden Einnahmen und Kosten ausfallen? Hier gehen notwendige Lizenzen, Arbeitsstunden u.s.w. in die Berechnung mit ein. Am Ende dieser Phase steht die Entscheidung über den Lösungsweg, oder in manchen Fällen die Entscheidung darüber, ob das Projekt überhaupt aufgenommen wird.

Herausforderung und Motivation des Solution Engineers

Die Herausforderung im Beruf des Solution Engineers ist, sowohl auf der Business-Seite als auch auf der technischen Seite erfolgreich mit Anderen zu kommunizieren. Auf Kundenseite gilt es, drastisch ausgedrückt, zu verhindern, dass die Anforderung nach dem Prinzip „Ich will das!“ aufgebaut ist und keine weiteren Informationen fließen. Der Solution Engineer muss dem Gesprächspartner also von der technischen Warte aus verständlich machen, dass er weiß worum es geht, aber vielleicht einen ganz anderen Lösungsansatz hat. In einem anderen Fall ist es vielleicht nötig mit den richtigen Worten darzustellen, dass eine Anforderung seitens des Requesters noch einmal überdacht werden sollte. Was das eigene Entwickler-Team angeht müssen die Informationen möglichst verlustfrei in harte Fakten, also Systemspezifikationen umformuliert werden.

Den Dialog aufrecht zu erhalten ist eine typische Herausforderung in der täglichen Arbeit eines Solution Engineers. Für mich birgt dieser Dialog aber auch eine große Motivationsquelle. Neben dem guten Gefühl auf technischer Ebene einen Teil zu einem erfolgreichen Projekt beigetragen zu haben, ist es immer wieder motivierend, wichtige bisher nicht angesprochene Aspekte aus einem Gespräch „heraus zu kitzeln“.

Der Weg zum Ziel

Ich kann zwar keine Handlungsanweisung geben, wie man die Position eines Head of Solution Engineering erreichen kann, aber aus meiner Erfahrung heraus ist es das Beste, sich in ein Software-Projekt zu stürzen. Ich empfehle zu versuchen, sich als Teil eines solchen Projektes zu fragen, was getan werden sollte, um eine passende Lösung zu finden. Ganz wichtig ist auch einen bereits ausgewählten Lösungsansatz weiter kritisch zu hinterfragen. Das Ganze muss gar nicht im großen Stil stattfinden. Die Übung macht den Meister! Für den Anfang reicht es aus, sich in einer kleinen Entwicklergruppe die Frage zu stellen: Hilft das was wir da entwickeln dem Requester wirklich? Ansonsten möchte ich denen, die an einer entsprechenden Position interessiert sind sehr ans Herz legen, was ich zuvor bereits beschrieben habe: Neben dem Fachwissen ist Kommunikation wichtig, aber auch die Fähigkeit zu abstrahieren und vom Abstrakten wieder zum Konkreten zu gelangen.

Jin-Ha Tchoe
IT-Business-Analyst