In dieser Episode sprechen Richard Seidl, Christian Mercier, Matthias Gross und Wolfgang Sperling über das Testerjahr 2025, KI im Alltag und Erwartungen an 2026. Nichtfunktionale Qualität rückt nach vorn: Security, Performance, Usability, Compliance. Gefragt sind T-Shaped Skills, technisches Verständnis und Haltung: Intuition, Mut, Resilienz.

Themen im Gespräch sind auch souveräne Cloud, Druck aufs Agile und mehr Validierung in der Produktion. Die Runde betont den Wert aktiver Communitys wie Testland und fragt: Wie gelingt gemeinsames Lernen, das konkrete Probleme löst?

Über die Gäste

Matthias Groß ist Partner von TestGilde und seit 2007 als Berater für Softwarequalitätssicherung und Testmanagement tätig. Seine Schwerpunkte liegen im operativen Testmanagement, der Einführung und Weiterentwicklung von Testmanagementstrukturen sowie der Betreuung kundenspezifischer Testservices. Er engagiert sich zudem an der Dualen Hochschule Baden-Württemberg, ist Mitgründer der Testcommunity The TestLänd und Mitglied des Programmkomitees des QS-Tags.

Christian Mercier begleitet IT-Projekte im Banking-Umfeld. In den klassischen, agilen oder hybriden Projekten nimmt er verschiedene Rollen ein – er ist Projektleiter, Coach, Testmanager, Business-Analyst oder Requirement-Engineer – aber das Thema Qualität steht für ihn immer an zentraler Stelle. Ihm geht es immer um pragmatische Lösungen, die auf fundierten Entscheidungen im jeweiligen Kontext beruhen.

Wolfgang Sperling ist Solution Architekt bei Avanade und Ansprechpartner für den Technologiestack von Microsoft im Kompetenzzentrum für digitale Souveränität bei Accenture. Seit mehr als 15 Jahren beschäftigt er sich mit Qualitätssicherung in Softwareprojekten, einen großen Anteil davon in kritischen oder herausfordernden Projektsituationen. In der Qualitätssicherung ist es ihm wichtig, neben Testen und Testautomatisierung auch Anforderungsmanagement und Releasemanagement in den Softwarelebenszyklus einzuschließen.

Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Software-Test Weihnachtsplausch – Christian Mercier, Matthias Gross und Wolfgang Sperling“ und steht auf YouTube bereit.

(mdo)

In dieser Podcastfolge widmen sich Dominique Winter und Tim Klein dem Spannungsfeld zwischen Vertrieb und Produktentwicklung. Beide bringen zahlreiche Erfahrungen aus Organisationen mit, in denen diese beiden Bereiche eng zusammenarbeiten müssen und sich dabei dennoch häufig gegenseitig blockieren, missverstehen oder aneinander vorbeiarbeiten.

Vertrieb und Produktentwicklung verfolgen oft unterschiedliche Ziele und arbeiten in unterschiedlichen Zeithorizonten. Während der Vertrieb stark auf kurzfristige Abschlüsse, Umsatzziele und konkrete Kundenbeziehungen fokussiert ist, denkt die Produktentwicklung in der Regel langfristiger: in Visionen, Roadmaps und Wiederverwendbarkeit. Diese unterschiedliche Perspektive führt regelmäßig zu Reibung, besonders dann, wenn Zusagen gemacht werden, die nicht zur Produktstrategie passen oder wenn Produktentscheidungen den Vertriebsrealitäten zu wenig Rechnung tragen. Das Spannungsfeld entsteht dabei weniger aus bösem Willen als aus strukturellen und kulturellen Unterschieden innerhalb der Organisation.

Verkaufsstrategie versus Anwendernutzen

Der Vertrieb und das Produktteam haben unterschiedlichen Zugang zu Kunden und Nutzenden. Vertrieb ist nah an den Einkaufsorganisationen und ihren Entscheidern, Produktentwicklung ist näher an den tatsächlichen Anwenderinnen und Anwendern. Gerade im B2B-Umfeld führt diese Trennung dazu, dass wertvolle Informationen nicht zusammenfließen. Der Vertrieb hört Marktargumente, Wettbewerbsvergleiche und Kaufhindernisse. Die Produktentwicklung sieht Nutzungsprobleme, fehlende Wirksamkeit und Schwächen im Erlebnis. Wenn diese Perspektiven getrennt bleiben, entstehen Situationen, in denen sich weder verkaufen lässt noch nachhaltig und strategisch Produkte entwickelt werden können.

