Kaizen 2 go 318 : Software-Entstehungsprozess - GeeMco : Götz Müller Consulting

Inhalt der Episode:

Welche Herausforderungen bringen Produktentstehungsprozesse typischerweise mit sich?
Was unterscheidet den Software-Entstehungsprozess im Allgemeinen von allen anderen Produkt-Entstehungsprozessen?
Welche Konsequenzen ergeben sich daraus?
Welche Probleme kann die Endkunden- bzw. Anwenderorientierung mit sich bringen?
Was vernachlässigen viele Produktentstehungsprozesse?
Wie können die genannten Probleme angegangen werden?

Notizen zur Episode:

Mitmachen?

Wenn Sie selbst ein interessantes Thema für eine Episode im Umfeld von Geschäftsprozessen haben, können Sie mir das auf dieser Seite mit Vorbereitungsfragen vorschlagen.

Ich freue mich darauf!

Ihnen hat der Inhalt gefallen? Dann bewerten Sie die Episode bitte bei iTunes.

Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...

(Teil)automatisiertes Transkript

Episode 318 : Software-Entstehungsprozess

Herzlich willkommen zu dem Podcast für Lean Interessierte, die in ihren Organisationen die kontinuierliche Verbesserung der Geschäftsprozesse und Abläufe anstreben, um Nutzen zu steigern, Ressourcen-Verbrauch zu reduzieren und damit Freiräume für echte Wertschöpfung zu schaffen. Für mehr Erfolg durch Kunden- und Mitarbeiterzufriedenheit, höhere Produktivität durch mehr Effektivität und Effizienz. An den Maschinen, im Außendienst, in den Büros bis zur Chefetage.

Götz Müller: Heute habe ich Matthias Künzi bei mir im Podcast-Gespräch aus der Schweiz, ich denke, das werden wir gleich hören, er ist Software-Berater und Coach. Hallo Matthias.

Matthias Künzi: Hallo Götz. Ja. Freut mich, dass ich dabei sein kann.

Götz Müller: Ich habe schon ein kurzes Stichwort zu dir gesagt, aber stell dich gerne nochmal in ein paar Sätzen den Zuhörern vor.

Matthias Künzi: Ja, sehr gerne. Ja, bevor ich seit 2016 meine eigene Firma gegründet habe und jetzt eben im Coaching und Consulting im Software-Bereich unterwegs bin, habe ich mal ganz ursprünglich mechanische Grundausbildung gemacht, habe dann Ingenieurstudium gemacht, damals noch Richtung Elektronik und Regeltechnik und habe dann sehr, sehr viel im Software-Bereich gearbeitet in verschiedenen Rollen, als Entwickler, als Projektleiter oder auch als Führungskraft. Und dann eben, wie gesagt, habe ich dann 2016 meine eigene Firma gegründet und heute berate ich Unternehmen in der Beherrschung von komplexen Software-Projekten einerseits aus organisatorischer Prozesssicht, aber auch dann, wenn es ganz konkret um Software-Produkte geht, um da Struktur reinzubringen, die Architektur zu bewerten, zu optimieren, das sind so die Bereiche, in denen ich mit meinen Kunden arbeite.

Götz Müller: Genau und das ist im Grunde ja auch das Thema unserer Unterhaltung heute, Software-Entstehungsprozess Software-Entwicklungsprozesse, aber vielleicht gehen wir nochmal, und das finde ich spannend, weil du durchaus einen, ich würde sagen ähnlichen Hintergrund hast wie ich, einerseits einen sehr starken Software-Fokus aber andererseits eben dann eine Ingenieursausbildung und deshalb also dieser Schritt zurück zu den allgemeineren Produktentstehungsprozessen. Was ist in deiner Wahrnehmung, was sind da die großen Herausforderungen, die Produktentstehungsprozesse, vielleicht im Kontrast zu Produktionsprozessen, mit sich bringen?

Matthias Künzi: Ja, grundsätzlich ist es halt schon so, dass das so bei Produktentwicklung, also dieses Thema Anforderungsmanagement, Requirements zu erfassen, das ist eigentlich immer so das Hauptthema, oder man versucht dann relativ schnell ein Produkt zu entwickeln, dann hat man ja irgendeine vage Idee, man schafft es dann auch nicht irgendwie da wirklich, ja, genau zu definieren, ob das dann wirklich auch die Kundensicht abdeckt. Das sind schon das ist so die Hauptherausforderungen dann schon mal zu Beginn. Ich denke, das kennst du wahrscheinlich auch bei deinen Kunden, oder?

Götz Müller: Ja, und ich glaube im Software-Kontext haben wir vielleicht die noch größere Herausforderung, wenn ich es jetzt mit dem Auto vergleiche, der, der das Auto kauft, in der Regel fährt er das auch, der, der die Software kauft, ist nicht notwendigerweise nachher der, der sie auch nutzt.

