Vom Aha‑Moment zur Doppelrolle: Wie Katja Hammer bei Doka GmbH Softwareentwicklung und Requirements Engineering verbindet

Ein Einstieg, der nicht mit Liebe begann – und warum das zählt

Aus Sicht der DevJobs.at‑Redaktion ist es oft der vermeintlich unspektakuläre Weg, der am meisten über echte Karrierewege in der Software erzählt. In der Session „Katja Hammer, Software Developer bei Doka” (Speaker: Katja Hammer, Company: Doka GmbH) nimmt uns die Softwareentwicklerin mit auf eine Reise, die vor allem eines zeigt: Begeisterung entsteht nicht immer von Beginn an, sondern wächst durch passende Lernumgebungen, konkrete Aufgaben – und das Erlebnis, dass die eigene Arbeit Wirkung entfaltet.

Katja beschreibt ihren Start ungeschönt: Sie habe mit dem Programmieren „im Zuge [ihrer] Ausbildung in der IT‑HTL” begonnen, aber:

Entscheidend ist die Wendung im dritten Ausbildungsjahr. Als sich der Fokus auf eine andere Programmiersprache verschiebt, erlebt sie, wie sie sagt, einen echten „Aha‑Moment”. Plötzlich macht es „richtig Spaß”. Dieser Moment ist mehr als ein Stimmungswechsel. Er markiert die Stelle, an der Neugier und Selbstvertrauen zusammenfinden – ein wiederkehrendes Muster in vielen Entwicklerbiografien, das uns im Talk klar entgegentritt.

Die Rolle der Ausbildung: Grundlagen, die Türen öffnen

Katja hat die HTL mit dem Schwerpunkt Medientechnik abgeschlossen – ein Detail, das rückblickend Bedeutung gewinnt. Einerseits vermittelt eine technische Schule solide Grundlagen; andererseits öffnet der Schwerpunkt in Richtung Gestaltung und Medien früh die Tür zur Nutzerperspektive. Genau diese Brücke wird später relevant, als sie erste Schritte im UI/UX‑Design setzt.

Im Talk wird deutlich: Der Ausbildungsteil war für Katja der Startpunkt, nicht die Zielgerade. Die Grundlagen aus der HTL erlaubten ihr, nach dem Abschluss rasch Anschluss in der Praxis zu finden. Das zeigt sich unmittelbar in ihrem Berufseinstieg.

Berufseinstieg bei Doka: Wirkung durch interne Tools

Nach dem Abschluss fand Katja „relativ schnell einen Job bei der Doka” und stieg in die Arbeit an einem internen Kalkulationstool ein. Interne Werkzeuge fehlen oft auf Hochglanz‑Foliensätzen, sind aber in vielen Unternehmen der Motor produktiver Teams. Wer hier mitentwickelt, lernt die Funktionsweise der Organisation aus nächster Nähe kennen: Geschäftslogik, Datenflüsse, Release‑Praktiken – und vor allem, wie Software den Arbeitsalltag spürbar verändert.

Katja beschreibt, wie im Laufe der Zeit „andere Programme dazugekommen” sind, an denen sie mitarbeiten durfte. Das ist ein leiser, aber wichtiger Indikator. Mehrere Systeme bedeuten unterschiedliche Stakeholder, andere Anforderungen – und damit die Chance, die eigene Problemlösungskompetenz zu erweitern. So baut sich echte Seniorität auf: nicht nur durch Sprache oder Framework, sondern durch Kontextbreite.

Die Öffnung Richtung UI/UX: Gestaltung trifft Engineering

Mit diesem Jahr ergab sich für Katja die Möglichkeit, „sich im Bereich UI, UX‑Design etwas auszuprobieren”. Dass sie die HTL mit Schwerpunkt Medientechnik abgeschlossen hat, erweist sich als solides Fundament. Es bringt die Sensibilität mit, Nutzeroberflächen nicht nur technisch korrekt, sondern auch zugänglich und stimmig zu denken.

Was uns daran beeindruckt: Diese Erweiterung ist kein Kategoriewechsel, sondern eine Ergänzung. In vielen Teams werden heute End‑to‑End‑Verantwortung und enger Austausch zwischen Entwicklung und Design erwartet. Wenn eine Entwicklerin Schritte in Richtung User Experience macht, verkürzt sie Feedbackschleifen – und versteht, warum bestimmte Anforderungen entstehen. Genau diese Verbindung spiegelt sich in Katjas aktueller Teamrolle.

Im Sales‑ und Operations‑Team der IT: Zwei Aufgaben, ein Ziel