Besonders deutlich wird das Spannungsfeld zwischen Vertrieb und Produktentwicklung bei kundenspezifischen Zusagen. Kurzfristige Deals können dazu führen, dass Features versprochen werden, die nicht zur langfristigen Ausrichtung passen. Dadurch entstehen Einzelfalllösungen, die Entwicklungsressourcen binden und selten echten Produktwert erzeugen. Gleichzeitig ist es zu einfach, diese Situation allein dem Vertrieb zuzuschreiben. Verkaufsziele, Incentives und Zeitdruck erzeugen ein Umfeld, in dem solche Entscheidungen logisch erscheinen. Die Produktentwicklung steht hier vor der Aufgabe, Orientierung zu geben und klarzumachen, wofür das Produkt langfristig stehen soll.

Umgekehrt darf die Produktentwicklung nicht erwarten, dass der Vertrieb die Produktstrategie automatisch versteht oder unterstützt. Wenn Vision, Zielgruppen und strategische Leitplanken nicht klar kommuniziert werden, entsteht Raum für Interpretationen. Der Vertrieb füllt diese Lücke dann mit eigenen Prioritäten. Das Spannungsfeld zwischen Vertrieb und Produktentwicklung verschärft sich dadurch weiter, obwohl beide Seiten eigentlich am gleichen Erfolg interessiert sind beziehungsweise sein sollten.

Und gerade in dieser Zusammenarbeit steckt enormes Potenzial (oder wird eben verschenkt). Der Vertrieb liefert wertvolle Einblicke in Marktveränderungen, Wettbewerber und Kaufmotive. Die Produktentwicklung kann diese Impulse nutzen, um bessere Entscheidungen zu treffen und Risiken frühzeitig zu erkennen. Wenn der Vertrieb regelmäßig Einblick in Produktentwicklungen bekommt, neue Funktionen versteht und deren Nutzen einordnen kann, steigt die Qualität der Gespräche mit Kunden deutlich. Beide Seiten gewinnen an Sicherheit und Wirksamkeit.

Zusammenarbeit bewusst gestalten und Vertrauen schaffen

Voraussetzung dafür ist eine bewusste Gestaltung der Zusammenarbeit. Regelmäßiger Austausch, gemeinsame Termine und echte Beziehungspflege schaffen Vertrauen. Es geht darum, die Perspektive des jeweils anderen zu verstehen und ernst zu nehmen. Produktentwicklung profitiert davon, Verkaufsrealitäten kennenzulernen. Vertrieb profitiert davon, die Komplexität von Produktentscheidungen zu verstehen. Diese Nähe reduziert Missverständnisse und verhindert Eskalationen, bevor sie entstehen.

Wenn Vertrieb und Produktentwicklung zumindest teilweise an denselben Kennzahlen gemessen werden, verändert sich das Verhalten spürbar. Kundenzufriedenheit, Nutzung oder langfristiger Erfolg rücken dann stärker in den Fokus. Das Spannungsfeld zwischen Vertrieb und Produktentwicklung verliert an Schärfe, weil beide Seiten auf ein gemeinsames Ergebnis hinarbeiten.

Konflikte zwischen Vertrieb und Produktentwicklung sind kein Zeichen von Dysfunktion, sondern Ausdruck unterschiedlicher Verantwortungen. Entscheidend ist, wie Organisationen damit umgehen. Wer den Dialog fördert, Transparenz schafft und gemeinsame Verantwortung ermöglicht, verwandelt Spannung in produktive Energie und schafft die Grundlage für nachhaltigen Produkterfolg.

Auf diese früheren Episoden wird im Gespräch verwiesen:

Die aktuelle Ausgabe des Podcasts steht auch im Blog der Produktwerker bereit: „Das Spannungsfeld zwischen Vertrieb und Produktentwicklung“.

(map)

