Dein Projekt läuft aus dem Ruder – Don’t panic!

Podcast Folge 32

Ashley Steel: Taktsoft Campus Podcast! Heute mit Nils Brettschneider, Geschäftsführer der Taktsoft Gmbh. Software Projekte laufen nicht immer nach Plan. Es liegt in der Natur der Sache. Die Frage ist aber, welche Ursachen gibt es dafür, und welche korrigierenden Maßnahmen können getroffen werden? Don´t panic! Mit über 17 Jahre Erfahrungen in der Softwareentwicklung hat Nils ist auch manches Projekt gerettet, erzählt, welche Ursachen das Projekt in eine Schieflage bringen kann und welche Maßnahmen eingeleitet werden können, um das Projekt wieder auf Kurs zu bringen. Und es geht nicht nur um Probleme im Bereich der Technologie. Ich freue mich auf das Gespräch mit ihm, und wie immer, wenn ihr Themen habt, die ihr gerne in einem Podcast beleuchtet haben möchtet: Schick uns eine Email an podcast@taktsoft.com.

Ashley Steel: Hi nils: Hallo, alles gut bei dir, ja, vielen dank, super! Wir wollen uns heute ein bisschen austauschen über das Thema. Ich sag mal so: Projekte, die Schief gehen. Ich meine, du hast 17, 18 Jahre Erfahrung in der Softwareentwicklung, du hast eine Menge Projekte geleiteten, umgesetzt. Ich habe auch viele Erfahrungen in diesem Bereich, und ich glaube, wir beide wissen, es gab immer Projekte, wo es Probleme gab. Das liegt, es liegt auch Natur der Sache. Ja, lassen es mal ein bisschen dazu austauschen, warum solche Sachen passieren können. Wie gesagt, das kann immer passieren, aber für wichtiger ist dann zu sagen: Okay, wer Erfahrung, hast du, Verheerung habe ich, um die Projekte dann, ich nenne, das zu retten. Wie, wie kann man so ein Projekt retten? Ja, vielleicht mal eine erste Frage an dich. Viele Leute denken, okay, wenn ein Projekt schief geht. Es gibt eben eine technologische Probleme. Ich glaube aber, dass Technologie glaube weiß, Technologie ist aber nur ein Thema, was in auch schief gehen kann. Absolut! Was sind erst mal deine Erfahrungen in anderen Bereichen, wo es Probleme geben kann?

Nils Brettschneider: Ja, genau, man denkt ja bei Technologieprojekten. Wenn was schief geht, dann liegt es an der Technologie. Aber, wie du richtig gesagt hast, es sind ganz verschiedene DInge auf ganz verschiedene Ebenen, auf denen Probleme verursacht werden können und das dann auch gelöst werden muss. Natürlich haben wir auch Technologie im engeren Sinne, aber was haben wir darüber hinaus? So die Organisation ums Projekt drum herum, das Team. Wie ist das Ganze aufgestellt? Das führt uns direkt zu People and Prozess, wenn man so will. Also sind die richtigen Leute da am Projekt dabei. Das heißt heißt, die, die da sind, sind die qualifiziert, sind die gut? Genauso, aber auch fehlt vielleicht jemand, eine wichtige Person, eine wichtige Entscheider. Wie sind die Prozesse? Sind die eingespielt? Und wenn wir da noch eine Ebene höher gehen, dann sind wir beim Management. Wie ist das Projekt Produkt überhaupt aufgestellt worden? Ist das Funding gut? Ausreichend? Zumindest. Also. Es gibt, glaube ich, ganz viele verschiedene Richtungen, aus denen so ein Projekt gut oder schlecht werden kann oder zumindest vor Probleme gestellt werden kann.

Ashley Steel: Genau, und ich glaube, es gibt einen Punkt, auch wenn die Sachen, die man nicht kennt, die passieren können. Da kommen ganze zum Schluss, manchmal Überraschungen, auch wenn man sich alles dann. Lass uns mal versuchen, das ein bisschen strukturiert durchzugehen. Du hattest das Thema Management mal angesprochen. So, jetzt nehmen wir die Technologie komplett, komplett beiseite. Es geht darum, wenn ein Projekt aufgesetzt wird, dass es Ziele geben soll: Okay, was will ich mit diesem Projekt erreichen? Eins, eine Sache, was ich dann erfahren habe oder erlebt habe: Okay, es wird ein Produkt oder ein Programm haben definiert, aber dann kommen Produktmanager, Management und sagen, aber ich will dies, ich will das, das sogenannte Scope creep, dass das von einem ein definiertes Ziel, das ist immer größer wird. Hast du sowas auch erlebt, und wie kann man mit sowas dann umgehen?

Nils Brettschneider: Ja, im Grunde kenne ich das auf jeder Ebene. Das kann das gesamte Projekt betreffen, was irgendwie immer mehr leisten soll. Das kann aber auch irgendwie das kleinste Feature oder die Komponente betreffen. Wenn wir so an software Oberflächen denken, und man baut da so Komponenten, dann soll sie noch das können und das können und hier noch konfigurierbar sein und das noch können, und schon wird das ganze dann doch ein bisschen überladen und komplex. Das heißt, eine wichtige Funktion von Produktmanagement ist aus meiner Sicht, die Dinge zu ordnen und auf das mögliche Minimum zu beschränken, wenn man so will, das eben, was ausreicht, um die Ziele zu erreichen, und da kommen wir schon so ins relative rein, dass zu viele Ziele, zu viele Anforderungen und Ansprüche bereiten ein Projekt Schwierigkeiten. Also muss man auf der Ebene eigentlich klären, was wollen wir denn erreichen, und was ist wichtiger und was ist weniger wichtig, und was lassen wir vielleicht auch aus diesem Scope raus?

Ashley Steel: Genau, und ich sag mal so das Thema MVP - minimal viable Product, im Produkt, dass man wirklich sagt, okay, das ist, was ich definiere, ich fokussiere darauf als erstes, und dann baut das nach und nach auf. Ja!

Nils Brettschneider: Genau, wobei natürlich dann im Verlauf so ein Produkt ja auch ausgebaut wird und durchaus komplexer werden soll und mehr Features bekommen soll. Aber selbst dann, wenn man im Grunde ja nicht mehr von minimal viable product spricht, sondern von einem reifen Produkt, habe ich ja immer wieder die Frage, kommt das jetzt dann noch mit rein? Bilden wir das im Produkt ab, oder machen wir das vielleicht irgendwo anders? Gehört das irgendwo anders rein? Diese Entscheidungen sind wichtig, weil genau immer, wenn ich natürlich irgendwie so eine Software hab, die wie so ein schweizer Taschenmesser ist, dann möchte ich vielleicht oder das Bild von von, dass ich davon habe, so Richtung schweizer Taschenmesser geht. Dann möchte ich damit alles machen. Aber das ist nicht unbedingt immer sinnvoll.

Ashley Steel: Genau, und ich denke da, das wichtigste ist diese enge Kooperation zwischen product management, Programm Management und Entwicklung, Produktmanagement, dass sie wirklich definieren können, genau was du sagst. Okay, was will ich genau immer ein Produkt haben, aber das zum Anfang auch die Entwickler oder die Architekten Entwickler mit einbezogen werden, so dass man sehen kann, okay, ist das dann wirklich technisch machbar? Und wenn es technisch machbar ist, wie komplex ist das ja, dass es wirklich diese zum Anfang wirklich eine Dialog gibt zwischen Entwicklung und Produktmanagement und nicht nur Produkt Management alleine, um das, um diese Definition des Funktions oder Funktionen zu machen, würdest du das dann auch?

Nils Brettschneider: Das würde ich so unterschreiben. Ich würde auch sagen, nicht nur am Anfang, sondern im besten Falle findet das ja laufend statt, wobei natürlich klar ist, dass Entscheider, die weiter weg von der eigentlichen Entwicklung sind, jetzt nicht ständig involviert werden können oder wollen. Aber das dann regelmäßig irgendwie ja rückzuspiegeln und zu überprüfen, ist, glaube ich, ziemlich essenziell, weil wir haben ja gelernt: Stichwort agile Entwicklung et cetera, das ist ein moving target. Wir müssen uns anpassen, das funktioniert auch. Wir lernen ständig im Rahmen der Entwicklung eines solchen Produkts etwas dazu. Und genau wenn sich diese Learnings dann nicht auch zu den anderen Ebenen durch propagieren, dann kommt es natürlich zu Konflikten, weil die Erwartungshaltung vielleicht auseinander laufen. Die einen haben schon was gelernt, haben gesehen, das funktioniert an der Stelle so nicht oder haben auch tolle neue Möglichkeiten aufgetan. Man ist aber irgendwie bei der Projektsteuerung und bei Entscheidern auf einer anderen Ebene vielleicht noch nicht so weit, hat das noch nicht gesehen, noch nicht wahrgenommen, und schon läuft man zumindest gefahr, aneinander vorbeizureden.

Ashley Steel: Genau und genau im Umfeld oder im Safe Umfeld die Zeremonien zum Ende des Sprints, dass etwas präsentiert wird, dass der Produktmanager das auch sieht, dass es eine Retrospektive gibt, sodass man die die die die dem allen Dingen genau genau andere Punkt. Was ich so miterlebt habe, ist die Abhängigkeiten zu anderen andere Organisationseinheiten klar. Es gibt dann so eine Entwicklungsmannschaft, aber die sind vielleicht abhängig von irgendwelche andere bereiche, die Cloudspeicher, Cloud computing, Plattformen und so weiter zu verfügen stellen. Ich denke auch da. Diese Abhängigkeiten will es immer geben, und ich denke auch da, um um potenzielle Probleme zu vermeiden, dass es auch zum Anfang und ständig während des Projektes auch den Austausch mit diesen anderen Einheiten gibt. Absolut!

Nils Brettschneider: Kann ich auch nur zustimmen. Genau es können verschiedene Abteilungen sein, die irgendwie Ressourcen zur Verfügung stellen sollen oder die irgendwie Abhängigkeiten auflösen können. Das kann aber auch einfach eine andere Software sein. Hinstelle, das erleben wir doch relativ häufig. Auch wenn man das gut auflöst, macht ein, dass es einfach etwas langsamer. Wenn man mit zwei verschiedenen Unternehmen über eine Schnittstelle sich und unterhalten muss über Datenformate, die darüber ausgetauscht werden, dann führt das dazu, wenn man auch da wieder etwas lernt. Wenn man merkt, wie intern sozusagen unterschiedlich das eine gleiche verarbeitet wird und wie man das miteinander harmonisieren kann, dann kostet das einfach Zeit, und die fehlt einem dann vielleicht an anderer Stelle, oder diese Zeit war nicht eingeplant, ist aber auch schwer, das zu antizipieren. Das sind genau solche Dinge, die ja ich auch nicht immer unbedingt immer zu einem Scheitern insgesamt führen, aber die dann eben wieder so eine Schwierigkeit und Hürde sind und die auch schwer zu kommunizieren sind, weil daraus natürlich nach Möglichkeit nicht so ein Fingerpointing entstehen sollte. Ja, die andern, dann sind schuld, die haben nicht geliefert, die haben nicht klar definiert. Das ist immer einfach gesagt, um meistens auch nicht die ganze Wahrheit da, also erstens Leute zu haben, die ein Bewusstsein dafür haben, dass das gut abgestimmt sein muss, dass man mit einem gewissen Vorlauf auch etwas vorbereitend präparieren muss, ehe man dann daran geht, dann diese timings abzustimmen, vielleicht in zwei unterschiedlichen Organisationseinheiten oder sogar Organisationen. Das ist schon nicht so ganz einfach und macht wiederum so gutes Produkt und Projektmanagement aus.

Ashley Steel: Genau, und ich glaube, der Kern von diesen Punkten, was wir gerade besprochen haben, ist diese enge, enge Abstimmung und regelmäßige Abstimmung. Das ist, das, ist wirklich das, das an.

Nils Brettschneider: Genau, und dafür muss man ja auch den Rahmen überhaupt eingeräumt bekommen. Wenn man halt jetzt sehr wenig Zeit hat, dann wird es schwierig, diese Abstimmung dann gut zu machen, und wenn man da zum Beispiel auch nur auf einer Seite sehr darauf gucken muss, die einen wollen ausführlich besprechen, die anderen haben irgendwie ein Rahmengesetz bekommen, in dem, den sie gerade mal Zeit haben, dann die eigentliche Entwicklungsarbeit oder Bereitstellung zu erledigen, aber sich nicht vernünftig dazu abzustimmen, schon, dann kannst ja zu Problemen kommen. Also das ist auch nicht so einfach zu planen, muss man ganz klar sagen und braucht, glaube ich, Erfahrung auf beiden Seiten und Menschen, die dann eben auch in der Lage sind, allen Beteiligten zu kommunizieren, was notwendig ist, welcher Zeitraum und wie schnell das ganze dann auch gehen kann. Weil nur dann geht es ja am Ende schnell, denn wenn ich da irgendwie Fehler mache, aneinander Vorbeirede, Unklarheiten nicht ausräumen, dann dauert es eigentlich immer länger.

Ashley Steel: Genau du hattest das Thema oder den. Den Stichpunkt. Fingerpointing war mal kurz erwähnt, wenn wir jetzt mal ein bisschen auf und Prozessen schauen. Ich habe es erlebt in einem Projekt, wo es ein Konflikt gab. Ja, du bist schuld, du bist schuld! Dass. Es ging darum, Entwicklung und Test, dass das dann nicht nicht abgestimmt waren, die waren, die waren nicht nicht bezahlt. Und wenn es, wenn es dieses Fingerpointing gibt, heißt es für mich, es gibt kein wir Gefühl. Ja, es gibt nicht das Gefühl. Insgesamt sind wir eine Mannschaft, Testing, Entwicklung, der Kunde, auch alle diese verschiedenen Elemente, die man braucht in einem Projekt, und wenn dieses wir Gefühl fehlt, habe ich erfahren, dass es dann Probleme gibt, und es gab verschiedene Zeiten, wo wir dann versucht haben mit cross team, training, team events und so weiter. Wir haben wirklich versucht, aus verschiedenen Einheiten eine Mannschaft, ein Team zu machen, um diese, um dieses Gefühl zu bekommen. Meine Erfahrung da war, dass, wenn man dieses wir Gefühl schafft, dass die Projekte viel, viel besser laufen. Ich weiß nicht, ob du Sowas auch erlebt hast.

Nils Brettschneider: Ja, also, wir achten da bei unseren eigenen Teams auf jeden Fall auch sehr drauf. Haben sie den Anspruch, immer viel sorgfalt bei dieser Teamzusammenstellung walten zu lassen? Jetzt arbeiten die bei uns sehr kontinuierlich zusammen. Deswegen gibt es da bei den eigenen Teams meistens keine so großen Probleme. Allerdings, und da ich die größere Herausforderung, möchte man ja über so ein Gesamtvorhaben hinweg eigentlich so ein wir Gefühl haben, also ganz verschiedene Leute aus verschiedenen Unternehmen zusammenbringen, die dann manchmal notwendigerweise auch nicht mit dem gleichen Zeitbudget oder mit Vollzeit eben oder mit viel Zeit auf dem Projekt arbeiten, aber die trotzdem wichtig sind und irgendwie in dieses wir hineingehören. Und ja, das ist eine Herausforderung, kann man natürlich trotzdem adress sieren. Manchmal braucht es eine gute Auftaktveranstaltung, gute Moderation, das Einbinden, das Einladen und das dann auch auf verschiedenen Ebenen. Das Fachliche muss erst mal klappen, aber auch, dass man das Menschliche, eben so ein bisschen das Kennenlernen der verschiedenen Leute nicht ganz vergisst. Auch wenn wenig Zeit ist, versucht man doch immer aufzuzeigen, dass da Menschen miteinander arbeiten und dass die einfach ein Interesse aneinander haben und haben sollten, und wenn das gelingt, dann reduzieren sie sich, glaube ich, Probleme in dem Bereich absolut.

Ashley Steel: Ja, absolut, und dass man der Kunde, der Endkunde auch mit einbezieht, das heißt, für wen entwickle ich jetzt, ich sag mal so, dieses Stück software? Dass der Endkunde auch Teil des Teams ist, was wir vorhin gesagt haben, dass das es die verschiedene Zeremonien gibt, sind damals zum Beispiel, dass das Produktmanager, aber auch der Endkunde dann wirklich mit allem bezogen werden in so in so ein Team, das das, das das Team dann das Gefühl hat, okay, ich kann offen mit meinem Kunden reden und offen über Probleme, über über eigenschaften Features und so weiter sprechen und nicht der Endkunde ausblenden. Der ist genauso wichtig in so einen Dialog aus als die anderen Leute im Projekt.

Nils Brettschneider: Und bei den meisten Softwareprojekten gibt es ja auch, wenn man so will, verschiedene Arten von Kunden. Es ist gerade von Kunden gesprochen. Das wären für mich auch die Nutzer letztendlich der Software. Ich habe aber, zumindest in unserem Kontext ist es ja typisch, dass man Unternehmenssoftware herstellt, die von er nachher bedient wird. Die Nutzer sind aber nicht die Kunden im Sinne von Auftraggeber, und dann muss ich natürlich auch immer beiden gerecht werden. Für den Endnutzer in diesem Sinne, für den Endkunden, gibt es natürlich die ganze Disziplin user experience und user experience design, also Menschen, die sich ja am besten systematisch damit auseinandersetzen und auch die Zeit bekommen, eben mit Nutzern zu arbeiten. Und genau für die anderen ist das natürlich primär das Produkt und Projektmanagement zuständig. Aber schon, diesen Dreisprung irgendwie so hinzubekommen, dass das Team ist an Bord, der Auftraggeber, wie auch immer sich das ausnimmt, der Weiß Bescheid ist, gut informiert, ist mit an Bord, und der eigentliche Nutzer, sei es ein Konsument oder eben in einem Unternehmen der Software, der wurde auch berücksichtigt und eingebunden. Das ist natürlich der Optimalfall und sollte so sein. Die Frage ist eben immer, in welchem Rahmen kann ich das machen, und wie wichtig ist das ganze natürlich auch genau.

Ashley Steel: Ja, genau, wir haben über Management gesprochen, über eben Prozessen. Aber es gibt doch das Thema Technologie. Es können auch Probleme im Bereich der Technologie sein. Falsche Technologie wird ausgewählt, man macht nicht rechtzeitig Performance oder oder Lasttest, und man hat dann hinterher Probleme mit Skalierbarkeit, oder das? Oder nein? Ich will nicht ein Stück oben so Software nehmen, weil ich habe es nicht geschrieben. Sag deinen Entwickler, und ich würde es selbst schreiben, hast du sowas auch erlebt, dass das auch diese mir sicher, dass du sowas erlebt hast, dass es diese technologische Probleme gibt, ohne Probleme mit Technologie, und wie kann man dann auch damit umgehen? Ich denke auch zum Beispiel, dass man rechtzeitig sagt: Okay, ich mache ein Spi in einem Sprint. Ich habe eine Idee, ich habe eine Technologie, Technologie angeschaut. Ich glaube, es könnte gut für das Projekt sein, dass man wirklich sagt: Okay, in einem Sprint werden wir einen wirken, zu schauen, ist diese Technologie oder dieses Stück Software das richtige zu benutzen, ja oder oder nein? Hast du Erfahrungen mit solchen technologischen Aspekten in Projekten oder im Bereich, wo es dann schief gehen kann mit der Technologie?

Nils Brettschneider: Hm!

Ashley Steel: Ja.

Nils Brettschneider: Ja, auch das findet im Grunde in jeder Hinsicht statt oder kann stattfinden. Es gibt so die, glaube ich, eher simplen Dinge, die aber häufig schwerwiegend sind. Wenn man tatsächlich die nachher objektiv gesehen falsche Technologie auswählt, haben wir auch schon erlebt, dass gerade im Bereich Softwareentwicklung entwickelt sich vieles schnell weiter. Das heißt, natürlich haben gute Leute auch immer den Anspruch, da moderne Ansätze zu wählen, und schon leider dann Frameworks eingesetzt, bei denen sie im Laufe der Entwicklung herausgestellt hat. Die hatten jetzt nicht so die Reife, die man sich vorgestellt hat, und wenn man dann im Grunde mit dem Framework oder mit der Libor oder was man auch immer da ausgewählt hat, dann kämpft, die ist nicht reif. Die Leute, die Herstellen sind vielleicht auch enthusiastisch, wollen helfen, aber man merkt, das ist eben nicht auf der Produktionsreife, auf der man sich das vorstellt. Dann hat man da schon ein Problem. Das kann man natürlich auch wieder durch gute Auswahl, Planung, Erfahrung und ähnliches ausgleichen. Das wird einem aber vielleicht manchmal passieren, und da muss man natürlich das Problem lösen. Dann steckt da aber drin, ich sage ja schon, gute Leute möchten auch mit modernen Technologien arbeiten. Gute Leute haben auch bestimmte Vorstellungen, wie sie technische Lösungen umsetzen wollen, und genau diese Ideen und Vorstellungen, die braucht man letztendlich. Man möchte ja jemanden, der Verantwortung übernimmt, der ein gutes software design sich überlegt, der über Software Architektur nachdenkt, und das hat eben so die andere Seite, dass da auch manchmal Menschen sind, die eben so ihre eigene Idee durchdrücken wollen, und zum Teil ist das eben sehr positiv zu sehen, weil das einfach die andere Seite von Verantwortung ist. Wenn ich Verantwortung übernehme, dann muss ich eben auch gestalten können auf der anderen Seite, wenn man eben dabei wenig kompromissbereit ist und nicht die verschiedenen Folgen und Aspekte der eigenen Technologie weil sieht, dann ist es vielleicht wieder ein bisschen problematisch, und so führt man da manchmal, ähm ja, Diskussionen, die ans Eingemachte gehen, und ich glaube, die müssen dann auch geführt werden, wenn jemand da eine Idee hat, dass etwas nur auf eine bestimmte Art umgesetzt werden kann und sollte. Dem ist aber nicht so, dann muss man sich damit wohl auseinandersetzen. Ja, aber irgendwann kommt der Punkt, wo man natürlich jemandem auch das Vertrauen geben muss, diese Wahl zu treffen und auch diese Verantwortung zu übernehmen und das zu leben, und dann funktioniert das Ganze, glaube ich, gut.

Ashley Steel: Ja, ich denke auch das Thema best practice, best practice ist auch eine gute Idee, dass man wirklich in verschiedenen Foren mal austauscht und offen die Erfahrungen erzählt: Okay, ich habe dieses Produkt oder dieses Platform oder Framo, wie du gesagt hattest, ausgewählt, und das sind wirklich die, die wir gemacht haben, dass man das Architekten beziehungsweise Entwickler lernen können, von anderen Leuten lernen, im positiven sind: Okay, das ist gut gelaufen, oder lernen auch im positiven Sinn, aber wo jemand dann sagt: Okay, aber das ist dann doch nicht so gut gelaufen mit Forke oder framwork For a genau.

Nils Brettschneider: Und dann ist es auch Technologieverwendung, was wir schon übernommen haben. Wir machen ja relativ viel mit Rob und Rob und Reals, und einzelne Projekte, die wir übernommen haben, da merkte man eben eben an, man hat gar nicht verstanden, wie dieses Framework eigentlich funktioniert und wie damit entwickelt werden sollte. Das wurde irgendwie anders angegangen, vielleicht auch aus einem anderen Erfahrungshorizont heraus, und das ist dann natürlich ganz schwierig, wenn man irgendwie so an der Idee hinter der Technologie auch vorbei arbeitet. Auch die bringt ja so ein bisschen Prinzipien und Verfahren mit, und wenn das irgendwie einfach zurecht gedengelt wird, dann ist das natürlich ganz schräg. Von daher also: Technologie, da könnte man wahrscheinlich noch mal einen eigenen Podcast draus machen, dann kann der schon falsch gelaufen ist. Da gibt es eigentlich auch eher die schönsten Geschichten, weil da kracht es manchmal gehörig. Aber genau eigentlich, wenn man das gut aufstellt, sind diese Dinge zu vermeiden und auch zu retten, und es hat irgendwie immer einen Grund, warum sowas passiert.

Ashley Steel: Genau genau, man denkt viel über in so einem Projekt, über die Entwicklung und Produktmanagement und so weiter. Dann kommt das Thema Testing. Ist auch meine Erfahrung, dass leider teilweise das ganze Testing nicht so, damit nicht so eine Priorität gesehen wird: Ach, wir testen mal eben schnell, auf gut deutsch gesagt, und vielleicht, dass das Testing nicht die Realität oder nicht. Du hattest vorhin gesagt, wir haben den Endnutzer, dass jemand testet, aber testet nicht, wie der Endnutzer wirklich so ein Stück Software oder eine Plattform benutzen werde, würde ja meine Erfahrung. Da ist auch Thema, wo wir gesagt haben, das Thema. Wir Gefühl, die verschiedene Einheiten nenne ich die, die Einheiten im Themen. Ein wichtig, wichtig, wichtiges Element ist das Thema Testing oder die Tests, dass die rechtzeitig eingebunden werden, wirklich zum Anfang des Projektes eingebunden werden und nicht: Naja, Okay, Testing, denken wir später drüber nach, aber das ganze Thema Test, Testkonzept, Testdurchführung, Einbindung von dem Kunden, Sachen nutze, dass das auch mit einer sehr, sehr hohe, hohe Pritt angesehen werden sollte. Ist das auch deine Erfahrung?

Nils Brettschneider: Hm ja, vor allem, dass es häufig nicht die Priorität hat, die es eigentlich verdient, ist es so, dass wir sehr viel automatisierte testen, also Entwickler, test man uns relativ viel. Die Herausforderungen sind dann immer zwischen bisher zurecht nochmal auf sozusagen das Einbinden von den verschiedenen Stakeholdern bei der Anforderung zurückgekommen, und dann schließt sich ja beim Testing letztendlich der Kreis, weil die auch da wieder eingebunden werden müssen und sich manchmal auch erst darüber im Plan sein müssen, dass sie da eine ganz wichtige und besondere Rolle spielen, nicht nur, weil sie natürlich mit dem Ergebnis zufrieden sein sollen, sondern weil sie das auch anders benutzen, anders angehen, vielleicht andere Arten von Testdaten mitbringen, die eben auf ihre Realität abstellen, und dann kann man manchmal noch ganz interessante Dinge generieren, die man so vorher und Erkenntnisse gewinnen, die man so vor gar nicht absehen konnte. Von daher ist das auf jeden Fall wichtig, und da sind wir wieder bei dem Anfang: Management und Planung. Diejenigen müssen auch genug Zeit in im Gesamtprojekt zur Verfügung haben, um so etwas eben zu tun. Dann wird das ganze auch rund und gut, sonst wird man das mit back Meldung im Verlauf vielleicht dann eher behandeln müssen, und das ist ja für alle unschön. Dann unterhält man sich darüber. Ist, ist wirklich eine Fehlfunktion, wurde es nicht richtig abgenommen? Wurde es nicht richtig getestet? Wer war denn eigentlich verantwortlich dafür, dass du testen? Und man merkt, ganz vorne ist das Kind in den Brunnen gefallen. Wieso meistens? Ich glaube auch bei den meisten Fehlschlägen, die es so gibt. Da wird eigentlich immer sehr früh der Fehler gemacht, und hinten muss man das dann manchmal auslöffeln oder eben ausbaden.

Ashley Steel: Genau, und du hast das Thema angesprochen, wird es immer geben. Das liegt auch in der Natur der Sache, aber meine Erfahrung auch da ist okay, wenn du gefunden werden, die sollen nicht versteckt werden oder das Team soll sagen, wir haben dieses gefunden, egal jetzt, warum dieses. Es ist gefunden und dann wirklich eine enge Diskussion oder Unterhaltung mit dem Produktmanagement zu haben. Okay, Superity, wie schwer ist dieses? Ist es ein? Muss es jetzt wirklich gefixt werden? Können wir das später machen? So wirklich einen Dialog dazu machen, um zu verstehen, okay, muss ich sich dieses, dieses bieten und vor allen Dingen in jedem Sprint wirklich Zeit einplanen, um diese Technik da die Fix ist, dann wirklich wirklich, dass die Mannschaft Zeit hat, neben den Neuentwicklungen, dass die Mannschaft Zeit hat, um diese zu beheben und neu zu testen?

Nils Brettschneider: Genau wenn sich das immer weiter aufbaut, dann hat man natürlich ein Problem. Bei bist dann natürlich auch immer die Frage, wie schlimm sind sie erst mal, und insofern kann eine Meldung ja auch erst mal gar kein schlechtes Zeichen sein. Wenn ich nämlich gar keine davon habe, dann war ich vielleicht auch ein bisschen zu langsam in der Entwicklung. Wenn das natürlich Fehler sind, die irgendwie Schaden verursachen oder irgendwie ganz unschöne Seiteneffekte haben, dann ist es trotzdem zu vermeiden. Aber auch da brauche ich ja irgendwie erst mal eine Linie und Verständnis. Ich weiß nicht, wie das bei dir aussieht, bei manchen oder so von den Erfahrungen in den Projekten, in denen du warst. Wir stellen jetzt keine Software her, die, sagen wir mal, Menschenleben direkt gefährden könnte. Wir haben natürlich immer das Potenzial von wirtschaftlichen Schäden, aber ich denke, da muss man gut drüber nachdenken, und bei wirtschaftlichen Geschichten kann muss man natürlich abwägen, test sich das alles noch ein bisschen es besser und bin dafür langsamer. Oder genau mache ich das bis zu einem gewissen Level und ziehe dann dinge auch später noch mal nach, in bewusster Abwägung, dass ich dadurch schneller bin und dass die bessere Rechnung ist, sozusagen.

Ashley Steel: Hm, wobei ich glaube, das ist dann auch ein Dialog, was, was passieren muss zwischen Management, Produktmanagement, Architekten und Entwicklung, genau das, was du gesagt hast: Okay, wir können das so machen, oder wir können das so machen. Das sind die Vorteile, das sind die Nachteile, und und das ist wirklich ein Dialog gibt zu entscheiden: Okay, dann sind wir doch vielleicht ein bisschen schneller. Wir wissen, dass wir haben werden, wir planen aber die Kapazität, um diese zu beheben, aber wir wissen, dass das die passieren können. Jetzt zum Glück habe ich auch nie in einem Projekt gearbeitet, wo irgendwas Menschenleben gefährdet werden könnten. Durch das muss man halt ganz anders testen, aber zumindest dann muss man wirklich, da muss man wirklich wirklich an das testen. Ja, das glaube ich auch.

Nils Brettschneider: Aber du hast auch im Telko Umfeld gearbeitet. Da hat man ja dann teilweise, was die schon auch 100000 Menschen beeinflussen, und allein auch dieses Verständnis gemeinsam zu schaffen. Wie viele Menschen sehen da nachher dieses Feature, und wie relevant ist das? Wenn es eine neue Produktentwicklung in Ation ist, dann ist Geschwindigkeit vielleicht ein bisschen wichtiger. Wenn man Tagesgeschäfts Feather für 100000 Nutzer ausrollt, dann liegen da die Präferenzen ein bisschen anders bei Eilen, und das muss man ja verstehen auf allen Ebenen, und daran besteht auch so ein bisschen wieder die Herausforderung. Ich kann natürlich ein Testkonzept haben und auch aufschreiben und kommunizieren und leben, aber ich muss irgendwie auch verschiedene Gänge schalten können, wenn man so will. Manchmal muss ich vielleicht da etwas sorgfältiger und umsichtiger noch sein als im Normalfall, und dann muss ich das wissen. An welchen Stellen betrifft das vielleicht mehr Nutzer? Wo kann der Impact größer sein? Wo ist das wichtig? Und da sind wir wieder beim Klassiker Kommunikation, die ist.

Ashley Steel: Extrem wurde das Thema Testing sehr hoch angesiedelt, genau aus dem Grund, weil es gab einen Riesen Kundenstamm, wie du sagtest. Man macht nicht für zehn Nutzer oder oder 100 Nutzer, sondern 100000 von nutzen, wenn es dann Probleme in der Produktion gab. Es ist auch mal passiert, aber dass es eine Auswirkung und ein Riesenproblem, um dann ein Buch zu machen oder schneller ein Abi zu machen, und daher wurde das Thema Testing immer wirklich hoch angesehen.

Nils Brettschneider: Und und auch hier kann ich wieder so einen Rückgriff noch auf das Thema Planung machen. Im besten Fall unterscheidet man ja so ein bisschen Bild und wann auch auf Budget Ebene bei Software, und gerne wird dann eben viel in das Aufbauen, in Features und Wachstum und Änderungen und Anpassungen, die auch manchmal notwendig gesetzlich getrieben sein können, und so weiter, vergisst aber so ein bisschen eben, das Budget in das Aufrechterhalten, das Betreuen und sowas zu stecken und das nur zu planen, weil natürlich möchte man immer gerne noch ein bisschen mehr, aber das aufrechterhalten, das wird dann unterschätzt, also auch wieder auf Planungsebene, dann gut oder schlechter aufgestellt zum Projekt.

Ashley Steel: Und ich denke auch, egal wie gut man planen kann, es gibt immer, ich nenne das die anderen. Wenn wir mal zurückblicken über den letzten Jahre mit Corona, Pandemic, wo keiner wusste, dass es kommen würde, hat eine Riesenauswirkung, oder wenn wir jetzt mal schauen Richtung Ukraine, wo es dann viele, viele Software, gute Software Ressourcen gibt. Es können immer Sachen passieren, die man nicht vorhersehen kann, oder durch Krank, Krankheit eines bestimmten Mitarbeiters, des Schlüssel im Themen. Das sind auch Sachen. Ich denke, wo man einfach offen sein muss, sagen: Okay, sowas kann passieren, man kann sowas, kann sowas nicht planen. Aber wenn sowas passiert, dass dann man sagt: Okay, rechtzeitig, Okay, lass uns mal als Team drüber nachdenken. Okay, wie können wir von je nachdem dann, was nun passiert? Hast du auch so erlebt, dass vielleicht ein Mitarbeiter dann durch krank ausgefallen ist oder das Unternehmen verlassen hat? Gibt es irgendwelche Erfahrungen, die ich sage? Es ist schwer, vorab dafür zu planen, aber gibt es irgendwelche contingency plans, die man dann nutzen kann, um um ein bisschen Schutz aufzubauen?

Nils Brettschneider: Ja, ich glaube, vor so einer Pandemie oder Kriegssituation, die ganz von außen kommt, das ist natürlich irgendwie unabsehbar und fast nicht einzuplanen. Da braucht man an sich irgendwie ein gewisses Maß an Stabilität und Resilienz bei den Menschen, aber auch bei den Organisationen und Unternehmen. Ich denke, das ist das, was man da tun kann, und für alles andere braucht man, denke ich, auch Erfahrungswerte, die dann wieder in die Planung einfließen, dass man nicht manche Dinge nicht zu sehr auf Kante plant, weil dann eben die kleinste Unwegbarkeit alles zusammenbrechen lässt, auch ja allein so ein cost funktionales Team mit Menschen, die sich da natürlich ergänzen sollen, aber die auch eine genügend große Schnittmenge bei ihnen Fähigkeiten haben, das kann schon für viel Stabilität sorgen, weil ich nicht an einer Person hängen oder nicht an jeder Person einzeln hängen, so dass sozusagen jeder Ausfall, der ja irgendwie statistisch gesehen, wenn man so will, irgendwann kommen wird, mich da total aus der Bahn wirft, sondern dass es aufgefangen werden kann, vielleicht nicht von der Kapazität, von dem, was ich schaffe, aber zumindest vom Nowhow her, sodass ich keinen Stillstand habe.

Ashley Steel: Genau genau ja, wie wir gesehen haben. Projekt kann aus verschiedenen Gründen schief gehen, sprechen, aber es kann auch gerettet werden, wie wir gesagt haben. Zum Anfang: Thema Management, enge Kooperation zwischen Product management, Management und Entwicklung werden im Bereich und im Personenbereich, dass man wirklich versucht, ein ein wer Gefühl im Team, Aufbau und Technologie, klar, Technologie spielt immer eine Rolle, aber auch diese Offenheit zu haben, zu sagen, okay, wir probieren etwas aus, wir schauen uns mal an, best practice anzugucken, dann, was haben die anderen Leute mit Technologien gemacht? Testing war ein sehr großes Punkt, wo wir gesprochen haben. Einbeziehung des Kunden beziehungsweise Endnutzer rechtzeitig in dem Projekt und zum Schluss, wie du sagst, es ist das andere. Ja, man muss ein bisschen Continue dafür einplanen, dass man das machen kann. Das hast du doch schön zusammengefasst. Wunderbar! Danke, danke wirklich für Beraten. Aber ich glaube, dass das wichtigste ist, dass man die Offenheit hat, im Team mit Management über diese Themen zu reden. Dass nichts versteckt wird ist. Die werden nicht versteckt, die werden, man redet offen drüber. Ich glaube, das ist das wichtige Kommunikation, wie du es sagst.

Nils Brettschneider: Munikation, und ich glaube, noch, als Voraussetzung, vertrauen, das ist das noch wichtiger, kommunizieren muss ich natürlich tun und auch können, aber ohne Vertrauen geht nichts, und das betrifft alle Ebenen. Wenn die Auftraggeber, Sponsoren, wie auch immer man sie nennt, wenn die nicht das Vertrauen haben, dass aus den zur Verfügung gestellten Mitteln was Gutes entsteht, dann wird es schwierig, wenn im Team kein Vertrauen ist oder zu denjenigen, die Zuarbeiten zu der technologischen Plattform, der Basis also. Vertrauen ist, glaube ich, die Basis ja.

Ashley Steel: Genau ist es wichtig. Super, Nils vielen Dank für deine Zeit. War ein sehr, sehr interessanten Austausch. Ich danke dir, war spannend. Ich sage mal so, bis die Tage, machst gut.

Ashley Steel: Taktsoft Campus Podcast, der Podcast Software und it professionals. Im Taktsoft Campus Podcast beschäftigen wir uns mit einem breiten Themenspektrum, um euch zu helfen. Praxis fragen zu Technologie, aber genauso fragen zur Umsetzung, Prozessen oder Projektorganisation. Danke, dass ihr dabei wart, euer Podcast Team.