Data Product Ownership

Der Data Product Owner spielt eine zentrale Rolle bei der Entwicklung erfolgreicher Datenprodukte. Neben den Aspekten Desirability, Viability und Feasibility muss er zusätzlich die Perspektive „Datability” managen, denn Unsicherheit, Datenqualität und iterative Weiterentwicklung prägen jedes Datenprojekt. Der Beitrag zeigt, welche Aufgaben und Kompetenzen einen guten Data Product Owner ausmachen und wie sich diese Rolle von der des Data Scientists abgrenzt.

Spec-Driven-Development

Die Verlockung von Large Language Models (LLMs) im Entwicklungsalltag ist riesig: Ein kurzer Prompt im Chat, und Sekunden später steht eine lauffähige Ad-hoc-Lösung bereit. Doch dieser Fokus auf die schnelle Umsetzung hat seinen Preis. Was kurzfristig wie ein massiver Produktivitätsschub aussieht, rächt sich schnell durch mangelnde Wartbarkeit, fehlende Stabilität und das Fehlen einer klaren architektonischen Richtung.

An dieser Stelle setzt das Paradigma des Spec-Driven Developments (SDD) an. Specs waren schon immer mehr als nur staubige Dokumentation: Sie definieren die Anforderungen. Im Zeitalter der KI-gestützten Entwicklung werden sie nun zu einer dynamischen Denkschicht und dem zentralen, geteilten Kontext zwischen Entwickler und Modell.

Video statt lesen?

Dieser Beitrag basiert auf einem unserer internen Share-Knowledges. Gerne schicken wir den Link zum Video an deine E-Mail Adresse.

Spec Driven Development

Die drei typischen Fallstricke der chat-basierten Entwicklung

Wer komplexe Features ausschließlich über interaktive Prompts in einer spontanen Chat-Session entwickelt, baut unbewusst technische Schulden auf. Das liegt nicht an einer generellen Schwäche der LLMs – mit dem passenden Kontext arbeiten diese extrem präzise. Das Problem ist vielmehr das unstrukturierte „Vibe Coding“ ohne festen Rahmen. Ohne ein klares, konsistentes Gerüst wird das Modell mit zersplitterten Informationen gefüttert, wodurch der Blick für das große Ganze und die langfristige Stabilität des Gesamtsystems verloren geht.

Slide: Three Failure Modes of Chat-Driven Development

Beim intuitiven „Vibe Coding“ im Chat stolpert man meist über drei typische Probleme:

  • Fragmentierte Architekturentscheidungen (Fragmented Design Decisions): Da ein Feature meist über mehrere Chat-Sessions hinweg entwickelt wird, fehlt dem Modell ein ganzheitliches Verständnis des Vorhabens. Wichtige Weichenstellungen fließen zwar implizit in den generierten Code ein, sind aber nirgends als explizite Anforderung festgehalten oder versioniert.
  • Abweichung vom Pfad (Prompt Drift): Im Eifer des Gefechts neigt man dazu, nur noch reaktiv auf die Code-Vorschläge der KI einzugehen. Statt das eigentliche Architekturziel konsequent zu verfolgen, lässt man sich vom Fluss des Chats treiben und verliert die ursprüngliche Richtung aus den Augen.
  • Ungesagte Annahmen (Hidden Assumptions): Lücken in den Anforderungen (Underspecified Gaps) füllt das LLM eigenständig mit impliziten Annahmen auf. Diese unaufgelösten Widersprüche und Fehlinterpretationen bemerkt man oft erst viel zu spät – meistens erst bei der Systemintegration.

Die Spec als aktiver „Shared Context“

Spec-Driven Development löst dieses Problem, indem es die Spezifikation der Anforderungen zeitlich vor die eigentliche Code-Generierung stellt. Sie dient als expliziter, versionierter und geteilter Kontext (Shared Context) zwischen dem Software Engineer und dem LLM, bevor auch nur eine Zeile Code geschrieben wird.