Katja verortet sich klar: Sie ist „Teil vom Sales und Operations Team in der IT” und hat „primär zwei Aufgaben”.

1) Softwareentwicklung – mit allem, was dazugehört:

• Anforderungen gemeinsam mit den Fachbereichen spezifizieren
• Programmieren und die Umsetzung der Anforderungen
• Software‑Releases und der Betrieb im Sinne von kontinuierlicher Weiterentwicklung

2) Requirements‑Engineering – als Partnerin der Fachabteilung:

• In Projekte eingebunden werden
• Der Fachabteilung helfen, IT‑Anforderungen zu definieren und zu schärfen

Diese Doppelrolle macht den Talk besonders relevant für alle, die zwischen Business und Tech vermitteln. Sie verdeutlicht, dass Wertschöpfung in der Software nicht an der Codezeile endet. Wer die Sprache der Domäne versteht, formt bessere Anforderungen – und entwickelt Lösungen, die tatsächlich passen.

Nähe zur Fachabteilung: Wo klare Anforderungen entstehen

Die Beschreibung „Die Fachabteilung [kann] mich zu Projekten als Partner hinzuholen” zeigt ein Verständnis von Zusammenarbeit, das wir in vielen erfolgreichen Teams sehen. Es geht darum, früh dabei zu sein – nicht erst dann, wenn ein Lastenheft vorliegt. Die gemeinsame Spezifikation ist ein Qualitätshebel.

• Frühzeitiger Austausch reduziert Missverständnisse und Rework.
• Gemeinsame Definitionen bringen implizite Annahmen ans Licht.
• Fachbereiche lernen, was technisch sinnvoll ist; Entwickler lernen, was fachlich wichtig ist.

Katjas Formulierung „Ich helfe der Fachabteilung, die IT‑Anforderungen zu definieren” beschreibt genau diesen Impact. Gute Requirements entstehen nicht im luftleeren Raum; sie sind das Resultat gut moderierter Gespräche.

Lernwege in die Software: Es gibt mehrere, und das ist gut so

Ein für uns zentrales Motiv in Katjas Story: Es gibt nicht nur einen richtigen Weg in die Softwareentwicklung. Sie beschreibt die Spannweite – vom Selbststudium über „Tutorials im Internet” bis zu „Kurse[n], Schule[n] oder Studium” mit begleitender Betreuung. Und sie vermeidet die Falle, eine allgemeine Empfehlung auszusprechen:

Für sie persönlich war der Weg über die HTL „ein guter Weg”. Entscheidender Verstärker war dann das Umfeld bei Doka: „Dank meiner Kollegen […] habe ich dieses Wissen schnell festigen und ausbauen können.” Die Botschaft dahinter ist universell: Grundbildung plus eine Praxisumgebung, die Wissen vertieft, beschleunigen Lernkurven.

Der unterschätzte Hebel „Team”: Lernen passiert im Kontext

Wenn Katja darüber spricht, Wissen „festigen und ausbauen” zu können, steckt darin das Zusammenspiel aus Feedback, Pairing, Code‑Reviews und pragmatischem Projektdruck. All das führt dazu, dass Theorie zur Praxis wird: Anforderungen verstehen, Änderungen sicher releasen, mit Fachbereichen sprechen – das sind Kompetenzen, die nicht im Lehrbuch allein entstehen.

Gleichzeitig zeigt ihre Laufbahn, wie wertvoll es ist, Räume zum Ausprobieren zu haben. Die Möglichkeit, UI/UX mitzudenken, ist so ein Raum. Wer so Verantwortung über die Schnittstelle zum Nutzer übernimmt, gestaltet Software ganzheitlicher.

Von Rückschlägen und Vorurteilen: Durchhalten ist Teil des Plans

Katja spart die unbequemen Teile nicht aus. Ihr Tipp fällt deutlich aus:

Das ist keine Floskel. Wer neue Technologien lernt oder Fachbereiche begleitet, wird Fehler machen, Annahmen korrigieren, Entscheidungen revidieren. In solchen Situationen entscheidet die Kultur: Darf man scheitern? Wird Lernen ermöglicht? Katjas Appell an Selbstvertrauen und Durchhaltevermögen ist deshalb auch ein Appell an Teams und Organisationen, die passende Umgebung zu schaffen.

Praktische Einsichten für Entwicklerinnen und Entwickler

Aus dem Gespräch lassen sich konkrete, alltagstaugliche Leitlinien ableiten:

