[0:20] Heute möchte ich mich mal mit einem Thema beschäftigen, was in, ja, eigentlich allen IT-Abschlussprojekten für die IHK-Prüfung relevant ist, und zwar die Stakeholder bei deinem Projekt. Welche es da so gibt, was die für Anforderungen haben könnten und welche du vielleicht vergessen hast bei deiner Stakeholder-Analyse, darüber wollen wir heute mal sprechen, sehe ich nämlich ganz oft. Normalerweise gehört zu jedem IT-Projekt, egal welche Fachrichtung, Systemmitigation, Anwendungsentwicklung, kaufmännisch, ganz egal, müssen wir eine Ist-Analyse machen, eine Anforderungsanalyse, sorry, bringe ich ein bisschen durcheinander gerade, die Anforderungsanalyse. Um die soll es heute gehen. Das heißt, welche Anforderungen soll dein Projekt überhaupt umsetzen? Und das ist ganz egal, ob ich eine Software entwickle oder irgendein System installiere, konfiguriere oder irgendein Angebot berechne. Ganz egal, was ich für ein Abschlussprojekt habe, es geht immer darum, wer will eigentlich was haben und für wen mache ich das und was wollen diese, meistens sind es Menschen oder Rollen oder Organisationen, Institutionen können es auch sein, wir gleich nochmal sehen, was wollen die von mir? Was haben die für konkrete Anforderungen an mein Projekt? Und diese Anforderungen muss ich aufnehmen, die muss ich dokumentieren, die muss ich im besten Fall priorisieren, die muss ich verfeinern und konkretisieren. Mit diesen Anforderungen steht und fällt der Erfolg meines Projekts. Denn du kennst vielleicht noch aus einer der unzähligen anderen Episoden, wo ich das Thema angesprochen habe, die Definition von Qualität.

[1:39] Qualität ist der Grad der Übereinstimmung mit den Anforderungen. Und wenn ich keine Anforderungen habe oder die Anforderungen halb habe oder vergessen habe oder unklar habe, dann weiß ich gar nicht, ob ich qualitativ gearbeitet habe, ob ich fertig bin, ob das Projekt wirklich das tut, was es soll, weil ich eine Anforderung übersehen habe, vergessen habe etc. Und woher kriege ich die Anforderungen von meinen Stakeholdern? Da erzähle ich auch immer gerne die witzige Geschichte, dass ein Prüfling in der Projektpräsentation das mal mit E-A geschrieben hat, also Steak, wie das Steak, was ich auf den Grill lege. Aber darum geht es hier natürlich nicht, sondern es geht um das englische Wort Steak, was leider genauso ausgesprochen wird, aber anders geschrieben wird, nämlich S-T-A-K-E. Stake ist das englische Wort für sowas wie, ja, wie soll ich sagen, so ein Stock oder eine Begrenzung. Ich erkläre das immer so. Die Gründerväter der USA, die da in die Wildnis aufgebrochen sind und gesagt haben, so, das Land gehört jetzt mir, haben die so einen Stock in den Boden gerammt und gesagt, so, das ist jetzt die Grenze. So, Grenzsteine. Ab jetzt ist das meine Farm.

[2:36] Wir wollen nicht drüber reden, ob das eine gute Idee war da damals, aber so ist es halt gelaufen. Und diese Stakeholder, die diesen Stock in der Hand haben, die haben gesagt, so, das ist es jetzt und jetzt gehört es mir. Und diese Stakeholder übertragen wir jetzt mal auf mein Projekt und überlegen uns, welche Personen, Institutionen, wie auch immer gerade aufgelistet, haben Interesse an meinem Projekt und haben Anforderungen für mich und an mein Projekt. Und dann ist es meine Aufgabe, als Anbietungsentwicklerin, als FISI, als Kaufmanager, IT-Mensch, was auch immer, das auszuwerten, was für Stakeholder es überhaupt gibt und was die für Anforderungen haben. Und das schmeißen wir dann alles in ein großes Dokument. Sei es ein Lastenheft, wenn ich ganz klassisch im Wasserfall unterwegs bin. Seien es User-Stories für agile Projekte. Ganz egal, aber in irgendeiner Form werden wir die Anforderungen verwalten müssen. Das gilt für jedes Projekt, egal welcher Fachrichtung. Ich muss mir erstmal klar werden, was soll überhaupt gemacht werden. Denn wenn ich nicht weiß, wo ich hin soll, wie weiß ich dann, ob ich das Ziel erreicht habe. Geht nicht. Also, ich brauche die Anforderungen, gehört für mich in jedem, jedem, jedem Projekt dazu. So.