Slide: The spec is not only documentation, it is the shared context

Was zeichnet eine effektive Spec im SDD-Umfeld aus?

  • Das Was steht vor dem Wie: Sie beschreibt präzise die fachlichen Anforderungen und die Geschäftslogik. Die KI kümmert sich um die technische Umsetzung, anstatt die Logik selbst erraten zu müssen.
  • Nachvollziehbarkeit der Entscheidungen (Rationale): Sie dokumentiert, warum bestimmte Pfade gewählt und andere verworfen wurden (ähnlich wie klassische Architecture Decision Records).
  • Umgang mit Unbekannten: Offene Fragen (Unknowns) werden explizit festgehalten, anstatt sie von der KI blind wegdiskutieren zu lassen.
  • Klare Grenzen (Out-of-Scope): Die Spec definiert haargenau, wo das Feature endet. Das hindert das LLM daran, eigenmächtig über das Ziel hinauszuschießen.

Die Evolution der Spec: Von Martin Fowler bis zur Praxis

Wie tief die Anforderungen in den KI-gestützten Entwicklungszyklus integriert werden, lässt sich hervorragend anhand der Taxonomie von Martin Fowler (2025) verdeutlichen:

Slide: Taxonomy of Spec-Driven Development
  • Spec-First: Die Anforderungen werden vor der Implementierung sauber aufgeschrieben und dienen der KI als präziser Input. Nach der Code-Generierung wird die Spec oft nicht weiter gepflegt.
  • Spec-Anchored: Die Anforderungen liegen als Markdown-Dateien direkt im Git-Repository. Sie entwickeln sich im Laufe des Projekts weiter und dienen über verschiedene Sessions hinweg als fester Anker für Refactorings und Erweiterungen.
  • Spec-as-Source: Die ultimative Stufe. Die Spezifikation ist das einzige Artefakt, das noch aktiv vom Menschen editiert wird, während der Code direkt daraus generiert wird (oftmals ohne manuelles Review).

Von der Theorie zur Praxis: SpecKit

Die methodischen Ansätze sind das eine, doch wie sieht das Ganze in der Praxis aus? Für die Umsetzung des Spec-Driven Development Workflows existieren mittlerweile mehrere Frameworks – etwa OpenSpec oder SpecKit – die jeweils eigene Schwerpunkte setzen. Ich greife hier exemplarisch das Command-Line-Tool SpecKit heraus, das genau diesen Workflow über strukturierte Befehle für deinen KI-Coding-Assistenten erzwingt. Die vorgestellten Prinzipien lassen sich aber genauso auf die anderen Tools übertragen.

Slide: The SpecKit setup is very lightweight

Der Workflow von SpecKit gliedert sich in fünf aufeinander aufbauende Phasen, die den Entwicklungsprozess leiten und jeweils reviewbare Artefakte erzeugen:

1. Specify (speckit.specify)

Hier werden High-Level-User-Stories in eine standardisierte und maschinenlesbare Anforderungsliste (spec.md) überführt.

Slide: SpecKit's spec.md - From User Stories to Requirements

2. Clarify (speckit.clarify)

Lücken in den User Stories werden nicht stillschweigend von der KI interpretiert. Stattdessen triggert dieser Befehl eine strukturierte Q&A-Runde, um ungesagte Annahmen und Edge-Cases vorab zu klären.

3. Plan (speckit.plan)

Es wird ein detaillierter technischer Umsetzungsplan generiert. Das Ergebnis sind zwei wesentliche Dokumente:

  • research.md: Eine strukturierte Analyse komplexerer Probleme (z. B. Chunking-Strategien bei langen osTicket-Verläufen).
  • contracts/: Festgelegte Daten- und API-Schnittstellenspezifikationen, die im Vorfeld wie ein starres Schema definiert werden.
Slide: Planning mode documents key decisions and details
Slide: Exemplary Contract - Citation Interface Definition

4. Tasks (speckit.tasks)