Matthias Künzi: Ja, das ist richtig. Ja, das ist, es ist genauso und ich meine im Software-Umfeld ist es ja so, da gibt es eigentlich so schon mit dieser agilen Vorgehensweise, gibt es schon auch so diesen sogenannten Product Owner, wenn man zum Beispiel Scrum macht, das sollte ja dann eigentlich der sein, der eigentlich das Produkt ownt und der wirklich verantwortlich ist, zu definieren, wie das Produkt aussehen soll und der dann auch die Inputs für die Entwicklung gibt. Aber häufig kann man ja nicht wirklich von Ownership sprechen, sondern das sind dann halt auch interne Leute, die dann mehr oder weniger gut auch die Kunden kennen und deshalb hinkt einfach das Ganze ein bisschen, oder? Und das ist zwar eine gute Idee, so einen Produkt Owner zu haben, ursprünglich war auch mal die Idee, so einen Customer on site, dass man einfach wirklich auch den Kunden involviert in Entwicklung und das passiert aber ganz, ganz selten und deshalb hat man eigentlich diese Kundensicht dann eigentlich nicht wirklich in den Projekten drin, im Normalfall.

Götz Müller: Ja, was ergibt sich dann da aus deiner Sicht daraus, was passiert denn, was sind denn die Folgen?

Matthias Künzi: Ja, die Folgen sind halt, ich meine, dass man dann zwar etwas entwickelt, was dann nicht ganz eigentlich den Anforderungen des Kunden entspricht und das merkt man dann halt irgendwie erst relativ spät, was natürlich ein bisschen abgefangen wird mit dieser iterativen und inkrementellen Entwicklung, das ist sicher auch gut, oder wenn man da die Chance hat, dann auch wirklich in solchen Inkrementen das auch mal einem realen Kunden zu zeigen, oder auch Kundenvertretern, die dann einfach auch mal etwas ausprobieren, die mal irgendwie schon ein Vorversion oder so einen Prototyp mal ausprobieren können, dann kann man das natürlich ein bisschen abdecken damit, aber es ist alles andere als effizient und effektiv natürlich oder weil es kann sein, dass dann halt Dinge entwickelt werden, die halt so nicht wirklich verstanden, gebraucht oder wirklich sinnvoll sind für den Kunden und dann dreht man dann halt hier nochmals Ehrenrunden.

Götz Müller: Ja, und ich glaube, gerade auch diese Runden, die man dann dreht, bringen ja durchaus ihre eigenen Herausforderungen mit sich, wobei ja manchmal, so nehme ich es auch war, so habe ich es in meinem früheren Leben wahrgenommen, Software ist ja gleich geändert.

Matthias Künzi: Ja, genau. Das ist auch so ein ganz spezieller Glaubenssatz, würde ich schon fast sagen, ich meine, das stimmt natürlich, ich meine auch Software, also im Sinne von soft, irgendwie weich, irgendwie schnell änderbar, das stimmt grundsätzlich, das Problem ist aber eigentlich, dass auch eine größere Software braucht eine Struktur, das braucht eigentlich wie auch ein mechanisches Teil, braucht eine Konstruktion, sage ich dann auch, oder ich meine, man spricht dann im Software-Umfeld von einer Software-Architektur und so eine Software-Architektur, das bestimmt natürlich dann so ein Produkt und die ganze Entwicklung sehr massiv. Und wenn man jetzt also nicht wirklich die Anforderungen kennt oder nicht die richtigen Anforderungen hat, wenn man beginnt und da so eine Struktur eigentlich erstellt, dann bedeutet das halt, dass dann vielleicht auch sehr viel später auch die ganze Konstruktion, die ganze Struktur der Software wieder geändert werden muss und dann ist das ist tatsächlich sehr, sehr schwierig und sehr aufwendig, also da würde ich dann nicht mehr davon sprechen, dass das sehr einfach ist, weil es eben Software ist.

Götz Müller: Wenn wir uns jetzt nochmal auf das Thema Kunde konzentrieren, wie, ja im Grunde, wie kommt man aus dem Dilemma heraus oder hat es jetzt wirklich etwas mit dem Thema Software zu tun oder sind es vielleicht, also das ist jetzt sehr spekulativ, sind es andere Gründe?

Matthias Künzi: Ja, ich denke, man muss das ein bisschen unterscheiden. Meine Erfahrung ist, ich meine, das reine Anforderungsmanagement, Anforderungen zu erfahren von den Kunden, da gibt es mittlerweile schon auch viele Firmen, die das eigentlich recht gut machen, aber ich meine das ist das einfach, dass man auch versteht, was da wirklich gebraucht wird. Ich meine, das ist so der eine Teil oder was dann aber bei Software sehr, sehr speziell ist, ist, dass halt Software auch meistens einen langen Lebenszyklus hat, dass eben Software da eben auch einer Veränderung unterworfen ist. Ich glaube, da unterscheidet sich eben auch, ob ich da irgendeine Elektronik, eine Hardware, eine Mechanik oder irgendein mechanisches Gebilde entwickle, da wird dann irgendwie, da kann es vielleicht sein, dass gewisse Dinge da man noch dran schrauben kann oder erweitern kann mit Steckplätzen bei Elektronik, aber bei Software ist eigentlich dann wirklich auch normalerweise die Idee, dass das sehr, sehr lange lebt, dass das weiterentwickelt werden soll, dass da vielleicht auch irgendwie Betriebssysteme ersetzt werden, also Dinge, die da irgendwie darauf aufgebaut sind, und das ist halt dann die Schwierigkeit, da irgendein System zu bauen, das dann eben auch diese Zukunftsfähigkeit wirklich auch unterstützt und dass man dann nicht irgendwo nach ein paar Jahren an der Stelle steht und sagt: Okay, jetzt müssen wir das Ganze in die Tonne treten und neu bauen.