[3:40] Und jetzt haben wir oft das Projekt, das Projekt, das Problem, dass die Prüflinge leider vergessen, wen man denn vielleicht noch hätte fragen sollen zu so einem Projekt. Denn ganz oft denkt man nur an den Kunden, der, der das am Ende bezahlt oder an die Benutzer, die das am Ende benutzen, die Software. Auch okay. Übrigens nicht das gleiche, Kunde und Benutzer. Kommen wir gleich nochmal drauf. Und dann vergisst man halt die 27 anderen Stakeholder, die es theoretisch auch noch geben könnte, die aber vielleicht auch harte Anforderungen an meinem Projekt haben. Ja, und dann gehen wir gleich mal eine konkrete Liste durch mit einigen potenziellen Stakeholdern, an denen du dich dann so ein bisschen orientieren kannst und dich davon inspirieren lassen kannst. Ja, und was passiert, wenn ich nur einen Stakeholder frage? Ja, ich vergesse natürlich ganz viel und am Ende scheitert das Projekt, weil irgendwer sagt, Moment mal, hast du daran eigentlich auch gedacht? Oh, nö, den habe ich leider nicht gefragt. Ja, doof gelaufen. Da kannst du mal von vorne anfangen oder das Projekt umbauen oder es ist gescheitert oder wie auch immer. Das wollen wir natürlich nicht. Also, das Ziel soll sein, alle relevanten Stakeholder zu identifizieren und natürlich von denen auch die Anforderungen zu bekommen, damit dein Projekt dann auch genau weiß, was da zu tun ist. Ja, okay. Fangen wir ganz vorne an. Definition. Stakeholder. Was ist das eigentlich? Also ich habe gerade gesagt, wie er nicht geschrieben wird, wie das Stake.

[4:54] Also es ist halt irgendjemand, der oder die Interesse an deinem Projekt hat. So ganz allgemein formuliert. Einige sagen auch, es müssen Menschen sein, die irgendwie Einfluss auf dein Projekt haben. Ja, weiß nicht. Also ich würde das ganz allgemein formulieren, alle, die irgendetwas mit deinem Projekt zu tun haben, weil sie daran interessiert sind, weil sie vielleicht Einfluss drauf haben, weil sie davon betroffen sind. Beispiel, du baust eine Software und die Menschen müssen die Software am Ende benutzen, werden sie natürlich davon betroffen.

[5:22] Aber, und ich fasse das gleich schon mal weiter, auch alles, woran man vielleicht nicht offensichtlich denkt, zum Beispiel, wenn du dein IT-Projekt hier in Deutschland umsetzt, gelten deutsche Gesetze, an die du dich halten musst, zum Beispiel. Aber ich greife schon ein bisschen vorweg, die konkrete Liste, die ich dir vorstellen möchte, die gehen wir ja gleich einmal durch. Wichtig ist, wie gesagt, dass du an alles denkst. Sind die alle für dein Projekt immer relevant? Nein, genau. Du musst also jetzt nicht alle, ich weiß gar nicht, wie viele sind, 10, 15 Stakeholder, die ich gleich aufzähle, müssen nicht für dein Projekt gültig sein. Aber als Idee, denk mal dran, vielleicht hast du einen übersehen. Also bitte nicht so verstehen wie, ich muss jetzt diese Liste abarbeiten, sondern für bestimmte Projekte gibt es auch nicht alle diese Stakeholder. Ich will dir nur zeigen, welche es geben könnte, damit du keinen vergisst.

