Wie funktioniert eigentlich Software-Entwicklung?
Auf welche Schwierigkeiten trifft man da, vor allem, wenn man
disruptiv arbeiten will?
Was wird die nächste Tesla-Produktion der pharmazeutischen oder
Biotech-Industrie?
Darüber spricht Christof Layher in der neuen Folge vom
ChaosHacker-Talk mit Marc Bleß, der sind in der
Unternehmensberatung damit beschäftigt, KI und Agilität
zusammenzubringen.
Vor Jahren hat er mal einen KI-unterstützten Coaching-Bot
angefangen zu bauen - ein halbes Jahr später kam ChatGPT um die
Ecke. Idee vertan und jetzt kümmert sich Marc darum, dass
Unternehmen Künstliche Intelligenz richtig einsetzen.
Christof hat schon öfter gesehen, dass Unternehmen versuchen,
Software zu bauen ohne Agilität, also in
traditionellenProjektmanagement-Methoden.
Für ihn ist das völlig unverständlich.
Was hält die Menschen davon ab, agil zu arbeiten?
Für Marc ist das die Tendenz zum Micromanagement. Kontrolle ist
schlecht möglich, wenn man Teams Aufgaben gibt, die diese in
einerfestgelegten Zeit dann erledigt haben sollen.
Im Engineering wird immer agil gearbeitet, in der Wissenschaft
auch.
In Unternehmen sollte das so auch normal werden.
Das Problem besteht aber auch in der Kommunikation.
Für viele ist Software abstrakt.
Wenn man sich nicht täglich damit beschäftigt, dann versteht man
gar nicht, was gemacht werden muss.
Deswegen ist es oft sinnig, MVPs zu bauen und diese den Kunden,
bzw. dem Business, zu präsentieren und so die eigene Arbeit
sichtbar zu machen.
Sonst verliert man schnell den Connect.
Mit einem ersten Proof of Concept kann man aber schonmal Feedback
einsammeln.
Doch dann entsteht ein neues Problem: Technische Schuld.
Die muss dann erstmal abgebaut werden.
Die beiden sprechen auch über architektonische Schuld in der
Produktion:Produktionsmaschinen sind oft so groß und keine
einzelnen Inseln, dass man sie nicht „mal eben“ stoppen kann, um
ein Update aufzuspielen.
Hier hilft es auch, über Notwendigkeiten zu sprechen.
Eine dritte Schuld ist die organisatorische Schuld: Viele
Unternehmen halten sich an Normen, Regeln und Dokumentationen
fest.
Ein Aufwand, der nicht getrieben wird, ist zu verstehen, was man
sich bei der Entwicklung der Norm eigentlich gedacht hat.
Das sollte man erfassen und sich dann überlegen, wie man den
Grundideen folgt, aber in der Praxis freier wird in der
Ausgestaltung.
00:00:00 Vorstellung Marc Bless
00:03:47 Software bauen ohne Agilität?
00:08:00 Software als abstraktes Konzept
00:13:00 Iterative Phasen
00:15:47 Connect zum Business
00:20:38 Technische Schuld
00:25:05 Arbeitsmethodiken
00:33:12 Architektonische Schuld
00:35:13 Organisatorische Schuld
00:37:49 Disruptive Produktion
00:39:48 Dokumentation und Normen
00:46:08 Organisationsoptimierung
00:54:10 Mensch im Vordergrund
00:55:22 Zwei Fragen an Marc
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.