ZA071 - Lean Systems Engineering - Stand der Dinge
05.12.2013
28 Minuten
Zusammenfassung
Heute geht es um Lean System Engineering und meinen aktuellen Stand meines „kleinen Forschungsprojekts“. Ich war am 04.12. als Speaker auf dem ESE 2013 und ihr hört in dieser Episode den Live-Mitschnitt von meinem Vortrag.
Die Themen der Episode:
- Den Kundennutzen des Systems kennen
- Eine klare Systemabgrenzung schaffen
- Eine sinnvolle Strategie schaffen
- Schnelles Lernen ermöglichen
- Engpässe entfernen
- Führung leben
- Respektvolle Zusammenarbeit
- Eine effektive Umgebung schaffen
Meine Folien zu dem Vortrag:
Hinweise in der Episode:
- Das Systems Engineering Barcamp 2014 in Berlin
- Das Lean Systems Engineering Seminar
Subscription link
Wenn Euch der Podcast gefällt, abonniert Ihn und erhaltet zukünftig kostenlos alle neuen Episoden direkt auf Eurer Smartphone:
Euer Feedback
Wenn Ihr eine Idee habt für den Podcast oder eine Frage für eine der zukünftigen Episoden, schreibt mir eine Mail an feedback@zukunftsarchitekten-podcast.de
Wenn Euch die Episode gefallen hat, bitte bewertet sie bei iTunes und schreibt eine ehrliche Meinung. Das würde sehr helfen, die Commuity zu erweitern! Danke.
Frage: Wie ist Eure Erfahrung? Welche Fähigkeiten sind aus eurer Sicht wichtig?
HAllo,
tolle Sache, die Idee von Systems Engineering!
Meine Einstellung seit Jahr(zehnten), dass man immer das Ganze sehen soll/muß, damit die einzelnen MAs nicht aneinander vorbei arbeiten.
In Deutschland ist die Einstellung ja noch sehr verbreitet:
Der andere Aufgabenbereich geht mich nichts an, auch wenn ich dort mit meiner Vorgehensweise (Mehr-)Arbeit schaffen könnte.
Habe SW schon entwickelt, als man das Glück hatte vom ersten Gespräch an beim Kunden dabei zu sein und Lasten- / Pflichtenheft etc. mit ihm in (auch ungeplanten) mehreren Gesprächen mit den jeweilig besten Ansprechpartnern unterschiedlicher Abteilungen/Funktionen wirklich nutzbringende Infos für die Vorgaben zu erarbeiten.
Danach mußte dann auch nicht viel umgeworfen werden. Fragen auf die zukünftige Ausrichtung wurden ja schon vorab gestellt und ggf. die SW darauf vorbereitet :-).
Auch Pflichtenhefte kann man so formulieren, dass sie zum Einen die Anforderungen wiederspiegeln und gleichzeitig so aufgebaut sind, dass atomare Testfälle sich daraus (größtenteils) automatisch ableiten lassen.
Hallo Torsten,
ja, ich denke wir müssen hier oft noch viel Erklärungsarbeit leisten. Gerade wenn Systeme komplexer und Entwicklungsteams größer werden, ist die häufige Reaktion die ich erlebe, dass sich die Teams auf ihren eigenen Kernbereich zurückziehen. Umso wichtiger wird die Rolle des Systemingenieurs, der vielleicht nicht die Tiefenkenntnis zu jedem Umsetzungsdetail hat, aber das große ganze Bild sieht.
Dann wird es auch für den Testbereich einfacher, besser zu testen.
Schönen Gruß aus Köln,
Maik