[6:07] Und jetzt gehen wir mal die Liste durch. Ich habe konkrete Stakeholder mal mitgebracht. Fangen wir ganz von an. Kunde, Auftraggeber. Und gerne auch Kundin oder Auftraggeberin natürlich. Und ich habe jetzt immer dazu aufgelistet, was für Interessen die haben könnten, beziehungsweise was für Anforderungen die haben können. Und Kunde, Kundin möchte natürlich gerne, dass das Budget eingehalten wird, weil, um das kurz abzugrenzen von dem nächsten Stakeholder, den ich mal eben vorgreife, nämlich Endbenutzerinnen, also die, die wirklich mit dem System am Ende arbeiten, wenn du eine Software programmierst, die, die mit der Software nachher rumklicken müssen, das sind die Endbenutzer. Und das sind nicht zwangsläufig die Kundinnen. Kundinnen sind die, die dir das Geld bezahlen, die sagen, so mach das mal bitte für mich. Das könnte zum Beispiel, Klischee, der Chef eines Unternehmens sein, der will, dass du da was programmierst, aber der Chef benutzt die Software am Ende gar nicht, sondern seine Mitarbeitende benutzen die, um das kurz abzugrenzen. Also, Kunde möchte Budget einhalten, Termine einhalten und vor allem die Business-Ziele erreichen. Ich will eine Rechnungswesen-Software programmiert haben, ja, dann sollte die am besten nachher auch Rechnungswesen können. Das wäre schon ganz gut. Also, das möchte der oder die Kundin von dir haben. Und der oder die Endbenutzerin, die am Ende damit arbeiten, die haben vielleicht ganz andere Anforderungen. Zum Beispiel wollen die, dass man das Ding einfach bedienen kann. Was interessiert die das eingehaltene Budget? Das müssen die ja nicht bezahlen. Aber wenn ich jeden Tag dreimal klicken muss, obwohl ich es auch mit einem Klick hätte machen können, das nervt die Leute natürlich. Also einfache Bedienung, Performance, Zuverlässigkeit. Wir sind jetzt hier so ein bisschen auch quasi schon bei den Softwarequalitätsmerkmalen aus der ISO-Norm.

[7:32] Ich muss jetzt so ein bisschen aufpassen, dass sich das hier nicht nur auf Softwareentwicklung bezieht. Das ist natürlich meine Stärke, keine Frage. Aber für alle anderen IT-Berufe ist es natürlich genauso. Es wird irgendeinen Endbenutzer, Endbenutzerin geben. Wenn ich als FISI ein neues System aufsetze, was auch immer mir da jetzt ein Fall fällt, ich installiere ein neues Active Directory, dann sind meine Endbenutzerinnen halt meine Admin-Kollegen, die den ganzen Tag damit arbeiten. Dann wollen die auch, dass das einfach zu bedienen ist, performant läuft und zuverlässig. Also es geht hier nicht nur um Softwareentwicklung, auch wenn sich viele Beispiele bei mir mal drauf beziehen. Also, die haben so Usability-Anforderungen mindestens mal an die Software. So, was haben wir noch für Stakeholder?

[8:11] Projektleitung. Naja, in deinem eigenen Projekt bist du das, aber auch du darfst natürlich Anforderungen an dein Projekt stellen. Das vergessen auch ganz viele. Es sind ja nicht immer nur Leute, die von extern kommen und sagen, ich will da was, sondern du als Umsetzende hast natürlich auch Anforderungen. Und bei der Projektleitung sieht man das. Zum Beispiel Planungssicherheit für dein IHK-Projekt von höchster Wichtigkeit. Du hast 80 oder 40 Stunden, mehr nicht. Wenn du jetzt irgendwas einplanst und deine Kollegen, Kolleginnen verspäten sich, externe Dienstleister kommen nicht in eine Pötte, was auch immer, und auf einmal sind deine 80 oder 40 Stunden bedroht, das ist schlecht, weil dann könntest du im Extremfall durch die Prüfung fallen. Das heißt, Planungssicherheit wäre vielleicht ganz wichtig und auch in echten Projekten natürlich, wollen die Leute, wenn am 1.1. Eingeführt werden soll, nicht, dass es erst am 3.1. fertig ist, ist klar. Ja, Risikominimierung, Reporting ist vielleicht auch interessant. Ich mache jetzt hier ein paar allgemeine Punkte, nicht nur fürs IHK-Projekt, deswegen ist davon vielleicht nicht alles relevant. Aber es gibt zum Beispiel auch Projekte in großen Konzernen, die umgesetzt werden. Da muss dann zum Beispiel auch ein Reporting stattfinden, irgendwie an den Vorgesetzten oder an die IT-Betriebsabteilung, dass da jetzt eine neue Ablikation fertig ist oder was auch immer. Das müsste man auch mit einplanen vielleicht.

