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.