Der Plan wird in eine konkrete, schrittweise Task-Liste (tasks.md) überführt. Aufgaben, die parallel gelöst werden können, erhalten einen Marker ([P]), was die Arbeitsteilung unter verschiedenen Sub-Agenten ermöglicht.

Slide: SpecKit's task file suggests implementation phases

5. Implement (speckit.implement)

Erst nach dieser lückenlosen Vorbereitung wird der eigentliche Code generiert. Das LLM arbeitet nun nicht mehr im luftleeren Raum, sondern baut den Code entlang der exakt definierten Tasks und Verträge.

Abwägung: Was bringt uns das?

Der Mehrwert (Value)Die Investition (Investment)
Klare Trennung der Absichten (Separated Intent): Logik und Anforderungen (Was) werden sauber von der reinen Code-Syntax (Wie) getrennt.Standardisierungs-Hürden: Es gibt noch keinen allgemeingültigen Industriestandard für KI-Spezifikationen.
Lebendige Dokumentation: Da Anforderungen und Schnittstellen-Spezifikationen im Repository leben, spiegeln sie immer den echten Systemzustand wider.Initialer Mehraufwand (Setup Overhead): Das Einrichten strukturierter Prozesse und das Formulieren der Specs benötigt anfangs mehr Zeit als ein schneller Chat-Prompt.
Konsistenter Kontext: Prompt Drift und das Verzetteln in langen, unübersichtlichen Chat-Verläufen gehören der Vergangenheit an.Pflegeaufwand (Maintenance Debt): Nimmt man Abkürzungen und ändert Code direkt, veraltet die Spec und verliert ihren Wert.
Perfekt für die Kommunikation: Da die fachliche Logik textbasiert festgehalten ist, lässt sie sich hervorragend mit nicht-technischen Stakeholdern besprechen.Höherer Token-Verbrauch: Das ständige Übergeben des gesamten Spec-Kontexts an das LLM sowie die Generierung der Specs erhöht die API-Kosten.

Fazit: Welches Tooling-Level ist das richtige für dich?

Spec-Driven Development bedeutet nicht, dass man für jede kleine Änderung ein riesiges Framework anwerfen muss. Wichtig ist, die Tiefe des Toolings an die Komplexität anzupassen:

  • Level 0 (Keine Spec): Perfekt für schnelle, isolierte Ad-hoc-Bugs, bei denen Stabilität und Richtung keine Rolle spielen.
  • Level 1 (LLM-Planung nutzen): Gut für mittlere Aufgaben, bei denen man die KI vorab um einen strukturierten Plan bittet, ohne diesen zwingend abzuspeichern.
  • Level 2 (Markdown Templates): Ideal für Solo-Entwickler, die ihre Anforderungen in standardisierten Markdown-Dateien im Git pflegen wollen.
  • Level 3 (Dedizierte Spec-Tools): Der Goldstandard für komplexe Features und die Arbeit im Team. Tools wie SpecKit oder OpenSpec garantieren, dass alle Agenten und Entwickler an derselben Wahrheit arbeiten.

Am Ende des Tages ist das exakte Format zweitrangig. Wichtig ist nur der mentale Shift: Erst explizit denken und spezifizieren, dann generieren lassen.

Der Vortrag zum Thema Spec-Driven-Development als Video

Gerne schicken wir den Video-Link an deine E-Mail Adresse.

Spec Driven Development


Autorin

Alina Dallmann

Alina Dallmann
Data Scieneer bei scieneers GmbH

alina.dallmann@scieneers.de

Ein Buchstabe, der alles verändert: Die Geschichte der Sichelzellkrankheit

Eine einzelne Mutation im HBB-Gen verursacht die Sichelzellkrankheit, indem sie Form und Funktion der roten Blutkörperchen verändert. Dieser Artikel beleuchtet die Biologie hinter der Krankheit, ihren Zusammenhang mit Malaria und wie CRISPR-Gentherapien wie Casgevy und Indiens Birsa-101 die Mutation an ihrem Ursprung korrigieren wollen.