[9:21] So, nächster Stakeholder oder Stakeholderin. Entwicklerinnen bzw. Die Admins, die ich gerade schon angesprochen habe. Also die, die die Systeme entweder weiterentwickeln oder im Betrieb nachher täglich sich drum kümmern müssen. Und die wollen dann zum Beispiel wartbaren Code. Ich will nicht irgendeine Grütze und heutzutage vor allem irgendeinen KI-Slop, der dahin generiert wurde und dann kümmert sich irgendwer anders die nächsten fünf Jahre darum, den Scheiß wieder aufzuräumen. Ich will jetzt nicht auf KI bashen. KI macht schon coolen Code. Auf jeden Fall geht es mir allgemein darum, wartbarer Code, damit nicht die nächsten fünf Jahre sich irgendwer jeden Tag die Haare ausreißt, wenn er diesen Code betreuen muss. Und stabile Systeme für die Upmands. Die wollen nicht fünfmal am Tag ein Server neu starten, weil du es schlecht programmiert hast oder schlecht installiert hast. Das wären so Beispiele für deren Anforderungen. Machen wir das konkret. Anwendungsentwicklerinnen, was wollen die noch haben? Die haben vielleicht auch UX, UI-Anforderungen. Das soll ja irgendwie schick aussehen zum Beispiel und natürlich gut bedienbar sein. Vielleicht haben wir Barrierefreiheit, dass wir mit einbauen müssen. Die Anwendungsentwicklung möchte natürlich, wenn du eine API baust, dass die stabil ist, dass sie sich nicht alle zwei Tage ändert. Oh, ich habe noch ein Parameter vergessen, tut mir leid. Das Ding soll natürlich testbar sein. Ich will nicht händisch alles durchklicken müssen nach einem Release, um zu gucken, ob es läuft. Ich will Unit-Tests anstellen oder ich brauche eine Bild-Pipeline, wo das durchläuft. Ich will das Ding automatisch deployen können. Ich will nicht einen Zip-File irgendwo hart auf der Produktion entpacken und dann in alten Ordner löschen und hoffen, dass alles läuft. Ich will einen definierten Deployment-Prozess zum Beispiel haben.

[10:43] Gehen wir konkret auf den nächsten Stakeholder, die Systemintegration. Was wollen die? Die wollen vielleicht von ihren Systemen, was auch immer, da geht es häufig um kritische Sachen wie Firewalls, Backup-Lösungen etc. Die wollen natürlich eine hohe Verfügbarkeit haben. Die wollen das Ding vielleicht skalieren können, wenn es zu langsam wird. Die brauchen natürlich ein Monitoring, ob das Teil noch läuft. Die wollen Alerts haben, wenn es nicht mehr läuft und so weiter. Das kann man alles auf harte Anforderungen auf dein Projekt ummünzen.

[11:07] Beispiel API-Stabilität für Anwendungsumwicklung. Da muss ich mir vielleicht mal vorher Gedanken machen, wie die API aussieht und nicht einfach irgendwas entwickeln und hoffen, dass ich nichts vergessen habe. Oder Monitoring. Muss ich halt dran denken, wenn ich eine Software zum Beispiel auswähle als Systemintegratorin, dass sie vielleicht auch definierte Standardschnittstellen anbietet, um in mein Monitoring-System eingehängt werden zu können und ich mir dann nicht irgendwie selber was zusammenzimmern muss.

