Verwandte Links:
- Wie man einen Qualitätsmanagement-Plan entwickelt
- 10 beste Projektmanagement-Software 2023: Expertenbewertung
- Die besten Tools für das Anforderungsmanagement 2023
- Die besten Bug-Tracking-Tools, um Probleme schneller zu erkennen, zu verfolgen und zu beheben
- Projektmanager oder Projektleiter? (Mit Rebecca Germond)
- The Digital Project Manager’s Podcast – Apple Podcasts
- The QA Lead Podcast
- Projektmanagement-Training
- Treten Sie unserer Mitgliedergemeinschaft bei
- Treten Sie der Digital Project Manager Community bei
Lies das Transkript:
Wir probieren aus, unsere Podcasts mit einem Softwareprogramm zu transkribieren. Bitte entschuldigen Sie eventuelle Tippfehler, da der Bot nicht immer 100% korrekt ist.
Ben Aston:
Es ist wirklich ärgerlich, wenn Dinge nicht funktionieren und wenn wir wochen- oder monatelang an einem Projekt arbeiten, nur um am Ende beim finalen UAT von einem heimtückischen Bug ausgebremst zu werden. Aber warum passiert das eigentlich fast immer – und können wir etwas dagegen tun? Wenn dich Bugs nerven, bleib dran – denn in diesem Podcast besprechen wir, wie wir Dinge wirklich richtig erledigen – mit einem verbesserten Produkt, besseren Prozessen und der Magie eines Qualitätsmanagementplans.
Danke, dass du eingeschaltet hast. Ich bin Ben Aston, Gründer von project managers. Willkommen zum DPM Podcast. Unsere Mission ist es, Projektmanager:innen zum Erfolg zu helfen, damit alle, die Projekte managen, bessere Ergebnisse liefern. Wir möchten, dass du dein Projekt-Know-how auf das nächste Level bringst. Schau auf thedigitalprojectmanager.com vorbei, um mehr über unsere Trainings und Ressourcen zu erfahren, die wir im Rahmen der Mitgliedschaft anbieten. Dieser Podcast wird dir präsentiert von Clarizen, dem führenden Anbieter von Software für Enterprise-Projektmanagement und Portfoliomanagement. Besuche clarizen.com, um mehr zu erfahren.
Heute begrüße ich Michael Luchen. Michael ist einer unserer DPM-Experten vor Ort. Er ist Produktcoach bei Crema, einer Digitalagentur, die Web- und Mobile-Apps für visionäre Unternehmen und Branchenführer entwickelt. Er arbeitet normalerweise remote aus D.C. und hilft Unternehmen, ihre Zusammenarbeit zu verbessern und komplexe Probleme zu analysieren und zu lösen. Er hat bereits mit Adidas, Callaway Golf und anderen gearbeitet und ist Coach bei Crema. Wir sprechen heute mit ihm darüber, wie man einen Qualitätsmanagementplan erstellt. Hallo Michael und willkommen zur Sendung.
Michael Luchen:
Hallo Ben, wie geht's?
Ben Aston:
Gut, danke. Mich interessiert dein Coach-Job, der ja erst seit kurzem deine neue Position ist. Kannst du uns erzählen, was ein Produktcoach bei Crema macht und was diese Rolle für dich bedeutet?
Michael Luchen:
Ja, wie du schon gesagt hast, basiert das auf rund sieben Jahren praktischer Projekt- und Produktmanagement-Erfahrung. Die Rolle selbst befindet sich gerade noch in der Definition. Wir versuchen herauszufinden, was diese Coach-Rolle bei Crema wirklich ist. Aktuell verstehen wir sie einfach als dienende Führungskraft, die Kunden dabei unterstützt, Agile zu verstehen, damit sie bessere Versionen ihrer selbst werden. Meistens übernehme ich die Rolle als Moderator, Produktstratege und Design Thinker, der hilft, Probleme neu zu framen und innovative Ansätze zu identifizieren. Besonders spannend ist aktuell, dass Crema versucht, in einer sehr vollen Branche durch eine einzigartige – eben nicht rein vorschreibende – Coaching-Perspektive hervorzustechen. Es gibt ja so viele vordefinierte Coaching-Prozesse da draußen, aber wir wollen anders sein.
Ben Aston:
Das heißt, du arbeitest mit einem kleinen Team direkt beim Kunden? Ist das eher strategisch, wenn ihr etwa einen Projekt- oder Produktfahrplan definiert?
Michael Luchen:
Ja, das ist-
Ben Aston:
Oder ist es eher umsetzungsorientiert?
Michael Luchen:
… Es geht in beide Richtungen, ist aber insgesamt menschenzentrierter. Was ich an Projektmanagement liebe, ist vor allem, ein gesundes Umfeld für Teams zu schaffen, damit diese ihre beste Arbeit leisten können. Das Ziel ist, den Kunden Werkzeuge und die richtige Denkweise zu vermitteln, damit sie produktive Kulturen und Arbeitsumfelder aufbauen, um beste Resultate zu erzielen.
Ben Aston:
Mit welchen Herausforderungen bist du konfrontiert, wenn du versuchst, die Herangehensweise an die Lieferung beim Kunden zu verändern?
Michael Luchen:
Das sind viele. Vor allem aber, dass Ergebnisse nicht immer sofort eintreten. Ich kann nicht einfach reingehen, sagen „mach das“ und dann läuft alles besser. Es gibt zwar viele X-Frameworks, mit denen angeblich jedes Team Erfolg hat, aber entscheidend ist, den gesamten kulturellen Kontext der Organisation zu verstehen. Es ist wichtig zu erkennen, dass Empowerment von Führungskräften Zeit braucht und dass sie experimentieren dürfen, wie die Learnings im Alltag umgesetzt werden.
Ben Aston:
Absolut. Es gibt keinen einen Prozess, der für jede Organisation perfekt passt. Einfach nur Schritte abarbeiten führt nicht automatisch zum Erfolg. Manche erwarten, dass Agile die Lösung für alles ist. Aber was bedeutet das konkret? Also spannende Aufgabe. Arbeitest du dabei hauptsächlich remote oder vor Ort mit Kunden?
Michael Luchen:
Meistens beides. Zum Zeitpunkt dieser Aufnahme aktuell 100% remote. Beziehungen lassen sich vor Ort gut aufbauen, aber ich habe festgestellt, dass sich effektive Gespräche auch per Zoom oder Loom Screen Shares gestalten lassen. Die Zusammenarbeit funktioniert also auf beiden Wegen wirklich gut.
Ben Aston:
Stichwort Remote-Arbeit – wir sind ja mitten in der Corona-Quarantäne und du hast vor kurzem ein Remote-Workshop für uns abgehalten. Für alle, die es verpasst haben: Was hilft dir, nicht durchzudrehen, wenn du alleine beziehungsweise remote arbeitest? Wie gehst du mit dem Gefühl der Isolation um? Hast du Tricks oder Techniken, um halbwegs normal zu bleiben, wenn du viel aus dem Homeoffice arbeitest?
Michael Luchen:
Ja, sehr gute und aktuelle Frage. Mental erinnere ich mich immer wieder daran, dass ich mit echten Menschen zusammenarbeite. So viele Video-Zoom-Calls wie möglich sind für mich wertvoll. Das klingt simpel, aber gerade, weil Zoom aktuell die meistgeladene Gratis-App ist, hilft es, den Fokus auf Zusammenarbeit zu legen. Man sieht auch nonverbale Kommunikation, die als Projektmanager:in extrem wichtig ist. Dafür nehme ich mir sogar einen zweiten Bildschirm, um alle Gesichter gleichzeitig sehen zu können, selbst wenn ich meinen Screen teile.
Ben Aston:
Guter Tipp. Man läuft sonst Gefahr, in Slack nur noch zu tippen, dabei gehen wesentliche Kommunikationsaspekte verloren. Richtige Zoom-Gespräche machen da einen Unterschied und helfen auch beim Beziehungsaufbau. Also: anziehen und Zoom-Meeting starten, zahlt sich aus!
Du hast vorhin erwähnt, dass du Coaching auch remote anbietest. Kannst du erzälen, an welchen Projekten du aktuell arbeitest?
Michael Luchen:
Momentan wechsele ich komplett von der Produktmanagement- in die Coach-Rolle. Ich beende gerade ein großes, mehrjähriges Enterprise-Projekt – jetzt mit Coaching-Mindset, da gibt es interessante Überschneidungen. Außerdem entwickle ich gemeinsam mit Crema ein differenzierendes Coaching-Angebot, um Kunden mit zurückhaltendem Selbstbewusstsein bestmöglich zu begleiten.
Ben Aston:
Mit welchen Delivery-Herausforderungen bist du konfrontiert, die du im neuen Coaching-Angebot adressieren willst?
Michael Luchen:
Wir vergleichen Coaching gerade mit einem Uni-Semester. Effektives Coaching lebt von Experimentieren – alle sollen aus eigener Erfahrung lernen. Meine Rolle ist die eines Moderators, Mentors und Guides mit Praxiserfahrung. Dazu gehören regelmäßige Check-ins, Retros, Beobachtungen und gemeinsame Notizen – so entsteht über einige Wochen ein echter Mehrwert für Teams.
Ben Aston:
Wie hilfst du großen Organisationen, die richtigen Stellschrauben zu identifizieren, um agiler zu werden? Wie priorisiert ihr gemeinsam Prozesse, die besonders günstig für eine agile Transformation sind?
Michael Luchen:
Zunächst starten wir mit einer Umfrage – nicht nur mit einer einzelnen Kontaktperson, sondern mit mehreren PMs, Entwicklern usw. Die Antworten helfen, wahrgenommene Probleme und Schwerpunkte zu erfassen. Im zweiten Schritt analysieren wir aus unserer Sicht diese Erkenntnisse und machen dann Vorschläge für die wichtigsten zwei oder drei Bereiche mit dem größten Potenzial auf schnelle Verbesserungen.
Ben Aston:
Klingt durchdacht – viel Erfolg dabei!
Michael Luchen:
Danke!
Ben Aston:
Zurück zum Thema Qualitätsmanagement. Falls ihr den zugehörigen Artikel noch nicht gelesen habt – auf thedigitalprojectmanager.com findet ihr eine Anleitung, wie man einen Qualitätsmanagementplan entwickelt. Michael erklärt darin Schritt für Schritt, wie so ein Qualitätsplan erstellt wird. Als Mitglieder findet ihr dazu auch Vorlagen, Geräte- und Anforderungslisten sowie Checklisten zum Thema Qualität.
Wir werden hier nicht den kompletten Plan durchgehen, sondern Michael fasst im Podcast zusammen, wie ein Qualitätsplan für Projekt oder Produkt erstellt werden kann. Zuerst stellt sich aber die Frage, was Qualität eigentlich bedeutet und warum es so schwierig ist, darüber Einigkeit im Team zu erzielen. Was denkst du, warum ist das so schwer greifbar?
Michael Luchen:
Um das Thema Qualität kurz einzuordnen: Für mich gibt es Produktqualität und Prozessqualität. Produktqualität meint das eigentliche, greifbare oder digitale Produkt und alles, was das Design- und Dev-Team geschaffen haben. Prozessqualität hingegen betrifft vor allem uns PMs: Sie beschreibt die Abläufe, mit denen wir das Team dazu befähigen, Ergebnisse zu erreichen – typisches Beispiel ist Velocity als Messgröße.
Dass das gemeinsame Verständnis von Qualität schwer fällt, liegt an der Subjektivität und den Emotionen, die in das Thema einfließen. Unterschiedlichste Stakeholder, Entwickler, Designer usw. haben verschiedene Sichtweisen und Präferenzen. Ein Stakeholder wünscht sich beispielsweise Erwartungen erfüllende Qualität, ein Entwickler legt eher Wert auf perfekten, sauberen Code. Unsere Aufgabe ist es, zwischen diesen Ansprüchen zu moderieren und das Gleichgewicht zu halten.
Ben Aston:
Stichwort Gleichgewicht – gerade im agilen Umfeld definiert man Akzeptanzkriterien für User Stories. Die Definition of Done legt fest, was grundsätzlich für alle Stories gilt. Und hier prallen dann Geschwindigkeit und Qualitätsanspruch schon mal aufeinander: Ist es wichtiger, schnell Wert zu liefern? Muss alles an Akzeptanzkriterien und Definition of Done erfüllt sein – oder kann es auch mal etwas langsamer gehen?
Michael Luchen:
Großartige Frage! Ich sehe Qualitätsfokus überhaupt nicht im Widerspruch zu Agilität – im Gegenteil: Qualitätsfokus ist ein Beschleuniger und Enabler für agile Teams. Definiert zu Beginn gemeinsam, was Qualität bedeutet und was nicht – das gibt dem Team einen klaren Fokus. Auch Akzeptanzkriterien sind dafür ein Werkzeug. Angenommen, bei der Umsetzung einer User Story ändert sich durch eine technische Hürde ein Akzeptanzkriterium, ist das kein Problem, sondern der Einstieg in eine wichtige Diskussion: Das Team passt das Kriterium an, Qualität steht weiter im Fokus – ohne dass man zwangsläufig bremst oder zurückfällt.
Ben Aston:
Es ist also eine Frage der Denkweise: Qualität ist kein Gegenspieler schneller Wertschöpfung, sondern Teil des Wertes selbst. Nur wenn unsere Qualitätskriterien erfüllt sind, liefern wir wirklich Wert. Unsere Definition und die Umsetzung von Qualität ist der Schlüssel zu echtem Mehrwert.
Michael Luchen:
Genau so ist es.
Ben Aston:
Du beschreibst in deinem Ansatz, wie die Verantwortung für Qualität verteilt wird. Gerade größere Agenturen oder Unternehmen haben eigene QA-Teams – dort landet oft alles beim PM oder Dev. Du sprichst dich dafür aus, einen Testingenieur einzusetzen. Warum ist das so wichtig?
Michael Luchen:
Gerade in meinen Anfangsjahren als PM habe ich die QA selbst übernommen. Seit ich mit Testingenieuren zusammenarbeite, ist das ein enormer Unterschied. Der geschulte, kritische Blick und das technische Detailwissen eines Testingenieurs ergänzen das Team enorm. Sie schauen nicht nur aus technischer Sicht ins Detail, sondern haben auch Auswirkungen auf das „große Ganze“ im Blick. Ein Testingenieur verstärkt damit die Leistung und Prüfgenauigkeit von Developer- und Designer-Rollen sowie meiner eigenen Aufgabe.
Ben Aston:
Die Denkweise eines Testingenieurs ist definitiv eine andere als die eines PMs. Während PMs den optimalen Weg testen und ungern Fehler finden wollen, ist der Testingenieur darauf spezialisiert, Schwachstellen aufzudecken und in extensive Testszenarien einzusteigen. Gerade Exploratory Testing bietet eine deutlich höhere Gründlichkeit und hebt die Produktqualität.
Und wenn wir über Zielgeräte sprechen – wie gehst du vor, wenn Kunden möchten, dass ihr Produkt überall läuft, sogar auf alten Browsern und Phones? Wie coachst du Kunden, sich auf die wichtigsten Geräte zu konzentrieren?
Michael Luchen:
Das Target-Device-Exercise ist eines meiner Lieblingsthemen! Es engt den Qualitätsfokus und damit die wesentlichen Ziele für die Nutzer ein. Besonders wenn Kunden am liebsten alle Betriebssysteme und Endgeräte abdecken wollen, hilft die Konzentration auf echte Userbedürfnisse. Natürlich gibt es manchmal legitime Anwendungsfälle, die spezielle Altgeräte erfordern, meistens aber sorgt die Zielgeräteeingrenzung für echten Mehrwert, weil Zeit und Ressourcen fokussiert werden.
Ben Aston:
Mein Tipp an alle, die ein Pflichtenheft oder Akzeptanzkriterien schreiben: Definiert sehr klar, welche Geräte unterstützt werden. Es gibt immer wieder Probleme bei Browserversionen, die sich im Lauf der Entwicklung ändern – das ist niemandes „Schuld“, aber es muss gut abgestimmt werden. Wer seinen Zielgeräte-Fokus sauber setzt, spart sich später viel Ärger.
Bleiben wir beim Testing: Testgetriebene Entwicklung versus adhoc dokumentiertes Testen – wie seid ihr bei Crema aufgestellt?
Michael Luchen:
Bei uns gilt: Qualität ist Sache des ganzen Teams. Unsere Entwickler setzen auf Test Driven Development und schreiben gleich Integrations- und Komponententests mit. So bleibt dem Testingenieur Raum für manuelle Tests, Automatisierung, Exploratory Testing und Edge Cases.
Ben Aston:
Alle sind verantwortlich – aber dann ist oft am Ende doch keiner verantwortlich. Wie förderst du praktisches Qualitätsdenken im Team? Wie sieht das aus?
Michael Luchen:
Das Fundament ist Aufklärung und ständige Diskussion (z. B. in Slack-Channels) über den Qualitätsbegriff für Projekte. PMs können Prozesse einführen, die regelmäßige Qualitätssicherungen ermöglichen: Wir nutzen JIRA-Workflows mit klaren Checks z. B. für Code Reviews zwischen „in progress“, „staging“ und QA. So erhält jede Aufgabe ausreichend Zeit und Coverage für die Prüfung.
Ben Aston:
Qualität muss Teil des Gesamtprozesses sein, nicht bloß ein Schritt am Ende. Auch das Einbinden von Unit-Tests direkt im Code ist wichtig. Aber automatisiertes Testen aufzusetzen kostet Zeit: Wann ist es sinnvoll, wann wird besser manuell getestet?
Michael Luchen:
Manuelles Testen ist der „low hanging fruit“, besonders bei komplexer User Interaktion (wie Drag & Drop), die nur schwer zu automatisieren ist. Für regelmäßig wiederkehrende, umfangreiche Formular-Eingaben lohnt sich aber Automatisierung – am besten, wenn der Testingenieur die Autofill-Kriterien gleich mitentwickelt.
Ben Aston:
Euer Qualitätsmanagement-Ansatz ermöglicht also einen organischen, projektspezifischen Aufbau des Testens und der Qualitätskriterien. Wie findest du dabei das richtige Maß?
Michael Luchen:
Ich genieße es, organisch vorzugehen – ähnlich wie bei der Velocity-Anpassung nach mehreren Sprints. Der Artikel zum Qualitätsmanagementplan gibt ein solides Fundament, aber alles ist letztlich nur Annahme zu Projektbeginn. Korrekturen und Anpassungen in den ersten Sprints sind normal; vielleicht zeigt das Nutzerfeedback, dass manche Zielgeräte wegfallen können, und die gewonnene Zeit investieren wir dann in andere Bereiche. Offenheit für Veränderung und die Erfahrungswerte aus jedem Projekt sind dabei entscheidend für das nächste.
Ben Aston:
Gesunder Menschenverstand ist in puncto Qualität entscheidend. Ein zu rigides Qualitätsmanagement läuft schnell Gefahr, reines Formalismus-Dokument zu werden. Die Balance: einerseits klare Checks und Prozesse, andererseits Flexibilität, etwa für Exploratory Testing – damit wir iterativ Wert schaffen und die Produktqualität Runde für Runde wächst.
Michael Luchen:
Absolut!
Ben Aston:
Wir haben kürzlich einen Podcast auf unserer Schwestersite gestartet, „QA Lead“. Wenn ihr mit QAs zusammenarbeitet, empfehlt ihnen qalead.com. Lest auch den Post mit Vorlagen, Beispielen und Mitgliederbereichen.
Wenn ihr noch nie mit einem Qualitätsmanagementplan gearbeitet habt, schaut gern rein – das hilft euch, eure Prozesse, Projekte und Produkte neu zu planen und echten Mehrwert durch bessere Qualität zu liefern.
Ich fand vor allem den Gedanken spannend, Qualitätsmanagement als Haltung im ganzen Unternehmen zu etablieren – unabhängig davon, ob es dedizierte Testingenieure gibt oder nicht. Qualität ist nicht „Ist es kaputt?“ – sondern: Wie arbeiten wir, wie verbessern wir uns permanent? Das iterative Mindset ist der Schlüssel. Danke Michael für deine Insights!
Michael Luchen:
Danke dir.
Ben Aston:
Was sind eure Tipps, Tricks und Learnings, wie man Projekte oder Produkte in hoher Qualität liefert? Teilt eure Erfahrungen und Fragestellungen gern in den Kommentaren unten.
Wenn ihr euch weiterentwickeln wollt, werdet Mitglied in unserer DPM-Community! Unter thedigitalprojectmanager.com/membership gibt’s Zugriff auf unser Slack-Team, Vorlagen, Workshops, Office Hours, eBooks und mehr. Wenn euch die Folge gefallen hat, abonniert uns! Mehr auf thedigitalprojectmanager.com – bis zum nächsten Mal, danke fürs Zuhören!
