Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Diesmal im Gespräch Alessandro, Sebaste und Thomas Gspona. Thomas hat viel Erfahrung in der Pharmaindustrie und gemeinsam mit Alessandro haben sie Konzepte aus der Herstellung von Medikamenten übertragen in die Softwareentwicklung. Das Ganze unter dem Titel "Quality by Design", das heißt den Entwicklungsprozess schon so gut zu machen, dass gar nicht mehr so viele Fehler entstehen. Wie das aussehen kann,
verraten sie uns in dieser Folge. Viel Spaß beim Hören. Hallo Alessandro, hallo Thomas, schön, dass ihr da seid. Ciao Richi, freut uns, dabei zu sein. Ja, das ist heute eine Premiere, weil das ist heute meine erste Schweizer Folge im Podcast. Das ist gut. Alessandro, du hast das ja quasi mit aufgestellt. Ihr seid ja als Swiss Testing Board ja auch Partner von dem Podcast und das ist schön, dass wir jetzt auch hier die erste von hoffentlich
vielen Folgen auch gemeinsam gestalten können. Das freut mich natürlich sehr. Und ihr habt ein spannendes Thema mitgebracht. Das hat mir schon vom Titel sehr gut gefallen, weil da resoniert alles schon ein bisschen bei mir. Und zwar das Thema "Quality by Design". Ja, holt uns doch da mal rein, was heißt denn das eigentlich "Quality by Design"? Also angefangen hat das eigentlich damit, wenn du Software entwickelst, dann stellen wir halt fest,
dass die Firmen oft die Qualität mit dem Testen gleichsetzen. Natürlich ist das wichtig, zentral. Aber häufig haben wir halt festgestellt, dass eigentlich die Probleme woanders liegen. Nämlich dabei, dass du die Fehler produzierst, um sie danach zu suchen und wieder zu entfernen. Und es wäre ja eigentlich schlauer, die Fehler gar nicht erst zu produzieren.
Und eigentlich war das so der Antrieb. Und mit Thomas zusammen, der kommt aus der Pharmaindustrie und kann das Qubity dann vom Konzept her noch einiges besser erklären, ist das ein Ansatz, der sich sehr gut eignet. Ja, ich hatte ja Alessandro schon ein paar Jahre kennengelernt und ich bin nicht aus der Softwarebranche. Und in unseren Wanderungen haben wir dann häufig über Qualität, über Softwarequalität gesprochen.
Und dann habe ich dann gefühlt oder gespürt, dass das eigentlich genau das gleiche Prinzip ist, wie das in der Pharmaindustrie angewendet wird mit diesem Qubity, mit diesem Quality by Design. Und dann haben wir gedacht, schauen wir mal an, wie man das zusammenbringen kann. Ja, das ist natürlich super spannend. Jetzt haben wir hier natürlich nur Hörerinnen und Hörer, die aus der Softwarebranche kommen. Also die meisten gehe ich davon aus.
Wenn du sagst, in der Pharmabranche, wie funktioniert das da? Was sind das da für Konzepte? Ja, also Quality by Design ist ja grundsätzlich ein ganzheitlicher Ansatz für die Qualität. Und der beruht hauptsächlich auf Risikoanalysen und auf stetiger Verbesserung, also Continued Improvement. Und in der Pharmaindustrie läuft das so ab, dass alles sehr reguliert ist. Wir haben eine sehr regulierte Umgebung von den Gesundheitsbehörden.
Und da ist das Ziel schon, dass man wirklich diese Qualität, die ein Medikament braucht, reinbringt. Und alles fängt eigentlich an mit einem Quality Target Product Profile, einem QTPP. Und das ist nichts anderes als die Useranforderungen. Man überlegt sich, was muss das Medikament können? Also es muss sicher sein, es muss wirken. Heute würde man auch sagen, man muss es sich leisten können. Und heute würden auch Aspekte der Nachhaltigkeit reinkommen.
Und dann überlegt man sich, was sind jetzt im Herstellprozess die kritischen Qualitätsmerkmale, die ich dann effektiv mehr vermessen kann. Und man überlegt sich die ganze Zeit, was kann in meinem Herstellprozess schiefgehen, damit ich diese Qualität nicht erreiche. Und dort kommt dann diese Risikoanalyse ins Spiel. Und wichtig ist zu verstehen, dass man den Herstellprozess entwickelt. Das Bond in der Software wäre dann der Softwareentwicklungsprozess. In der Pharma ist es der Herstellprozess.
Und da geht es darum zu verstehen, was kann wo schiefgehen, damit man diese Qualität nicht erreicht. Und dann versucht man den Prozess so zu entwickeln, so zu designen, dass man diesen Prozess kontrolliert, stetig verbessert und kontrolliert. Und so kann man verhindern, dass Fehler ins Produkt reingebaut werden. Und man reduziert das Endprodukt-Testing, was ja eigentlich auch das Ziel ist beim Quality-Design in der Softwareentwicklung.
Ja, das ist natürlich ganz spannend, weil das ist ja genau das, was wir... Wenn wir die Testaufwände runterbringen, das ist ja eh ein Argument für jeden. Und du sagst es ganz schön, diese Qualitätsmerkmale, die haben wir ja in der Softwareindustrie ja auch, aber die liegen oft so ein bisschen... Also im Testkonzept stehen sie noch, wenn man die 2510 notiert oder so was. Aber dann sickert das so ein bisschen weg.
Und wie habt ihr euch diesem Transfer denn genähert, da Richtung diesen Prozess in die Software zu bringen? Nun, zuerst habe ich uns überlegt, man sollte zwischen Softwarequalität und Quellcodequalität unterscheiden. Weil die Qualität der Software hat eine gänzlich andere Ausrichtung als der Quellcode. Dabei geht es um diese Qualitätsmerkmale. Ich erwarte von einer Software, dass sie halt stabil läuft, performant ist, bedienbar ist und so weiter. Also du hast diese ISO-Normen angesprochen, klar.
Aber ich war jetzt letzte Woche bei einer Veranstaltung hier in der Schweiz, wo das Thema Nachhaltigkeit auch ein sehr, sehr grosser Teil wird und immer mehr. Und die Anforderung vom Kunden ist, beispielsweise in dieser Hinsicht auch zu wissen, wie viel Strom eine Applikation braucht, um ein Beispiel zu nennen. Auch das sind Merkmale, die du hineinbringst. Die Software sollte eigentlich über diese Merkmale definiert sein. Was bringt es dem Kunden, was braucht der Kunde?
Oder noch besser, was braucht das Kunden Kunden? Wenn ich eine Applikation anbiete als Service oder so. Und wir haben natürlich auch versucht, Analogien herzustellen. Alessandra aus der Softwarewelt und ich aus der Pharmawelt. Dann sind wir quasi Schritt für Schritt durch diese Building Blocks von Qubity durchgegangen und haben versucht zu sehen, wo gibt es diese Analogien oder wie könnte man das übersetzen.
In der Pharma ist es natürlich ein wissenschaftlicher Ansatz, also ein naturwissenschaftlicher Ansatz. Softwareentwicklung ist aus meiner Sicht weniger naturwissenschaftlich als Qubity. Aber es gibt eben doch diese Parallelen, eben Qualitätsattribute oder Prozesskontrollparameter. Das sind dann eben diese Aspekte, wo kann ich im Softwareentwicklungsprozess etwas steuern und die Qualität des Endprodukts schlussendlich beeinflussen.
Dann sind Aspekte wie Quellcode oder solche Sachen herausgekommen, die man mit ähnlichen Prinzipien abhandeln kann. Thomas hat vorher noch das Thema Regulatorien erwähnt. Uns ist allen bewusst, in der Softwareentwicklung ist das etwa so. Blockt man das? Man möchte nicht reguliert werden. Das war eigentlich genau einer der Schwerpunkte. Wie kann ich Qubity einführen, ohne genau dieses Gemüt zu vermitteln, aber effektiv auch nicht zu kontrollieren? Wir sind agil und die Agilität braucht es.
Und das ist dann, haben wir festgestellt, der Punkt ist eigentlich der, wenn du Software entwickelst, bist du an einem bestimmten Punkt, solltest du nicht agil sein oder respektive solltest du nicht alles tun können. Also wenn du einen Quellcode schreibst, dann irgendwo musst du Regeln einhalten bis zu einem bestimmten Punkt, damit die Qualität gewährt ist. Ab einem bestimmten Punkt sollst du flexibel sein.
Also wie du die Applikation baust, das sollte offen sein, wie die Lösung konstruiert ist, aber die Komponente, die du dazu benötigst, da möchten wir weniger Kompromisse haben. Und dieses Bewusstsein, was ist Softwarequalität, was ist Quellcodequalität und wie kann ich das messen, dann sprechen wir von Metriken. Metriken, ein Buch mit sieben Siegeln, wird häufig, wenn du ein Tool hast, das etwas ausspuckt, dann machst du es.
Ich persönlich habe es noch praktisch nie gesehen, dass man es dann wirklich auch einsetzt, um zu verstehen, wo geht es dann schief und was könnte ich tun, um es dann besser zu machen. Also es ist ein Zusammenspiel zwischen dem Messen, dem Verständnis, wie bauen wir Software, was für eine Technologie benutzen wir usw., dass wir einen guten Quellcode bekommen und basierend darauf dann eine gute Software, die den Anforderungen entspricht.
Also du merkst, es zerlegt die Softwareentwicklung in Teilbereiche, die wir dann beeinflussen möchten, auch überwachen möchten, aber nicht einschränken, nur verstehen. Hast du da oder habt ihr da vielleicht auch ein paar Beispiele? Also es ging ja bei Ö&Farmer quasi auch darum, diesen Herstellungsprozess zu verbessern und dort schon die Fehler quasi gar nicht entstehen zu lassen. Was sind denn da so für Metriken, die man in der Softwareentwicklung nutzen kann, um das sichtbar zu machen?
Also beim Kunden, wo ich bin, die brauchen SAFe als Framework. Einfaches Beispiel, es gibt ja diese Definition of Done, Definition of Ready, man hat Stories eingeführt. Ich habe dann relativ bald festgestellt, dass die Qualität dieser Artefakte, also dieser Stories oder dieses QBDs, zwar stehen, wie du anfangs gesagt hast, aber dann macht man es ein bisschen so, ein bisschen anders. Und eine Metrik, die wir nun eingeführt haben, ist die Datenqualität dieser Artefakte.
Also wir messen, wurde wirklich immer eine Fachanwendung ausgewählt, haben wir die Akzeptanzkriterien, wurde es richtig ausgefüllt, arbeiten wir diese Tickets so ab, wie wir das gedacht haben. Und dann haben wir festgestellt, 60% der Tickets sind unvollständig. Und dann ist es schon schwierig, du musst mehr interpretieren. Also es ist ein triviales Beispiel, es gibt dann beiders komplexere Dinge, aber so ist der Ansatz, also haben wir das eingeführt und das sichtbar gemacht.
Die Qualität der Tickets ist gestiegen, wenn man es sieht. Und dadurch auch konnten wir einfache Fehler reduzieren oder Loops reduzieren. Aber das musst du messen, vom Gefühl her kannst du das schon schnell mal sagen, aber das musst du dann messen. Und das ist schon sehr zentral bei diesem Ansatz. Du veränderst nicht etwas aus Gefühl, sondern weil du statistische Werte hast. Also du machst es bewusst, nicht zum Flächenbrand, sondern ganz gezielt.
Ja, also ich glaube, das kann ich mir gut vorstellen, diese Sichtbarkeit, dass das schon viel bringt, dass man sieht, okay, da ist was im Argen, weil jeder kennt seine Jira oder Asher Tickets oder sonst irgendwas, da steht Kraut und Rüben drinnen. Manchmal sind die Fehler ausgefüllt, manchmal nicht, aber man weiß gar nicht, wie ist das eigentlich das Gesamtbild dazu. Gerade mit Datenqualität, das ist ja schon etwas, was dann ja auch stark auf den Prozess abzielt.
Also dass das dann besser gemacht wird, besser ausgefüllt wird. Genau, das ist ja denke ich auch ein sehr wichtiger Aspekt, das ist eben dieses Prozessverständnis. Wie arbeiten die Leute, wie entwickeln die Leute die Software und dann kommen genau solche Aspekte ins Spiel, wenn man das nicht sauber ausfüllt oder so. Und das ist genau dort, wo es halt dann auch eine gewisse Standardisierung braucht. Wenn wir Jira Tickets machen, dann formulieren wir die so, dass wir da diesen Standard drin haben.
Und das hat dann einen grossen indirekten Effekt auf die Qualität und die Effizienz auch vom Entwickeln her. Da muss ich jetzt gleich noch einmal mit einem, weil wenn ich jetzt so meine Teams anschaue und sage denen, komm, wir machen das jetzt, dann sehe ich schon das Augenrollen, da denke ich mir, mein Gott, da müssen wir ja noch mehr machen, oh Gott, wofür denn das Ganze? Wie kriegt ihr denn das da rein, dass das wirklich auch gelebt wird? Das ist genau der Punkt, oder?
Qubity ist nicht ein Framework wie Scrum oder Safe, das die Vorschriften macht. Es geht darum, mit dem Team zusammen zu definieren, wo haben wir unsere Schwächen? Also vielleicht baust du etwas mit einer Technologie, die du noch nicht kennst. Also schaust du mit dieser Risikoanalyse grundsätzlich, wo könnte es schief gehen? Und genau dort definierst du Massnahmen. Es ist nicht gesagt, dass es zum Beispiel Test, Stream und Development dein Ansatz ist.
Es kann dein Ansatz sein, aber es muss ins Bild passen, es muss ins Team passen. Wenn du ein kleines Team hast mit zwei, drei Seniors, dann brauchst du wahrscheinlich weniger Regeln, weniger Vorschriften, um gute Software zu entwickeln, als wenn du ein Team hast, vielleicht fünf, sechs Teams hast mit zehn Leuten je, dann ist das vielleicht wichtiger, weil du auch Juniors hast oder Leute hast, die das Business noch nicht so kennen. Also das ist eigentlich schon der Erfolgsfaktor.
Nicht einfach blind irgendetwas darüberlegen, sondern mit dem Team zusammen herauszufinden, wo kann es schief gehen und genau dort eine Massnahme ergreifen, die das Team umsetzen will und kann. Und das ist natürlich eine kulturelle Geschichte. Das muss irgendwie in die Firma eingebaut sein, dieser Qualitätskultur.
Weil Qualität bedeutet nicht, dass man compliant ist, auch in der Pharma nicht, obwohl viele Leute das Gefühl haben, ja, ich habe die Spezifikationen und die Regulatorien erfüllt, also habe ich gute Qualität. Und das sollte ja in der Software auch nicht so sein. Es geht wirklich um diese innere Einstellung, was bedeutet Qualität für mich und wer ist verantwortlich für die Qualität. Und es ist jeder einzelne Mensch, der verantwortlich für die Qualität ist.
In der Pharma ging es dann in diese Richtung, dass man die Leute dann auch gefragt hat, würdest du dieses Medikament einem Kind spritzen? Ja. Was ist Qualität? Also wenn du einen Roboter programmierst oder ein Flugzeug oder weiss nicht was, würdest du dort einsteigen und fliegen? Würdest du das machen, dass man wirklich diese Kultur reinbringt, hey, ich bin verantwortlich für diese Qualität. Und das bringt man halt auch nur rein, wenn die ganze Firma diese Kultur hat. Was bedeutet Qualität?
Wir stehen hinter der Qualität und was das bedeutet. Und dann sind dann auch die Leute parat, etwas auf sich zu nehmen, um eben dorthin zu kommen. Und sie werden dann auch selber Vorschläge bringen, was man noch verbessern könnte. Und dann wird das quasi ein Selbstläufer. Aber es ist nicht einfach, dorthin zu kommen. Das ist schon klar. Ja, das ist schön, weil der Überbegriff dieses ganzen Podcasts von Folge 1 war ja, Qualität als Haltung zu leben.
Und das, finde ich, das spielt ja genau in die Karten, genau mit dem Team gemeinsam, diese Haltung, dieses Mindset auch aufzubauen und diese Kultur dann auch mitzuentwickeln. Das, finde ich, passt da sehr schön zusammen. Jetzt habt ihr, also ich kenne das so ein bisschen aus der Medizintechnik, da gab es auch immer so Risikoanalysen. Das waren dann sehr große Excel-Tapeten, wo irgendwas dann da drinnen stand.
Wenn Hochwasser ist, muss da irgendwie oder alles Mögliche, alles, was so passieren kann. Ihr habt ja jetzt auch schon so ein Projekt oder Projekte da mit dem, ihr macht in der Softwareentwicklung. Wie umfangreich ist denn das, wenn ich so ein Jahr mit dem QBD da arbeite? Wie viele Metriken oder, ich sage mal nicht Zeilen im Excel, aber dass wir so eine Vorstellung haben, wie umfangreich das eigentlich immer wird, wenn man sich da so auf den Weg macht.
Weil man kann ja auch nicht mit allem gleichzeitig starten, gehe ich davon aus, sondern man muss ja irgendwo sich das auch erarbeiten. Das ist eine schwierige Frage. Ja, also fangen wir bei der Risikoanalyse an. Die kannst du mehr oder weniger systematisch machen. Da gibt es verschiedene Methoden, die bekannt sind, FMEAs, Fischgrad-Gerät-Analyse. Das kannst du eigentlich beliebig komplex und strukturiert machen. Kannst du das auch informell machen, je nach Grösse vom Team.
Aber eine Transformation dauert halt schon seine Zeit. Also ein, zwei Jahre brauchst du schon, bis die ersten Dinge anfangen zu wirken. Und bei den Metriken, also bei den Messpunkten, solltest du schon darauf achten, so wenig wie möglich zu haben. Wirklich nur an den wirklichen neurologischen Punkten. Ja, wie viel Aufwand ist das? Es ist schwierig zu sagen. Es ist etwas, das dich begleitet.
Du kannst das nicht in drei Monaten quasi einführen, aufbauen, Risikoanalyse machen und so, sondern weil es wirklich ein kultureller Wandel ist, musst du mit den Menschen da durchgehen. Und du fängst dann schon aber überall gleichzeitig an. Oder einfach in kleinen Schritten. Du versuchst zuerst schon bei den Anforderungen oder so, Dinge festzustellen, aber auch schon bei der Qualität der Software.
Vielleicht hast du ein Ticketportal, das du noch gar nicht auswertest und du gar nicht weisst, wie viel kommt denn da zurück und was kommt dann zurück. Und dann fängst du eigentlich überall an, deine Messpunkte einzubauen, die sich dann entwickeln. Und mit der Zeit musst du auch für dich feststellen, dass das, was du dort liest, also diese Zahlen, dass das auch deinen Gefühlen spricht.
Also wenn die Zahlen sagen, hey, das ist eine Katastrophe und du findest, aber es läuft ja wunderbar, dann sind wir nicht dort, wo wir sollten, oder? Ich denke auch, man kann klein anfangen. Und alles fängt eben mit diesem QTPP an, mit diesem Quality-Target-Product-Profile, also mit den User-Anforderungen.
Und wenn man sich dann nachher fragt, was kann schiefgehen, wird es relativ schnell eine Liste von Einflussgrössen geben, wo die Entwickler oder wer auch immer sagt, oh, das könnte dann wirklich schiefgehen. Und dann kann man sich eben die Frage stellen, was bedeutet das? Was bedeutet das für die Entwickler, für die End-User, für das Produkt und für deine Firma? Und dann kommt man relativ schnell auf ein paar Kennzahlen, die man anschauen will.
Aber man fängt halt an, und dann fängt man halt, wenn man nur vier Kennzahlen hat, dann fängt man halt mit denen an. Das Wichtige ist, denke ich, eben nachher, dass man genau diese Metriken anschaut und monitort und dann versucht zu verstehen, was passiert da. Weil wenn man sobald anfängt, diese Daten zu erfassen, wird man auch sehen, dass dort ziemlich Schwankungen drin sind.
Und dann muss der nächste Gedanke sein, diese Schwankungen zu verstehen, diese Variabilität zu verstehen, woher kommt das? Und dann wird man sich überlegen, was sind dann die Einflussgrössen auf diese Kennzahlen? Und so wird man eben mit diesem stetigen Verbesserungs-Mindset, wird man je länger, je mehr oder je länger, je ausgeklügelterer Metriken finden, die dann effektiv zur Steuerung und zum Monitoring der Prozesse sehr wertvoll sind.
Also man muss ja nicht versuchen, von Anfang an einen riesen QBD-Konstrukt bauen zu wollen, das wird gar nicht funktionieren. Also klein anfangen und eben diesen stetigen Verbesserungsprozess triggern. Oder kommt das von alleine? Das ist eigentlich auch das Schöne dabei, weil du kannst relativ rasch sogenannte Quick-Wins einsacken. Weil wenn du mal darüber nachdenkst, dir das mal anschaust, merkst du sofort, ja, wieso machen wir das in drei verschiedenen Tools? Wir könnten es ja in einem machen.
Und dann machst du das und schon bist du besser. Jetzt sagst du ja ganz schön, auch schnelle Quick-Wins zu schaffen. Hast du da vielleicht auch noch ein oder zwei Beispiele? Du hast gesagt, diese Datenmetrik, das hat euch da bei den User-Stories geholfen. Hast du da vielleicht noch was, dass wir da so noch ein Bild haben, was ihr da angepasst habt, wo ihr dann gemerkt habt, das ist dann richtig besser geworden nach einem Jahr oder nach einem halben Jahr?
Ja, ich kann da gleich das Beispiel anknüpfen, das ich vorhin erwähnt hatte. In einer Firma hat man in Jira Stories geprüft, die hat man gesammelt über mehrere Sprints hinweg und dann einmal abgenommen. Und das ist so gelaufen, dass man diese exportiert hat in Excel, in Excel sortiert hat und dass die Leute dann in Excel das eingetragen haben über einen Sharepoint und dann kamen dann die technischen Probleme dazu und so.
Und der Ansatz war dort, dass wir das eigentlich direkt in Jira machen könnten, ohne es zu exportieren. Und dazu haben wir einen Workflow angepasst, wir haben Berechtigungen angepasst. Also das sind schon ein paar hundert Leute, das Projekt. Und das hat eigentlich dazu geführt, dass der ganze, ich sage dir mal, Abnahmeprozess schneller durchlief, die Übersicht schneller da war, also auch die Projektleiter sahen direkt im Jira-Board, was läuft, was läuft nicht.
Und das hat eigentlich dazu geführt, dass die Übersicht und die Planbarkeit der Arbeit besser wurde. Man musste nicht auf einen Export warten. Natürlich gab es bei der Einführung schon Probleme oder Herausforderungen, weil man hat das schon lange gemacht, man muss sich da umstellen, geht Jira wie es sollte und so weiter. Aber letzten Endes ist das Feedback sehr gut. Also die Leute haben das sehr gut akzeptiert und arbeiten heute so.
Da können wir schon sehr viel Zeit sparen, Zeit, die wir anderen Orts dann wieder einsetzen können. Es ist schön, weil das klingt ja total banal, wenn man sagt, ja klar, man hat so einen Excel zu ersetzen, aber ich kenne das ja gerade bei großen Teams, das sind eingespielte Prozesse, die zum Teil auch oft an technischen Sachen scheitern.
Bei dem einen geht der Sharepoint nicht, der dritte hat dann wieder das Problem, dass ich bei Microsoft nicht anmelden kann oder irgendwas ist immer, dass sich diese Dinge verzögern und hier diese Komplexität auch aus dem Prozess rauszuholen und sagen, wir haben ja ein Tool, mit dem kann man das eigentlich gut abwickeln.
Und dann muss man halt einmal dadurch, dass jeder diese Veränderung durchmacht und das darin nutzt, um dann quasi auf einem neuen Level einfach auch dann wieder zu landen und dann besser weiterarbeiten zu können. Du sagst ein gutes Stichwort Komplexität rausnehmen, denn das ist das, was wir oft feststellen. Die Prozesse entwickeln sich und wenn etwas nicht so geht, baut man einfach noch eine Software drauf. Und dann wird es immer, immer, immer schlimmer.
Und dann musst du Daten hin und her schieben und bekommst sie nicht mehr raus und nicht mehr rein. Und das ist schon eigentlich ein Punkt. Letzten Endes versuchen wir, das Ganze so zu reduzieren auf ein Minimum an Werkzeugen, an Abläufen, an Vorschriften, an was auch immer, weil es dann einfach besser durchgeht. Und wenn man halt drin ist, merkst du das oft nicht. Also wenn du selbst zehn Schritte zurückgehen würdest, würdest du selbst auf die Idee kommen.
Aber man ist halt wirklich in der Arbeit und man muss liefern und du hast gar nicht die Zeit, um das anzuschauen, auch wenn du es irgendwo spürst. Ja, verstehe. Thomas, ich habe noch eine Frage an dich. Du kommst ja aus der Pharma-Branche und siehst quasi den ganzen Herstellungsprozess der Medikamente und so. Und jetzt siehst du da so einen Software-Entwicklungsprozess. Jetzt habt ihr da so begonnen.
Wo siehst denn du in diesem ganzen Prozess, wenn du den so von außen betrachtest, so den größten Hebel, da noch besser zu werden? Das ist jetzt eine schwierige Frage. Also ich als Nutzer von Software, ich habe ja das Gefühl, heutzutage mit diesem Continuous Integration, Continuous Deployment, da wird a gogo deployed und keiner kümmert sich darum, was da eigentlich rauskommt. Und nur weil wir heutzutage so viele Rechenpower haben, ist das ja eigentlich nur möglich.
Also die Leute, die müssen sich gar nicht überlegen, was sie da deployen. Sie entwickeln, schmeissen das raus und wenn es nicht funktioniert, wird halt dann ein Bug gefixt oder was auch immer. Aber das geht so schnell. Und der Tester ist ja da im Wesentlichen der End-User. Aber ich als nicht-Software-Mensch, das Gefühl. Und da denke ich mal, wo man halt wirklich sehr viel rausholen könnte, ist, wenn man halt, ohne jemandem zu nahe treten zu wollen, wenn man zuerst denkt und dann entwickelt.
Und das ist ja eben auch dieser QBD-Ansatz, dass man den Prozess anschaut, dass man sich überlegt, mit User-Anforderungen, braucht es das wirklich, was machen wir? Und dann in diesen Prozess reinkommen, dass man halt wirklich nur das entwickelt, was es auch wirklich braucht und zwar so entwickelt, dass es halt dann beim ersten Mal richtig rauskommt. Weil es ist halt schon anders, als in der Barmann, dort ist dieser naturwissenschaftliche Ansatz und hier eher weniger.
Deshalb denke ich hier, dass eben dieser Prozess sich, was können wir besser machen, was brauchen wir, was brauchen wir nicht im Software-Entwicklungsprozess und diese stetige Verbesserung, das Monitoring denke ich, zockt mein Bauchgefühl, kann man sehr viel, sehr viel rausholen. Ich glaube, das ist ein schönes Stichwort, was du sagst, auch diese ganze Automatisierung, die wir in den Prozessen mittlerweile schaffen können, die quasi verleitet ja dazu, das Denken etwas zurückzustellen.
Das ist jetzt total einfach. Ich lasse mir das da ein bisschen von Jettivity was zusammen programmieren oder von Copilot, freue mich darüber und dann geht das in der Pipeline durch die Welt. Dann laufen noch irgendwelche automatisierten Tests, wo ich vielleicht auch gar nicht mehr genau weiss, ob die wirklich noch Fehler finden würden oder nicht. Also da darf man durchaus auch immer wieder kritisch drauf schauen.
Und ich glaube, das ist ja auch ein bisschen in eurem Prozess mit drinnen, die Prozesse auch auch immer wieder zu betrachten und einmal schauen, okay, wo ist denn da so der nächste Pain, den man bearbeiten kann und verbessern kann. Und das ist ja auch dieser Nachhaltigkeitsaspekt. Blinde, die neue Software entwickeln oder in automatisierten Ressourcen verbraten, die es eigentlich nicht. Da habe ich eine Anspruch. Ja, super.
Alessandro, Thomas, vielen lieben Dank für diesen Einblick in diese Transformation von Pharma in die Softwareentwicklung, das Thema Quality by Design mal praktisch auch zu hören. Ich habe das am Anfang ja so schön gesagt, man findet oft in den Konzepten, da gibt es irgendwelche Merkmale. Ich höre jetzt auch immer Nachhaltigkeit wird auch immer mehr in der Softwareentwicklung.
Aber so wirklich, das mal wie kann ich das eigentlich konkret in meinen Prozessen umsetzen und da die Qualität schon frühzeitig einfach drinnen zu haben, um mir nachher dann auch im Testen Aufwände zu sparen und natürlich Fehler zu reduzieren. Das finde ich einen tollen Ansatz dazu. Wir werden eure Kontaktdaten ja auch in den Journals haben. Das heißt, wenn jemand Interesse hat, der wird sich dann auch gerne bei euch melden und euch mit Fragen bombardieren. Sehr gerne.
Das wäre natürlich cool, weil das ja relativ neu ist. Auch ein paar Inputs oder Ideen zu haben. Auf jeden Fall. Dafür ist ja dieser Podcast auch da. Ich danke euch schön, dass ihr euch die Zeit genommen habt und schicke liebe Grüße hier von Essen Richtung Schweiz. Und ich hoffe, wir sehen uns bald wieder. Ja, danke dir. Ja, danke dir. Bis bald. Auf Wiedersehen. Tschüss. Ciao. [Musik]