Götz Müller: Ja, da lasse ich gerade so vor meinen Augen, weil ich hier vor dem Fenster auch ein paar Autos sehe, auch wenn man es vielleicht nicht unbedingt darauf angelegt hat, aber ja, wahrscheinlich seit über 100 Jahren ist es für uns ganz natürlich, dass man halt irgendwann sich ein neues Auto kauft, weil es, in Anführungszeichen, wirklich runtergefahren ist, was einem ja bei der Software in der Form ein Stück weit nicht passiert und dann ist natürlich eine Software, wenn wir jetzt eine betriebliche Software betrachten ist sie, sehr viel stärker in die Geschäftsprozesse unter Umständen des Unternehmens, wenn ich jetzt mal sowas wie eine wie ERP-Software nehme, ist es ja viel stärker in die Geschäftsprozesse des Unternehmens verwoben und da kommt dann ja genau das, was du gerade erwähnt hast dazu, das tausche ich halt nicht mal so geschwind aus wie ich zum Autohändler fahren und mir ein neues hole.

Matthias Künzi: Ja, genau. Es gibt ja auch so die Aussage „Software altert nicht“, ich meine genau das, was du sagst, aber ich meine es gibt irgendwie, also diese klassischen Abnutzungserscheinungen, wie man sie bei anderen Geräten und Maschinen hat, die gibt es tatsächlich nicht bei der Software, aber trotzdem spricht man natürlich von Alterung. Die Alterung passiert dann halt dadurch, dass man Dinge ändert, dass vielleicht auch so diese Architektur, diese grundsätzliche Konstruktion ein bisschen verbessert wird, dann werden Dinge angebaut, vielleicht nicht mehr im Sinne des Erfinders ganz so, wie es gedacht war und dann kann man eigentlich eben auch von der Alterung sprechen oder es wird dann immer schlechter, immer schwieriger wartbar und das Umfeld verändert sich und das ist eine sehr, sehr große Herausforderung. Ich meine, ich habe viele Kunden, die haben auch mal begonnen mit einer Software-Entwicklung, haben einfach Dinge gebaut. Da sind dann irgendwie so Elektronik-Ingenieure, haben angefangen zu programmieren und dann ist das größer geworden. Die Anforderungen sind gestiegen, dann kommt die ganze Vernetzung dazu und auf einmal haben sie so eine riesige Software, die kaum mehr wartbar und weiterentwickelbar ist und das sind dann eben diese Herausforderungen, die dann die dann sehr sehr schwierig sind.

Götz Müller: Mhm, ja. Was ich da früher eben auch wahrgenommen habe, aber das ist wie gesagt schon eine Ecke her, was, weil ich damals auch so an der Schnittstelle zwischen Hard- und Software tätig war als Systemingenieur, bei einer Hardware-Entwicklung habe ich dann immer noch diesen Übergang zur Fertigung und da guckt dann noch mal jemand drauf. Das ist einerseits eine gewisse, eine gewisse zusätzliche Hürde, die ich halt bei der Software nicht habe, aber ich habe dadurch auch gewisse andere Ansprüche an das, was ich da baue, in Anführungszeichen, was halt bei der Software uns damals und, wie gesagt, da bin ich jetzt eine Weile weg, fehlt das heute immer noch oder ist man damit, geht man damit heute anders um, so Themen eben wie Qualitätssicherungsaspekte?

Matthias Künzi: Ja, das ist genauso wie du sagst. Ich meine, so Elektronik, auch Mechanik-Entwicklung oder dann braucht es dann vielleicht sogar Werkzeuge, die gebaut werden müssen oder dann muss irgendwie auch die Konstruktionszeichnung dann irgendwann eingefroren werden, weil dann eben die Produktion von solchen Werkzeugen länger geht oder eben auch so Hardware-Entwicklung, wo dann Prints hergestellt werden und das gibt es ja tatsächlich eben nicht in der Software und deshalb ist die Gefahr sehr groß, dass man da halt dann denkt, okay, man kann irgendwie kurz vor Release dann noch Änderungen machen, und das muss dann halt einfach von den Prozessen her sichergestellt werden. Da spricht man dann von einer Stabilisierungsphase oder von so Freezing, dass man sagt: Okay, jetzt ist eigentlich eingefroren, jetzt überlegt man sich tatsächlich bei jeder Änderungen, sollen wir das noch tun, kann das einen Impact haben auf Dinge, die eigentlich schon mal getestet worden sind und das ist so ein bisschen das Umfeld, wo ich mich sehr stark bewege, oder ich meine, das ist auch hier, wo ich so meinen Ingenieursbackground immer versuche, da wieder reinzubringen, dieses systematische Vorgehen, auch da irgendwas zu sagen: Okay, trotz Agilität müssen wir auch diese Phasen haben. Wir müssen jetzt mit der Entwicklung fertig machen, jetzt müssen wir in die nächste Phase, in die Stabilisierungsphase und das sind solche Dinge, die ebenso diese reinen agilen Konzepte zumindest in ihrer Grundform nicht hergeben, oder nicht davon sprechen und das macht es dann halt schwierig, weil die Leute sich gewohnt sind, okay, ja dann mache ich halt wieder eine Änderung und dann gefühlt werden dann einfach diese Software-Produkte nie stabil, weil sie immer einer Veränderung unterworfen sind.

