Ein Gespräch mit Product Manager Stefan Dinh über agile Variablen, die Illusion von IT-Wissen im Management und das teure Erwachen nach dem „Hudeln“.
Die Software-Landschaft ist schnelllebig, und der Druck auf Go-Live-Termine ist hoch. Doch was passiert mit der Produktqualität, wenn Fristen über alles gestellt werden? Und warum wird Barrierefreiheit oft fälschlicherweise als „lästiges Zusatzfeature“ verbucht, obwohl sie eigentlich das Fundament sauberer Softwarearchitektur ist? Wir haben uns mit Stefan zusammengesetzt. Mit langjähriger Erfahrung als Product Owner und Product Manager bringt er einen scharfen Blick auf die Realität agiler Projekte mit – und räumt dabei mit einigen Mythen über IT-Wissen und Team-Verantwortlichkeiten auf.
Julia Undeutsch
Stefan, schön dass du dir die Zeit nimmst. Du hast ja in den letzten Jahren als Product Owner und Product Manager so einige Phasen vom Kick-off bis zum Go-Live miterlebt. Wenn du mal ganz ehrlich Bilanz ziehst: Wie viele deiner Projekte sind eigentlich wirklich punktgenau im Zeitplan gelandet? Was ist da der Realitätscheck?
Stefan Dinh
Da müssen wir direkt am Anfang kurz den Unterschied zwischen Produkt und Projekt klären. Ein Produkt hat ja kein fixes Ende, ein Projekt schon. Aber wenn wir Feature-Releases als eigene kleine Projekte betrachten, ist die Antwort zweigeteilt.
Bei kommerziell gebundenen Projekten war ein verspäteter Abschluss schlicht keine Option – das musste funktionieren. Der Preis dafür war dann eben manchmal eine Reduktion der Qualität oder des Scopes. Bei reinen Feature-Projekten sah das anders aus: Je komplexer das Feature, desto wahrscheinlicher die Verzögerung. Grob geschätzt wurde da jedes dritte Feature nach dem geplanten Datum released.
Julia Undeutsch
Woran liegt das? Hand aufs Herz: Ist das ein Planungsfehler, oder brennt einfach spontan die Hütte, weil Mitarbeiter ausfallen?
Stefan Dinh
Ich arbeite grundsätzlich agil, und für mich persönlich haben sich in der Praxis drei Grundvariablen herauskristallisiert, um die sich im Kern alles dreht: das Release-Datum, der Scope und die Entwicklungskraft – also die Teamgröße, die Skills und die Seniorität der Leute.
Meistens sind eine oder zwei dieser Variablen fix. Die dritte muss dann flexibel bleiben. Wenn das Team und der Scope feststehen, muss sich das Datum eben verschieben.
Dazu kommt, dass technische Komplexität oder Altlasten – also Tech Debt – im Vorfeld oft nicht sichtbar sind. Das zieht die Entwicklung dann unbarmherzig in die Länge.
Julia Undeutsch
Du hast Wirtschaftsinformatik studiert und bringst einen IT-Background mit. Ich persönlich halte das für ein Riesenvorteil im Projektmanagement, um Probleme überhaupt zu verstehen. Siehst du das auch so?
Stefan Dinh
Spannenderweise nein. Ich glaube sogar, es kann von Nachteil sein, wenn ein PM zu technisch denkt oder selbst aus der Entwicklung kommt. Solche Manager verfangen sich oft in internen technischen Details, anstatt mit den Kunden zu sprechen und den Endverbraucher wirklich zu verstehen.
Heute kann man Code im Zweifel per KI analysieren lassen. Ein guter PM muss vor allem die Probleme der Kunden verstehen. Branchenwissen bringt da am Ende viel mehr als tiefes IT-Wissen.
Julia Undeutsch
Aber wie sieht es in den Teams aus? Wenn die Entwickler, Designer und Tester ihren Techstack nicht in- und auswendig kennen, leidet doch die Timeline, oder?
Stefan Dinh
Das ist extrem unterschiedlich und hängt stark von der Unternehmenskultur ab. Manche Start-ups mischen bewusst Seniors und Juniors, um die Leute aufzubauen. Andere haben weder Zeit noch Geld dafür – das leisten sich dann eher Corporates. Die meisten Entwickler kannten ihren Techstack schon gut, weil beim Recruiting sehr gezielt darauf geachtet wurde.
Aber ja: Wenn die Entwickler die Architektur im Vorfeld besser kennen und das cross-funktionale Zusammenspiel zwischen Backend, Frontend und Mobile-Teams besser abgestimmt ist, spart das locker einige Tage ein.
Julia Undeutsch
Schaust du dir eigentlich selbst mal den Code an? Ich erlebe im Alltag oft, dass grundlegende Dinge wie HTML und CSS im Frontend mangelhaft umgesetzt werden – also quasi das Handwerkszeug der Entwickler.
Stefan Dinh
Nein, in den Code schaue ich nicht rein. Das liegt ganz klar außerhalb meines Verantwortungsbereichs, wenn man nach dem RACI-Modell geht. Ich habe aber das Glück gehabt, mit Designern zu arbeiten, die im Bereich HTML und CSS extrem stark waren und dort quasi die Qualitätskontrolle übernommen haben.
Ansonsten vertraue ich da voll und ganz den Dev Leads und Architekten. Es ist ihre Verantwortung, für sauberen Code zu sorgen, und das erwarte ich auch.
Julia Undeutsch
Du sagst, das ist Sache der Dev Leads. Hast du als PM denn gar kein Mitspracherecht bei der Teamzusammenstellung? Da könnte man ja theoretisch schon Aussieben und nur die Motivierten mitnehmen.
Stefan Dinh
Das lag bei keiner meiner Stationen in meiner Hand, und das ist auch gut so. Die Dev Leads kennen ihre Leute am besten. Zum Thema Motivation habe ich ohnehin eine klare Meinung: Wenn jemand nicht die intrinsische Motivation mitbringt, gute Arbeit zu leisten, dann sitzt er im falschen Unternehmen – oder zumindest im falschen Team.
Julia Undeutsch
Ich erlebe leider oft diese „Ach, passt schon“- oder „Bei mir funktioniert’s“-Mentalität. Da wird Code gemerged, bei dem man am liebsten weinen würde. Wie nimmst du das wahr?
Stefan Dinh
Das gibt es, absolut. Für mich ist das aber ein reines Kulturproblem. Wenn diese Haltung von oben vorgelebt wird und Entwickler darauf vertrauen, dass die QA-Abteilung die Fehler schon irgendwie ausbügelt, leidet die Qualität massiv. Die Grundhaltung muss sein: Ich bin stolz auf meinen Code und nicht nur froh, dass der Task auf „Done“ steht. QA sollte für manuelle Edge Cases und Regressionstests da sein, nicht zum Hinterherräumen.
Julia Undeutsch
In Österreich sagt man so schön: „Vom Hudeln kommen die Kinder“. Es wirkt anfangs immer so, als würde Code-Qualität Zeit fressen. Am Ende kostet das spätere Bugfixing aber viel mehr Geld. Teilst du diese Erfahrung?
Stefan Dinh
Zu einhundert Prozent. Ich habe ganz früh in meiner Karriere selbst im QA-Bereich gearbeitet. Da lernt man schnell: Je später ein Bug gefunden wird, desto teurer wird er. Findet der Entwickler ihn direkt beim Schreiben, kostet das fast nichts.
Man darf Qualitätssicherung auch nicht als den nächsten Schritt im Wasserfallmodell sehen. QA muss parallel laufen. Wenn Code früh und oft auf Dev-Server gepusht wird, kann man Fehler sofort abfangen. Das erfordert aber ein reifes, eingespieltes Team.
Julia Undeutsch
Ich hatte mal ein Projekt, da gab es monatelang CSS-Probleme. Am Ende kam raus: Niemand hatte das fertige Seitentemplate aus dem Designsystem genutzt, weil die Kommunikation komplett schiefgelaufen war. Ich habe das dann in drei Tagen neu gebaut und die Bugs waren weg. Erlebt man sowas auch als Product Manager?
Stefan Dinh
So extrem habe ich das zum Glück noch nicht erlebt. Ich lege aber von Tag eins an enormen Wert auf Kommunikation und eine saubere Planungsphase, noch bevor die erste Zeile Code überhaupt geschrieben wird. Damit lassen sich solche Fauxpas eigentlich fast immer vermeiden.
Julia Undeutsch
Jetzt kommen wir zu einem Punkt, den ich besonders wichtig finde: Barrierefreiheit. Für viele Entscheider ist das immer noch ein Unwort. Da heißt es dann: „Das ist Extra-Aufwand für die zwei, drei Behinderten da draußen.“
Aber ist das, worüber wir gerade gesprochen haben – schlechter Code, mangelndes Verständnis für die eigenen Tools – nicht der wahre Grund, warum Barrieren überhaupt erst entstehen? Da muss man das Wort Barrierefreiheit doch eigentlich gar nicht erst in den Mund nehmen.
Stefan Dinh
Ich weiß genau, was du meinst. Viele hören „Barrierefreiheit“ und sehen sofort zusätzlichen Scope, der das Projekt sprengt. Von der Führungsebene kommt da oft wenig Verständnis, weil dort primär auf die nackten Zahlen geschaut wird.
Aber die Realität ist: Wenn ein Framework einmal sauber etabliert und barrierefrei implementiert ist, ist der laufende Zusatzaufwand überhaupt nicht mehr signifikant. Und der Mehrwert ist riesig – sowohl für bestehende als auch für neue Kundengruppen.
Julia Undeutsch
Auf der anderen Seite muss man die Entwickler aber auch in Schutz nehmen. Oft wollen sie gute Arbeit leisten, bekommen aber vom PO oder PM die Pistole auf die Brust gesetzt, weil ein Feature „unbedingt heute noch“ raus muss. Woher kommt dieses kurzfristige Denken? Ist das ein österreichisches Mentalitätsproblem?
Stefan Dinh
Nein, das ist kein länderspezifisches Problem, sondern eine klassische Projektmanagement-Krankheit namens Stakeholder-Management. Stakeholder kommen mit unzähligen Wünschen und harten Fristen um die Ecke, und da muss man sich als PM manchmal verbiegen.
Da sind wir wieder bei den drei Variablen: Wenn das Datum und die Ressourcen fixiert sind, leidet zwangsläufig der Scope. Und in der Praxis bedeutet das dann leider viel zu oft: Abstriche bei der Qualität und Bugs, die man zwei Tage später frustriert wieder auf der Liste hat.
Julia Undeutsch
Ein perfektes Schlusswort. Stefan, vielen lieben Dank für diese ehrlichen Einblicke und deine Perspektive!