Stakeholder für deine IHK-Projektarbeit – IT-Berufe-Podcast-Shorts #8

Um Stakeholder für deine IHK-Projektarbeit geht es in der achten
Episode der Shorts des IT-Berufe-Podcasts.


Ich zeige dir in diesem Podcast-Short, warum Stakeholder für
jedes IHK-Abschlussprojekt zentral sind: Von ihnen kommen die
Anforderungen, an denen sich später die Qualität deines Projekts
misst. Dabei solltest du nicht nur an Kund:innen und
Benutzer:innen denken, sondern auch zum Beispiel an
Projektleitung, Betrieb, Support, Datenschutz, Gesetzgeber,
Sicherheitsverantwortliche, Management, externe Dienstleistende
oder technische Rahmenbedingungen. Ich empfehle dir, alle
relevanten Stakeholder systematisch zu sammeln, ihre
Anforderungen zu dokumentieren und zu priorisieren, damit dein
Projekt nicht an übersehenen Anforderungen scheitert.
Stakeholder und Anforderungen im IHK-Abschlussprojekt

Ich erkläre dir, warum die Stakeholder-Analyse in praktisch jedem
Abschlussprojekt für die IHK-Prüfung wichtig ist. Egal ob du in
der Anwendungsentwicklung, Systemintegration oder in einem
kaufmännischen IT-Beruf arbeitest: Du brauchst eine
Anforderungsanalyse. Dabei geht es darum,
herauszufinden, wer was von deinem Projekt
erwartet und welche Anforderungen daraus entstehen.


Die Anforderungen musst du aufnehmen, dokumentieren, priorisieren
und konkretisieren. Sie sind entscheidend für den Projekterfolg,
denn Qualität bedeutet: Grad der Übereinstimmung mit den
Anforderungen. Wenn Anforderungen fehlen, unklar sind
oder übersehen wurden, kannst du am Ende nicht sicher sagen, ob
dein Projekt wirklich erfolgreich ist.
Was Stakeholder sind

Ich fasse Stakeholder als alle Personen, Rollen, Institutionen
oder auch Rahmenbedingungen auf, die:


Interesse an deinem Projekt haben,

Einfluss auf dein Projekt haben,

oder von deinem Projekt betroffen sind.



Wichtig ist: Nicht alle denkbaren Stakeholder sind in
jedem Projekt relevant. Die Liste soll dir helfen,
mögliche Stakeholder nicht zu vergessen.
Warum Stakeholder oft übersehen werden

Ich beobachte häufig, dass Prüflinge nur an folgende Stakeholder
denken:


Kund:innen beziehungsweise Auftraggeber:innen

Endbenutzer:innen



Dabei werden viele weitere Stakeholder vergessen, obwohl sie
ebenfalls konkrete und teilweise harte Anforderungen an das
Projekt haben. Wenn du nur einzelne Stakeholder berücksichtigst,
kann dein Projekt später scheitern, weil wichtige Anforderungen
fehlen.
Mögliche Stakeholder und ihre typischen Anforderungen
Kund:innen oder Auftraggeber:innen

Diese Stakeholder bezahlen das Projekt oder geben es in Auftrag.
Ihre typischen Interessen sind:


Einhaltung des Budgets

Einhaltung von Terminen

Erreichen der Business-Ziele



Kund:innen sind nicht automatisch auch die Menschen, die das
Ergebnis später benutzen.
Endbenutzer:innen

Das sind die Personen, die mit der Software oder dem System
tatsächlich arbeiten. Ihre Anforderungen können ganz anders sein
als die der Kund:innen, zum Beispiel:


einfache Bedienung

gute Performance

Zuverlässigkeit



Das gilt nicht nur für Software, sondern auch für Systeme in der
Systemintegration.
Projektleitung

Auch die Projektleitung ist ein Stakeholder. In deinem
IHK-Projekt kannst das auch du selbst sein. Mögliche
Anforderungen sind:


Planungssicherheit

Risikominimierung

Reporting



Gerade im Prüfungsprojekt ist Planungssicherheit wichtig, weil du
nur eine begrenzte Stundenzahl hast.
Entwickler:innen beziehungsweise Administrator:innen

Die Personen, die das System später weiterentwickeln oder
betreiben, haben ebenfalls Anforderungen. Beispiele sind:


wartbarer Code

stabile Systeme

gute Testbarkeit

definierte Deployment-Prozesse

stabile APIs

eventuell Anforderungen an UX, UI oder Barrierefreiheit



Für die Systemintegration können zusätzlich wichtig sein:


hohe Verfügbarkeit

Skalierbarkeit

Monitoring

Alerts

IT-Betrieb und Support