[11:29] Dann, IT-Betrieb und Support wird häufig vergessen. Das Ding wird, wenn ich das eingeführt habe, normalerweise vielleicht ein bisschen laufen. Außer ich schmeiße das Projekt sofort weg, wenn es fertig ist. Aber ich hoffe nicht, dass das passiert. Das heißt, es wird vielleicht Jahre im Betrieb sein. Und in der Zeit, wer kümmert sich? Naja, wer ist erster Ansprechpartner, Ansprechpartnerin für unsere Mitarbeitenden oder die Kunden? Der Support. Und die wollen natürlich auch, dass das Ding wartbar ist. Die haben jetzt nicht Code-Wartbarkeit im Hintergrund, aber zum Beispiel, keine Ahnung, Das Ding legt ständig irgendwelche Temp-Dateien an, die ich händisch löschen muss. Wäre blöd, vielleicht sollte das Teil das lieber selber aufräumen. Ganz wichtig für den Betrieb, irgendeine Form von Logging, dass da irgendwie genau protokolliert wird, was ist schiefgelaufen, was war der Fehler, damit man im Fehlerfall auch reagieren kann und weiß, was passiert ist. Und natürlich auch die Dokumentation. Irgendwo ist ein Fehler, was ist jetzt überhaupt der Prozess, wen kann ich anrufen, wie kann ich das Ding, darf ich das Ding einfach neu starten oder muss ich bestimmte Schritte der Reihe nach durchführen? Also eine klassische Dokumentation, ganz wichtig für diesen Bereich.

[12:26] So, und jetzt kommen wir so ein bisschen zu Stakeholdern, die eher mal vergessen werden oder gar nicht auf dem Zettel sind, dass die überhaupt gibt. Und wir sind nun in der EU, zumindest in Deutschland, da gilt natürlich die DSGVO. Das heißt, Oberpunkt Datenschutz bzw. Compliance noch etwas weiter befasst. Und da gibt es, je nachdem, in welchem Unternehmen du arbeitest, hunderte von Vorgaben. Also, Datenschutz sind nur ein paar, aber zusätzlich, wenn man Compliance noch mit dazu nimmt, gibt es ja die wildesten Vorschriften und Regeln, die man einhalten muss. Das geht von erzwungene Code-Reviews, wenn du was programmierst oder Vier-Augen-Prinzip oder jetzt ganz neu die DORA, der Digital Operational Resilience Act. Du musst vielleicht sogar ein Monitoring mit einbauen, weil die EU das jetzt fordert für dein Projekt. Das heißt, da können solche Sachen rauskommen wie DSGVO-Konformität, Datensparsamkeit. Du darfst nicht einfach alles erfassen, was du willst. Du musst vielleicht explizit Zugriffskontrollen, Monitoring, Resilience-Zeug einbauen, weil irgendeine Vorgabe das von dir erfohlen wird. Ganz harte Vorgaben tatsächlich auch für Softwareprojekte.

[13:28] Um das noch weiter zu führen, Staat und Gesetzgeber würde ich darüber hinaus nochmal sehen, weil je nach Branche hast du auch ganz harte gesetzliche Vorgaben. Ich bin jetzt in einer privaten Krankenversicherung, da kommt gefühlt jedes Jahr irgendein neues Gesetz raus, das wieder irgendwelche harten Vorgaben für unsere Produkte und für unsere Softwareentwicklung insbesondere macht. Wir haben ganz neu, als ich das hier aufnehme, das Barrierefreiheitsstärkungsgesetz. Das heißt, du wirst eventuell verpflichtet, deine Software barrierefrei zu bauen oder, wenn du zum Beispiel fisi bist, eine auszuwählen, die barrierefrei ist, weil dein Unternehmen eben barrierefreie Sachen anbieten muss. Oder natürlich ganz klassisch Aufbewahrungspflichten, wenn du vom Finanzamt gefragt wirst, was war denn vor neun Jahren auf der Rechnung? Ja, da brauchst du vielleicht ein Archiv, ein revisionssicheres Archiv eventuell sogar für deine Daten. Das können alles harte Anforderungen vom Gesetzgeber sein. Und dann haben wir noch so eine Rolle im Unternehmen. Datenschutzbeauftragte hatten wir gerade schon, aber es gibt vielleicht auch Sicherheitsverantwortliche, die genaue Vorgaben machen für Zugrissschutz, für erzwungene Verschlüsselung vielleicht, für Pentests, die gemacht werden müssen, bevor so ein System online gehen kann. Ja, kann ja sein, was auch immer. Als Fisi suchst du dir eine neue Firewall aus, die du installierst, hast aber nicht daran gedacht, die zu patchen oder irgendwelche Sicherheitssachen richtig einzustellen. Dann wäre es ganz gut, wenn die zentrale Firewall des Unternehmens vielleicht, bevor sie live geht, mal so einen Pentest bekommen von externen, um zu gucken, dass du wirklich an alles gedacht hast. So, und das muss aber eingeplant werden. Das kostet Geld, das kostet Zeit, das muss alles mit in deine Projektplanung rein. Also, noch ein Punkt, an den man denken könnte.

