Der Produktentwickler - Podcast

ITEM-Planung„Der Plan zeigt die Route, nicht die Reise."🗺️ Worum geht es in dieser Episode?In dieser Episode tauchen wir eine Ebene tiefer in die Welt der Work-ITEMs ein. Während der Überblick über alle ITEMs Orientierung, Priorisierung und Verständnis von Abhängigkeiten ermöglicht, brauchen wir genau das auch innerhalb der einzelnen ITEMs. Wir schauen uns an, wie ITEMs geplant werden sollten — und warum weder zu viel noch zu wenig Planung zum Ziel führt.🔑 KernthemenPlanung — ja oder nein? Ein höchst kontroverses Thema: Manche treiben Planung ins Extrem, andere lehnen sie als unnötige Bürokratie ab. Die Wahrheit liegt — wie so oft — in der Mitte.Was Helmuth von Moltke uns lehrt Der preußische Generalfeldmarschall und Erfinder der Auftragstaktik liefert die perfekte Denkgrundlage. Sein berühmtes Zitat: „Kein Operationsplan reicht mit einiger Sicherheit über das erste Zusammentreffen mit der feindlichen Hauptmacht hinaus." — Keine Absage an die Planung, sondern ein Plädoyer für ihre richtige Anwendung.Aufmarsch vs. Auftragstaktik Moltke unterscheidet zwei Phasen: die präzise Vorbereitungsplanung (Aufmarsch) und die flexible Ausführung im Angesicht der Realität (Auftragstaktik). Beides übertragen wir auf modernes Projektmanagement.Die eigentliche Funktion von Planung Planung ist Vorbereitung, nicht Kontrolle. Sie liefert den theoretisch besten Ansatz und schafft die Voraussetzungen für erfolgreiche Ausführung. Je größer das ITEM, desto mehr Planung ist erforderlich.Meilensteine statt Aktivitäten Ein Plan beschreibt das Was und das Wann, nicht das Wie. Termine und Ziele bleiben stabil; der Weg bleibt flexibel.📦 ITEM-Typen & ihre PlanungslogikITEM-Typ:ProjekteKlare Fristen & Ziele, Fokus auf Meilensteine statt AktivitätenTechnologieentwicklungGrößere Volatilität einplanen, kein lückenloses Anschluss-ProjektFeatures & FunktionenSprint-Planung + DCVI-Meilensteine (Definition, Erstellung, Validierung, Implementierung)KundensegmenteProjektcharakter, negatives Ergebnis muss einkalkuliert seinProblemlösungInkrementell starten, Meilensteine planbar (Ursachenanalyse → Maßnahmen → Wirksamkeit)ProzessentwicklungAnalog zu Projekten, auch ohne formale Struktur mindestens mit PlanMitarbeiterentwicklungQuartalsziele im Fokus, Langfristplan nur bei klar definierter Zielrolle📌 Die 5 PlanungsregelnPlane, um Erkenntnisse zu gewinnen – der Planungsprozess schafft das vollständige BildSchaffe die Voraussetzungen – erst starten, wenn die Grundlagen bereit sindHalte die Richtung – Plan als Orientierung, nicht als starre EinschränkungVertraue den Handelnden – das Wie liegt bei denen, die die Realität sehenBewertet die Lage – Fortschritt kontinuierlich mit der Realität abgleichen💡 Das nimmst du heute mitPlanung ist notwendig — immer.Sie darf weder zu detailliert noch zu vage sein.Die richtige Balance ist entscheidend.Die Art der Planung hängt stark vom ITEM-Typ ab und muss auf den Kontext zugeschnitten sein. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

