Hallo und herzlich willkommen zu einer neuen Folge von Podcast Software Testing. Heute wieder mit einer Folge von der OOP 2023 aus München. Zu Gast bei mir Markus Harrer mit dem Thema "Evolutionäre Qualitätsziele". Da hatte ich mal drei Fragezeichen über dem Kopf,
was denn das bedeuten kann, aber Markus konnte die in drei Ausrufezeichen verwandeln. Er beschreibt uns das Modell, wieso Qualitätsziele sich über den Produktzyklus ändern und auch einen anderen Fokus bekommen und was das auf die Entwicklung und den Test für Auswirkungen hat. Viel Spaß bei der Folge. Hallo Markus, schön, dass du da bist. Ja, Richard Herrn, hallo. Vielen Dank für die Einladung.
Ja, sehr gerne. Du bist ja hier auf der OOP auch Speaker gewesen mit einem Thema, das wir heute aber nicht betrachten wollen, aber da sind wir ins Gespräch gekommen. Genau. Und ich fand das andere Thema auch ganz spannend. Das ist auch das erste,
das werden wir mal als Goodie noch aufheben, vielleicht für die Zukunft mal. Aber heute wollen wir uns über das Thema "Evolutionäre Qualitätsziele" unterhalten und das finde ich schon mal einen spannenden Titel, weil der bei mir schon mal drei Fragezeichen auslöst. Oh. Und genau, was bedeutet denn das? Ja, das ist ja ein gut gewählter Titel, wenn er ein bisschen so Spannung erzeugt.
Ja, also ich bin ja ein bisschen so in der Beratungswelt unterwegs. Ich mache viel Software-Retour-Beratung und habe da ganz viele unterschiedliche Kunden von Start-ups, die Software neu entwickeln möchten, aber auch sehr viele Leute, die beispielsweise in Bankenwesen unterwegs sind, im Versicherungsbereich, bei denen die Software, sagen wir mal so, nicht mehr so qualitativ hochwertig ist, die ein bisschen nach vorne gehen möchten, aber nicht wissen, was sie jetzt machen sollen,
wo sie jetzt ein Augenmerk drauf legen müssen. Und ja, in den ganzen IT-Tour-Reviews, wo ich da unterwegs bin, komme ich eben ein bisschen herum und habe so ein bisschen so das Gefühl gehabt, dass Leute ab und zu ein bisschen zu viel wollen dann auch,
wenn die sagen, ich möchte meine Software modernisieren beispielsweise. Und Start-ups, teilweise, die sehen nicht ein, dass man sich jetzt plötzlich um Qualität nochmal kümmern muss, man hat am Anfang schon mal irgendein Produkt herausgegeben und das ist doch alles toll.
Und plötzlich fällt ihnen irgendwo ein Brief eines Datenschutzbeauftragten einer Firma rein beispielsweise und die müssen dann handeln und irgendwelche Daten durch Konzepte erstellen und kommen die auch irgendwie auf die Gedanken, haben wir jetzt irgendwas verpasst oder so und kommen damit nicht zurecht mit diesen neuen Situationen. Und das habe ich ein bisschen beobachtet und ist ja so, in der Beratung, du musst ja sehr schnell reinkommen,
ein Unternehmen ein bisschen so wissen, wo die ticken, wo die stehen. Und da habe ich mir ein bisschen so angeschaut, wo ich so Schwerpunkte legen kann, bei Varelius beispielsweise. Und da sind wir mal gekommen beispielsweise bei einem, ja eher so ein Fintech-Unternehmen, da stelle ich mir üblicherweise so eine Frage wie, ja wie verdient der Geld? Dann sagen die zu mir, ja gar nicht oder so. Da habe ich schon gemerkt, es ist anders wie wenn man herstellt an einer
Bankensoftware, die ja jahrelang im Geschäft drin sind. Dann habe ich gedacht, irgendwie ist da was drin, was ich nicht erfasst habe. Und da bin ich vor ein paar Jahren auf einen Berater gekommen, Simon Wortley, der macht sehr so Unternehmensberatung an sich und der hat eben so diesen evolutionären Aspekt der Weiterentwicklung von beispielsweise Software-Systemen ziemlich stark getrieben. Und das hat mich dazu veranlasst, mal zu gucken, ob ich da nicht so diese Software-
qualitäten zuordnen kann. Ein bisschen so je nachdem, wie weit ein Software-System schon gekommen ist, ob es da nicht sinnvoll ist, mal zu gucken, welche Qualitäten jetzt so relevant sind, die man unbedingt jetzt nicht verpassen darf. So das ist diese Geschichte von diesem Vortrag, von meinem Thema. Ist im Endeffekt ein Denkmodell und damit war ich eigentlich am Anfang schon mal ganz gut, um ein bisschen so die ersten wichtigen Fragen in Beratungsprojekten zu stellen.
Ja, da wollen wir jetzt natürlich wer wissen. Also vielleicht kannst du einmal kurz zu diesem Evolutionsmodell, dass wir da auch das rein und recht mit nicht jeder kennen. Genau, es ist ein bisschen tricky. Also das Ganze ist angebettet in dem Thema Wortley-Mapping. Das ist, muss ich sagen, für diese Folge jetzt ein bisschen zu groß, komplett zu erklären. Mal ganz kurz, ich nenne es auch auf Deutsch strategische Landkarten oder
evolvierende Strategielandkarten. Also dann kann man ein bisschen so Software-Systeme, also grafisches Instrument, um Software-Systeme zu visualisieren, Komponenten von Software-Systemen zu visualisieren, in Beziehung zu setzen und ein bisschen darüber zu quatschen, was mache ich jetzt mit dem ganzen Ding. Und diese Wordley-Map-Technik, die hat so zwei Achsen an sich. Und eine Achse nennt sich Evolutionsachse und auf die bin ich vor allem rein, um Software-Qualität ein bisschen
zu visualisieren, zu mappen. Und die Evolutionsachse, die müssen wir ein bisschen erklären. Das ist, da kann man sich so ein bisschen vorstellen wie so ein Produkt-Linear-Lebenszyklus, nicht so ganz, aber so verschiedene Phasen, die so ein Software-System durchwandern kann. Man hat so was wie eine Genesis-Phase, so eine Ideen-Phase für ein Software-System. Ich weiß noch gar nicht, ob das überhaupt möglich ist, sowas umzusetzen in einem Software-System
beispielsweise. Und dann geht es langsam so über, ja, ich mache so einen ersten Prototypen, so ein Minimal-Viable-Product-Ding oder einen Prototyp an sich, um so erste Kunden zu akquadrieren. Da habe ich schon mal was an der Hand, aber ich weiß noch nicht, ob es so funktioniert, ob der Markt so da ist. Das ist so ganz typisch für so eine zweite Phase, die sich da eben so der Einzelanfertigung eben nennt. Also ich kann mal ein Beispiel machen, ganz am Anfang vielleicht
in der Genesis-Phase, mache mal ein Beispiel mit Reisekosten-Abrechnung. Ich habe keine Ahnung, ob ich irgendwie Belege systematisch erfassen kann, ob das jemand braucht da draußen überhaupt. Dann systematisier ich das vielleicht für mich, dann gehe ich so rüber in die Einzelanfertigung, mache vielleicht mal ein Excel-Sheet auf und sehe, okay, ich kann Preise erfassen in verschiedenen Spalten und Zeilen. Das funktioniert an sich für mich, weiß aber nicht, ob das da draußen
auch gebraucht wird. Und da kommen dann auch noch zwei andere Phasen, eher so Produkt-Phase. Ich sehe, okay, Reisekosten-Abrechnung muss jeder irgendwie machen. Vielleicht möchte ich jetzt eine Software bauen, eine Datenbank dahinter bauen, das beim Mediamarkt anbieten, weil sich das mittlerweile rentiert, so Zeit und Aufwand reinzustecken in so eine Software. Das sind so der richtigen Commodity-Phase, so Gewohnheitsgutmäßig, wo ich denke, ja, Reisekosten-Abrechnung braucht jeder
auf der Welt. Ich kann supergut herstellen, wieso stellen wir das nicht in der Cloud, S-Service beispielsweise. Und das sind so diese mehr oder weniger so ein Wachstum einer Software. Ja, Reifegrad, je nachdem, wie man das auch sehen möchte. Und meine Beobachtung war eben an der Stelle, dass für diese verschiedenen Phasen unterschiedliche Qualitäten immens wichtig sind in der Richtung hier. Und da muss ich nochmal tiefer rein. Also was ist die Evolutionsachse?
Ich glaube, es ist eher in diesen Phasen ein bisschen so versucht zu erklären. Aber diese Evolutionsachse, die besteht eigentlich aus, ja, nochmal zwei Achsen. Das ist ein bisschen zu schwierig. Es sind zwei Komponenten, sagen wir es mal so, mathematisch richtig vielleicht sogar. Du hast immer so ein Wechselspiel zwischen Angebot und Nachfrage-Wettbewerb in dem Fall. Das bedeutet ganz am Anfang, Genesis-Phase, da ist es so, du weißt ja noch gar nicht,
ob da draußen eine Nachfrage da ist für deine Idee der Reisekosten-Abrechnung. Und du weißt noch gar nicht, ob du das herstellen kannst. Also die Angebotszeit ist auch noch ungeklärt. Geht das überhaupt konzeptionell? Kann ich das formalisieren? Und da in dieser ersten Phase, ja, kann man sich dann die Frage stellen, welche Qualitäten wären uns plötzlich wichtig in diesem
Bereich? Also wie kann ich jetzt da loslegen, beim Thema Softwarequalität mal anzudocken, mal ein bisschen daran zu arbeiten, wenn mein Softwaresystem sich ein bisschen so nach vorne bewegt, Richtung vorne, Richtung es wächst weiter, es geht voran auf dieser Evolutionsgeschichte im Endeffekt. Und da kann man sich auch mal beispielsweise die ISO 25.000 ziehen, schnappen. Die heilige Bibel. Die heilige Bibel, auch für uns in der Softwaredikturwelt. Weil man
da einen schönen Wortschatz hat, muss man auch mal sagen. Also Begriffe, die sind geklärt. Man kann über Qualität fundierter reden, als wenn man selbst mit sowas eben rauskommt im Endeffekt. Ist super gut dafür, auch gedacht für uns in der Softwareentwicklungswelt. Und da kann man sich mal fragen, von diesen acht Qualitäts-Obermerkmalen im Endeffekt, was wird es da in dieser Genesis-Phase,
Experimentierphase relevant? Das könnte ich dir mal fragen. Was denkst du, wenn ich jetzt ganz am Anfang stehe, an so einer initialen Idee und ich möchte das irgendwie auf die Straße bringen, was könnte mir jetzt also interessant sein? Mir fallen gleich so ein paar Sachen an, die ich da überhaupt nicht relevant am Anfang sehe. Das sind so diese Sachen wie Wartbarkeit und Performance und sowas. Also Effizienz oder so. Das kann man am Anfang wahrscheinlich
weglassen. Es geht mal um Funktionalität, vielleicht auch um ein User-Erlebnis schon irgendwo. Ja genau, genau. Also ich muss ja beweisen eigentlich in der ersten Phase, dass ich was kann. Deswegen würde ich auch dieses Thema mit Funktionaleignung auf jeden Fall reinnehmen, um überhaupt diesen Case zu demonstrieren. Ja, geht. Das ist auf jeden Fall richtig. Genau. Und dann würde ich, ja Benutzbarkeit kann man auch nehmen. Also da merkt man, das Modell,
das ist ein bisschen unterschiedlich je nach Kontext. Für die Reisekostenabrechnung denkt man sofort, ja das muss ein bisschen weit gehen. Das muss zugänglich sein für ganz viele Endnutzer, im Endeffekt ein Unternehmen unterschiedlichen Ausbildungsgrad. Genau. Und es zieht mich weit vorne auf jeden Fall. Ich habe in meinem Modell mal rein das Thema mit der Zuverlässigkeit. Also ich habe ja keinen, ich muss ja am Anfang immer, ich habe immer gedacht an Venture Capitalists.
Die müssen mir Geld geben und dann muss ich immer zeigen, dass das funktioniert, was ich liefere. Und dass es nicht beim nächsten Klick irgendwie die Grätsche macht. Und deswegen habe ich eben in dieser ersten Phase so einen Fokus bei mir in diesem Denkmodell mit rein, Funktionaleignung und eben Zuverlässigkeit. Und da geht man als Firma auch sehr stark in eine Vorleistung. Man muss sehr viel tüfteln, man muss sehr viele Prototypen herausnehmen, mit vielen Ideen
irgendwie experimentieren. Und irgendwann kommt das Produkt aber zum Fliegen. Ich habe so erste Nutzende, vielleicht erste Firmen gewonnen, die da so mit einsteigen in mein Software-System, das ich herstelle. Und dann geht das Spiel eben weiter. Also plötzlich zieht bei der Evolutionsachse jetzt nicht mehr, also wenn man sich das ein bisschen so im Grafverlauf anschaut, nicht mehr so die Angebotszeite vor, sondern plötzlich zieht die Nachfrage an. Das bedeutet,
plötzlich kommen neue Kunden auf mich zu. Plötzlich habe ich ganz unterschiedliche Leute wieder im Blick, die ich da mit der Reisekosten-Aufrechnungssoftware beispielsweise versorgen muss. Und da kommt eben die Benutzbarkeit bei dir mit rein. Also das ist eben auch mein zweiter Schritt in diesem Fall, dass man sagt, okay, ich muss jetzt einen großen Markt irgendwie bedienen können. Die haben Ansprüche, Ästhetik, Ansprüche, wie dass es eben leicht zugänglich ist,
dass ich es benutzen kann. Da haben wir eben auf jeden Fall Benutzbarkeit mit drin. Und ja, das habe ich schon ein bisschen geteasert. Jetzt kommen viele neue Nutzer mit rein, je nachdem, wie ich das mache. Ist halt Performance auf was. Also Benutzbarkeit, Performance, so schön responsive eine Anwendung zu haben, ist natürlich was Cooles anzubieten und wird immer nachgefragt. Und deswegen schwappt hier eben von diesem Qualitätsspektrum das
erstmal rein in diese zweite Phase der Einzelanfertigung. Habe ich jetzt mal das so eben klassifiziert. Dann haben wir schon die vier mit drin. Und dann ist es so bei der Evolutionsachse, dass eben mein Produkt auf dem Markt ist. Das ist ein auffassendes Produkt, also Produkt gibt es auch als Phasenname. Deswegen sage ich Software-System. Das ist auf dem Markt ultra erfolgreich und die Nachfrage schießt in die Decke sozusagen.
Und ich habe aber das Problem, dass ich jetzt ganz viele neue große Kunden vielleicht bekomme. Und die muss ich auch irgendwie versorgen. Die haben neue Features, Wünsche an der Stelle. Und das kann ich irgendwie nur abdecken, indem ich eben auch neue Entwickler mit rein stelle. Deswegen habe ich jetzt hier den Case sozusagen aufgelegt für das Wartbarkeitsding. Ich muss jetzt plötzlich dafür sorgen, dass ich plötzlich auf der Angebotsseite wieder was bieten kann für den
Kunden und eben in akzeptabler Zeit Feature-Requests abfrühstücken kann. Da brauche ich Man-and-Woman Power sozusagen. Das bedeutet, ich muss mir halt überlegen, wie ich da Teams schnell onboarden, oder neue Mitarbeiter schnell onboarden kann. Wie ich Teams vielleicht unabhängig voneinander entwickeln lasse. Deswegen kommt eben Wartbarkeit, Thema Modalität, Analysefähigkeit mit rein. Und das andere ist, ich habe es schon vorher gesagt, anspruchsvollere Kunden, die möchten dann
vielleicht mal ein Löschkonzept sehen. Die möchten diesen Datenschutz, die Auftragsdatenverarbeitung natürlich so in der Richtung sehen, wie das funktioniert. Die brauchen Sicherheitskonzepte, die brauchen sowas wie Single Sign-On. Da kommt eben Sicherheit auch noch mit rein in diesem Modell. Und in diesem Fall bleiben uns noch zwei übrig. Im Endeffekt gehe ich mal kurz durch. Also Kompatibilität und Übertragbarkeit. Das ist so typisch für Commodity, also Cloud betreiben,
großflächig Leute versorgen, für Stabilität sorgen. Oder auch diese Schnittstandoffenheit. Bei dem Maps-Thema im Generellen ist es immer so, ich möchte am Schluss ja möglichst für andere Dienste anbieten. Also eine Reisekostenabrechnung kann mir vorstellen, dass sich da vielleicht,
der gute ist, ein bisschen ein Case konstruieren, denke ich. Sagen wir mal, vielleicht irgendwelche Analyse-Tools auf meine Reisekostensoftware loslassen möchte, um zu sehen, wie meine Reisekostenabrechnungen so sind, wie sie so laufen, wo ich vielleicht
dann mit Hotels was nachverhandeln kann, mit Mengenrabatten, was auch immer. Auf jeden Fall möchte ich den Punkt machen, dass man da vielleicht schnittschnell nach außen exponieren muss und dann auch regeln muss, wie die Kommunikation ist für Dienstenehmer im Endeffekt, die meine Software verwenden. Und das Letzte eben mit dem Thema, dass ich vielleicht in der Cloud betreibe, da möchte ich dafür sorgen, dass mein Software-System auf, ich sage mal, dumme Hardware
läuft. Ich möchte nicht mehr jeden Server einzeln benennen müssen, sondern dadurch, dass ich eben diesen Massenmarkt, der vielleicht auch dynamisch ist, abdecken möchte, damit ich halt einfach auf Cloud-Infrastruktur vielleicht laufen kann. Und deswegen setze ich da bei diesem Qualitätsthema nochmal ins Laufen zu schauen, ob ich eben über verschiedene, ja, verschiedene Services eben da kompatibel bin mit dem Laufen. Ja, das ist ja total spannend, dass man über
diesen Lifecycle von so einem Produkt zu sehen, also jetzt evolutionär gesehen. Was mir da sofort einfällt, ist irgendwo, das entspannt natürlich auch die ganze Softwareentwicklung in gewissem Maße. Gerade ein Startup oder so was, wenn ich da als Berater, ich bin total auf Wartbarkeit, die sagen, wir haben ja keine Zeit für Wartbarkeit, weil es vielleicht auch gerade
da noch nicht dran ist. Genau, also seit diesem Modell bin ich halt auch sehr entspannter. Also ich muss auch sagen, ich komme auch der Softwareentwicklung, bin ja jahrelanger Java-Entwickler, mag auch Clean Code, also da bin ich Feuer und Flamme auch dafür, wie man das umsetzt. Aber man muss auch auch zugeben, ab und zu braucht man auch ein bisschen Zurückhaltung. Also das habe ich auch selbst erfahren, habe ich selbst ein Startup mal gegründet gehabt. Unser Claim war sozusagen,
das erste Startup zu sein, das erfolgreich ist mit Clean Code von Anfang an. Also wir haben eben dieses Modell ein bisschen umgedreht. Für uns war ganz am Anfang Wartbarkeit und funktionelle Eignung und Benutzbarkeit waren uns erstmal egal. Hauptsache wir konnten da super gut entwickeln und alles war so use case getrieben, sauber geschnitten. Das führte auch dazu, dass wir das mit der, ich sage mal so, Übertragbarkeit ein bisschen auch übertrieben
hatten. Wir hatten die Möglichkeit eben unseren Persistenzmechanismus auszutauschen. Es ging ja innerhalb von ein, zwei Tagen und wir hatten es auch gemacht, fünfmal. Aber hat keinen Sinn ergeben, aber wir konnten. Also das ist ein bisschen so. Und da hilft mir eben auch dieses Modell ein bisschen auch für meine Kunden zu gucken. Fokussiert ihr euch jetzt auf die richtigen Dinge? Kann man noch ein bisschen was aussetzen? Muss ich jetzt Entscheidungen schon treffen oder kann ich
das ein bisschen vertragen? Das ist genau richtig die Beobachtung. Dafür nutze ich das erstmal, um initial mal ein bisschen sowas abzustecken, wo man eben noch tiefer reingeht oder was man sonst noch so tun kann. Ja, also es ist, also ich sage mal auch gerade für Bestandskunden, also wenn jemand schon lange Software entwickelt, jetzt kommt man dahin und dann sieht man ja, okay, eigentlich haben die schon viele Entwickler dran. Man sollte eigentlich auch
in Wartbarkeit investieren. Das wird aber komplett ausgeblendet, es werden immer neue Features dazu gebaut. Da hat man auch da nochmal so einfach auch guten Argumentationsmechanismus dafür. Ja, und also das Modell, also ich habe jetzt nur die eine Wahrheit erzählt, sagen wir mal so. Ja, das ist schön. Und es geht dann noch weiter und ich finde das viel spannender
an sich. Da muss ich aber nochmal zu Warty Maps zurück und diesen Achsen, die es da so gibt. Also wir waren jetzt andauernd bei dieser Evolutionsachse und die andere Achse, die es da so gibt, die bringt so eine Perspektive rein von dem Nutzenden einer Software. Die nennt sich da so Wertschöpfungskette an sich und im Endeffekt ist die Idee, Softwarekomponenten ein bisschen so anzuordnen, zu was sieht der Nutzer direkt, womit kommt er in Kontakt und was ist mehr so versteckt, was ist so
unten. Also das Thema üblicherweise, was es da gibt, ist eine Fotomanagement-Software in der Cloud oder so. Wenn man den Nutzer sieht, hat ein Bedürfnis beispielsweise, möchte gerne Fotos anzeigen, managen, drucken können oder so. Was brauche ich dazu? Das ist die Frage, was wird gebraucht dafür, um dieses Bedürfnis im Endeffekt zu befriedigen. Ja, ich brauche eine Website. Was braucht die Website? Die Website braucht Informationen über den Kunden. Also braucht man ein
Kundeninformationssystem. Was braucht das Kundeninformationssystem? Das braucht eine Betriebsplattform. Die Betriebsplattform braucht irgendwann mal Strom oder so, also bis ganz nach unten. Also wir gehen jetzt nicht bis zum Erzabbau, um irgendwelche Stromleitungen zu
gehen. Also ist da Cut natürlich mit drin, also nur das Relevante. Und es gibt einfach so eine Sicht von oben nach unten, wenn man sich das grafisch in der World Map darstellen würde, beziehungsweise in unserem Fall haben wir jetzt keine grafischen Mitteln mehr oder weniger da. Es gibt eben Dinge, die nahe sind bei den Nutzenden, wo klar ist, okay, wofür das gebraucht
wird. Websiten in meinem Fall ist klar. Kundeninformationssystem ist vielleicht nicht so nahe dran, aber wenn der Kunde sagt, ich habe ein Problem mit dem Fotodrucken und ruft an bei der Support-Hotline, dann würde er sagen, Moment, ich gucke meinem Kundeninformationssystem nach vielleicht, wo sie da stehen und so. Vielleicht haben sie einen anderen Account mittlerweile. Also das kann passieren, aber er wird nicht bekommen, dass ich, keine Ahnung, auf dem
Kubernetes-Cluster laufe. Also so technische Dinge, das ist ein Nutzenden meiner Software total egal. Und da habe ich mich auch gefragt, warum wird das immer schwieriger, wie Erwachsene ein Software-System ist, für gewisse Qualitäten der Software zu sorgen. Also wir haben ja das Problem in der Softwareentwicklung, dass immer neue Ansprüche kommen. Wir müssen immer was tun, aber irgendwie wird es schwieriger, mal für Erwartbarkeit zu werden, also ganz typisch.
Und da kann man das gleiche Spiel machen, indem man sagt, okay, welche der Qualitäten sind denn da besonders im Fokus der Nutzenden im Endeffekt und welche eben ein bisschen weg. Das können wir jetzt wieder durchgehen, mit diesen ganzen acht Oberqualitätsmerkmalen im Endeffekt ISO 25.000, 10. Und im Endeffekt kann man sich das deuten und würde ihm aber keiner glauben, weil das vielleicht ein bisschen gekünstelt aussieht. Deswegen habe ich dann noch eine zweite Datenquelle,
auch so in meinem Kopf sozusagen, mitgenommen. Und zwar mache ich schon seit ein paar Jahren Software-Editor-Trainings und habe da zufälligerweise auch eine Übung mit drin, um ein bisschen so den Teilnehmenden zu zeigen, was die Schwierigkeiten sind, wenn man beim Thema
Softwarequalität ein bisschen drüber spricht. Und vor allem habe ich drin, dass man die Teilnehmenden da ein bisschen dazu zwingt, ist vielleicht ein bisschen zu krass ausgedrückt, aber in verschiedenen Rollen hineinsteckt, um aus einer Rolle eines Geschäftsführers, eines Benutzers und eines Entwicklers jeweils verschiedene Gruppen zu verargumentieren, welche Qualitäten jetzt für das Software-System, das wir da so bauen in der Schulung, jetzt besonders wichtig
sind am Anfang. Und wir haben jetzt gedacht, es gibt unterschiedliche Sichtweisen von unterschiedlichen Leuten, also Captain Obvious, also ja, so weit, so klar. Und da habe ich das auch immer fasst, mit so einem schönen Spinnendiagramm, viele verschiedenen Qualitätsmerkmale wieder nach der ISO. Und das habe ich mir mal geschnappt jetzt vor ein paar Monaten und mal ausgewertet,
denn es war so eine Zahlenbewertung, also von 0 bis 10. Und habe das mal einfach eben in Excel hinein gepackt und dann mal geguckt, da kann ich ja so ein Ranking machen nach verschiedenen Stakeholdern im Endeffekt, bei wem denn wie jetzt welche Qualitäten besonders wichtig sind. Und natürlich das offensichtliche, Benutzer, Benutzbarkeit, Geschäftsführer, ja die war eher so wichtig beispielsweise, dass halt das, was geliefert wird, halt auch
eingehalten wird, deswegen hast du so funktionelle Eignungen. Spannend finde ich da in den letzten Jahren, dass das Thema Sicherheit nach oben geht, ist nicht ganz oben, aber langsam wird es auch klar, dass Geschäftsführer irgendwann haften müssen, wie die ganzen Datenlags.
Und Entwickler natürlich ja, Wartbarkeit ist ja klar. Und dann kannst du so Auswertungen machen und Beobachtungen wie, okay, wenn ich den Boss und die Benutzer zusammenlege, habe ich Benutzbarkeit ganz oben und bei den Entwicklern ist ganz unten von der Wahrnehmung oder von den Prioritäten im Endeffekt. Und das erklärt, warum vielleicht Leute ein bisschen aneinander vorbeireden, unterschiedliche Dinge auch sehen. Und das habe ich eben auch gemappt auf diese
Wertschöpfungsachse. Das bedeutet dann bei mir, also ich habe das so gemappt, dass ich sage, besonders wichtige Qualitäten, die sind den Benutzern besonders wichtig, weil die besonders wertvoll erscheinen und deswegen erscheinen die eben auch ganz oben in dieser
Wertschöpfungskette. Das ist sozusagen da die andere Anordnung. Dann hast du, wie gesagt, ganz oben funktionelle Eignungen und unten oder in der Mitte sowas wie Wartbarkeit, weil wenn man das alles zusammen verschneidet und ermittelt, was natürlich methodisch nicht ganz sauber ist, muss ich zugeben, aber es gibt das gleiche Bild, die gleiche Abfolge wie bei der Evolutionsachse, wenn man es da dann eben gliedert. Und was bedeutet das?
Das bedeutet, dass ich, wenn man das sieht, das mal vergegenwärtigt, dass ich am Anfang eigentlich eines Software-Steams mich um Qualitäten kümmere, die sehr, ich sage mal, nutzernah sind, die ein Product Owner auch einordnen kann, die ein Geschäftsführer, wo er darauf achtet, dass es passt. Also diese funktionelle Eignung, Benutzbarkeit, Themenzuverlässigkeit. Und je weiter ich nach hinten gehe, habe ich dann so Wartbarkeitsaspekte, Sicherheitsthemen,
die sind aber auch plötzlich weiter entfernt von dem eigentlichen Nutzenden. Das bedeutet, die kümmern sich dann nicht darum, ob jetzt welches Verschlüsselungsverfahren verwendet wird. Das ist für die eigentlich sehr weit weg. Und da finde ich immer, dass das irgendwann
umswitcht. Man hat so das Thema, ich habe die äußeren Qualitäten, externen Softwarequalitäten ein bisschen so, die auch für die Nutzenden eben gut interpretierbar sind und einordnbar sind, wo man was als Product Owner dazu auch sagen kann und definieren kann, also auch Vorgaben machen kann. Und später habe ich diese internen Softwarequalitäten, wo ich als Product Owner, als jemand, der das Produkt weiter treiben muss, keine Meinung habe. Und
dann gibt es immer diesen Kick. Das fängt dann genau so bei der Wartbarkeit an. Also da ist es das erste Mal, wo man auch als Software-Detektor oder Entwickler drin dann entsprechend andere Taktiken auffahren muss, um dafür zu werben, dass jetzt andere Qualitäten wichtig sind. Dann komme ich nicht mehr durch. Ja, wir müssen es schneller machen. Ja, mach. Also müssen wir es mehr wartbar machen. Was bedeutet das? Keine Ahnung. Warum sollte ich mir das
tun? Können wir es nicht schneller machen? Das kann ich besser zuordnen. Das ist ein typisches Projektproblem, was man häufig hat. Die Entwickler rufen nach mehr Wartbarkeit und wollen dann mehr haben davon. Und der Produkteur sagt, ja, was habe ich davon? Genau, weil am Anfang ist man sich nicht gewohnt. Das kommt auf uns zu, weil mit dem Thema Onboarding habe ich eben vorher auch
schon mit angesprochen, dass ich da irgendwann was machen muss. Um mein Produkt nach vorne zu schieben, weil ich sonst nicht mehr nachkomme, um Features zu liefern, weil ich keine Einarbeitung mehr liefern kann in angemessener Zeit, Software zu wenig flexibel ist. Ich muss mich einfach darum kümmern. Also wenn man sich das so ein bisschen vergegenwärtigt. Und natürlich, wie gesagt, andere Taktiken muss ich jetzt fahren. Da geht es beispielsweise
die Dora-Metriken. Also wie kann ich jetzt so zeigen, dass ich jetzt zu lange brauche, um ein Feature zu entwickeln. Dieses Lead-Time-Thema von der Idee bis zum Rollout. Da muss ich ein bisschen kreativer sein. Bei Sicherheit muss ich ein bisschen mit Angstszenarien, mit Risiken arbeiten. Was kann passieren? Um eben da anzudocken bei den Produktmanagenden, den Fraktionen
im Endeffekt. Und da muss ich als Architekt und Software-Mitglied eben entsprechend kreativer sein und mehr so Verbindungen zum Business eigentlich dann führen oder ziehen an der Stelle. Ich finde allein schon den zweiten Gedanken, den du da jetzt ja auch hattest, dass diese Rollen unterschiedliche Ziele auch im Kopf haben. Also das ist etwas, was man sich ja viel zu wenig bewusst. Man schmeißt die alle in ein Team rein und sagt, jetzt macht mal
Ziele und das sagt halt jeder was anderes. Weil für jeden was anderes wichtig ist in dem ganzen Prozess. Und ich glaube, dass allein schon dieses Bewusstsein ja total viel macht, dass man da einfach auch ein bisschen fokussierter drauf schauen kann, was ist denn jetzt gerade wichtig. Ja genau. Und das ist auch so, wenn man das nicht weiß, das ist ja das Thema, was den Umgang mit Softwarequalität ein bisschen schwierig macht. Dass man Leute befragt und
unterschiedliche Ansprüche hat. Und dann bin ich eigentlich verloren irgendwie als Software-Architekt oder Architektin, die das irgendwie so organisieren muss, dass doch jeder am gleichen Stang zieht im Endeffekt. Und diese unterschiedlichen Ansichten muss ich ja von vornherein schon mal ein bisschen den Konflikt lösen. Das ist auf jeden Fall wichtig, indem ich das aufschreibe, indem ich was validierbar mache. Ich bin auch Fan
von Nicht-Zielen. Dann das Thema mit der Evolution wieder. Was kann ich jetzt noch ein bisschen aussetzen, um die Leute mitzunehmen. Ja, ich weiß, Wartbarkeit ist wichtig. Ein gutes Thema, das wir unbedingt mal beachten müssen. Aber jetzt ist nicht der Zeitpunkt, denn das typische Beispiel ist ja, die Messe steht an. Wir müssen hier mal kurz was liefern. Und da kann ich Leute ein bisschen einfangen und sagen, ihr seid dran, hier ist die Roadmap.
Da kümmern wir uns dann drum, wenn wir wirklich die Probleme haben. Kann die Idee noch einfangen, ein bisschen vertragen, auf den Platzhalter setzen oder auf die Ersatzbank, je nachdem und später darauf zurückgreifen, wenn die Zeit da ist. Ja, ich glaube, das darf man auch da nicht vergessen. Das ist ja nicht absolut. Das ist, wie du sagst, auch eine Evolution. Und die Sachen verändern sich mit der Zeit. Es wird
die Wartbarkeit immer wichtiger. Es wird vielleicht die Sicherheit, das ganze Übertragbarkeitsthema noch mal wichtiger, als es vielleicht am Anfang ist. Also auch immer wieder darauf zu schauen und diese Qualitätsziele dann auch dementsprechend zu ranken, wo ich gerade in dieser Evolution bin oder auch von dieser Wertschöpfung, wo ich da gerade stehe.
Genau, genau. Das ist ja das Nächste. Was es noch mal schwieriger macht, neben diesen Multiperspektiven, blickt so auf das Thema Softwareaktivität, dass sich das mit der Zeit ändert und ich halt nicht fertig bin. Also ist ja was Gutes. Es zeigt, jemand braucht das System. Es gibt neue Kundengruppen. Das System ist aktiv. Das wird ja nicht sich verändern,
wenn es niemand nutzt. Das ist ja ein gutes Zeichen. Aber ich darf halt nicht verpennen, mit diesem Qualitätsthema in den Top 5 von Anfang weiterzuarbeiten und weiter zu optimieren. Also ich muss einfach ran. Also das darf ich nicht verschlafen im Endeffekt. Ganz richtig. Jetzt haben wir ja hier in unserer Hörerschaft ganz viele Entwickler, Entwicklerinnen, Tester, Testerinnen. Was würdest du denn, wenn die so im Projektsaft stehen sozusagen, was würdest
du denen als so einen ersten Schritt mitgeben? Wie die das mal bei sich im Team oder im Unternehmen auch mal mit betrachten können? Was hast du da an der Hand vielleicht? Genau, also das Erste wäre, dass man eben noch nicht, also man hat ja bestimmte Methodiken,
um den für Qualität zu werben. Und das für mich wäre halt wichtig, den Leuten mitzugeben, dass das an irgendeinem Punkt eben switcht von dieser Begreifbarkeit von den Produktmanagern, den Stakeholdern, dass das plötzlich etwas ominös wird und zu weit weg von dem täglichen
Doing. Dass man da eben neue Methodiken einfach braucht, neue Herangehensweisen. Also konkret beispielsweise, wenn das nicht zieht, also mein Modell nicht ziehen würde bei einer Firma beispielsweise, weil man das mit der Wartbarkeit nicht sieht, dann kann ich mir auch in der Entwicklung vorstellen, dann mache ich so eine Interessensgruppe bei mir intern. Also ich aktiv, ja, bilde ich eine Community of Practice beispielsweise, die sich darum kümmert,
wie man Wartbarkeit umsetzen kann in einem konkreten Kontext. Um einfach das ein bisschen mehr Awareness für diese Wichtigkeit des Themas auch hochzuheben. Und das könnte ich machen beispielsweise. Ich kenne jetzt von einer Firma, die macht eine Software-Craft-Community, um einfach das Thema der Wartbarkeit in die Höhe zu halten, um zu sagen, jetzt ist Zeit, wir müssen uns darum kümmern. Ist unser Problem gerade. Sind da ziemlich erfolgreich
damit und sowas kann ich eben auch lokal bei mir im eigenen Unternehmen starten. Vielleicht nicht mit einer Gruppengründung gleich direkt, sondern einfach ein bisschen zu werben. Jetzt ist Zeit drum. Hier auf unserer Agenda steht, wir wollen 50 neue Leute onboarden. Jetzt müssen wir halt handeln bei dem Bereich. Ja, und das kann ja dann auch den Proof bringen, dass das was bringt, dass dann auch irgendwann der Product Owner sieht, ja okay, so schlecht
ist es nicht, dass wir hier ein bisschen was in Richtung Wartbarkeit machen. Genau, also das habe ich auch so für die Entwickler, die müssen halt immer mehr versuchen, dann, wenn es wirklich tief runtergeht in die Technik, bei den eigentlichsten Qualitäten dafür, zu Schlüsse zu ziehen. Also ein Beispiel wäre so was wie, okay, wir haben eigentlich ein Business Need, wir müssen diesen Black Friday ein bisschen abfangen. Und da kann
ich natürlich sagen, ja, wir setzen Kubernetes ein oder so, aber das ist zu weit weg. Ich brauche dazu einen Zwischenpunkt, zu argumentieren, dass ich sage, okay, ich möchte gerne dynamische Lasten irgendwie abfangen können, was auch so eine Eigenschaft dann ist, wenn ich da in diesem Bereich unterwegs bin. Und das ist auch wieder viel besser zuortbar zu einem
Business Need im Endeffekt. Da kann ich ein bisschen schauen, also wie kann ich das, was unten in der Technik so herumschlummert, bei mir in der Software, was weg ist von den ganzen Leuten da oben, im Business, von der Business Sicht im Endeffekt geschickt verbinden mit Dingen, die mir ein bisschen so ein Sprungbrett liefern, damit die das besser zuordnen können. Also da muss man kreativ sein. Das ist halt einfach schwierig, auch pauschal was zu sagen.
Es gibt ein paar Heuristiken, die man nutzen kann, das sind diese Abkürzungen, dafür zu werben, Best Practices von anderen zu zeigen. Die machen das jetzt auch an der Stelle. Also ein paar Tricks gibt es, wobei man natürlich aufpassen muss mit Best Practices, dass es natürlich auf seinen eigenen Kontext passt. Aber da kann man schon viel auch in Erwicklung tun von sich heraus. Super. Also ich bin ganz begeistert auf einen ganz frischen Blick auch mal auf diese Software-Evolution.
Markus, da danke ich dir sehr, um mal diesen Blick auch mal wieder zu heben. Von mir aus ist das super, das Projekt, mal auch die Qualitätsziele anders zu sehen, auch das Rollenverständnis da zu sehen, was da eigentlich für Bedürfnisse sind und dass ich das eben auch entwickeln kann über die Zeit. Also da nehme ich jetzt auch ganz viel für mich mit und danke dir sehr, dass du hier warst im Podcast und wünsche dir noch eine schöne Konferenz. Ich danke dir auch, ja. Vielen Dank. Bis bald.
Bis dann. Ciao. Ciao. [Musik]