In den vergangenen 30 Jahren hat sich eine rege Community im Java-Umfeld gebildet. Ich habe im Laufe des Jahres einige deutschsprachige Vertreter zu ihren Erfahrungen befragt. Die Resonanz war überwältigend. Vielen Dank an alle, die mitgemacht haben. In diesem ersten Teil kommen Alexander Culum (Organisator JUG Frankfurt), Birgit Kratz (Co-Organisatorin der Softwerkskammern Köln und Düsseldorf sowie der SoCraTes), Simon Martinelli (Java Champion, Co-Organisator JUG Schweiz), Dierk König (Java Champion und Professor Fachhochschule Nordwestschweiz) und Christian Stein (Open Source Committer und Mitglied Java Platform Group) zu Wort.

Java prägt viele Entwicklerinnen und Entwickler seit ihren ersten Schritten in der IT – und hat in dieser Zeit Höhen, Tiefen und mehrere Neuerfindungen erlebt. Die folgenden Antworten spiegeln persönliche Anfänge, prägende Erlebnisse, kritische Momente und eine Einordnung von Javas Rolle in der heutigen Softwareentwicklung wider. Abschließend wagen sie einen Blick nach vorn: mit Tipps für die eigene Weiterentwicklung und Erwartungen an Java in den kommenden Jahren.

Wann und mit welcher Version bist du erstmals mit Java in Berührung gekommen?

Alexander Culum: Das war tatsächlich erst im Studium an der Uni Münster; der Professor (Achim Clausing) hatte damals (also tatsächlich schon 1997!) gerade seine komplette Grundstudiumsvorlesung von Ada auf die brandneue objektorientierte Sprache Java umgestellt, im Nachhinein zu diesem Zeitpunkt eine sehr mutige und weitblickende Entscheidung. Auch ein spannender Moment mit Professor Clausing war etwa 1999, als ich mit ihm zusammen saß und er mir Google gezeigt hat, eine neue Suchmaschine aus dem Forschungsbereich. Sie würde dank fortschrittlicher Algorithmen die damaligen Suchmaschinen (Altavista, Yahoo) ablösen. Ich habe das meinen Kommilitonen erzählt und wir haben viel gelacht. Nun ja.

Birgit Kratz: Ich habe dazu mal in meinem CV nachgeschaut. Anfang 2005 wurde dort erstmals ein Projekt erwähnt, bei dem ich mit Java entwickelt habe. Damals war gerade Java 5 herausgekommen. Aber im Projekt wurde noch Java 1.3 verwendet. Davor habe ich ziemlich viel mit C/C++ gearbeitet. Der Umstieg auf Java war für mich zwar nicht „easy peasy“, aber auch keine unüberwindbare Hürde. Nach nunmehr 20 Jahren finde ich Java immer noch spannend und lerne fast täglich neue Aspekte der Sprache kennen.

Simon Martinelli: Im Jahr 2000 bin ich während eines Nachdiplomstudiums zum ersten Mal mit Java in Berührung gekommen – damals war J2SE 1.3 gerade brandneu.

Dierk König: 1995 mit Java 1.0. Cool waren am Anfang Applets und JDBC.

Christian Stein: Mich hat Java seit 1997 gepackt, das muss dann wohl laut der kompletten JDK-Matrix eine der 1.1er-Versionen gewesen sein. Ich hatte bis dahin bereits einige Erfahrungen mit Basic, Pascal, Delphi und C vor allem in der Spieleentwicklung gemacht. Und mir war bereits trotz der damaligen Langsamkeit im direkten Vergleich der Sprachen klar, dass eine virtuelle Maschine in Zukunft besser und stabiler dastehen würde.

Was war rückblickend dein schönstes Erlebnis mit der Sprache oder dem Ökosystem Java?

Alexander Culum: Da gibt es eine Menge. Es war toll zu sehen, dass Java sich immer mehr durchsetzte, auch gegen starke Konkurrenten wie C#. Das Release Java 8 fand ich toll und auch die Tatsache, dass ich die Java User Group Frankfurt 2009 gründen konnte und es immer (manchmal gerade genug) Interessenten gab, sodass die JUGF sich bis heute gehalten hat und wir eine kleine, aber sehr feine Community sind. Generell war Spring, nachdem ich es endlich verstanden hatte (und da reden wir von Jahren), auch immer mein treues, manchmal zu magisches Werkzeug, welches ich sehr zu schätzen gelernt habe. Das Java-Ökosystem wäre heute ohne Spring und die tollen Entwickler dahinter sicher ein anderes.

