SSI Schäfer IT Solutions GmbH
Manuela Jobstmann, Requirements Engineer bei SSI Schäfer IT Solutions
Description
Manuela Jobstmann von SSI Schäfer IT Solutions erzählt im Interview über ihren Werdegang in der IT bis hin zur aktuellen Rolle im Requirements Engineering und gibt Tipps für Neueinsteiger.
Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.
Video Zusammenfassung
In "Manuela Jobstmann, Requirements Engineer bei SSI Schäfer IT Solutions" berichtet Manuela Jobstmann von ihrem späten Quereinstieg: Mit 38 absolvierte sie eine Programmierausbildung (u. a. C++, Java, C#), bildete sich kontinuierlich fort, machte mit 48 einen Master in Innovationsmanagement und wechselte danach zu SSI Schäfer als Requirements Engineer, wo Technologie und Logistik für sie neu waren und sie die Zusammenarbeit mit Kunden und Teams schätzen lernte. Sie beschreibt einen klaren RE-Prozess vom Analysieren der Stakeholder-Probleme über Flowcharts, Entwicklerabstimmung und Reviews bis zum teamweiten Acceptance-Test (mit UI/UX, Doku, Entwicklung, Support); parallel begleitet sie die Modernisierung von einer Desktop-Client/Client-Server-Lösung hin zu einer Web-Lösung, um Altlasten zu bereinigen und die Software zeitgemäß auszurichten. Ihre Lehre: Gute Lösungen entstehen kollegial, in offenem Austausch und ohne Hast—unterschiedliche Perspektiven respektieren, das Arbeitstempo der Kollegen zulassen und offen für Neues bleiben.
Spätstart mit Wirkung: Wie Manuela Jobstmann als Requirements Engineer bei SSI Schäfer IT Solutions von der Programmierausbildung zur Teamorchestrierung fand
Ein klarer Fokus: Von der Ausbildung mit 38 zur Wirkung im Produkt
Bei DevJobs.at haben wir die Session „Manuela Jobstmann, Requirements Engineer bei SSI Schäfer IT Solutions“ mit besonderem Interesse verfolgt. Der Titel nennt klar, worum es geht: Speaker Manuela Jobstmann (Company: SSI Schäfer IT Solutions GmbH) zeigt eine Laufbahn, die viele Vorurteile über späten Quereinstieg, lebenslanges Lernen und die gelebte Praxis von Requirements Engineering ins Wanken bringt.
Ihr Weg ist weder linear noch glatt – und gerade deshalb lehrreich. Mit 38 startet sie eine Programmierausbildung, von Programmierlogik über C++ und objektorientierte Programmierung bis hin zu Java und C#. Es folgen erste Junior-Tätigkeiten „wie jeder halt, nur mit 38 halt“, kontinuierliche Fortbildungen, ein Masterstudium in Innovationsmanagement mit 48 und schließlich der Wechsel zu SSI Schäfer IT Solutions GmbH – in eine Rolle, die ihre Stärken bündelt: Requirements Engineering in einem neuen Domänenumfeld, der Logistik.
Was uns besonders auffiel: die Ruhe, mit der sie über Tempo, Teamarbeit und Qualität spricht. Und der konkrete, strukturierte Blick auf die Arbeit mit Stakeholdern, Produktmanagement und Entwicklung – vom ersten Problemstatement über Flowcharts bis zum gemeinsamen Acceptance-Test.
Meilenstein 1: Die Programmierausbildung mit 38 – ein bewusster Neustart
Der erste markante Wendepunkt: die Entscheidung, mit 38 Jahren eine Programmierausbildung zu beginnen. Inhalte waren laut Manuela Jobstmann unter anderem:
- Programmierlogik
- C++
- Objektorientierte Programmierung
- Java
- C#
Bemerkenswert ist weniger die Liste als die Haltung dahinter. Ein solches Curriculum verlangt Disziplin und den Willen, Grundlagen wirklich zu verstehen. Der Einstieg als Junior – ausdrücklich „wie jeder“, nur eben später – zeigt, dass Seniorität in Jahren nicht automatisch Seniorität in einer Disziplin bedeutet. Entscheidend ist, Verantwortung für das eigene Lernen zu übernehmen.
„Ich habe dann Juniorarbeiten, Tätigkeiten gemacht, so wie jeder halt, nur mit 38 halt.“
Dieser Satz verankert eine Kernbotschaft ihres Vortrags: Es gibt keinen falschen Zeitpunkt, um in Tech einzusteigen. Es gibt nur das falsche Tempo – nämlich zu schnell, ohne Substanz, oder zu langsam, ohne Dranbleiben.
Meilenstein 2: Kontinuierliche Fortbildung – die stille Konstante
Über Jahre hinweg hält Manuela den Takt hoch: „jedes Jahr ein, zwei Fortbildungen“, um beruflich fit zu bleiben. Das klingt unspektakulär – ist es aber nicht. Regelmäßige, kleine Lernschritte schaffen die Voraussetzung, später größere Sprünge zu machen. Wer Requirements formuliert, muss Technologie, Randbedingungen und implizite Annahmen verstehen. Fortbildung ist hier nicht Zierrat, sondern Werkzeugeinsatz.
Diese Haltung kulminiert in einem weiteren großen Schritt: dem Masterstudium Innovationsmanagement mit 48. Der Übergang von Technik- zu Management- und Prozessperspektiven legt die Grundlage für ihre spätere Rolle. Wer Innovation steuert, muss beobachten, abstrahieren und Entscheidungen moderieren – genau das tut Requirements Engineering tagtäglich.
Meilenstein 3: Der Wechsel zu SSI Schäfer IT Solutions – Rolle statt Stack
Nach der Ausbildung und den ersten Berufsjahren sucht Manuela „eine neue Herausforderung“ und geht zu SSI Schäfer IT Solutions GmbH. Die Technologie dort ist anders – weg von der vertrauten Microsoft-Schiene, hin zu Java – und genau daraus ergibt sich ihre Entscheidung für den Einstieg als Requirements Engineer.
- Vorheriger Schwerpunkt: eher Microsoft-Stack
- Neue Umgebung: Java-dominiert
- Konsequenz: Einstieg über Requirements Engineering statt direkt in die Entwicklung
Das ist keine Kapitulation, sondern kluge Rollenwahl: Sie wählt den Hebel, an dem sie sofort Wirkung entfalten kann, statt sich am Stack zu verkämpfen. Dazu kommt eine neue Domäne: Logistik. Sie arbeitet sich ein – und entdeckt Freude am Schreiben von Requirements, an Kundengesprächen und an der internen Abstimmung mit mehreren Abteilungen.
„Logistik war für mich auch neu. Da habe ich mich dann in das Thema eingearbeitet und habe Spaß daran gefunden, also Requirements für die Software zu schreiben.“
Diese Passage unterstreicht: Domänenwissen ist erlernbar, wenn die Haltung stimmt. Was zählt, ist ein strukturiertes Vorgehen und echte Neugier auf das Problem.
Was Requirements Engineering für sie bedeutet
Im Gespräch wird klar, wie Manuela Requirements Engineering versteht – nicht als reines Dokumentationshandwerk, sondern als analytische, moderierende und iterierende Teamleistung. Ihre Haupttätigkeit beschreibt sie so:
- Aufnahme von Problemstellungen aus dem Produktmanagement oder von Stakeholdern
- Analyse der Probleme bzw. des Abbildungswunsches in der Software
- Ausarbeitung eines groben Ablaufs (Flow/Flowchart), wie die Lösung aussehen könnte
- Diskussion des Ablaufentwurfs mit den Entwicklerinnen und Entwicklern, die „eine andere Sicht auf die Software“ haben
- Gemeinsame Lösungsfindung, die an Stakeholder zur Review geht
- Begleitende Abstimmungen während der Entwicklung („Kleinigkeiten“), um die beste Lösung herauszuarbeiten
- Umsetzung, Test, Dokumentation, Release
- Gemeinsamer Acceptance-Test im Meeting mit UI/UX, Doku, Entwicklung und Support
Aus Engineeringsicht ist das ein klarer, beobachtbarer Zyklus: Diagnose – Entwurf – Peer-Review – Validierung – Umsetzung – Prüfung. Die Flowchart-Phase ist dabei nicht Kosmetik, sondern ein verbindendes Artefakt, das unterschiedliche Perspektiven auf einen gemeinsamen Nenner bringt.
„Mit diesem Ablauf oder dem Flow Chart gehe ich dann zu den Entwicklern, diskutiere das mit ihnen. … Gemeinsam finden wir dann eine Lösung.“
Wichtig ist auch die Klarstellung: Ausführliche externe Dokumentation steht nicht im Fokus. Stattdessen zählen Vivibilität in der Zusammenarbeit und gezielte interne Doku, die die Umsetzung trägt.
Die Kraft der Teamarbeit – und ihre Ambivalenz
Manuela betont die Kollegialität im Umgang und die hohe Wertschätzung der Teamarbeit – nicht als Floskel, sondern als gelebte Praxis in Reviews, Entwicklerdialogen und Acceptance-Tests.
- Vorteile: Breitere Sicht, bessere Lösungen, geteilte Verantwortung
- Herausforderung: Unterschiedliche Arbeitsweisen und Perspektiven
„Nur gemeinsam kann man wirklich gute Lösungen finden. Aber das ist zugleich auch die größte Herausforderung, weil jeder arbeitet etwas anders, jeder hat eine andere Sicht auf die Dinge.“
Der Umgang damit ist kein Geheimnis, sondern Handwerk: viele Gespräche, kontinuierliche Zusammenarbeit, individuelles Eingehen auf Kolleginnen und Kollegen. Mit anderen Worten: Teamarbeit ist ein anstrengender, aber wirksamer Qualitätsfilter.
Vom Desktop-Client zur Web-Lösung: Modernisierung als Chance zur Entlastung
Ein besonders konkretes Feld, auf dem Requirements Engineering seinen Nutzen ausspielt, ist die laufende Umstellung: Zur bestehenden Client-Server-Lösung (Desktop-Client) wird bei SSI Schäfer IT Solutions eine Web-Lösung geplant bzw. umgesetzt.
- Anlass: Erweiterung um eine Web-Lösung
- Chance: Jede Anforderung wird auf „Zeitgemäßheit“ hinterfragt
- Effekt: Altlasten ausmisten, modernere User Experience, „schicker“, benutzerfreundlicher
„Das hat den Vorteil, dass man jede einzelne Anforderung auch hinterfragen muss, ob das noch zeitgemäß ist. Man kann da einiges auch ausmisten von Altlasten … und zeitgemäß ist es eigentlich.“
Aus Product- und Engineering-Perspektive steckt hier viel drin: Migrationen sind nicht nur technische Portierungen, sondern strategische Möglichkeiten, Requirements zu entschlacken. Wer bewusst streicht, schafft Klarheit für die nächsten Jahre. Eine Web-Lösung zwingt außerdem zu präziseren Oberflächenflüssen – ideal für Flowcharts und gemeinsame Acceptance-Kriterien.
Akzeptanztests als Teamritual: Qualität gehört allen
Der Acceptance-Test findet „in einem Meeting zusammen“ statt – mit UI/UX, Doku, Entwicklerinnen und Entwicklern sowie Kolleginnen und Kollegen aus dem Support. Diese Zusammensetzung ist kein Zufall: UI/UX prüft Erlebbarkeit, Doku sichert Verständlichkeit, Entwicklung validiert die Implementierung, Support bringt den Blick aus der Praxis ein.
- UI/UX: Bedienbarkeit und Klarheit der Interaktion
- Doku: Verständlichkeit und Nachvollziehbarkeit
- Entwicklung: technische Solidität
- Support: Realitätscheck aus dem Nutzeralltag
Das Ziel: gemeinsam „wirklich das Beste rausholen für alle“. Es ist ein Anspruch, der anstrengend ist – und nur dann erreicht wird, wenn alle Perspektiven von Anfang an in den Ablauf integriert sind.
Tempo, Geduld, Qualität: Eine Arbeitsphilosophie mit Architektur-DNA
Ein zentrales Motiv in Manuelas Erzählung ist das richtige Tempo. Sie verweist explizit auf Erkenntnisse aus dem Bereich Architektur:
„Schnelle Lösungen sind oft nicht die besten. Es braucht Zeit, man muss jeden sein eigenes Tempo mitgehen lassen.“
In komplexen Softwareprojekten trifft diese Einsicht ins Schwarze. Geschwindigkeit ohne Abstimmung erzeugt Reibungskosten, die später als Bugfixing, Usability-Probleme oder technische Schulden wieder auftauchen. Ihre Empfehlung:
- Kolleginnen und Kollegen in ihrem eigenen Tempo arbeiten lassen
- Alternativvorschlägen Raum geben
- Sich selbst „zwischendurch ein bisschen zurücknehmen“ und überzeugen lassen
- Offen sein für neue Dinge
Diese Haltung ist die soziale Ergänzung zum technischen Requirements-Prozess. Sie schützt Teams vor vorschnellen Lösungen und erhöht die Akzeptanz von Entscheidungen.
Der konkrete Ablauf – ein komprimierter Leitfaden aus der Praxis
Aus Manuelas Beschreibung lässt sich ein praxiserprobter Leitfaden destillieren. Er ist simpel genug, um wiederholbar zu sein, und präzise genug, um Orientierung zu geben:
- Problemaufnahme: Hole die Fragestellung klar vom Produktmanagement oder den Stakeholdern.
- Analyse: Kläre, welches Problem gelöst oder was in der Software abgebildet werden soll.
- Grober Ablauf: Skizziere einen Flow/Flowchart – die kleinste gemeinsame Visualisierung.
- Entwicklerdialog: Suche aktiv die technische Gegenperspektive, vergleiche Annahmen.
- Gemeinsame Lösung: Formuliere die Option, an die alle glauben können.
- Stakeholder-Review: Spiegle die Lösung zurück und legitimere sie im Business-Kontext.
- Feinschliff in der Entwicklung: Halte kurze Schleifen für „Kleinigkeiten“.
- Umsetzung, Test, Doku, Release: Baue stabil, prüfe, dokumentiere gezielt, veröffentliche.
- Acceptance-Test im Team: Integriere UI/UX, Doku, Entwicklung, Support – Qualität gehört allen.
Es ist bewusst kein schwergewichtiges V-Modell – und auch kein loses Ad-hoc-Vorgehen. Es ist der pragmatische Mittelweg, der in vielen Produktteams funktioniert.
Lernkurven, die bleiben: Vom Stackwechsel zum Domänenwissen
Zwei Lernkurven prägen Manuelas Geschichte:
- Stackwechsel: Von einer stärkeren Microsoft-Ausrichtung in ein Java-Umfeld – und die bewusste Wahl, Wirkung als Requirements Engineer zu suchen, anstatt sich vom Stack aufhalten zu lassen.
- Domänenwechsel: Einstieg in die Logistik – Einarbeitung, Verständnisaufbau, Freude am Requirements-Schreiben in genau diesem Kontext.
Für Entwicklerinnen und Entwickler ist das eine Einladung: Domänen- und Rollenwechsel sind keine Sackgassen, sondern Multiplikatoren, wenn man den Prozess klar hält und neugierig bleibt.
Teamkultur: Kollegial, aber klar in den Erwartungen
Manuela beschreibt den Umgang als „sehr kollegial“. Gleichzeitig benennt sie die Realität: Unterschiedliche Arbeitsweisen prallen aufeinander. Gute Teamkultur ist nicht die Abwesenheit von Reibung, sondern die Fähigkeit, Reibung produktiv zu machen – durch Gespräche, aktives Zuhören und die Bereitschaft, die eigene Sicht zu relativieren.
„Man rückt da näher und versteht die Kollegen besser und geht auch auf jeden individuell ein.“
Dieser Satz klingt einfach, ist aber anspruchsvoll. Individuelle Bedürfnisse im Takt einer Produktroadmap zu berücksichtigen, erfordert Moderation – genau dort entfaltet Requirements Engineering seinen sozialen Wert.
Was Entwicklerinnen und Entwickler konkret mitnehmen können
Aus der Session „Manuela Jobstmann, Requirements Engineer bei SSI Schäfer IT Solutions“ lassen sich für die Praxis einige klare Schritte ableiten:
- Beginne mit dem Problem, nicht mit der Lösung: Lass Stakeholder zuerst die Schmerzen benennen.
- Visualisiere früh: Ein grober Flowchart verhindert Missverständnisse über Monate hinweg.
- Suche aktiv Gegenperspektiven: Entwicklerinnen und Entwickler sehen die Software anders – nutze das.
- Mache Reviews zum Normalfall: Stakeholder-Feedback ist kein Gate, sondern ein Lernschritt.
- Halte die Schleifen kurz: Kleine Abstimmungen während der Entwicklung sparen große Korrekturen danach.
- Quality as a team sport: UI/UX, Doku, Support gehören an den Abnahmetisch.
- Modernisierung ist Entschlackung: Beim Schritt zur Web-Lösung bewusst Anforderungen streichen.
- Tempo bewusst wählen: „Schnelle Lösungen sind oft nicht die besten.“ Plane Zeit für Reife ein.
- Offen bleiben: Eigene Präferenzen relativieren, andere Sichten anerkennen, dazulernen.
Warum dieser Weg Zukunft hat
Der durchgängige Faden in Manuelas Geschichte ist Verantwortungsübernahme: für das eigene Lernen, für Verständlichkeit im Team, für robuste Entscheidungen. Sie erzählt nicht von Tools, Frameworks oder KPIs – sie beschreibt Arbeit an der Substanz: Problem, Prozess, people.
- Lebenslanges Lernen ist kein Slogan, sondern gelebte Routine (jährliche Fortbildungen, Master mit 48)
- Rollenflexibilität schlägt Stack-Fixierung (Entry über Requirements Engineering in Java-Umfeld)
- Teamprozesse sind kein Selbstläufer (kollegial, aber anspruchsvoll in der Abstimmung)
Für Tech-Teams ist das eine stabile Blaupause – besonders in Umbruchphasen wie dem Übergang von Desktop-Client zu Web-Lösung.
Schlussbild: Der späte Start als unfairer Vorteil
Wer spät beginnt, bringt oft zwei Stärken mit: Demut vor der Materie und Beharrlichkeit im Prozess. In Manuelas Fall führt genau das zu einem Requirements-Engineering-Ansatz, der Menschen zusammenbringt, Annahmen prüft und Qualität sichtbar macht.
„Man muss offen sein für neue Dinge“ – dieser Satz wirkt wie ein leises Fazit. Er erklärt, wie eine Karriere vom späten Einstieg über kontinuierliches Lernen bis zur tragfähigen Teamarbeit wachsen kann. Und er macht Mut, dass Wirkung im Produkt nicht davon abhängt, wann man anfängt – sondern wie man den Weg gestaltet.