Götz Müller: Ja, da möchte ich jetzt ganz gern noch ein bisschen nachbohren, weil ich glaube, das ist kein, in Anführungszeichen, Einzelfall und ein Stück weit vielleicht, jemand, der jetzt heute aus einer Hochschule kommt und halt kein Ingenieurstudium, also so wie wir zwei, ich bezeichne uns jetzt als Quereinsteiger, mit dieses vielleicht eher restriktiven Denken im Sinne von „Ich kann nicht alles machen“, wie, ja wie soll man das ausdrücken, wie fängt man ganz platt ausgedrückt, wie fängst du die Menschen ein? Ich weiß nicht, ob das jetzt der richtige Begriff ist, aber das ist jetzt gerade das, was mir durch den Kopf schießt.

Matthias Künzi: Ja, das ist es, ich glaube, ich weiß ein bisschen, was du andeuten möchtest und das ist tatsächlich so ein Thema. Ich meine, wenn ich so mit Leuten spreche, ich sage mal eher vielleicht auch mit jüngeren Leute, die eben vielleicht auch ein Software-Studium gemacht haben, dann kennen die diese Agilität und das ist so irgendwie im Blut drin, und ich habe das ja wirklich so wie du sagst, eher erst später gelernt oder wir haben irgendwie damals eben auch Elektronik entwickelt und irgendwie so wirklich auch so eigentlich so ein bisschen Wasserfall-Prozesse gelebt und ich glaube aber, die Stärke liegt tatsächlich in der Verbindung von diesen Dingen. Und ich habe häufig dann auch Entwicklungsleiter oder Software-Leiter, die da auf mich zukommen oder die mir dann erzählen: Hey irgendwie, das ist ja alles gut und recht mit dieser Agilität, aber irgendwie hab‘ ich einfach das Gefühl, da braucht es etwas mehr Struktur, etwas mehr Systematik, und das sind dann genau diese Punkte, oder wo dann die Leute irgendwie das Gefühl haben, hey, aber irgendwie wäre es vielleicht auch mal gut, etwas aufzuschreiben, mal Konzepte zu formulieren und dann vielleicht erst zu beginnen zu entwickeln, weil das ist etwas, was eben nicht mehr so ja, en vogue ist heute, sondern man hat dann das Gefühl, okay, man braucht eigentlich gar nicht viel zu wissen, man macht einfach mal einen Sprint und dann setzt man Software um und dann versucht man mal da so iterativ und inkrementell, sich da ranzutasten, und das ist natürlich sehr, sehr teuer und eben auch meistens mit ein bisschen Schmerzen verbunden in den Organisationen, und da gibt es jetzt viele, so bei meinen Kunden, gibt es viele, die da irgendwie denken, okay, das muss doch irgendwo auch noch ein bisschen anders gehen.

Götz Müller: Also ich höre auch raus, es ist anfänglich vielleicht sogar eher ein vages Bauchgefühl und da kommt mir dann wieder mein, in Anführungszeichen, zweites Herz Six Sigma in den Sinn, da sagt man ja auch zu Beginn, und im Lean-Kontext durchaus auch mal ähnlich, eben so ein vages Bauchgefühl, aber was das eigentliche Problem ist, ist anfänglich gar nicht klar, weil sonst müssten wir über solche Dinge gar nicht reden, dann würde man es halt machen, dann würde man es halt lösen, wenn man wüsste, das wirkliche Problem ist.

Matthias Künzi: Ja, das ist richtig. Aber es gibt ja auch, es gibt ja auch viele Organisationsentwickler, die versuchen dann eben auch so ein Muster, agile Transformation da überzustülpen über Organisationen, das kann in gewissen Fällen natürlich funktionieren. Ich bin da sehr davon abgekommen, einfach dazu sagen, okay, ihr müsst einfach agiler werden, sondern ich versuch hauptsächlich eben auch wirklich mal das richtig zu analysieren und mal zu schauen, okay, wo, wie sind denn wirklich die Reibungspunkte und ob dann irgendwie eine Methode, ein agiler Prozess notwendig ist oder es einfach darum geht, dass man den Leuten vielleicht sagen muss, hey, vielleicht solltet ihr vielleicht auch mal Anforderungen aufschreiben und gegenseitig reviewen, bevor ihr mit der Entwicklung beginnt, das ist dann von Fall zu Fall natürlich sehr unterschiedlich.

Götz Müller: Ja, und ich finde es jetzt spannend und da schließt sich für mich ein Stück weit der Kreis, einerseits hinten raus, um es mal so auszudrücken, da fehlt mir diese, ich nenne es jetzt mal normative Kraft einer Produktion, und andererseits fehlt es mir aber, so habe ich es bei dir rausgehört, fehlt es mir vorne, weil ich mir vorne nicht die Gedanken machen muss, wie ich mir das vielleicht mache, wenn ich ein Auto baue, da ist auch dieser Plattformgedanke, aber wenn wir das als Autofahrer, als Kunden gar nicht so wahrnehmen, aber das ist dann ein ganz wichtiges Element, was die Autobauer im Grunde auch bei Toyota abgeguckt haben und die Guten schon seit vielen Jahren machen, noch keiner wirklich so richtig gut wie Toyota, aber aus dem, was du jetzt gerade erzählt hast, höre ich das auch ganz deutlich raus, dass das halt in bestimmten Bereichen bei der Software fehlt, weil ich halt mal schnell, ich muss halt nicht erst, ich muss kein Eisen biegen, um das mal so flapsig auszudrücken, sondern ich kodiere halt erst mal etwas los.