Birgit Kratz: Am schönsten finde ich immer die Momente, in denen es bei mir in Bezug auf neue Sprachfeatures Klick macht. Es liegt wahrscheinlich daran, dass ich aus meiner Sicht manchmal sehr langsam lerne, fast schon begriffsstutzig bin. Ich hatte das damals beim Umstieg von prozeduraler auf OO-Programmierung. Dann kam Java 5 mit Annotationen. Gefühlt habe ich ewig gebraucht zu begreifen, wozu die da sind und was man damit machen kann. Heute sind Annotationen, speziell bei der Benutzung von Frameworks wie beispielsweise Spring Boot, nicht mehr wegzudenken. Mein nächster großer Kampf war die Einführung von Lambdas und damit der Schritt zu mehr funktionaler Programmierung. Auch da hat es für mich sehr lange gedauert, das zu erfassen und dann auch gezielt einzusetzen. Aber wenn es dann Klick gemacht hat, dann ist das ein sehr schönes Gefühl.

Simon Martinelli: Es gibt unzählige schöne Erlebnisse in meiner Karriere. Eines der spannendsten Projekte mit Java war der erste Online-Ticket-Shop der SBB in den Jahren 2002/2003 – mein erstes Mal als Entwickler in einem richtig großen Team. In jüngerer Zeit denke ich oft an die vielen inspirierenden Begegnungen als Speaker auf Java-Konferenzen und JUG-Meetups. Doch das absolute Highlight war zweifellos meine Ernennung zum Java Champion im Jahr 2024.

Dierk König: Ohne Zweifel die Java Community mit Events wie der JavaOne, als sie das Moscone Center noch alleine ausfüllte, und wir zehntausende Entwickler ansprechen konnten, zum Beispiel bei der Vorstellung von Groovy.

Christian Stein: Nur ein Erlebnis? Na gut, nur ein paar wenige aus so vielen schönen: ein in Java geschriebenes Spiel (iRoll) auf den Markt zu bringen, Teil des JUnit-Teams, der Java User Group Bonn und der Java Platform Group geworden zu sein.

Aber es ist nicht alles golden, was glänzt. Was hat dich negativ beeinflusst bzw. was war ein unschöner Moment im Java-Umfeld?

Alexander Culum: Auch da gibt es eine Menge: Am Anfang bin ich gar nicht mit der Sprache warm geworden (wie gesagt, ich bin mit Java 1.0 gestartet). Schrecklich langsam, fürchterlich overengineered (ja genau: Applets und EJB 1.0!). Nach Borlands Delphi ein wahres Grausen. Dann kam der Kauf von Sun durch Oracle, was in der Community als der letzte Sargnagel wahrgenommen wurde, zu einem Zeitpunkt, als die Konkurrenten sich viel dynamischer und schneller entwickelten. Interessant, dass es vielleicht genau andersherum war. Auch der unbedingte Fokus auf Abwärtskompatibilität wurde nicht immer gut aufgenommen und häufig kritisiert. Ohne diesen Fokus wäre aber Java heute vermutlich nur eine Sprache von vielen im Unternehmensumfeld.

Birgit Kratz: Es liegt wahrscheinlich auch wieder daran, dass sich manche Sachen sehr langsam erfassen und dann aber auch schnell wieder vergessen lassen. Ein ewiger Kampf ist für mich immer das Lesen von Dateiinhalten und die Verarbeitung der darin enthaltenen Daten. Files, InputStreams, OutputStreams, Reader, Writer, … – ein großes Wirrwarr in meinem Kopf. Ähnlich ist es beim Arbeiten mit Datum und Zeit: Date, Time, Instance, Zone, Clock, Temporal, Formatter, … – da hilft nur, jedes Mal aufs Neue, die Doku zu lesen. Leider macht es bei diesen Themen immer nur kurzzeitig Klick bei mir. Und leider schafft es dieses Wissen dann auch nie, sich in meinem Langzeitgedächtnis einzunisten