Die Suche nach der Nadel im genomischen Heuhaufen

Jedes menschliche Genom enthält Millionen genetischer Varianten. Die meisten sind harmlos, doch manchmal kann schon eine einzige Veränderung eine schwere Krankheit verursachen. Diese eine Variante zu finden gleicht der Suche nach der Nadel im Heuhaufen – eine Herausforderung, die zunehmend mit Machine Learning angegangen wird.

Dynamische Disposition in Straßenbahndepots durch Reinforcement Learning

Wenn der Linienbetrieb endet, beginnt im Straßenbahndepot ein komplexes Optimierungsproblem. Gemeinsam mit der Firma IVU Traffic Technologies haben wir untersucht, wie Deep Reinforcement Learning die dynamische Disposition im Depot unterstützen kann.

Rückblick auf unser Frühlingsevent 2026

Beim diesjährigen Frühlingsevent in Köln kamen Kolleg:innen aus allen Standorten zusammen, darunter erstmals auch welche aus Berlin und München. Zwei Tage lang standen Austausch, Teamkultur und spannende interne Themen im Mittelpunkt – von Leistungsbeurteilung und Feedback über KI-Ethik bis hin zu Diversity, Co-Design und gemeinsamen Aktivitäten in Köln. Der Rückblick zeigt, wie wertvoll persönliche Begegnungen sind, wenn ein Team weiter wächst und zugleich eng verbunden bleiben möchte.

Frühlingskonferenzen 2026: PyCon DE und PyData & Minds Mastering Machines

Bei den Frühlingskonferenzen 2026 drehte sich alles um KI, Daten und praxisnahe Engineering-Themen. Auf der PyCon DE & PyData sowie der Minds Mastering Machines hielten wir Vorträge zu RAG-Pipelines mit multimodalen Embeddings, Spec-Driven Development, Genolator und KI-Bildgenerierung. Dieser Beitrag gibt einen kompakten Überblick über die wichtigsten Inhalte, technischen Erkenntnisse und zentralen Erkenntnisse der Konferenzen.

Gestaltungsmöglichkeiten für Mitarbeitende bei scieneers 

Eine erfolgreiche Organisation lebt nicht nur von effizienten Prozessen und durchdachten Strategien, sondern vor allem von den Menschen, die sie mit ihrem Wissen, ihren Erfahrungen und ihren vielfältigen Perspektiven täglich gestalten. Genau diese Vielfalt lässt unser Team wachsen und stärker werden. Deshalb ist es uns wichtig, dass alle unsere Mitarbeitenden die Möglichkeit haben, sich aktiv einzubringen und ihre Stimme zu nutzen. 

Ob durch regelmäßiges Mitarbeitenden-Feedbackindividuelle Ideen oder die Mitwirkung an internen Themen: Beteiligung ist ein fester Bestandteil unserer Kultur. Dadurch entwickeln wir uns gemeinsam weiter, lernen voneinander und schaffen ein Arbeitsumfeld, in dem sich alle gehört und wertgeschätzt fühlen. 

In diesem Beitrag zeigen wir, welche Möglichkeiten es gibt, sich einzubringen, und wie jede Person unsere Unternehmenskultur aktiv mitgestalten kann. 

1. Regelmäßiges Mitarbeitenden-Feedback 

Regelmäßiges Mitarbeitenden-Feedback ist ein essenzieller Bestandteil unserer Zusammenarbeit. Es bietet Raum für offene Rückmeldungen, neue Perspektiven und konkrete Vorschläge und trägt dazu bei, dass wir uns als Team kontinuierlich weiterentwickeln können. 

Ein zentrales Format dafür ist unsere jährliche Mitarbeitendenzufriedenheitsumfrage. Sie findet anonym statt, sodass alle Mitarbeitenden ihre Meinungen, Einschätzungen und konstruktive Kritik offen teilen können – auch zu Themen, die im Arbeitsalltag möglicherweise weniger sichtbar sind. Ein Beispiel hierfür ist die Frage, wie wir Diversity in unserer Arbeitsumgebung weiterhin aktiv vorantreiben können. 