Matthias Künzi: Ja, genau. Und das hat natürlich zwei, ich meine das eine, was wir jetzt ja vorhin schon besprochen haben, ist natürlich so diese Kundensicht, die dann vielleicht fehlt oder dass man ein Produkt entwickelt, das zum Schluss dann halt so ein bisschen neben dem vorbei ist, was der Kunde wirklich braucht und gewünscht hat. Das ist das eine. Das andere ist aber natürlich auch, dass das hier eine sehr große Reibung in die Entwicklung reinbringt oder ich meine, ich habe dann Kunden auch die haben dann begonnen, die haben auch da wirklich iterativ, inkrementell, eigentlich so agil gemacht, wie man das auch, wie das eigentlich auch, also von dem her eigentlich nicht schlecht gemacht, das Problem war einfach da dann, dass auch gewisse Dinge dann gefehlt haben, ganz klar zu sagen, wie wollen wir es dann und dann haben die begonnen, weil es eine große Software-Entwicklung ist, das auf breitere Füße zu stellen, auch zusätzliche Software-Partner da miteinzubringen und dann wird es natürlich dann immer noch schwieriger, oder weil dann ist einfach auch, dann fehlen einfach die Anforderungen, um effizient entwickeln zu können oder weil dann eben nicht mehr die internen Leute, die dann schon mal irgendwie über den Tisch rufen können und fragen können: Hey, wie hast du dir das vorgestellt, sondern die sind dann vielleicht sogar remote, die müssen wissen, was sie jetzt entwickeln und dann gibt es halt die einen, die tun dann einfach irgendwas und die anderen, die fragen dann immer nach und das beides nervt dann natürlich die internen Leute und dann ist dann irgendwie das Chaos perfekt oder das sind auch viele, aus meiner Sicht eben diese Mängel, die dann am Anfang so ein bisschen dieses Frontloading vernachlässigt wird und dass das rächt sich dann eben auch in der Entwicklung, weil dann einfach nicht mehr effizient gearbeitet werden kann.

Götz Müller: Ja, das ist aber, also Stichwort Frontloading, das ist ein Element, was ich jetzt im klassischen Entwicklungskontext, also wo es nicht nur um reine Software geht, nehme ich das auch sehr oft wahr, dass es auch dort viel zu kurz kommt und ich meine, das mag jetzt aber auch, da die Rückfrage dann an dich, das mag jetzt vielleicht im Softwareentwicklungskontext, was die Produktkosten angeht, nicht ganz so kritisch sein, aber typischerweise sagt man, dass eine Produktentwicklung jetzt in einem physischen, bei einem physischen Produkt weit über 50% der späteren Produktkosten, also nicht die reine Entwicklungszeit, sondern den Einfluss, den eine Entwicklung ausübt, ist dann auf die schlussendlichen Produktkosten, die ein Kunde bezahlen muss, weit über 50%.

Matthias Künzi: Mhm. Ja, also das ist jetzt noch schwierig, wie das so im Software-Umfeld aussieht, aber ich meine, die Frage ist halt einfach, was würde da alles irgendwie dazugehören zum Frontloading, oder ich meine, dieser Begriff, der ist ja tatsächlich im Software-Umfeld ist der ja nicht geläufig, oder? Ich meine, ich kenne den auch so eher aus diesem Lean-Umfeld. Ich find das aber eigentlich guten Begriff, den ich immer auch wieder mal verwende, um auch irgendwie aufzuzeigen, hey, da braucht es einfach gewisse Dinge vorab und für mich gehören dann eben auch so Dinge dazu, nebst diesen Anforderungen eben auch wirklich eine gute Architektur zu bauen, selbst wenn man versucht, eine evolutionäre Design-Architektur zu bauen, braucht es eben auch eine gute Grundlage, damit man eben auch dann wirklich inkrementell das Ganze erweitern kann. Und wenn man das dann eben auch dazu zählt, ich glaube, da kommt man dann auch schon auf eine große Prozentzahl, vielleicht nicht 50%, aber ich denke, da lohnt sich eben auch da wirklich diese Zeit zu investieren.

Götz Müller: Ja, damit eben irgendwo, wenn man so das Bild eines Hauses vor Augen hat, damit man halt ein gutes Fundament hat. Gut. Was wäre jetzt aus deiner Sicht, ja, der Ausweg aus dem Dilemma? Ich meine, ein Stück weit haben wir es schon diskutiert, ich möchte es noch ein bisschen vertiefen, im Sinne von wenn, du hast auch eine Sache angedeutet, und da ist mir dann auch wieder eine Situation eingefallen aus, ja, aus meinem früheren Leben raus, wo dann eben auch investiert wurde, im Sinne von, wir renovieren jetzt unsere Plattform und da habe ich so das Gefühl, dass das vielleicht auch in dem Software-Entwicklungskontext ein bisschen zu kurz kommt, weil ich halt nicht diesen ultimativen Zwang habe.