Simon Martinelli: Schon zu Beginn meiner „Java-Karriere“ hatte ich erste Berührungspunkte mit J2EE-Applikationsservern – eine durchaus spannende Erfahrung. Doch wenn ich an die langen Wartezeiten beim Serverstart zurückdenke, vermisse ich diese Zeiten ganz sicher nicht.

Dierk König: Der Untergang von Sun Microsystems war schmerzhaft.

Christian Stein: Bis heute vermisse ich den UI-Editor von Delphi! Es gab und gibt Nachahmer im Java-Umfeld, aber die reichen nicht an das Original, beziehungsweise an meine Erinnerung daran, heran. Damit verbunden stört es mich, dass das Java Development Kit seit 30 Jahren kein eigenes Build-Tool mitliefert. Zwar geben die einzelnen Tools wie javac, jar, jlink und jpackage einen normierten Ablauf vor, doch fehlt hier eine grundsätzliche Projektstruktur und eben ein Tool, das diese Struktur dann in Aufrufe der anderen Tools umsetzt. Was nicht ist, kann ja noch werden.

Glaubst du, dass Java auch nach 30 Jahren noch relevant ist? Welche Rolle spielt Java deiner Meinung nach in der modernen Softwareentwicklung, insbesondere im Vergleich zu anderen Sprachen und Technologien?

Alexander Culum: Ja, ich denke, Java wird auch in 30 Jahren noch relevant sein. Es wird, trotz unglaublich vieler toller Neuerungen, vermutlich nie die Sprache der „Early Adopter“ und Start-ups sein. Aber viele Rewrites der coolen, schicken JS-serverseitigen Anwendungen werden in Java sein. Und bei der aktuellen Entwicklung sieht man, dass Java mit Leichtigkeit Neuerungen aus anderen Sprachen adaptieren kann, wenn es will, sogar als „schwergewichtige“, statisch typisierte Programmiersprache.

Birgit Kratz: Auf jeden Fall ist Java auch nach 30 Jahren noch relevant. Sehr sogar. Ich denke, Java kommt jetzt gerade in die besten Jahre. Seit der Umstellung auf halbjährliche Releasezyklen gibt es kontinuierlich nützliche Entwicklungen, die einerseits die Sprache modern halten, andererseits aber auch sehr viel Kontinuität garantieren. Sicherlich sieht der Code, den man in Java entwickelt, heute nicht mehr so aus wie vor 30 Jahren. Und das ist auch gut so. Mal ehrlich, wer sieht heute noch so aus wie vor 30 Jahren, und – würde man das wollen? Heutzutage kann man in Java viel prägnanteren Code schreiben, der aber immer noch (oder vielmehr gerade deswegen) sehr gut lesbar ist. Natürlich gibt es andere, neuere Programmiersprachen, mit denen man Aufgaben vielleicht einfacher, kürzer oder „knackiger“ lösen kann. Oft genug sind solche Sprachen aber auch sehr spezialisiert auf die Lösung solcher Aufgaben. Java hingegen bietet ein sehr breites Fundament für die Lösung (fast) aller Probleme.

Simon Martinelli: Java ist nach wie vor äußerst relevant. In meinen aktuellen Softwaremodernisierungsprojekten erlebe ich immer wieder, dass bestehende Systeme einfach analysiert und teilweise sogar wiederverwendet werden können – ein großer Vorteil der statischen Typisierung und der einzigartigen Rückwärtskompatibilität von Java.

Dierk König: Java steht für Verlässlichkeit einer stabilen und weitverbreiteten Ausführungsumgebung.

Christian Stein: Ja, absolut relevant. Gerade weil Java als Plattform sowohl lange dabei und offen ist, weil Java „langweilig“ ist, und auch weil seit Java 9 im Jahr 2017 sich nicht nur durch zwei Releases pro Jahr neu aufgestellt hat: Innovationen erscheinen zuverlässig und planbar! „Lange dabei“: OpenJDK, große Open-Source-Szene, viele Java-User-Gruppen und Konferenzen; „langweilig“: 30 Jahre sind in der IT schon was, bezahlt die Brötchen, andere Sprachen testen Neuerungen aus – Java zieht nach; „Innovationen“: Projekte wie Loom, Valhalla, Babylon und nicht zuletzt Amber schließen Lücken zu anderen Sprachen und gehen manchmal sogar darüber hinaus.