• Schaffe früh Aha‑Momente: Probiere unterschiedliche Sprachen, Paradigmen und Aufgaben aus. Oft ist es der Perspektivwechsel, der das Feuer entfacht.
• Suche Nähe zur Domäne: Arbeite mit Fachabteilungen an der Anforderung – nicht nur an deren Umsetzung. Das verbessert Qualität und Geschwindigkeit.
• Baue auf Grundlagen auf: Eine solide Ausbildung (ob formal oder autodidaktisch) ist das Sprungbrett. Entscheidend ist, wie schnell du sie in Projekten anwendest.
• Nutze dein Team: Kolleginnen und Kollegen sind Lernbeschleuniger. Frage nach Feedback, suche Pairing‑Situationen, lies und diskutier Code.
• Übersetze zwischen Welten: Requirements‑Engineering ist kein „Extra”, sondern Kernarbeit moderner Softwareentwicklung. Wer beides kann, stiftet überproportional Nutzen.
• Halte Irritation aus: Rückschläge sind Signal, nicht Stigma. Justiere Lernpfade, statt aufzugeben.

Ein genauer Blick auf die Doppelrolle: Warum sie heute so wertvoll ist

Katjas Arbeitsalltag umfasst sowohl das „Wie” (Implementierung, Releases) als auch das „Was” (Anforderungen). Diese Verbindung ist aus unserer Sicht die Antwort auf die Komplexität moderner IT‑Landschaften:

• Anforderungen sind selten vollständig: Wer gleichzeitig entwickeln kann, hinterfragt Annahmen präziser – und macht Vorschläge, die technisch und fachlich tragfähig sind.
• Entwicklung profitiert von Kontext: Wer die Entstehung der Anforderungen begleitet hat, umgeht blinde Flecken in der Umsetzung.
• Releases werden ruhiger: Wer nahe an Nutzerinnen und Nutzern ist, schneidet Features präziser und reduziert Überraschungen im Betrieb.

Dass Katja dies im Sales‑ und Operations‑Kontext tut, zeigt, wo Software oft den größten Hebel hat: nahe am Geschäft, in den Abläufen, die täglich Wert schaffen.

Interne Tools als Lernkurve: Warum sie Karrierebooster sein können

Katjas Start an einem internen Kalkulationstool ist ein Paradebeispiel dafür, wie Lernkurven in realen Teams entstehen:

• Klarer Nutzen: Jede Verbesserung spiegelt sich direkt in der Arbeit der Fachabteilung.
• Schnelles Feedback: Nutzer sitzen sprichwörtlich „im Haus”; Releases wirken unmittelbar.
• Breiter Stack: Von Geschäftslogik über Daten bis UI – interne Anwendungen decken oft die ganze Kette ab.

So wird aus „nur intern” ein echter Booster für technische und kommunikative Fähigkeiten.

Die Rolle von Designkompetenz: UI/UX als Brücke zum Nutzer

Die Möglichkeit, sich im UI/UX‑Design auszuprobieren, ist mehr als ein persönliches Interesse. Sie ist ein Signal dafür, wie Produktentwicklung heute gedacht wird. Selbst wenn Entwicklerinnen nicht die Designrolle übernehmen, hilft die Sensibilität für Nutzeroberflächen dabei, bessere Entscheidungen im Code zu treffen:

• Klarheit: Gute Oberflächen erzwingen gute Domänenmodelle.
• Priorität: Was Nutzer brauchen, hat Vorrang vor technischer Eleganz.
• Kohärenz: Ein konsistentes Nutzererlebnis verlangt ein konsistentes Architekturdenken.

Katjas medientechnischer Hintergrund liefert dafür eine stimmige Basis.

Lernpfade wählen: Typgerecht statt dogmatisch

Besonders wohltuend ist Katjas Absage an den „einen richtigen Weg”. Ob Tutorials, Kurse, Schule oder Studium – entscheidend ist die Passung zum eigenen Lerntyp und das Umfeld, in dem man das Gelernte anwendet. Ihr persönlicher Weg über die HTL zeigt: Praxisnähe kombiniert mit strukturierten Grundlagen entfaltet Wirkung – vor allem, wenn Kolleginnen und Kollegen dieses Wachstum aktiv begleiten.

Für alle, die überlegen, in die Software einzusteigen, lässt sich daraus ein einfacher Fahrplan ableiten:

1) Starte mit Experimenten: Kleine Übungen, kurze Projekte, unterschiedliche Sprachen und Frameworks.

2) Suche Struktur: Wenn dir Selbstlernen schwerfällt, wähle Kurse oder eine Schule, die dir Rhythmus und Feedback gibt.

3) Finde Praxis: Projekte – ob intern, im Praktikum oder in der ersten Stelle – machen aus Wissen Können.