Matthias Künzi: Ja, ja, genau. Es ist sehr gefährlich natürlich. Ich meine, man hat dann vielleicht eine Software entwickelt, die wird weiterentwickelt, die wird irgendwie ausgebaut, umgebaut, und dann merkt man eigentlich gar nicht, wieso das Ganze immer schleppender geht. Man braucht dann auch irgendwie viele Ressourcen, um das Ganze am Leben zu halten, diese Maintenance-Phase irgendwie zu bewältigen und ich glaube, das ist etwas, was vielen Leuten gar nicht so wirklich bewusst ist, aber man hat dann auch, irgendwie ist das so selbstverständlich, okay, da braucht es jetzt einfach irgendwie die Leute und ich meine, solange dann halt eben vielleicht auch Mitarbeiter dabei sind, die sehr viel Erfahrung haben, die das Produkt sehr gut kennen, ist das auch meist nicht so ein Problem. Aber wenn man sich dann überlegt, okay, wenn da jemand dann gehen würde und dann das ganze Knowhow, und das ist wenig dokumentiert, dann kann es dann irgendwie sehr, sehr schnell zu einem richtigen Problem werden. Und das ist so ein bisschen das Diese, dass es so schleichend geht, dass man das vernachlässigt und es dann immer mehr Aufwand gibt und so mein Ansatz heutzutage ist, dass ich da versuche, auch so ein bisschen diesen Fachkräftemangel da reinzubringen, oder dass ich dann auch den Leuten irgendwie erzähle, ja, schau mal, ich meine, ihr habt so viele Arbeiten auch mit Dingen, die ihr eigentlich besser machen könntet, wo ihr effizienter werden könntet, da braucht ihr nicht neue Leute zu suchen, sondern müsst nur schauen, dass ihr vielleicht das, was ihr zu tun habt, das etwas schneller und etwas effizienter oder eben auch weniger und dann so auch entsprechend Zeit spart und dann vielleicht auch mehr Innovationen machen könnt, ohne dass ihr neue Fachkräfte braucht. Das ist so ein bisschen diese Marketing-Thematik, die ich versuche reinzubringen und das funktioniert eigentlich ganz gut, weil dann denken sich dann die Leute: „Ah okay, ja das macht irgendwie Sinn, weil wir finden keine Leute und irgendwie unsere Leute, die sind irgendwie beschäftigt mit dem alten Zeugs, statt dass wir da Neues bauen können und dann kommt dann so ein bisschen diese Erkenntnis und dann versucht man dann halt das anzugehen.

Götz Müller: Ja, in dem Kontext kommt mir jetzt noch etwas in den Sinn, was man früher, also ich rede jetzt hier durchaus über 20+ Jahre, dieser Punkt Lines of Code pro Zeiteinheit, das ist ja so eine naive Maßzahl, die man für die Produktivität eines Software-Entwicklers manchmal genommen hat, zumindest wie gesagt, vor Jahrzehnten, mag heute hoffentlich anders sein, aber was mir damals schon aufgefallen ist, und im Grunde habe ich das heute nicht anders, hat sich das nicht verändert, dass damals schon die Unterschiede in der, in Anführungszeichen, Produktivität eines Software-Entwicklers, fiel mir damals und heute ist es immer noch so, kein anderer Berufszweig ein, wo sich so große Unterschiede ergeben zwischen einem guten Softwareentwickler und einem halt noch nicht so Guten. Ist das heute, also jetzt einfach die Frage an dich, du bist da heute näher dran, ist das immer noch so und was ergibt sich vielleicht sogar aus dieser Erkenntnis, wenn es noch so sein sollte?

Matthias Künzi: Ja, das ist tatsächlich, das habe ich auch vor x Jahren mal gelesen, dass da irgendwie so von Faktor 10-12 die Rede ist und das hat mich dann auch extrem gewundert, aber ich würde heute sagen, mit meiner Erfahrung, das kann ich eigentlich unterschreiben, dass das tatsächlich so ist und dass immer noch so ist, also da gibt es tatsächlich Faktoren dazwischen und ich glaube so, aus meiner Sicht, ich meine, es geht ja nicht darum, dann irgendwie so diese auszusortieren und irgendwie zu versuchen, irgendwie nur die Leute zu finden, die da irgendwie sehr viel produktiver sind. Ich glaube, es hängt auch sehr stark damit zusammen, da vielleicht auch eben so ein bisschen Spezialisierung zu haben oder Dinge auch aufzuteilen, gerade im Software-Umfeld gibt es vielleicht auch eben so diese konzeptionellen Dinge, Architekturen und ich denke, da muss man eben wirklich die guten Leute einsetzen, die das definieren, die das eben vielleicht auch dokumentieren idealerweise, da auch Vorgaben machen und dann kann man natürlich auch die Produktivität von, ich sage mal nicht so Experten-Level-Programmierern, die können dann natürlich auch sehr viel effizienter arbeiten und das ist aus meiner Sicht so die Lösung, dass man da halt versucht, ein bisschen das ganze aufzutrennen. Das funktioniert aber in vielen Fällen nicht so gut, weil auch sehr gute Softwareentwickler sich da so bisschen scheuen, da konzeptionell zu arbeiten und zu dokumentieren, weil die dann halt auch lieber in die Taste greifen und ihren Code selber schreiben, aber meist führt einfach kein Weg daran vorbei und das sind so ein bisschen die Diskussionen, die ich dann häufig habe, in diesen Software-Teams, wie man da eben da auch optimieren kann.

Götz Müller: Ja, und das Stück weit hört es sich für mich so an, also da dann durchaus wieder eine ähnliche Situationen wie bei physischen Produkten, wie gebe ich denn dieses Wissen so weiter an jemand anders, weil ich habe so das Gefühl und wenn ich da so vor meinem geistigen Auge den ein oder anderen Softwareentwickler vorbeiziehen lasse, die wussten im Grunde selber gar nicht, was sie jetzt, außer diesen Lines of Code pro Zeiteinheit, was sie jetzt so viel anders machen.