Die Ergebnisse sind dabei mehr als nur ein Stimmungsbarometer. Sie helfen uns, Entwicklungen frühzeitig zu erkennen, gezielte Maßnahmen abzuleiten und einen kontinuierlichen Dialog zu fördern, der unsere Organisation nachhaltig stärkt.

 

Darüber hinaus führen wir regelmäßig Umfragen zu verschiedenen internen Themen durch. Sie schaffen einen geschützten Raum, in dem wir konkretes und ehrliches Feedback – gerne auch anonym – einholen können, und dienen als Ausgangspunkt für gemeinsame Gespräche, Workshops und interne Initiativen. Anschließend werden diese Initiativen in kleineren Arbeitsgruppen aktiv umgesetzt. Mehr dazu erzählen wir gleich. 

Die Meinung von Mitarbeitenden ist aber auch persönlich stets willkommen, egal ob bei einem spontanen Austausch oder im Rahmen des Jahresgesprächs. 

2. Shared Knowledge Sessions

Neben regelmäßigem Mitarbeitenden-Feedback ist auch der regelmäßige Wissensaustausch für unsere tägliche Arbeit von großer Bedeutung. Ein etabliertes Format dafür sind unsere Shared-Knowledge-Sessions. Sie finden alle zwei Wochen statt und bieten einen offenen Rahmen, in dem wir unser Wissen miteinander teilen und voneinander lernen können. 

Die Inhalte dieser internen Sessions entstehen direkt aus dem Arbeitsalltag. Mitarbeitende haben die Möglichkeit, eine Session zu einem Thema ihrer Wahl anzubieten. Dabei ist es egal, ob es sich um ein technisches Thema, ein neues KI-Tool oder ein persönliches Interessengebiet handelt. 

Gleichzeitig bieten sie allen Teilnehmenden die Möglichkeit, neue Einblicke in unterschiedliche Arbeitsbereiche zu gewinnen, von den Erfahrungen der Kolleg:innen zu profitieren und ihr eigenes Wissen kontinuierlich zu erweitern. Der regelmäßige Wissensaustausch fördert eine offene Lernkultur und schafft eine Umgebung, in der Informationen und Wissen frei zugänglich sind, transparent geteilt werden und gemeinsam weiterentwickelt werden können. Außerdem findet wöchentlich ein Treffen von Mitarbeitenden aller fünf Standorte statt, bei dem verschiedene Themen besprochen werden. Dadurch erhalten alle einen tieferen Einblick in die Arbeit der anderen und erfahren, wie sie an die Themen herangehen. 

3. Individuelle Ideen

Gute Ideen können überall entstehen und sich auf die unterschiedlichsten Bereiche beziehen. Wir laden daher alle Mitarbeitenden aktiv dazu ein, eigene Vorschläge und Impulse zur Verbesserung interner Prozesse sowie zur Weiterentwicklung unserer Unternehmenskultur einzubringen. Jede Idee kann ein wertvoller Impuls für die Weiterentwicklung unserer Organisation sein.  

In den vergangenen Jahren sind bereits verschiedene Initiativen aus Ideen von Mitarbeitenden entstanden: So wurde beispielsweise auf Wunsch von Mitarbeitenden die Rolle der Diversity-Managerin geschaffen, ebenso wie Formate wie die oben genannte Mitarbeitendenumfrage oder die Frauenrunde (Ein Treffen, das einmal im Monat stattfindet und bei dem sich alle Mitarbeiterinnen zusammenkommen, um sich miteinander auszutauschen). Auch der DesInfo-Navigator ist ein Ergebnis interner Impulse. Wer auch eine Idee für ein After-Work-Event hat, kann diese jederzeit im Channel bei ihrem Standort teilen.