Dieser Stakeholder wird oft vergessen, obwohl das System nach der
Einführung meist über längere Zeit betrieben wird. Typische
Anforderungen sind:


Wartbarkeit im Betrieb

Logging

Dokumentation

klare Prozesse für Fehlerfälle

Datenschutz und Compliance

Sobald dein Projekt in einem regulierten Umfeld stattfindet,
können daraus verbindliche Anforderungen entstehen. Beispiele
sind:


DSGVO-Konformität

Datensparsamkeit

Zugriffskontrollen

Monitoring

weitere organisatorische oder technische Vorgaben



Ich nenne auch zusätzliche Vorschriften wie Code-Reviews,
Vier-Augen-Prinzip oder neue regulatorische Anforderungen.
Staat und Gesetzgeber

Je nach Branche gelten weitere gesetzliche Vorgaben, zum
Beispiel:


Anforderungen an Barrierefreiheit

Aufbewahrungspflichten

revisionssichere Archivierung



Diese Vorgaben können sehr konkrete Anforderungen an Software
oder Infrastruktur auslösen.
Sicherheitsverantwortliche

Im Unternehmen kann es Rollen geben, die Sicherheitsanforderungen
vorgeben. Beispiele sind:


Zugriffsschutz

Verschlüsselung

Pentests vor dem Go-live



Solche Punkte musst du bei Zeit, Budget und Planung
berücksichtigen.
Kulturkreis

Wenn Software international eingesetzt wird, entstehen
Anforderungen durch Sprache und Nutzungskontext, zum Beispiel:


Übersetzungen

unterschiedliche Schreibrichtungen

Datumsformate

Zahlenformate

Management oder Geschäftsführung

Diese Stakeholder interessieren sich vor allem für die
wirtschaftliche und strategische Seite des Projekts, zum
Beispiel:


Amortisation

Return on Investment

strategische Passung

Budget und Portfolio

Skalierbarkeit

Externe Dienstleistende

Wenn externe Unternehmen beteiligt sind, können zusätzliche
Anforderungen entstehen, etwa:


technische oder organisatorische Schnittstellen

Kommunikationswege

Service-Level-Agreements

Hardware beziehungsweise vorhandene Infrastruktur

Auch technische Rahmenbedingungen können wie ein Stakeholder
wirken. Beispiele sind:


begrenzte CPU- oder RAM-Ressourcen

Netzwerklatenzen

begrenzter Speicherplatz



Diese Limitierungen beeinflussen direkt, wie du dein Projekt
umsetzen kannst.
So kannst du in deinem Projekt vorgehen

Ich empfehle dir ein schrittweises Vorgehen:


Stakeholder sammeln
Überlege zuerst, wer Interesse an deinem Projekt haben könnte.


Stakeholder gruppieren
Zum Beispiel in intern und extern oder nach anderen sinnvollen
Kriterien.


Repräsentierende Personen auswählen
Du kannst nicht mit allen sprechen, also such dir passende
Ansprechpersonen oder Rollen aus, etwa Key-User:innen.


Anforderungen erheben
Das kann oft einfach über Gespräche passieren. Bei Gesetzen oder
Spezialthemen kannst du auch Fachpersonen wie Datenschutz- oder
Sicherheitsbeauftragte einbeziehen.


Anforderungen dokumentieren und
priorisieren
Schreib die Anforderungen auf, formuliere sie einheitlich und
priorisiere sie. Daraus kann zum Beispiel ein Lastenheft
entstehen.


Widersprüche und Prioritäten prüfen
Später kannst du analysieren, welche Anforderungen besonders
wichtig sind und ob es Konflikte zwischen ihnen gibt.
Beispiel aus einem kleinen Web-App-Projekt

Ich nenne zum Schluss ein einfaches Beispiel:


Benutzer:innen wollen eine einfache Oberfläche

Admins wollen zum Beispiel Rechteverwaltung,
Security-Vorgaben und Logging

gesetzliche Vorgaben wie DSGVO müssen bei personenbezogenen
Daten eingehalten werden



Selbst bei einem kleinen Projekt kommen also schnell mehrere
Stakeholder zusammen.
Fazit

Ich mache deutlich, dass du in deinem Projekt nicht nur an
Kund:innen oder Benutzer:innen denken solltest. Es gibt viele
weitere mögliche Stakeholder, deren Anforderungen dein Projekt
beeinflussen. Wenn du diese Anforderungen frühzeitig sammelst,
dokumentierst und priorisierst, reduzierst du das Risiko, dass
dein Projekt an übersehenen Anforderungen scheitert. Genau daran
entscheidet sich letztlich auch, wie erfolgreich und qualitativ
dein Projekt ist.
Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Transkription der gesamten Episode

Automatisch erzeugte Transkription der Episode

[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.