Matthias Künzi: Ja, das ist sicher so. Ich meine, im Softwarebereich ist halt auch, oder wenn man jetzt wirklich auf diese Programmiertätigkeit schaut, ich meine, da gibt es dann eben schon Dinge, die man etwas komplizierter machen kann oder eben vielleicht auch diese Sprach-Features etwas elegant reinsetzen kann. Ich meine, da ist natürlich ein riesen Faktor drin, aber das ist halt einfach auch eine Thematik, ich glaube, die lässt sich tatsächlich eben dadurch auch auflösen, dass man da auch Vorgaben macht, dass man auch irgendwie sagt, okay, wie werden Dinge gemacht, welche Sprach-Features werden eingesetzt, auf welche Art und Weise und dann eben vielleicht auch so ein Rahmenwerk, ein Framework gebaut, Libraries gebaut, die wiederverwendet werden können, und wenn man das eben tut, ich meine, dann lösen sich eigentlich so diese Unterschiede sehr stark auf, weil dann eben jeder Entwickler da nicht irgendwie immer irgendwie so von Grund auf eigentlich mit den kleinen Elemente der Programmiersprache arbeiten muss, sondern irgendwann dann eben sehr mächtige, ich sage immer so kleine Legosteine hat, die er dann zusammenbauen kann und dadurch natürlich viel, viel effizienter das Ganze geschieht und das, ich glaube, das ist so der Ansatz, um das in den Griff zu kriegen.

Götz Müller: Ja, und da schließt sich für mich dann der ganz große Kreis, der ganz große Bogen Richtung Lean rüber. Ja, der Prozess ist wichtig, aber die Menschen, die in dem Prozess arbeiten mit der Tätigkeit, die sie tun, sind im Grunde genauso wichtig und ich muss mir halt überlegen: Was können sie, wo haben sie vielleicht noch Defizite, wie kann ich die beheben? Und dann auf einer, wie soll man es ausdrücken, vielleicht auf einer Art von Meta-Ebene einen Prozess zu definieren, der jetzt mit der reinen Produktentstehung gar nichts zu tun hat, aber wie gebe ich Wissen weiter, wie gebe ich Erfahrungen weiter, um … ich meine, das Thema, was du gesagt hast, ist ja auch ganz entscheidend jetzt, ich gehöre noch zu den Babyboomers, ich weiß nicht, wie das in der Schweiz eingeordnet wird, aber wir werden irgendwann in den Ruhestand gehen und das ist ja keine zweistellige Jahreszahl mehr und, ich glaube, da ist die Gefahr eben, du hast es auch schon angedeutet, ganz groß, dass unheimlich Wissen verloren geht.

Matthias Künzi: Ja, genau. Und ich sehe es genauso. Ich meine, das eine ist so dieses Technische, die Prozesse, die Methoden, wie Dinge gemacht werden, das ist das eine, aber es ist tatsächlich so, eben diese menschliche Komponente oder eben auch das Team, die Möglichkeiten, die vielleicht auch eine Organisation hat, von den Leuten, vom Ausbildungsstand, vom Expertenlevel, und da braucht es eben dann vielleicht auch Anpassungen an den Prozessen, damit das eben dann auch gut funktioniert. Und das bedeutet eben auch, dass eben ein Prozess für Firma A eben, der vielleicht sehr, sehr gut funktioniert für Firma B eben nicht funktioniert, einfach weil es eine andere Konstellation ist. Und eben dieses Knowhow-Transfer, ich meine, wir sprechen ja dann im Software-Umfeld eher dann von diesem Re-Using, das ist dann eigentlich so ein bisschen angewandtes Knowhow-Transfer, würde ich mal sagen, und das ist eben sehr, sehr wichtig, dass man da eben auch versuchte, das nicht auszureizen und zuschauen, okay, wie kann ich denn nicht nur einfach Informationen irgendwie bereitstellen im Sinne von Knowhow, sondern wie kann ich eben auch immer effizienter arbeiten, Dinge wiederverwenden, so Teilkomponenten vielleicht auch bauen, die dann eingesetzt werden und das macht es dann natürlich viel einfacher.

Götz Müller: Ja, auch wenn du den Begriff nicht verwendet hast, zumindest hab ich ihn nicht so rausgehört, aber jetzt in meinem Kontext eben, der Begriff der Standards ist da ganz entscheidend und jetzt auch wieder so ein bisschen reflektiert, was habe ich früher erlebt und du hast es auch so ein bisschen angedeutet noch mit dem Thema, wie kodiere ich auch manchmal irgendwas und manchmal rein nur dieses, wie schreibe ich es auf, was teile ich in Zeilen auf, was nehme in eine Zeile rein, um es Lesen zu können, manchmal auch nur, weil ja eben, auch da wieder dieser Bogen zur Produktion rüber, weil ich nicht diesen Zwang habe, es aufschreiben zu müssen, weil irgendwo jemand damit weiter arbeitet, damit er das produzieren kann.