Die Komplexität im Tagesgeschäft beherrschenWie man den Überblick behält und das richtige Timing trifft.In dieser Folge zeige ich dir, wie du die wachsende Komplexität im Tagesgeschäft besser in den Griff bekommst – und gleichzeitig deinen Projekten mehr Raum gibst. Dafür führe ich einen neuen Begriff ein: das ITEM – ein Sammelbegriff für alles, was erledigt werden muss.Als Orientierungshilfe dient das Granatapfelbaum-Modell: Alles, was auf deinem Schreibtisch liegt, entspricht einem Granatapfel an einem Baum – unterschiedlich groß, unterschiedlich reif.Die wichtigsten Themen der Episode:Warum klassisches, agiles und hybrides Projektmanagement allein nicht ausreicht – und warum das wahre Leben sich nicht in Schubladen pressen lässtWas ein ITEM ist und welche Kategorien darunter fallen: Projekte, Features & Funktionen, Technologieentwicklung, Kundenapplikationen, Probleme, Prozesse und MitarbeiterentwicklungWarum ein gemeinsames, großes Backlog für alle ITEMs mehr Transparenz schafft und bessere Priorisierung ermöglichtWie ITEM-Management das klassische Multiprojektmanagement erweitertWarum Daten der Treibstoff für Effizienz sind – und wie eine solide Datenbasis die Voraussetzung für den sinnvollen Einsatz von KI istDie zentrale Idee dieser Episode:Lass uns hybrides Projektmanagement nicht nur auf Projekte beschränken, sondern alles, was erledigt werden muss, in ein gemeinsames großes Backlog schreiben!Ausblick:In den nächsten Episoden zeige ich dir, wie das ITEM-Management konkret operativ umgesetzt werden kann – inklusive eines Einblicks in meine eigene Datenbank.Mach mit!Welche ITEM-Kategorien fehlen deiner Meinung nach? Schreib es in die Kommentare!Teile deine Meinung, schick mir eine Nachricht oder chatte mit mir auf Substack.Wenn dir der Podcast gefällt – empfiehl ihn weiter und abonniere ihn, damit du keine Folge verpasst! Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

„Wenn die Software den Mehrwert des Produktes definiert" Worum geht es in dieser Episode?Die Maschinen lernen denken – und sie werden immer besser darin. Aber was bedeutet das konkret für Produkte, ihre Entwicklung und alle, die daran beteiligt sind?In dieser Episode beleuchte ich den großen Wandel, den mechatronische Produkte gerade durchlaufen, von der dominanten Mechanik, hin zu Software als zentralem Werttreiber. Und ich zeige, warum das nicht das Ende klassischer Entwicklungsmethoden bedeutet – sondern den Beginn einer neuen, parallelen Welt.Das lernst du in dieser EpisodeMuskeln vs. Gehirn – Wie die Mechanisierung körperlicher Arbeit die Welt verändert hat und warum die Elektronisierung kognitiver Funktionen der nächste große Sprung istWarum Mechanik an eine Sättigung stößt – Physikalische Gesetze setzen klare Grenzen; Software hingegen steht noch ganz am AnfangDas Nervensystem der Maschine – Wie Sensoren, Mikroelektronik und Software Maschinen ein „Gehirn" geben und was das für die Systemarchitektur bedeutetSoftware Defined Vehicle & Co. – Was hinter diesem Begriff steckt und warum der Trend weit über die Automobilindustrie hinausgehtParallele Entwicklungswelten – Warum es künftig sowohl hybride als auch rein agile Prozesse geben wird – und warum der klassische Ansatz nicht ausstirbtIndustrie 4.0 und Maschinenkommunikation – Was passiert, wenn Maschinen in Millisekunden miteinander reden, Daten teilen und Entscheidungen synchronisierenDie 4 wichtigsten Erkenntnisse auf einen BlickStark physische Produkte → klassischer Entwicklungsprozess bleibt das Mittel der WahlMechatronische Produkte (die Mehrheit) → hybride Vorgehensweise erforderlichSoftware Application Layer → wird zunehmend entkoppelt und agil entwickeltVernetzte Systeme → Systems Engineering ist unabdingbarErwähnte Konzepte & BegriffeSystems EngineeringSoftware Defined Vehicle (SDV)Industrie 4.0 / Over-the-Air-UpdatesHybride vs. agile EntwicklungsprozesseZentralisierte Elektronik- und Softwarearchitektur Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