Ein weiteres Beispiel ist die Idee eines Mitarbeitenden, zunächst einen Coffee Bot auf unserem internen Kommunikationskanal zu testen und ihn anschließend umzusetzen. Das ist heute ein bedeutender Aspekt unseres Arbeitsalltags geworden. Dabei werden zwei oder mehr Arbeitskolleginnen und Kollegen, die Lust und Zeit haben, zufällig zu einem Catchup Round zusammengebracht. Je nach Matchup können sie sich im Büro oder remote zusammensetzen und sich einfach austauschen. So haben wir die Möglichkeit, uns über unsere Zusammenarbeit hinaus besser kennenzulernen.

Wer eine Idee hat, kann diese jederzeit über interne Kanäle teilen oder das Thema direkt im Team ansprechen. So entsteht ein offener Austausch, in dem neue Ansätze sichtbar werden, die gemeinsam weitergedacht werden können. 

4. Mitgestaltung interner Themen

Viele der individuellen Ideen, die von uns ausgehen, entwickeln sich anschließend in konkrete Initiativen. Neben der Möglichkeit, Feedback zu geben und eigene Ideen einzubringen, können sich Mitarbeitende aktiv an internen Themen beteiligen und deren Weiterentwicklung mitgestalten. 

Zu diesem Zweck bilden sich zu verschiedenen internen Themen (z. B. Projektzufriedenheit, kollegiales Feedback usw.) eigenständig Arbeitsgruppen. Sie entstehen aus dem Interesse und der Initiative unserer Mitarbeitenden. In den Gruppen beschäftigen wir uns mit organisatorischen, technischen oder kulturellen Themen, zu denen wir gemeinsam neue Konzepte entwickeln, Wissen strukturieren und an Lösungen arbeiten. Bei unseren zweimal im Jahr stattfindenden Firmenevents im Frühling und Herbst können die neuen Ergebnisse sowie der aktuelle Stand interner Projekte mit allen geteilt werden.  

Ein Beispiel hierfür ist das Thema „Familiäres Wachstum“. Hierzu hat sich eine kleine Arbeitsgruppe gebildet, die sich neben der täglichen Arbeit mit Kundenprojekten die Zeit nimmt, das Thema in einem internen Projekt voranzutreiben. Der aktuelle Stand zu diesem Thema ist, dass wir derzeit Geburtstagsbuddys haben. Wer Lust hat, kann sich beteiligen, indem er oder sie sich am eigenen Standort mit anderen zufällig als Geburtstagsbuddy matchen lässt, um sich gegenseitig kleine Geschenke zu machen. Darüber hinaus entstehen aus diesen Initiativen immer wieder weitere Formate und Angebote, wie beispielsweise ein interner Merch-Shop oder gemeinsame Potluck-Partys

Ein weiteres Thema, das für uns als Unternehmen in letzter Zeit spannend ist, ist die Entwicklung des Data Product Ownership (DPO). Warum wir das Thema gestalten: Als Data Product Owner können wir unsere Kunden in Bezug auf Data Products und Strategien besser unterstützen. Dabei können Mitarbeitende, die daran interessiert sind, die Weiterentwicklung selbst mitgestalten und weitere Schritte mitbestimmen. Unser Angebot zum Thema DPO wird hier näher erläutert.

Auf diese Weise kann Mitgestaltung zu einem aktiven Bestandteil unseres Arbeitsalltags werden. Dazu gehört auch, dass Mitarbeitende an ihren Standorten regelmäßig eigene Teamevents planen und umsetzen können. Durch den regelmäßigen Austausch hat jede Person die Möglichkeit, ihre Perspektive einzubringen und dazu beizutragen, unsere Unternehmenskultur bewusst mitzuprägen. 

5. Planung und Gestaltung von Events

Wie bereits erwähnt, finden unsere Firmenevents zweimal im Jahr statt. Unsere Mitarbeitenden erwartet dabei ein abwechslungsreiches Programm aus inhaltlichem Austausch, gemeinsamen Aktivitäten und Raum für persönliches Kennenlernen. 