Matthias Künzi: Ja, genau. Das ist so. Das ist auch so. Ich glaube, da könnten wir eine eigene Podcast-Episode machen, über Standards. Ich meine, ich komme ja, ich habe ja auch Software entwickelt für Medizinprodukte und deshalb habe ich mich da sehr lange mit dem auseinandergesetzt und das ist tatsächlich etwas, das ein bisschen verpönt ist im Software-Umfeld. Man hat das Gefühl, die Standards beschränken die Leute in ihrer Agilität. Ich sage dann immer, ja, du musst ja nicht bei Standard-Aufgaben kreativ sein, da definieren wir einfach, wie es sein soll, dann sollen es alle gleich machen und dann haben wir so wieder freien Raum für Kreativität bei den wirklich wichtigen Dingen. Also ich sehe das genau gleich oder ich glaube, viele Dinge die kann man standardisieren, da kann man auch wirklich sein diese Entscheide auch schneller machen, dass man sagt: Okay, das ist einfach eine Standard-Aufgabe, die lösen wir genau so und genau so wird es gemacht. Das bringt einerseits eine Einheitlichkeit natürlich, das bringt aber auch für, gerade für neue Leute macht es das viel einfacher, weil sie genau wissen, wie Dinge gemacht werden. Und ich glaube, das ist auch etwas, was man extrem unterschätzt in den Umfeldern, wo es eben regulatorisch nicht vorgeschrieben ist oder dass man da eben auch trotzdem versucht zu überlegen, wo braucht es Standards, was wollen wir tun. Und da spricht man nicht nur von Coding Standards, sondern eben auch vielleicht auf Design-Ebene, auf Anforderungsebene, auf Architektur-Ebene, auf allen Prozess stufen.

Götz Müller: Ja, da glaube ich eben, da kann die Software, bei all dem, was du jetzt erzählt hast, habe ich das Gefühl, es hat sich seit meiner Zeit in manchen Bereichen gar nicht so viel verändert und das ist aber, glaube ich, eben so ein Punkt, wo die Software, die Software-Entwicklung von einer klassischen physischen Produktentwicklung noch einiges abgucken kann, auch wenn sie, und das finde ich ja persönlich grundsätzlich sehr gut, auch wenn sie natürlich das agile Umfeld, da ja viel Lean drin steckt, aber manchmal schon wieder fast schon verloren geht, wo es denn herkommt und so könnte ich mir vorstellen, dass dieses, ja, über den Tellerrand rausschauen, was machen andere, was funktioniert bei anderen gut, was kann ich dann übernehmen. Ich meine, dieses Stichwort Good Manufacturing Practice aus dem medizinischen Kontext raus, glaube ich, ist dann durchaus lohnen sich auch im Software-Kontext anzuschauen.

Matthias Künzi: Ja, genau. Ich erinnere mich dann immer noch, als ich da meine Grundausbildung gemacht habe, als Maschinenmechaniker, da haben wir so, hatten wir so Bücher über Maschinenbauelemente und da erinnere ich mich noch häufig daran, und dann überleg ich mir dann jeweils, okay, jetzt im Software-Umfeld, was könnte denn das sein. Ja, wir haben irgendwie Design-Pattern, Entwurfsmuster, wir haben da so ein bisschen Lösungsschablonen, aber sehr, sehr vage, also wir haben eigentlich nicht Standardlösungen für Standardprobleme oder ich meine irgendwie, dass man sagt, okay, ja, da wissen wir, da müssen wir irgendwie zwei Bauteile miteinander verbinden und da gibt es eine Schraubverbindung oder Nietverbindung und so, ich meine auf dem Level sind wir im Software-Bereich noch lange nicht. Ich meine, Ansätze gibt es in die Richtung, ich denke, das ist auch etwas, das man weiterverfolgen sollte, weil ich glaube, da gibt es tatsächlich ein riesen Potenzial, dass eben solche Dinge auch viel, viel einfacher passieren und dass man da halt auch wie so einen Katalog mit Standards hat, wo man so Standardaufgaben dann auch wirklich lösen kann, aber da sind wir noch meilenweit entfernt von einer anderen Disziplin, das ist tatsächlich so.

Götz Müller: Ja, ich kann dich insofern beruhigen, auch im Bereich der physischen Produkte ist noch nicht alles Gold und glänzen tut es schon gar nicht. Deshalb finde ich es spannend, weil ein Stück weit, um es mal so platt auszudrücken, leben wir ja auch davon, dass nicht alles hundertprozentig funktioniert. Matthias, ich fand das eine sehr spannende Unterhaltung, speziell zum Schluss sind ein paar für mich Gedanken entstanden, die ich am Anfang auch in der Vorbereitung, in unserem Vorgespräch so gar nicht vermutet hätte. Deshalb Matthias, ich danke dir für deine Zeit.

Matthias Künzi: Sehr gerne, hat mir auch Spaß gemacht. Vielen Dank auch dir.

Götz Müller: Das war die heutige Episode im Gespräch mit Matthias Künzi zum Thema Software-Entstehungsprozess. Notizen und Links zur Episode finden Sie auf meiner Website unter dem Stichwort 318.

Wenn Ihnen die Folge gefallen hat, freue ich mich über Ihre Bewertung bei iTunes. Sie geben damit auch anderen Lean-Interessierten die Chance, den Podcast zu entdecken.

Ich bin Götz Müller und das war Kaizen to go. Vielen Dank fürs Zuhören und Ihr Interesse. Ich wünsche Ihnen eine gute Zeit bis zur nächsten Episode. Und denken Sie immer daran, bei allem was Sie tun oder lassen, das Leben ist viel zu kurz, um es mit Verschwendung zu verbringen.