Braucht es noch Projekte – oder sind Projekte ein alter Zopf von gestern? In dieser Episode geht Uwe Mierisch dem großen Dilemma der Mechatronikentwicklung auf den Grund: klassisches Projektmanagement auf der einen Seite, agile Methoden auf der anderen. Anhand einer typischen – und schmerzhaft vertrauten – Geschichte aus der Fahrzeugentwicklung zeigt er, warum weder der rein klassische noch der rein agile Ansatz für mechatronische Produkte funktioniert, und was stattdessen die Lösung ist.Das lernst du in dieser Episode:Warum mechatronische Projekte immer wieder in die gleiche Stressfalle tappenWas ein mechatronisches Produkt grundlegend von rein mechanischen oder rein digitalen Produkten unterscheidetWarum klassisches Projektmanagement in der Mechatronik strukturell scheitertWarum rein agiles Arbeiten ebenfalls keine Lösung ist – und wo es seine Grenzen hatWelche zwei konkreten Merkmale der Hardwareentwicklung ein rein agiles Vorgehen verhindernWie das hybride Modell des New PDP funktioniert und aus welchen vier Ebenen es bestehtWarum die Umsetzung des New PDP eine klare Führungsaufgabe istInhalt der EpisodeDas typische Szenario (ca. Min. 0–5) Uwe schildert den klassischen Ablauf eines Fahrzeugprojekts: monatelange Verhandlungen, ein zusammengestauchter Zeitplan, teure Hardware-Prototypen – und dann der Schock, wenn das Fahrzeug nicht fährt, weil die Software nicht fertig ist. Die darauffolgende Heldenphase kurz vor dem Serienanlauf, in der alle zusammenrücken und die Krise mit letzter Kraft abwenden, ist symptomatisch für eine strukturell fehlerhafte Vorgehensweise.Was ist ein mechatronisches Produkt? (ca. Min. 5–8) Hardware und Software sind untrennbar miteinander verbunden. Erst gemeinsam liefern sie den Kundennutzen. Am Beispiel des modernen LKW – mit Systemen zur Verbrauchsoptimierung, Fahrerassistenz und Flottenmanagement – wird deutlich, warum solche Produkte ohne Software schlicht nicht mehr denkbar sind.Warum klassisches Projektmanagement nicht ausreicht (ca. Min. 8–11) Das sequenzielle Aneinanderreihen von Hardware- und Softwareentwicklungsphasen führt zu Projektzeitplänen, die wirtschaftlich unrealistisch sind. Die Folge: Pläne werden gestaucht, was kein echtes Projektmanagement mehr ist – und dessen Erfolg von Zufall abhängt.Warum rein agiles Vorgehen ebenfalls scheitert (ca. Min. 11–14) Zwei grundlegende Merkmale der Hardwareentwicklung verhindern ein rein agiles Arbeiten:Hardware ist nur eingeschränkt inkrementell entwickelbar – ein halbfertiges Produkt kann nicht an Kunden übergeben werden.Hardwareentwicklung braucht langfristige Planung – Fertigungseinrichtungen, Werkzeuge, Validierungsumgebungen (Sommer/Winter-Tests, geteilte Ressourcen) müssen weit im Voraus koordiniert werden.Die Lösung: Der New PDP (ca. Min. 14–17) Das hybride Modell besteht aus vier Ebenen:Programmmanagement – alle Produktveränderungen werden aufeinander abgestimmt und in einen gemeinsamen Rhythmus gebrachtProjektebene – der essentielle Ablauf vom Start bis zur Kundenauslieferung mit klaren MeilensteinenDrum Beat – ein kurzzyklischer Rhythmus für Detailplanung, Ergebnisreviews und die Reaktion auf UnvorhergesehenesWochensprint-Umsetzung – Teams erledigen Aufgaben, das Management steuert RessourcenDer entscheidende Punkt: Führung ist gefragt (ca. Min. 17–18) Der New PDP funktioniert nur, wenn Hardware- und Softwareentwickler gemeinsam und konsequent den gesamten Prozess leben. Das ist eine Umgewöhnung für beide Seiten – und damit eine klare Führungsaufgabe. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