Im Rahmen von Projektvorstellungen, Wissensaustauschformaten und Lightning Talks zu technischen oder persönlichen Themen geben Kolleg:innen Einblicke in ihre Arbeit und Interessen. Gleichzeitig schaffen gemeinsame Erlebnisse wie Graffiti-Workshops oder Escape-Room-Besuche einen Ausgleich zum Arbeitsalltag. Auch das gemeinsame Abendessen bietet Raum für Austausch in entspannter Atmosphäre. 

Zum Abschluss jedes Events findet selbstverständlich eine Feedbackrunde statt, in der wir erfahren, was wir beibehalten und was wir beim nächsten Mal besser machen können. 

Auch diese Veranstaltungen leben von der aktiven Beteiligung unserer Mitarbeitenden. Bei uns übernimmt nicht eine Person die zentrale Planung, sondern mehrere Kolleg:innen bringen sich in die Organisation ein, sammeln Ideen und entwickeln gemeinschaftlich ein Programm, das die Interessen unseres Teams widerspiegelt. 

So gab es bei unserem letzten Event im Herbst beispielsweise ein gemeinsames Flammkuchenessen und einen Besuch im Funpark. Unsere Frühlingsevent und unser Herbstevent im Jahr 2025 sind auf unserem Blog zu lesen.

Leerer Seminarraum mit Stuhlreihen, rundem Tisch mit Projektor und Leinwand vor großen Fenstern.

Gerade weil unser Unternehmen kontinuierlich wächst und immer wieder neue Mitarbeitende dazukommen, ist jede Veranstaltung an jedem unserer Standorte einzigartig. Die gemeinsamen Erlebnisse, die wir als vollständiges Team bei diesen Veranstaltungen haben, fördern den persönlichen Austausch, stärken unseren Zusammenhalt und ermöglichen Gespräche, die im Arbeitsalltag oft zu kurz kommen. 

Gemeinsam gestalten wir unsere Organisation

Mitarbeitendenbeteiligung bedeutet viel mehr als nur Feedback zu geben und anzunehmen. Sie bedeutet auch, eigene Ideen einzubringen, Initiative zu ergreifen und aktiv zur Weiterentwicklung unserer Kultur beizutragen. Jede Meinung, jede Initiative und jedes Engagement trägt dazu bei, unser Team weiterzuentwickeln und zu stärken. 

Sei es durch die Erfassung von Meinungen, die Mitteilung eigener Ideen oder die Mitwirkung an internen Themen: Beteiligung schafft TransparenzVertrauen und Vielfalt. Sie hilft uns, unser Miteinander zu stärken und als Team weiterzuwachsen. 

Wir laden alle Mitarbeitenden ein, diese Möglichkeiten zu nutzen, Fragen zu stellen und neue Impulse zu setzen. Denn am Ende gestalten wir unsere Organisation gemeinsam. 

Bewerbungsprozess bei scieneers

Du möchtest Teil von scieneers werden? Hier erfährst du Schritt für Schritt, wie unser Bewerbungsprozess aussieht – von der Online-Bewerbung über Remote-Interviews bis zum Kennenlernen vor Ort. Finde heraus, ob wir zueinander passen, und entdecke, was im Bewerbungsprozess besonders wichtig ist: Persönlichkeit, Eigeninitiative und Begeisterung für Technik.

Einblicke von der Microsoft AI Tour 2026 in München – zwischen Vision, Souveränität und konkreten Anwendungen

Ein Besuch auf der Microsoft AI Tour 2026 in München zeigt, wie rasant sich KI von einer experimentellen Technologie zu einer zentralen Infrastruktur für Unternehmen und Forschung entwickelt. Von multimodalen Modellen im Healthcare‑Bereich über neue Konzepte digitaler Souveränität bis hin zu KI‑gestützten Entwicklungsplattformen und Agenten in Business‑Prozessen – ein persönlicher Erfahrungsbericht über die wichtigsten Eindrücke und Entwicklungen rund um die nächste Generation von KI‑Systemen.