Head of Solution Engineering – Erfahrungsbericht

Mein fachlicher Hintergrund als Solution Engineer ist ein Studium der Informatik mit Nebenfach Betriebswirtschaftslehre und einem Schwerpunkt auf Softwaretechnologie. Schon während des Studiums habe ich mit der Arbeit als Softwareentwickler 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. Dabei gehörte die Softwareentwicklung immer weniger zu meinen Aufgaben. 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. Dies diente dazu, 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 man während des Entwicklungsprozesses wann kommunizieren 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 als Solution Engineer

Die Hauptaufgabe des Head of Solution Engineering ist, herauszufinden, was die Requester wirklich möchten oder brauchen. Zwar haben sie meist eine konkrete Vorstellung, 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 realisiert man das Softwareprojekt.

Requirements Engineering vs. Solution Engineering

In meinem Fall beinhaltet 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, stimmt man zu diesem Zeitpunkt ab. 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 man eine ganze Reihe von Fragen beantworten. Werden Zahlen eingetragen oder Freitext? Wenn es eine Zahl ist, soll diese mit anderen Zahlen abgeglichen werden? Für den Requester mögen die Antworten vielleicht selbstverständlich sein. Drückt man diese aber nie explizit aus, besteht im Ende vielleicht die Gefahr, dass man das Falsche entwickelt.

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 E-Mail, oder wie auch immer. Bereits hier spricht man mit dem Requester kurz darüber, 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 und wer sehen muss, ob es aktiv ist – es also testet. Auch wie das Feature abgerechnet wird, muss berücksichtigt werden. Dazu gehört auch, zu klären, wer insgesamt in den Entwicklungsprozess involviert ist. Beispielsweise probiert die Support-Abteilung aus, ob das Feature richtig funktioniert, oder 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 beginnt in dieser Phase.

Die dritte Phase nennt sich „pre-study“. In dieser wird sich inzwischen erstmals konkreter mit der Lösung des Problems befasst. Man wählt mögliche technische Lösungen aus vielleicht mehreren Optionen anhand verschiedener Kriterien aus. Dabei berücksichtigt man natürlich auch kaufmännische Aspekte. Wie würden Einnahmen und Kosten ausfallen? Hier gehen notwendige Lizenzen, Arbeitsstunden usw. in die Berechnung mit ein. Am Ende dieser Phase steht die Entscheidung für einen Lösungsweg, oder in manchen Fällen die Entscheidung darüber, ob man das Projekt überhaupt aufnimmt.

Herausforderung und Motivation des Solution Engineers

Die Herausforderung im Beruf des Solution Engineers – sowohl auf der Business-Seite als auch auf der technischen Seite – ist es, mit anderen erfolgreich 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 man eine Anforderung seitens des Requesters noch einmal überdenken sollte. Was das eigene Entwickler-Team angeht, muss man die Informationen möglichst verlustfrei in harte Fakten, also Systemspezifikationen umformulieren.

Den Dialog aufrechtzuerhalten, 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 „herauszukitzeln“.

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 man tun 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, raten, 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