[14:56] Und dann, das finde ich besonders interessant immer, der Kulturkreis. Das ist auch ein toller Stakeholder, denn wenn wir zum Beispiel in Deutschland unsere Software programmieren, dann ist ja für uns selbstverständlich, dass wir von links nach rechts lesen. Aber wenn wir zum Beispiel internationale Software bauen, weil wir in einem Konzern arbeiten und die Software wird weltweit eingesetzt, wie ist es denn dann mit Sprache? Muss das einfach nur übersetzt werden oder müssen wir vielleicht sogar die ganze Schreibrichtung ändern, von links nach rechts nach rechts nach links? Ich glaube, ich bin jetzt nicht so der Sprachexperte, aber ich glaube, Arabisch wird zum Beispiel von rechts nach links gelesen. Und ich meine, Japanisch oder Chinesisch wird auch, wie auch immer, wird von oben nach unten gelesen. Also spaltenweise, glaube ich. Korrigiert mich gern, wenn das falsch ist. Und da muss ich vielleicht meine ganze Software umgestalten, je nachdem, in welchem Land die gerade ausgerollt wird. Und ganz klassisch natürlich Datumsformate, Zahlenformate. Da ist ja, je nachdem, in welchem Land man ist, wird alles irgendwie unterschiedlich gemacht. Gemacht, insbesondere natürlich USA versus Europa, die allein die Datumsformate, also mich macht sowas immer verrückt. Wie kann man den, wie schreiben die das? Monat, Tag, Jahr, also das beknackteste Datumsformat ever.

[16:00] Oder kann man vielleicht überall einfach ISO-Datumsformat nehmen, das einzig Vernünftige. Je nachdem, wo ich mich befinde, kann es halt unterschiedlich sein. So, wen haben wir noch? Management oder Geschäftsführung dürfen wir auch nicht vergessen. Die wollen, dass sich das Ding irgendwann amortisiert. Hey, das machst du nicht nur für die IHK-Prüfenden, weil wenn du deinen Chef in Zukunft fragst, hey, darf ich dieses Projekt umsetzen, wird er auch als erstes fragen, was kostet das denn? Bzw. eigentlich, wenn ein schlauer Chef ist, was bringt uns das denn? Spart uns das Geld? Wann amortisiert sich das Ding? Ja, also Return on Investment ist hier das Stichwort. Wie gut, dass du eine Amortisationsrechnung für dein Projekt machst, nicht wahr? Ja, so außerdem gucken wir natürlich auf strategische Ziele, passt das Projekt gut in unser Budget, in unser Portfolio, nennt man es ja auch gerne, ist das überhaupt sinnvoll für das Unternehmen da zu investieren zum Beispiel und vielleicht auch Skalierbarkeit, ne, wenn die zum Beispiel sagen, ja mach mal hier die neue Ticket-Software für Eventim, ja, dann sollte die vielleicht skalieren zu Weihnachten zum Beispiel, ne.

[16:55] So, zwei habe ich noch. Externe Dienstleister. Wenn du mit irgendjemandem zusammenarbeitest, vielleicht gerade in FISI-Projekten, die stellen dir, weiß ich nicht, Hardware bereit oder installieren dir das Server oder die Cloud-Infrastruktur oder was auch immer. Da ist natürlich wichtig, Schnittstellen. Wie kommuniziert ihr? Gibt es technische Schnittstellen? Gibt es schriftliche Schnittstellen? Per E-Mail, Telefon, was auch immer. Sowas muss natürlich festgelegt werden. Gibt es Service-Level-Agreements, die ihr aushandeln müsst, vielleicht sogar während deiner Projektzeit. Das sind alles Themen, die mit externen geklärt werden müssen, mit internen vielleicht nicht so. Und letzter Punkt, Und vielleicht limitierender Faktor Hardware, beziehungsweise die vorhandene Infrastruktur. Das ist weder ein Mensch noch eine Institution, aber kann trotzdem ein Stakeholder sein. Denn wenn du da eben einen dicken Server hast, aber keinen zweiten, dann muss deine Applikation sich vielleicht daran orientieren, dass sie darauf läuft, dass sie die Ressourcen sparsam einsetzt und so weiter. Also vielleicht hast du konkrete Limitierungen. Deine Software darf maximal zwei CPUs benutzen, weil mehr haben wir nicht frei im VMware Cluster. Kann ja sein. Also Limitierung durch CPU oder RAM. Oder Netzwerklatenzen. Vielleicht habt ihr, keine Ahnung, nur eine Remote-Dial-In-Verbindung, weil deine Software am Südpol läuft. Ich weiß es nicht. Dann gibt es vielleicht Probleme mit der Netzwerklatenz und du musst darauf achten, dass du hohe Timeouts in deine Software einbaust oder so etwas. Und Storage natürlich. Vielleicht ist die nicht unendlich groß oder du protokollierst oder erzeugst riesengroße Datenmengen. Die müssen vielleicht auch irgendwo abgelegt werden können. Dafür brauchst du vielleicht genug Speicherplatz.

[18:19] Also, wir haben jetzt ganz viele Stakeholder gehört. Ich wiederhole nochmal kurz. Kunde, Kundin, Endbenutzerin, Projektleitung, Entwickler oder Administratoren. Dann haben wir den IT-Betrieb, Datenschutz, Staat und Gesetzgeber.

[18:32] Sicherheitsverantwortliche, Kulturkreis, Management, externe Dienstleistende, Hardware. Das sind so meine, die mir so eingefallen sind. Wahrscheinlich gibt es noch mehr, aber du siehst, es gibt nicht nur einen Stakeholder, sondern ein paar mehr, an die du denken musst unbedingt bei deinem Projekt. Denn sonst vergisst du vielleicht hinten was und hast eben kein qualitatives Projekt. denn wir erinnern uns Qualität, Übereinstimmung mit den Anforderungen.

[18:56] So, wie machst du das jetzt konkret für dein Projekt? Nummer eins, sammel erstmal die Stakeholder. Wer könnte Interesse an deinem Projekt haben? Heißt ja nicht, dass sie es haben müssen, aber erstmal eine Liste aufstellen, an wen du denken könntest. Und dann kannst du dir ja vielleicht schon mal sogar gruppieren. Beispiel, intern oder extern. Was sind Leute, mit denen ich eh zusammenarbeite? Da sind die Anforderungen vielleicht, ja, was auch immer die Folge ist. Vielleicht sind sie wichtiger als die externen, vielleicht unwichtiger. Das ist halt die Frage, wie du es jetzt gruppierst. Das kann ich für dein Projekt natürlich nicht vorgeben, was da sinnvoll ist. Das ist nur ein Beispiel, wie du das machen könntest. Und dann könntest du je nach Gruppe dir die Anforderungen abholen. Vielleicht hast du eine Person, die sogar mehrere Stakeholder abdeckt, weil sie gleichzeitig Kundin und Endbenutzerin ist. Als Beispiel könnte ja sein. Oder gleichzeitig Kundin und Management könnte ja auch sein. Dann sparst du dir quasi mit jedem einzelnen Menschen zu sprechen. Kannst du sowieso nicht. Du musst ja immer, wenn du zum Beispiel für 300 Benutzerinnen was programmierst, kannst du nicht mit 300 Leuten reden. Dann musst du sowieso eine Auswahl treffen. Ja, also gruppier die vielleicht, such dir dann passende Repräsentationen dieser Gruppen, zum Beispiel eine Key-Userin, die auch sonst in Firmenprojekten immer gut oder Eingebungen macht für Benutzerfreundlichkeit oder so. Dann fragst du die einfach, weil die kann das gut oder denkt an viele Sachen oder so.

[20:10] Also such dir die konkreten Personen raus oder wenn es keine Personen sind, such dir die konkreten Gesetze raus oder frag jemanden, der sich mit diesen Gesetzen auskennt. Stichwort Sicherheitsbeauftragter, Datenschutzbeauftragter etc. Und dann fragst du die einfach, Oder machst andere Dinge, um an die Anforderung zu kommen? Und ich glaube, das wird eine weitere Podcast-Episode, denn da habe ich mindestens zehn verschiedene Wege, wie man an diese Anforderung rankommt. Aber das soll heute nicht das Thema sein. Oft wird es halt vielleicht für so ein Projekt einfach erstmal ein Gespräch sein. Erzähl mir doch mal, was du haben willst. Also, hol dir die Anforderung von diesem Stakeholder, schreib die auf, priorisiere die, formuliere die einheitlich und dann hast du schon mal das erste Artefakt für deine Projektarbeit, nämlich etwas wie ein Lastenheft, hatte ich eingangs schon gesagt. Und dann sind wir weiter bei der Anforderungsanalyse, aber das schaffen wir heute auch alles nicht mehr. Du kannst dir angucken, gibt es widersprüchliche Anforderungen? Was sind denn jetzt die wichtigsten? Was sind muss, kann, sollte, nicht Anforderungen? Ja, das geht dann alles noch seinen Weg. Aber heute ging es ja erstmal darum, überhaupt an die Stakeholder zu denken und da ranzukommen. Und ich denke, das soll jetzt erstmal reichen für heute. Zum Abschluss ein kleines Mini-Beispiel. Angenommen, du baust eine klassische Web-App als Anwendungsermittlerin.

[21:15] Da hast du sicherlich mindestens mal Benutzerinnen. Die wollen vielleicht eine einfache UI. Du hast auf jeden Fall irgendeinen Admin, der was haben will. Sei es Security-Einschränkungen, Rechteverwaltung, Logging zum Beispiel. Der aber auch, oder das aber auch für den Betrieb natürlich interessant ist. Und natürlich hast du automatisch sowas wie den Staat, der dir das GVO vorgibt. Wenn du zum Beispiel eine Person mit zu den Daten hast, dann musst du die einhalten. Punkt. Da gibt es gar keine Widerrede. Du musst es einhalten. Es ist gesetzliche Vorgabe. So, das sind schon mal ein paar, die anfallen bei einem kleinen Mini-Web-App-Projekt.

[21:48] Und zum Fazit heute, ganz wichtig, denk bei deinem Projekt dran, es gibt viele potenzielle Stakeholder, nicht nur der oder die Kundin ist Stakeholder oder der oder die Benutzerin, sondern es gibt noch viele andere. Schau dir meine Liste nochmal an, überlege, was ist für dein Projekt sinnvoll, welche gibt es da, welche Personen sind auch entsprechend in der Rolle und wen kannst du fragen über diese Anforderungen. Denn die Anforderungen entscheiden über deinen Projekterfolg. Der Erfolg definiert sich danach, wie gut du die Anforderungen deiner Stakeholder umgesetzt hast. Also, es lohnt sich, da ein bisschen Zeit zu installieren, zu investieren. Ich bin schon hier, ich bin schon im Fiesi-Slagging angekommen. Also, mach dir eine Liste, sprich mit den Leuten und vergiss keine Anforderungen. Das ist ein Hauptgrund, warum Projekte scheitern, weil einfach Anforderungen nicht richtig umgesetzt wurden oder gar nicht umgesetzt wurden.

[22:39] So, ich hoffe, das hilft dir ein bisschen bei deiner Projektarbeit. Ich wünsche dir viel Erfolg bei Projektdokumentation und Präsentation und bis zum nächsten Mal.