4) Bleib offen: Interessen können sich verschieben. So wie bei Katja der Fokuswechsel den „Aha‑Moment” ausgelöst hat.

Zusammenarbeit mit der Fachabteilung: So wird Requirements‑Engineering zur Teamleistung

Katja beschreibt, wie sie als Partnerin in Projekte geholt wird, um „IT‑Anforderungen zu definieren”. In der Praxis heißt das:

• Gemeinsame Sprache finden: Fachbegriffe präzisieren, Beispiele nutzen, Abnahmekriterien formulieren.
• Konflikte früh sichtbar machen: Was ist wichtig, was ist verzichtbar? Welche Abhängigkeiten bestehen? Welche Releaseschritte sind vernünftig?
• Verbindlichkeit schaffen: Wenn Fachbereich und Entwicklung gemeinsam formulieren, wachsen Commitment und Verständnis.

So entsteht Qualität nicht erst im Code, sondern bereits in der Anforderung.

Roter Faden der Story: Zutrauen, Kontext, Entwicklung

Wenn wir Katjas Weg zusammenfassen, zeigt sich ein Muster:

• Zutrauen: Trotz eines holprigen Starts dranzubleiben, bis der „Aha‑Moment” kommt.
• Kontext: Früh in reale Problemstellungen eintauchen – interne Tools, reale Nutzer, echte Anforderungen.
• Entwicklung: Die eigene Rolle erweitern – von der Implementierung über die Anforderung hin zur Nutzerperspektive.

Dieser Dreiklang macht Karrierewege resilient und anschlussfähig. Er erklärt, wie man in einem dynamischen Feld wie der Softwareentwicklung nicht nur Schritt hält, sondern stetig an Wirkung gewinnt.

Was Teams von Katja Hammers Beispiel mitnehmen können

• Öffnet Wege: Ermöglicht Seitwärtsbewegungen wie UI/UX‑Erfahrungen – sie zahlen sich in Produktqualität aus.
• Holt Entwickler früh ins Gespräch: Je früher die Engineering‑Sicht auf Anforderungen trifft, desto zielgenauer die Lösung.
• Fördert Lernumgebungen: Pairing, Reviews, Mentoring – sie beschleunigen das Festigen von Grundlagen.
• Respektiert Lerntypen: Nicht jeder Weg passt zu jedem. Entscheidend ist die Passung und die Möglichkeit zur Anwendung.

Abschluss: Ein klarer, menschlicher Weg in die Tech‑Karriere

„Katja Hammer, Software Developer bei Doka” zeigt in kompakter Form, was eine robuste Entwicklerlaufbahn prägt. Nicht der perfekte Start, sondern die stetige Bewegung: von ersten Grundlagen zur praxisnahen Umsetzung, von der Implementierung zur Anforderungsarbeit, von Technik zur Nutzerperspektive. Und dazu die Haltung, sich nicht von Rückschlägen oder Vorurteilen entmutigen zu lassen.

Für uns ist das die ermutigende Botschaft dieses Talks mit Speaker: Katja Hammer (Company: Doka GmbH): Der eigene Weg darf Ecken und Kanten haben. Wichtig ist, neugierig zu bleiben, Verantwortung zu übernehmen – und den Moment zu nutzen, in dem aus Pflicht Begeisterung wird.

• 

  

  Benjamin Schauer, Group Leader Digital Operation Tools bei Doka

  Group Leader bei Doka Benjamin Schauer umreißt im Interview die Organisation des Teams für Digital Operation Tools, was dort technologisch spannend ist und wie das Recruiting und Onboarding gestaltet ist.

  Jetzt ansehen
• 

  

  Ronni Bjelosevic, DevOps Team Lead bei Doka

  DevOps Team Lead bei Doka Ronni Bjelosevic gibt im Interview einen Überblick über den Aufbau der Teams im Unternehmen, was dort neue Mitarbeiter erwartet und mit welchen Technologien gearbeitet wird.

  Jetzt ansehen

• 

  

  Matthias Schmutzer, Mobile Developer bei Doka

  Matthias Schmutzer von Doka spricht im Interview über seinen Einstieg ins Software Development, mit welchen Aufgabenbereichen er in seiner aktuellen Arbeit zu tun hat und gibt Ratschläge für Leute, die selbst gerne mit Development starten möchten.

  Jetzt ansehen
• 

  

  Michael Hahn, Corporate Software Architect bei Doka

  Michael Hahn von Doka spricht im Interview über seine analogen Anfänge im Programmieren, was die Aufgaben seines aktuellen Berufes umfassen und gibt Tipps für Neueinsteiger.

  Jetzt ansehen