Warum Softwareentwicklung anders ticktIn dieser Folge wagt sich Uwe Mierisch auf „dünnes Eis“ und blickt zurück auf seine Anfänge mit Fortran und Lochstreifen, um eine Brücke zur modernen, agilen Softwarewelt zu schlagen. Warum scheitern klassische Projektmanagement-Methoden oft an Code, während sie bei Hardware funktionieren?Die Schwerpunkte dieser Episode:Die Komplexitäts-Falle: Warum volatile Ziele, die „Blackbox“ moderner Microservices und tückische Heisenbugs (Race Conditions) die Planung erschweren.Vorteil Software: Wie inkrementelles Arbeiten (MVP), die Abwesenheit von physischen Verschleiß und die universelle Einsetzbarkeit von Entwicklern die Time-to-Market verkürzen.Projekt vs. Agile: Ein direkter Kriterien-Vergleich, der zeigt, warum Agilität bei Software „wie die Faust aufs Auge“ passt – und wo bei großen Systemen (Scaled Agile) das klassische Management doch wieder eine Rolle spielt. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

Die klassische Vorgehensweise im Projektmanagement entstammt den Eigenarten und Erfordernissen bei der Entwicklung von Hardwareprodukten. Darum macht es nach wie vor Sinn, diese Vorgehensweise anzuwenden, wenn die Hardware den Schwerpunkt einer Produktentwicklung bildet. Allerdings bieten agile Projektmanagementelemente die Möglichkeit die Schwächen in der traditionellen Vorgehensweise abzustellen und damit die Entwicklung schneller und effizienter zu machen. Diese Form des hybriden Projektmanagements wird in der Zukunft bei Hardwareentwicklungsprojekten den Standard bilden. Hören sie in dieser Episode warum. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

Transformation oder Untergang: Produktentwicklung neu gedachtDie Welt wartet nicht darauf, dass wir unsere alten Arbeitsweisen bequem optimieren. Während neue Akteure aus Asien den Markt radikal verändern, müssen wir in Europa und Nordamerika unsere Wettbewerbsfähigkeit durch drastische Veränderungen sichern, um nicht "die Entwicklungsländer von morgen" zu werden.In dieser Episode stelle ich den NewPDP (New Product Development Process) vor – ein Framework, das auf aktuellen Marktstudien und 30 Jahren Praxiserfahrung basiert, um Entwicklungsprozesse auf Geschwindigkeit, Effizienz und Zukunftssicherheit zu trimmen.Die Kerninhalte dieser Folge:Der NewPDP: Warum wir keine schrittweise Evolution, sondern einen radikal neuen Prozess brauchen.4 Säulen der Transformation: *Zusammenarbeit (Drum Beat): Wie wir durch Synchronisation einen maximalen „Wirkungsgrad“ menschlicher Energie erreichen.Prozesse (Evolving Standard Procedures): Warum konsequente Standardisierung die Basis für Geschwindigkeit ist.Technologie (Proaktive Technologiereifung): Der intelligente Umgang mit KI und ElektrifizierungWerkzeuge (Hardware Light Development): Die gigantischen Effizienzsprünge durch virtuelle Prototypen und das Metaverse.3 Katalysatoren: Warum neue Organisationsformen, moderne Führung und Software-zentrierte Produktarchitekturen unverzichtbar sind.Kapitelmarken (Time-Stamps):00:26 – Die industrielle Vorherrschaft des Westens bröckelt.01:53 – Die Entstehung des NewPDP aus der Praxis.04:48 – Säule 1: Zusammenarbeit & der „Drum Beat“.06:39 – Säule 2: Prozesse & Standardisierung08:38 – Säule 3: Proaktive Technologiereifung.11:19 – Säule 4: Hardware Light Development.13:08 – Die Katalysatoren: Organisation, Führung und Architektur17:34 – Ausblick und Einladung zum Austausch.Diskutieren Sie mit!Der NewPDP ist ein lebendes Framework. Ich lade Sie herzlich ein, Ihre Perspektiven, kritischen Meinungen oder Fragen in den Kommentaren auf Substack zu teilen oder mir eine persönliche Nachricht zu schicken.Abonnieren Sie diesen Podcast, um keine der kommenden Detail-Folgen zu den einzelnen Transformationsfeldern zu verpassen. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe