Moin und herzlich willkommen zur Folge 99 von einfach komplex heute. Das Thema Requirements Engineering mit Doktor Svenja Schröder von der MSG Plaut. Hallo Svenja. Hallo Gerrit, Hallo Burkhard, Oh mein Gott, direkt mit Doktor TÖ freue mich hier zu sein. Freue mich über das Thema zu reden. Ja, schön, dass du da bist. Nicht die einzige Doktorin, also die einzige Doktorin. Aber wenn wir noch n Doktor bei uns ja den Burkhard, Hallo Burkhard und der steht auch.
Neuen Geräte? Ja, die können wir mal weglassen, das dauert uns immer so lange, aber manchmal ist es ganz schön, ne gehört ja irgendwie dazu und man hat tatsächlich auch n bisschen gearbeitet dafür. Ja ja, könnt ihr euch ruhig, könnt ihr auch n bisschen stolz drauf sein, so ne also. Ich kann das ja sagen, ärztlich Doktor. Wir haben den Persönlichkeitstest bestanden, Burkhard. OK, also. Dann lass uns doch in unser
Thema vom Tag starten oder? Beziehungsweise vielleicht Svenja, magst du ein bisschen erzählen, was du schon gemacht hast, wie du dahin gekommen bist und warum du jetzt auch eine gute Ansprechpartnerin und Expertin einfach für das Thema
bist? Mhm, ja, vielen Dank. Vielleicht erst mal vorweg für die Hörerinnen und Hörer, ich hab Gerrit und Burkhard angeschrieben, weil ich fand das Thema Requirements Engineering war unterrepräsentiert und es zeigt sich gerade heute in der Zeit wo wir so in Richtung Nearshoring und Offshoring auch nachdenken müssen, gerade in größeren Projekten das eben. Gute Requirements oder gute Anforderungen an so Projekte einfach total wichtig sind,
vielleicht ganz kurz zu mir. Also ich hab mich eigentlich schon immer für Computer interessiert, aber mich erst sehr spät getraut das auch öffentlich zu tun. Also ich hab erst in meinem Studiengang, der eigentlich sehr viel mit Medien war, dann angefangen mich in der Informatik einführungsveranstaltung dafür zu interessieren, hab dann so viel aufgesogen wie möglich und hab aber das Programmieren immer gehasst. Also ich programmiere tatsächlich nicht so gerne.
Und hab mich dann immer auf die Schnittstelle zwischen Mensch
und Computer fokussiert. Da ist auch viel Psychologie drin, da ist alles mögliche andere auch drin, vielleicht bisschen Soziologie, aber eben auch ganz viel Technik und ich hab dann sehr lange eben Doktorat und so, das sind Forschung, Forschung, Lehre, Wissenschaft weiter vorangetrieben, es gibt auch so ein Studienfach in der Informatik, das heißt Human Computer Interaction genau und hab mich dann eben nach meinem Doktorat dazu entschieden.
Ich möchte gerne mal sehen, wie echte Software für echte Menschen in echten Firmen gebaut wird. Und bin dann im Requirements Engineering und so n bisschen auch im UX Design gelandet, wobei ich eben keine Designerin bin, sondern Informatikerin und ich find da passt das Thema Requirements Engineering eigentlich sehr gut.
Ja, mittlerweile leite ich eine Abteilung hier bei der MSG Cloud bei einer mittelständischen IT Beratung in in Wien leite ich eine Abteilung zum Thema Requirements Engineering, die habe ich selber aufgebaut, also handverlesen selbst hochgezogen und wir sind eigentlich sehr erfolgreich hier eingebettet, unterstützen eben unsere Entwicklungsteams bei der Anforderungserhebung. Arbeiten da sehr, sehr eng zusammen. Vielen herzlichen Dank. Das ist gut, dass du es ansprichst.
Gleich, dass ihr das auch als Abteilung macht, das Requirements Engineering, da kannst du es uns ja gleich mal aus der Praxis näherbringen. Was bedeutet das denn eigentlich und wann kommt ihr rein und wo geht ihr vielleicht auch wieder raus aus Projekten, dann also übertragen in andere Firmen, die jetzt keine Externen dafür reinholen oder keine Experten, wann fängt das an, wo hört das auf, kannst du es so ein bisschen definieren? Für uns.
Also ich finde Requirements Engineering fängt eigentlich direkt bei der allerersten Idee an, die man für so ein Projekt
hat. Und zwar sollte man eigentlich immer alles dokumentieren, durchdenken und und am Ende auch eben Durchsprechen mit dem Kunden oder mit der Kundin, das heißt Requirements Engineering, also Anforderungsanalyse, da geht es um das strukturierte erheben, analysieren, dokumentieren von Anforderungen an Softwareprojekte und wir sind eigentlich idealerweise von Anfang an mit dabei.
Und der Charme ist, wenn man eben von der ersten Idee über die Anforderungserhebung über die Umsetzung vielleicht schon zum Betrieb auch dabei ist, dass man eben einen roten Faden durch das Projekt hat und idealerweise, wenn es 100% bestens läuft, wirklich durchgängige Dokumentation über alle Anforderungen, über Entscheidungen zum Projekt, wie die Stakeholder entschieden haben, wer wann welches
Stakeholder abgeholt hat. Also man hat das idealerweise dann alles vorliegen und kann eben so sehr gut nachvollziehen. Warum, wann, was im Projekt Lee gebaut wurde? Und ist das wahr? Für alle Größen von Software Projekten oder fängt das erst an bei gewissen Volumina? Also ich persönlich finde, das macht in Projekten jeder Größe Sinn, wobei es nicht immer Sinn macht ne eigene Rolle Requirements Engineering zu starfen.
Also ihr kennt das sicherlich auch aus eurer Entwicklungstätigkeit, gerade wenn ihr so in Richtung Architektur unterwegs seid. Ihr werdet sicherlich auch das eine oder andere aufschreiben oder einfach niederschreiben, bevor ihr anfängt zu programmieren. Einfach, damit alle wissen, gerade wenn man vielleicht bei Juniors dabei hat, dass alle wissen, was da gefordert ist,
was erwartet ist. Vielleicht bei Akzeptanzkriterien was muss man machen, aber die damit diese Story jetzt umgesetzt ist andererseits wiederum in riesengroßen Projekten schafft das wahrscheinlich nicht eine Person alleine jetzt alles durch zu zu analysieren. Da hat man dann manchmal wirklich Analyse Teams von 567, Requirements Engineers oder vielleicht auch Business Analysten, das ist tatsächlich in der Industrie teilweise. Nicht so ganz trennscharf, wie die Rollen benannt sind.
Und dann hat dann jeder irgendein fachliches Paket, Rechnungslegung, steuerberechnung, keine Ahnung, worum man oder Frau sich dann halt kümmert. Mhm, ich hab noch mal ne ganz einfache Frage. Ich bin mich nicht so bewandert im Requirence Engineering muss ich sagen Asche auf mein Haupt, aber ist es eigentlich eher jetzt ne Aktion die man nach innen heraus macht?
Also ich verstehe ich fang noch mal an also man hat n kundenprojekt sag ich mal es geht gerade so los und man hat irgendwie nen Lastenheft. Mehr oder gut definiert, das heißt ja irgendwie Lastenheft. Es gibt ja auch das Pflichtenheft und so, und es ist manchmal auch einfach ne powerpoint, je nachdem wie man das Projekt dann halt gestalten will und jetzt kommt wahrscheinlich schon mal der erste Schritt des Requirement Engineerings, ist ja dann eher
erstmal nach innen heraus, also diskutiert hier quasi intern, welche Datenbanklösungen nehmen wir, ist das international oder nicht und so weiter ist es so ne Art n bisschen softwarearchitektur oder wird das sofort gleichgespiegelt auch mit dem Kunden? Das das mussten wir glaub ich erst noch mal. Muss ich erst mal verstehen. Das sind natürlich 2 Aspekte. Einmal, wie wird es analysiert oder was passiert damit, das andere ist?
Wann redet man mit den Kunden? Ich mein, Ich bin ein großer Fan von Transparenz, ich finde der Kunde sollte eigentlich jederzeit Einblick haben, manchmal geht es aber nicht, gerade wenn es vielleicht der Kunde ein bisschen sperriger ist. Das gibt es ja manchmal auch, aber also ich würde sagen beides, also man man, man geht natürlich erst mal in sich und diskutiert intern ein bisschen über Lösungen, da gibt es ja auch so ein.
Ja, ich will nicht zu theoretisch werden, so n Double Peak Modell, wo Architekt und Requirements Engineer quasi in einem Sprint work quasi drüber reden.
Was braucht man fachlich, wie ist es technisch möglich, das wäre technisch möglich, also kann man das fachlich übersetzen, dann dann wird der Architekt und die Architektin sich eher um das technische kümmern und der Requirements Engineer sich eher um das fachliche weil der Requirements Engineer quasi auch draußen steht und mit Kundenkundinnen
oder Stakeholdern redet. Und natürlich muss das Ganze, wenn man dann zu einer zu einer Lösung ist, von der man denkt, das ist herzeigbar oder man muss vielleicht auch mit dem Kunden drüber diskutieren, weil der Kunde Entscheidungen treffen muss. Da muss man natürlich das mit dem Kunden abstimmen, und zwar so, dass er oder sie das
versteht. Wir arbeiten oft auch so mit Glossaren tatsächlich, das ist dann wieso ein kleines Wörterbuch von Fachbegriffen hört sich trivial an, aber wer schon mal in so einem Softwareprojekt versucht hat. Über das gleiche Thema zu reden, also da gibt es wahnsinnig viele Missverständnisse, und das kann man durch paar einfache, ich sag jetzt mal Taschenspielertricks, die aber trotzdem gut kommuniziert werden müssen, kann das sehr gut abgefangen werden.
Also ist die Hauptaufgabe von Requirements Engineering, dass alle auf der gleichen alle das gleiche Verständnis haben von von dem Projekt und was gemacht werden soll und das aber nicht nur zu einem Zeitpunkt vor dem Projekt, sondern auch dann im Laufe des Projekts oder was ist die Hauptaufgabe?
Ja, genau das kann man so sagen. Also einmal quasi so Handwerkszeug, einmal dolmetschen zwischen Fachbereich und Technik, man übersetzt die Technik so, dass die Fachleute das verstehen, man übersetzt die Fachsachen so, dass dass die Techniker Technikerinnen das programmieren können, man dokumentiert auch, also das schreibt man alles so nieder, dass es eben nachträglich nachvollziehbar ist, auch in die Zukunft, und dann begleitet man das Projekt eben und zum
Beispiel, wenn jetzt der Burkhardt mein Projekt programmieren könnte, müsste, könnte, der Burkhardt. Mich anrufen und mich fragen. Hey Svenja, wie war das noch mal? Bei der Zinslegung sind das 2 oder 3% und wir du müsstest nicht jedes Mal den Kunden anrufen, der vielleicht mit dem Kopf auch irgendwie in der eigenen Geschäftswelt steckt. Also da gibt es viele viele
Vorteile ich. Find es spannend, dass du, dass du gesagt hast, gleich am Anfang hätte ich mich als nächstes gefragt, dass du dann mit dem Softwarearchitekten sprichst, weil den hätte ich jetzt auch ins Spiel gebracht. Von der Diskussion her, weil der Architekt ist ja eigentlich die Person, der das Requirement auch irgendwie aufsetzt und technisch
verantwortet. Und jetzt kann ich es mir so vorstellen, dass das aber vielleicht sogar der Architekt gar nicht direkt mit dem Kunden interagiert in in in deinem Modell, sondern dass dass du als Requirement Engineer quasi die die Brücke spielst zum Kunden schon, aber n relativ tiefes Verständnis hast von der Technik, weil sonst könntest du ja nicht mit beiden Parteien sprechen und so n bisschen die Brücke auch bildest zum zum Softwarearchitekten, den aber
eher vielleicht sogar nach innen heraus, dass ihr da nach innen heraus euch durchdiskutiert und du das dann quasi wieder im Notfall zum Kunden zurückspielst. Denn manchmal gibt es ja auch Anforderungen vom Kunden, die man einfach so nicht umsetzen kann oder wo man sagt, nee, Pass mal auf, wenn du das so oder so machst, dann haben wir noch DMT Vorteile, dass man das, dass man lieber so machen und so weiter und sofort ne ungefähr richtig verstanden, oder?
Ja, schon. Wobei das genaue Setting hängt immer, also wie man genau das Macht, hängt immer vom Setting ab, in dem man sich befindet, weil es gibt es gibt manche Situationen, da macht es natürlich Sinn, wenn der Architekt mit zum Kundengerät geht, gerade wenn man tiefere technische Konzepte erklären muss und der Kunde die verstehen muss. Es hängt immer auch ein bisschen von der Persönlichkeit des Architekten ab.
Manche Leute haben halt kein keine Lust, sich so mit, so sage ich jetzt mal, vielleicht auch unangenehmeren Kundensituationen auseinanderzusetzen, die wollen gerne einfach eine Software bauen und was es auch noch gibt, ist, dass man nicht den einen Kunden hat, sondern halt vielleicht einen Kunden mit mit 12 Fachbereichen oder so. Man hat dann immer diese Workshops mit Halt 12 Personen drin, die man irgendwie zu einer
Einigung bringen muss. Ich sag mal so, das müsste eigentlich idealerweise auch ein Product owner machen, also ein Product owner oder ein Product Ownerin macht auch immer sehr viel Requirements Engineering am Ende des Tages, aber manchmal bleibt es halt auch bei den Requirements Engineers, dann hängen jetzt so negativ ausgedrückt, aber manchmal muss man das eben auch machen, dass man sagt, OK, ich muss es jetzt vorbereiten diesen Workshop zu machen, am Ende möchte ich da
eigentlich mit einer produktiven Lösung rausgehen und da braucht mich der Architekt oder die Architektin sich das die ganze Diskussion anzuhören, also da muss man schauen wer macht was also. Gibt verschiedene Settings und ich ich find es aber persönlich immer gut, wenn auch ein Architekt oder eine Architektin dann mal Mitglied auch zum Kunden hat meiner Meinung nach immer Mehrwert wenn man so die
Kette verschlankt. Was ist ist ja auch immer die Frage wie weit ist die Kette von dem tatsächlichen Bedarf bis zur Umsetzung und meiner Meinung nach sollte die nicht zu lang sein, aber natürlich sollte niemand dann total entnervt irgendwann aufgeben also das ist so ein bisschen der Spagat da. Dann lass uns mal reingehen, vielleicht in das Thema.
Anforderungen definieren, Lastenheft schreiben, sowas in der Form ne. Also man kann sich da ja auch, man kann es ja auch übertreiben, nehm ich mal an, man sollte es aber irgendwie sicher haben, also irgendwie gewisser Weise ja schon möglichst detailgetreu oder oder detailliert, aber vielleicht auch nicht übertreiben, wo es denn da das
richtige Maß ist. Deiner Sicht für so n für so n Projekt das Softwareprojekt kannst vielleicht, vielleicht kannst du uns auch einfach mal so n Softwareprojekt nennen, für das wir das jetzt mal so anwenden und durchspielen, das wär ja vielleicht auch ganz cool ne, dass wir n Beispiel haben. Na, ein gutes Beispiel wär vielleicht so ne kleine App, die der Kunde haben möchte, mit dem die internen Mitarbeitenden
Zeiten buchen können. Vielleicht die internen Zeiten oder oder vielleicht auch Zeiten beim Kunden das Ganze eben auf dem Smartphone, das gibt es nämlich nicht so oft in in Firmen, da muss man sich halt meistens ins SAP einloggen, dass man einfach auf der auf der auf dem Handy so ne kleine App hat, braucht jeder, den ganzen Tag, muss muss schnell funktionieren und muss eben auch an Bedürfnisse angepasst sein. Ja, kurzes Beispiel, das nervt dafür. Wie sieht das aus? Normalerweise.
Wenn ich jetzt der Dienstleister wäre, wird es ja eigentlich wird man, vielleicht wird der Kunde sich irgendwann an mich wenden und es wird so eine Art presales Prozess geben und es wird dann irgendwann in ein Angebot an uns münden.
Ich persönlich finde das ganz wichtig, dass wir als Requirements Engineers schon im presales Prozess mit dabei sind und vielleicht auch die ersten Termine mit dem Kunden machen, weil das Angebot basiert ja eigentlich auch schon auf Anforderungen, halt meistens high Level Anforderungen, aber da kann man schon den Scope stecken, weil meistens.
Also Last in der Pflicht helfen machen wir ja eigentlich heute nicht mehr, so ist eigentlich nicht mehr ganz zeitgemäß, meistens hat man ja schon irgendwie agile oder zumindest hybride Settings und da wollen die Kunden natürlich, also in jedem Setting wollen die Kunden meistens wissen, OK, wieviel wird das denn kosten und wie schätzt man Aufwände, Aufwände schätzt man eben auch mit mit einer Anforderungsbasis, deswegen ist das ganz, ganz wichtig, dass wir von Anfang an
mit dabei sind, weil dann kann man nachher mit den High Level Anforderungen, könnte ich zum Beispiel zu Burkhardt gehen und sagen, Burkhardt schätzt mir das doch mal grob. Dann würde der Burkhardt sich wahrscheinlich ein bisschen
beschweren. Boah, das ist ja viel zu high Level, das kann ich nicht schätzen und dann müssen wir uns irgendwie hinsetzen und gucken, OK, wie machen wir dann estimed draus min max Average und können das, wenn wir mit dem Kunden gut sind auch durchsprechen und gegebenenfalls könnte ich noch mal ein paar Rückfragen stellen so und ich verwende das auch tatsächlich das was ich in der Angebotsphase lerne verwende ich dann als Ausgangspunkt für die weitere Arbeit im Projekt, weil
das muss man ja nicht noch mal neu machen. Genau. Und im Projekt wird man dann eben in der Regel mit mit einer Reihe von Workshops starten, dass man eben sagt, OK man, man fragt sich erst mal durch, also Kick off, man fragt sich durch, wer sind denn die Stakeholder,
mit wem sollten wir reden? Ja klar, mit irgendjemanden der da arbeitet, mit der HR, vielleicht vielleicht auch mit jemanden der der keine Ahnung besondere Arbeitszeitregelung haben und da wird man einfach mal n Workshop machen wo wo wir die entsprechenden Stakeholder halt an einen Tisch setzen und mal brainstorm, OK wer hat welche Anforderungen? Was braucht man da eigentlich alles?
Was sind vielleicht sie so, die die wichtigsten Use Cases, was ist vielleicht nicht so wichtig aber nice so have also manche Sachen macht man täglich und manche macht man vielleicht einmal im Jahr, dafür sind die extrem wichtig, dass die gut funktionieren und dann wird man eigentlich schon anfangen das zu verschriftlichen. Das ist ja aber schon ganz schön viel servicedienstleistung, die ja erstmal noch gar nicht so
technisch ist. Ne, also wenn du du sagst quasi voraus, dass man davon ausgeht, dass sich die Firma, die das Produkt haben möchte. Intern vielleicht, aber noch gar nicht so einig ist, wie es genau aussehen soll, wie die Anforderungen tatsächlich sind. Und du sagst, man braucht im besten Falle so ne Art Workshop um die verschiedenen Gesichter, die verschiedenen Abteilungen mit ihren ganzen Bedürfnissen und so weiter einmal in Einklang zu bringen.
Ich würd ja fast provokant sagen, Na ja, das könnten sie sich ja vielleicht, wie würde ich es vorher überlegen, bevor sie überhaupt irgendwie rausgehen und das Angebot irgendwie aufnehmen wollen, weil das ist ja eigentlich die Arbeit, die in der Firma stattgefunden haben soll und da brauchte man vielleicht ja noch nicht unbedingt den Umsetzpartner, der das Macht. Der könnte ja quasi das finale
Ergebnis haben. Also man muss ja, man ist ja dann dabei und macht quasi noch so n bisschen streichelneiten so ja, also bitteschön, der RHR Kollege muss das irgendwie noch so haben und dem anderen ist irgendwie der Knopf wichtig und ist das immer so bei den Kunden, das ist ja dann schon ganz schön krass, ja oder? Ich es ist nicht immer so, aber es macht am meisten Sinn und ich kann euch das auch erklären
wieso? Weil wenn der Kunde sich intern versucht zu einigen Grad wenn Anforderungen widersprüchlich sind, endet das meistens in Streitereien.
Und oft braucht man diese externe Moderation, dass jemand externes mit Moderationsskills dabei ist und dann vielleicht auch einfach mal fundierte Vorschläge macht, weil das ist, das ist tatsächlich ein Punkt, wenn du Kunden direkt fragst, was sie haben wollen, dann sind sie meistens nicht in der Lage, das adäquat auszudrücken, also der der Klassiker ist.
Ich würd gern einen großen Grünen, blinkenden Button haben und der Punkt ist aber, die Kunden wollen keinen großen Grünen blinkenden Button haben, das ist die schlechteste Idee ever, die wollen, dass der Kaufen Button gut sichtbar ist. Dort, wo man schnell hinschaut und und leicht accessible und sofort auf der Startseite sichtbar.
Und da muss man halt hingehen und mit guten Argumenten und vielleicht schon einen guten Vorschlag hingehen und sagen, ich glaube, das ist das, was ihr wollt, stimmt das. Und wenn man ganz fancy sein will, kann man 23 Vorschläge machen und der Kunde sucht sich einen aus. Das sind so Tricks und Kniffe, das andere ist, wenn der Kunde schon mit einer Anforderungsbasis kommt, müssen wir die auch erst mal verstehen. Das heißt, man macht die Arbeit
eigentlich doppelt. Der Kunde macht die Arbeit und wir müssen dann eigentlich auch noch mal reingehen, weil wir sind ja die, die das umsetzen, das Macht der Kunde ja nicht selber, sonst hätte er uns ja nicht gefragt.
Das heißt, wir müssen noch mal reingehen und die gleiche Arbeit noch mal neu machen, das heißt, an diesen Schnittstellen zwischen verschiedenen Dienstleistern geht meistens total viel Arbeitszeit und und Nerven auch verloren, denn wenn man Pech hat, ich mein, es kann auch super funktionieren, wir haben auch Firmenübergreifend gute. Gute Erfahrung gemacht eben, dass eine Firma die Anforderungen macht und dann andere Dienstleister
programmiert. Aber da müssen wirklich beide sehr gut verstehen, was wie sie das machen und manche Firmen gehen tatsächlich erstmal mit wahnsinnig viel Requirements Engineering Leistungen rein, weil sie sagen da sind beide Seiten besser abgesichert, beide Seiten wissen wovon sie reden, es ist sehr klar wie die Lösung aussieht, das ist schon durchdacht und das senkt das Risiko, dass nachher Mehrkosten
entstehen. Und gerade ich hab es dann in der Einleitung schon erwähnt, gerade bei so Nearshoring und offshoring kann man sich eigentlich drüber streiten, was dann wichtiger ist. Die Programmierung am Ende des Tages bei so großen Projekten oder die Qualitätssicherung durch Requirements Engineering und Testing.
Sorry, war jetzt n bisschen länger, aber ich find das ist immer so genau der bunte Punkt und manche Firmen fliegen erst auf die Nase und sehen dann irgendwann ein, dass das Requirements Engineering wichtig ist. Gerade in so Projekten, die für 56 Jahre laufen, finde ich total wichtig, wenn da jemand Neues reinkommt, dass die Person dann. Schaut, was ist da eigentlich vor 3 Jahren entschieden worden und wieso? Ein kurzer Hinweis in eigener Sache. Kennst du das auch?
Ihr seid gefangen zwischen starrer, veralteter Standardsoftware und endlosen Individualentwicklungsprojekten. Unsere Mission bei Heisenware ist es, das zu beenden mit unserem App Baukasten geben wir dir die Möglichkeit, maßgeschneiderte Software für den Shopfloor schnell und ohne Code zu erstellen. Denk an Maschinendatenerfassung moderne Visualisierung für die Produktionsleiter. Oder eine mobile App zur Buchung von Zeiten. Und das beste, du kannst deine Lösung ganz einfach ohne it
Aufwand selbst betreiben. Kurz gesagt, günstiger als eine externe Entwicklung unendlich passender als Software von der Stange. Weitere Infos und eine kostenlose 30 Tage Testphase findest du auf heisenware.com. Einfach komplex und jetzt viel Spaß mit der weiteren Folge.
Es ist total relevant und immer ja egal auch, ob wir jetzt noch KI haben und so weiter aber jetzt musst du jetzt sind wir genau in diesem tiefen Punkt. Jetzt musst du mir noch was erklären, weil was was ich jetzt daraus so n bisschen ja ich schieß los, ich brenn so an Fingernägeln, was ich daraus so n bisschen verstehe ist, dass wir so ne, dass dass du im besten falle so ne Art Top Down Planning hast, möglichst früh für nen für nen möglichst also möglichst.
Umfassende Anforderungen am Anfang schon mal verstehen, ob man sich einig ist. Glaubst du wie und so weiter das das Bedarf ja einer Kompletterfassung des Projektes was so n bisschen im Widerspruch oder auch nicht steht.
Gucken wir gleich mal zum agilen Entwicklungsprozess und das heißt ja immer diese alte ich ich plane mir das Ding zusammen ja und dann geh ich da wasserfallmäßig runter definier milestones und so weiter und sofort, da gibt es ja viele Texte im Internet die dann sagen ja ja, also das haben wir uns früher gemacht, ja viel besser ist, weil wir nämlich genau alle wissen, dass wir es gar nicht wissen. Wir fangen mal an, quasi ohne Anforderung.
Ich übertreibe jetzt ne, aber nur um den Punkt zu machen und dann gucken wir alle 2 Wochen treffen wir uns und es wird andauernd iteriert und das Produkt wird ständig weiter iteriert und bewegt sich quasi in einer Kurvenbahn hoffentlich in die Richtung wie es der Kunde zum Schluss dann auch haben möchte. Ja das und und diese 2 für mich gerade so n bisschen gegensätzliche Konzepte, das musst du mir jetzt auch noch mal quasi aufgleisen, weil garantiert gibt es da irgendeinen.
Hab ich da was falsch verstanden? Das gibt irgendwie so ne Schnittstelle in der Mitte oder irgendwas. Ja, das gibt auf jeden Fall ne Schnittstelle und und in manchen Firmen funktioniert das besser das Leichtgewichtiger zu machen und damit zu starten. Und bei manchen Firmen muss erst alles einmal durchgedacht werden. Also da gibt es verschiedene Ansätze, aber der Knackpunkt ist, wenn man alle 2 Wochen neu iteriert und neu entscheidet, also. Vielleicht muss ich da noch was zu sagen.
Ich finde dieses Beispiel von dem reinen Scrum finde ich meist nicht so gelogen, weil das setzt voraus, dass das Team sich selber steuert, aber es steht irgendwie da kommt nie eine Vision oder eine Roadmap vor und spätestens wenn irgendjemand der Geldgeber sich am Ende des Tages hinstellt und fragt, Wieso hat das denn so viel gekostet und das Team dann sagt, Na ja, wir haben halt im ersten halben Jahr in die Richtung entwickelt und dann fanden wir das andere anders und dann am Ende haben
wir noch mal in die Richtung entwickelt, das hört halt auch keiner gerne, der dann halt sein Geld da reinsteckt, deswegen ich glaub die Wahrheit liegt in der liegt in der Mitte. Manche Themen kommen ja auch erst auf, wenn man dann wirklich
entwickelt. Also das kann eigentlich dann auch niemand vorhersehen, oder es ändert sich noch mal ein Sachverhalt, das heißt, was wir am Anfang machen, das ist in der Regel sehr, sehr grob und feiner wird es dann, wenn man, wenn man eben das gemeinsam dann mit dem Architekten oder mit den Entwicklern dann durchspricht oder halt auch schon umsetzt, wichtig ist, dass man mit dem Kunden auch ein guten Modus hat,
was passiert. Also wie laufend reported wird, wie laufend nachanalysiert und nachgebessert wird und wie auch Changes, zum Beispiel wenn der Kunde halt was reinruft. Ach das wär auch noch cool, könnt ihr das auch noch machen, wie man eben mit Changes und changes requests dann umgeht? Also ja ich glaub die die Wahrheit liegt in der Mitte meiner Meinung nach ja. Ich, ich refinal noch mal, was
ich sagen wollte. Ich verstehe, dass das so sagst mit den Scrubs und so was kenne ich auch aus meinem früheren Leben mit mit mit größeren Teams und so weiter ich meine aber sogar den den den Prozess als Agilität.
Das den Kunden mit einbindet ne, also ich weiß nicht wie das typischerweise so gemacht wird bei uns bei der Heisen wäre es oft so, dass wir dann so so Fixes haben, die sind gar nicht so selten, das sind so alle 2 Wochen am Anfang vielleicht zum Schluss vom Projekt sogar wöchentlich mit dem Kunden, wo wir dann quasi zeigen, so sieht es aus, ja das ist jetzt gerade der Stand der Dinge und der Kunde hat immer wieder die Möglichkeit n bisschen zu ändern und das ist aber auch spannend,
weil das müssen wir ja alle zugeben. Keiner ist in der Lage n komplexeres Projekt von den Anforderungen her komplett durchzuverstehen von oben herab, das wär schön wenn es so wär. Es gibt immer wieder Sachen die aus 1000 gründen, aus Prozessgründen, manchmal aus technischen Gründen und so weiter leicht geändert werden müssen im im Verlauf der Dinge und jetzt kommt noch mal ne Frage, wie bewertet ihr das und das find ich manchmal selber auch ganz schön schwer, ab wann ist irgendwas?
Klar, Teil von dieser Anforderung, die am Anfang ja aber sehr grob war, wie du sagst, ja und wo man sagt ja ganz klar, richtigerweise müssen wir technisch hier n bisschen was anders machen als wir geplant hatten, haben wir selber quasi zu verantworten sag ich mal, ist im Budget mit drin oder anders gesagt der Kunde sagt OK verflickst hier hab ich noch beim Prozess was vergessen, hier gibt es noch was, hatten wir nicht drüber nachgedacht, das müssen wir irgendwie noch da
eingleisen ab wann ist quasi ne ne ne Änderung an der Anforderung. Ne echte Änderung der Anforderung und muss quasi vielleicht auch neu besprochen, neu bepreist, neu alles werden. Und ab wann ist das quasi im normalen agilen Flow drin? Kannst du da vielleicht auch noch mal aus deinem aus deiner Erfahrung einfach noch mal n bisschen was zu sagen? Ich glaube, das ist dann tatsächlich was, was, was eine Änderung vom ursprünglichen ist.
Wenn der Kunde die ursprüngliche Anforderung abgenommen hat und sich das ändert, man das überarbeiten muss und der Kunde das noch mal abnehmen muss. Weil in der Regel machen wir das so, dass du eben High Level oder Top down wie du das meinst, runter spezifizieren und dann machen wir es noch mal Fine.
Weil es gibt ja auch Refinance. Also ich find refinance ist 1 der wichtigsten Meetings wo man einmal zusammensitzt und die Anforderung durchspricht guckt ob es noch Lücken gibt, dann ist sie eben zu Ende refined und Ready for vor Umsetzung sag ich jetzt mal und dann sollte im Idealfall der Kunde das Abnehmen und sagen oder der Product Owner vom Kunden oder wie auch immer, ja das ist gut, gibt es das so in die Umsetzung? Das ist dann geschätzt und und getaggt und alles.
Und wenn dann irgendwas kommt, wo man sagt, OK, das ist jetzt nicht innerhalb von 2 Stunden machbar, also vielleicht kann man auch so ein Toleranzlevel festlegen, sondern das ist eine größere Änderung, dann wird man es überarbeiten und das dem Fund noch mal vorlegen und sagen, Schau, das wird jetzt 3 Tage mehr Aufwand machen, der Business Value ist aber vielleicht eher gering, willst du das wirklich machen und dann müssen wir halt mit Stempel und mit Siegel sagen, ja, das möchte
ich jetzt, das sind tatsächlich Prozesse. Die sind recht wichtig und oft, wenn man, gerade wenn man sich gut versteht, sagt man ja, ist nicht so wichtig, wir machen das einfach, aber das kann einem auch mal, gerade wenn man sich anfängt, dann vielleicht doch mal zu streiten. Über einzelne Punkte kann einem das doch auf den Kopf fallen.
Also ich würde das in meinen Projekten immer festlegen, was ist der Change Prozess, wie sind die Abnahmeprozesse und und wie geht man damit um, beantwortet das deine Frage, war das jetzt zu Projektmanagement mäßig? Nee, überhaupt nicht. Weil das, das hat ja alles auch mit Projektmanagement zu tun, ne und also? Ich glaube, das ist immer n Thema. Also bei uns ist das immer n Thema und vor allen Dingen je je agiler du mit der Technik umgehen kannst, desto desto leichter ist man ja.
Als Dienstleister sag ich mal in der in der Versuchung zu sagen, ja OK, dann machen wir das noch mal hier und so, weil ich ich sag ja mal was unsere unsere Art und Weise wie wir Software entwickeln, auch einfach dadurch, dass KI jetzt Einzug hält, wird ja schneller und agiler an sich, ja aber wir, das kann man ja nicht wegdiskutieren wir wir können als Software Dienstleister. Zügiger glaub ich einfach umsetzen als vorher und das führt ja auch zu so ner bisschen
zu so ner Verzerrung. Ja und jetzt könnte ja der der der Kunde könnte jetzt ja meinten Na ja OK, dann hauste das halt irgendwie noch mal da rein, JGPT rein oder irgendsowas damit das schon passen soll. Ja weißt du, deswegen frag ich auch noch mal so ne, weil die Erwartungen erwachsen ja mit der gefühlten KI die jetzt die Software lösen kann beim Kunden halt ja auch entsprechend ja. Das ist irgendwie ganz witzig,
dass du es ansprichst. Weil momentan liegen auch zumindest ein Teil der KI Agenten bei mir und meinem Team, weil ich sag, also ja, ich sag gutes Prompting, ist ja eigentlich auch schon so eine Art von von Anforderungserhebung, weil gerade wenn man vipe Coding macht. Man muss sehr genau beschreiben
können, was man haben möchte. Ich hab selber auch schon ein bisschen vipe Coding gemacht, du musst wirklich ein ein Experte im prompt Engineering sein, du musst wissen wie du es formulierst und fernab von du bist ein erfahrener Softwareentwickler, du machst jetzt. Das und das, das reicht halt nicht. Du musst es wirklich gut können und dann musst du es wirklich
auf den Punkt bringen. Und wenn man eine gute Anforderungsbasis hat, ja, das ist viel Text, das kommt uns jetzt zugute, das ist nicht negativ, auch wenn es
aufbereitet ist. Das kann nur ein Vorteil sein beim White Coding, gerade auch, weil dann nachher die AI Tester das dann testen können, weil auch White Coding musst du gut testen und dann kannst du sagen, Hey hier, da gibt es auch jetzt so eine Fortbildung zum Thema KI Testing, das machen unsere Kollegen aus der Testingabteilung, dann kannst du einfach ganz ganz anders arbeiten dann. Testest du es halt einfach nachher.
Anhand der Anforderungen kannst dir sicher sein, ja passt hat gut geklappt, da muss man eigentlich als Architekt nur noch die ich sag jetzt mal die Oval Architecture im Kopf behalten und schauen, dass es dann doch noch irgendwie
verständlich ist. Aber das hilft halt total bei der Arbeit. Vielleicht können wir da noch mal den, den den Schwung machen zum zum Prototyping und solche Sachen. Also man kann ja einerseits Anforderungen aufschreiben oder man kann sie auch als User Stories aufschreiben, nehm ich mal an, ist vielleicht n bisschen zugänglicher für einige aber noch zugänglicher ist ja was klickbares. Angefangen bei bei Mogup ja, wo ich einfach nur mal sehen kann, wie das aussehen würde.
Irgendwie n Front End, vielleicht n Click Dummy über ja bis hinzu was gelokoadeten oder sogar gewipecoadeten oder sowas ne was dann auch Backend Funktionalität hat, also gehört das auch da ins Requimes Engineering oder welche Rolle spielt das? Meiner Meinung nach spielt das ne sehr große Rolle, aber es ist noch mal n bisschen n anderes Fachgebiet, also wirklich clickeral Prototypes fallen meiner Meinung nach und das UX Design.
Und werden entweder in so Tools wie Figma oder so umgesetzt oder vielleicht vom Frontend Entwickler, wenn er oder sie da
schon Skills hat. Im Thema UX Design und das kann aber die gleiche Funktionalität im Projekt haben und ich sag immer UX Design machen am allerbesten die Designer weil es sieht ganz anders aus, wenn ein Techniker eine Oberfläche zusammenklickt als wenn ein Designer eine Oberfläche zusammenklickt also ich sag auch immer da hört meine Kompetenz auf, ich bin promovierte Informatikerin. Designs muss jemand anderes machen, da bin ich echt nicht
gut drin. Ich mache so Low Fidelity prototypes, aber ich finde das sehr wichtig und wenn ich das kann, nehme ich mir immer ein UX Designer, eine UX Designerin hinzu, weil man kann da man hatte sehr viel Überschneidungspunkte in der Arbeit und man kann da das Beste rausholen, das heißt man hat einmal die technisch abgestimmten Anforderungen und einmal das qualifizierte Design mit einem guten Flow und und ein Maß für die Personas und.
Dieses ganze Emotionen also. Manchmal hat man ja auch dieses, man möchte Wow wow Effekte erzeugen, also es auch wenn es in Richtung Customer Relations geht oder Customer Experience, sorry, also das ist auch so ein Thema, manche Kunden dann sagen dann ja, warum brauche ich requirements engineering, ich habe ja ein UX Designer, eine UX Designerin, das kann gut funktionieren in Projekten, wenn man einen guten Architekten hat und einen guten UX Designer. Dann kann das gut funktionieren,
wenn der Architekt die Anforderungen dort mit dokumentiert, wo es dem UX Designer zu technisch wird.
Aber auch da kommt es immer ganz klar drauf an, was ist das für ein Projekt, wieviel Anteil hat da grafische Oberfläche ist, muss das jetzt ein ein Produkt sein, das auf den Markt geht, das ist ganz unterschiedlich, aber ich sag ja, am allerbesten geht man zum Kunden mit einem clickable Prototype, das ist sehr wenig Aufwand und man kann den Kunden, man kann bis zur Management Ebene drüber diskutieren und Entscheidungen treffen ob das umgesetzt werden kann oder nicht.
Und was wollte ich vielleicht noch zu den zu dem Punkt davor sagen? Ich bin da immer sehr ergebnisorientiert, ich sag dann immer, was braucht das Projekt um erfolgreich zu sein, das beantwortet auch zum Teil das, was ihr vorher gefragt habt, weil ich schaue halt was braucht dieses Projekt um erfolgreich zu sein, dann nehmen wir uns das hinzu und auch bei diesen was muss man in der Vorphase machen, wie kommt man dann zu zu der Beauftragung oder wie kriegt man
das durch? Was braucht man da, um dort erfolgreich zu sein? Und da gehört meiner Meinung nach, wenn es wenn das Produkt ne Oberfläche hat auch Gutes für ex Design hinzu, Mhm. Passt auch zu meiner Erfahrung. Ich hab also wenn wenn man es könnte würd ich mal fast sagen, die erfolgreichsten Projekte sind wo man quasi ganz am Anfang schon das finale Produkt, wenn es ne UI ist.
Meistens ist es, aber wir sprechen ja meistens von Apps und so weiter ja also ich sag mal 90% der Dinger, die sind ja irgendwie in einem Fenster oder auf einer App oder irgendwie was ja. Also wenn wenn der Kunde das sehen kann und die Knöpfe und so weiter und und auch die verschiedenen Seiten, die man so hat, dann wird es auf einmal für alle so einfach dieses Projekt durch zu verstehen und man zäumt
quasi das Pferd von hinten auf. Also man guckt quasi dieses fertige Ding an, obwohl da noch gar nichts hinter steht, ist ja nur ne Fassade, weil weil ich glaube also in meiner Erfahrung wird das dann auf einmal so einfach auf einmal fangen alle an von dem gleichen Krams zu sprechen auch und und anhand
dieses. Prototyps kann man ja auch schon mal die Namen feststellen, was gesagt ist, glossery und so weiter ja dann kann man sagen, OK, das nennen wir so, die Page heißt so, wenn man den Knopf fasst ist, dann geht diese Story an und so weiter und sofort und auf einmal hat man auch ganz klar gezogen, wie heißt das alles und wir sprechen alle von dem gleichen und wenn man das einmal agreed hat und meistens fallen da schon die Knackpunkte aus, da merkt da schon der Kunde
scheiße, ich hab noch vergessen, ich brauch ja irgendwie noch ne Settings Page und ah das sieht ja kacke aus, wir brauchen auch noch auf jeden Fall n Dunkles. Oder Irgendsowas wir müssen das, das ist total wichtig so, das fällt ja meistens dem Kunden dann schon auf, wenn man das da sieht, weil das irgendwie weiß ich nicht, irgendwelche anderen Locken im Gehirn irgendwie aktiviert so, ja und und wenn man das dann hat, dann das quasi rückwärts einfach mit Leben füllen, ne einfach mit in
Anführungszeichen, aber quasi da dann quasi die echte Logik das Backend dran schalten und so weiter ja das ist meine Erfahrung, ich weiß nicht, aber. Ist natürlich manchmal n bisschen schwierig es zu tun, aber deswegen machen wir natürlich bei der Eisenwehr auch n Nocode. Wir können das quasi so machen und tatsächlich auch rückwärts
anfangen. Ja, es geht natürlich nicht in jedem Softwareprojekt, wenn es tatsächlich klassisch gecoded wird, aber ja. Ja, ich bin eh n großer Fan von Lowcode lowcode, weil es so ne angenehme Einstiegshürde hat, aber ich seh das auch so, dass sich das wirklich hernehmen und sich das anschauen zu können, sich schon durchklicken zu können. Das hat dann auch voll die
Wertigkeit für den Kunden, also stecken wir vielleicht nur. 34 personentage Arbeit dahinter es ist für den Kunden eigentlich gefühlt schon die Hälfte des Projektes und was ich meinen Consultants auch immer sage, ärgert euch nicht, wenn wenn da zum Beispiel Rechtschreibfehler bemäkelt werden, wenn die Leute im UX die im UX Prototypen nur die Rechtschreibfehler bemängeln, heißt das Ihr habt alles andere richtig gemacht, also das da sind dann man daran zeigt sich dann halt auch viel
bei der Reaktion ob das jetzt ein Erfolg ist oder nicht. Also ja stimme ich voll zu. Da möchte ich kurz reinspringen. Ich habe das Gefühl, Leute, also. Bei einem Wort, was falsch geschrieben ist, wissen die Leute ganz genau, wie es richtig geschrieben ist. Deswegen können Sie da ganz schnell was zu sagen.
Aber zu einem zu einer UI, da wissen sie ja nicht, wie es jetzt richtig wäre, es gibt ja keine richtig per se an der Stelle. Ja, also da ist, also würde ich fast eher sagen, ist die Erfahrung, die die Leute gucken halt noch irgendwas wo sie was zu sagen können oder und wo Sie auch Sicherheit sagen können, dass es an der Stelle falsch ist. Ja, das stimmt. Aber generell, wenn die Leute wenn wenn wenn wenn es nicht passt. Und man kann das fachlich nicht
anders ausdrücken. Heißt dann heißt dann meistens so, Boah, das gefällt mir nicht oder ist es kommt dann generelle Unzufriedenheit oder so, aber wenn ja schon, aber wenn, wenn sie sagen, Boah ja, gefällt mir schon gut, aber vielleicht bessern sie da mal das aus oder das Rot ist dort, ist mir dort zu dunkel oder so also das ich find man kann schon so n bisschen an den Reaktionen lesen, ist das jetzt eigentlich
ein Erfolg oder nicht? Und die Leute sagen oft was um halt was zu sagen, aber das muss man eher positiv sehen. Am allerschlimmsten ist eigentlich, wenn sie gar nichts sagen, also dann weiß man mal total verkackt, wenn gar nichts kommt, weiß man, jetzt ist man eigentlich dann gleich raus, also das ist ja meist so, Sprachlosigkeit. Also Svenja, du würdest also sagen und ich find das spannend?
Ja, weil das ist das ist ne Frage, wo investiert man also man ist ja immer Investment von Zeit und Geld und so weiter du sagst und ich sage das auch, aber man investiert vielleicht sogar n bisschen mehr Zeit. In in diese ganz anfängliche Phase, um die Kunden und sich selbst mit abzuholen. Wo wird die Reise eigentlich hingehen?
Ja, denn das ist ja, selbst wenn man auch so nen Prototyp macht, der eigentlich noch nichts kann, du brauchst dann im Notfall n bisschen simulierte Daten, damit da irgendwie was durchfließt, du brauchst so nen minimalen State Krams und so, selbst wenn du das jetzt nicht codest wenn du das Low codest und so weiter ist halt immer extra Aufwand, ja du musst im Notfall ne Maschine simulieren, weil du hast jetzt irgendwie noch nicht von der PLC
das Signal und so weiter und diese ganzen Simulations getönt und so weiter um das mal so n bisschen durchzuspielen. Das musst du ja wieder wegschmeißen, sag ich mal. Das ist ja nur dafür, dass man einmal errafft. Wo soll die Reise hingehen? Und es ist halt Aufwand. Ich glaube, dass der sich aber tausendmal lohnt am Anfang ja selbst wenn du das alles wieder wegschmeißen musst, nur damit man nur damit man auf der gleichen Page ist.
So ja, weil ich glaube nach hinten heraus holt sich das dann wieder alles ab. Ja man man ist sich wenigstens irgendwie einig gewesen und es dieser ganze Zank und Ärger wo man sich einfach missverstanden hat, selbst wenn man es gar nicht wollte, ja einfach mal aneinander vorbeigeredet hat, man hat es nicht gemerkt, weil es abstrakt des Gedöns ist.
Spart man sich? Ja, das wollte ich noch mal von dir abholen, ob das auch deine Meinung ist, dass man da lieber ich weiß nicht wieviel Prozent du sagen würdest, kann man dafür einsetzen vom Projekt ich, ich würde fast sagen irgendwie ruhig 20% und ich hab hab ich nur mit den damit verbracht, dass wir, dass wir erst mal genau wissen im Projekt was was wollen wir genau tun, den Kunden mit an Bord holen und dann sind vielleicht 80% tatsächlich das Projekt, die Umsetzung, die
Tests, die alles mögliche. Mhm. Das passt eigentlich ganz gut in ein anderes Thema aus dem Vorgespräch. Was kostet zu welchem Zeitraum, zu welchem Zeitpunkt des Projektes wieviel und vielleicht
um das vorab zu beantworten. Ja ich sag geh auch oft mit 20% rein, ich glaub der tatsächliche Aufwand ist alles zwischen 10 und 30%, manche Firmen sagen auch sie stecken 40% Analyse rein wenn danach ein Festpreisprojekt raus purzeln soll, also da gibt's unterschiedliche Ansätze, aber bei mir ist die Daumenregel auch zu 20% vom Entwicklungsaufwand
also. Gewissen Overhead also kann man auch für Testing und Projektmanagement und Co. Aufrechnen, werde ich jetzt nicht tun, da müsste jemand anderes für einladen, aber ansonsten ich mein Wegschmeißen tut man meistens, die Frage ist, wann schmeißt man es weg und wieviel Arbeit schmeißt man weg, weil wir haben eh schon über dieses über die 1 1000 regel geredet, wenn es halt in der Analysephase auffällt und und man sagt OK man hat ja jetzt 2
personentage reingesteckt und man überarbeitet das noch mal und steckt noch mal 2 personentage rein.
Ist viel besser, als wenn man es dann auf in der Entwicklung halt drauf kommt und dann halt schon 20 Entwicklungstage reingesteckt hat und dann noch mal 20 drauflegen muss oder wenn es im Betrieb erst auffällt und das Ganze dann noch mal höher ist und vielleicht schon 200 Personentage gekostet hat und deswegen ist es eben ganz wichtig am Anfang einen ausreichenden Effort eben da reinzustecken, das ganze gut durchzuanalysieren, dass man eben früh auch auf Fehler kommt,
schaut, ob das alles so zusammen geht, damit man nicht was baut, was am Ende noch mal neu gebaut werden muss, weil das ist kostenintensiv und teuer. Am Ende des Tages, genau also in der Regel ist das so, Requirements Engineering, Entwicklung, Testing und betrieb, man kann wahrscheinlich auch in einer 1 10 100000 Regel draus machen, wenn man möchte, weil wenn es mal im Betrieb ist und man muss es neu machen, dann muss man eigentlich ganz vorne wieder anfangen und das ist dann
extrem schmerzhaft. OK, wenn man eine Zehnerpotenz zwischen den einzelnen Stufen da ist. Natürlich immer so eine, so eine Hausregel oder so eine Daumenregel, aber. Ist es schon schmerzhaft, wenn man im Betrieb drauf kommt? Das Feature gefällt kein, kann auch einfach das Lebensende für ein Produkt bedeuten, wenn man Pech hat. Ein Feature meinst du?
Ja, wenn man irgendwas ganz falsch baut, ist natürlich jetzt n extremes Beispiel. Ich kann mir das auch vorstellen, das muss dann gut passen, wenn man sich individuelle Software baut und das passt dann doch nicht. Das ist glaub ich manchmal vielleicht wieso n Auto.
Hat sich da irgendwie drauf gefreut und eine riesen Investitionssumme. Und wie geht das genau passend haben und stell dir vor irgendwie, du wolltest unbedingt n schwarzes schwarzes Auto haben und das ist jetzt irgendwie weiß ich nicht grün oder Irgendsowas das ist schon blöd ja, also dass du irgendwie nicht so zufrieden bist. Ich find ich find man muss doch nicht immer in funktionalen Anforderungen denken, sondern man kann auch in nicht funktionalen Anforderungen denken.
Also funktionale Anforderungen sind halt so Features und nicht funktionale Anforderungen, ist halt sowas wie Sicherheit.
Performance und sowas alles. Und wenn man halt sagt, OK wir brauchen halt irgendwie eine App, die muss halt mit einer Latenzzeit von so und so viel Sekunden also so und so viel Millisekunden sofort da sein, wenn man das nicht von Anfang an die in die Architektur halt reinbaut, dann sind das so Sachen, die kriegt man nachher nie wieder rein oder das Datenmodell man baut das Datenmodell auf und möchte dann nachher ein Feld hinzufügen und stellt fest das passt gar nicht
in die aktuelle Datenarchitektur rein und das sind halt so Sachen, da muss man halt genau aufpassen, dass man es von vornherein mitdenkt. Und vielleicht auch mit dem Kunden oder dem Auftraggeber gemeinsam nicht Ziele festlegt, dass man sagt, das soll nicht im Scope sein.
Also wir sind auch dafür da, einmal die gesamten, den gesamten Umfang abzuklopfen und eben sagen, was ist drin und was ist nicht drin, dass man nachher sagen kann, wir haben extra gesagt, das ist nicht drin, weil wir haben Ihnen nie gesagt, das wär zu teuer, das ist ganz, ganz wichtig das. Finde ich noch mal ne Kernaussage das das machen wir auch ganz oft die Abgrenzung was ist nicht drinne ne Anforderung in der Anforderung hat man es nämlich genau.
Denn das ergibt nämlich einem, einem einem Dienstleister die Freiheit, der vielleicht schon das ganze n bisschen tiefer durchdrungen und durchdacht hat als der Kunde selber bestimmte Sachen Vorauszuahnen, vorauszudenken und schon zu antizipieren, was da vielleicht noch kommen würde und es von vornherein auszuschließen, weil wir wissen, dass das ne
technische Explosion ist. Die Pandora Büchse ist glaub ich ne sehr clevere Geschichte. Das das würde ich noch mal wiederholen wollen, das nutze ich auch oft. Ja das ist wichtig, ja weil man, weil man das als Dienstleister vielleicht sogar besser erahnen kann als jetzt der Kunde selbst, ja. Kein Problem.
Na ich wollte noch sagen, das ist aber auch dann der Job vom Softwarehersteller meiner Meinung nach das auf jeden Fall da da da gehört eine gewisse Beratungsleistung dazu, also so dieses von der einen Seite, ja, das Macht der Entwicklungsdienstleister, da kümmern wir uns nicht drum und dann so, ja wir haben es ihnen eh gesagt, aber sie haben nichts
dazu gewusst. Finde ich funktioniert halt heutzutage nicht mehr, weil man möchte ja am Ende des Tages, dass es funktioniert für beide Seiten und da muss man schon schon dann beraten oder halt auch vielleicht auf manche Dinge bestehen. Du hast gerade erwähnt, wenn man als Anbieter, als als Softwareanbieter dann Festpreis anbietet, will man vielleicht auch 40% eher in die Analyse am Anfang investieren, also die Anforderungen noch konkreter und und genauer eigentlich definieren.
Hab ich dich da so richtig verstanden und das heißt, was gibt es da noch für alternativen Timing Material wär es dann wahrscheinlich ne, also entweder mach ich das oder dies und was
was was hab ich noch. Ja, also entweder festpreisprojekt man definiert halt ein Gewerke und genau ein Gewerk und genau das wird halt umgesetzt für einen fixen Betrag. Da liegt natürlich mehr Risiko auf der Auftragnehmerseite, das heißt man sagt Halt quasi zu, dass der Kunde das bekommt am Ende des Tages für diesen Preis, wenn man dann schneller fertig wird, ist es natürlich Lotto Jackpot, wenn man halt länger braucht, ist es dann natürlich
schneller, dass die Marge, die man rausbekommt das andere ist. Time mit Material. Man verrechnet dem Kunden in der Regel monatlich einfach das, was angefallen ist.
Und ich sag mal so, das klassische klassisches Crumb ist halt Time and Material, dass man eben sagt, OK, wir schauen uns halt von Sprint zu Sprint an und und genau dann gibt es halt in der Regel dann eben regelmäßig ne Rechnungslegung und ne ne ne ausweisen der Aufwände, dass man sagt, hierfür haben wir so lange braucht, hierfür haben wir so lange braucht, das ist eigentlich sehr transparent auch genau wir arbeiten in der Regel eher Time and Material. Fixpreis gibt es ja, aber aber
auch ab und an mal. Kommt natürlich drauf an für was. Ich glaube, es kommt für mich so n bisschen der Punkt du, du hast ja viel gesehen, viel Erfahrung jetzt schon gesammelt in dem Bereich. Wenn du jetzt mal schildern würdest und ich weiß nicht ob das geht, vielleicht musst du die eine Partei annehmen oder die andere, aber was wäre denn der goldene schnitt sag ich mal. Was wäre das also, wie sieht das Ideale der ideale Flow aus für so n Softwareprojekt wenn du das beschreiben würdest?
Wir können ja ruhig bei dem Beispiel bleiben von der. Von der Time, von der Zeitmessungsapp, die du, die wir als Beispiel hatten, ja im im im im besten Falle kannst du ruhig noch mal n bisschen durchschildern. Ja, wenn du als Expertin wie baut man sowas aus, welche Prozentsätze, wieviel Zeit geht da drauf und so weiter vielleicht kannst du es einfach noch mal durchixen was deine persönliche Meinung ist, wie man sowas perfekt gestalten würde. Oh. Schwierig, ich weiß es.
Ist schwierig, weil es, man muss wirklich immer schauen, was ist der Kunde, was ist das Projekt und so. Aber wenn wir mal grob davon ausgehen, ich. Von dem Projekt, was wir vorne hatten, dass man eben dann in
dieses Projekt am startet. Diese zeiterfassungs App wird man dann eben sagen, OK man man startet halt in einem Scrum Zyklus rein, vielleicht hat man noch so Setup arbeiten, dass man halt das Team mal zusammenstellt und aufstellt, dass alle ihre Arbeitsumgebung einrichten, dass man mal die Stages aufbaut und so und dann fängt man eben mit mit mit Scrum Sprints an, da gibt es dann eine Spritlänge 2 bis 4 Wochen das das kennt ihr selber auch, das werden auch die ganzen Hörerinnen und Hörer
kennen und idealerweise hat. Begleitet der Requirements Engineer oder die Requirements Engineer, die schon in der ersten Phase ist, eben das Projekt laufend und und verfeinert dann eben die Stories, die es auf grober Ebene schon gibt und und zwar anhand dessen, was der was der Product owner sagt, also vielleicht noch mal für alle diese Rolle Product Owner Product Owner ist eine sehr, sehr wichtige Rolle meiner Meinung nach in so Scrum Teams und weil der Product Owner oder
die Product Ownerin ist die Person.
Die vorgibt, in welche Richtung geht das Projekt, was bringt den größten Business Value, also die Person ist wirklich auch für den für den monetären Erfolg dieses Projektes zuständig, füllt auch das Backlog, priorisiert auch das Backlog und stimmt sich im Hintergrund mit allen Stakeholdern und Stakeholderinnen ab, das heißt, wenn da so eine Firma mit 13 Fachbereichen ist, dann dann ist der Product Owner in der Regel dafür zuständig, dass die alle abgeholt sind, informiert sind
so. So, jetzt aber der Knackpunkt.
Diese Rolle Product Owner ist die totale Wunderfutzi Rolle, weil die Person muss die fachlichen Sachen verstehen, muss die Stakeholder abholen, muss das Backlog befüllen, muss mit den Entwicklern reden, muss monetär wissen worum es geht, also eine Personalunion gibt es eigentlich sehr selten, weswegen wir mit als Requirements Engineers reingehen und sagen, du kannst gerne die Stakeholder abholen und so, wir unterstützen Dich im Hintergrund und helfen dir gute Entscheidungen zu
treffen. Ja, wir dokumentieren auch, wir machen das für dich oder mit dir gemeinsam. Und das ist einfach dann dann so ne Supportrolle, die aber auch super ist. Wenn man natürlich dann auch eigentlich sehr viel mitgestaltet. Also man kann in der Regel gar nicht alles auf einmal machen und genau. Zwischen zwischen Product owner und requirement Engineer das find ich ganz cool, ja. Ja, das es gibt diese Rolle des Proxy Product owner, das habt ihr vielleicht auch schon mal gehört.
Das ist dann jemand. Ja, es ist auch ne.
Es ist so n Hybrid Ding. Also ich find deines Scruming hat so n paar Knackpunkte die Halt in der Realität sich nicht bewährt haben, also Testing Field Requirements Engineering, Field Projektmanagement, Field es gibt zwar Scrum Master und Product owner, aber zum Beispiel diese ganzen monetären Sachen fallen halt völlig hinten runter so und und da muss man, da muss man schon noch n paar Rollen mit da reinsetzen oder sich n gutes Setup überlegen aber ja manchmal ist das so, dass dass man eben
einen Product Owner hat, der Halt schaut, OK. Das ist meine Vision, das ist meine Roadmap MBP, nächster Prototyping Stage und dann kann man vielleicht das erste Produkt ausrollen und priorisiert dann so und im Hintergrund hilft eben ein Requirements Engineer das das alles zu managen und die
Anforderungen zu schreiben. Genau ist ein mögliches Setup, manchmal hat man noch UX Design dabei, der der oder die laufend takeable Prototypes liefert kann man auch schön an die Anforderungen anhängen, ist auch dann ist dann auch eine Anforderung für die Frontend Designer.
Und dann verfeinert man eben von Sprint zu Sprint Stories immer die, die man gerade braucht für die nächsten 123, Sprints, refindy mit dem Team und dann irgendwann hat man eben die Umsetzungserlaubnis oder das Umsetzungs Go von Kunden und die die die Stories werden dann umgesetzt und die Stories, die in der Zukunft liegen, sind in der Regel sehr vage und die, die näher an meinen Zielen liegen, die die nächsten Sprints umgesetzt werden sollen, werden halt dann immer.
Finer gemacht und das hat dann eben den Vorteil, dass wenn sich was im Scope ändert oder man doch n kleineren Richtungswechsel hat, dann muss man nicht alles noch mal neu schreiben. Genau. Und du hast schon von Anfang an alle Stories auf diesem abstrakteren Level oder diesem High Level und dann, das sind User Stories, nehm ich an, oder? Na ja, es gibt epics Features und Stories. Das ist auch in jedem Fachbereich als Quatsch in jeder Branche.
Eigentlich unterschiedlich und auch teilweise ist von Firma zu Firma aber in der Regel sind Epics so ja gröbere. Entweder sind es Releases oder einzelne Apps oder oder ganz grobe Chunks von Dingen die man umsetzen muss, dann gibt es Features, das sind tatsächlich Feature Pakete, das wäre dann sowas wie vielleicht Warenkorb oder oder ach so nein wir sind ja bei der Zeitbuchungs App Zeiten anschauen, Zeiten buchen. QR Code, ein einklickst du hin oder irgendwas, ja.
Das kann, das wär vielleicht fast wieder user Story, weil da drunter kommen dann die User Stories zum Beispiel ja QR Code Scannen oder Zeiten eintragen, Zeiten überprüfen, Zeiten anschauen, das sind dann die kleineren Stories, genau. Also ich, ich sag mal was im technischen Bild. Ich versuch das noch mal n bisschen zusammenzufassen, was
ich gefühlt verstanden habe. Ich weiß nicht, ob unsere Zuhörer das kennen, aber wenn man dann j. Peg NJ PEG Bild ist ne schöne Sache eigentlich, wenn man dann wenn man noch nicht so viel Datenqualität hat und ganz schnell. Ne Bild anzeigen wie mit J. Peg, dann ist das immer schon da.
Das Bild ist ganz schnell da ist zwar noch nicht fein geladen ne und je mehr Netzwerk ich habe desto desto feiner dröselt sich das aus bis ich irgendwann voller Auflösung hab ne ich find das ist n schönes Beispiel für vielleicht was wir da jetzt gesagt haben also wenn ich jetzt in n Erstgespräch mit einem Kunden komme versuche ich NJ PEG Bild möglichst vollständig erstmal zu haben, das ist noch nicht fein aufgelöst aber es zeigt schon mal. So die Borderlines, wo das ganze
Projekt hingeht. Ich glaube, das hast du gesagt, wenn ihr am Anfang halt ist das Requirement Engineering schon so, sie versuchen nen Komplettüberblick zu haben, weil das Brauch ich für alles möglich, das brauch ich für für ne ungefähre Abschätzung der Zeit, für die für die, für die Finanzplanung und so weiter und sofort ja und jetzt und mit mit diesem Ding fang ich an loszufahren und während das Projekt läuft verfeinert sich quasi das nennst du refinement
glaub ich verfeinert sich quasi. Zeile für Zeile immer wieder. Aber das ganze Bild, vielleicht sogar ja, man arbeitet ja auch vielleicht gar nicht von vorne nach hinten, sondern das Projekt wird irgendwie gleichzeitig von verschiedenen Teams bearbeitet.
Insgesamt wird quasi die Auflösung etwas verfeinert und in diesem Prozess nehme ich quasi meinen Kunden mit, möglichst das ist ja quasi in diesen Scrum Prozess eingehakt, wo ich vielleicht alle 4 Wochen mal im Zwischenstand zeige, wie sieht das aus, ja. Und komme im im besten Falle, wenn das Bild scharf ist, da an bei dem Bild die das beide im Kopf hatten ganz am Anfang ja ziemlich sowohl der Kunde als auch der Dienstleister und damit das gut funktioniert, versuchen
wir am Anfang das ist mir glaub ich auch gesagt, das ist für mich auch NN wichtiger Punkt über ich darf auch noch mal sagen weil es mir einfach so wichtig ist dieses dieses noch unscharfe Bild, aber das müssen wir, das muss sich der Kunde und der Dienstleister lange angucken und lange darüber diskutieren, dass genau beide davon verstehen was das werden will und wenn das n bisschen schärfer wird, was da so ungefähr aufploppt und ich glaube. Und das sind diese 20%, von
denen wir gesprochen haben. Sind die vielleicht mach ich auch irgendwas nur mal, um dieses Bild quasi wirklich anzuzeigen, mehr oder weniger noch n bisschen unscharf, aber schon mal so, dass man, dass man genau weiß, wo die Reise hingeht, grob ja, ich weiß nicht, ob das ob diese Anekdote, da dieses insgesamt, dieses Bild ganz gut passt, aber so n bisschen, so stell ich mir nen optimalen ja Prozess vor für so
n softwareprojekt. Ja, ich glaube so n bisschen bei dir auch, aber du kannst mich ja gern noch mal wegrätschen, wenn ich irgendwas vergessen hab, oder? Nein, nein, das passt total gut und ich glaub, der Knackpunkt ist, der Kunde muss sich das, während das Bild sich verfeinert sich das immer wieder noch mal neu mit anschauen und das ist halt was, das muss man wirklich einfordern.
Also wir sagen den Kunden, wir wollen sie da gern dabei haben, sie müssen sich auch die Zeit dafür nehmen, weil es vielleicht nicht wenn sie am Anfang einmal auf das Kästchen gucken und dann ganz am Ende halt das fertige Bild sich anschauen und dann sagen, Oh na so hab ich das aber nicht gewollt, sondern wir machen halt das Bild Stückchen für Stückchen und damit der Kunde dann halt sagen kann Stopp. Alles stimmt, nur das stimmt nicht.
Da müssen wir noch mal drüber reden und, und das ist halt total wichtig und finde ich extrem wichtig, die Kunden das einzubinden, auch wenn man sich vielleicht gefühlt, vielleicht manchmal auch mehrere Wochen lang das Gleiche anschaut. Nein, ist es nicht, im Hintergrund tut sich ja manchmal auch sehr viel, also da, da ist man wirklich dann gefragt, den Kunden so mitzunehmen, dass dass der Kunde immer auch weiß, wo stehen wir da gerade und was wird gerade gemacht und so und
warum. Das das ist auch was, was ich
erlebt habe. Man muss manchmal da den Kunden n bisschen antreiben, weil gefühlt hat der Kunde Spaß und Lust am Anfang vom Projekt. Man hat auch Spaß und Lust sich Stattzunehmen, das ist irgendwie gefühlt, wenn es fertig ist zu testen, aber er hat irgendwie gar keine Lust zwischendurch irgendwie aktiv zu werden, hat er 1000 andere Sachen zu tun, so lass das mal die Entwickler machen, das ist irgendwie gefühlt nicht meine Aufgabe und gefühlt sind ja auch Kunden
schlecht gelaunt wenn sie halbfertige Sachen angucken. Es ist auch, es ist auch n sehr schmaler Grat, weil dann dann wird noch dann, dann denkt man so, oh, das ist ja alles noch kaputt, das ploppen vielleicht hier und da noch Fehler, weil es
ganz klar noch nicht fertig ist. So ja, und man ist als Dienstleister dabei zu erklären, ja, ja, er kommt ja noch und dann kommt irgendwie irgendwie, so ist das noch nicht fertig und so gefühlt sind diese Zwischenmeetings nicht so einfach, psychologisch, technisch und so weiter und ich versuche immer, aber die gibt es und die sind so wichtig wie du
es sagst. Ich glaube, es ist total wichtig, irgendwie gute Laune zu verbreiten bei diesen Meetings und irgendwie auch schon irgendwie Motivation und und Zuversicht abzustrahlen als Dienstleister, dass das schon werden wird, aber das ist, ich weiß nicht wie du die kennst, ob du auch mit vielen von solchen Meetings dabei bist. Das finde ich manchmal auch ne krasse Herausforderung irgendwie, da da ne gute Atmosphäre zu zu balancieren. Ja zwischen Kunde und Dienstleister.
Ja, ich find gerade da helfen auch Requirements Engineers oder manchmal eben auch UX Designer extrem. Weil ich also wie soll ich das sagen? Die meisten Softwarearchitekten und Architektinnen, die ich kenne, sind sehr auf ihre Arbeit in der Programmierung fokussiert und wollen sich gar nicht damit auseinandersetzen.
Wenn jemand das also so diese gute Laune zu verbreiten, weil es ist ja auch, es ist ja auch eine Kunst, dann in so einem Meeting unwieehrbar gute Laune zu verbreiten, und ich sehe das auch ein bisschen als meinen Job, dass ich das dann weghalte von meinen eher, das sind die Leute, die ich kenne von meinen Grumpy entwicklerkollegen, die da sagen, Boah, da habe ich jetzt überhaupt keine Lust, ich habe es doch immer super Sachen
gebaut. Und dann kommt da jemand, sagt, Boah, das Grün ist aber doof und man denkt sich so, oh mein Gott, ich hab da einmal diesen Hashwert mit 6 Ziffern, das ist einfach das Grüne, dass ich gefunden hab und all die anderen Sachen, die ich drum herum gebaut habe.
Oh mein Gott, und dann ist das so kein Problem, du das Grün, das ändern wir gleich und dann redet man halt eine Stunde über das Grün und und sagt, dass man das Ausbessert und so, und dann hat man die gute Laune schon geschafft und und am Ende des Tages wird es dann. Abgenommen, wenn man nur das Grün ändert, ist eigentlich der beste Fall. Da muss man, muss man, dann kann man dann beide Seiten beruhigen.
Man kann den Kunden beruhigen und sagen, Boah ja, sorry, wir machen das und dann kann man die Entwicklungskollegen auch beruhigen, sagen du reg dich nicht auf, es ist alles super, das ist super gebaut, wenn die Person sich über das Grün aufregt, das heißt es ist meiner Meinung nach auch ein Teil des Jobs, dann dann zu schauen, dass alle Seiten zufrieden sind und sich verstehen, also oft ist man echt in dieser Dolmetschrolle
und gut ich also. Und gerade die bisschen seniorigerinnen oder Lead Level Consultants sind da manchmal auch so. So was wie Psychologen oder Krisenmanager oder so. Also aber ich finde persönlich, ich finde persönlich, das ist auch ein Teil des Jobs, weil man hat sehr viel mit Menschen zu tun, mit sehr vielen unterschiedlichen Menschen, ich bin auch immer sehr neugierig auf neue Menschen und man lernt einfach sehr viel kennen, man lernt sehr viel Branchen kennen, man lernt sehr viel Leute
kennen, man lernt drauf gut drauf zu hören, dass Leute eigentlich wirklich wollen oder brauchen. Und man hilft am Ende des Tages hilft man halt auch Leuten, erfolgreich zu sein und dafür gehört halt eben nicht nur die Technik, sondern dazu gehört halt auch diese menschliche Komponente und ich finde das total spannend.
Also es, ich finde das eigentlich am spannendsten, muss ich sagen, also Technik hin oder her, ich rede auch gerne darüber, wie man Leuten helfen kann, das ist vielleicht also ja. Irgendwann geht es einem leicht von der Hand. Deswegen bist du ja auch in deinem Job, den du hast. Ja, schon. Ich mag das. Ich lerne gerne Leute kennen und und schaue, dass sie erfolgreich sind.
Das ist tatsächlich deswegen. Also ich sehe das gar nicht so mit Borderline, jetzt muss ich wieder gute Laune verbreiten, sondern ja, jetzt schaue ich mal was, also jetzt versuche ich natürlich, das zu verkaufen, was meine Kollegen programmiert haben, weil ich habe bisher nur mit sehr guten Leuten zusammengearbeitet, die richtig tolle Sachen bauen, und manchmal hängt sich es dann an Kleinigkeiten an und schau dann OK. Wie kann man jetzt eigentlich
das Ganze zum Erfolg machen? Du machst dir n Bier auf, hast du noch eine Flasche? Ja, das. War. Doch das Wort zum Sonntag und zum Sonntag, ja ich, ich wollt das erst mal so sacken lassen.
Jetzt, was du gesagt hast. Es klang ja erst mal auch wie n Cooles. Also ja, war zum Sonntag Zusammenfassung zum Ende noch mal n bisschen was emotionales, Persönliches da drinne, aber dennoch es wenn ja vielleicht sagst du wir wir sollten noch mal über irgendwas fachliches Reden im im Requirements Engineering, das war jetzt noch nicht. Besprochen haben bisher wo du sagst, da müssen wir auf jeden Fall noch mal darauf eingehen, dass Hamburg hat den Gerät jetzt vergessen.
Zu Fragen gibt's da irgendwas? Ja, vielleicht noch eine Sache, die für uns mittlerweile sehr, sehr wichtig ist. Und zwar, das ist das Thema Qualitätssicherung. Das ist vielleicht auch für die Hörerinnen und Hörer noch interessant, weil Kunden oft herkommen zu meinem Kollegen, also mein, mein Kollege leitet die Testingabteilung und sie sagen dann, ja, wir wollen gerne unsere Software von ihnen testen lassen, ist ja auch mal schön, wenn man next, also jemand.
Einen externen Anbieter dann testen lässt oder nicht?
Die Partei, die programmiert, dann auch testen lässt oder jemand anderen und oft kommt mein Kollege mit seinen Mitarbeiterinnen und Mitarbeitern dann rein und sagt, Na ja, aber wo gehen gegen sollen wir den testen, es gibt ja gar keine Anforderungen und das kann man wirklich so ein bisschen als qualitätssicherungsklammer oder oder als Loop oder so bezeichnen, dass wenn man gute Anforderungen hat, zum Beispiel als User Stories mit Akzeptanzkriterien. Kann man daraus gute Testcases
mit Abnahmekriterien schreiben und kann so 1 zu 1 schauen? Was ist vorne reingekommen und was ist hinten rausgekommen oder vorne reingegangen, was ist hinten rausgekommen und kann so
sehr gut sehr gut. Also man kann die Entwicklung eigentlich wie eine Blackbox behandeln und wenn man jetzt über das Thema Blackbox nachdenkt und dann eben wieder deswegen, sage ich die ganze Zeit near Shoring of shoring KI, dann hat man eigentlich ein sehr gutes Handwerkszeug, auch so Bereiche, die man vielleicht jetzt nicht zu 100%. Kontrollieren kann oder auch nicht.
Möchte dann trotzdem gut Qualität zu sichern und das ist glaube ich ein ein Punkt, der ist sehr wichtig, weswegen ich das noch mal extra erwähnen möchte und und führt auch zu sehr viel Klarheit auf allen Seiten, gerade auch von den Kunden. Also die Kunden wissen sehr genau, was sie zu erwarten haben und sehen am Ende sehr gut was sie bekommen und das ist eigentlich nur positiv meiner Meinung nach. Mit der Blackbox meinst du jetzt, das kann jetzt irgendwo passieren, diese Programmierung?
Ja, aber ich hab ja vorher gut meine User Stories geschrieben und kann also nachher. Gut gegen diese User Stories testen und alles was dazwischen passiert lass ich mal außer 8 in diesem in diesem Modell jetzt mal kurz ja. Ja, aber man man hat so ein bisschen, man kann dann besser
schlafen. Also oft ist jetzt gerade diese offshoring Szenarien sind mit sehr viel Schrecken verbunden, dass man sagt, ja, dann habe ich, habe ich halt dem Team aus XY gesagt, das soll was programmieren und und dann kommt irgendwas ganz anderes. Gibt's viele verschiedene
Erklärungsansätze? Meiner Meinung nach kann man aber sehr genau definieren, was man haben möchte, vielleicht sogar mit Visual Prototypes und mit Akzeptanzkriterien und kann das am Ende sehr gut testen, wenn man halt testcases Abnahmekriterien hat und dann sieht man eh sehr schnell was. Was habe ich eigentlich gefordert und was habe ich dann bekommen und meistens funktioniert das dann. OK, also man hat's selber in der Hand. Ja, also natürlich nicht zu 100%, aber.
Es ist halt was, was ich gerne euch und vielleicht auch den Hörerinnen und Hörern mitgeben möchte. Das ist ja weiß ich nicht, man muss sich manchmal die eigene Nase fassen, ne, also man kann nicht immer auf die anderen schimpfen, weil man kann sich fragen, was kann ich besser machen, damit mein Erfolg zum mein Projekt zum Erfolg wird und dann, ja, vielleicht muss ich einfach besser spezifizieren was ich haben möchte, vielleicht kommt dann eher das raus, was
ich gerne haben möchte. Ganz bestimmt, ganz bestimmt,
weil ich glaube, dass. Und je mehr Personalunion man hat, desto weniger wird das vielleicht gemocht, weil die ich, ich kann das sagen, als als eher Techniker und gerne programmierender im Herzen macht man alles, das nicht gerne, was einen davon abhält und user Stories aufzuschreiben, Anforderungen festzuziehen, die zu refinen, die ja auch zu warten und zu Maintainen über den Lauf des Projektes, das ist was, was Softwareentwickler jetzt erstmal nicht so aus
eigenem Antrieb machen würden. Und wenn es dann diese Rolle nicht gibt oder den Druck nicht gibt, auch eher vielleicht
weglassen würden. Insofern es ist, es ist glaub ich ne wichtige ne wichtige Sache und ich glaub du sprichst jetzt nicht von 2 Seiten oder 3 Seiten im powerpoint jetzt ich nehm noch mal unser Beispiel dieser relativ einfachen zeiterfassungs App ohne viel Gedöns und so weiter aber du sprichst wahrscheinlich von mindestens 10 Seiten oder vielleicht sogar 20 Seiten irgendwie Text mit Bildern und so n paar Diagrammen dabei und so weiter was dann für dieses
Projekt die Anforderungen. Ja, und nicht in jedem kleinen Detail, beschreibt weil. Das ist ja das Source Code selber, sondern irgendwie n gutes Level.
Findet es so zu beschreiben, vor allen Dingen, ich glaube das ist halt die Audienz und das ist ja hauptsächlich der Kunde mit auf seinem technischen Level gut nachvollziehen und verstehen kann ne. Ja oder halt 3 bis 5 features mit 20 bis 40 user Stories und dann ist man in der Regel schon dabei und vielleicht ein clickable Prototype, aber find ich witzig, dass du sagst, dass du das auch nicht gerne machst.
Find ich lustig, weil. Also ich, ich muss ja auch sagen, ich genieß das immer n bisschen in den in den Projekten, wo ich immer requirements Engineer war, waren die meisten Entwickler und Entwicklerinnen immer Fan von mir. Das heißt, man kann sich da auch unheimlich beliebt machen, man muss noch mal Schokolade mitbringen, man muss einfach nur das dokumentieren, worauf die anderen keinen Bock haben und sehr viel reden, also man kann auch intern da für für gute Stimmung sorgen.
Das glaub ich dir sofort. Ja OK. Sag gut, ja, Dankeschön, dass du das noch hinzugefügt hast jetzt. Macht total Sinn. Ja, also klar Qualitätskontrolle am Ende wird natürlich einfacher, wenn ich vorher genau beschrieben hab was ich brauche. Ja ist ja auch logisch, dann wir können ja magst du noch mal n bisschen erzählen was ihr bei der MSG plaut macht, für was man euch vielleicht kontaktieren darf, das soll auf jeden Fall auch nicht zu kurz kommen.
Ja, also ich bin bei der MSG PLAUT hier in Wien. Wir sind aber Teil der MSG Gruppe. Die MSG Gruppe ist hauptsächlich im Dachraum unterwegs mit Hauptsitz in München, Wir sind ein IT Beratungsunternehmen, Wir
machen. Viele Dinge. Wir haben mal mit SAP Lösungen für den Versicherungsbereich angefangen, machen aber viel, viel mehr, sind natürlich in erster Linie ein SAP Haus, haben aber bei uns in Wien zum Beispiel Individualsoftwareentwicklung, wo auch ich angesiedelt bin, als auch Lösungen im Microsoft Bereich und bespielen eben verschiedene Branchen.
Also unsere Hauptbranchen sind Banking, Versicherungen, produzierende Betriebe und der öffentliche Bereich, das heißt immer wenn es wenn es den Wunsch gibt nach verschiedenen technischen Lösungen digitalisierungs. Lösung in einem der Bereiche kann man sich gerne bei mir melden oder auch zum Thema Requirements Engineering. Wir haben da viele tolle Lösungen, genau und sonst auch.
Wir finden eigentlich meistens die passende Lösung für den jeweiligen Anlassfall, da wir natürlich dann auch noch die große Muttergesellschaft im im Rücken haben. Wir verlinken alles in den Shownotes, damit ihr auch da reinschauen könnt. Und da würde ich sagen, passt es zum Thema Requirements Engineering. Vielen herzlichen Dank, dass du. Heute zu Gast warst und ja, bis bald. Ja, danke für die Einladung und hoffe ich konnte euch ein bisschen begeistern.
Ciao, auf jeden Fall. Wenn ja, vielen dank, Tschüss. Einfach komplex wird produziert und präsentiert von Heisenware Heisenware ist deine Loco Plattform zur Erstellung und zum Betrieb interaktiver Apps rund um den Shopfloor. Starte noch heute deinen Free Twil unterheisenware.com einfach komplex.